BPEL - Guide rapide

La SOA ou l'architecture orientée services est une approche architecturale qui utilise la technologie pour présenter les processus métier comme des services réutilisables.

  • Il se concentre sur l'entreprise et permet la transformation des processus vers de nouveaux niveaux d'intégration, de visualisation, de surveillance et d'optimisation.

  • Ce n'est pas une technologie, c'est un concept et une stratégie d'utilisation des technologies pour créer des solutions d'automatisation d'entreprise.

Nous allons maintenant voir ce qu'est BPEL et comment il aide dans la SOA.

Qu'est-ce que BPEL?

Business Process Engineering Language est une technologie utilisée pour créer des programmes en architecture SOA.

Ajout d'un composant de service de processus BPEL

Suivez ces étapes pour ajouter un composant de service de processus BPEL -

  • Dans le navigateur d'application, sélectionnez Fichier> Nouveau> Applications> Application SOA.

  • Cela démarre l'assistant de création d'application SOA.

  • Dans la boîte de dialogue Nom de l'application, saisissez un nom d'application dans le champ Nom de l'application.

  • Dans le champ Répertoire, saisissez un chemin de répertoire dans lequel créer l'application composite SOA et le projet.

  • Cliquez sur Suivant.

  • Dans la boîte de dialogue Nom du projet, entrez un nom dans le champ Nom du projet.

  • Cliquez sur Suivant.

  • Dans la boîte de dialogue Paramètres SOA du projet, sélectionnez Composite avec le processus BPEL.

  • Cliquez sur Terminer.

Fichiers dans le composite BPEL

Le composite BPEL contient les fichiers suivants -

  • composite.xml - Ce fichier décrit l'ensemble de l'assemblage composite des services, des composants de service, des références et des fils.

  • .bpel - Ce fichier contient l'ensemble des activités ajoutées au processus.

  • .componentType - Ce fichier décrit les services et les références du composant de service de processus BPEL.

  • .wsdl - Ce fichier définit les messages d'entrée et de sortie pour ce flux de processus BPEL, l'interface client et les opérations prises en charge, ainsi que d'autres fonctionnalités.

Concepts utilisés dans le processus BPL

Dans cette section, nous allons apprendre les différents concepts impliqués dans le processus BPL.

