SAP PI pour les débutants

Objectif

L’objectif de ce tutoriel est de vous faire comprendre – qu’est-ce que l’intégration de processus SAP? Nous n’entrerons pas dans le vif du sujet, mais nous discuterons de l’architecture et des différentes fonctionnalités de SAP PI. Nous couvrirons uniquement les fonctionnalités de base et éviterons de discuter de toutes les fonctionnalités de ce tutoriel.

Ensuite, il y a un ensemble d’études de cas qui vous donneront une idée de l’utilisation de SAP PI au niveau de l’industrie. Une fois que vous vous familiariserez avec le sujet, vous devriez essayer de les résoudre. Les cas de test sont préparés de manière à vous amener dans le sujet du plus simple au plus complexe à chaque leçon et à vous donner une idée globale du sujet.

Qu’est-ce que SAP ERP?

Pour toute entreprise, grande ou petite, ce sont les fonctionnalités métier standard qu’elle doit exécuter, à savoir la Gestion du matériel, les Ventes et la Distribution, les Finances, les Ressources Humaines, etc. Il y a beaucoup de logiciels sur le marché qui sont utilisés par l’industrie. Vous remarquerez le plus simple – le guichet générant une facture de vente si vous visitez un petit magasin à un réseau d’ordinateurs dans un grand magasin de détail, un hôtel, etc. fonctionnant sur un ERP.

La planification des ressources d’entreprise, c’est-à-dire l’ERP, est une approche efficace que la plupart des entreprises mettent en œuvre pour améliorer leur productivité et leurs performances. SAP ERP est la solution de planification des ressources d’entreprise de SAP AG, une solution logicielle intégrée qui intègre les fonctions clés de l’entreprise. Les fonctionnalités de base, à savoir HR, MM, SD, FICO, etc., sont appelées modules métier dans SAP. SAP les construit en tant que produits et les vend sur le marché. Il existe deux autres modules qui ne prennent pas directement en charge les fonctions métier mais sont utilisés pour la présentation et l’intégration. Le premier s’appelle EP (Portail d’entreprise) et le second s’appelle PI (Intégration de processus). Tous les modules métier sont développés en ABAP tandis que EP et PI sont développés principalement en Java. Ces modules ne sont pas exécutables, mais ils doivent être déployés dans un serveur d’applications, c’est-à-dire un serveur d’applications Web ABAP pour les modules ABAP et des serveurs d’applications Web Java pour les modules Java.

Il y a peu de points que nous devrions connaître avant de nous lancer dans le sujet.

• SAP signifie Systèmes, Applications et Produits dans le Traitement des Données.

• SAP AG est une société multinationale allemande de logiciels qui fabrique des logiciels d’entreprise pour gérer les opérations commerciales et les relations avec les clients. SAP ERP est le progiciel de gestion intégré de la société, une solution logicielle intégrée qui intègre les fonctions clés de l’entreprise.

• SAP NetWeaver Process Integration (SAP PI) est un logiciel d’intégration d’applications d’entreprise SAP (EAI), un composant du groupe de produits NetWeaver utilisé pour faciliter l’échange d’informations entre les logiciels et systèmes internes d’une entreprise et ceux de parties externes.

Système hérité

Lors de la mise en œuvre de l’ERP SAP dans un grand établissement commercial, il est constaté que toutes les sections ne peuvent pas être intégrées à l’ERP SAP. De nombreuses sections commerciales peuvent avoir leurs propres outils propriétaires qui sont très complexes et peuvent ne pas être remplacés. Ils fonctionnent parallèlement au système SAP. Ils sont appelés les Systèmes hérités. Ensuite, il devient nécessaire d’intégrer entre les systèmes SAP et un tel système non SAP préexistant. C’est là que le SAP PI entre en jeu.

Pourquoi avons-nous besoin de SAP PI En dehors des Systèmes hérités, dans une grande entreprise, SAP ERP ne se compose pas d’un seul système mais de plusieurs systèmes intégrés, à savoir CRM, SRM et FICO, etc. Pour gérer de telles complexités, SAP a introduit une plate-forme d’intégration des processus pour fournir un point d’intégration unique pour tous les systèmes sans toucher au réseau complexe existant de systèmes hérités. Il s’agit d’un middleware puissant conçu par SAP pour fournir une intégration transparente de bout en bout entre les applications SAP et non SAP à l’intérieur et à l’extérieur des limites de l’entreprise. SAP PI prend en charge les échanges B2B et A2A, prend en charge les échanges de messages synchrones et asynchrones et inclut un moteur intégré pour la conception et l’exécution des processus d’intégration.

