Dynamics NAV: Verzeichnisinhalt ermitteln

Die Variable recFile verweist auf die Tabelle „File“.

File-Record

Heute möchte ich das Beispiel ein wenig ausbauen und vor allem auf die Gestaltung des XMLPorts mit einer variablen Anzahl von Unterknoten eingehen.

XML-Datei

Zum besseren Verständnis schauen wir uns am Beginn gleich einmal das gewünschte Ergebnis an:

Zu einem Mitarbeiter soll neben den allgemeinen Daten (Name, Geburtsdatum, Gehalt) auch die variable Anzahl der Kinder mit Namen und Alter abgespeichert werden.

XMLPort

Struktur

Den entsprechenden XMLPort habe ich folgendermaßen aufgebaut:

XMLPort – Struktur

Zu beachten ist der SourceType Table beim dynamischen Unterknoten „Kind“. Die DataSource wurde dabei auf Integer festgelegt (und der Name statt <Integer>(Integer) auf Kind(Integer) abgeändert).

Ich habe auch dieses Beispiel wieder bewußt sehr einfach gehalten. So würde man z.B. in Navision mangels dynamischer Arrays wohl eher auf eine temporäre Tabelle zum Zwischenspeichern der Kinderdaten zurückgreifen.

Der Einfachheit halber setze ich aber voraus, dass es keine Mitarbeiter mit mehr als 10 Kindern geben wird, um dennoch auf ein Array (eben mit fixer Dimensionsanzahl) zurückgreifen zu können.

Das Feld „KinderAnzahl“ soll nicht mit einem Fixwert beschickt sondern dynamisch aus der Anzahl der übergebenen Kinder-Daten errechnet werden.

Globale Variablen

Globale Variablen für den dynamischen Unterknoten

In g_intKinderZaehler wird automatisch die Anzahl der übergebenen Kinder hochgezählt.

Die Daten pro Kind (im Beispiel: Name und Alter) stehen im Array g_strKind. Die Länge dieser Variablen (im Beispiel: 20) muss der Länge des längsten „Unterfeldes“ (z.B. KindName) entsprechen, ansonst kann ein Laufzeitfehler auftreten – Siehe auch Routine AddKind.

Die Array-Dimensionen habe ich folgendermaßen festgelegt (wie gesagt: dynamsiche Arrays kennt NAV 5.0 SP1 nicht):

Festlegen der Array-Dimensionen für den Unterknoten

• Die 1. Dimension bezieht sich auf die maximale Anzahl der Kinder: 10
• Die 2. Dimension muss der Anzahl der Unterknoten-Elemente entsprechen (pro Kind: Name und Alter)

Programmierung

Wie wird nun die variable Anzahl an Kindern befüllt?

Ermittlung der Anzahl der Kinder

Im Trigger OnInitXMLPort() wird der „Kinder-Zähler“ auf 0 gesetzt.

Bei der Ausgabe der Daten wird diese Zähler-Variable im Trigger OnPreXMLPort() dem Element „KinderAnzahl“ zugewiesen.

Wie werden nun die Kind-Daten an den XML-Port übergeben?

Ich habe dazu eine Routine „AddKind“ entwickelt, welche meine Array-Variable entsprechend befüllt und dabei auch den Kinder-Zähler hochzählt.

Wie erfolgt nun die Ausgabe dieser Kinddaten?

Ausgabe der dynamischen Kinder-Daten

Im Trigger „Kind – Export::OnPreXMLItem()“ wird festgelegt, wieviele Unter-Elemente auszugeben sind. Im Trigger „Kind – Export::OnAfterGetRecord()“ erfolgt schließelich die Zuweisung der Array-Variablen an die XML-Unterknotenelemente.

Nur der Vollständigkeit halber möchte ich auch noch den Programmcode zur Befüllung der Mitarbeiterdaten anführen, welche ich mittels meiner Routine „SetMitarbeiter“ vornehme:

Befüllung der Mitarbeiterdaten

XMLPort-Aufruf

Zu guter Letzt fehlt uns jetzt nur noch der Aufruf unseres XMLPorts.

Die grundsätzliche Vorgangsweise habe ich ja bereits in einem früheren Artikel beschrieben. Heute wollen wir aber auch noch die neuen Erweiterungen berücksichtigen und in unserer Aufruf-CodeUnit einbauen:

Aufruf des XML-Ports

Schöne Grüße – Christian

Ich habe einen XMLPort für einen Daten-Export benötigt.

Dazu habe ich folgende Routine in eine CodeUnit eingebaut:

PROCEDURE XMLAusgabeTest();