Orchestration

    Habituellement utilisé dans les processus commerciaux privés.

  • Un processus central (qui peut être un autre service Web) prend le contrôle des services Web impliqués.

  • Coordonne l'exécution des différentes opérations sur les services Web impliqués dans l'opération.

  • Les services Web impliqués ne «savent» pas (et n'ont pas besoin de savoir) qu'ils sont impliqués dans un processus de composition et qu'ils participent à un processus métier de plus haut niveau.

  • Seul le coordinateur central de l'orchestration est conscient de cet objectif, donc l'orchestration est centralisée avec des définitions explicites des opérations et de l'ordre d'appel des services Web.

Chorégraphie

  • Ne compte pas sur un coordinateur central.

  • Chaque service Web impliqué dans la chorégraphie sait exactement quand exécuter ses opérations et avec qui interagir.

  • Chaque service Web impliqué dans la chorégraphie sait exactement quand exécuter ses opérations et avec qui interagir.

  • Tous les participants à la chorégraphie doivent être conscients du processus métier, des opérations à exécuter, des messages à échanger et du calendrier des échanges de messages.

Dans ce chapitre, nous allons découvrir les différentes activités qui composent les blocs de construction Les blocs de construction d'un composant de service de processus BPEL.

Oracle BPEL Designer inclut un ensemble d'activités que vous faites glisser dans un composant de service de processus BPEL et double-cliquez sur une activité pour définir ses attributs et ses valeurs de propriété.

Attribuer une activité

 Une activité d'affectation permet de manipuler des données, comme la copie du contenu d'une variable dans une autre.

Invoquer une activité

 Une activité d'appel vous permet d'appeler un service (identifié par son lien partenaire) et de spécifier une opération que ce service doit effectuer.

Recevoir l'activité

  Une activité de réception attend un message de réponse de rappel asynchrone d'un service.

Apprenons-en plus sur l'activité Invoke dans notre section suivante.

Invoquer une activité

L'activité d'appel permet de spécifier une opération à appeler pour le service (identifiée par son lien partenaire). L'opération peut être unidirectionnelle ou demande-réponse sur un port fourni par le service. Les variables peuvent être créées automatiquement dans une activité d'appel. Une activité d'appel appelle un service synchrone ou lance un service Web asynchrone.

L'activité d'appel ouvre un port dans le processus d'envoi et de réception de données. Ce port peut en outre être utilisé pour soumettre les données requises et recevoir une réponse. Pour les rappels synchrones, un seul port est nécessaire pour les fonctions d'envoi et de réception.

Les liens partenaires sont définis comme des échanges de communication entre toutes les parties avec lesquelles le processus BPEL interagit.

Ce sont les références aux implémentations réelles, à travers lesquelles le processus BPEL interagit avec le monde extérieur.

Liens partenaires invoqués

Ce sont des liens vers des services qui sont appelés par le processus BPEL.

Liens client-partenaire

Ce sont des liens vers des services qui peuvent appeler un processus BPEL.

Propriétés du lien partenaire

L'Editeur de propriétés de lien partenaire vous permet d'établir des liens partenaires pour vos processus BPEL. Avec l'éditeur de propriétés de lien partenaire, vous pouvez spécifier les éléments suivants:

  • Name - Spécifie le nom de l'élément Invoke.

  • WSDL File - Indique le fichier WSDL associé au lien partenaire.

  • Partner Link Type - Indique le type de lien partenaire défini dans le WSDL.

  • My Role - Indique le rôle du processus métier lui-même.

  • Partner Pole - Indique le rôle du partenaire.

  • Documentation - Consulté dans la fenêtre Propriétés.

Les liens partenaires sont définis dans le fichier .bpel.

Un BPEL peut interagir avec les services des trois manières suivantes:

  • Services qui invoquent un processus BPEL
  • Services appelés par le processus BPEL
  • Des services qui agissent dans les deux sens

Dans ce chapitre, nous allons apprendre à créer un lien partenaire.

Suivez les étapes ci-dessous pour créer un lien partenaire -

  • Dans l'éditeur composite SOA, double-cliquez sur le composant de service de processus BPEL.

  • En cliquant sur le composant de service, Oracle BPEL Designer s'affiche.

  • Dans la palette de composants, développez Services BPEL.

  • Faites glisser un lien de partenaire dans le couloir de liens de partenaire approprié.

  • Remplissez les champs de cette boîte de dialogue comme indiqué ci-dessus dans les propriétés du lien partenaire.

Les adaptateurs permettent d'intégrer le composant de service de processus BPEL avec l'accès aux systèmes de fichiers, aux serveurs FTP, aux tables de base de données, aux files d'attente de base de données, aux sockets, aux services de messagerie Java (JMS), à MQ et à Oracle E-Business Suite. Cet assistant permet de configurer les types d'adaptateurs indiqués dans la figure ci-dessous pour une utilisation avec le composant de service de processus BPEL -

Types d'adaptateur

L'image suivante montre les différents types d'adaptateur -

Mise en file d'attente avancée (AQ)

Pour une interaction avec une file d'attente. AQ fournit un mécanisme flexible pour la communication bidirectionnelle et asynchrone entre les applications participantes.

Oracle Business Activity Monitoring (BAM)

Pour publier des données sur des objets de données dans un serveur Oracle BAM.

Base de données

Pour l'interaction avec les bases de données Oracle et non-Oracle via JDBC et Oracle Business Intelligence (qui est un type de source de données spécial).

FTP et fichier

Pour l'échange de fichiers (lecture et écriture) sur les systèmes de fichiers locaux et distants (via l'utilisation du protocole de transfert de fichiers (FTP)).

Service de messagerie Java (JMS)

Pour l'interaction avec JMS. L'architecture JMS utilise une interface client unique vers plusieurs architectures de serveurs de messagerie.

File d'attente de messages (MQ)

Pour l'échange de messages avec les systèmes de mise en file d'attente WebSphere MQ.

Applications Oracle

Pour l'interaction avec l'ensemble d'applications métier intégrées d'Oracle Application.

Oracle B2B

Pour parcourir les métadonnées B2B dans le référentiel du service de métadonnées (MDS) et sélectionner les définitions de document.

Douilles

Pour la modélisation de protocoles standard ou non standard pour la communication via des sockets TCP / IP.

Nom du service de l'adaptateur

La fenêtre Nom du service vous invite à saisir un nom lorsque le type d'adaptateur est sélectionné dans la palette. Pour cet exemple,File Adaptera été choisi. Une fois l'assistant terminé, un fichier WSDL portant ce nom de service apparaît dans le navigateur d'application pour le composant de service de processus BPEL (pour cet exemple, nomméReadFile.wsdl). Le nom du service doit être unique dans le projet. Ce fichier de configuration comprend les paramètres de configuration de l'adaptateur spécifiés avec cet assistant. D'autres fichiers de configuration (tels que les fichiers d'en-tête et les fichiers spécifiques à l'adaptateur) sont également créés. Ces fichiers sont affichés dans le navigateur d'application.

