Important BPEL Activities and Elements
The following section covers important activity and element tags associated with BPEL processing.
<assign>, <copy>, <from>, <to>
The <assign>
activity is used to:
Copy data from one variable to another
Construct and insert new data using expressions and literal values
Copy partner link endpoint references
Syntax
<assign standard-attributes> standard-elements <copy>+ from-spec to-spec </copy> </assign>
The from-spec
section can have the following forms:
<from variable=”ncname” part=”ncname”?/> <from variable=”ncname” part=”ncname”? query=”queryString”?/> <!-- Executable processes only -->
<from partnerLink=”ncname” endpointReference=”myRole|partnerRole”/> <from variable=”ncname” property=”qname”/> <from expression=”general-expr”/> <from> ... literal value ... </from> <from opaque=”yes”> <!-- Abstract processes only -->
The to-spec
section can have the following forms:
<to variable=”ncname” part=”ncname”?/> <to variable=”ncname” part=”ncname”? query=”queryString”?/> <!-- Executable processes only -->
<to partnerLink=”ncname”/> <to variable=”ncname” property=”qname”/>
Example
<assign> <copy> <from variable=”TravelRequest” part=”flightData”/> <to variable=”FlightDetails” part=”flightData”/> </copy> <copy> <from variable=”EmployeeTravelStatusResponse” part=”travelClass”/> <to variable=”FlightDetails” part=”travelClass”/> </copy> </assign>
<catch>, <catchAll>
The <catch>
activities are specified within fault handlers to specify faults that are to be caught and handled. The
<catchAll>
activity is used to catch all faults. Within a fault handler, at least one <catch>
activity needs to be specified. The optional <catchAll>
activity can also be specified.
The <catch>
activity has two attributes that can be used to specify which fault to handle. At least one of them needs to be specified:
faultName
: Specifies the name of the fault to handlefaultVariable
: Specifies the variable type used for fault data
Syntax
<faultHandlers> <!-- there must be at least one fault handler or default --> <catch faultName=”qname”? faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers>
When used to define an inline fault handler for the <invoke>
activity, the syntax is as follows:
<invoke partnerLink=”ncname” portType=”qname” operation=”ncname” inputVariable=”ncname”? outputVariable=”ncname”? standard-attributes> standard-elements <correlations>? <correlation set=”ncname” initiate=”yes|no”? pattern=”in|out|out-in”/>+ </correlations> <catch faultName=”qname” faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> <compensationHandler>? activity </compensationHandler> </invoke>
Example
<faultHandlers> <catch faultName=”trv:TicketNotApproved” > <!-- Perform an activity --> </catch> <catch faultName=”trv:TicketNotApproved” faultVariable=”TravelFault” > <!-- Perform an activity --> </catch> <catch faultVariable=”TravelFault” > <!-- Perform an activity --> </catch> <catchAll> <!-- Perform an activity --> </catchAll> </faultHandlers>
<compensate>
To invoke a compensation handler, you use the <compensate>
activity. The <compensate>
activity has an optional scope
attribute that can be used to specify the compensation handler to be invoked. The scope name or activity name (for inline compensation handlers) has to be specified.
Syntax
<compensate scope=”ncname”? standard-attributes> standard-elements </compensate>
Example
<compensate scope=”TicketConfirmationPayment” />
Or
<compensate scope=”TicketConfirmation” />
<compensationHandler>
Compensation handlers are used to define compensation activities. Compensation handlers gather all activities that have to be carried out to compensate another activity and can be defined for the whole process or scope, or can be inlined for the <invoke>
activity.
Syntax
<compensationHandler> activity </compensationHandler>
Example
Compensation handler for a scope:
<scope name=”TicketConfirmationPayment” > <compensationHandler> <invoke partnerLink=”AmericanAirlines” portType=”aln:TicketConfirmationPT” operation=”CancelTicket” inputVariable=”FlightDetails” outputVariable=”Cancellation” /> <invoke partnerLink=”AmericanAirlines” portType=”aln:TicketPaymentPT” operation=”CancelPayment” inputVariable=”PaymentDetails” outputVariable=”PaymentCancellation” /> </compensationHandler> <invoke partnerLink=”AmericanAirlines” portType=”aln:TicketConfirmationPT” operation=”ConfirmTicket” inputVariable=”FlightDetails” outputVariable=”Confirmation” /> <invoke partnerLink=”AmericanAirlines” portType=”aln:TicketPaymentPT” operation=”PayTicket” inputVariable=”PaymentDetails” outputVariable=”PaymentConfirmation” /> </scope>
Inline compensation handler for the <invoke>
activity:
<invoke name=”TicketConfirmation” partnerLink=”AmericanAirlines” portType=”aln:TicketConfirmationPT” operation=”ConfirmTicket” inputVariable=”FlightDetails” outputVariable=”Confirmation” > <compensationHandler> <invoke partnerLink=”AmericanAirlines” portType=”aln:TicketConfirmationPT” operation=”CancelTicket” inputVariable=”FlightDetails” outputVariable=”Cancellation” > </compensationHandler> </invoke>
<correlations>, <correlation>
The <correlation>
element is used to associate a correlation set (a collection of key data fields) with an activity. Correlation can be used within the <receive>
, <reply>
, <invoke>
, and <onMessage>
activities.
Syntax
<correlations> <correlation set=”ncname” initiate=”yes|no”? pattern=”in|out|out-in”/>+ </correlations>
Example
<correlations> <correlation set=”TicketOrder” initiate=”yes” pattern=”in” /> </correlations>
<correlationSets>, <correlationSet>
A correlation set is a set of properties shared by messages and used for correlation. It is used to associate a message with a business process instance. Each correlation set has a name
attribute.
Syntax
<correlationSets> <correlationSet name=”ncname” properties=”qname-list”/>+ </correlationSets>
Example
<correlationSets> <correlationSet name=”VehicleOrder” properties=”tns:chassisNo tns:engineNo”/> <correlationSet name=”TickerOrder” properties=”aln:FlightNo”/> </correlationSets>
<empty>
An activity that does nothing is defined by the <empty>
tag.
Syntax
<empty standard-attributes> standard-elements </empty>
Example
<empty/>
<eventHandlers>
Event handlers react to events that occur while the business process is executing. When these events occur, the corresponding event handlers are invoked. Event handlers can be specified for the whole process as well as for each scope.
Syntax
<eventHandlers> <!-- there must be at least one onMessage or onAlarm handler --> <onMessage partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”?>* <correlations>? <correlation set=”ncname” initiate=”yes|no”>+ </correlations> activity </onMessage> <onAlarm for=”duration-expr”? until=”deadline-expr”?>* activity </onAlarm> </eventHandlers>
Example
<process name=”BusinessTravelProcess” enableInstanceCompensation=”yes” ... > ... <eventHandlers> <onMessage partnerLink=”client” portType=”trv:TravelApprovalPT” operation=”CancelTravelApproval” variable=”TravelRequest” > <terminate/> </onMessage> <onAlarm for=”’PT12H’”> <terminate/> </onAlarm> </eventHandlers> ... </process>
<faultHandlers>, <faultHandler>
Fault handlers are used to react to faults that occur while the business process activities are executing. They can be specified for the global process or each scope, or inline for <invoke>
activities. Multiple <catch>
activities can be specified within the fault handler for specific faults. You need to specify at least one <catch>
activity. You can optionally specify the <catchAll>
activity. The syntax and functionality of the <catch>
activity is the same as described in the earlier section on <catch>
and <catchall>
.
Syntax
<faultHandlers> <!-- There must be at least one fault handler or default --> <catch faultName=”qname”? faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers>
An inline fault handler for the <invoke>
activity is specified as shown below:
<invoke partnerLink=”ncname” portType=”qname” operation=”ncname” inputVariable=”ncname”? outputVariable=”ncname”? standard-attributes> standard-elements <correlations>? <correlation set=”ncname” initiate=”yes|no”? pattern=”in|out|out-in”/>+ </correlations> <catch faultName=”qname” faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> <compensationHandler>? activity </compensationHandler> </invoke>
Example
<faultHandlers> <catch faultName=”trv:TicketNotApproved” > <!-- Perform an activity --> </catch> <catch faultName=”trv:TicketNotApproved” faultVariable=”TravelFault” > <!-- Perform an activity --> </catch> <catch faultVariable=”TravelFault” > <!-- Perform an activity --> </catch> <catchAll> <!-- Perform an activity --> </catchAll> </faultHandlers>
<flow>
The <flow>
activity provides concurrent execution of enclosed activities and their synchronization.
Syntax
<flow standard-attributes> standard-elements <links>? <link name=”ncname”>+ </links> activity+ </flow>
Example
<flow> <!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke name=”EmployeeTravelStatusSyncInv” partnerLink=”employeeTravelStatus” portType=”emp:EmployeeTravelStatusPT” operation=”EmployeeTravelStatus” inputVariable=”EmployeeTravelStatusRequest” outputVariable=”EmployeeTravelStatusResponse” /> <!-- Prepare the input for AA and DA --> ... <!-- Async invoke of the AA web service --> <invoke name=”AmericanAirlinesAsyncInv” partnerLink=”AmericanAirlines” portType=”aln:FlightAvailabilityPT” operation=”FlightAvailability” inputVariable=”FlightDetails” /> <!-- Receive the callback --> <receive name=”AmericanAirlinesCallback” partnerLink=”AmericanAirlines” portType=”aln:FlightCallbackPT” operation=”FlightTicketCallback” variable=”FlightResponseAA” /> <!-- Async invoke of the DA web service --> <invoke name=”DeltaAirlinesAsyncInv” partnerLink=”DeltaAirlines” portType=”aln:FlightAvailabilityPT” operation=”FlightAvailability” inputVariable=”FlightDetails” /> <!-- Receive the callback --> <receive name=”DeltaAirlinesCallback” partnerLink=”DeltaAirlines” portType=”aln:FlightCallbackPT” operation=”FlightTicketCallback” variable=”FlightResponseDA” /> <!-- Select the best offer and construct the TravelResponse --> ... <!-- Make a callback to the client --> <invoke name=”ClientCallback” partnerLink=”client” portType=”trv:ClientCallbackPT” operation=”ClientCallback” inputVariable=”TravelResponse” /> </flow>
<invoke>
The <invoke>
activity is used to invoke the web service operations provided by partners.
Syntax
<invoke partnerLink=”ncname” portType=”qname” operation=”ncname” inputVariable=”ncname”? outputVariable=”ncname”? standard-attributes> standard-elements <correlations>? <correlation set=”ncname” initiate=”yes|no”? pattern=”in|out|out-in”/>+ </correlations> <catch faultName=”qname” faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> <compensationHandler>? activity </compensationHandler> </invoke>
Example
<!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke name=”EmployeeTravelStatusSyncInv” partnerLink=”employeeTravelStatus” portType=”emp:EmployeeTravelStatusPT” operation=”EmployeeTravelStatus” inputVariable=”EmployeeTravelStatusRequest” outputVariable=”EmployeeTravelStatusResponse” /> <!-- Async invoke of the AA web service --> <invoke name=”AmericanAirlinesAsyncInv” partnerLink=”AmericanAirlines” portType=”aln:FlightAvailabilityPT” operation=”FlightAvailability” inputVariable=”FlightDetails” />
<links>, <link>
Synchronization dependencies in concurrent flows are specified using links.
Syntax
<links> <link name=”ncname”>+ </links>
Example
<links> <link name=”TravelStatusToTicketRequest” /> <link name=”TicketRequestToTicketConfirmation” /> </links>
<onAlarm>
This activity is used in the <pick>
and <eventHandlers>
activities to specify the occurrence of alarm events.
Syntax
<onAlarm (for=”duration-expr” | until=”deadline-expr”)> activity </onAlarm>
Example
<onAlarm for=”’PT30M’”> <throw faultName=”trv:CallbackTimeout” /> </onAlarm>
<onMessage>
Used in <pick>
and <eventHandlers>
activities to specify the occurrence of message events.
Syntax
<onMessage partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”?> <correlations>? <correlation set=”ncname” initiate=”yes|no”?>+ </correlations> activity </onMessage>
Example
<onMessage partnerLink=”AmericanAirlines” portType=”aln:FlightCallbackPT” operation=”FlightTicketCallback” variable=”FlightResponseAA”> <!-- Perform an activity --> </onMessage>
<partnerLinks>, <partnerLink>
A business process interacts with services that are modeled as partner links. Each partner link is characterized by a <partnerLinkType>
. More than one partner link can be characterized by the same <partnerLinkType>
. See the next section for more on <partnerLinkType>
.
Syntax
<partnerLinks> <partnerLink name=”ncname” partnerLinkType=”qname” myRole=”ncname”? partnerRole=”ncname”?>+ </partnerLink> </partnerLinks>
Example
<partnerLinks> <partnerLink name=”insurance” partnerLinkType=”tns:insuranceLT” myRole=”insuranceRequester” partnerRole=”insuranceService”/> </partnerLinks>
<partnerLinkType>, <role>
A partner link type characterizes the relationship between two services. It defines roles for each of the services in the conversation between them and specifies the port type provided by each service to receive messages. Partner link types and roles are specified in the WSDL.
Syntax
<definitions name=”ncname” targetNamespace=”uri” xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:plnk=”http://schemas.xmlsoap.org/ws/2003/05/partner-link/”> ... <plnk:partnerLinkType name=”ncname”> <plnk:role name=”ncname”> <plnk:portType name=”qname”/> </plnk:role> <plnk:role name=”ncname”>? <plnk:portType name=”qname”/> </plnk:role> </plnk:partnerLinkType> ... </definitions>
Example
<plnk:partnerLinkType name=”flightLT”> <plnk:role name=”airlineService”> <plnk:portType name=”tns:FlightAvailabilityPT” /> </plnk:role> <plnk:role name=”airlineCustomer”> <plnk:portType name=”tns:FlightCallbackPT” /> </plnk:role> </plnk:partnerLinkType>
<partners>
The partner element is used to represent the capabilities required from a business partner. A partner is defined as a set of partner links.
Syntax
<partners> <partner name=”ncname”>+ <partnerLink name=”ncname”/>+ </partner> </partners>
Example
<partner name=”ServiceProvider”> <partnerLink name=”ReantacarProvider”/> <partnerLink name=”LodgingProvider”/> </partner>
<pick>
The <pick>
activity is used to wait for the occurrence of one of a set of events and then perform an activity associated with the event.
Syntax
<pick createInstance=”yes|no”? standard-attributes> standard-elements <onMessage partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”?>+ <correlations>? <correlation set=”ncname” initiate=”yes|no”?>+ </correlations> activity </onMessage> <onAlarm (for=”duration-expr” | until=”deadline-expr”)>* activity </onAlarm> </pick>
Example
<pick> <onMessage partnerLink=”AmericanAirlines” portType=”aln:FlightCallbackPT” operation=”FlightTicketCallback” variable=”FlightResponseAA”> <!-- Perform an activity --> </onMessage> <onMessage partnerLink=”AmericanAirlines” portType=”aln:FlightCallbackPT” operation=”FlightNotAvaliable” variable=”FlightNAResponseAA”> <!-- Perform an activity --> </onMessage> <onMessage partnerLink=”AmericanAirlines” portType=”aln:FlightCallbackPT” operation=”TicketNotAvaliable” variable=”FlightTNAResponseAA”> <!-- Perform an activity --> </onMessage> <onAlarm for=”’PT30M’”> <throw faultName=”trv:CallbackTimeout” /> </onAlarm> </pick>
<process>
This is the root element of each BPEL process definition.
Syntax
<process name=”ncname” targetNamespace=”uri” queryLanguage=”anyURI”? expressionLanguage=”anyURI”? suppressJoinFailure=”yes|no”? enableInstanceCompensation=”yes|no”? abstractProcess=”yes|no”? xmlns=”http://schemas.xmlsoap.org/ws/2003/03/business-process/”> <partnerLinks>? <!-- Note: At least one role must be specified. --> <partnerLink name=”ncname” partnerLinkType=”qname” myRole=”ncname”? partnerRole=”ncname”?>+ </partnerLink> </partnerLinks> <partners>? <partner name=”ncname”>+ <partnerLink name=”ncname”/>+ </partner> </partners> <variables>? <variable name=”ncname” messageType=”qname”? type=”qname”? element=”qname”?/>+ </variables> <correlationSets>? <correlationSet name=”ncname” properties=”qname-list”/>+ </correlationSets> <faultHandlers>? <!-- Note: There must be at least one fault handler or default. --> <catch faultName=”qname”? faultVariable=”ncname”?>* activity </catch> <catchAll>? activity </catchAll> </faultHandlers> <compensationHandler>? activity </compensationHandler> <eventHandlers>? <!-- Note: There must be at least one onMessage or onAlarm handler. --> <onMessage partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”?> <correlations>? <correlation set=”ncname” initiate=”yes|no”?>+ <correlations> activity </onMessage> <onAlarm for=”duration-expr”? until=”deadline-expr”?>* activity </onAlarm> </eventHandlers> activity </process>
Example
Examples are shown in Chapters 3 and 4.
<property>
Properties are used to create globally unique names and associate them with data types (XML Schema types). Properties have greater significance than the types themselves. Properties are defined in WSDL.
Syntax
<wsdl:definitions xmlns:bpws=”http://schemas.xmlsoap.org/ws/2003/03/business-process/”> ... <bpws:property name=”ncname” type=”qname”/> ... </wsdl:definitions>
Example
<bpws:property name=”FlightNo” type=”xs:string” />
<propertyAlias>
Property aliases are used to map global properties to fields in specific message parts. Property aliases are defined in the WSDL.
Syntax
<wsdl:definitions xmlns:bpws=”http://schemas.xmlsoap.org/ws/2003/03/business-process/”> ... <bpws:propertyAlias propertyName=”qname” messageType=”qname” part=”ncname” query=”queryString”/> ... </wsdl:definitions>
Example
<bpws:propertyAlias propertyName=”tns:FlightNo” messageType=”tns:TravelResponseMessage” part=”confirmationData” query=”/confirmationData/FlightNo”/>
<receive>
A <receive>
activity is used to receive requests in a BPEL business process to provide services to its partners.
Syntax
<receive partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”? createInstance=”yes|no”? standard-attributes> standard-elements <correlations>? <correlation set=”ncname” initiate=”yes|no”?>+ </correlations> </receive>
Example
<!-- Receive the initial request for business travel from client --> <receive partnerLink=”client” portType=”trv:TravelApprovalPT” operation=”TravelApproval” variable=”TravelRequest” />
<reply>
A <reply>
activity is used to send a response to a request previously accepted through a <receive>
activity. Responses are used for synchronous request/reply interactions. An asynchronous response is always sent by invoking the corresponding one-way operation on the partner link.
Syntax
<reply partnerLink=”ncname” portType=”qname” operation=”ncname” variable=”ncname”? faultName=”qname”? standard-attributes> standard-elements <correlations>? <correlation set=”ncname” initiate=”yes|no”?>+ </correlations> </reply>
Example
<!-- Send a response to the client --> <reply partnerLink=”client” portType=”trv:TravelApprovalPT” operation=”TravelApproval” variable=”TravelResponse”/>
<scope>
Scopes define behavior contexts for activities. They provide fault handlers, event handlers, compensation handlers, data variables, and correlation sets for activities.
Syntax
<scope variableAccessSerializable=”yes|no” standard-attributes> standard-elements <variables>? ... </variables> <correlationSets>? ... </correlationSets> <faultHandlers>? ... </faultHandlers> <compensationHandler>? ... </compensationHandler> <eventHandlers>? ... </eventHandlers> activity </scope>
Example
<scope> <faultHandlers> <catch faultName=”emp:WrongEmployeeName” > <!-- Perform an activity --> </catch> <catch faultName=”emp:TravelNotAllowed” faultVariable=”Description” > <!-- Perform an activity --> </catch> <catchAll> <!-- Perform an activity --> </catchAll> </faultHandlers> <invoke partnerLink=”employeeTravelStatus” portType=”emp:EmployeeTravelStatusPT” operation=”EmployeeTravelStatus” inputVariable=”EmployeeTravelStatusRequest” outputVariable=”EmployeeTravelStatusResponse” /> </scope>
<sequence>
A <sequence>
activity is used to define activities that need to be performed in a sequential order.
Syntax
<sequence standard-attributes> standard-elements activity+ </sequence>
Example
Examples are covered in Chapters 3 and 4.
<source>
<source>
elements are used to declare that an activity is the source of one or more links. This is a standard element.
Syntax
<source linkName=”ncname” transitionCondition=”bool-expr”?/>*
Example
<invoke name=”EmployeeTravelStatusSyncInv” partnerLink=”employeeTravelStatus” portType=”emp:EmployeeTravelStatusPT” operation=”EmployeeTravelStatus” inputVariable=”EmployeeTravelStatusRequest” outputVariable=”EmployeeTravelStatusResponse” > <target linkName=”EmployeeInputToEmployeeTravelStatusSyncInv” /> <source linkName=”EmployeeTravelStatusSyncInvToAirlinesInput” /> </invoke>
<switch>, <case>
To express conditional behavior, the <switch>
activity is used. It consists of one or more conditional branches defined by <case>
elements, followed by an optional <otherwise>
element. The case branches of the switch are considered in alphabetical order.
Syntax
<switch standard-attributes> standard-elements <case condition=”bool-expr”>+ activity </case> <otherwise>? activity </otherwise> </switch>
Example
<!-- Select the best offer and construct the TravelResponse --> <switch> <case condition=”bpws:getVariableData(‘FlightResponseAA’, ‘confirmationData’,’/confirmationData/aln:Price’) <= bpws:getVariableData(‘FlightResponseDA’, ‘confirmationData’,’/confirmationData/aln:Price’)”> <!-- Select American Airlines --> <assign> <copy> <from variable=”FlightResponseAA” /> <to variable=”TravelResponse” /> </copy> </assign> </case> <otherwise> <!-- Select Delta Airlines --> <assign> <copy> <from variable=”FlightResponseDA” /> <to variable=”TravelResponse” /> </copy> </assign> </otherwise> </switch>
<target>
The <target>
element is used to declare that an activity is the target of one or more links. This is a standard element.
Syntax
<target linkName=”ncname”/>*
Example
<!-- Select the best offer and construct the TravelResponse --> <switch name=”BestOfferSelect”> <target linkName=”AmericanAirlinesCallbackToBestOfferSelect” /> <target linkName=”DeltaAirlinesCallbackToBestOfferSelect” /> <case condition=”bpws:getVariableData(‘FlightResponseAA’,‘confirmationData’,’/confirmationData/aln:Price’) <= bpws:getVariableData(‘FlightResponseDA’,‘confirmationData’,’/confirmationData/aln:Price’)”> <!-- Select American Airlines --> <assign> <copy> <from variable=”FlightResponseAA” /> <to variable=”TravelResponse” /> </copy> </assign> </case> <otherwise> <!-- Select Delta Airlines --> <assign> <copy> <from variable=”FlightResponseDA” /> <to variable=”TravelResponse” /> </copy> </assign> </otherwise> </switch>
<terminate>
The <terminate>
activity is used to immediately terminate a business process instance.
Syntax
<terminate standard-attributes> standard-elements </terminate>
Example
<terminate />
<throw>
The <throw>
activity is used to explicitly signal internal faults.
Syntax
<throw faultName=”qname” faultVariable=”ncname”? standard-attributes> standard-elements </throw>
Example
<throw faultName=”WrongEmployeeName” /> <throw faultName=”trv:TicketNotApproved” faultVariable=”TravelFault” />
<variables>, <variable>
Variables are used to hold messages that constitute the state of a business process. The variable may be of the WSDL message type, an XML Schema simple type, or an XML Schema element.
Syntax
<variables> <variable name=”ncname” messageType=”qname”? type=”qname”? element=”qname”?/>+ </variables>
Example
<variables> <variable name=”InsuranceRequest” messageType=”ins:InsuranceRequestMessage”/> <variable name=”PartialInsuranceDescription” element=”ins:InsuranceDescription”/> <variable name=”lastName” type=”xs:string”/> </variables>
<wait>
A <wait>
activity is used to specify a delay for a certain period of time or until a certain deadline is reached.
Syntax
<wait (for=”duration-expr” | until=”deadline-expr”) standard-attributes> standard-elements </wait>
Examples
<wait until=”’2004-03-18T21:00:00+01:00’”/> <wait until=”’18:05:30Z’”/> <wait for=”’PT4H10M’”/> <wait for=”’P1M3DT4H10M’”/> <wait for=”’P1Y11M14DT4H10M30S’”/>
<while>
A <while>
activity is used to define an iterative activity. The iterative activity is performed until the specified Boolean condition no longer holds true.
Syntax
<while condition=”bool-expr” standard-attributes> standard-elements activity </while>
Example
<while condition= “bpws:getVariableData(‘Counter’) < bpws:getVariableData(‘NoOfPassengers’)”> <sequence> <!-- Construct the FlightDetails variable with passenger data --> ... <!-- Invoke the web service --> <invoke partnerLink=”AmericanAirlines” portType=”aln:FlightAvailabilityPT” operation=”FlightAvailability” inputVariable=”FlightDetails” /> <receive partnerLink=”AmericanAirlines” portType=”trv:FlightCallbackPT” operation=”FlightTicketCallback” variable=”FlightResponseAA” /> ... <!-- Process the results … --> ... <!-- Increment the counter --> <assign> <copy> <from expression=”bpws:getVariableData(‘Counter’) + 1”/> <to variable=”Counter”/> </copy> </assign> </sequence> </while>