Architecture de SAP PI

Le SAP PI se compose d’une structure de moyeu et de rayons; les rayons se connectent à des systèmes externes tandis que le moyeu échange des messages entre eux. Le système source est connu sous le nom de système émetteur et le système cible est connu sous le nom de système récepteur. L’IP n’est pas un composant unique, mais plutôt un ensemble de composants qui fonctionnent ensemble de manière flexible pour mettre en œuvre des scénarios d’intégration. L’architecture comprend des composants à utiliser au moment de la conception, au moment de la configuration et au moment de l’exécution.

Nous pouvons diviser le PI SAP en plusieurs zones

1. Serveur d’intégration
2. Constructeur d’intégration
3. Paysage système
4. Configuration et surveillance

Le serveur d’intégration est le moteur de traitement central du PI SAP. Tous les messages sont traités ici de manière cohérente. Il se compose de trois moteurs distincts

1. Moteur d’intégration
2. Moteur d’adaptateur
3. Moteur de processus métier

Le moteur d’intégration peut être considéré comme le moyeu et le moteur d’adaptateur le rayon. En ce qui concerne le Moteur de processus métier, je l’expliquerai plus tard.

Integration Builder est un framework client-serveur pour accéder et éditer des objets d’intégration et il se compose de deux outils associés:

1. Référentiel de services d’entreprise – pour concevoir et développer des objets à utiliser dans des scénarios
2. Répertoire d’intégration – pour configurer les objets ESR pour développer des scénarios

Deux ensemble, nous avons construit des processus d’intégration communément appelés scénarios.

Le Paysage système est un référentiel central d’informations sur les logiciels et les systèmes du centre de données et simplifie l’administration de votre paysage système.

Dans la configuration et la surveillance, nous pouvons surveiller les messages et les adaptateurs.

Pile simple et pile double

Lorsque PI a été publié pour la première fois, tous les composants n’étaient pas construits sur la même plate-forme. Le Moteur d’intégration et le Moteur de processus métier ont été construits en ABAP tandis que le Moteur d’adaptateur, le Constructeur d’intégration, le SL, le CM et le Runtime de cartographie ont été construits en Java. PI a donc besoin à la fois de l’environnement Java et de l’environnement ABAP pour s’exécuter et est connu sous le nom de double pile.

Pile ABAP	Pile Java
Moteur d’intégration Moteur de processus métier Générateur d’intégration	Répertoire d’intégration du Référentiel de services d’entreprise Workbench d’exécution Répertoire de paysage système Moteur d’adaptateur Exécution de mappage

Mais dans la version ultérieure, tous les composants sont construits en Java. Certains composants à double pile sont supprimés ou modifiés pour fonctionner sur la pile Java. PI n’a donc besoin que de l’environnement Java pour s’exécuter et est connu sous le nom de pile unique.

Il y a des avantages et des inconvénients entre les deux piles, mais ils ne sont pas couverts dans ce tutoriel.

Moteur d’intégration

Le Moteur d’intégration est responsable des services du serveur d’intégration central, c’est-à–dire des étapes de la canalisation – routage et mappage. Si la structure du message source est différente de la structure du message cible, le moteur d’intégration appelle le Runtime de mappage, où la structure source est convertie en structure cible. Le Runtime de mappage est basé sur la pile Java. Le moteur d’intégration peut également utiliser un programme ABAP pour la conversion, basé sur la pile ABAP.

Un message peut être de deux types

1. Synchrone – a à la fois la partie requête-réponse
2. Asynchrone – n’a que la partie requête ou réponse

Dans PI, le message est représenté par une interface.

Interface – > structure du message au format XML + direction

Sur la base des critères ci–dessus, il existe trois types d’interfaces

1. Interface sortante – se connecter au système émetteur
2. Interface entrante – se connecter au système récepteur
3. Interface abstraite – se connecter au BPE

Lorsque nous configurons la logique d’intégration (scénario) dans SAP PI selon nos exigences métier, c’est le moteur d’intégration qui exécute cette configuration de manière progressive. Pipeline est le terme utilisé pour désigner toutes les étapes effectuées lors du traitement d’un message XML. Les étapes de la conduite se composent des éléments suivants:

