Planification du processus de migration

SAP Process Orchestration propose plusieurs solutions de déploiement d'infrastructure qui peuvent être classées comme domaines centraux, distribués (modèle 1) ou distribués (modèle 2).

Un serveur d'intégration unique communiquant avec tous les systèmes de gestion. Le déploiement central de SAP Process Orchestration est une architecture commune à la plupart des organisations car elle représente la plus petite empreinte d'installation possible et présente les avantages du coût total de possession (TCO) associés.

Un serveur d'intégration unique avec un ou plusieurs moteurs d'adaptateur décentralisés communiquant avec les systèmes de gestion pertinents. On le trouve souvent dans les entreprises où des raisons de performance ou de sécurité imposent une solution plus complexe que la centralisation. Il s'agit d'une approche hybride entre les modèles centraux et fédérés combinant les avantages liés à la performance et à la sécurité avec les avantages de la gouvernance, de la maintenance et du suivi centralisés.

Deux serveurs d'intégration ou plus (domaines) au sein d'une même infrastructure communiquant avec les systèmes de gestion pertinents. L'utilisation d'adaptateurs décentralisés supplémentaires par serveur d'intégration est également possible et ajoute un niveau de complexité supplémentaire. En raison de l'architecture plus complexe, le deuxième modèle de domaine distribué permet une plus grande flexibilité, mais au détriment d'un coût total de possession plus élevé. Ces organisations sont généralement de plus grande taille et nécessitent un haut degré d'abstraction dans leur paysage.

Contrairement aux raisons orientées client pour ce modèle, il existe également certaines raisons pilotées par SAP, telles que l'isolement pour l'indépendance du chemin de montée de version ou le découplage des systèmes de gestion et des liaisons d'IU du portail.

