Mises à jour des services web Microsoft Dynamics AX 2012 (3.2.93a)
J’ai le plaisir d’annoncer une mise à jour majeure de notre prise en charge des services web Microsoft Dynamics AX. Elle concerne principalement Microsoft Dynamics AX 2012 R1, R2 et R3 (mais aussi quelques changements pour Microsoft Dynamics AX 2009).
Ces 6 à 8 derniers mois, nous avons travaillé intensément sur notre prise en charge de Microsoft Dynamics AX 2012, en particulier sur celle des services web Microsoft Dynamics AX 2012. Nous nous engageons à prendre en charge toutes les versions de Microsoft Dynamics AX, et il est donc naturel pour nous de continuer à investir dans l’amélioration de notre prise en charge de ces systèmes. Cette mise à jour regroupe un ensemble de changements introduits au fil du temps, et le résultat global est qu’il est désormais beaucoup plus simple et plus rapide de mettre en place une intégration avec Microsoft Dynamics AX 2012.
Poursuivez votre lecture pour un aperçu complet des changements :
Prise en charge des dimensions par défaut et des champs de dimension (services web Microsoft Dynamics AX 2009)
Dans Microsoft Dynamics AX 2009, les dimensions par défaut doivent être envoyées sous forme de liste d’éléments, par exemple lorsque vous utilisez le service web Customer pour créer un client dans Microsoft Dynamics AX. Nous avons ajouté une prise en charge générale de ce cas en permettant d’envoyer une liste de champs sous forme de tableau de chaînes vers Microsoft Dynamics AX. Dans MyRapidi, vous pouvez créer une liste de deux façons : soit avec un Gather Transfer, soit avec la fonction SPLIT (bien plus simple).
Voici un exemple :
##SPLIT('AAA|BBB|CCC','|')
Cette fonction crée une liste de trois éléments/chaînes qui peut être mappée sur le champ Dimension du service web Customer de Microsoft Dynamics AX 2009. Elle définit AAA comme première dimension, BBB comme dimension suivante et CCC comme troisième dimension. Si votre paramétrage des dimensions dans Microsoft Dynamics AX prévoit plus ou moins de dimensions, adaptez simplement la formule. Vous pouvez également récupérer les valeurs des dimensions dans des champs de l’enregistrement source, en indiquant ces champs (entre guillemets doubles) dans la formule.
Cette fonctionnalité est disponible depuis la version 3.2.91n du RapidiConnector.
Prise en charge des dimensions par défaut et des champs de dimension (services web Microsoft Dynamics AX 2012)
Dans Microsoft Dynamics AX 2012, la structure des dimensions est plus souple et prévoit plusieurs dimensions déjà nommées, tout en vous permettant de n’en définir que quelques-unes si vous le souhaitez. La structure attendue par le service web de Microsoft Dynamics AX doit contenir à la fois le nom et la valeur de chaque dimension, et vous pouvez définir un nombre variable de dimensions. Là encore, nous avons simplifié les choses dans MyRapidi en vous laissant indiquer une liste. Cette liste doit contenir un nombre pair d’éléments et comporter le nom et la valeur de chaque dimension que vous voulez définir.
Voici un exemple :
##SPLIT('CostCenter|OU_3567|Department|OU_2310','|')
Si vous utilisez cela comme source et le mappez sur le champ DefaultDimension du service web Customer de Microsoft Dynamics AX 2012, vous définissez la dimension CostCenter sur OU_3567 et la dimension Department sera définie sur OU_2310. Dans le layout, vous verrez le type « valueset » pour les champs de type DimensionValueSet.
Cette fonctionnalité est disponible depuis la version 3.2.92z du RapidiConnector.
Améliorations liées au Read Design (services web Microsoft Dynamics AX 2012)
Vous pouvez maintenant faire un Read Design sur le SalesQuotationService standard. Il y avait un problème de nommage du service, mais il est désormais lu correctement lors du Read Design et fonctionne dans les Transfers. Ajouté en version 3.2.91r du RapidiConnector.
Nous lisons désormais la SOAP Action et le Target Namespace depuis le WSDL et utilisons ces informations pour composer les appels de service web. Auparavant, nous composions ces informations à partir du nom du service. Cela nous permet de prendre en charge différents services web pour Microsoft Dynamics AX, y compris des services web développés sur mesure qui n’utilisent pas le namespace standard (ajouté en version 3.2.91s du RapidiConnector).
Nous avons ensuite amélioré le processus de Read Design pour la SOAP Action, car l’approche ci-dessus ne fonctionnait pas toujours (correctif fourni en version 3.2.92q).
En version 3.2.92z, nous avons amélioré la découverte des services web pour Microsoft Dynamics AX 2012 : nous recherchons désormais aussi les services web publiés avec le namespace tempuri.org, en plus du namespace Microsoft Dynamics standard.
Et enfin, après d’autres phases de débogage, nous avons trouvé une meilleure façon d’extraire ces informations du WSDL, et c’est celle qui est introduite en version 3.2.93a du RapidiConnector.
Prise en charge de services web standard et personnalisés supplémentaires
Dans le WSDL des différents services web publiés dans Microsoft Dynamics AX, vous ne voyez pas quel champ constitue réellement la clé primaire ou unique de ce service web. Comme nous avons besoin de cette information, par exemple pour mettre à jour des enregistrements, nous la définissons manuellement dans le code. Cela signifie que si vous voulez utiliser un nouveau service web (personnalisé), vous devrez peut-être contacter notre support pour la faire renseigner. Nous avons récemment ajouté la prise en charge des WebServices suivants :
SalesQuotationTable, table avec QuotationId (version 3.2.91r)
InventTrans, table avec InventTransId (version 3.2.91y)
ConfigTable, table avec le champ d’identifiant ConfigId (version 3.2.92e)
smmBusRel, table avec le champ d’identifiant BusRelAccount (version 3.2.92w)
ContactPerson, table avec le champ d’identifiant ContactPersonId (version 3.2.92w)
smmOpportunityTable, table avec le champ d’identifiant OpportunityId (version 3.2.92w)
smmLeadTable avec le champ d’identifiant LeadId (version 3.2.92z)
Cette liste n’est pas exhaustive : essayez donc avec votre service web. Si vous obtenez une erreur du type « IdFieldName not found for entity... », veuillez contacter notre support.
Nous travaillons à une meilleure solution : par exemple reprendre cette information depuis le paramétrage du transfert si possible. Restez à l’écoute.
Divers correctifs sur le format des données et l’ordre d’envoi des sous-éléments
Nous avons apporté plusieurs améliorations pour générer les données au bon format et dans le bon ordre, même si vous indiquez par exemple les sous-éléments (ou sous-tables) dans un ordre différent dans MyRapidi. Les services web de Microsoft Dynamics AX sont très stricts sur l’ordre dans lequel vous envoyez les champs et les éléments, et les messages d’erreur renvoyés par Microsoft Dynamics AX ou IIS sont généralement inutilisables (quelque chose à propos d’un problème de schéma, ou simplement que le serveur n’a pas pu traiter la requête en raison d’une erreur interne...). Cela peut compliquer considérablement la recherche de la cause.
Lors de la création de nouvelles entités, nous envoyons désormais toujours les sous-éléments (sous-tables) dans le bon ordre (selon le WSDL) vers Microsoft Dynamics AX.
Nous ajoutons désormais le ServiceName devant le nom de la table afin de le rendre unique. C’est important pour que plusieurs services web puissent coexister même s’ils ont des sous-éléments portant les mêmes noms (comme DirParty ou ContactPerson). Le nom du service est aussi ajouté au champ de commentaire du layout, pour voir facilement à quel service appartient une table (sous-table) lors du mapping.
Nous avons corrigé un problème qui pouvait faire échouer notre fonction de tracing lorsque la valeur d’un champ date ou datetime était vide.
Nous avons également corrigé un problème d’écriture des champs datetime : le format devait comporter un « Z » à la fin.
Nous avons corrigé une erreur liée aux champs Decimal. Le message d’erreur était : « createField: unknown type AxdType_Decimal ». Nous résolvons maintenant le type correct lors du Read Design, si bien que vous n’obtiendrez plus cette erreur. Corrigé en version 3.2.92w.
Il reste une amélioration à apporter concernant la prise en charge des différents types de champs avec les services web Microsoft Dynamics AX 2012. Pour l’instant, nous ne prenons pas en charge les champs AxdEntityKey_. Si vous devez définir une valeur pour un champ de ce type, contactez-nous et nous ferons le nécessaire pour le prendre en charge.
Test de connexion amélioré (bouton Test sur la fiche Connection), meilleure gestion des erreurs et meilleurs messages d’erreur
Pour Microsoft Dynamics AX 2012, lors du test de connexion, nous n’essayons plus seulement de nous connecter au serveur IIS : nous appelons réellement un service web, par exemple quand vous cliquez sur le bouton Test de la fiche Connection. Nous sommes ainsi certains que la fonction Test Connection révélera bien tout problème d’appel des services web publiés sur le serveur.
La fonction Test Connection appelle l’opération read du GenericDocumentService pour tenter de lire les Customer Groups depuis Microsoft Dynamics AX. Cela fonctionne tant que vous avez publié l’opération Read du GenericDocumentService.
Nous avons en même temps repris la gestion des erreurs possibles pendant ce test et cherché à améliorer les messages d’erreur, avec notamment des suggestions de solutions possibles au problème rencontré.
Entre autres, nous vérifions maintenant précisément le cas d’un chemin erroné indiqué dans le paramètre « Server Connect » et proposons une meilleure gestion et un meilleur message pour cette situation (cela pouvait auparavant produire un SocketReadError).
Nous fournissons maintenant un meilleur message d’erreur si le serveur IIS n’est pas démarré (auparavant, nous obtenions une erreur SocketConnectToServer parlant de serveur central, etc.).
Ces améliorations ont été introduites en version 3.2.92z.
Utiliser DBLookup pour lire depuis Microsoft Dynamics AX (base de données SQL)
Lorsque vous utilisiez une fonction DBLookup pour lire dans la base de données Microsoft Dynamics AX (base SQL), nous utilisions notre gestionnaire MS-SQL générique pour effectuer la recherche dans la base SQL. Cela fonctionnait, mais créait aussi une fuite de mémoire dans le RapidiConnector. C’est maintenant corrigé : nous utilisons désormais correctement le gestionnaire Microsoft Dynamics AX pour le DBLookup.
Cela signifie aussi que le DBLookup applique automatiquement un filtre sur le champ DATAAREA (sur la société définie dans la Connection Microsoft Dynamics AX). C’est normalement parfait, mais dans certains cas vous devrez rechercher des données dans une autre société : indiquez alors simplement un filtre sur DATAAREA dans le DBLookup, et il remplacera le filtre général.
Corrigé en version 3.2.92h du RapidiConnector.
Alors quelle version utiliser ?
De manière générale, pour bénéficier de la meilleure prise en charge des services web Microsoft Dynamics AX, vous devriez passer à la version 3.2.93a du RapidiConnector et à la version 3.2.92z ou ultérieure sur le service central.
Veuillez contacter notre support pour organiser cela.
Merci de votre lecture, et n’hésitez pas à nous poser vos questions.
Michael