VAR

XMLFile : File;
sOut : OutStream;
XMLPort : XMLport #ObjectID des XMLPorts#;

BEGIN

XMLFile.TEXTMODE(TRUE);
XMLFile.CREATE(‚C:\Temp\xmltest.xml‘);
XMLFile.CREATEOUTSTREAM(sOut);
XMLPort.SETDESTINATION(sOut);
XMLPort.EXPORT;
XMLFile.CLOSE;

END;

Die Routine benötigt in dieser einfachen Form 3 Variablen:

• XMLFile – Datentyp File
• sOut – Datentyp OutStream
• XMLPort – Datentyp XMLPort (Verweis auf einen zuvor errichteten XMLPort)

Sieht man aber genauer unter die Oberfläche, merkt man dann doch den einen oder anderen Unterschied – um nur einige zu nennen:

• Wie elegant lassen sich komplette Umänderungen im Layout und den Anwender-Funktionalitäten durchführen
• Welche komplexen Möglichkeiten sind bereits in der Admin-Oberfläche untergebracht, ohne Eingriffe in den PHP-Skripts oder CSS-Dateien erforderlich zu machen
• Wie rasch wird die Seite an den Besucher ausgeliefert (soll auch für das Google-Ranking relevant sein)
• Gibt es ein relative hohe Wahrscheinlichkeit (100%-ige Sicherheit wird es nie geben), dass das Theme auch für zukünftige WordPress-Versionen weitergepflegt wird
• Und nicht zuletzt: Wie bzw. wie rasch erhält man professionellen Support bei spezifischen Detailfragen (insbesondere für Geschäftssites unumgänglich)

Insbesondere wegen des letzten Punktes hatte für mich eine deutschsprachige Entwicklung Vorrang – die Suche nach geeigneten Premium Themes gestaltete sich aber anfänglich gar nicht so einfach.

Während es am englischsprachigen Markt (den ich natürlich nie gänzlich ausschließen würde, wenn meine sonstigen Qualitätsanforderungen erfüllt werden würden) massenhaft Premium Themes – auch relativ preisgünstige (hoffentlich nicht billige) – gibt, scheint die deutschsprachige WordPress-Entwicklergemeinschaft eine kleine, aber wohl feine und eingeschworene Gemeinschaft zu sein, da hier sehr gerne untereinander verlinkt wird.

Die für mich letztlich beste Ausgangsadresse fand ich bei „Perun“ (Vladimir Simovic), von dem ich auch ein WordPressbuch besitze.

Und dann ging das Demo-Schauen, Testen und Vergleichen erst richtig los.

Am Ende habe ich mich für folgende 3 Anbieter entschieden:

1. DER PRiNZ – Michael Oeser
2. xTreme One – Framework
3. ThemeShift – Simon Rimkus

Welche Themes im einzelnen ich bei diesen Anbietern gekauft habe sowie über meine ersten Eindrücke und Erfahrungen werde ich in einem späteren Artikel berichten.

Schöne Grüße – Christian

Zumal ich nach dem Wühlen in meinen (nicht allzu zahlreichen) alten Einträgen doch den einen oder anderen guten Tipp entdeckte, der mir in der Zwischenzeit schon wieder entfallen war.

Ich habe ja schon des Öfteren über meine Suche nach einem idealen CMS berichtet – und was habe ich da in der Vergangenheit nicht schon alles getestet (Joomla, Typo3, DotNetNuke). Aber richtig warm wurde ich mit keinem dieser Systeme.

Ich möchte mich nicht erst wochenlang eingehend mit technischen Belangen herumschlagen / ärgern.

Mir geht es in erster Linie um das Schreiben selbst – nicht zum Selbstzweck, sondern um Dinge später wieder halbwegs rasch zu finden.

Ein Content-Management-System (CMS) also nicht wegen der unübertroffenen Fülle an Spezialfunktionen oder wegen seiner genialen Designbarkeit wegen, sondern als einfach handhabbares Redaktionssystem zum systematischen, strukturierten und geordneten Sammeln und Verwalten meiner Daten, Gedanken, Ideen, Erfahrungen und Informationen – zum rascheren Generieren und Abrufen von Wissen.

Und bei der Suche nach einem Tool, welches mich bei diesem Vorhaben möglichst effizient unterstützen konnte, stieß ich eben wieder auf WordPress – ein Software-Werkzeug, welches ich bereits seit einigen Jahren sehr gerne zum Bloggen verwende (u.a. in AlpenYetis Wanderblog oder auf Wanderprofi.at).