1. Identification du récepteur – détermine le système qui participe à l’échange du message.
2. Détermination de l’interface – déterminez quelle interface doit recevoir le message.
3. Fractionnement du message – si plusieurs récepteurs sont trouvés, PI instanciera un nouveau message pour chaque récepteur.
4. Mappage de messages – mappage pour transformer le message source au format de message de destination.
5. Routage technique – liez une destination et un protocole spécifiques au message.
6. Adaptateur d’appel – envoie le message transformé à l’adaptateur ou à un proxy.

Moteur d’adaptateur

Vous devez avoir remarqué précédemment que le moteur d’intégration gère uniquement les messages dans le protocole XML-SOAP. Mais que se passe-t-il si nous avons un système d’entreprise émetteur et récepteur où les données ne sont pas dans le même format. Nous utilisons les différents adaptateurs du moteur d’adaptateur pour convertir les messages XML et HTTP au protocole et au format spécifiques requis par ces systèmes, et vice versa.

Comme nous l’avons discuté précédemment, SAP PI est une structure de moyeu et de rayons où le moteur de l’adaptateur peut être considéré comme un rayon. Nous utilisons le moteur Adaptateur pour connecter le moteur d’intégration (Hub) aux systèmes externes. Le cadre de l’adaptateur est la base du moteur de l’adaptateur. L’infrastructure de l’adaptateur est basée sur le moteur SAP J2EE (faisant partie du serveur d’applications Web SAP) et l’architecture J2EE Connector (JCA). L’infrastructure d’adaptateur fournit des interfaces pour la configuration, la gestion et la surveillance des adaptateurs.

Dans un système à double pile, la plupart des adaptateurs étaient basés sur la pile Java, à l’exception de deux adaptateurs basés sur la pile ABAP.

Pile Java	Adaptateur RFC, adaptateur SAP Business Connector, adaptateur fichier / FTP, Adaptateur JDBC, Adaptateur JMS, Adaptateur SOAP, Adaptateur Marketplace, Adaptateur mail, Adaptateur RNIF, Adaptateur CIDX
Pile ABAP	Adaptateur IDOC et adaptateur HTTP

Lorsque SAP PI est passé d’une pile double à une pile simple, ces deux adaptateurs sont devenus une partie de la pile Java. Le moteur d’adaptateur modifié est connu sous le nom de moteur d’adaptateur avancé et les deux adaptateurs sont appelés respectivement adaptateur IDOC_AAE et adaptateur HTTP_AAE.

Moteur de processus métier

Le Moteur de processus métier est responsable de l’exécution et de la persistance des processus d’intégration.

BPM signifie cross-component Business Process Management ou ccBPM et est également appelé processus d’intégration. Un processus d’intégration est un processus exécutable inter-système pour le traitement des messages. Dans un processus d’intégration, vous définissez toutes les étapes du processus à exécuter et les paramètres pertinents pour contrôler le processus. La gestion des processus métier fournit à l’infrastructure SAP Exchange les fonctions suivantes:

1. État – traitement complet des messages : L’état d’un processus d’intégration est conservé sur le serveur d’intégration.
2. Vous pouvez également utiliser des corrélations pour établir des relations sémantiques entre les messages.
3. Vous implémentez des processus d’intégration lorsque vous souhaitez définir, contrôler et surveiller des processus d’intégration complexes qui s’étendent au-delà des limites de l’entreprise et des applications, c’est-à-dire collecter/Fusionner, diviser, Multidiffusion

Au moment de l’exécution, le moteur de processus métier exécute les processus d’intégration. Le processus d’intégration peut envoyer et recevoir des messages à l’aide d’interfaces abstraites uniquement.

Construire un scénario dans SAP PI

Nous partons de la page d’accueil si nous devons construire un scénario dans PI.

La page d’accueil ressemblera à celle donnée ci-dessous:

Figure 6 – Page d’accueil de la pile Java SAP PI

La page d’accueil comporte des hyperliens vers les 4 zones de travail suivantes

1. Référentiel de services d’entreprise (ESR)
2. Répertoire d’intégration (ID)
3. Paysage système (SL)
4. Configuration et surveillance (CM)

Chaque lien hypertexte ouvrira une application. Tous ces quatre sont des applications Java. ESR et ID sont des applications swing. Ils sont lancés à partir du navigateur basé sur JNLP. Donc, pour la première fois, cela prend plus de temps car il télécharge l’intégralité du fichier de la bibliothèque. Mais à partir de la deuxième fois, le lancement prend moins de temps. SL et CM sont des applications web pures et s’exécutent sur le navigateur.

Référentiel de services d’entreprise

Ici, nous concevons et créons des objets à utiliser dans la réalisation d’un scénario d’intégration. Le flux de données dans PI ressemblera à ce qui est indiqué ci-dessous:

Nous trouvons la possibilité de concevoir les objets d’interface suivants

1. – Interface de Service, Type de Message, Type de Données
2. Objets de mappage – Mappage d’Opérations et Mappage de Messages
3. Processus d’intégration

PI utilise le référentiel d’intégration pour concevoir une structure de message pour les systèmes émetteur et récepteur et développer un message d’interface en utilisant des structures de message correspondantes qui agissent comme un point d’interaction avec le monde extérieur. Le type de données et le type de message sont utilisés pour simplifier et modulariser la conception d’une interface complexe.

Le mappage d’opérations permet de transformer la structure source en structure cible lorsque les deux structures sont différentes. Mais si la structure source et la structure cible sont identiques, le mappage d’opération peut être supprimé. Similaire à l’interface de service, le mappage de messages est utilisé pour simplifier et modulariser la conception d’un mappage d’opérations complexes. Le mappage de messages peut être implémenté de 4 manières

1. Mappage graphique
2. Mappage Java
3. Mappage XSLT
4. Mappage ABAP

Le mappage graphique est le plus utilisé car il permet au développeur de mapper graphiquement les attributs des deux structures pour transmettre des données à l’aide d’interfaces de service. Pour les trois autres, nous devons développer le mappage en écrivant du code. S’il s’agit d’un serveur à pile unique, le mappage ABAP ne sera pas disponible.

Il existe également d’autres domaines, mais ils ne sont pas couverts dans ce tutoriel.

Répertoire d’intégration

Ici, nous effectuons les étapes de la ligne de canalisation en configurant les objets ESR créés précédemment. Ces étapes sont exécutées par le moteur d’intégration pendant l’exécution.

Avant de commencer la configuration, nous devons créer /importer les objets suivants dans le RÉPERTOIRE.

1. Service – Système d’entreprise / Service d’entreprise / Processus d’intégration
2. Canal de communication

Un service vous permet d’adresser un expéditeur ou un destinataire de messages. Selon la façon dont vous souhaitez utiliser le service, vous pouvez choisir parmi les types de services suivants.

1. Système d’entreprise – Si vous souhaitez adresser un système d’entreprise particulier en tant qu’expéditeur ou destinataire de messages, choisissez ce type de service. Un système d’entreprise est un système d’application réel dans un paysage de système.
2. Service commercial – Si vous souhaitez adresser une entité commerciale abstraite en tant qu’expéditeur ou destinataire de messages, choisissez ce type de service. Un service métier n’est pas défini dans le paysage système.
3. Service de processus d’intégration – Si vous souhaitez traiter un processus d’intégration en tant qu’expéditeur ou destinataire de messages, choisissez ce type de service. Au moment de l’exécution, ces processus d’intégration sont contrôlés par des messages et peuvent eux-mêmes envoyer des messages.Le canal de communication

détermine le traitement entrant et sortant des messages. Les messages sont convertis du format natif au format de message spécifique soap-xml et vice-versa via l’adaptateur. Généralement, il existe deux types de canaux de communication dans un scénario

1. Canal de communication émetteur
2. Canal de communication récepteur

Vous devez attribuer un canal de communication à un service. Selon que le service est adressé en tant qu’émetteur ou récepteur de messages, le canal de communication attribué a le rôle d’émetteur ou de récepteur et doit être configuré en conséquence. Vous ne pouvez pas affecter un canal de communication à un service de processus d’intégration.

Les étapes de canalisation sont créées en créant les 4 configurations suivantes dans le répertoire

Nous trouvons les options suivantes:

1. Accord d’expéditeur
2. Détermination du récepteur
3. Détermination de l’interface
4. Accord de récepteur

Accord d’expéditeur définit comment le message d’un expéditeur doit être transformé afin qu’il puisse être traité par le Serveur d’intégration. Il se compose du

1. Composant expéditeur
2. Interface expéditeur
3. Canal de communication expéditeur

L’accord expéditeur est similaire à la clé primaire dans le tableau. Il ne peut pas y avoir deux accords d’expéditeur similaires dans un même paysage.

L’accord de réception définit comment le message doit être transformé afin qu’il puisse être traité par un récepteur. Il se compose de

1. Composant émetteur
2. Composant récepteur
3. Interface récepteur
4. Canal de communication récepteur

Vous utilisez une détermination de récepteur pour spécifier à quels récepteurs un message doit être envoyé. Vous avez la possibilité de définir des conditions pour transmettre le message aux destinataires. Il se compose de

1. Composant expéditeur
2. Interface expéditeur
3. Composant récepteur

La détermination du récepteur est de deux types – Standard ou étendue, selon que vous souhaitez spécifier le Récepteur manuellement ou dynamiquement par un mappage au moment de l’exécution.

Vous utilisez une détermination d’interface pour spécifier l’interface entrante d’un récepteur vers laquelle le message doit être transmis. Vous pouvez également spécifier quel mappage d’interface à partir du référentiel d’intégration doit être utilisé pour traiter le message, c’est-à-dire si l’émetteur et l’interface du récepteur ne sont pas du même format, il existe un mappage opérationnel pour changer le format. Vous définissez une détermination d’interface pour un expéditeur, une interface sortante et un récepteur. Il se compose de

1. Composant expéditeur
2. Interface expéditeur
3. Composant récepteur
4. Interface récepteur

La détermination de l’interface est de deux types – Standard ou améliorée, selon que vous souhaitez spécifier l’interface récepteur manuellement ou via une répartition des messages basée sur le mappage.

Détermination du récepteur et Détermination de l’interface – les deux ensembles sont communément appelés routage logique. Accord d’expéditeur et Accord de destinataire – les deux ensemble sont communément appelés Accord de collaboration.

Paysage système

Le répertoire Paysage système SAP (SLD) est le fournisseur d’informations central dans un paysage système. Dans la page web, vous trouverez les liens suivants:

1. Système technique – Les systèmes techniques sont des systèmes d’application installés dans le paysage de votre système.
2. Système d’entreprise – Les systèmes d’entreprise sont des systèmes logiques qui fonctionnent comme des expéditeurs ou des récepteurs au sein de PI. Business Systems a une dépendance individuelle avec le système technique associé.
3. Produits et composants – Il s’agit d’informations sur tous les produits et composants SAP disponibles, y compris leurs versions. S’il existe des produits tiers dans le paysage système, ils sont également enregistrés ici.

Le SLD ressemblera à ce qui est donné ci-dessous:

Figure 11 – Paysage du Système

Les Produits et composants sont communément appelés Informations sur les Composants

Le Système Technique et le Système d’entreprise sont communément appelés Description du paysage.

Un système d’entreprise peut être configuré en tant que serveur d’intégration ou système d’application.

1. Serveur d’intégration – Le serveur d’intégration exécute uniquement la logique d’intégration configurée dans le générateur d’intégration. Ils peuvent également être identifiés comme des étapes de canalisation. Il reçoit un message XML, détermine le récepteur, exécute les mappages et achemine le message XML vers les systèmes récepteurs correspondants. Ainsi, un Moteur d’Intégration configuré est identifié comme étant un Moteur d’Intégration Configuré Central.
2. Système d’application – Le système d’application n’exécute pas la logique d’intégration. Il appelle à son tour le serveur d’intégration pour exécuter la logique d’intégration si nécessaire. Il agit en tant qu’expéditeur ou destinataire de messages XML. Ainsi, le système d’application avec un moteur d’intégration local nécessite que le serveur d’intégration exécute la logique d’intégration.

Un seul client du système SAP peut être configuré en tant que serveur d’intégration.

Les informations suivantes sont extraites du SLD dans l’ESR et les informations de composant

1. sont utilisées dans l’ESR pour définir le Produit et le Système métier SWCV
2. sont utilisées dans le Répertoire pour définir l’expéditeur et le destinataire des messages

Configuration et surveillance

C’est le point d’entrée central à des fins de surveillance. Cela vous donne la possibilité de naviguer vers les fonctions de surveillance du Moteur d’intégration, ainsi que l’intégration avec le Système de gestion du Centre de calcul (CCMS) et l’Infrastructure de surveillance des processus (PMI) de SAP.

La configuration et la surveillance ressembleront à celles données ci-dessous:

Figure 13 – Configuration et surveillance

Avec la Configuration et la surveillance, les fonctions de surveillance suivantes sont prises en charge:

