Beim Entwickeln und/oder Testen von AIF-Service, welche als Webservice bereit gestellt werden, entstehen oftmals (mindestens) 2 Fragestellungen.

1. Wie kann die Nachricht betrachtet werden, welche zwischen den System über den Webservice ausgetauscht wird?
2. Wie lässt sich der Webservice-Aufruf debuggen?

Leider werden diese Fragen bei einer Suche im Internet oft mit “Geht nicht” beantwortet.
Dies ist so allerdings nicht richtig.

Es ist z.B. möglich, für alle Webserviceaufrufe eine Tracing-File zu erzeugen, welches u.A. auch die Nachricht protokolliert, die von oder zu Dynamics AX geschickt wurde.
Um das Tracing zu aktivieren müssen nur entsprechende Einstellungen in der web.config des Webservices vorgenommen werden.

Wie dies im Detail funktioniert beschreibt dieses kleine How-To des Microsoft Dynamics Developer Centers im MSDN.
http://msdn.microsoft.com/en-us/library/cc967372.aspx

Es ist ebenfalls möglich, die Webserviceaufrufe zu debuggen.

Allerdings müssten hierfür einige Schritte beachtet werden, damit das Debuggen von Webserviceaufrufen auch für X++ Code funktioniert.
Eine detaillierte Anleitung hierzu ist am Ende des Whitepapers “Tips for Creating Services in Microsoft Dynamics AX 2009” zu finden.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=90388b14-fb8c-4633-a255-28ff7146c5b2

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.

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:

1. Erstellen eines neuen AIF Dokuments bzw. AIF Services.
2. Über die Maske Dienstleistungen, zu finden unter "Grundeinstellungen -> Einstellungen -> Application Integration Framework -> Dienstleistungen", Funktion "Aktualisieren" das neue Dokument / den neuen Service "aktivieren".
3. Über den Button "Servicearbeitsgänge" können nun alle Operationen welche durch das Dokument / den Service bereit gestellt werden eingesehen werden.
4. Verschieben aller Elemente des Dokuments / des Services in einen anderen Layer.
5. Schritt 2 erneut druchführen.
6. Ü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.

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.

1. AOT öffnen und zu der Tabelle "AifCorrelation" navigieren.
2. Den Quelltext der Methode "displayEntityKey" anzeigen lassen bzw. diese für die Bearbeitung öffnen.
3. Folgende Quelltextzeile suchen:
   dictField = new DictField(entityKey.parmTableId(), enumerator.currentKey());
4. 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.