Und ebendieses WordPress hat sich in den letzten Jahren Dank des bemerkenswerten Einsatzes vieler – häufig freiwilliger – Entwickler zu einem respektablen CMS entwickelt.

Die Bedienbarkeit ist vergleichsweise einfach, die Gestaltbarkeit im Gegensatz zu einer Eigenentwicklung, wie ich sie viele Jahre zuvor gepflegt hatte, um ein Vielfaches flexibler.

Die Installation ging bei einem Provider meines Vertrauens gewohnt unkompliziert, da automatisch, vonstatten.

Für 2 neue Projekte wollte ich mir dieses Mal aber ein sich von der Masse abhebendes „Kleid“ leisten – bei WordPress nennt sich dieses vom Inhalt unabhängige und getrennte Äußere „Theme„.

Tausende dieser Themes findet man kostenlos im Internet und ich habe mir eine ganze Arbeitswoche gegönnt, um einen Favoriten zu küren. Aber immer wieder klemmte es hier und da.  Kleinigkeiten in der Bedienung oder im Layout oder auch gröbere Unverträglichkeiten mit dieser oder jender Browserversion.

Also habe ich mich dazu durchgerungen, für professionelle WordPress Premium Themes einen in Summe zwar nicht mehr kleinen, angesichts der schon bald erzielbaren Arbeitsersparnisse aber durchaus angemessenen Obulus im unteren dreistelligen Euro-Bereich aufzubringen.

Der größte Aufwand war ohnehin eine weitere Arbeitswoche für die Auswahl der mir am geeignetsten scheinenden Premium-Theme-Kandidaten.

Dass ich angesichts zu erwartender Detailfragen und nervenden Spezialproblemen im professionellen Einsatz auf deutschsprachigen Support Wert legte, erleichterte die Suche nicht unbedingt.

Aber ich wurde fündig (Siehe oben: Dreistelliger Euro-Bereich ;-)) und bin teilweise auch recht bis sehr zufrieden.

Warum nur recht zufrieden?

Nun – der erwartete Ärger blieb natürlich im speziellen Einzelfall nicht aus und nun versuche ich „Workarounds“ über den Support zu erfragen.

„Nur recht zufrieden“ auch deshalb, weil man entgegen der Marketingaussagen auch nach wie vor solides Grundwissen über HTML und CSS mitbringen sollte bzw. die Mächtigkeit einiger Werkzeuge doch eine längere Einarbeitungszeit erfordert, auch wenn vorher im Beispielvideo alles so kinderleicht ausgesehen hat.

Im nächsten Artikel werde ich dann etwas näher auf die von mir erworbenen Premium Themes eingehen, die mir erlauben sollen, WordPress etwas abseits der großen Masse als CMS einzusetzen.

Bis dahin

Schöne Grüße – Christian

• CODE: Varchar (maximal 250 Zeichen)
• OPTION: Integer
• INTEGER: Integer (Wertebereich von -2.147.483.647 bis +2.127.283.647)
• DECIMAL: DECIMAL (oder FLOAT???)
• DATE: SMALLDATETIME (SQLServer startet erst ab 01.01.1754)
• TIME: DATETIME
• BOOLEAN: TINYINT (oder BIT???)
• TEXT: VARCHAR (maximal 250 Zeichen)

„Das Speichern von Änderungen ist nicht zulässig. Die vorgenommenen Änderungen erfordern das Löschen und Neuerstellen der folgenden Tabellen. Sie haben entweder Änderungne an einer Tabelle vorgenommen, die nicht neu erstellt werden kann, oder die Option ‚Speichern von Änderungen verhindern, die die Neuerstellung der Tabelle erfordern‘ aktiviert.“

Lösung:

SQL Server Managementstudio

Menüfolge: Extras => Optionen

Auswahl Designers => Tabellen- und Datenbank-Designer

Option „Speichern von Änderungen verhindern, die die Neuerstellung der Tabelle erfordern“ deaktivieren (Hakerl rausnehmen)

Das Problem, welches sich dabei stellt:

Die Bat-Datei wird zwar bei manuellem Aufruf ordnungsgemäß ausgeführt, bei Eintrag in die Aufgabenplanung passiert aber nichts.

Workaround:

Nicht die Batch-Datei wird direkt im Startprogramm aufgerufen, sondern:

• Programm/Skript: C:\Windows\System32\cmd.exe 
• Argumente hinzufügen (optional): /C „/C:\MeinProgramm.Bat“

Bei einem XCOPY auf ein Netzlaufwerk musste statt dem zugeordneten Laufwerksbuchstaben der UNC-Pfad verwendet werden.