1. Surveillance des composants – surveillance des différents composants SAP PI (parties Java et ABAP).
2. Surveillance des messages – suivi de l’état de traitement des messages dans un composant SAP PI et lors de la détection et de l’analyse des erreurs.
3. Surveillance de bout en bout – surveillance du cycle de vie d’un message du point de vue SAP PI.
4. Surveillance de la performance – les statistiques sur les différents aspects de la performance de SAP PI sont accessibles via le RWB. Ici, vous pouvez sélectionner et agréger des données de performances, par exemple par composant, plage de temps ou attributs de message.
5. Administration de l’index – en administrant et en surveillant l’indexation des messages par composant SAP PI, vous activez une recherche de messages basée sur l’index que vous pouvez utiliser dans la surveillance des messages. Ce type de recherche de messages vous offre des critères de sélection améliorés, y compris des attributs de message spécifiques à l’adaptateur et des termes ou expressions de la charge utile du message.
6. Configuration des alertes – en utilisant le cadre d’alertes, une surveillance centrale dans PI peut être fournie avec toutes les erreurs signalées lors du traitement des messages dans ABAP et Java. Cela permet une réaction améliorée à de telles erreurs à la fois dans le runtime ABAP et dans le moteur d’adaptateur basé sur Java. A cet effet, le Cadre d’alerte est doté de règles basées sur certains événements et sur des informations provenant de l’en-tête du protocole de message PI. Ces règles déterminent si des alertes sont envoyées ou non. Si une alerte est envoyée, elle peut être utilisée pour l’analyse des erreurs.
7. Boîte de réception des alertes – la boîte de réception des alertes est spécifique à l’utilisateur et affiche toutes les alertes pour chaque serveur d’alertes qui a été généré en fonction de la configuration des alertes.
8. Surveillance du cache – la surveillance du cache affiche les objets qui se trouvent actuellement dans le cache d’exécution. Différents objets de cache sont surveillés en fonction de l’instance de cache concernée.

Communication synchrone vs asynchrone

Un processus peut être défini comme synchrone ou asynchrone.

• Un processus synchrone est appelé par une opération de requête/réponse, et le résultat du processus est immédiatement renvoyé à l’appelant via cette opération.
• Un processus asynchrone est appelé par une opération unidirectionnelle et le résultat et les défauts éventuels sont renvoyés en invoquant d’autres opérations unidirectionnelles. Le résultat est renvoyé à l’appelant via une opération de rappel.

Dans le monde informatique, il n’y a pas de communication asynchrone. Toute communication entre deux systèmes se fait toujours par appel de méthode (opération de demande / réponse). Alors, comment le rendre asynchrone? La réponse réside dans l’introduction d’un troisième système entre la fonction appelée et la fonction appelante.

Supposons qu’il existe deux systèmes – A et B. Toutes les communications entre A et B se font via un appel de méthode et sont donc synchrones. Nous introduisons un troisième système entre A et B et l’appelons le système intermédiaire -I. La communication entre A et I se fait par appel de méthode et de même entre I et B se fait également par appel de méthode. Mais la communication entre A et B peut être qualifiée d’asynchrone car A n’a pas à attendre la réponse de B.

C’est la base de la communication asynchrone et quel est ce système intermédiaire? C’est la file d’attente. A est appelé l’expéditeur et B est appelé le récepteur. Le message de A est d’abord ajouté à la file d’attente, puis il est à nouveau extrait de la file d’attente et envoyé à B. La réponse de B atteint A de la même manière. Dans certaines situations, l’exigence métier nécessite que les messages soient livrés à B dans le même ordre qu’ils sont déclenchés à partir de A. Dans ce cas, nous suivons une politique du premier entré et du premier sorti. S’il n’y a pas de telles exigences, les messages sont envoyés de la file d’attente à B dans n’importe quel ordre.

Avec la communication asynchrone, nous obtenons une livraison garantie, c’est-à-dire que le système B n’est pas disponible lorsque le système A envoie le message. Le message est ajouté à la file d’attente et y reste tant que B n’est pas disponible. Une fois que B est disponible, le message est extrait de la file d’attente et envoyé à B.

Afin que nous puissions classer notre communication de messages de trois manières:

1. Synchrone
2. Asynchrone avec l’ordre non maintenu
3. Asynchrone avec l’ordre maintenu

Dans PI, nous les identifions comme: Synchrone-BE (Meilleur effort), Asynchrone avec l’ordre non maintenu – EO (Exactement Une fois), Asynchrone avec l’ordre maintenu – EOIO (Exactement une fois dans l’Ordre).

Accusé de réception

Accusé de réception est la racine de la communication asynchrone. Pourquoi?

