Maintenant que nous avons couvert la phase de traitement des événements et que nous avons passé en revue tous les concepts de base liés à la mise en place du système B1iF pour « superviser » correctement ces événements pour nous, passons à la partie la plus intrigante de notre projet – recevoir la charge utile sortante (XML) envoyée avec l’Atom HTTPCall et invoquer notre WebHook qui déclenche alors notre flux de travail.
Je suppose que vous avez déjà un abonnement Azure actif ; si ce n’est pas le cas, il est grand temps de vous en procurer un.
Étapes du flux de travail de l’application logique :
Etape 1) Notre Logic App doit avoir un déclencheur – Dans notre cas, ce sera le connecteur « Quand une requête HTTP est reçue » :
Rappelez-vous, tout ce que nous voulons, c’est nous abonner à un point de terminaison de service en enregistrant une
URL de rappel.
TCette URL sera générée une fois que la Logic App sera sauvegardée pour la première fois, et elle sera
unique
à ce flux de travail.
Étape 2) Si vous vous souvenez, l’Atom HTTPCall sur B1iF consiste à appeler notre flux de travail (en utilisant l’URL de rappel ci-dessus ) en envoyant un corps XML, de sorte que nous utiliserions l’expression « triggerBody() » pour récupérer ce que notre déclencheur doit livrer.
Mais ce n’est pas suffisant, car nous voulons convertir le corps XML entrant en une structure plus « légère » avec laquelle nous pouvons facilement travailler – JSON (JavaScript Object Notation).
En fait, B1iF maintient ses propres schémas de transformation XSL pour pratiquement tous les types de sortie requis par le système récepteur, de sorte que nous pouvons nous assurer d’effectuer cette conversion avant même de transmettre la charge utile à l’atome final sortant.
Cela impliquerait des étapes supplémentaires pour préparer la sortie afin que notre WebHook obtienne un corps JSON au lieu d’un corps XML. Pour simplifier les choses, j’ai décidé d’utiliser une méthode plus rapide et d’effectuer la conversion à partir de l’application Logic elle-même.
- Si vous souhaitez en savoir plus sur les schémas de transformation XSL, allez à la version 1.X de votre B1iF, naviguez vers
Aide ->
Documents
et cherchez « Schemas ». Je pourrais éventuellement écrire un blog ultérieur sur la façon de gérer les différents types de schémas lors des transformations XSL.
Ainsi, notre 2e étape du flux de travail impliquerait une action « Compose » qui convertit le corps en un élément JSON :
Étape 3) SI nous devions exécuter le flux de travail jusqu’à sa deuxième action, nous obtiendrions le résultat suivant :
Nous pouvons clairement constater que la valeur que nous cherchons à obtenir (le code du nouveau partenaire commercial, vous vous souvenez ? ) se « cache » dans l’objet JSON nouvellement créé, et nous devons l’extraire de là
Étape 4) Nous allons ensuite créer une deuxième action « Compose » et utiliser l’expression « Outputs() » pour naviguer dans notre JSON :
Cette action récupère le code BP et stocke sa valeur.
Il peut très bien s’agir d’une commande client avec des articles, d’une facture ou d’un nouvel article créé/mise à jour – cela dépend vraiment de votre scénario d’entreprise.
L’important est que vous puissiez maintenant le conserver et l’utiliser pour faire ce qui est nécessaire en fonction de vos besoins :
- Vous pouvez déclencher un processus d’approbation
- Vous pouvez générer une commande sur la base d’une commande client.
- Vous pouvez envoyer un devis à un client pour un article nouvellement créé.
Tout cela pourrait être réalisé en utilisant la couche de service de SAP Business One à partir de l’application logique.
L’action finale, dans mon cas, consisterait à m’envoyer un courriel en utilisant la fonction «
Envoyer un email (V2) »
et d’utiliser les résultats de l’action « Composer » comme corps de l’e-mail :
Notre flux final ressemblera à ce qui suit :
Vient ensuite l’Email lui-même :
Une fois de plus, nous devons sauvegarder notre Logic App pour que l’URL de rappel soit générée :
Une fois que nous avons copié l’URL, nous pouvons retourner à B1iF et terminer les choses – nous décomposerons l’URL dans les champs suivants :
- destProtocol- https
- destHost- notre nom d’hôte Azure
- destPort- 443
- destPath- la chaîne URL restante
- Méthode – Il s’agit généralement d’une méthode « POST » pour ce scénario.
Remarques finales :
Bien que notre scénario ne soit pas trop complexe, nous avons pu avoir un aperçu de la manière dont les événements intégrés de SAP Business One peuvent être récupérés puis utilisés pour déclencher d’autres flux d’activités à l’aide du cadre d’intégration et de la technologie sans serveur comme les flux de travail Azure Logic Apps.
Les avantages immédiats que nous en retirons sont les suivants :
- Réduction du DevOps
- Une mise sur le marché plus rapide (= un client plus heureux tout en nous aidant à mieux gérer nos propres ressources internes).
- Réduction des coûts
Azure Logic Apps nous accompagne depuis un certain temps maintenant, mais avec la version actuelle, il n’y a pratiquement rien qui ne puisse être réalisé lors de la construction d’une intégration à notre ERP et de la gestion de nos API.
Le fait que nous puissions sauter le processus relativement long (fastidieux et également assez coûteux) d’abonnement à la plateforme SAP BTP et de configuration de l’Event Mesh/Grid pour travailler avec elle nous ouvre une vaste fenêtre d’opportunité pour lancer des flux de travail commerciaux qui sont uniquement basés sur des événements réels provenant de notre propre ERP, en temps réel, plutôt que de manière répétée. l’interrogation et la vérification de nos nos points d’accès pour voir si nous avons des données avec lesquelles travailler.
Laisser un commentaire
Vous devez être identifié pour poster un commentaire.