PowerShell: Skripte aus NAV erzeugen und ausführen

Da die PowerShell-Konsole oder das Powershell ISE sich unter Angabe eines auszuführenden Skripts auch aus NAV heraus starten lässt (das geht mit jeder Version, es finden nur einfache Textexporte statt) ist es möglich, Objekte aus allen Datenbanken ab NAV 2013 direkt per Mausklick zu exportieren (auch importieren,kompilieren), wenn man das richtige Skript dazu schreibt .

Um das umzusetzen, kann man die Datenbanknamen in einer separaten Tabelle erfassen, es kann aber auch eine vorhandene Tabelle wie z.B. die Kontakttabelle verwendet und um die notwendigen Felder erweitert werden.

2WayMerge_1.png

Das PowerShell-Skript wird über ein Codeunit mitsamt der notwendigen Parameter (Datenbankname, Servername, Clientordner, ggf. Objektfilter) erzeugt.
Bei den Clientordnern sind z.B. bei NAV 2015 mittlerweile schon 4 verschiedene Versionen notwendig, um alle Datenbanken ohne Konvertierung öffnen zu können (80_9,80_8,80_7,80_3).

2WayMerge_2.png

und anschließend entweder sofort im Skriptbereich aufgerufen …

2WayMerge_3.png

…oder im PowerShell ISE, dort kann man es vor der Ausführung noch einmal kontrollieren und ggf. abändern …

2WayMerge_4.png

…oder alternativ in der PowerShell-Konsole direkt ausgeführt.

Weitere Möglichkeiten :

• Objekte anhand einer festen Indexliste zu exportieren (z.B. um den Mergebereich eines Add-on aus einer Datenbank zu ziehen, in der dieses noch nicht vorhanden ist)
• Objekte anhand eines Objektfilters zu exportieren. Filtermöglichkeiten: ExportObjects
• ein beliebiges Objektpaket zu zerlegen und diese Objekte aus einer anderen Datenbank als Vergleichsobjektpaket zu ziehen
• Sprachlayer zu entfernen

In den nächsten Tagen folgen hier die Beispielobjekte dazu.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Falls ich das richtig verstanden habe: Beim Exportieren vergiss bitte nicht, dass eine Befehlszeile eine maximale Länge hat (ich glaube es waren 1024 Zeichen). Falls noch nicht implementiert, dann empfehle ich zum Einen die Liste soweit wie möglich mit Range-Operator aufzubauen und eine Möglichkeit zu schaffen, in mehreren Schritten zu exportieren.

Wenn du dann alles in einem Paket haben möchtest, kannst du über eine leere (neu angelegte) Datenbank die Objekte zwischenimportieren und dann als Gesamtpaket neu exportieren.

Wenn gleiche Objekte aus zwei Datenbanken benötigt werden, läuft das so:
Das Paket t1.txt wird in einzelne Dateien zerlegt, diese bilden eine temporäre Indexliste, die dann einzeln Objekt für Objekt abgearbeitet wird, am Schluss wird dann alles in der richtigen Objektgruppierung wieder in t2.txt zusammengefügt, damit es genauso aussieht, als wenn der Client es aus dem Development Environment exportiert hätte (das macht das Join-Cmdlet ja leider nicht, das ändert die Gruppierung).
Das Grundverfahren nutze ich schon seit Monaten. Neu ist jetzt, die parametrisierten Skripte zur Laufzeit aus NAV heraus zu erzeugen und direkt auszuführen. Das spart enorm viel Zeit, wenn man die Datenbankliste gepflegt hat.

Wenn man Tausende von Objekten exportiert, kommt die PowerShell beim Zusammenführen in das Gesamtpaket mit den Skripten u.U. an ihre Grenzen mit OutOfMemory, besonders Report-RDL-Layouts belegen ja extrem viel Platz. Da man in der Praxis pro Vorgang ja aber eher einige Hundert analysieren und mergen muss, läuft das bei mir alles stabil. Nachtrag: Wer trotzdem mehr benötigt, kann die Speicherzuweisung erhöhen.

Eine Hilfstabelle zum Erzeugen und Abspeichern der Objektfilterstrings ist auch mit dabei.

Wenn nichts dazwischen kommt, kommen die Beispielobjekte für den CC heute Abend.

Im Anhang befinden sich die Beispielobjekte für den Classic Client, erstellt mit NAV 2009 R2.

PS_ExportScript1.jpg