Les moniteurs de processus BPEL dans Oracle BPEL Designer peuvent être configurés en sélectionnant Surveiller en haut d'Oracle BPEL Designer.

À ce stade, l'adaptateur Oracle BAM doit être configuré.

Le processus BPEL client envoie un message au processus BPEL de service et le processus BPEL de service n'est pas obligé de répondre comme indiqué dans la figure ci-dessous -

  • Le processus BPEL client a besoin d'un lien partenaire valide et d'une activité d'appel.

  • Le processus BPEL de service a besoin d'une activité de réception.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction. Le fichier WSDL est comme indiqué ci-dessous.

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Le processus BPEL client envoie une demande au processus BPEL de service (d1 dans la figure ci-dessous) et reçoit une réponse immédiate (d2 dans la figure ci-dessous). Par exemple, un utilisateur demande un abonnement à un formulaire de demande en ligne pour l'admission à un collège et reçoit immédiatement une confirmation par courrier électronique que sa demande a été acceptée.

  • Le processus BPEL client a besoin d'une activité d'appel. Le port côté client envoie la demande et reçoit la réponse.

  • Le processus BPEL de service a besoin d'une activité de réception pour accepter la demande entrante et d'une activité de réponse pour renvoyer soit les informations demandées, soit un message d'erreur (une erreur; f1 dans la figure ci-dessous) défini dans le WSDL.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction. Le fichier WSDL est comme indiqué ci-dessous.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage" />
      <wsdl:output message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Le processus BPEL client envoie une demande au processus BPEL de service (d1 dans la figure ci-dessous) et attend que le service réponde (d2 dans la figure ci-dessous).

Par exemple, un utilisateur demande un abonnement à un formulaire de candidature en ligne pour l'admission dans un collège et la demande ne peut être confirmée que si elle est acceptée au bureau d'admission.

  • Le processus BPEL client a besoin d'une activité d'appel pour envoyer la demande et d'une activité de réception pour recevoir la réponse.

  • Le processus BPEL de service a besoin d'une activité de réception pour accepter la demande entrante et d'une activité d'appel pour renvoyer les informations demandées ou une erreur.

    Note - La différence entre la réponse à partir d'un processus BPEL synchrone et asynchrone est que le service synchrone utilise une activité de réponse pour répondre au client et un service asynchrone utilise une activité d'appel.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction. Le fichier WSDL est comme indiqué ci-dessous.

WSDL File

<wsdl:portType name = "BPELProcess">
   <wsdl:operation name = "process">
      <wsdl:input message = "client:BPELProcessRequestMessage"/>
   </wsdl:operation>
</wsdl:portType>

<wsdl:portType name = "BPELProcessCallback">
   <wsdl:operation name = "processResponse">
      <wsdl:input message = "client:BPELProcessResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

Le processus BPEL client envoie une demande au processus BPEL de service (d1 dans la figure ci-dessous) et attend jusqu'à ce que le service réponde ou jusqu'à ce qu'un certain délai soit atteint, selon la première éventualité. (d2 dans la figure ci-dessous).

Par exemple, un utilisateur demande un abonnement à un formulaire de demande en ligne pour l'admission à un collège et la demande est annulée si l'utilisateur ne reçoit pas de réponse de confirmation dans un délai spécifié.

Le processus BPEL client a besoin d'une activité d'appel pour envoyer la demande et d'une activité de prélèvement avec deux branches - un onMessage branche et un onAlarmbranche. Si la réponse arrive après l'expiration du délai, le message est placé dans la file d'attente des lettres mortes.