Pour une communication synchrone, le système A appelle le système B et si B ne parvient pas à envoyer la réponse, le processus a échoué. Mais dans une communication asynchrone, le Système A appelle le Système I et le Système I appelle le système B. Supposons donc que la communication entre A et I réussisse mais entre I et B, elle échoue. Comment A devrait-il se rendre compte que la livraison à B a échoué? Ceci est réalisé par un accusé de réception qui est renvoyé à A par B via la même route que le message de A pris à B. Si l’accusé de réception de B n’arrive pas à A, A considère que le processus a échoué et envoie à nouveau le message.

Alors que nous avons discuté de la communication asynchrone dans PI, nous avons utilisé le terme – « Exactement une fois » pour EO et EOIO. Exactement une fois signifie qu’un message livré une fois ne peut pas être remis à nouveau. Pour ce faire, il existe un accusé de réception pour chaque message envoyé de A à B. Ce sont les adaptateurs qui se trouvent à la fin de la communication. Les adaptateurs doivent donc prendre en charge l’accusé de réception.

Tous les adaptateurs fournissent un accusé de réception système i.e. accusé de réception de la livraison. Les adaptateurs qui prennent en charge la communication synchrone prennent en charge l’accusé de réception de l’application en plus de l’accusé de réception du système.

Ainsi, dans PI, voici le type d’accusé de réception

1. Accusé de réception système – Accusés de réception système utilisés par l’environnement d’exécution pour confirmer qu’un message asynchrone a atteint le récepteur.
2. Accusé de réception d’application – Accusés de réception d’application utilisés pour confirmer que le message asynchrone a été traité avec succès au niveau du récepteur.

Appel de fonction à distance

Lorsque vous travaillez dans PI, vous rencontrerez le terme -RFC. Quels sont-ils? Pour établir la communication entre deux systèmes SAP, c’est-à-dire un R/3 et un PI, nous créons la destination RFC. Il est configuré par le

1. Type de connexion
2. Adresse IP et port du récepteur

Type de connexion indique le type de connexion système, c’est-à-dire R/3, TCP / IP, Interne, etc.

La destination RFC que nous créons est classée en fonction du mode de communication requis, c’est-à-dire s’il doit prendre en charge la communication synchrone ou asynchrone.

1. pour communication synchrone – RFC synchrone
2. pour communication asynchrone avec ordre non maintenu – RFC transactionnel
3. pour communication asynchrone avec ordre maintenu – RFC en file d’attente

Ils sont identifiés par sRFC, tRFC et qRFC.

Études de cas – 1

Supposons que vous êtes dans une salle de classe et qu’il y a 10 étudiants. L’enseignant demande ensuite à chaque élève de préparer ses données personnelles suivantes et de les enregistrer dans un fichier XML. Les détails sont les suivants:

1. ID étudiant
2. Nom
3. Mobile
4. Email
5. Sexe

Il y aura 10 fichiers et les fichiers sont nommés cv_1, 2, 3….10. Les fichiers sont enregistrés dans le répertoire source. À des fins de test, les répertoires suivants sont créés :

Répertoire source : c:\ibm\sap\training\input

Répertoire d’archives: c:\ibm\sap\training\archive

Répertoire d’erreurs : c:\ibm\sap\training\error

Répertoire cible : c:\ibm\sap\training\target

Vous êtes invité à développer des scénarios dans SAP PI qui liront les fichiers source du répertoire source et les écriront dans le répertoire cible. Une fois qu’un fichier est lu avec succès à partir du répertoire source, il doit être déplacé vers le répertoire d’archive et si le fichier ne peut pas être lu pour une erreur, c’est-à-dire que le format XML n’est pas maintenu, il doit être déplacé vers le répertoire d’erreur. Les fichiers déplacés vers le répertoire archive, error ou target doivent avoir un horodatage ajouté au nom du fichier.

1. c.-à-d. nom du fichier +< horodatage >.

Leçon-1

Préparez un scénario pour lire un seul fichier, c’est-à-dire le fichier cv_1.xml à partir du répertoire source et écrivez-le dans le répertoire cible. Le nom du fichier cible doit également être cv_1.xml avec l’horodatage ajouté au nom.

Leçon-2

Préparez un scénario pour lire tous les fichiers du répertoire source et les écrire dans le répertoire cible. De même, les fichiers cibles doivent également être nommés cv_1,2..xml avec l’horodatage ajouté à chacun d’eux.

Leçon-3

L’instructeur vous demande ensuite d’ajouter la validation suivante aux données.

1. Le numéro de mobile doit avoir 10 chiffres numériques – si le numéro de mobile n’est pas de 10 chiffres, remplacez-le par ‘error’
2. L’e-mail doit avoir un caractère ‘@’ et un ‘.’caractère – si l’e-mail n’a pas le ‘@’ ou ‘.’ caractère, puis remplacez-le par ‘ erreur’