Anwendung:
Die Dateien t1.txt bzw. t2.txt werden von den Skripten jeweils im temporären Pfad des Benutzers (C:\Benutzer\<BENUTZERNAME>\AppData\Local\Temp)) abgelegt bzw. müssen als Startdatei (bei den Funktionen 3. und 4.) dort liegen. Zum einfachen Aufrufen kann man dafür einen Link unter Favoriten ablegen. Ich hatte anfangs C:\Temp\ verwendet, aber das kann bei Remotezugriff zu Konflikten führen, wenn mehrere Leute im Homeoffice sitzen . Für individuelle Pfadänderungen kann man den Code anpassen, im C/AL die Stellen TEMPORARYPATH und im Skriptbereich die Stellen $env:temp.

1. Export mit festem Index
Dazu muss ein Ordner mit den einzelnen Dateien vorhanden sein (im Beispielskript wird C:\Objexp\OPPINDEX verwendet) die man aus der Datenbank ziehen möchte. Bei mir liegen darin z.B. 139 Dateien, die bei jedem monatlichen Cumulative Update mindestens ggf. gemergt werden müssen. Der Inhalt dieser Dateien ist nicht relevant, die können auch leer sein, aber die Dateinamen müssen exakt stimmen, TAB…,PAG…,REP… usw., also so wie das Split-Cmdlet trennt.

TestIndex.png

2. Export mit Objektfilter
Dazu ruft man den Lookup von der Datenbanktabelle auf, die Objektfiltertabelle stellt den Filterstring aus den einzelnen Feldern automatisch zusammen.
Häufig benötigte Filter kann man hier auch mit einem eindeutigen Code abspeichern, dann müssen diese beim nächsten Export nur noch direkt aufgerufen werden.

PS_ExportScript2.jpg

3. Export mit temporärem Index
Wie heute hier schon beschrieben . Wie alle anderen Punkte wahlweise für t1.txt und t2.txt nutzbar.
Dieser temporäre Indexliste wird aus der t1.txt oder t2.txt durch das Skript erzeugt und dann für die aktuelle Datenbank abgearbeitet und erzeugt daraus ein Objektpaket als t2.txt bzw. t1.txt.

TempIndex.png

4. Sprachlayerentfernung
Von der Wirkungsweise wie dieses Skript (dort kann man einen beliebigen Dateipfad verwenden), nur eben auf t1.txt bzw. t2.txt im Tempordner angewendet.

PS-Menüpunkte: Führen das jeweilge Skript direkt in der PowerShell-Konsole aus und schließt diese nach der Ausführung.
PS-ISE-Menüpunkte: Rufen das Skript im Skriptbereich im PowerShell ISE auf. Mit F5 kann es dann ausgeführt werden, das ISE bleibt danach natürlich offen. Sollte dort noch ein gleichnamiges aus einem vorigen Lauf stehen, muss das vorher geschlossen werden, bzw. das aktuelle muss man hinterher im Skriptbereich selber schließen.

Die Nummernserie ist zur Vereinfachung des Beispiels hart codiert.

Sonstige Voraussetzungen:

• NAV 2015 Installation im normalen Clientordner 80, von dort werden die Cmdlets geladen. Dafür gab es auch Hotfixes, diese sollten von einer aktuellen Install-DVD ggf. ausgetauscht werden, wenn noch mit einem alten Build gearbeitet wird.
• Exportdatenbanken: ab NAV 2013. Die Verwaltungsdatenbank, die die Skripte erzeugt, kann dagegen auch eine 2.x sein .
• Im "Name Clientordner" muss der Name des Ordners stehen, der eine finsql.exe mit dem Build enthält, mit der die angegebene Datenbank ohne Konvertierung geöffnet werden kann. Diese Namen kurz halten (80_9,80_8 usw.)
• In der PowerShell Set-Executionpolicy mindestens RemoteSigned

t in den Dateinamen steht für 'temporär' und ist auch so zu verstehen , diese Dateien werden durch den aktuellen Lauf jeweils überschrieben.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Wenn man Tausende von Objekten exportiert, kommt die PowerShell beim Zusammenführen in das Gesamtpaket mit den Skripten u.U. an ihre Grenzen mit OutOfMemory, besonders Report-RDL-Layouts belegen ja extrem viel Platz.

Für Fälle wie diese kann man der PowerShell auch mehr Speicher als den Vorgabewert 1 GB zuweisen.
Fix Powershell error: System.OutofmemoryException (incl. NAV PSM wrapper)
Learn How to Configure PowerShell Memory