Wird die Eigenschaft(Property) “AllowEditOnCreate” eines Tabellenfeldes auf den Wert “No” gesetzt, ist es nicht möglich,
Werte für dieses Tabellenfeld über das AIF (Application Integration Framework) zu schreiben (Insert-Operation).
Alle Tabellenfelder, welche diese Eigenschaft auf “No” gesetzt haben, werden durch das AIF automatisch auf deren Default-Wert gesetzt und jegliche Wert der AIF Nachricht werden ignoriert.
Dies hat zur Folge, dass wenn das Tabellenfeld kein Enum ist, das Tabellenfeld immer leer ist.
Da dieser Automatismus schon vor Ausführung der AX<Table> Klasse greift, der Wert also schon beim Ausführen der entsprechenden Parm-Methode “leer” ist,
kann dieses Verhalten ohne Änderung der AIF-Basis Klassen nicht geändert werden.
Egal ob Anfänger oder schon erfahrener Dynamics AX Entwickler.
Von Zeit zu Zeit tauchen immer die gleichen Fragen und/oder Problemstellungen auf.
Was immer mal wieder in Foren oder Newsgroups zu lesen ist, ist die Frage, wie die Berechnung des Artikelpreises für eine Debitor mit X++ Code durchgeführt werden kann.
Der Standard von Microsoft Dynamics AX bringt zwar eine Maske zur “Preisabfrage” mit sich, welche diese Problemstellung eigentlich schon löst, allerdings ist es manchmal
notwendig, die Preisberechnung z.B. in einer Klasse durchzuführen, um mit dem Ergebnis weitere Operationen durchführen zu können.
Da in Dynamics AX Preise für einen Artikel nicht nur “direkt” im Artikelstamm, sondern auch in den Handelsvereinbarungen, hinterlegt werden können, stellt der Standard von
Dynamics AX die Klasse “PriceDisc” zur Verfügung, welche alle Möglichkeiten der Preispflege berücksichtig.
Unter Anderem werden auch Rabatte bzw. Zuschläge der Handelsvereinbarungen durch diese Klasse berücksichtigt.
Die Klasse “PriceDisc” stellt die statische Methode “actualSalesPriceDisc” bereit. Mit dieser können z.B. der Verkaufspreis pro Preiseinheit, der Rabatt oder die Zuschläge
berechnet und/oder ermittelt werden.
Durch eine zweite statische Methode “price2Amount” lässt sich anschließend der Nettobetrag eines Artikels ausrechnen.
Beispiel:
CustTable custTable = CustTable::find("5010");InventTable inventTable = InventTable::find("1000");Qty qty = 1.00; SalesPrice salesPrice; // Verkaufspreis je Preiseinheit PriceMarkup salesMarkup; //Preis sonst. Zuschläge PriceUnit priceUnit; // Preiseinheit SalesLineDisc salesLineDisc; // Rabatt SalesLinePercent salesLinePercent; DiscPct percent1; DiscPct percent2; PriceDiscTable actualPrice; // Gefundener Datensatz der Handelsvereinbarung (Verkaufspreis) PriceDiscTable actualDisc; // Gefundener Datensatz der Handelsvereinbarung (Rabatte) AmountCur lineAmount; // Nettobetrag ; [salesPrice, salesMarkup, priceUnit, salesLineDisc, salesLinePercent, percent1, percent2, actualPrice, actualDisc] = PriceDisc::actualSalesPriceDisc(custTable, inventTable, qty); lineAmount = PriceDisc::price2Amount(salesPrice, priceUnit, salesLineDisc, qty, qty, salesMarkup, salesLinePercent, custTable.Currency, 0);
Die neue oder zweite Auflage von "Inside Mircosoft Dynamics AX" ist vor wenigen Tage erschienen.
Inside Mircosoft Dynamics AX 2009
Wie auch schon die erste Auflage des Buches, welche auf der Version 4.0 von Microsoft Dynamics AX basierte, ist diese Buch in erster Linie für Entwickler gedacht.
Die aktuelle Auflage umfasst gut 100 Seiten mehr als die erste Auflage und ist leider auch im Preis etwas teurer.
Weitere Informationen über den Inhalt können z.B. auf den Seiten von Amazon entnommen werden.
Es ist zu hoffen, dass sich diese Auflage auf gleichem Level wie die erste Auflage bewegt und somit zu einem "Must-Have" oder "Must-Read" für AX Entwickler wird.
Heute bin ich, bei einem meiner "Streifzüge" durch das Internet, auf eine neue Seite zum Thema Dynamics gestoßen.
Diese neue Seite heißt DynamicsWorld.
Als einer der ersten Einträge, wurde dort eine Liste der 100 einflussreichsten Menschen, bezogen auf Microsoft Dynamics, veröffentlicht.
Wie diese Liste erstellt wurde, bzw. welche Kriterien zur Erstellung dieser Liste verwendet/berücksichtigt wurde ist ebenfalls beschrieben.
Nach einem Blick auf diese Liste war ich sehr erstaunt.
Unter Position 62 ist folgendes zu lesen (Orginalauszug):
Axel Kühn
One of the German Dynamics AX developers who has resisted the temptation to fall in to the arms of SAP. He has been a regular contributor to the GLS layer for Germany and is involved in some of the largest AX implementations, his blog blog.ak-home.net regularly has a readership of over 3000 AX developers and consultants.
Der orginale Eintrag ist hier zu finden.
Ich freue mich zu lesen, dass meine Bemühungen und Beiträge zu der Microsoft Dynamics Community so hoch bewertet werden.
In dem Artikel "Anzeige von Lagerdimensionen auf Masken" wurde bereits gezeigt, was zu tun ist, um die Anzeige von Lagerdimensionen auf Masken dynamisch anpassen zu können bzw. das Standardverhalten für die Anzeige von Lagerdimensionen zu implementieren.
Manchmal soll eine ähnliche Funktionalität auch für Berichte bereit gestellt werden, um zum Beispiel vor der Berichtserstellung auswählen zu können, welche Lagerdimensionen auf dem Bericht(Report) angedruckt werden.
Auch hierfür sind im Dynamics AX Standard die entsprechenden Funktionalitäten (oder besser Klassen) bereits vorhanden, sodass diese nur verwendet werden müssen.
Als Ausgangsbasis für den Bericht dient ebenfalls die Tabelle „AKU_DemoTable“.
Der Bericht soll nun, die in dieser Tabelle gespeicherten Datensätze andrucken/ausgeben.
Wie bei Masken, muss auch für einen Bericht, die Query entsprechend um die Tabelle InventDim ergänzt werden.
Hierbei ist zu beachten, dass die Eigenschaften (Properties) „FetchMode“ auf „1:1“ und „Relations“ auf „Yes“ gesetzt werden.
Als nächstes muss nun, ebenfalls analog zu dem Vorgehen bei Masken, die Feldgruppe „InventoryDimensions“ in den Designzweig des Reports aufgenommen werden.
Beispielhaft wird diese in einem Body-Element erstellt.
Nun müssen noch einige Anpassungen an den Methoden des Berichts durchgeführt werden, damit das gewünschte Ergebnis erreicht werden kann.
Bezogen auf die Möglichkeit, die zu druckenden Lagerdimensionen bestimmen zu können, müssen die Methoden „classDeclaration“, „run“, „dialog“ und „getFromDialog“ wie folgt überschrieben werden.
Auch das Überschreiben der Methoden „pack“ und „unpack“ ist hilfreich (für die Lagerdimensionsanzeige nicht zwingend erforderlich), da über diese die Speicherung der „Nutzungsdaten“ realisiert wird.
public class ReportRun extends ObjectRun
{
InventDimParm inventDimParm;
DialogRunbase dialog;
DialogGroup dialogInventoryDimensions;
#define.CurrentVersion(1)
#localmacro.CurrentList
inventDimParm
#endmacro
}
void updateDesign()
{
;
InventDimCtrl::updateReportVisible(element, inventDimParm);
}
public void run()
{
;
this.updateDesign();
super();
}
public Object dialog(Object _dialog)
{
;
dialog = _dialog;
dialogInventoryDimensions = inventDimParm.addFieldsToDialog(dialog,"@SYS53654",true, false, "@SYS102592");
return dialog;
}
public boolean getFromDialog()
{
;
inventDimParm.getFromDialog(dialog, dialogInventoryDimensions);
return true;
}
public container pack()
{
return [#CurrentVersion, #CurrentList];
}
public boolean unpack(container packedClass)
{
Version version = RunBase::getVersion(packedClass);
;
switch(version)
{
case #CurrentVersion:
[version,#CurrentList] = packedClass;
break;
default:
return false;
}
return true;
}
Wird nun der Bericht geöffnet, zum Beispiel über ein MenuItem, kann in einem Dialog ausgewählt werden, welche Lagerdimensionen auf dem Report angedruckt werden sollen.
Der ausgegebene Bericht(Report) sieht, unter Berücksichtigung der im Dialog gewählten Einstellungen, wie folgt aus.
Das vorgestellt Bespiel steht hier als Download bereit um die einzelnen Schritte genau ansehen/nachvollziehen zu können.
AKU_Demo_InventDimRep.rar (1,99 KB)
Heute erhielt ich von Microsoft die erfreuliche Nachricht, dass ich ein weiteres Jahr den Titel Microsoft Most Valuable Professional tragen darf.
Ich fühle mich geehrt, diese Auszeichnung nun schon zum 2ten mal (in Folge) erhalten zu haben.
Ich möchte mich an dieser Stelle bei allen bedanken, die mich in den letzten Monaten immer wieder tatkräftig unterstützt haben.
Im Standard von Microsoft Dynamics AX besteht auf jeder Maske, auf der Artikel und deren Lagerdimensionen angezeigt werden, die Möglichkeit, die Lagerdimensionen, bzw. die angezeigten Felder der Lagerdimensionen, über die Funktion "Lager-Dimensionenanzeige" entsprechend zu steuern.
Die einzelnen Elemente (Felder) der Lagerdimension können über diese Funktion ein- bzw. ausgebledet werden.
Weiterhin ist es auch möglich, durch Parametrisierung zu bestimmen, ob ein Feld einer Lagerdimension eingeben werden muss (Mussfeld) oder ob überhaupt eine Eingabe möglich ist.
Ein gutes Beispiel hierfür ist die Maske "Aufträge".
Wie ist es nun, wenn eine neue Maske erstellt werden soll, welche Artikelinformation und Lagerdimensionen anzeigen soll?
Wie genau muss vorgegangen werden, um die bereits an vielen Stellen im Standard verwendete Funktionalität auch für die selbst erstellte Maske bereitzustellen?
Gehen wir einmal davon aus, es wurde eine neue Tabelle erstellt, welche die Artikelnummer (ItemId) und die Lagerdimensionsnummer (InventDimId) speichert.
Für diese Tabelle soll eine Maske erstellt werden, úm dem Benutzer die Möglichkeit zu geben, Datensätze zu erfassen, zu ändern oder einfach nur anzuzeigen.
Dies könnte z.B. so aussehen:
Um nun die Funktion der Lagerdimensionensteuerung einzubauen muss zuerst die Tabelle InventDim als DataSource der Maske hinzugefügt werden.
Anschließend müssen die Eigenschaften (Properties) der DataSource noch auf folgende Werte geändert werden.
|
Name |
InventDim |
|
JoinSource |
Haupt-Datenquelle (hier: AKUDemoTable) |
|
LinkType |
InnerJoin |
|
DelayActive |
No |
|
InsertAtEnd |
No |
|
InsertIfEmpty |
No |
Nun muss eine neue ButtonGroup (Name: "Inventory") im Designzweig der Maske erstellt werden. Diese sollte das LAbel "Lager" zugewiesen werden.
Nun noch das MenuItem "InventDimParmFixed" in diese ButtonGroup ziehen (z.B. per drag & drop aus dem AOT) und dem so erstellten MenuItemButton folgende Eigenschaften zuweisen.
|
Name |
InventDimParmFixed |
|
MenuItemName |
InventDimParmFixed |
|
DataSource |
Haupt-Datenquelle (hier: AKUDemoTable) |
Über das MenuItem (oder genauer über den erstellten MenuItemButton) wird nun wie im Standard, die Maske "Lagerdimensionen" zu öffnen.
Allerdings öffnet sich die Maske „Lagerdimensionen“ noch nicht wie gewünscht über den MenuItemButton. Hierfür sind noch weitere Anpassungen notwendig.
Damit sich die Maske „Lagerdimensionen“ wie gewünscht öffnet muss die neue Maske die Methode „inventDimSetupObject“ implementieren welche eine Instanz von „InventDimCtrl_Frm“ zurück gibt.
Die Klasse „InventDimCtrl_Frm“, bzw. eine der von ihr abgeleiteten Klassen, steuert z.B. welche Lagerdimensionen für den aktuellen Datensatz zulässig sind oder welche Dimensionen für den aktuellen Datensatz angegeben werden müssen, damit dieser gespeichert werden kann.
Da über die Parametrisierung der Lagersteuerungsgruppen und der Modulparameter hierfür durchaus unterschiedliche Einstellungen gewählt werden können, sind in Dynamics AX etliche Ableitungen dieser Klasse vorhanden (jede wird für eine oder mehrere andere Masken verwendet).
Je nachdem, was für eine Funktionalität bzw. was für ein Business-Prozess erstellt werden soll, kann entweder eine der bereits im Standard vorhandenen Klassen verwendet werden oder es muss eine neue Klasse geschrieben werden, um die benötigte Funktionalität zu liefern (z.B. welche Dimensionen immer angezeigt werden müssen).
Das Erstellen einer neuen Klasse, welche von „InventDimCtrl_Frm“ abgeleitet ist, ist recht einfach.
Es sollte immer die Methode „new“ überschrieben werden und mindestens die statischen Methoden „construct“ und „newFromForm“ erstellt werden.
class AKUInventDimCtrl_Frm_Demo extends InventDimCtrl_Frm
{
}
protected void new()
{
super();
}
public static AKUInventDimCtrl_Frm_Demo construct()
{
return new AKUInventDimCtrl_Frm_Demo();
}
static AKUInventDimCtrl_Frm_Demo newFromForm(FormRun _formRun)
{
AKUInventDimCtrl_Frm_Demo inventDimCtrl = AKUInventDimCtrl_Frm_Demo::construct();
InventDimAxFormAdapter adapter = InventDimAxFormAdapter::newFromForm(_formRun);
;
inventDimCtrl.parmCallingElement(adapter);
inventDimCtrl.init();
return inventDimCtrl;
}
Weiterhin können noch andere Methoden überschrieben werden, um z.B. zu steuern, welche Felder der Tabelle „InventDim“ beim Aufruf der Maske angezeigt werden sollen.
Weitere Informationen hierzu sind im Microsoft Dynamics AX Developer Center zu finden: http://msdn.microsoft.com/en-us/library/cc618009.aspx
NoYes mustShowGridField(fieldId _dimFieldId)
{
NoYes ret;
ret = super(_dimFieldId);
//always show InventLocationId in Grid
if(_dimfieldId == fieldnum(InventDim, InventLocationId))
{
ret = NoYes::Yes;
}
return ret;
}
Wie zuvor beschrieben muss nun die Methode „inventDimSetupObject“ auf der Maske implementiert werden. Das diese eine Instanz von „InventDimCtrl_Frm“ zurück geben muss, ist diese ebenfalls zu erzeugen. Als erstes muss eine Objektvariable für das „InventDimCtrl_Frm“ Objekt erstellt werden.
public class FormRun extends ObjectRun
{
InventDimCtrl_Frm inventDimFormSetup;
}
Anschließend kann die Methode „inventDimSetupObject“ erstellt werden.
Object inventDimSetupObject()
{
return inventDimFormSetup;
}
Da die Objektvariable durch diesen Quelltext noch nicht initialisiert wird, muss noch entsprechender Code zur Initialisierung geschrieben werden.
void updateDesign(InventDimFormDesignUpdate mode)
{
inventDimParm inventDimParmShow;
inventDimParm inventDimParmEnabled;
;
switch (mode)
{
case InventDimFormDesignUpdate::Init :
if (!inventDimFormSetup)
{
inventDimFormSetup = AKUInventDimCtrl_Frm_Demo::newFromForm(element);
}
inventDimFormSetup.parmSkipOnHandLookUp(true);
case InventDimFormDesignUpdate::Active :
inventDimFormSetup.formActiveSetup(
inventTable::find(AKUDemoTable.ItemId).dimGroupId);
inventDimFormSetup.formSetControls(true);
break;
case InventDimFormDesignUpdate::FieldChange :
inventDimFormSetup.formActiveSetup(
inventTable::find(AKUDemoTable.ItemId).dimGroupId);
inventDim.clearNotSelectedDim(inventDimFormSetup.parmDimParmEnabled());
inventDimFormSetup.formSetControls(true);
break;
default :
throw error(strfmt("@SYS54195",funcname()));
}
}
public void init()
{
;
super();
element.updateDesign(InventDimFormDesignUpdate::Init);
}
Da die Logik, welche durch die Methode „updateDesign“ bereit gestellt wird, mehrfach benötigt wird, erfolgt die Initialisierung des „InventDimCtrl_Frm“ Objekts nicht direkt in der „init“ Methode.
Damit die in der Maske erstellten Datensätze auch richtig gespeichert werden können, müssen nun noch einige weitere Anpassungen an den Methoden der Datenquellen vorgenommen werden.
Datasource „AKUDemoTable“ (Hauptdatenquelle):
Hier sind die Methoden „write“, „validateWrite“ und „active“ zu überschreiben.
public void write()
{
;
ttsbegin;
AKUDemoTable.inventDimId = InventDim::findOrCreate(InventDim).inventDimId;
super();
if(AKUDemoTable.inventDimId != InventDim.inventDimId)
{
InventDim.data(InventDim::find(AKUDemoTable.inventDimId));
InventDim_ds.setCurrent();
}
ttscommit;
}
public boolean validateWrite()
{
boolean ret;
;
AKUDemoTable.InventDimId = inventDim::findOrCreate(InventDim).inventDimId;
ret = super();
return ret;
}
int active()
{
int ret;
;
ret = super();
element.updateDesign(InventDimFormDesignUpdate::Active);
inventDim_DS.active();
return ret;
}
Datasource „InventDim“:
Hier müssen die Methoden „initValue“ und „write“ überschrieben werden.
public void initValue()
{
;
InventDim.data(InventDim::find(AKUDemoTable.inventDimId));
super();
}
public void write()
{
//super();
}
Hierbei muss unbedingt beachtet werden, dass der „super“ Aufruf in der „write“ Methode der Datasource „InventDim“ auskommentiert wird, um das Speichern von falschen InventDim Datensätzen zu verhindern.
Als letzte Methode sollte nun noch die Methode „modified“ des DataSource-Field „ItemId“ der Datasource „AKUDemoTable“ überschrieben werden, damit auf eine Änderung der Artikelnummer reagiert werden kann (z.B. Artikelabhängige Anzeige der Lagerdimensionen).
public void modified()
{
;
super();
element.updateDesign(InventDimFormDesignUpdate::FieldChange);
}
Somit sind alle benötigten Quelltextanpassungen durchgeführt, sodass nur noch die Feldgruppe „InventoryDimensions“ der DataSource „InventDim“ mit in das Grid gezogen werden muss um die Lagerdimensionen auf der Maske anzuzeigen. Optional kann diese auch in die TabPage „Dimensions“ gezogen werden um ein standardkonformes Aussehen der Maske zu erhalten.
Das vorgestellt Bespiel steht hier als Download bereit um die einzelnen Schritte genau ansehen/nachvollziehen zu können.
AKU_Demo_InventDimFrm.rar (2,71 KB)
Leider scheint es ein Problem mit duplizierten Tabellen in Dynamics AX 2009 zu geben.
Unter gewissen "Umständen" ist es möglich, Quelltext der in einem andern Layer (z.B. CUS oder BUS) geschrieben wurde, in den SYS Layer zu "verschieben".
Dieser Verhalten ist sehr unschön, da viele Entwickler, z.B. für Testzwecke, mal ein Objekt duplizieren, neuen Quelltext testen und anschließen diesen auf das orginale Objekt übernehmen oder verschieben. Leider taucht genau an dieser Stelle das Problem auf (es kann sein, dass dieses "Verschieben" den Quelltext in den SYS Layer schreibt).
Das genaue Verhalten ist in einem Video von "elranu" auf YouTube beschrieben (Link zum Video):
In den Newsgroups ist auch ein entsprechender Thread zu finden: Ax 2009 bug in Sys Layer
Wie in einem Artikel auf der Microsoft Dynamics AX Webseite zu lesen ist wird der "alte" COM Business Connector nicht mehr in zukünftigen Versionen von Dynamics AX enthalten sein.
The COM Business Connector will be discontinued in future releases of Microsoft Dynamics AX
Bereits in der Version 2009 von Microsoft Dynamics AX wird der COM Business Connector vom "normalen" Setup nicht mehr angeboten.
Dieser muss manuell, wie im Microsoft Dynamics AX Developer Center beschrieben, nachinstalliert werden.
How to: Install COM Business Connector using Command-line Options
Somit ist es an der Zeit, bestehende Lösungen welche den COM Business Connector verwenden, auf den neueren .NET Business Connector zu portieren, um diese Lösungen auch in zukünftigen Versionen verwenden zu können.
Alle benötigten Informationen über die Verwendung des .NET Business Connectors können in der Library des Microsoft Dynamics AX Developer Centers gefunden werden
.NET Business Connector Overview
Oft ist in Newsgroups und Foren die Frage zu lesen, wie .NET (CLR) Arrays in X++ verwendet, bzw. wie diese deklariert werden können.
Im Großen und Ganzen unterscheidet sich die Syntax für die Verwendung eines .NET Array kaum von der eines reinen X++ Array.
.NET Arrays können in X++ sogar auf zwei verschiedene Arten deklariert werden.
Variante 1:
Die Deklaration eines .NET Arrays erfolgt analog zu der Deklaration eines "reinen" X++ Arrays:
System.Object[] arrayOfObjects;
System.Int32[] arrayOfIntegers;
Die Syntax für die Instanzierung des .NET Array weicht allerdings leicht von der "normalen" X++ Syntax ab:
arrayOfObjects = new System.Object[10]();
arrayOfIntegers = new System.Int32[3]();
Wichtig ist hierbei, dass immer "()" verwendet wird.
Um die Werte eines .NET Arrays zu setzen wird die Methode "SetValue()" verwendet:
arrayOfObjects.SetValue(myObject, 0);
arrayOfIntegers.SetValue(300, 1);
Um Werte aus einem Array abzufragen kann die Methode "GetValue" verwendet werden:
arrayOfObjects.GetValue(0);
arrayOfIntegers.GetValue(1);
Eine weitere sehr nützliche Methode ist die Methode "get_Length()". Diese liefert die Anzahl der Array-Elemente zurück.
Variante 2:
Alternativ zur ersten Variante besteht noch die Möglichkeit, ein .NET Array über die Klasse System.Array zu erzeugen.
Leider stößt man bei diesem Weg immer mal wieder auf kleinere Probleme, weswegen die erste Variante für die Verwendung von .NET Array bevorzugt werden sollte.
Eine etwas ausführlichere Beschreibung der Verwendung von .NET Array in X++ bzw. deren besonderheiten und Abweichungen zur "normalen" X++ Syntax kann im Microsoft Dynamics AX Developer Center gefunden werden.
How to: Use X++ Syntax for CLR Arrays
Wer schon mit dem AIF in der Version 4.0 von Microsoft Dynamics AX gearbeitet hat wird sich daran erinnern, dass ein Debuggen des Quellcodes, welcher durch das AIF ausgeführt wird, nur möglich ist, wenn hierfür eine kleine Codeanpassung in den Klassen "AifInboundProcessingService" und "AifOutboundProcessingService" vorgenommen wird.
Das genaue Vorgehen für die Version 4.0 von Dynamics AX ist in diesem Artikel beschrieben.
Für Dynamics AX 2009 kann diese Quellcodeänderung allerdings nicht so ohne weiteres angewendet werden, da für Dynamics AX 2009 einige Features ergänzt wurden (z.B. paralelle Verarbeitung von AIF Nachrichten) und somit der Quellcode der beiden Klassen einige Abweichungen zu dem der Version 4.0 hat.
Debuggen von ausgehenden Nachrichten
Um das Debuggen von ausgehenden Nachrichten zu ermöglichen, muss die Methode "runAsWrapper" der Klasse "AifOutboundProcessingService" angepasst werden.
Der Aufruf von "runAS" (Zeile 22) muss durch "AifOutboundProcessingService::processAsUser(messageIdContainer)" ersetzt werden.
...
try
{
// runAs currentUser and process all messages in the container.
new RunAsPermission(runAsUserId).assert();
// AKU, Enable Debuging for outbound messages - START -->
// Do not use in production system!!!
// BP deviation documented
//runas(runAsUserId,
// classnum(AifOutboundProcessingService),
// staticmethodstr(AifOutboundProcessingService, processAsUser),
// messageIdContainer,
// runAsCompany);
AifOutboundProcessingService::processAsUser(messageIdContainer);
// AKU, Enable Debuging for ourbound message - END -->
// Revert the permission
CodeAccessPermission::revertAssert();
}
...
Debuggen von eingehenden Nachrichten
Um das Debuggen von eingehenden Nachrichten zu ermöglichen, muss die Methode "runAsWrapper" der Klasse "AifInboundProcessingService" angepasst werden.
Der Aufruf von "runAS" (Teile 24) muss durch "AifInboundProcessingService::processAsUser(messageIdContainer)" ersetzt werden.
...
try
{
// Convert to Axapta UserId
axaptaUserId = AifEndpointUser::getAxaptaUser(runAsUserId).Id;
new RunAsPermission(axaptaUserId).assert();
// AKU, Enable Debuging - START -->
// Do not use in production system!!!
// BP deviation documented
//runas(axaptaUserId,
// classnum(AifInboundProcessingService),
// staticmethodstr(AifInboundProcessingService, processAsUser),
// messageIdContainer);
AifInboundProcessingService::processAsUser(messageIdContainer);
// AKU, Enable Debuging - END -->
CodeAccessPermission::revertAssert();
}
...
Für beide Quellcodeänderung sollte noch erwähnt werden, dass diese in einem Produktivsystem nicht durchgeführt werden sollten, da dies Auswirkungen auf die Verarbeitung der Stapelprozesse des AIF's haben könnte.
Das Application Integration Framework von Dynamics AX basiert auf Dokumenten (Axd<Document> Klassen).
Eigene Dokumente lassen sich reicht einfach per Hand oder mit Hilfe des Dokumenten-Wizards erstellen.
In der Version 2009 von Dynamics AX erstellt dieser Wizard auch gleichzeitig den benötigenten Service (WCF-Webservice) und andere benötigte Elemente wie (Serviceklassen und Macros).
Welche Schritte hierfür benötigt werden ist zum Beispiel im Microsoft Dynamics AX Developer Center beschrieben.
Ein kleines Problem entsteht, wenn das neue Dokument, genauer gesagt die Elemente oder Objekte des Dokuments, in einem Layer (zum Beispiel CUS-Layer) entwickelt wird und später, aus welchen Gründen auch immer, alle Objekte des Dokuments (Query, Ax<Table> Class, Axd<Document> Class) in einen anderen Layer (zum Beispiel VAR-Layer) verschoben werden.
Nach der "Verschiebung" des neuen Dokuments in einen anderen Entwicklungslayer werden durch die AIF-Konfigurationsmasken (siehe Maske Dienstleistungen) allerdings keine Operationen (Insert, Update, Delete, FindKey, etc.) mehr angezeigt.
Auch an anderen Stellen, wie zum Beispiel der Endpunktkonfiguration, sind die entsprechenden Operationen nicht mehr auswählbar oder vorhanden.
Der Grund hierfür liegt in der ClassId der Serviceklasse des neuen Dokuments. Dieser, wie auch jedem anderen Objekt, wird beim Import in einen anderen Layer eine neue ID zugewiesen, wenn nicht explizit angegeben wurde, dass der Export und Import mit ID's erfolgen soll. So kann es sein, dass die Klasse mit der ID 40001 nach dem Import in einen anderen Layer die ID 300001 zugeordnet ist.
Da wärend der Konfiguration des AIF's der AOT nach Dokumenten/Services durchsucht wird und für jedes Dokument bzw. jeden Service ein Datensatz in der Tabelle "AifService" sowie ein bis mehrere Datensätze in der Tabelle "AifAction" erzeugt wird, welche alle eine Referenz auf die ClassId der Serviceklasse enthalten, kommt es jetzt zu dem genannten Problem.
Der Id 40001 ist nun keine Klasse oder noch schlimmer eine andere Klasse zugewiesen. Auch eine "Aktualisierung" dieser Datensätze über die Aktualisierungsfunktion, welche auf der Maske Dienstleistungen bereit gestellt wird, führt nicht zum gewünschten Erfolg.
Genau in dieser Funktion scheint sich ein kleiner Fehler eingeschlichen zu haben. Dort wird zwar eine Aktulisierung der ClassId für die Datensätze der Tabelle "AifService", aber nicht für die Datensätze der Tabelle "AifAction", durchgeführt.
Um diese Verhalten zu reproduzieren, muss folgendes gemacht werden:
- Erstellen eines neuen AIF Dokuments bzw. AIF Services.
- Über die Maske Dienstleistungen, zu finden unter "Grundeinstellungen -> Einstellungen -> Application Integration Framework -> Dienstleistungen", Funktion "Aktualisieren" das neue Dokument / den neuen Service "aktivieren".
- Über den Button "Servicearbeitsgänge" können nun alle Operationen welche durch das Dokument / den Service bereit gestellt werden eingesehen werden.
- Verschieben aller Elemente des Dokuments / des Services in einen anderen Layer.
- Schritt 2 erneut druchführen.
- Über den Button "Servicearbeitsgänge" werden keine Operation mehr angezeigt.
Um dieses Problem zu lösen, gibt 2 Möglichkeiten.
Entweder manuelles Löschen alle zu diesem Dokument/Service gehörigen Datensätze der Tabelle "AifAction" oder aber man ergänzt die Methode "registerOperations" der Klasse "AifServiceGenerationManager" um ein wenig X++ Code (bei Zeile 43) welcher nicht nur den Namen der Operation aktualisiert sondern auch die ClassId.
Da dieser Code sehr einfach ist verzichte ich an dieser Stelle auf ein Beispiel.
Leider tritt dieses Problem auch mit Dynamics AX 2009 Service Pack 1 auf.
In Microsoft Dynamics AX werden alle Informationsmeldungen, Warnungen und Fehlermeldungen in einem Fenster, dem so genannten Infolog, ausgegeben.
Wie Informationen, Warnungen oder Fehlermeldungen erzeugt werden können, ist an vielen Stellen bereits beschrieben.
Ein wie ich finde sehr guter Artikel über dieses Thema ist dieser: The user friendly Infolog.
An dieser Stelle soll aber kurz beschrieben werden, wie die Meldungen des Infologs ausgewertet werden können, um zum Beispiel zu ermitteln, ob das Infolog eine Fehlermeldung oder auch eine Warnung enthält.
Zuerst stellt sich die Frage, warum benötigt man überhaupt diese Art von Information da in Dynamics AX die Möglichkeit besteht, verschiedenste Operationen innerhalb einer Transaktion zu Kapsel und diese bei Auftreten eines Fehlers oder Erzeugung einer Fehlermeldung (Stichwort "throw error") automatisch rückgängig zu machen.
Diese Frage soll anhand eines Beispiels beantwortet werden.
Angenommen wir möchten eine Anpassung in Dynamics AX schreiben, welche es ermöglicht, Änderungen an Stücklisten und Arbeitsplänen von Produktionsaufträgen zu automatisieren und alle getätigten Änderungen in einer Transaktion zu kapseln. Anschließend soll noch der Status der Produktions aktualisiert werden. Ebenfalls innerhalb der Transaktion.
Zum Beispiel soll der Produktionsauftrag gestartet werden.
Hierfür ist es notwendig verschiedene Standardfunktionen von Dynamics AX zu verwenden, die bereits eine Fehlerbehandlung implementiert haben und somit keine Fehler mehr "melden", welche den Abbruch einer Transaktion zu Folge haben könnten.
Somit wird zwar gewährleistet, dass alle "Unterfunktionen" in sich richtig auf Fehler richtig reagieren, aber dennoch könnte eine Dateninkonsistenz entstehen, da nicht alle Operationen rückgängig gemacht werden. Es könnte Beispielhaft sein, dass die Anlage von neuen Stücklistenpositionen und/oder Arbeitsgangpositionen funktioniert, die spätere Statusaktualisierung des Produktionsauftrags aber nicht. Die erstellten Stücklistenpositionen und/oder Arbeitsgangpositionen würden im System gespeichert (bleiben).
Abhilfe für dieses Problem kann duch die Auswertung des Infologs und manuellen Aufrufs von "ttsabort" geschaffen werden.
Mit dem "SysInfologEnumerator" können alle Meldungen, welche in das Infolog geschrieben wurden, durchlaufen werden.
Über die Methode "currentException" kann anschließend ausgewertet werden, um was für eine Meldung (Information, Warnung, Fehler) es sich handelt.
Hier ein kurzes Beispiel, wie dies aussehen könnte:
boolean hasError()
{
SysInfologEnumerator enum;
SysInfoAction action;
boolean hasError = false;
;
//Analyse the infolog to see if there are any warnings/errors
enum = SysInfologEnumerator::newData(infolog.infologData());
while (enum.moveNext())
{
switch (enum.currentException())
{
case Exception::Error:
case Exception::Warning:
hasError = true;
break;
}
infolog.add(enum.currentException(), enum.currentMessage(), enum.currentHelpUrl());
}
return hasError;
}
Es muss allerdings beachtet werden, dass alle Meldungen des Infologs, durch den Aufruf von "SysInfologEnumerator::newData(...)", gelöscht werden.
Sollen diesese Meldungen nach der "Auswertung" dennoch dem Benutzer angezeigt werden, müssen diese wieder manuell in das Infolog geschrieben werden (über "infolog.add(..)").
Im Standard von Microsoft Dynamics AX 2009 werden verschiedenste Business Intelligence Funktionen mitgeliefert.
Die hierfür benötigen Cubes und Dimensionen erstellt Dynamics AX 2009 unter Verwendung der Analysis-Extension direkt in den Analysis Services des SQL Servers.
Dies ist schon einmal sehr schön, da die meiste Arbeit durch die Installationsroutinen abgenommen wird.
Muss oder möchte man allerdings die mitgelieferten Cubes oder Dimensionen an die eigenen Gegebenheiten anpassen, muss zuerst ein BI-Projekt für Visual Studio erzeugt werden, da die Bearbeitung in Visual Studio erfolgt (über die Funktion „BI-Projekt generieren“).
Es können einige „allgemeine“ Einstellungen für die Erstellung eines BI-Projektes über die Funktion „Generierungsoptionen für BI-Projekt“ getätigt werden.
Beispielhaft sei hier die Einstellung der Zeitdimensionen genannt.
Allerdings kann es sein, dass man anstatt der erwartet Maske eine Fehlermeldung ausgegeben bekommt.
Dies kann besonders bei Verwendung, der für Dynamics AX 2009 bereit gestellten, Demo Daten der Fall sein.
Leider ist diese Fehlermeldung nicht sehr Aussagekräftig.
Hier hilft ein Blick in das Ereignisprotokoll des Dynamics AX Object Servers.
Dies lässt zumindest schon einmal den „groben“ Grund erkennen, was für ein Fehler verursacht wurde bzw. wo der Fehler liegen könnte.
Nach einem Blick in die Tabellendefinition und den Tabellebrowser der angegebenen Tabelle „BIUDMROLES“ wird man feststellen, dass es die angegeben Spalte wirklich nicht gibt. Es gibt aber einen Datensatz mit entsprechender UserGroupId (UserGroupId = PRComplete). Verwendet man nun die Funktion „Gehe zu Haupttabelle“, wird man feststellen, dass es diese Benutzergruppe nicht im System gibt.
Somit ist die Lösung recht einfach.
Nachdem der Fehlerhafte Datensatz gelöscht wurde, kann die Maske „Generierungsoptionen für BI-Projekt“ ohne Probleme geöffnet werden.
Wie bestimmt man ein Alias für ein Tabellenfeld in Microsoft Dynamics AX um über mehr als ein Feld die Auswahl des Datensatzes zu bestimmen?
In den Auftragspositionen kann man anstelle einer Artikelnummer auch den Suchbegriff aus dem Artikelstamm eingeben um den gewünschte Artikel auszuwählen.
Beispiel:
Artikelnummer: 12345
Suchbegriff: MeinArtikel
Da, sofern man keine sprechenden Artikelnummern verwendet, ein Suchbegriff oft einprägsamer ist als eine Artikelnummer hat man Systemweit die Möglichkeit anstelle der Artikelnummer „12345“ den Suchbegriff „MeinArtikel“ einzugeben.
Diese Funktion kann man ganz einfach auch selbst erstellen. Hierzu wird auf Tabellenfeldebene in den Eigenschaften des Feldes Suchbegriff, die Eigenschaft AliasFor auf Artikelnummer (ItemId) gesetzt.
Sobald man nun „MeinArtikel“ im Feld Artikelnummer eingibt, wird automatisch die Artikelnummer eingefügt.
Dieses Verhalten ist nun Systemweit anwendbar. Überall wo ein Artikel über die Artikelnummer ausgewählt werden kann (Bspw. Aufträge, Bestellungen) kann nun in der manuellen Eingabe der Suchbegriff verwendet werden. Nach der Eingabe des Suchbegriffs wird dieser durch die Artikelnummer ersetzt (sofern vorhanden).
Microsoft Dynamics AX 2009 bietet die Möglichkeit, den Verlauf eines Dokuments, welches über das AIF exportiert oder importiert wurde zu betrachten.
Dies war auch schon mit Microsoft Dynamics AX 4.0 möglich.
Über die Maske "Dokumentverlauf" können alle Dokumente/Nachrichten eingesehen werden, welche über das AIF verarbeitet wurden.
Über den Button "Korrelation" ist es sogar möglich, die von der Verarbeitung (schreiben, ändern, lesen, etc.) betroffenen Datensätze anzuzeigen.
So ist es zumindest in der Theorie.
In der Praxis sieht es leider etwas anders aus. Nach einem Klick auf den Button "Korrelation" öffnet sich leider nicht wie erwartet die Maske "Dokumentkorrelierung".
Stattdessen wird der Debugger (wenn installiert) geöffnet und die Fehlermeldung ausgegeben, dass ein Objekt nicht über die Methode "extendedTypeId" verfügt.
So wie es scheint, hat sich in den Quellcode ein kleiner Fehler eingeschlichen, welcher dazu führt, dass die Maske "Dokumentkorrelierung" niemals geöffnet werden kann.
Nach einem Vergleich der Funktionalitäten zwischen Dynamics AX 4.0 und Dynamics AX 2009 kann dieses Verhalten (der Fehler) aber wie folgt beschrieben behoben werden.
- AOT öffnen und zu der Tabelle "AifCorrelation" navigieren.
- Den Quelltext der Methode "displayEntityKey" anzeigen lassen bzw. diese für die Bearbeitung öffnen.
- Folgende Quelltextzeile suchen:
dictField = new DictField(entityKey.parmTableId(), enumerator.currentKey());
- Dieses Zeile abändern in:
dictField = new SySDictField(entityKey.parmTableId(), enumerator.currentKey());
Nach dieser kleinen Quelltextänderung sollte alles wie erwartet funktionierten und die Maske "Dokumentkorrelierung" mit den entsprechenden Datensätzen angezeigt werden.
Im wieder taucht in den Newsgroups und einschlägigen Foren die Frage auf, ob es möglich ist, Dynamics AX 2009 unter Windows Server 2008 und/oder in Verbindung mit SQL Server 2008 zu betreiben.
Die Antwort auf diese Frage lautet eigentlich „Ja“, zugleich aber auch „Nein“.
Offiziell sind die beiden Produkte zwar noch nicht für die Verwendung mit Dynamics AX 2009 freigegeben, aber prinzipiell funktioniert Dynamics AX 2009 auch mit dieser Systemkonfiguration (Kernfunktionalität).
Allerdings muss auch erwähnt werden, dass der eine oder andere Punkt bei der Installation bzw. beim Betrieb von Dynamics AX 2009 mit Windows Server 2008 und/oder dem SQL Server 2008 für Verwirrung sorgen kann.
So wird, nach erfolgreicher Installation der Basiskomponenten von Dynamics AX 2009 und anschließendem AOS Start, eine Fehlermeldung im Ereignisprotokoll von Windows Server 2008 erzeugt, welche aussagt, dass Dynamics AX 2009 (genauer der AOS) das gewählte Betriebssystem nicht unterstützt.
Ungeachtet dieser Fehlermeldung, läuft der AOS Dienst von Dynamics AX 2009 unter Windows Server 2008 ohne weitere Probleme. Unschön ist nur, dass diese Meldung bei jedem Start des AOS erzeugt wird.
Für die Verwendung des Enterprise Portals bzw. des Rolecenters muss beachtet werden, dass wie im Installation Guide von Dynamics AX 2009 beschrieben, die Sharepoint Services 3.0 mit SP1 verwendet werden müssen, da frühere Versionen nicht richtig unter Windows Server 2008 laufen.
Ein weiterer Punkt der unbedingt beachtet werden sollte, sind die Reporting-Erweiterungen von Dynamics AX 2009.
Eine Installation der Reporting-Erweiterungen ist derzeit leider nur möglich, wenn die Reporting Services des SQL Server 2005 in der Service Pack Version 2 verwendet werden.
Sollen die Reporting Services des SQL Server 2008 verwendet werden, scheitert es schon an der Installation der Reporting-Erweiterungen von Dynamics AX 2009.
Diese lassen sich in einer solchen Systemumgebung erst gar nicht installieren. Das Setup wird durch eine entsprechende Fehlermeldung abgebrochen.
Dies hat zur Folge, dass die Reporting Services des SQL Server 2008 nicht mit Dynamics AX 2009 verwendet werden können.
Gleiches gilt für die Analysis Extensions von Dynamics AX 2009 in Kombination mit den Analysis Services des SQL Server 2008.
Diese lassen sich zwar ohne Problem installieren, aber eine Verarbeitung der Cubes ist nicht möglich, da diese auf Grund von Verarbeitungsfehlern abgebrochen wird.
Schlussendlich bedeutet dies, dass die Verwendung von Windows Server 2008 als Betriebssystem für Dynamics AX 2009 keine Probleme bereiten sollte.
Für die reinen Datenbankdienste von SQL Server 2008 trifft dies ebenfalls zu. In meinen Test konnte ich keinerlei Probleme beim Betrieb mit Dynamics AX 2009 erkennen.
Anderes gilt für die Reporting und Analysis Services von SQL Server2008. Deren Verwendung ist leider noch nicht möglich und es müssen weiterhin die Reporting und Analysis Services des SQL Server 2005 verwendet werden um alle möglichen Funktionalitäten von Dynamics AX 2009 zur Verfügung stellen zu können.
Am 9. September 2008 fand der Dynamics Technical Airlift 2008 in Fürstenfeldbruck bei München statt. Wie auch schon im letzten Jahr, richtete sich die Veranstaltung an die eher technisch ausgerichteten Personen (Consultants/Entwickler) aus der Dynamics-Gemeinde.
Ich selbst durfte in diesem Jahr als ATE (Ask the Expert) an dieser Veranstaltung teilnehmen.
Der eine oder andere wird mich in dem orangen Poloshirt gesehen haben. 
Insgesamt kann ich nur sagen, es war eine sehr gut organisierte Veranstaltung, auch wenn einige Vorträge, für den einen oder anderen, nicht die gewünschte technische Tiefe hatten.
Auch der gemeinsame Informationsaustausch und die vielen Gespräche mit Personen der Dynamics-Gemeinde haben die Veranstaltung positiv abgerundet.
Da Meinungen ja bekanntlich weit auseinander gehen, möchte ich jeden einzelnen bitten, seine Eindrücke und Meinungen zu dem Dynamics Technical Airlift 2008 zu schildern.
Wer dies nicht "öffentlich", durch die Kommentarfunktion (hier), machen möchte, kann mir auch gerne eine Email schreiben (Email me).
Ich möchte auch die jenigen bitten, die nicht an dieser Veranstalltung teilgenommen haben, mir ein kurzes "Feedback" zukommen zu lassen.
Besonders die Erwartungen an eine solche Veranstaltung und/oder die Community im Allgemeinen würden mich interessieren.
Bitte beachtet, dass alle Kommentare erst durch mich "überprüft" werden müssen, bevor sie angezeigt werden.
Alle frei erhältlichen Dokumente über Microsoft Dynamixs AX 2009 stehen jetzt über Windows Live SkyDrive für jedermann frei zur Verfügung.
Vielen Dank an Arijit Basu, der sich die Arbeit gemacht hat, diese dort zum downlaod zur Verfügung zu stelllen.
Mehr Informationen hierzu gibt es im Blog von Arijit Basu.
Hier der "direkt" Link zu den Dokumenten: AX 2009 Documents
Wie bereits im diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" beschrieben, kann es zu Fehlermeldungen beim Starten des Dynamixs AX 4.0 Client kommen.
Eine weitere Fehlermeldung, welche erzeugt werden kann ist "Incompatible ext. version".
Es ist auch möglich, dass diese sogar mehrfach ausgegeben wird.
Grund hierfür ist meist ein Problem mit der TAPI-Integartion des CRM Moduls, bzw. genauer gesagt, ein Problem mit den eingestellten Wählregeln/Standorte der Windows Telefon- und Modemoptionen.
Die Behebung des Fehlers ist eigentlich ganz einfach.
- Wenn die TAPI-Integration nicht genutzt wird, kann diese deaktiviert werden.
Wie dies genau geht kann in diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" nachgelesen werden.
- Wenn die TAPI-Integration verwendet werden soll, muss ein neuer Standort in den Windows Telefon- und Modemoptionen erstellt werden.
Das Erstellen eines neuen Standorts erfolgt über "Start -> Systemsteuerung -> Telefon- und Modemoptionen" auf dem jeweiligen Clientcomputer (pro Benutzer).
Dort sollte, wenn vorhanden, ein bestehender Standort gelöscht werden und ein neuer angelegt werden.
Wie bereits in diesem Artikel "Auswahl von mehreren Datensätzen in einem Grid-Control (MultiSelect)" beschrieben, kann für ein Grid-Control die Eigenschaft MultiSelect gesetzt werden, womit es ermöglicht wird, dass mehrere Datensätze für eine weitere Verarbeitung ausgewählt werden können.
Dies Funktioniert solange, bis <DataSource>_ds.research() aufgerufen wird. Dieser Aufruf hat zur Folge, dass die Daten der DataSource neu geladen werden und somit auch die Selektierung verworfen wird.
Ein Beispiel wie es nicht funktioniert:
void clicked()
{
CustTable custTable;
;
for (custTable = CustTable_ds.getFirst(true) ? CustTable_ds.getFirst(true) : CustTable_ds.cursor();
custTable;
custTable = CustTable_ds.getNext())
{
//do something with custTable
info(custTable.accountNum);
custTable_ds.research();
}
}
Es gilt also genau zu beachten zu welchem Zeitpunkt bzw. an welcher Stelle im Quelltext die Methode <DataSource>_ds.research() aufgerufen wird.
Weiterhin kann es zu Problemen beim MultiSelect kommen, wenn in den Methoden der DataSource ein Aufruf von <DataSource>_ds.research() erfolgt.
Normalerweise werden die DataSource-Methoden für jeden selektierten Datensatz ausgeführt. Wenn aber innerhalb einer der Methoden, wie z.B. Delete(), wird diese Methode nur für den ersten ausgewählten Datensatz ausgeführt und dann ein Research ausgeführt, was wie schon beschrieben zu einem Verwerfen der Selektierung führt.
Microsoft Dynamics AX verwendet für eindeutige Kennungswerte (Id’s) die eingebauten Nummernkreise, für welche ein Feld vom Typ „String“ benötigt wird. Dies macht auch Sinn, da Nummernkreise in Dynamics AX oft ein oder mehrere alphanumerische Zeichen enthalten. Natürlich können auch rein nummerische Nummernkreise mit diesem „Framework“ erstellt werden.
Allerdings sind die Nummernkreise im Dynamics AX Standard nicht ganz optimal bei der Verwendung von einem rein nummerischen Nummernkreisen. Dies fängt z.B. schon beim Datentyp an, der für das ID-Feld der Tabelle verwendet werden muss. Bedingt dadurch, dass ein Feld vom Typ „String“ verwendet werden muss, belegt dieses Feld unnötig viel Speicher in der Datenbank. Weiterhin gestalten sich Sortierungen, Rechenoperationen, etc. erheblich schwieriger.
Diese Probleme können umgangen werden, wenn für das ID-Feld der Datentyp „Integer“ oder „Int64“ verwendet wird. Leider kann nun nicht mehr das Nummernkreis-Framework des Dynamics AX Standards verwendet werden, da dies den Datentyp „String“ für ein ID-Feld vorschreibt.
Es muss also ein eigenes, kleines Nummernkreis-Framework oder ein eigener Nummernkreis geschrieben werden, der die Verwendung des Datentyps „Integer“ für ID-Felder ermöglicht. Dies hört sich zuerst schwierig an, da Dinge wie fortlaufende Nummernvergabe oder die Wiederverwendung von freien Nummern (Löchern im Nummernkreis) berücksichtigt werden sollten.
Es ist aber ganz und gar nicht schwierig, eine eigene Nummernkreisfunktionalität zu erstellen. Das einzige was hierfür benötigt wird ist eine entsprechen aufgebaute Select-Abfrage.
Die nächste Nummer eines Nummernkreises ist immer die zuletzt vergebenen Nummer (höchste) + 1.
Aku_TestTable t1;
;
select maxof(ID) from t1;
return t1.ID + 1;
Etwas schwieriger wird es, wenn auch die frei gewordenen Nummern des Nummernkreises wieder vergeben/verwendet werden sollen. Dann muss immer die kleinste Id aus der Tabelle gesucht werden, für die es keinen Datensatz in der Tabelle gibt. Gibt es kein "Nummernloch", muss die nächst höchste Nummer vergeben werden.
Aku_TestTable t1;
Aku_TestTable t2;
;
select minof(ID) from t1 notexists join t2 where t2.ID == (t1.ID + 1);
return t1.ID + 1;
Um diese ein wenig zu verdeutlichen, kann eine beispielhafte Implementierung eines eigenen Nummernkreises in diesem Demoprojekt "SharedProject_AKU_OwnIntNumberSeq" angesehen und runter geladen werden.
Die Benamung von Tabellenfeldern erfolgt über Labels, die in der Feldeigenschaft "Label" festgelegt werden.
Diese Benamung wird immer angezeigt, wenn das Feld in der Applikation angezeigt wird. Es gibt in den Eigenschaften der Tabellenfelder noch die Eigenschaft "GroupPrompt", die die Benamung in Masken festlegt, wenn das Feld innerhalb einer Gruppe angezeigt wird.
Die hinterlegte Benamung in der Eigenschaft GroupPrompt wird immer dann verwendet, wenn das Feld in einer Gruppe dargestellt wird. Das können Tabellenfeldgruppen oder Gruppen, die in Forms erzeugt wurden, sein.
Manchmal ist es möglich, dass beim Starten des Microsoft Dynamics AX 4.0 Clients eine oder meherer Fehlermeldungen in einem Infolog-Fenster ausgegeben werden.
Diese Fehlermeldung könnten z.B. "Corrupted ini file" sein.
Die große Frage ist nun, woher kommt diese Fehlermeldung bzw. wodurch wird diese erzeugt.
Leider ist die Fehlermeldung, welche im Ereignisprotokoll gefunden werden kann, meist auch nicht besonders hilfreich.
Sollten solche, eher unerklärlichen Fehlermeldungen beim Starten des Dynamics AX Client ausgegeben werden, lohnt sich oft ein Blick in die Systemkonfiguration, welche über Verwaltung, Einstellungen, System, Konfiguration aufgerufen werden kann.
Der Grund für diese Fehlermeldung könnte die aktivierte Telefonieintegration des CRM Moduls sein.
Wird diese deaktiviert, sollte die Fehlermeldung nicht mehr erzeugt werden.
Wenn bei der Entwicklung mit Microsoft Dynamics AX 4.0 die Quellcodeverwaltung mittels Visual SourceSafe 2005 eingeschaltet wurde, besteht die Möglichkeit einzelne Versionen eines Objekts miteinander zu vergleichen.
Hierbei kann es aber bei einer "ungünstigen" Konfiguration des lokal Repository-Verzeichnisses sein, dass bei einem Vergleich von zwei Objektversionen die Fehlermeldung "Fehler: Fortsetzen nicht möglich" ausgegeben wird.
Diese Fehlermeldung wird immer erzeugt, wenn sich das lokale Repository-Verzeichnis und das Verzeichnis, in dem die temporären Internetdateien (Temporary Internet Files) gespeichert werden, nicht auf der gleichen Partition (Datenträger) befinden.
Beispiel:
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = D:\VSSRepository\Test
-> Die Fehlermeldung wird ausgegeben.
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = C:\VSSRepository\Test
-> Die Fehlermeldung wird nicht ausgegeben und der Versionvergleich funktioniert problemlos.
Dieses Problem wird durch ein Update für Visual SourceSafe 2005 behoben. Es empfiehlt sich, bei Verwendung der Quellcodeverwaltung mit Visual SourceSafe 2005 als VC-System, dieses Update einzuspielen.
Die Eigenschaften von FormControls, wie heightMode und widthMode werden im Form Designer über Enums gesetzt. Leider hat man hier mittels X++ Probleme, denn es wird bei der Verwendung dieser Methoden nicht angegeben um welchem Enum es sich handelt. Das hat zufolge, dass man immer wieder probieren muss, um die gewünschte Eigenschaft richtig zu setzten. Desweiteren ist so auch der Quellcode schlechter lesbar. Der Aufruf sieht normal so aus:
FormControl.heightMode(1);
Besser ist es, wenn man sprechende Parameter mit dem richtigen Enum verwendet
FormControl.heightMode(FormHeight::ColumnHeight); Mögliche Optionen:
FormHeight::Auto
FormHeight::ColumnHeight Ähnlich sieht der Parameter bei widthMode aus, nur wird hier der Enum FormWidth genutzt.
FormControl.witdthMode(FormWidth::ColumnHeight); Mögliche Optionen:
FormWidth::Auto
FormWidth::ColumnHeight Wie schon bei den letzten beiden Eigenschaft kann man bei TopMode auch nur raten, was mittels X++ übergeben werden muss.
FormControl.TopMode(0); Besser ist, wenn auch hier ein sprechender Parameter mit dem richtigen Enum verwendet wird.
FormControl.TopMode(FormTop::Auto);
Mögliche Optionen:
FormTop::Auto
FormTop::ButtomEdge
FormTop::Center
FormTop::TopEdge
Bei FormGroupControls gibt es die Eigenschaft frameOptionButton, auch hier tritt dasselbe Problem auf.
FormControl.frameOptionButton(0); Der Enum lautet hier FormFrameOptionButton und ermöglicht somit die korrekte Zuweisung oder besser lesbaren Quellcode zu schreiben.
FormControl.frameOptionButton(FormFrameOptionButton::None); Mögliche Optionen:
FormFrameOptionButton::None
FormFrameOptionButton::Hide
FormFrameOptionButton::Check
FormFrameOptionButton::Radio Es kommt nicht nur bei FormControls zu dieser Art von Problemen. Bei QueryRanges gibt es die Eigenschaft Status, auch hier kann es beim Setzen zu Schwierigkeiten dieser Eigenschaft mittels X++ kommen.
QueryBuildRange.Status(0); Besser ist auch hier den sprechenden Parameter mit dem Richtigen Enum zu verwenden.
QueryBuildRange.Status(RangeStatus::Hidden); Mögliche Optionen:
RangeStatus::Hidden
RangeStatus::Locked
RangeStatus::Open Das waren erstmal die Sachen, die mir noch in Erinnerung sind. Es gibt wahrscheinlich einige andere Stellen, bei denen es Schwierigkeiten bereitet, den richtigen Parameter zu wählen. Ich habe mit den genannten Enums bisher positive Erfahrungen sammeln können, ob es aber wirklich die Richtigen sind, wird man wohl nicht in Erfahrung bringen können.
Für jede Tabelle können Systemfelder wie Erstellt von, Geändert von, Erstellungsdatum, Erstellungszeit oder Änderungsdatum von Dynamics AX aktiviert werden.
Diese Felder werden durch Dynamics AX automatisch gefüllt. Wird zum Beispiel ein neuer Datensatz erzeugt, füllt Dynamics AX die Systemfelder mit den entsprechenden Daten.
Es gibt aber Situationen wo man selber Einfuß auf die Werte dieser Felder nehmen muss. Ein Beispiel hierfür könnte eine Datenübernahme sein, bei der die Informationen über den Ersteller oder das Erstellungsdatum des Datensatzes nicht verloren gehen dürfen.
Wie dies gehen kann zeigt dieses kleine Beispiel:
YourTable table;
;
ttsbegin;
//can only be called on server tier. -> method must be executed on server tier.
new SkipAOSValidationPermission().assert();
table.skipAosValidation(true);
table.YourField = "Value";
table.overwriteSystemfields(true);
//set your own values for the system fields.
table.(fieldnum(Table1, ModifiedDate)) = today() - 2;
table.(fieldnum(Table1, CreatedDate)) = today() - 5;
table.(fieldnum(Table1, CreatedBy)) = "TEST";
table.insert();
ttscommit;
table.skipAosValidation(false);
Allerdings können die Systemfelder nur beim Erstellen eines neuen Datensatzes "von Hand" festgelegt werden.
Wie das Ändern von Werten der Systemfelder bei bereits bestehenden Datensätzen geht demonstriert die Klasse "BatchRun", Methode "runJob" und "finishJob".
Kurz gesagt wird genau genommen der Datensatz nicht geändert, sondern es werden nur die Daten des bestehenden Datensatzes in den neuen Datensatz kopiert (mit newBuffer = oldBuffer.data()) und dann wie bereits beschrieben die Systemfelder mit eigenen Werten befüllt. Dann wird der bestehnde Datensatz gelöscht und der neue Datensatz in die Datenbank geschrieben.
|