Pattern de conception pour l'implémentation de services Get (SOI)
Le pattern de conception des services Get constitue le pattern de base à utiliser pour l'extraction et l'affichage d'informations depuis les services Web.
Le diagramme de classes suivant illustre les classes impliquées dans la création d'un service Get. Une commande de contrôleur maître est créée pour chaque service Get pour chaque nom. Cette commande, qui utilise la classe d'utilitaire com.ibm.commerce.foundation.server.util.oagis.SelectionCriteriaMapper, extrait les informations Get de la requête BOD. Elle divise ensuite le travail en deux tâches, déléguant à l'infrastructure de commandes l'exécution d'une commande Fetch et d'une commande Compose. La commande Fetch extrait les données, tandis que la commande Compose compose la réponse.
Extraire
La commande Fetch renvoie une liste de beans de données correspondant à l'expression. Les extensions de cette commande Fetch sont associées à une expression XPath particulière. Elles doivent implémenter l'expression de recherche uniquement pour renvoyer la liste appropriée des beans de données qui correspond à l'expression.
L'infrastructure de commandes peut utiliser l'expression XPath et l'instruction de tâche Fetch pour résoudre la requête Get à une implémentation particulière à l'aide des données de registre de commandes (CMDREG) HCL Commerce existantes. Au lieu d'avoir une implémentation pour une tâche métier Fetch, l'infrastructure de commandes utilise le XPath comme sélecteur pour résoudre l'implémentation. Si une implémentation spécifique n'est pas définie pour le XPath donné, une Fetch par défaut est utilisée.
Le grand principe derrière ce pattern de conception est la personnalisation. Ce modèle favorise la réutilisation de la commande Fetch, de sorte que la prise en charge d'une nouvelle expression de recherche est une question d'implémentation d'une nouvelle commande Fetch pour renvoyer une liste de bases de données renseignées qui représentent cette nouvelle expression. En utilisant la configuration XPath et la configuration de commande, vous pouvez associer une expression XPath à une implémentation de commande ou plusieurs expressions XPath avec la même implémentation de commande. Vous n'avez pas besoin de modifier les tâches Compose uniquement pour prendre en charge une nouvelle expression de recherche.
Ecrire
La commande Get prend alors cette liste et pour chaque bean de données, elle appelle une tâche Compose pour transformer le bean de données en modèle logique approprié (nom).
Profil d'accès
Il est recommandé qu'un profil d'accès soit utilisé pour cibler les données de réponse. L'utilisation d'un profil d'accès facilite l'extension du service plus tard, en utilisant différents profils pour permettre un accès différent ou le renvoi de données différentes. Vous pourriez, par exemple, vouloir renvoyer une vue spécifique des données (comme une vue de la recherche d'une entrée de catalogue) ou bien les données dans toutes les langues pour des besoins de création. Dans l'extension de la syntaxe XPath, la paire nom-valeur du profil d'accès doit précéder, entourée d'accolades ({}), l'expression XPath. Par exemple, pour spécifier le profil d'accès :
{_wcf.ap=$accessProfile$}/CatalogGroup[Name='MyCatalogGroupName']
Lorsque la commande Get appelle la commande Compose, elle utilise le profil d'accès de la requête comme clé pour sélectionner l'implémentation Compose appropriée. Étant donné que le profil d'accès n'est qu'un surensemble d'un autre profil d'accès, la commande Compose délègue au profil d'accès parent pour renseigner d'abord le modèle logique et ajouter toutes les informations requises. Il en résulte une chaîne de commandes Compose qui sont appelées pour le bean de données, chacune renseignant un ensemble du modèle logique.
Pour personnaliser la quantité et le type de données renvoyées dans la réponse, vous pouvez utiliser différentes tâches Compose sans modifier la tâche Fetch, en utilisant un profil d'accès différent comme clé. La prise en charge d'un nouveau profil d'accès consiste à créer une nouvelle commande Compose pour ce profil d'accès et à enregistrer l'implémentation. En outre, ce schéma d'enchaînement garantit que la personnalisation de la commande Compose à un profil d'accès particulier est reflétée dans tous les profils d'accès dépendants. Si la personnalisation ajoute plus de données au profil d'accès récapitulatif, tous les profils d'accès enfant incluent également ces données récapitulatives. Si vous remplacez une commande, tout le code dépendant bénéficie de ce nouveau comportement.
Les noms de profil d'accès portant le préfixe IBM_ sont réservés aux profils d'accès prédéfinis IBM. Cela empêche les conflits de nommage entre les profils d'accès définis par les composants HCL Commerce et vos profils d'accès personnalisés.
Les noms de profil d'accès qui ont comme préfixe IBM_Admin_ sont destinés aux services censés être utilisés par les appels de services basés admin/CMC.
Les noms de profil d'accès qui ont comme préfixe IBM_Store_ sont destinés aux services censés être utilisés par la vitrine.
Pour obtenir une cohérence entre les différents modules de service, les noms de profil IBM_Admin_Summary et IBM_Admin_Details sont utilisés lors de la récupération des informations récapitulatives et de niveau de détail sur l'objet entité.
La procédure recommandée pour prendre en charge les opérations Get consiste à utiliser les beans de données HCL Commerce existants pour réutiliser la logique métier et les stratégies de contrôle d'accès existantes.