Le processus BPEL de service a besoin d'une activité de réception pour accepter la demande entrante et d'une activité d'appel pour renvoyer les informations demandées ou une erreur.

Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Dans ce chapitre, nous allons découvrir les interactions asynchrones avec un minuteur de notification. Considérez les points suivants liés aux interactions asynchrones -

  • Le processus BPEL client envoie une demande au processus BPEL de service et attend une réponse, bien qu'une notification soit envoyée après l'expiration d'un temporisateur.

  • Le processus BPEL client continue d'attendre la réponse du processus BPEL de service même après l'expiration du temporisateur.

  • Le processus BPEL client a besoin d'une activité d'étendue contenant une activité d'appel pour envoyer la demande et une activité de réception pour accepter la réponse. leonAlarm Le gestionnaire de l'activité d'étendue a une limite de temps et des instructions sur ce qu'il faut faire lorsque le minuteur expire.

  • Par exemple, attendez 60 secondes, puis envoyez un avertissement indiquant que le processus prend plus de temps que prévu.

  • Le processus BPEL de service a besoin d'une activité de réception pour accepter la demande entrante et d'une activité d'appel pour renvoyer les informations demandées ou une erreur.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Dans ce chapitre, nous en apprendrons davantage sur le concept d'une demande et de réponses multiples.

  • Le processus BPEL client envoie une seule demande au processus BPEL de service et reçoit plusieurs réponses en retour.

    Par exemple, la demande peut être de commander un produit en ligne, et la première réponse peut être le délai de livraison estimé, la deuxième réponse une confirmation de paiement et la troisième réponse une notification que le produit a été expédié. Dans cet exemple, le nombre et les types de réponses sont attendus.

  • Le processus BPEL client a besoin d'une activité d'appel pour envoyer la demande et d'une activité de séquence avec trois activités de réception.

  • Le processus BPEL de service a besoin d'une activité de réception pour accepter le message du client et d'un attribut de séquence avec trois activités d'appel, une pour chaque réponse.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Dans ce chapitre, nous allons découvrir le concept d'une demande et l'une des deux réponses possibles.

  • Le processus BPEL client envoie une seule demande au processus BPEL de service et reçoit l'une des deux réponses possibles.

    Par exemple, la demande peut être de commander un produit en ligne, et la première réponse peut être soit un message en stock, soit un message de rupture de stock.

  • Le processus BPEL client a besoin des éléments suivants:

    • Une activité d'appel pour envoyer la demande.

    • Une activité de prélèvement avec deux branches: une onMessage pour la réponse en stock et des instructions sur la marche à suivre si un message en stock est reçu.

    • Un deuxième onMessage pour la réponse en cas de rupture de stock et les instructions sur la marche à suivre en cas de réception d'un message de rupture de stock.

  • Le processus de service BPEL a besoin d'une activité de réception pour accepter le message du client et d'une activité de commutation avec deux branches, une avec une activité d'appel envoyant le message en stock si l'article est disponible, et une seconde branche avec une activité d'appel envoyant le message de rupture de stock si l'article n'est pas disponible.

Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Dans ce chapitre, nous comprendrons le concept d'une demande, d'une réponse obligatoire et d'une réponse facultative.

  • Le service BPEL client envoie une seule demande au processus BPEL de service et reçoit une ou deux réponses.

  • Ici, la demande est de commander un produit en ligne. Si le produit est retardé, le service envoie un message informant le client. Dans tous les cas, le service envoie toujours une notification lorsque l'article est expédié.

  • Le service BPEL client a besoin d'une activité d'étendue contenant l'activité d'appel pour envoyer la demande et d'une activité de réception pour accepter la réponse obligatoire. Pour le message facultatif, leonMessagele gestionnaire de l'activité d'étendue est défini avec les instructions sur ce qu'il faut faire si le message facultatif est reçu (par exemple, vous informer que le produit a été retardé). Le processus BPEL client attend de recevoir la réponse obligatoire. Si la réponse obligatoire est reçue en premier, le processus BPEL se poursuit sans attendre la réponse facultative.

  • Le processus BPEL de service a besoin d'une activité d'étendue contenant l'activité de réception et d'une activité d'appel pour envoyer le message d'expédition obligatoire, ainsi que la portée onAlarm handler pour envoyer le message différé facultatif si un minuteur expire (par exemple, envoyer le message différé si l'article n'est pas expédié dans les 24 heures).

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Maintenant, nous allons apprendre le concept de traitement partiel dans BPEL.

  • Le processus BPEL client envoie une demande au processus BPEL de service et reçoit une réponse immédiate, mais le traitement se poursuit du côté service.

  • Ce modèle peut également inclure plusieurs rappels de plans, suivis d'un traitement à plus long terme.

  • Par exemple, le client envoie une demande d'achat d'un forfait vacances, et le service envoie une réponse immédiate confirmant l'achat, puis continue à réserver l'hôtel, le vol, la voiture de location, etc.

  • Le processus BPEL client a besoin d'une activité d'appel pour chaque demande et d'une activité de réception pour chaque réponse pour les transactions asynchrones, ou simplement d'une activité d'appel pour chaque transaction synchrone.

  • Le processus BPEL de service a besoin d'une activité de réception pour chaque demande du client et d'une activité d'appel pour chaque réponse. Une fois les réponses terminées, le processus BPEL de service en tant que service peut continuer son traitement, en utilisant les informations recueillies dans la transaction pour effectuer les tâches nécessaires sans aucune autre entrée du client.

  • Comme pour toutes les activités du partenaire, le fichier WSDL (Web Services Description Language) définit l'interaction.

