Book Image

Business Process Execution Language for Web Services 2nd Edition

Book Image

Business Process Execution Language for Web Services 2nd Edition

Overview of this book

Web services provide the basic technical platform required for application interoperability. They do not, however, provide higher level control, such as which web services need to be invoked, which operations should be called and in what sequence. Nor do they provide ways to describe the semantics of interfaces, the workflows, or e-business processes. BPEL is the missing link to assemble and integrate web services into a real business process BPEL4WS standardizes process automation between web services. This applies both within the enterprise, where BPEL4WS is used to integrate previously isolated systems, and between enterprises, where BPEL4WS enables easier and more effective integration with business partners. In providing a standard descriptive structure BPEL4WS enables enterprises to define their business processes during the design phase. Wider business benefits can flow from this through business process optimization, reengineering, and the selection of most appropriate processes . Supported by major vendorsó including BEA, Hewlett-Packard, IBM, Microsoft, Novell, Oracle, SAP, Sun, and othersó BPEL4WS is becoming the accepted standard for business process management. This book provides detailed coverage of BPEL4WS, its syntax, and where, and how, it is used. It begins with an overview of web services, showing both the foundation of, and need for, BPEL. The web services orchestration stack is explained, including standards such as WS-Security, WS-Coordination, WS-Transaction, WS-Addressing, and others. The BPEL language itself is explained in detail, with Code snippets and complete examples illustrating both its syntax and typical construction. Having covered BPEL itself, the book then goes on to show BPEL is used in context. by providing an overview of major BPEL4WS servers. It covers the Oracle BPEL Process Manager and Microsoft BizTalk Server 2004 in detail, and shows how to write BPEL4WS solutions using these servers.

Related Content you might be interested in

Current Title:

Small book image
Business Process Execution Language for Web Services 2nd Edition
Jan, 2006 | 372 pages
No titles found
Table of Contents (14 chapters)
Business Process Execution Language for Web Services
Business Process Execution Language for Web Services
Credits
Credits
About the Authors
About the Authors
About the Reviewers
About the Reviewers
Preface
Preface
Free Chapter
1
Introduction to BPEL and SOA
Introduction to BPEL and SOA
Why Business Processes Matter
Web Services
Enterprise Service Bus
Service Oriented Architecture
Service Composition
BPEL for Service Composition
Relation of BPEL to Other Languages
BPEL Servers Overview
The Future of BPEL
Conclusion
2
Web Services Technology Stack
Web Services Technology Stack
E-Business Collaborations
WS-Security
Typical Business Transaction Scenario
WS-Coordination
Web Services Transaction Specifications
OASIS BTP
Reliable Messaging
WS-Addressing
WS-Inspection
WS-Policy
WS-Eventing
Conclusion
3
Service Composition with BPEL
Service Composition with BPEL
Developing Business Processes with BPEL
Core Concepts
BPEL Business Process Example
Asynchronous BPEL Example
Conclusion
4
Advanced BPEL
Advanced BPEL
Advanced Activities
Fault Handling and Signaling
Scopes
Compensation
Managing Events
Business Process Lifecycle
Correlation and Message Properties
Concurrent Activities and Links
Dynamic Partner Links
Abstract Business Processes
Model Driven Approach: Generating BPEL from UML Activity Diagrams
Conclusion
5
Oracle BPEL Process Manager and BPEL Designer: Overview
Oracle BPEL Process Manager and BPEL Designer: Overview
Overview and Architecture
Process Deployment Example
Process Management with the BPEL Console
Graphical Development with BPEL Designer
Summary
6
Oracle BPEL Process Manager: Advanced Features
Oracle BPEL Process Manager: Advanced Features
Extension Functions and Activities
Dynamic Parallel Flow
Web Services Invocation Framework
Java Code Embedding
Notification Service
Workflow Service
Identity Service
BPEL Server APIs
Summary
7
MS BizTalk Server
MS BizTalk Server
Overview
Architecture
Building a Sample Orchestration in BizTalk
Exporting Orchestration to BPEL
Importing BPEL Processes into BizTalk
Do’s and Don’ts for BPEL Compliance in BizTalk
Comparing BizTalk Orchestration Constructs with BPEL
Advanced BPEL Functions using BizTalk
Other BizTalk-Specific Features
BizTalk Server 2006 and Beyond
Summary
BPEL Syntax Reference
BPEL Syntax Reference
Important BPEL Activities and Elements
BPEL Functions
Deadline and Duration Expressions
Standard Elements
Standard Attributes
Default Values of Attributes
Standard Faults
Namespaces
Index
Index

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 handle

  • faultVariable: 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’) 
                    &lt;= 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’) 
                    &lt;= 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’) &lt;
       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>
Previous Section
End of Section
Next Section