Erstellen einer Entität - beispielsweise eines Debitoren - per Code
12.11.2013Microsoft Dynamics AX (Axapta)
|
Dieser Beitrag bezieht sich auf die Version:
Dynamics AX 2012
Dynamics AX 2012
|
|
|
|
|
|
Dieser Beitrag bezieht sich auf die Version:
Dynamics AX 2012
|
Beim Start eines AX-Projektes ist die Übernahme von Daten aus Vorsystemen oft ein Thema. Mittlerweile gibt es zahlreiche Möglichkeiten dies zu tun - beispielswiese das Data import Export Framework (DIXF), ich möchte in diesem Beitrag aber auf die einfachste Variante eingehen, um eine Entität - im Beispiel einen Debitoren - in Dynamics AX per Code anzulegen.
Und diese aus meiner Sicht einfachste Variante ist, mittels X++ Logik einzubinden, welche die Daten direkt in die Tabelle schreibt. Ein solches Stück Code kann wie folgt aussehen:
Nachteile dieses einfachen Beispiels:
Es wird keine Logik aufgerufen, die bestimmte Felder eines neuen Datensatz initalisiert (CustTable.initValue())
Weder jene die im AOT als Mandatory gekennzeichnet sind (beispielsweise CustTable.CustGroup), noch solche die über die Programmlogik nur unter bestimmten Umständen ausgefüllt werden müssen (beispielsweise CustTable.TaxGroup).
Man kann in die Felder - solange es der Datentyp zulässt - irgendwelche Werte reinschreiben, beispielsweise auch Debitorengruppen, die im AX gar nicht vorhanden sind.
Beispielsweise werden normalerweise, wenn man eine Debitorengruppe einträgt, Standardwerte diese Gruppe in den Debitoren übernommen (Feld PaymTermId über die Methode initFromCustGroup())
Vorteile dieser Variante:
Da aus meiner Sicht die Nachteile überwiegen, würde ich persönlich die obige Variante nur in Ausnahmefällen verwenden.
Etwas besser ist die folgende Logik/der folgende Job, der prinzipiell immer noch wie oben arbeitet, d.h. wir schreiben nach wie vor direkt in die Tabelle hinein. Allerdings ist dieser Job bereits um einige Prüfungen erweitert worden, sodaß wir hier eher die Chance haben, daß unsere Entität genauso aussieht, wie wenn diese über das entsprechende (Debitoren-)Formular angelegt worden wäre.
Es werden die Methoden initValue(), validateField(), modifiedField() und validateWrite() explizit aufgerufen. Diese wiederrum führen jeweils weitere Logik aus.
Wie gesagt, macht dieser Job prinzipiell genau das selbe wie die ganz oben stehende Variante, nur etwas "eleganter". Allerdings haben wir die Entität, nämlich unseren Debitoren, immer noch nicht vollständig angelegt!
Beispielsweise ist im Datenmodell von Dynamics AX 2012 nämlich nicht vorgesehen, daß der Name des Debitoren direkt in der Tabelle CustTable gespeichert wird. Dieser wird im sog. Globalen Adressbuch verspeichert und diesen Umstand berücksichtigt der folgende Job. Auch besitzt dieser nun ein rudimentäres Errorhandling.
Letztlich haben alle oben angeführten Jobs zumindest einen Nachteil, versucht man nämlich beispielsweise einen 100 Zeichen langen Text in ein Textfeld einzufügen, welches lt. EDT nur 60 Zeichen fassen kann, so wird dieser Text kommentarlos abgeschnitten.