Nous en apprendrons davantage sur les multiples interactions des applications avec BPEL dans ce chapitre.

  • Lorsqu'il y a plus de deux applications impliquées dans une transaction.

  • Ce modèle de transaction A à B à C à A peut gérer plusieurs transactions en même temps. Par conséquent, un mécanisme est nécessaire pour savoir quel message va où.

  • Cela peut être géré à l'aide de WS-Addressing ou d'ensembles de corrélation.

Nous avons discuté dans l'un des chapitres précédents que le service Web synchrone en est un, qui fournit une réponse immédiate à un appel.

Dans la capture d'écran ci-dessous, nous avons créé un processus BPEL synchrone qui a une activité de réception pour accepter la demande de l'utilisateur. L'activité de réponse renvoie simultanément la réponse.

Comme indiqué précédemment, le service Web asynchrone est celui qui envoie une demande à un autre service Web et attend la réponse.

Dans la capture d'écran ci-dessous, nous avons créé le processus BPEL asynchrone qui a une activité de réception pour accepter la demande de l'utilisateur. L'activité d'affectation attribue en outre des valeurs aux différents éléments de la demande.

Ensuite, l'activité d'appel appelle l'application HelloWorld qui envoie la réponse simultanément et qui est capturée dans l'activité de réception.

De plus, nous avons l'activité de rappel qui génère finalement une sortie et envoie une réponse de manière asynchrone.

Si vous double-cliquez sur le receiveInput ou callbackClient, vous verrez que chacun d'eux n'a qu'une seule variable.

receiveInput → inputVariable
callbackClient → outputVariable

Dans ce chapitre, nous allons comprendre comment fonctionne le flux parallèle dans BPEL.

Qu'est-ce que l'activité Flow?

Une activité de flux contient généralement de nombreuses activités de séquence, et chaque séquence est exécutée en parallèle. Une activité de flux peut également contenir d'autres activités.

Par exemple, deux rappels asynchrones s'exécutent en parallèle, de sorte qu'un rappel n'ait pas à attendre que l'autre se termine en premier. Chaque réponse est stockée dans une variable globale différente.

Dans l'activité de flux, le code BPEL détermine le nombre de branches parallèles. Cependant, le nombre de succursales requis est souvent différent selon les informations disponibles.

Qu'est-ce que l'activité FlowN?

L'activité flowN crée plusieurs flux égaux à la valeur de N, qui est définie au moment de l'exécution en fonction des données disponibles et de la logique du processus. Il y a un incrément de variable d'index chaque fois qu'une nouvelle branche est créée, jusqu'à ce que la variable d'index atteigne la valeur de N.

L'activité flowN effectue des activités sur un nombre arbitraire d'éléments de données. À mesure que le nombre d'éléments change, le processus BPEL s'ajuste en conséquence.

Les branches créées par flowN effectuent les mêmes activités, mais utilisent des données différentes. Chaque branche utilise la variable d'index pour rechercher des variables d'entrée. La variable d'index peut être utilisée dans l'expression XPath pour acquérir les données spécifiques à cette branche.

BPEL applique la logique pour faire des choix par branchement conditionnel. Les deux actions différentes basées sur le branchement conditionnel sont présentées ci-dessous -

Changer d'activité

Dans cette méthode, vous configurez deux branches ou plus, chaque branche sous la forme d'une expression XPath. Si l'expression est vraie, la branche est exécutée. Si l'expression est fausse, le processus BPEL passe à la condition de branche suivante, jusqu'à ce qu'il trouve une condition de branche valide, rencontre une autre branche ou soit à court de branches. Si plus d'une condition de branche est vraie, BPEL exécute la première vraie branche.

Pendant l'activité

Vous pouvez utiliser une activité while pour créer une boucle while afin de sélectionner entre deux actions.

Pour comprendre comment utiliser la gestion des pannes, nous devons apprendre l'architecture de base d'un Service Composite dans Oracle SOA Suite.

  • Service components- Processus BPEL, règle métier, tâche humaine, médiateur. Ceux-ci sont utilisés pour construire une application composite SOA.

  • Binding components - Établir une connexion entre un composite SOA et un monde externe.

  • Services - Fournit un point d'entrée à l'application composite SOA.

  • Binding - Définit les protocoles qui communiquent avec le service comme SOAP / HTTP, l'adaptateur JCA, etc.

  • WSDL - Définit la définition de service d'un service Web.

  • References - Permet à une application composite SOA d'envoyer des messages à des services externes

  • Wires - Permet la connexion entre les composants du service.

Types de défauts

Voyons maintenant les différents types de défauts.

