WS-BPEL :

<receive> L'activité <receive> permet au processus métier d'attendre l'arrivée d'un

message correspondant.

<bpel:receive name="receiveInput" partnerLink="client"

portType="tns:processExemple"
operation="process" variable="input"
createInstance="yes"/>
<reply> L'activité <reply> permet au processus technique d'envoyer un message en
réponse à un message

<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:invoke name="Invoke" partnerLink="calculatorlink" operation="add"

portType="ns:CalculatorPortType" inputVariable="calculatorlinkRequest"
outputVariable="calculatorlinkResponse">
</bpel:invoke>
<assign> L'activité <assign> est utilisée pour mettre à jour les valeurs des variables avec
de nouvelles données.

<bpel:assign validate="no" name="Assign"></bpel:assign>

<throw> L'activité <throw> est utilisée pour générer une erreur à l'intérieur du processus
métier.

<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:forEach parallel="no" counterName="Counter" name="ForEach">

<bpel:startCounterValue
 expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
<![CDATA[0]]>
</bpel:startCounterValue>
<bpel:finalCounterValue
expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
<![CDATA[5]]>
</bpel:finalCounterValue>

<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:pick name="Pick" createInstance="yes">

<bpel:onMessage partnerLink="client" operation="add"
portType="tns:processtestpick" variable="clientRequest">
</bpel:pick>
<flow> L'activité <flow> est utilisée pour spécifier une ou plusieurs activités à effectuer
simultanément. <links> peut être utilisé dans un <flow> pour définir les
dépendances de contrôle explicites entre les activités enfants imbriquées.

<bpel:flow name="Flow"> </bpel:flow>

<scope> L'activité <scope> est utilisée pour définir une activité imbriquée avec ses
propres <partnerLinks> associés, <messageExchanges>, <variables>,
<correlationSets>, <faultHandlers>, <compensationHandler>,
<terminationHandler> et <eventHandlers>.

<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:validate name="Validate" variables="input output"></bpel:validate>

<extensionActivity> L'élément <extensionActivity> est utilisé pour étendre WS-BPEL en
introduisant une nouvelle activité type. Le contenu d'un élément
<extensionActivity> DOIT être un élément unique qui DOIT
rendre disponibles les attributs standard et les éléments standard de WS-BPEL.
<import> L'élément <import> est utilisé dans un processus WS-BPEL pour déclarer une
dépendance à Schéma XML ou définitions WSDL.

<!-- Import the client WSDL -->

<bpel:import location="processExempleArtifacts.wsdl"
namespace="http://exemple.bpel.dz/bpel/exemple"
importType="http://schemas.xmlsoap.org/wsdl/" />

<partnerLinks> La notion de <partnerLinks> est utilisée pour modéliser directement les

relations de partenaires de conversation pair-à-pair. <partnerLinks> définit le
forme d'une relation avec un partenaire en définissant les portTypes utilisés dans
les interactions dans les deux directions.

Chaque <partnerLink> est caractérisé par un partnerLinkType. Plus d'un

<partnerLink> peut être caractérisé par le même partnerLinkType.

Dans un <partnerLink>, le rôle du processus métier lui-même est indiqué par

l'attribut myRole et le rôle du partenaire sont indiqués par l'attribut partnerRole.
Lorsqu'un partnerLinkType n'a qu'un seul rôle, l'un de ces attributs est omis si
nécessaire. Notez qu'un <partnerLink> DOIT spécifier le myRole, ou le
partnerRole, ou les deux.

<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:links> <bpel:link name="link1"></bpel:link> </bpel:links>

<bpel:assign validate="no" name="Assign">

<bpel:sources>
<bpel:source linkName="link1"></bpel:source>
</bpel:sources>

</bpel:assign>

<bpel:assign validate="no" name="Assign1">

<bpel:targets>
<bpel:target linkName="link1"></bpel:target>
</bpel:targets>
</bpel:assign>
</bpel:flow>