SAP Business Accelerator Hub (https://hub.sap.com) est une application Web hébergée par SAP pour découvrir, explorer et tester les API SAP et partenaires (interfaces de programmation d'applications) requises pour créer des extensions ou des intégrations de processus.

Les API des solutions SAP utilisent différents protocoles, documentations et mécanismes d'accès. Les développeurs d'applications et d'intégration doivent avoir une vue d'ensemble cohérente des API disponibles dans les systèmes SAP pertinents (déployés sur site et dans le Cloud). Le test des API et la création de prototypes impliquent également l'organisation de l'accès aux systèmes et locataires pertinents pour les développeurs.

SAP Business Accelerator Hub répond à ces défis en proposant un catalogue central d'API, ainsi qu'un environnement de test intégré dans le Cloud pour faciliter les tests. SAP Business Accelerator Hub couvre les API de SAP S/4HANA, SAP SuccessFactors, SAP BTP, SAP Hybris, etc.

Le modèle Agrégateur est un modèle d'intégration d'entreprise fondamental utilisé dans des systèmes tels que SAP Integration Suite pour regrouper plusieurs messages associés et les traiter en masse. Ce modèle est essentiel pour les scénarios dans lesquels des messages individuels doivent être collectés et gérés ensemble, tels que le regroupement de plusieurs postes de commande dans un seul document d'ordre. Le message agrégé est ensuite envoyé au récepteur réel.

La figure Modèle d'agrégateur explique les différences entre l'implémentation du modèle dans SAP Process Orchestration et SAP Integration Suite.

Comme le modèle d'agrégateur conserve un état, SAP Business Process Management (SAP BPM) est requis pour orchestrer le flux de messages. Pour l'échange réel de messages avec les systèmes concernés, l'exécution SAP Process Integration de SAP Process Orchestration est utilisée.

Comme vous pouvez le voir dans le modèle de flux d'intégration, SAP Integration Suite est fourni avec une étape de flux d'agrégateur dédiée. Par conséquent, vous n'avez pas besoin de modéliser le modèle dans une boucle comme vu pour SAP Process Orchestration. Dans l'étape de flux Agrégateur, vous définissez réellement votre condition de corrélation ainsi que les conditions d'achèvement. Actuellement, la condition du dernier message et le délai d'expiration de l'achèvement sont pris en charge. Malheureusement, le nombre maximal de messages n'est pas encore pris en charge. Le reste des étapes de flux est utilisé pour mapper la collection d'éléments au bon format de message, dans notre cas une commande avec des informations d'en-tête d'ordre et tous les postes, supprimant ainsi les informations redondantes.

Ce modèle est utilisé lorsqu'un message avec plusieurs éléments doit être traité et que chaque élément nécessite un traitement différent. Le message est fractionné en sous-messages et envoyé à différentes destinations pour traitement. Les résultats sont ensuite recombinés en un seul message.

Dans cet exemple, un séparateur général est utilisé pour diviser l'ordre en plusieurs messages individuels, en fonction du nombre de postes dans l'ordre d'origine. Dans une étape ultérieure, le routeur transfère les articles à un autre système de gestion des stocks, en fonction de la catégorie de produit. L'enrichissement de contenu lit ensuite les données de manière synchrone à partir d'un système externe et ajoute les informations supplémentaires au message d'origine avant le routage vers le récepteur réel. Enfin, l’étape Regrouper réagrège les réponses multiples en un seul message dans l’ordre d’origine.

Avec le modèle Scatter-Gather, vous pouvez diffuser un message à plusieurs destinataires et réagréger les réponses en un seul message.

Le flux d'intégration du modèle de dispersion/regroupement de référence se compose de deux processus d'intégration : l'un pour la partie dispersion et l'autre pour la partie regroupement.

Dans cet exemple, la partie Scatter prend la demande et la diffuse à plusieurs banques. Avant cette partie Nuage de points, le temporisateur est déclenché via un message distinct envoyé à la partie Rassembler.

Le processus d'intégration Rassembler reçoit les offres des banques, les agrège, calcule la meilleure offre et renvoie finalement la meilleure offre au demandeur.

L'enrichissement du contenu lit les données de manière synchrone à partir d'un système externe et ajoute les informations supplémentaires au message d'origine avant le routage vers le récepteur réel.

La figure Modèle d'enrichissement du contenu explique ce modèle dans SAP Process Orchestration et SAP Integration Suite.

Dans l'exemple ci-dessus, le processus commence à rassembler une liste de commandes pour un salarié spécifique. Les détails du client sont manquants. Ils doivent être récupérés à partir d'un autre système. Par conséquent, vous passez en boucle la liste des ordres et, dans chaque passage de boucle, vous effectuez un appel de service Web à l'aide d'une activité automatisée. Dans l'activité automatisée, les informations supplémentaires sont ensuite mappées sur le poste de commande correspondant, ce qui enrichit le message.

Dans SAP Integration Suite, vous pouvez modéliser l'enrichissement du contenu via le modèle Réponse à la demande ou via une étape de flux Enrichissement du contenu dédiée.

L'étape de flux Enrichissement du contenu fait automatiquement correspondre les réponses aux différents éléments du message d'origine. Elle est particulièrement adaptée à l'enrichissement de données en vrac. L'utilisation de cette option est bien meilleure en termes de performances par rapport à un modèle de réponse à une demande. Ici, vous n'avez pas besoin de répéter tous les postes en exécutant des appels de recherche individuels, vous n'effectuez qu'un seul appel et la comparaison est effectuée automatiquement en fonction de votre clé.

Selon le cas d'utilisation, plusieurs options sont disponibles pour le modèle Séparateur. Le modèle Séparateur vous permet de diviser un message en plusieurs messages individuels en fonction du nombre d'éléments.

Il existe deux cas d'utilisation :

• Fractionner un message de commande en masse en plusieurs commandes
• Fractionnement d'une seule commande avec plusieurs postes

Variante avec séparateur d'itération

Lors du fractionnement d'un message de commande en masse en plusieurs commandes, vous pouvez utiliser la variante avec le séparateur d'itération.

La figure Variante avec séparateur itératif illustre ce scénario simple contenant une étape d'itération du séparateur.

Variante avec séparateur général

Le séparateur général vous permet de fractionner un seul ordre avec plusieurs postes en messages individuels. Le séparateur général duplique automatiquement les informations d'en-tête de l'ordre pour chaque message individuel.

La variante de flux d'intégration avec le séparateur général contient une étape de séparateur générale.

Variante avec mappage de messages

Utilisez cette variante si vous avez des besoins spécifiques qui ne sont pas couverts par le séparateur général ou si vous voulez réutiliser le mappage de votre système SAP Process Orchestration.

La figure Variante avec mappage de messages illustre les étapes de flux requises.

Le routage basé sur le contenu vous permet de transférer des messages au bon destinataire, en fonction du contenu d'un message.

Pour chaque récepteur, vous pouvez gérer une condition sous la forme d'une expression XPath. L'expression XPath peut être basée sur les données utiles ou l'en-tête du message. Lors du traitement des messages, Cloud Integration évalue la condition et, si elle est remplie, achemine le message vers le destinataire correspondant. Si aucun récepteur ne peut être déterminé, Cloud Integration peut procéder selon les variantes suivantes :

• Envoyer un message à un destinataire par défaut
• Ignorer le message
• Déclencher une erreur

Envoyer un message à un destinataire par défaut

Dans l'exemple de flux d'intégration, le message est acheminé vers différents récepteurs en fonction d'une certaine condition de routage. Si aucune condition de routage n'est remplie, Cloud Integration envoie le message à un destinataire par défaut.

La figure Variante Envoyer un message à un récepteur par défaut illustre l'iFlow.

Ignorer message

Dans cette variante, aucun récepteur ne peut être déterminé au moment de l'exécution car aucune condition de routage n'est remplie.

Pour chaque récepteur, la condition de routage est configurée en conséquence. En outre, un itinéraire qui pointe vers un événement de fin est configuré.

Déclencher une erreur

Dans cet exemple, une erreur est déclenchée si aucun récepteur ne peut être déterminé, en fonction de l'expression XPath. Désormais, l'itinéraire par défaut mène à un événement de fin d'erreur.

Différentes options de traitement des messages sont modélisées pour le sous-processus d'exception. Les options varient selon que l'événement est déclenché par l'événement Fin de l'erreur dans le processus d'intégration principal ou par toute autre erreur pouvant survenir lors du traitement des messages.

Le modèle d'intégration de liste de destinataires vous permet d'envoyer un ou plusieurs messages à différents destinataires. Comme pour une commande, vous voulez envoyer à différents fournisseurs en fonction du produit que vous voulez commander. Par conséquent, les fournisseurs spécifiques sont déterminés dynamiquement en fonction des marchandises respectives. En dehors du routeur basé sur le contenu, une copie du message est envoyée à plusieurs destinataires.

Il existe deux options lors de l'implémentation du modèle de liste Récepteur :

• Routage statique avec conditions XPath
• Routage dynamique à l'aide d'un mappage pour déterminer les récepteurs

Gamme statique

Dans cette variante, il existe une liste fixe de récepteurs potentiels. Le modèle de liste des destinataires est réalisé via une combinaison de multidiffusion et de filtres de messages.

La figure Liste des destinataires des variantes avec routage statique illustre un exemple d'iFlow. L'étape Multicast permet d'envoyer des copies du même message à plusieurs itinéraires. Le filtre de message est un type spécifique du routeur de messages qui n'a qu'un seul canal récepteur. Le filtre de message évalue chaque message entrant. Si le message répond aux critères spécifiés par le filtre de message, il sera acheminé vers le destinataire, sinon il sera ignoré.

Gamme dynamique

Outre la variante de gamme statique, vous n'avez pas besoin de gérer un nombre fixe de récepteurs dans le flux d'intégration.

Comme illustré dans la figure ci-dessus, la partie détermination du récepteur est découplée de la livraison du message spécifique au récepteur. Par conséquent, un processus d'intégration principal contenant la détermination du récepteur est modélisé et un flux d'intégration est modélisé pour chaque récepteur potentiel. Le modèle principal et les flux d'intégration individuels sont couplés via l'adaptateur ProcessDirect. L'adresse ProcessDirect est définie dynamiquement en fonction de la détermination du récepteur.

Le modèle Filtre de messages vous permet de supprimer toutes les données d'un canal qui ne vous intéresse pas. Le filtre de messages est un type spécifique du modèle Routeur de messages qui n'a qu'un seul canal récepteur. Tout message entrant est évalué et s'il répond aux critères spécifiés par le filtre de message, le message est acheminé vers le récepteur, sinon il est rejeté.

Le modèle Filtre de message est similaire au modèle Gamme basée sur le contenu où le message est ignoré si vous ne pouvez pas déterminer le destinataire.

Cependant, pour le modèle Filtre de messages, vous définissez un seul destinataire.

Dans le flux d'intégration Filtre de modèle de message, vous définissez une condition de routage basée sur la catégorie de produit. Si la condition de routage n'est pas remplie, le message est rejeté. Vous pouvez obtenir ce comportement en ajoutant un routage par défaut pointant vers un événement de fin.

Le modèle de filtre de contenu vous permet de supprimer des données d'un message qui n'est pas requis dans votre système d'application.

Il existe deux options lors de l'implémentation d'un tel scénario :

• À l'aide d'une étape de filtre
• Utilisation du mappage de messages

Utilisation d'une étape de filtre

Dans cette variante, le filtre est utilisé pour supprimer tous les éléments de données inutiles du message. Cependant, l'en-tête du message est conservé.

La figure Variante à l'aide d'une étape de filtre illustre ce scénario simple.

Utilisation du mappage de messages

Dans cette variante, le mappage de messages est utilisé pour supprimer tous les éléments de données inutiles du message, mais l'en-tête du message est conservé.

Le flux d'intégration contient uniquement Mappage de messages.

Edge Integration Cell est inclus dans le cadre de SAP Integration Suite existante (pour les éditions standard et premium, Cloud Platform Enterprise Agreement (CPEA) et Pay-as-You-Go (PAYG)). Des cellules d'intégration Edge supplémentaires peuvent être acquises via une unité de gestion des stocks (UGS) supplémentaire distincte. Seuls 50 % des messages traités par Edge Integration Cell sont facturables (à l'exclusion du contenu standard non modifié pour le progiciel SAP vers SAP).