Danjo's two cents NAV, Powershell, Android, C#, Lync, Win8, …

2Feb/120

Mit Powershell in C# neue Dienste anlegen

Derzeit bin ich damit beschäftigt das C#/Powershell-Projekt für NAV-Services des MS Dynamics NAV Team Blog's für mich anzupassen und zu erweitern.
(http://blogs.msdn.com/b/nav/archive/2011/09/19/using-powershell-to-configure-dynamics-nav-services.aspx)

Während einiges schnell umgesetzt werden kann, hat sich das Anlegen von Diensten, gerade über Remote-Zugriffe als nicht so trivial erwiesen. Das Hauptproblem für mich war das ich keine Beispiele online finden konnte. 😉
Nach einigen Tagen suchen und testen habe ich es mit wenigen Zeilen Code geschafft. (Dieser Codeschnipsel ist Teil des oben verlinkten Projektes, alle nicht hier definierten Objekte sind dort zu finden)

Schaut euch diesen MSDN-Artikel für eine Definition der Parameter und weitere Starttypen an.

12Jan/120

Mergen von Reports mit RDLData (VS-Design)

Wie einige bereits bemerkt haben dürften, gibt es beim Mergen von Reports seit NAV 2009 ein paar neue Herausforderungen.

Meiner Meinung nach ist der beste Weg NAV-Objekte zu mergen nach wie vor der Textvergleich. Dies gilt auch für Reports, sogar wenn diese RDLData beinhalten. Die Gefahr beim Merge von RDLData in Reports besteht darin, dass ein Objekt ohne korrekte RDLData zwar in NAV importiert werden kann, aber nicht mehr editierbar in Visual Studio ist. Der häufigste Fehler den ich beim merge von Reports erhalten habe, war das eine (oder mehrere) Tabellenzeilen nicht die selbe Anzahl an Spalten hatte/n wie die anderen. Das kann zum Beispiel dann passieren wenn ein neues Feld in eine existierende Zeile eingefügt wird, und zeitgleich eine neue Zeile (ohne leeres Feld als Platzhalter für die neue Spalte) ergänzt wurde.

 

Ich habe hier ein kleines Beispiel entworfen um das ganze zu veranschaulichen.

Layout des Ursprungsreports:

Layout nach Entwicklung A:

Eine neue Zeile wurde eingefügt.

Layout nach Entwicklung B:

In der Tabelle wurde ein neues Feld hinzugefügt (das bedeutet, dass es zu allen Zeilen hinzugefügt wurde).

Damit das Feld nur in der benötigsten Zeile zu sehen ist, wurde es in den anderen Zeilen mit den Zellen daneben zusammengeführt.

 

So lange ein Report nur eine Hand voll Zeilen und Felder hat, ist es kein Problem dies beim merge zu erkennen und einen Fehler zu vermeiden. Und auch wenn es bereits passiert ist, geht es relativ schnell die entsprechende Stelle zu finden und zu korrigieren.

Anders sieht es allerdings aus, wenn wir viele Tabellen, Zeilen und Felder haben. Wie soll man hier die richtigen Codezeilen wiederfinden?

Da das RDLData-Design eines Reports gemeinsamkeiten mit HTML aufweist, habe ich ein kleines Tool geschrieben um die Anzahl der Spalten pro Zeile auf zu summieren. Hiermit wird es möglich ohne lange Suche im Text die störende Codestücke zu finden.

Dies ist das Ergebnis des Tools bei einem intakten Report:

Wie liest man das ganze nun:

1 Reihe mit 2 Feldern / Spalten (im Objekt an Zeile 121 zu finden)

1 Reihe mit einem Feld (das aus 2 zusammengefügten Feldern besteht)

Dieser Report beseht aus einer Tabelle (mit dem Namen "Table1"), welche aus sieben Reihen besteht.

Die erste Reihe beginnt im Textfile in Zeile 121, die letzte in Zeile 314. Jeder der Reihen besteht aus zwei Spalten. Vier der Reihen bestehen aus je zwei Zellen / Textboxen, die anderen drei Reihen bestehen aus nur einre Textbox mit einem "colspan" von 2 (was so viel heisst wie zwei Zellen wurden im Visual Studio zusammen gefügt).

 

Um auf mein Beispiel zurück zu kommen, ist hier das Ergebnis eines 3-Wege-merges mit einem Standardeditor zu sehen (in diesem Fall habe ich Beyond Compare verwendet)

Wie deutlich abzulesen ist, wurde die Tabellenstruktur total zerstört. Das Objekt lässt sich zwar importieren und kompillieren, bringt nun allerdings Fehler beim Versuch das Layout zu editieren.

Um dies zu korrigieren, schaue ich mir nun das Ergebnis der Analyse an:

Die "breiteste"  Reihe besteht aus 4 Spalten, dass bedeutet das ich nun die anderen Reihen so anpassen muss das sie die selbe Anzahl an Spalten haben. Der einfachste Weg dies zu erreichen ist es die "Col-Span"-Eigenschaft zu verändern bzw. einzufügen. In der ersten Reihe ist das dann <ColSpan>2</ColSpan>. In der zweiten Reihe <ColSpan>3</ColSpan> und in der dritten Reihe muss lediglich das <ColSpan>3</ColSpan> durch <ColSpan>4</ColSpan> ersetzt werden. Das ganze zeiht sich dann weiter so durch bis zur letzten Reihe.

In diesem Fall ist das natürlich zu viel Aufwand, da recht schnell zu sehen ist das die 4 Spalten ein einmaliger Ausreiser ist und dazu auch noch zusammengefügte Spalten enthält.. Der schnellere Weg ist es hier den ColSpan-Tag der Reihe ab Zeile 330 zu entfernen und die Zeilen mit nur zwei Spalten zu verändern.

Anschliessend kann das Objekt erneut in NAV importiert und im Visual Studio bearbeitet werden (was nach der "blinden" Abänderung der Struktur auch zu empfehlen ist).

 

Hier ist der Link zum VS-Projekt: FindMissingTableCellsInRDL

   
%d Bloggern gefällt das: