Cela fait un certain temps que j’ai mis en œuvre mon premier scénario événementiel dans SAP Business One. Depuis que j’ai commencé, j’ai rencontré un « océan » de possibilités/plateformes/services qui offrent à peu près la même approche sur la façon d’y parvenir, chacun ayant ses propres avantages et inconvénients.

Il ne fait aucun doute que l’industrie est bien développée et peut offrir de nombreuses façons de faire les choses, et je suis un peu « trop zélé » lorsqu’il s’agit d’apprendre les nouvelles technologies (après tout, c’est notre pain et notre beurre). Mais lorsque je m’assois pour rédiger un projet, j’essaie de m’en tenir à l’approche du « guichet unique », en optant pour la réutilisation des outils et des services intégrés dans l’application B1 elle-même, ce qui serait probablement en tête de ma liste.

Ces outils existent depuis lors et ont évolué au fil des ans. Non seulement ils n’ont pas été dépréciés, mais leurs capacités et leurs performances se sont accrues.

Ne vous méprenez pas, je pense que la plateforme SAP BTP, par exemple, offre des possibilités infinies lorsqu’il s’agit de consommer des services Web REST qui peuvent interagir avec nos systèmes SAP et permet également de réutiliser certains des connecteurs les plus puissants pour s’intégrer à d’autres systèmes SAP / non SAP, ainsi que pour étendre nos applications et processus d’entreprise. Le BTP SAP utilise également des services de pointe tels que les outils AI Builders et Fiori Apps. L’ objectif n’est donc pas de dénigrer le SAP BTP, qui a légitimement mérité sa place, mais simplement d’affirmer que le SAP BTP n’est pas le seul jeu en ville.

Néanmoins, ceux d’entre vous qui ont essayé de naviguer dans cet océan de données exposées sur la plateforme SAP BTP se sont probablement rendu compte que la BTP est très orientée S4/HANA et n’est pas spécifiquement conçue pour les développeurs SAP Business One.

De plus, le BTP présente des lacunes évidentes :

1. Installation longue et fastidieuse – l’ajout d’un abonnement, d’une instance ou d’un élément constitutif vous fera perdre du temps et, dans la plupart des cas, vous n’y parviendrez pas du premier coup.
2. Les niveaux de prix ne sont tout simplement pas adaptés aux PME. Tant que vous utilisez l’abonnement « gratuit » pour des environnements non productifs, tout devrait bien se passer, mais une fois que vous passez aux niveaux d’abonnement « Pay-As-You-Go » et que vous passez à la production, dans la plupart des cas, cela deviendrait une « surcharge » pour tout projet basé sur une PME et également assez coûteux.
3. Il n’a pas de conscience intégrée des objets B1. Nous pouvons l’utiliser et l’appeler comme nous le ferions avec n’importe quelle autre API pour la rendre « consciente » de ce que nous cherchons à obtenir.

Entrons donc dans le vif du sujet : comment mettre en œuvre un scénario de transfert d’événements et utiliser les informations obtenues pour déclencher/construire d’autres solutions liées à la catégorie B1 sans compliquer les choses à l’excès ?

En règle générale, nous devrions procéder comme suit :

1. Mise en place d’une instance SAP Event Mesh sur BTP
2. Disposer d’une application SAP CAP pour gérer les événements dans BTP (généralement utilisée pour la création d’entreprises)
   d’entreprise
   -d’entreprise, ce qui, une fois de plus, revient à « se battre pour la clôture » lorsqu’il s’agit de SAP B1).
3. Nous devrions coder une étape auxiliaire pour récupérer le jeton afin de nous authentifier auprès de l’instance SAP Event Mesh sur la plateforme SAP BTP.

La vue d’ensemble de l’architecture ressemblerait à ce qui suit :

Et si je vous disais que nous pouvons sauter la partie où nous nous abonnons au BTP et aller directement à notre cadre d’intégration B1 (B1If) pour consommer ces événements et les utiliser pour étendre le comportement de notre application B1 à l’aide de Microsoft Azure ?

En supposant que le B1iF soit installé et configuré correctement dans votre environnement, vous avez pris un bon départ.

Je vous conseille vivement d’envisager de prendre les mesures suivantes afin de vous assurer que vous remplissez toutes les conditions préalables :

• Mise en place de l’environnement de développement B1iF.
• Comprendre les bases de B1iF et l’aperçu technique.
• Mise en place de la configuration SLD de votre entreprise.
• Configurer la connectivité à la couche de service B1 (nous ne voulons pas nous fier uniquement à l’API DI, qui est l' »ancienne génération » de l’API d’extension pour consommer les données et les services de SAP Business One).

** Si vous rencontrez des problèmes lors de la configuration du B1iF, n’hésitez pas à me contacter et je me ferai un plaisir de vous guider et de vous aider**.

Enfin, nous souhaitons configurer notre émetteur d’événements B1iF pour qu’il commence à déclencher des événements.

Les meilleures pratiques de la B1iF exigent que nous respections ce qui suit :

1) Assurez-vous d’accéder au Integration Framework 2.0 au lieu de 1.0 :

Cela présente plusieurs avantages importants :

• En plus du cadre d’intégration, tous les modèles de programmation peuvent être exécutés simultanément en parallèle.
• Optimisé pour l’informatique en nuage
• Multi-tenance intégrée – Plus de flexibilité dans les déploiements de scénarios
• Conçu pour répondre aux besoins de tous les développeurs d’intégration
  • Une plus grande flexibilité
  • Plus de contrôle et de transparence dans le développement du contenu de l’intégration
• Les développeurs « classiques » se sentent plus à l’aise grâce au nouvel IDE basé sur un navigateur.
• Jusqu’à 10 fois plus rapide – s’exécute directement au-dessus de la plate-forme d’intégration
• Ne remplace pas le modèle de programmation actuel La migration des paquets de scénarios existants n’est pas nécessaire, à moins que vous ne souhaitiez utiliser la multi-location dans les environnements en nuage.

2. Vérifiez que toutes les connexions SLD sont correctes :

Si l’une de ces connexions est rompue, le processus est compromis et la communication avec le serveur HANA / la couche de service est interdite par la suite. Il convient donc de s’assurer que toutes les connexions sont claires et, si ce n’est pas le cas, de reconfigurer les chaînes de connexion.

3) Assurez-vous de filtrer les événements B1i en naviguant vers Maintenance -> B1 Event Filter et en cochant la case « B1i User Filter Switched On » – cela vous permettra de vous débarrasser de tous les événements du système que vous ne souhaitez pas écouter.

Notez que vous pouvez également inclure cette configuration dans la version 1.X en y accédant directement à partir de la version 2.0 (sous Outils ->Version 1) et en naviguant jusqu’à l’Assistant d’envoi d’événements.

C’est ici que vous voudrez également inclure vos ID d’objets B1 pour tous les objets pour lesquels vous souhaitez obtenir des événements.

Vous trouverez la liste complète des objets B1 à la fin de ce fil de discussion.

Vous pouvez également récupérer cette valeur directement à partir de l’application B1 en lançant le générateur de requêtes et en sélectionnant la colonne « <table_name> ». ». ObjType »:

4) L’étape la plus importante est de tester que VOS événements ne sont PAS filtrés mais plutôt relayés au moniteur d’événements B1 lors du déclenchement de votre scénario.

Dans mon cas, j’ai simplement créé un partenaire et actualisé l’affichage pour voir que B1iF était en mesure de capturer l’événement :

Note : L’exécution du test ne sera réussie que si vous vous assurez d’ajouter un nouveau déploiement au « Panneau de déploiement » de votre scénario et d’assigner un système d’expéditeur/récepteur valide à partir de votre SLD – ce panneau est la nouvelle (et cool !) fonctionnalité de la version 2.0 qui vous permet d’avoir une vue d’ensemble unique de tous les artefacts de votre scénario.

Une fois que nous avons la certitude que notre émetteur d’événements traite correctement nos événements, nous pouvons poursuivre la construction de notre scénario dans BizFlow.

Il est important de bien comprendre ce que nous essayons de faire ici :

Nous voulons simplement que B1iF transmette chaque événement qui répond à nos critères de filtrage à un flux de travail externe basé sur un crochet Web HTTP sous la forme d’une charge utile XML à partir de laquelle nous pouvons ensuite analyser et extraire des données.

C’est tout ce qu’il y a à faire !

Si vous vous demandez « Pourquoi ? », la réponse est assez simple :

Avec
Azure Logic Apps
et le connecteur HTTP Webhook intégré, nous pouvons créer des tâches et des flux de travail automatisés qui s’abonnent à un point de terminaison de service en enregistrant une URL de rappel, attendent des événements spécifiques et s’exécutent en fonction de ces événements, plutôt que de vérifier ou d’interroger régulièrement ce point de terminaison.

Ceci est particulièrement utile et bénéfique dans les cas où les PaaS (Platforms as a Service) comme Microsoft-Azure vous facturent par exécution.

Imaginez le nombre d’exécutions déclenchées dans un délai de 24 heures lorsqu’un flux de travail est programmé pour s’exécuter toutes les 15 minutes (96 exécutions), contre 3 exécutions pour les 3 nouveaux partenaires commerciaux que vous avez créés lorsque le flux de travail est programmé pour s’exécuter toutes les 15 minutes (96 exécutions). seulement déclenchée juste après l’ajout de l’enregistrement du partenaire dans la base de données B1.

Cela a un impact direct sur la consommation et, par conséquent, sur le montant qui vous sera facturé à la fin du mois.

Ceci dit, je couvrirai le côté Logic App de notre projet dans la prochaine partie de ce blog.

Commençons par finaliser notre scénario et les étapes du scénario.

Notre diagramme BizFlow sera relativement simple :

Nous examinons un mode de processus « asynchrone » typique dans lequel l’événement est déclenché, récupéré puis relayé vers l’atome entrant, où il est ensuite transformé via un atome XSLT pour être utilisé dans notre atome HTTPCall.

Gardez à l’esprit que B1iF traite toujours les données en interne au format XML. Dans notre cas, nous souhaitons simplement récupérer la représentation XML de notre événement à partir du système émetteur (Event Sender) et l’utiliser comme partie de notre corps d’appel HTTP.

Une bonne façon d’analyser la structure des messages pendant l’exécution est d’utiliser le débogueur B1iF :

Notre transformation XSL Atom devra seulement être ajustée pour récupérer la charge utile XML entrante de l’événement B1, où une expression XPATH sera alors ajoutée à notre HTTPCall Atom.

Nous reviendrons sur notre HttpCall Atom après avoir conclu notre discussion sur la Logic App (WebHook) dans la partie 2 de ce blog.

Résumons ce que nous avons accompli jusqu’à présent :

1. Nous avons présenté notre sujet principal – Création et transmission d’événements dans SAP Business One
2. Nous avons abordé quelques-unes des méthodes les plus courantes pour gérer les événements, tout en soulignant les avantages et les inconvénients de chaque approche.
3. Nous avons passé en revue certains des paramètres et configurations de base de SAP Business One Integration Framework.
4. Nous avons couvert les nouvelles améliorations de la version 2.0 de B1iF
5. Nous avons eu un aperçu détaillé de la configuration de l’émetteur d’événements et avons appris comment définir des critères de filtrage pour les objets B1 pour lesquels nous souhaitons obtenir des événements.
6. Nous avons appris à déployer un développement via le « panneau de déploiement » de notre scénario et à assigner un système d’émetteur/récepteur SLD.
7. Nous avons discuté des crochets Web HTTP et compris comment ils jouent un rôle important dans la réduction du nombre d’exécutions de flux de travail qui affecteront finalement notre facturation.
8. Nous avons parcouru les différentes étapes du scénario pour recevoir un message entrant (événement), le traiter et le transformer, puis le préparer pour le HTTPCall Atom.

Rejoignez-nous sur la page Blog de la communauté SAP Business One pour la deuxième partie de la mise en œuvre d’un mécanisme de transmission d’événements à l’aide de SAP Business One B1iF et de Microsoft Azure.

Liste des types d’objets SAP Business One