Traitement de document OAGIS

Utilisation de la zone de données BusinessContext

Dans le cadre de la transition de HCL Commerce vers des interactions OAGIS, un groupe de substitution pour la zone ApplicationArea du type OAGIS BusinessObjectDocumentType a été créé en vue d'ajouter des informations de contexte métier avec le message. L'objet de cette zone ApplicationArea étendue est de fournir une définition commune du mode de diffusion de la langue, de la devise, du magasin et d'autres informations de contexte métier communes dans HCL Commerce.

Les données de contexte métier sont distinctes du contexte de sécurité de l'utilisateur. Le contexte de sécurité est supposé être géré par l'environnement d'exécution (celui de HCL Commerce ou de WebSphere). Dans le cas de HCL Commerce, le contexte de sécurité pour les requêtes locales est déterminé par le contrôleur de solution et basé sur le jeton de sécurité dans l'en-tête SOAP des requêtes de service Web.

Format des données BusinessContext :

L'objet des données de contexte métier est de permettre au client de spécifier le contexte de la requête. Le client doit gérer le jeu de données de contexte requises pour chaque requête BOD et l'inclure lors de l'émission de la requête. Les données de contexte métier sont en texte clair et ne sont pas considérées constituer des données sensibles. En utilisant des données identifiables en externe, ces données peuvent être utilisées par la médiation pour leur intégration dans d'autres systèmes.

Les données de contexte sont transmises en clair pour permettre leur transformation depuis le format OAGIS vers un autre style de message pour une intégration de type ESB (Enterprise Service Bus). Si les données de contexte métier sont chiffrées, il devient impossible de les mapper et d'utiliser la technologie ESB pour leur intégration.

Le schéma est illustré sous forme graphique dans le diagramme suivant :

L'exemple de code Java ci-dessous indique comment spécifier storeId dans l'élément BusinessContext de la zone ApplicationArea de la requête :

aBusinessContext =
CommerceFoundationFactory.eINSTANCE.createBusinessContextType();
ContextDataType cStoreId =
CommerceFoundationFactory.eINSTANCE.createContextDataType();
cStoreId.setName("storeId");
cStoreId.setValue("10001");
aBusinessContext.getContextData().add(cStoreId);

Utilisation des paramètres de contrôle

Dans certains cas, l'appelant d'une interface de service a besoin de transmettre des paramètres supplémentaires (ne faisant pas partie du nom) afin que la logique métier appropriée puisse être exécutée sur le serveur HCL Commerce. Par exemple, merge, reverse, allocate et check sont des paramètres ATP de la commande OrderItemAddCmd permettant de contrôler le comportement du stock lors de l'ajout d'un article à une commande.

Ces types de paramètres doivent être spécifiés dans l'expression XPath d'HCL Commerce (stockés dans l'élément ActionExpression ou SelectionExpression du verbe). Tous les paramètres doivent débuter par un préfixe spécial, identique au préfixe du schéma de composant (par exemple, _ord). L'exemple suivant illustre comment transmettre les paramètres "allocate " et "reverse" pour tous les éléments OrderItems (indiqués par le signe *) dans le BOD ChangeOrder pour OrderItemAddCmd :

{_ord.reverse='*';_ord.allocate='*'}/Order[1]/OrderItem[1]

Mise en corrélation de la requête et de la réponse lors de l'utilisation de messagerie asynchrone

Depuis sa perspective, un composant ne peut pas savoir si le protocole utilisé correspond aux services Web, au protocole JMS natif, à SMTP ou à tout autre protocole. Ces informations de liaison sont déterminées par la configuration de la couche de service de communication pour le composant concerné. Cependant, le client sait si la communication est synchrone ou non.

Les messages OAGIS ont été conçus pour un mode de transmission synchrone ou asynchrone. Pour prendre en charge les communications asynchrones, un mécanisme doit permettre d'établir la corrélation entre les messages de requête et de réponse.

La structure de message OAGIS fournit un élément BODID dans la zone d'application. L'environnement d'exécution HCL Commerce (et la bibliothèque client pour les communications client) génère un GUID et l'intègre dans le BODID à chaque requête. Comme le code client ne connaît pas le type de transport, un BODID est généré pour chaque requête.

Les requêtes "Sync" sont généralement assurées par une messagerie asynchrone avec livraison garantie. Cette approche est adéquate puisque les requêtes "Sync" sont conçues pour être diffusées à toutes les parties intéressées. Ceci signifie qu'une interaction point à point synchrone n'est pas requise puisque le système d'enregistrement n'a pas besoin d'attendre une réponse à la requête.