Ein großer Vorteil des Application Integration Frameworks (AIF) gegenüber “selbst geschriebene” Schnittstellen ist es, dass man sich über Dinge wie Datentyp-Mapping keine Gedanken machen muss.
Das Application Integration Framework verfügt über die entsprechende Logik, um alle Dynamic AX Datentypen automatisch in den jeweils gültigen XSD-Datentyp zu “mappen” (oder umgekehrt).
Zeiten, in denen sich der Entwickler zum Beispiel Gedanken machen musste, wie viele Nachkommastellen eine Zahl haben darf, oder welches Zeichen als Dezimaltrennzeichen verwendet werden muss, sind somit vorbei.
Da alle Daten die aus Dynamics AX exportiert oder nach Dynamics AX importiert werden, in einem XSD-Schema konformen XML-Dokument “transportiert” werden, und das AIF entsprechendes Mapping bereits stellt, geschieht das Datentyp-Mapping automatisch.
Allerdings kann auf Seiten der Anwendung, welche über das Application Integration Framework (AIF) angebunden werden soll, ein wenig “Verwirrung” entstehen.
Durch die von Programmiersprache zu Programmiersprache durchaus unterschiedlichen Datentypen kann es vorkommen, dass Dynamics AX Datentypen nicht in dem erwarteten Datentyp der anderen Programmiersprache erscheinen.
Dies ist allerding kein “wirkliches” Problem des Application Integration Frameworks (AIF), sondern eher eine Frage, welche Datentypen eine Programmiersprache bereit stellt und wie diese in XSD-Datentypen “gemappt” werden.
Ein gutes Beispiel hierfür sind die Dynamics AX Datentypen “Date”, “Time” und “DateTime” (inklusive aller von diesen Basisdatentypen abgeleiteten EDT’s).
Ohne genauere Betrachtung liegt die Annahme nahe, dass ein DateTime Datentyp von Dynamics AX in einen DateTime Datentyp von z.B. C# “gemappt” wird.
Dies ist allerdings nicht richtig. Da nicht direkt zwischen Dynamics AX Datentyp und C# Datentyp gemappt wird, sondern immer von/zu einem XSD-Datentyp gemappt wird, wird in C# eine neue Klasse hierfür erzeugt.
Ein wenig schwieriger wird es bei den beiden Dynamics AX Datentypen “Date” und “Time”. Für diese Datentypen wird z.B. in C# kein direkt vergleichbarer Datentyp bereit gestellt.
Diese Datentypen werden jeweils als C# DateTime Datentypen gemappt.
Das Mapping der Datentypen geschieht wie folgt:
|
Dynamics AX |
XSD Schema |
.NET (C#) |
|
Date |
xs:date |
System.DateTime |
|
Time |
xs:time |
System.DateTime |
|
DateTime |
xs:dateTime |
new class
i.e. “AxdType_DateTime” |
Da die beiden Dynamics AX Datentypen “Date” und “Time” in den C# Datentyp “DateTime” gemappt werden, kann an dieser Stelle leider ein kleines Problem entstehen.
In C# ist nun leider nicht mehr zu erkennen, um was für einen Dynamics AX Datentyp es sich z.B. bei einem Feld handelt, und ob nun ein Datum oder eine Zeit in diesem enthalten ist.
Oftmals entsteht diese Problem dadurch nicht, dass der jeweilige Business-Kontext die Datentypverwendung entsprechend einschränkt und es somit teilweise egal ist ob nun in ein Dynamics AX Date oder Time gemappt wird.
Ist es aber erforderlich zu wissen, um ob ein Feld nun den Dynamics AX Datentyp Date oder Time hat, kann der generierte Code der Proxyklasse Aufschluss geben (oder das XSD-Schema).
Durch die Angabe eines Serialisierungs-Attributes wird bestimmt, welcher “Teil” des DateTime Datentyps verwendet wird.
Für ein Feld, welches in einen Dynamics AX Date Datentyp gemappt wird, wird nur der “Datumsteil” in das XML-Dokument serialisiert.
Entsprechendes geschieht für einen Dynamics AX Time Datentyp.
Mapping eines C# Datetime Datentyps in einen Dynamics AX Date Datentyp (generierter Code der Proxyklasse):
1: [System.Xml.Serialization.XmlElementAttribute(DataType="date", IsNullable=true, Order=54)]
2: public System.Nullable<System.DateTime> MyDateField { 3: get { 4: return this.myDateFieldField;
5: }
6: set { 7: this.myDateFieldField = value;
8: this.RaisePropertyChanged("MyDateField"); 9: }
10: }
Mapping eines C# Datetime Datentyps in einen Dynamics AX Time Datentyp (generierter Code der Proxyklasse):
1: [System.Xml.Serialization.XmlElementAttribute(DataType="time", IsNullable=true, Order=56)]
2: public System.Nullable<System.DateTime> MyTimeField { 3: get { 4: return this.myTimeFieldField;
5: }
6: set { 7: this.myTimeFieldField = value;
8: this.RaisePropertyChanged("MyTimeField"); 9: }
10: }
Wie durch den generierten Code der Proxyklasse ersichtlich wird, wird nur der jeweils benötigte “Teil” eines C# Datetime Datentyps serialisiert/deserialisiert und somit verwendet.
Für einen Dynamics AX DateTime Datentyp wird bei Erstellung des Proxys eine neue Klasse generiert. Somit kann der Dynamics AX Datentyp hierbei immer eindeutig identifiziert werden.
1: [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4016")] 2: [System.SerializableAttribute()]
3: [System.Diagnostics.DebuggerStepThroughAttribute()]
4: [System.ComponentModel.DesignerCategoryAttribute("code")] 5: [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.microsoft.com/dynamics/2008/01/documents/Customer")]
6: public partial class AxdType_DateTime : object, System.ComponentModel.INotifyPropertyChanged { 7:
8: private System.DateTime localDateTimeField;
9:
10: private bool localDateTimeFieldSpecified;
11:
12: private AxdEnum_Timezone timezoneField;
13:
14: private bool timezoneFieldSpecified;
15:
16: private System.DateTime valueField;
17:
18: [System.Xml.Serialization.XmlAttributeAttribute()]
19: public System.DateTime localDateTime ...
20:
21: [System.Xml.Serialization.XmlIgnoreAttribute()]
22: public bool localDateTimeSpecified...
23:
24: [System.Xml.Serialization.XmlAttributeAttribute()]
25: public AxdEnum_Timezone timezone...
26:
27: [System.Xml.Serialization.XmlIgnoreAttribute()]
28: public bool timezoneSpecified...
29:
30: [System.Xml.Serialization.XmlTextAttribute()]
31: public System.DateTime Value { 32:
33: public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;
34:
35: protected void RaisePropertyChanged(string propertyName)...
36: }
Dieses Verhalten ist nicht nur mit C# zu beobachten. Auch JAVA oder andere Programmiersprachen verhalten sich ähnlich und muss entsprechend berücksichtigt werden.
