Microsoft Dynamics AX 2012 Webservice-Updates (3.2.93a)
Ich freue mich, ein umfangreiches Update unserer Unterstützung für die Webservices von Microsoft Dynamics AX ankündigen zu können. Das betrifft vor allem Microsoft Dynamics AX 2012 R1, R2 und R3 (enthält aber auch einige Änderungen für Microsoft Dynamics AX 2009).
In den letzten 6-8 Monaten haben wir intensiv an unserer Unterstützung für Microsoft Dynamics AX 2012 gearbeitet, insbesondere an unserer Unterstützung für die Microsoft Dynamics AX 2012 Webservices. Wir haben uns verpflichtet, alle Versionen von Microsoft Dynamics AX zu unterstützen, und daher ist es für uns selbstverständlich, weiter in die Verbesserung unserer Unterstützung für diese Systeme zu investieren. Das Update besteht aus einer Reihe von Änderungen, die im Laufe der Zeit eingeführt wurden, und das Ergebnis insgesamt ist: Eine Integration mit Microsoft Dynamics AX 2012 lässt sich jetzt deutlich einfacher und schneller umsetzen.
Lesen Sie weiter, um einen vollständigen Überblick über die Änderungen zu erhalten:
Unterstützung für Standarddimensionen und Dimensionsfelder (Microsoft Dynamics AX 2009 Webservices)
In Microsoft Dynamics AX 2009 müssen die Standarddimensionen als Liste von Elementen gesendet werden, wenn Sie z. B. den Customer-Webservice verwenden, um einen neuen Kunden in Microsoft Dynamics AX anzulegen. Wir haben dies allgemein unterstützt, indem eine Liste von Feldern als Array von Strings an Microsoft Dynamics AX gesendet werden kann. In MyRapidi können Sie eine Liste auf zwei Arten erstellen: entweder über einen Gather Transfer oder über die SPLIT-Funktion (was deutlich einfacher ist).
Hier ein Beispiel:
##SPLIT('AAA|BBB|CCC','|')
Diese Funktion erstellt eine Liste mit drei Elementen/Strings, die dem Dimension-Feld des Customer-Webservice von Microsoft Dynamics AX 2009 zugeordnet werden kann. AAA wird als erste Dimension gesetzt, BBB als nächste Dimension und CCC als dritte Dimension. Wenn Ihre Dimensionseinrichtung in Microsoft Dynamics AX mehr oder weniger Dimensionen vorsieht, passen Sie die Formel einfach entsprechend an. Sie können die Werte für die Dimensionen auch aus Feldern des Quelldatensatzes beziehen, indem Sie diese Felder (in doppelten Anführungszeichen) in die Formel aufnehmen.
Diese Funktion wurde in Version 3.2.91n des RapidiConnector bereitgestellt.
Unterstützung für Standarddimensionen und Dimensionsfelder (Microsoft Dynamics AX 2012 Webservices)
In Microsoft Dynamics AX 2012 ist die Dimensionsstruktur flexibler: Es gibt mehrere bereits benannte Dimensionen, und Sie können auf Wunsch auch nur einige davon setzen. Die Struktur, die der Webservice von Microsoft Dynamics AX erwartet, muss Name und Wert jeder Dimension enthalten, und Sie können eine variable Anzahl von Dimensionen setzen. Wir haben es in MyRapidi auch hier einfacher gemacht: Sie geben einfach eine Liste an. Die Liste muss eine gerade Anzahl von Elementen enthalten und sowohl den Namen als auch den Wert jeder Dimension enthalten, die Sie setzen möchten.
Hier ein Beispiel:
##SPLIT('CostCenter|OU_3567|Department|OU_2310','|')
Wenn Sie dies als Quelle verwenden und dem Feld DefaultDimension im Customer-Webservice von Microsoft Dynamics AX 2012 zuordnen, setzen Sie damit die Dimension CostCenter auf OU_3567 und die Dimension Department wird auf OU_2310 gesetzt. Im Layout sehen Sie für DimensionValueSet-Feldtypen den Typ "valueset".
Diese Funktion steht ab Version 3.2.92z des RapidiConnector zur Verfügung.
Verbesserungen bei Read Design (Microsoft Dynamics AX 2012 Webservices)
Sie können jetzt Read Design für den Standard-SalesQuotationService ausführen. Es gab ein Problem mit der Benennung des Service, aber jetzt wird er bei Read Design korrekt gelesen und funktioniert in Transfers. Hinzugefügt in Version 3.2.91r des RapidiConnector.
Wir lesen jetzt die SOAP Action und den Target Namespace aus der WSDL und verwenden diese Informationen beim Zusammenstellen der Webservice-Aufrufe. Vorher haben wir diese Informationen aus dem Service-Namen zusammengesetzt. So können wir verschiedene Webservices für Microsoft Dynamics AX unterstützen, auch selbst entwickelte Webservices, die nicht den Standard-Namespace verwenden. (Hinzugefügt in Version 3.2.91s des RapidiConnector.)
Später haben wir den Read-Design-Prozess für die SOAP Action weiter verbessert, da der oben beschriebene Ansatz nicht immer funktionierte (ein Fix kam mit Version 3.2.92q).
In Version 3.2.92z haben wir die Erkennung von Webservices für Microsoft Dynamics AX 2012 verbessert – jetzt suchen wir zusätzlich zum Standard-Namespace von Microsoft Dynamics auch nach Webservices, die im Namespace tempuri.org veröffentlicht sind.
Und schließlich haben wir nach weiterem Debugging einen besseren Weg gefunden, diese Informationen aus der WSDL zu extrahieren; das ist in Version 3.2.93a des RapidiConnector enthalten.
Unterstützung für weitere Standard- und benutzerdefinierte Webservices
In der WSDL der verschiedenen in Microsoft Dynamics AX veröffentlichten Webservices ist nicht zu erkennen, welches Feld tatsächlich der Primär- bzw. eindeutige Schlüssel des jeweiligen Webservice ist. Da wir diese Information z. B. beim Aktualisieren von Datensätzen benötigen, setzen wir sie manuell im Code. Wenn Sie also einen neuen (benutzerdefinierten) Webservice verwenden möchten, müssen Sie sich unter Umständen an unseren Support wenden, damit wir das einrichten. Zuletzt haben wir Unterstützung für die folgenden WebServices hinzugefügt:
SalesQuotationTable-Tabelle mit QuotationId (Version 3.2.91r)
InventTrans-Tabelle mit InventTransId (Version 3.2.91y)
ConfigTable-Tabelle mit ID-Feld ConfigId (Version 3.2.92e)
smmBusRel-Tabelle mit ID-Feld BusRelAccount (Version 3.2.92w)
ContactPerson-Tabelle mit ID-Feld ContactPersonId (Version 3.2.92w)
smmOpportunityTable-Tabelle mit ID-Feld OpportunityId (Version 3.2.92w)
smmLeadTable mit ID-Feld LeadId (Version 3.2.92z)
Das ist keine vollständige Liste dessen, was wir unterstützen – probieren Sie es also mit Ihrem Webservice aus. Wenn Sie einen Fehler wie "IdFieldName not found for entity..." erhalten, wenden Sie sich an unseren Support.
Wir arbeiten an einer besseren Lösung dafür – zum Beispiel daran, diese Information wenn möglich aus dem Transfer-Setup zu übernehmen. Bleiben Sie dran.
Verschiedene Korrekturen bei Datenformat und Reihenfolge der gesendeten Unterelemente
Wir haben eine Reihe von Verbesserungen vorgenommen, damit Daten im richtigen Format und in der richtigen Reihenfolge erzeugt werden – auch wenn Sie z. B. Unterelemente (oder Untertabellen) in MyRapidi in einer anderen Reihenfolge angeben. Die Webservices von Microsoft Dynamics AX sind sehr streng in der Reihenfolge, in der Sie Felder und Elemente senden – und die Fehlermeldungen von Microsoft Dynamics AX oder IIS sind meist wirklich nutzlos (irgendetwas mit Problemen im Schema oder einfach, dass der Server die Anfrage wegen eines internen Fehlers nicht verarbeiten konnte ...). Das kann die Fehlersuche sehr mühsam machen.
Beim Anlegen neuer Entitäten senden wir Unterelemente (Untertabellen) jetzt immer in der richtigen Reihenfolge (gemäß WSDL) an Microsoft Dynamics AX.
Wir stellen jetzt den ServiceName vor den Tabellennamen, damit der Tabellenname eindeutig ist. Das ist wichtig, damit mehrere Webservices nebeneinander bestehen können, auch wenn sie Unterelemente mit gleichen Namen haben (etwa DirParty oder ContactPerson). Der Service-Name wird außerdem in das Kommentarfeld des Layouts eingetragen, sodass beim Mapping leicht zu erkennen ist, zu welchem Service eine Tabelle (Untertabelle) gehört.
Wir haben ein Problem behoben, bei dem unsere Tracing-Funktion fehlschlagen konnte, wenn der Wert eines Date- oder Datetime-Feldes leer war.
Außerdem haben wir ein Problem beim Schreiben von Datetime-Feldern behoben – das Format musste am Ende ein "Z" enthalten.
Wir haben einen Fehler im Zusammenhang mit Decimal-Feldern behoben. Die Fehlermeldung lautete: "createField: unknown type AxdType_Decimal". Wir ermitteln jetzt beim Read Design den richtigen Typ, sodass dieser Fehler nicht mehr auftritt. Behoben in Version 3.2.92w.
Eine Verbesserung bei der Unterstützung verschiedener Feldtypen für Microsoft Dynamics AX 2012 Webservices steht noch aus. Derzeit unterstützen wir die AxdEntityKey_-Felder nicht. Wenn Sie einen Wert für ein Feld dieses Typs setzen müssen, sprechen Sie uns an – wir arbeiten dann daran, das zu unterstützen.
Besserer Verbindungstest (Test-Schaltfläche auf der Connection-Karte) sowie bessere Fehlerbehandlung und Fehlermeldungen
Für Microsoft Dynamics AX 2012 versuchen wir beim Verbindungstest jetzt nicht nur, eine Verbindung zum IIS-Server herzustellen, sondern rufen tatsächlich einen Webservice auf – zum Beispiel wenn Sie auf der Connection-Karte auf Test klicken. So stellen wir sicher, dass die Funktion Test Connection tatsächlich alle Probleme beim Aufruf der auf dem Server veröffentlichten Webservices aufdeckt.
Die Funktion Test Connection ruft die Read-Operation des GenericDocumentService auf und versucht, die Customer Groups aus Microsoft Dynamics AX zu lesen. Das funktioniert, solange Sie die Read-Operation des GenericDocumentService veröffentlicht haben.
Gleichzeitig haben wir die Fehlerbehandlung für die möglichen Fehler dieses Tests überarbeitet und die Fehlermeldungen verbessert, einschließlich Hinweisen auf mögliche Lösungen für das jeweilige Problem.
Unter anderem prüfen wir jetzt gezielt, ob im Parameter "Server Connect" ein falscher Pfad angegeben ist, und liefern für diesen Fall eine bessere Fehlerbehandlung und Meldung (vorher konnte das zu einem SocketReadError führen).
Wir liefern jetzt eine bessere Fehlermeldung, wenn der IIS-Server nicht läuft (vorher kam ein SocketConnectToServer-Fehler, der von einem zentralen Server usw. sprach).
Diese Verbesserungen wurden in Version 3.2.92z eingeführt.
DBLookup beim Lesen aus Microsoft Dynamics AX (SQL-Datenbank) verwenden
Wenn Sie eine DBLookup-Funktion verwendet und aus der Microsoft Dynamics AX-Datenbank (SQL Database) gelesen haben, nutzten wir für den Lookup in der SQL-Datenbank unseren generischen MS-SQL-Handler. Das funktionierte, führte aber auch zu einem Speicherleck im RapidiConnector. Das ist jetzt behoben: Wir verwenden für den DBLookup nun korrekt den Microsoft Dynamics AX-Handler.
Das bedeutet auch, dass der DBLookup automatisch einen Filter auf das Feld DATAAREA setzt (auf das Unternehmen, das in der Microsoft Dynamics AX Connection eingestellt ist). Normalerweise ist das genau richtig, aber manchmal müssen Sie Daten in einem anderen Unternehmen suchen. Dann geben Sie im DBLookup einfach einen Filter auf DATAAREA an, und dieser überschreibt den allgemeinen Filter.
Behoben in Version 3.2.92h des RapidiConnector.
Welche Version sollten Sie also verwenden?
Um die beste Unterstützung für Microsoft Dynamics AX Webservices zu haben, sollten Sie generell auf Version 3.2.93a des RapidiConnector und auf dem zentralen Service auf Version 3.2.92z oder höher aktualisieren.
Bitte wenden Sie sich an unseren Support, um das einzurichten.
Danke fürs Lesen – und melden Sie sich gern, wenn Sie Fragen haben.
Michael