Défauts commerciaux

Se produit lorsque l'application exécute une activité THROW ou qu'une INVOKE reçoit une erreur en réponse. Le nom de l'erreur est spécifié par le composant de service de processus BPEL. Le gestionnaire d'erreurs utilisant le nom de l'erreur et la variable d'erreur intercepte cette erreur.

Défauts d'exécution

Ceci est jeté par le système. Ces défauts sont associés àRunTimeFaultMessage et sont inclus dans

http://schemas.oracle.com/bpel/extensionnamespace.

Moyens de gestion des pannes

Dans cette section, nous découvrirons les différentes méthodes de gestion des pannes.

Activité de lancer

Lancer l'activité jette explicitement la faute. Le bloc catch intercepte cette faute et les actions correspondantes sont exécutées de cette manière.

  • En utilisant l'activité de lancement, vous pouvez lancer des erreurs métier et dans la portée créée, vous pouvez attraper cette erreur et rediriger vers l'appelant (consommateur) pour qu'il agisse.

  • Au lieu de l'approche ci-dessus, vous lancez la même erreur interceptée dans l'activité de capture de la portée créée. Dans la portée principale, vous pouvez attraper cette faute en utilisant l'activité catchall.

Cadre de gestion des erreurs (EHF)

Les 2 principaux fichiers utilisés dans EHF sont -

  • Fault-Policy.xml
  • Fault-Bindings.xml

Chaque fois que le processus BPEL génère une erreur, l'EHF vérifie si l'erreur existe dans les fichiers Fault-Bindings.xml. Si tel est le cas, l'action dans le fichier Fault-Policy.xml sera effectuée. Si l'action n'est pas trouvée, la faute sera lancée et elle sera traitée dans le bloc catch.

L'infrastructure de gestion des pannes (Fault-Policy.xml et Fault-Bindings.xml) est conservée dans un composite SOA.

Les gestionnaires de fautes comme catch et catchall sont à l'intérieur d'un BPEL pour attraper toutes les fautes, mais fault policies will only be executed when an invoke activity fails.

Dans ce chapitre, nous verrons différents scénarios liés à la resoumission d'un processus défaillant.

Scénario A

Le code BPEL utilise une politique de panne et une panne est gérée à l'aide de l'activité «ora-human-intervention». L'erreur est alors marquée comme récupérable et l'état de l'instance est défini sur «En cours d'exécution».

Scénario B

Le code BPEL utilise une politique d'erreur et une erreur est interceptée et relancée à l'aide de l'action «ora-rethrow-fault». Le défaut est alors marqué comme récupérable et l'état de l'instance est défini sur «Faulted»; à condition que l'erreur soit récupérable (comme l'URL n'était pas disponible).

Il existe plusieurs méthodes pour incorporer du code Java et Java EE dans les processus BPEL. Voici quelques méthodes importantes -

  • Wrap en tant que service SOAP (Simple Object Access Protocol)

  • Incorporer des extraits de code Java dans un processus BPEL avec la balise bpelx - exec

  • Utilisez une façade XML pour simplifier la manipulation du DOM

  • Utiliser bpelx - méthodes intégrées exec

  • Utiliser du code Java encapsulé dans une interface de service

L'activité Java Embedding nous permet d'ajouter des activités dans un processus BPEL. Nous pouvons écrire un extrait de code Java à l'aide des bibliothèques JDK standard, des API BPEL, des classes Java personnalisées et tierces incluses dans les fichiers JAR des composites SCA déployés (dans le répertoire SCA-INF / lib) et des classes et bibliothèques Java disponibles sur le chemin de classe pour la SOA Temps d'exécution de la suite.

Java Embedding signifie des fonctionnalités cachées à l'intérieur, d'une manière peu découplée. Le code Java est difficile à maintenir. En intégrant Java dans BPEL (piloté par XML), nous commençons à mélanger des technologies, qui nécessitent des compétences différentes, ainsi que le marshaling et la démarshalling d'objets XML coûteux.

Les meilleurs cas d'utilisation de Java Embedding semblent être pour la journalisation / traçage avancé ou pour des validations / transformations spéciales. Cependant, ne pas remplacer les capacités intégrées du moteur BPEL ainsi que les autres composants de SOA Suite 11g et les adaptateurs qui l'accompagnent.

XPath est principalement utilisé pour manipuler les XML dans le processus BPEL. Il existe de précieuses fonctions Xpath qui peuvent être utilisées pour manipuler XML. Voyons les fonctions ci-dessous.

bpel: getVaribleData (varName, partName, xpathStr)