Avant d’exécuter le scénario, dans certains des fichiers source, modifiez le mobile et l’e-mail afin qu’ils soient en erreur selon la logique donnée ci-dessus.

Leçon-4

Préparez un scénario pour lire tous les fichiers source et les classer selon leur sexe. Les fichiers pour les hommes seront écrits dans un répertoire et pour les dames dans un autre répertoire. Deux répertoires sont créés dans le but ci-dessus :

Répertoire cible pour les hommes: c:\ibm\sap\training\target\men

Répertoire cible pour les femmes : c:\ibm \ sap \training\target\women

Supposons qu’il y ait 6 hommes et 4 femmes dans la classe, alors si tous les fichiers source sont lus avec succès, le répertoire cible pour les hommes devrait avoir 6 fichiers et le répertoire cible pour les femmes devrait avoir 4 fichiers.

Études de cas – 2

L’instructeur vous demande ensuite de préparer un seul dossier avec les données personnelles de chaque élève dans des segments distincts.

Leçon-5

Écrivez un scénario qui lira ce fichier et produira 10 fichiers cibles où chaque fichier doit correspondre aux données personnelles de chaque employé. Les fichiers cibles doivent être nommés cv_ < emp_ID > _ < horodatage >

Lesson-6

Modifiez le scénario ci-dessus afin qu’il produise 2 fichiers cibles au lieu de 10 où un fichier cible pour les hommes et un autre fichier cible pour les femmes. Le fichier cible pour les hommes doit avoir 6 segments pour 6 hommes et le fichier cible pour les femmes doit avoir 4 segments pour 4 femmes.

Les fichiers cibles doivent être nommés comme

Pour men–men_ < horodatage >

Pour Ladies-women_ < time_stamp >

Étude de cas-3

Identique à l’étude de cas–1, l’instructeur demande à chaque élève de préparer son/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses/ses ses données personnelles et les enregistrer dans un fichier XML. Il y aura 10 fichiers. Les fichiers sont enregistrés dans le répertoire source.

Leçon-7

Préparez un scénario pour lire tous les fichiers source du répertoire source et créer un seul fichier dans le répertoire cible. Le nom du fichier cible sera affiché.xml avec l’horodatage ajouté au nom du fichier. Le fichier cible aura tous les détails de chaque fichier source en tant que sous-segment.

Leçon- 8

Préparez un scénario pour lire l’intégralité des fichiers source du répertoire source et créez deux fichiers dans le répertoire cible – l’un pour les hommes et l’autre pour les femmes. Pour 6 hommes, le fichier des hommes doit comporter six segments ayant les détails de chaque homme et pour 4 femmes, de même, il doit y avoir 4 segments avec les détails de chaque femme.

Étude de cas – 4

L’instructeur demande maintenant à chacun des étudiants de préparer un autre ensemble de détails qui consisteront en ses détails académiques suivants:

1. ID étudiant
2. Nom de l’école
3. Nom du collège
4. Nom du département
5. Année d’admission

Il y aura 10 fichiers et les fichiers sont nommés ad_1, 2, 3….10. Les fichiers sont enregistrés dans le répertoire source. Ainsi, chaque étudiant aura maintenant une paire de fichiers – l’un pour les détails personnels et l’autre pour les détails académiques. Deux fichiers sont co-liés avec la carte d’étudiant. Le répertoire d’entrée se compose désormais de 10 fichiers personnels et de 10 fichiers académiques.

Leçon–9

Vous êtes invité à développer un scénario qui sélectionnera les fichiers source et les traitera par paires. Le scénario générera 10 fichiers cibles. Chaque fichier cible comprendra les détails personnels et académiques d’un étudiant dans des segments distincts. Les fichiers cibles seront nommés res_1, 2, 10.

Les fichiers cibles ressembleront à:

Leçon–10

Il vous est ensuite demandé de modifier l’identifiant de l’étudiant dans certains fichiers afin qu’ils n’aient pas de fichiers académiques ou personnels correspondants et vice-versa. Le scénario devrait s’exécuter et s’il trouve des fichiers qui n’ont pas de fichier correspondant correspondant, le processus devrait se terminer après un certain temps, c’est-à-dire 2 min et ces fichiers seront déplacés dans le répertoire d’erreur et il n’y aura pas de fichiers cibles correspondants pour eux.