Beruflich Dokumente
Kultur Dokumente
<bpel:reply name="replyOutput"
partnerLink="client"
portType="tns:processExemple"
operation="process"
variable="output"
/>
<invoke> L'activité <invoke> permet au processus d'invoquer un service
<bpel:throw name="Throw"></bpel:throw>
<exit> L'activité <exit> permet de terminer immédiatement une instance de processus
métier dans laquelle L'activité <exit> est contenue.
<bpel:exit name="Exit"></bpel:exit>
<wait> L'activité <wait> est utilisée pour attendre une période donnée ou jusqu'à ce
qu'un certain moment été atteint.
<bpel:wait name="Wait">
<bpel:until><![CDATA["2018-04-30T20:03:00"]]></bpel:until>
</bpel:wait>
<empty> L'activité <empty> est une opération "no-op" dans un processus métier. Ceci est
utile pour la synchronisation des activités concurrentes, par exemple.
<bpel:empty name="Empty"></bpel:empty>
<sequence> L'activité <sequence> est utilisée pour définir une collection d'activités à
effectuer séquentiellement dans l'ordre lexical.
<bpel:sequence name="Sequence"></bpel:sequence>
<if> L'activité <if> est utilisée pour sélectionner exactement une activité à exécuter à
partir d'un ensemble de choix.
<bpel:if name="If">
<bpel:condition expressionLanguage =
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
<![CDATA[$input.payload/tns:input ='azerty']]>
</bpel:condition>
</bpel:if>
<while> L'activité <while> est utilisée pour définir que l'activité enfant doit être répétée
aussi longtemps que le <condition> spécifiée est vraie.
<bpel:while name="While">
<bpel:condition expressionLanguage =
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><!
[CDATA[$iterator<10]]></bpel:condition>
</bpel:while>
<repeatUntil> L'activité <repeatUntil> est utilisée pour définir que l'activité enfant doit être
répétée jusqu'à ce que la condition <condition> spécifiée devient vraie. La
<condition> est testée après l'activité de l'enfant
complète. L'activité <repeatUntil> est utilisée pour exécuter l'activité enfant au
moins une fois.
<bpel:repeatUntil name="RepeatUntil">
<bpel:condition expressionLanguage =
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
<![CDATA[$input.payload/tns:input="azerty"]]>
</bpel:condition>
</bpel:repeatUntil>
<forEach> L'activité <forEach> itère son activité de portée enfant exactement N + 1 fois où
N est égal à <finalCounterValue> moins <startCounterValue>.
Si parallel = "yes" alors les N + 1 instances de l'activité <scope> jointe
DEVRAIENT se produire en parallèle. Un <completionCondition> peut être
utilisé dans <forEach> pour permet à l'activité <forEach> de se terminer sans
exécuter ni terminer toutes les branches spécifié.
<bpel:completionCondition>
<bpel:branches expressionLanguage =
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"
successfulBranchesOnly="no">
<![CDATA[3]]>
</bpel:branches>
</bpel:completionCondition>
<bpel:scope>
</bpel:scope>
</bpel:forEach>
<pick> L'activité <pick> est utilisée pour attendre l'arrivée des messages ou
l'expiration d'un délai. Lorsque l'un de ces déclencheurs se produit, l'activité
enfant associée est effectuée. Quand l'activité enfant se termine alors l'activité
<pick> est terminée.
<bpel:scope>
<bpel:sequence name="Sequence">
<bpel:empty name="Empty"></bpel:empty>
</bpel:sequence>
</bpel:scope>
<compensate> L'activité <compensate> est utilisée pour commencer la compensation sur tous
les champs internes qui ont déjà terminé avec succès, dans l'ordre par défaut.
Cette activité DOIT uniquement être utilisée à partir de dans un gestionnaire
d'erreurs, un autre gestionnaire de compensation ou un gestionnaire de
terminaison.
<bpel:compensate></bpel:compensate>
<compensateScope> L'activité <compensateScope> est utilisée pour démarrer la compensation sur
une portée interne spécifiée a déjà terminé avec succès. Cette activité DOIT
uniquement être utilisée à partir d'un gestionnaire d'erreurs, un autre
gestionnaire de compensation ou un gestionnaire de terminaison.
<bpel:compensateScope name="CompensateScope">
</bpel:compensateScope>
<rethrow> L'activité <rethrow> est utilisée pour renvoyer la faute qui a été capturée.
L'activité <rethrow> DOIT seulement être utilisée
dans un gestionnaire d'erreurs (c'est-à-dire des éléments <catch> et <catchAll>)
<bpel:rethrow></bpel:rethrow>
.
<validate> L'activité <validate> permet de valider les valeurs des variables par rapport à
leur XML associé et définition de données WSDL.
<bpel:partnerLinks>
<!-- The 'client' role represents the requester of this service. -->
<bpel:partnerLink name="client"
partnerLinkType="tns:processExemple"
myRole="processExempleProvider"
/>
</bpel:partnerLinks>
<partnerLinkType> Un <partnerLinkType> caractérise la relation conversationnelle entre deux
services en définant les rôles joués par chacun des services dans la conversation
et spécifier le portType fourni par chaque service pour recevoir des messages
dans le contexte de la conversation. Chaque
<role> spécifie exactement un portType WSDL.
<plnk:partnerLinkType name="processExemple">
<plnk:role name="processExempleProvider"
portType="tns:processExemple"/>
</plnk:partnerLinkType>
<variable> Chaque <variable> est déclarée dans un <scope> et est censée appartenir à cette
portée. Variables
appartiennent à la portée globale du processus sont appelées variables globales.
Les variables peuvent aussi appartenir à d'autres,
étendues non globales, et ces variables sont appelées variables locales. Chaque
variable est visible uniquement dans
l'étendue dans laquelle il est défini et dans tous les domaines imbriqués dans le
périmètre auquel il appartient
<bpel:variables>
<!-- Reference to the message passed as input during initiation -->
<bpel:variable name="input"
messageType="tns:processExempleRequestMessage"/>
<!--
Reference to the message that will be returned to the requester
-->
<bpel:variable name="output"
messageType="tns:processExempleResponseMessage"/>
</bpel:variables>
<faultHandlers> Traitement des erreurs déclenchées. Il DOIT y avoir au moins un élément
<catch> ou <catchAll> .
<bpel:faultHandlers>
<bpel:catch>
<bpel:sequence><bpel:compensate></bpel:compensate>
<bpel:rethrow></bpel:rethrow>
</bpel:sequence>
</bpel:catch>
</bpel:faultHandlers>
<eventHandlers> Chaque scope, y compris le scope du processus, peut avoir un ensemble de
gestionnaires d'événements. Ces gestionnaires d'événements
peut s'exécuter simultanément et sont invoqués lorsque l'événement
correspondant se produit.
<bpel:eventHandlers>
<bpel:onEvent>
<bpel:scope></bpel:scope>
</bpel:onEvent>
</bpel:eventHandlers>
<compensationHandler> La capacité de déclarer la logique de compensation
<links> <links> peut être utilisé dans un <flow> pour définir les dépendances de
contrôle explicites entre les imbriqués
<bpel:flow name="Flow">
<bpel:sources>
<bpel:source linkName="link1"></bpel:source>
</bpel:sources>
</bpel:assign>
<bpel:targets>
<bpel:target linkName="link1"></bpel:target>
</bpel:targets>
</bpel:assign>
</bpel:flow>