Cela peut être utilisé pour extraire un ensemble d'éléments d'une variable, en utilisant une expression XPath.

<bpel:copy>
   <bpel:from>
   <![CDATA[count(bpel:getVariableData(‘$Variable','$partName')/ns:return)]]>
   </bpel:from>
      <bpel:to variable = "itemNumber">
   </bpel:to>
</bpel:copy>

bpel: getLinkStatus ()

Cela peut être utilisé pour évaluer et renvoyer un booléen si un lien particulier est actif ou inactif.

: getVariableProperty (chaîne, chaîne)

Ceci est utile pour extraire les propriétés des variables.

: doXSLTTransform ()

Cela effectue les transformations XSLT.

chaîne ()

Cela peut être utilisé pour extraire le contenu texte des éléments plutôt en utilisant / text ().

Longueur de chaine()

Cette fonction est utilisée pour calculer la longueur de la chaîne. Mais l'opérateur! = Ne semble pas fonctionner avec la sortie de cette fonction. Vous pouvez donc utiliser> ou <plutôt en utilisant! =.

Valeurs booléennes

Vous pouvez affecter des valeurs booléennes avec la fonction booléenne XPath.

<assign>
   <!-- copy from boolean expression function to the variable -->
   <copy>
      <from expression = "true()"/>
      <to variable = "output" part = "payload" query="/result/approved"/>
   </copy>
</assign>

Attribution d'une date ou d'une heure

Vous pouvez affecter la valeur actuelle d'un champ de date ou d'heure à l'aide de la fonction Oracle BPEL XPath getCurrentDate, getCurrentTime ou getCurrentDateTime, respectivement.

<!-- execute the XPath extension function getCurrentDate() -->
<assign>
   <copy>
      <from expression = "xpath20:getCurrentDate()"/>
      <to variable = "output" part = "payload"
      query = "/invoice/invoiceDate"/>
   </copy>
</assign>

Concaténation de chaînes

Plutôt que de copier la valeur d'une variable de chaîne (ou d'une partie ou d'un champ de variable) dans une autre, vous pouvez d'abord effectuer une manipulation de chaîne, comme la concaténation de plusieurs chaînes.

<assign>
   <!-- copy from XPath expression to the variable -->
   <copy>
      <from expression = "concat('Hello ',
      bpws:getVariableData('input', 'payload', '/p:name'))"/>
      <to variable = "output" part = "payload" query = "/p:result/p:message"/>
   </copy>
</assign>

Attribution de littéraux de chaîne

Vous pouvez affecter des chaînes littérales à une variable dans BPEL.

<assign>
   <!-- copy from string expression to the variable -->
   <copy>
      <from expression = "'GE'"/>
      <to variable = "output" part = "payload" query = "/p:result/p:symbol"/>
   </copy>
</assign>

Attribution de valeurs numériques

Vous pouvez attribuer des valeurs numériques dans les expressions XPath.

<assign>
   <!-- copy from integer expression to the variable -->
   <copy>
      <from expression = "100"/>
      <to variable = "output" part = "payload" query = "/p:result/p:quantity"/>
   </copy>
</assign>

Note - Quelques fonctions XSLT ont été utilisées pour transformer un document XML.

La corrélation BPEL fait correspondre les messages entrants avec une instance de processus spécifique. Lorsque vous devez associer des données spécifiques à une instance spécifique d'un processus métier, vous utilisez la corrélation.

Par exemple, lors de la création d'un processus qui vérifie un numéro de compte et vérifie la limite de crédit du compte. Une fois vérifié, le processus appelle un autre système pour vérifier l'inventaire et, si l'article est en stock, génère une commande d'achat. Comment le bon de commande sait-il quel compte doit être débité? La réponse à cette question est la corrélation.

Ensembles de corrélation

Les ensembles de corrélations sont utilisés pour identifier de manière unique les instances de processus. Vous attribuez à chaque jeu de corrélations un nom unique, puis vous le définissez par une ou plusieurs propriétés. Chaque propriété a un nom et un type (par exemple, une chaîne ou un entier).

Alias ​​de propriété

L'alias de propriété de chaque propriété de l'ensemble de corrélations doit être défini. Un alias de propriété est un mappage qui lie la propriété aux valeurs d'entrée ou de sortie.

Les points importants

Tenez compte des points importants suivants liés à la Correlation Sets and Message Aggregation -

  • Un processus qui contient plusieurs activités de réception ou de prélèvement doit avoir un ensemble de corrélations.

  • Les ensembles de corrélations sont initialisés avec les valeurs des messages entrants ou sortants de processus.

  • Si vous avez des groupes de messages associés à un processus spécifique, vous pouvez configurer un ou plusieurs ensembles de corrélations à gérer.

Les services Web asynchrones mettent généralement beaucoup de temps à renvoyer une réponse et, en tant que tel, un composant de service de processus BPEL doit pouvoir expirer ou abandonner l'attente et continuer avec le reste du flux après un certain temps. Vous pouvez utiliser l'activité de prélèvement pour configurer un flux BPEL pour qu'il attende pendant une durée spécifiée ou pour continuer à exécuter ses tâches. Pour définir une période d'expiration pour l'heure, vous pouvez utiliser l'activité d'attente. Pour gérer les messages, les événements peuvent être utilisés en particulier lorsque le processus métier attend des rappels des services Web partenaires.

Événements

BPEL prend en charge deux types d'événements -

Événements de message

Ces événements sont déclenchés par des messages entrants via l'appel d'opération sur les types de port.

Événements d'alarme

Ces événements sont liés au temps et sont déclenchés soit après une certaine durée, soit à un moment précis.

  • Souvent, cependant, il est plus utile d'attendre plus d'un message, dont un seul apparaîtra.

  • Les événements d'alarme sont utiles lorsque vous souhaitez que le processus attende un rappel pendant un certain temps, par exemple 15 minutes.

    • Si aucun rappel n'est reçu, le flux de processus continue comme prévu.

    • Utile dans les architectures orientées services faiblement couplées, où vous ne pouvez pas compter sur des services Web disponibles à tout moment.

Choisir une activité

L'activité pick a 2 branches -

  • onMessage - le code sur cette branche est égal au code de réception d'une réponse avant l'ajout d'un timeout.

  • onAlarm - cette condition a un code pour un timeout d'une minute.

Activité d'attente

L'activité d'attente permet à un processus d'attendre pendant une période donnée ou jusqu'à ce qu'une limite de temps soit atteinte. L'un des critères d'expiration doit être spécifié.

Le processus BPEL peut être utilisé pour le service de notification. Le processus peut être conçu pour envoyer ce qui suit -

  • email
  • message vocal
  • messagerie instantanée (IM), ou
  • notifications de service de messages courts (SMS)

Pour les services mentionnés ci-dessus, vous pouvez configurer le canal pour le message entrant et sortant.

Les capteurs composites dans une application SOA permettent de définir des champs traçables sur les messages et vous permettent de trouver une instance composite spécifique en recherchant un champ ou des champs dans un message. Par exemple, un capteur pourrait être défini pour un numéro de commande dans un message, nous permettant ainsi de trouver l'instance où se trouve le numéro de commande en question.

Les capteurs composites peuvent être définis dans une application SOA en plusieurs composants -

  • Composant de service (service exposé)

  • Composant de référence (référence externe)

  • Médiateur ou composant BPEL qui s'est abonné à un événement commercial (la publication d'un événement ne peut pas avoir de capteur)

Différentes façons de définir un capteur composite

Il existe différentes manières de définir un capteur composite -

  • En spécifiant une variable existante comme capteur.
  • Par une expression à l'aide du générateur d'expression.
  • En utilisant des propriétés (par exemple les propriétés d'en-tête de message).

Capteurs dans Enterprise Manager

La définition d'un capteur permet une recherche rapide de données dans une instance composite dans EM Console.

Dans le tableau de bord EM Console, un utilisateur peut rechercher des instances par nom et valeur de capteur.

Dans l'onglet «Instances de flux», vous pouvez sélectionner des capteurs dans les listes déroulantes et utiliser des valeurs de type générique pour la valeur du capteur.

De nouvelles activités ont été ajoutées dans la version 2.0 qui ont remplacé celles de la version 1.1.

<pourChaque>

Cette activité permet de répéter l'ensemble des activités. L'activité remplace l'activité FlowN dans la version BPEL 1.1.

<repeatUntil>

Cette activité est utile si le corps d'une activité doit être pratiqué au moins une fois. La condition d'expression XPath dans l'activité repeatUntil est évaluée une fois le corps de l'activité terminé.

<if> - <elseif> - <else>

Cette activité remplace l'activité de commutation dans BPEL 2.0. L'activité vous permet de définir un comportement conditionnel pour des activités spécifiques afin de choisir entre deux branches ou plus. Une seule activité est sélectionnée pour exécution à partir d'un ensemble de branches.

<compensateScope>

Cette activité permet de compenser la portée enfant spécifiée.

<rethrow>

Cette activité a été ajoutée aux gestionnaires d'erreurs. Il vous permet de renvoyer une erreur capturée à l'origine par le gestionnaire d'erreurs immédiatement englobant.