Carnets de bord

 

BMPI has an interoperability working group looking at the general binding between BPML and other technologies. One technology of interest for us is of course ebXML BPSS.

Again a large part of this section is a summary of the corresponding section of the Wrox book, Processional ebXML foundations.

Message Flow Binding

We are looking at binding the collection of simple activities which involve the same participant with which the BPMS collaborates to the business transaction activities of a BPSS binary collaboration definition (see figure below). BPML provides the concept of an abstract to group these activities in a single entity. Abstracts are used to model views of processes supported by participants, or to define reusable views of a process with regards to one or more participants.

An abstract need not be complete and may omit information that is not relevant outside the context of interaction with its participants.

A process can declare it supports one or more abstracts. This is actually the essence of a business process definition: a business process is a collection of collaborations between a role represented by the BPMS and any number of participants, which can be users, systems, or business partners. All simple activities can be associated with a given collaboration.

Consequently, an abstract is the representation of a particular collaboration from the perspective of the BPMS. A BPSS collaboration does not have any point of view, it represents the shared view of the message interchanges between two roles. A process definition may support as many abstracts as necessary. One role may support more than one abstract.

There is no need for an abstract to model the sequencing rules of its collaboration. It is merely a series of simple activity definitions that will be sequenced within the process definition as complex activities. The process definition sequencing rules turn out to be substantially different from the collaboration sequencing rules. In the process definition, other activities, with specific and internal sequencing rules will be interleaved with the simple activities that participate in the abstract. These internal activities and sequencing rules are completely independent from the collaboration definition.

An abstract definition is very simple – an example is provided below:

<abstract name="Ab:Process Purchase Order" timeToPerform="2D">

   <message name="Msg:Process PO" type="request"/>

   <message name="Msg:Ack PO" type="response"/>

   <message name="Msg:Reject PO" type="response"/>

 

   <operation name="Op:Process PO">

      <input message="Msg:Ack PO"/>

      <output message="Msg:Process PO"/>

   </operation>

   <exception name="Exc:Reject PO"

      <input message="Msg:Reject PO"/>

   </exception>

</abstract>

BPMI is currently working on a binding framework specification for ebXML as well as other standards such as RosettaNet. There is no vocabulary or meta model that has been specified yet. The following example is just a tentative to illustrate what a binding may look like:

<?xml version="1.0"?>

<! DOCTYPE "BPMLBinding.dtd" >

 

<!-- We are binding the abstract to the BPSS collaboration -->

<Bindings abstract="Ab:Process PO" version="1.0">

   <Binding name="PlatinumCusotmers" type="ebXML:OAGIS">

   <MessageBinding  collaboration="CB:Process PO"

                          uri="http://openapplications.org/…/004_ProcessPO_003.xml">

      <operation name="Op:Process PO">

         <input message="Msg:Ack PO">

            <ebBPSS:DocumentEnvelope BusinessDocument="BD:Ack PO"/>

         </input>

         <output message="Op:Process PO">

            <ebBPSS:DocumentEnvelope BusinessDocument="BD:Process PO"/>

         </output>

      </operation>

      <exception message="Exc:Reject PO">

         <ebBPSS:DocumentEnvelope BusinessDocument="Reject PO"/>

      </exception>

   </MessageBinding>

   <TimeToPerform duration="7D"/>

   <DataBinding>

         ...

   </DataBinding>

   <ProtocolBinding>

       <ebXMLProtocol>

            ...

       </ebXMLProtocol>

   </ProtocolBinding>

   <ParticipantRole name="Buyer"/>

   </Binding>

  

   <Binding name="RegularCustomers" type="ebXML:OAGIS">

      <MessageBinding ref="CB:Process PO"/>

      <TimeToPerform duration="30D"/>

      <ProtocolBinding>

         <ebXMLProtocol>

            ...

         </ebXMLProtocol>

      </ProtocolBinding>

      <ParticipantRole name="Buyer"/>

   </Binding>

</Bindings>

Note that, as in this example, several bindings may exist for the same (abstract or collaboration) association. This is a key design decision in the metamodel of a given BPMS, since this is what is going to relate participant profiles to the way the business process definition really behaves at run time, once the performer of an activity is identified. BPML allows for both static and dynamic participants, therefore taking advantage of multiple possible bindings, one for each group of participant. A static participant is defined as part of the business process definition, a dynamic participant is "passed" to a business process instance at run time.

The fact several binding can be associated to a given abstract is essential in the architecture of highly connected systems. Within a large community of business partners, when a new version of a standard is available, it is unlikely that all partners will upgrade their systems at the same time. However, if they upgrade to a new format (such as OAGIS v8.0) or a new communication protocol (such as ebXML 2.0) it is also likely that a given business process definition will still be applicable, only its binding will need to be updated. So ultimately, any given process definition which involves collaborations with business partners will have to support multiple bindings, 80% of these bindings are likely to be relative to different business document versions.

Data Flow Binding 

Data flow is a very important concept in BPMS systems. We have seen earlier that XML enables the modeling of the context of a business process instance as a set of structured documents. These are extensible, as the various activities of the business process operates on the documents, and semantically accessible, which enable the definition of business rules or transformations into participant format which are somewhat decoupled from the structure of the document itself. BPML is one of the first business process standards which truly takes advantage of an XML data flow.

The binding is done via the concept of assignment. Assignments work both ways, with the information collected from or communicated to participants. The example below shows an Insure shipment request document appended with the status value of the response document. It also shows that an Insure shipment request could be created from the Purchase order document, which was created as part of a previous activity and is now part of the business process context.

<abstract name="Ab:Process PO" timeToPerform="2D">

   <message name="Msg:Process PO" type="request">

      <xsd:element name="004_PROCESSPO_003" type="oagis:004_PROCESSPO_003.dtd"/>

   </message>

 

   <message name="Msg:Ack PO" type="response">

      <xsd:element name="CONFIRMBOD" type="oagis:CONFIRMBOD.dtd"/>

   </message>

   <operation name="Op:Process PO">

      <input message="Msg:Ack PO"

         <!-- append request document with response from supplier -->

          <assign target="004_PROCESS_PO/STATUS"

                 select="CONFIRMBOD/STATUS"/>

      </input>

      <output message="Msg:Process PO">

         <!-- Create request from purchase order -->

         <assign select="Msg:Purchase order"

                target="Msg:Process PO"/>

      </output>

   </operation>

</abstract>

We have also added the message format definition. We have chosen an OAGIS (www.openapplications.org) format for the request and the response. These formats represent the internal format used by the BPMS to store its context. This format may itself be bound to various formats, maybe different versions of the OAGI specification or other standards such as ACORD, xCBL, which all have a purchase order document. The data binding is specified at the document level since documents may be reused over different messages within several collaborations . Let’s take a look at what a document format binding (or data binding) looks like. Again, this is not part of BPML, it is just an illustration of what could be part of BPML.

<?xml version="1.0"?>

<! DOCTYPE "BPMLBinding.xsd" >

<Bindings abstract="Ab:Insure shipment request"

          version="1.0">

   <Binding name="PlatinumCusotmers" type="ebXML:ACORD">

      <MessageBinding name="CB:Insure shipment request">

         ...

      </MessageBinding>

      <TimeToPerform duration="7D"/>

 

      <DataBinding>

         <message ref="Msg:Process PO">

            <ebBPSS:BusinessDocument ref="BD:Process PO"/>

            <transformation uri="http://.../tsf/ProcessPO_OAGIS_1_2.xslt"/>

         </message>

 

         <message ref="Msg:Ack PO">

            <ebBPSS:BusinessDocument ref="BD:Ack PO"/>

            <transformation uri="http://.../tsf/Ack_PO_OAGIS_1_2_.xslt"/>

         </message>

      </DataBinding>

 

      <ProtocolBinding>

         <ebXMLProtocol>

            ...

         </ebXMLProtocol>

      </ProtocolBinding>

      <ParticipantRole name="Buyer"/>

   </Binding>

   <Binding name="RegularCustomers" type="ebXML:OAG">

      ...

   </Binding>

</Bindings>

Control Flow Binding 

In this section, we are going to explore the rules that map collaboration sequencing rules into complex activities and BPML transactions. This section is based on the BPML specification which is available at www.bpmi.org. What we are going to do here is create a business process definition which control flow supports the collaboration document envelope (this is message) choreography.

Complex activities provide facilities to model (In parentheses, I have indicated the corresponding BPML tag names):

• Sequences of activities (Sequence). 
• Activities happening in parallel (All). 
• Conditional process branching (Switch). 
• Conditional participant branching (Choice). 
• Repeat of activities over a set of entities (ForEach).

An activity can either be a complex, process, or simple activity. A conditional process branching is based on the information contained in the business process instance context.. For instance, "if an order amount is greater than $10,000, it requires a manual approval process for the ack_po". A conditional participant branching is a decision taken by a participant and communicated to the process instance as a message. For instance, an insure shipment request order may be accepted or rejected by the insurer. This decision is communicated as part of a message to the buyer business process instance.

Time constrains may be associated to any activity as part of the control flow of the business process definition.

BPML, XLANG, and WSFL are one of the very few business process specifications to support transactional semantics. The Worfklow Management Coalition (WfMC) does not support these semantics. In the business world, transactions are significantly different from database transactions. The traditional ACID (atomic, consistent, durable, isolated) properties of a database transaction are difficult to implement in real world business transactions. The major issue is the isolation of a database transaction. This property requires resource locking which is impractical in the business world. It would also preclude users from participating in a business process.

BPML supports two transaction models: coordinated and extended. They both provide an "all-or-nothing" guarantee for complex interactions between multiple participants. In a coordinated transaction, all participants agree to either complete the transaction or abort it. This model relies on a two phase commit protocol and is also known as a closed, flat transaction due to its ability to support isolation. The extended transaction model relaxes the isolation requirement. There are two possible modes of recovery for such a transaction: backward recovery, where the transaction initiates some compensating activities that will cancel the effects of the failed transaction, and forward recovery, where the business process instance is allowed to continue its execution taking into account that the transaction failed. Compensating activities are used wherever the execution of an activity cannot be rolled back (such as when an order is shipped). These transactions are also known as open nested transactions or Sagas. This model supports transaction interleaving with arbitrary nesting, in other words, transaction may be composed of other transactions.

BPML transactions operate with users, partners, and systems without discrimination. They do not impose limits on duration and survive hardware or software failures.

Control flow binding is somewhat arbitrary, in the sense that somebody has to sit down and make decisions taking into account not only the collaboration but the internal context in which this collaboration will be executed. The best we can do, it to can establish production rules to transform a collaboration definition into the skeleton of a business process definition that only features those activities that involve the partner role of the collaboration. We may also develop an algorithm that takes an arbitrary business process definition and creates a collaboration definition for a given role.

If we take the example of Process RFQ collaboration:

The corresponding BPML definition which supports this collaboration may look like this:

<abstract name=”buyer:RFQ_Collaboration”>

     ...

</abstract>

<process name=”Process RFQ”>

     <supports abstract=”buyer:RFQ_Collaboration”/>

     <sequence name=”main”>

          <completedBy duration=”P10D”

          <operation name=”Create RFQ”>

                <participant select=”seller”/>

                <output message=”RFQ”>

                <input message=”Accept RFQ”>

                     <assign target=”RFQ_Status”

                            select=”Accept RFQ/Status/text()”

                </input>

          </operation>

          <exception code=”TechnicalFailure”

                <complete/>

          </exception>

          <consume>

                <participant select=”seller”/>

                <input message=”Reject RFQ”>

                     <assign target=”RFQ_Status”

                            select=”Accept RFQ/Status/text()”

                </input>

          </consume>

          <switch>

                <case condition=”[RFQ_Status=’OK’]”>

                     <!-- could have some internal

                          activities defined here -->

                     <sequence name=”reviewRFQ”>

                          ...

                     </sequence>

                <otherwise>

                     <complete/>

                </otherwise>

          </switch>

          </sequence>

</process>

The review RFQ activity is a complex activity which corresponds to this part of the collaboration:

The corresponding code follows:

<process>

     <sequence name=”reviewRFQ”>

          <all>

                <sequence name=”Change RFQ”>

                     <!-- Internal operation goes here -->

                    

                     <operation name=”Change RFQ”>

                       <participant select=”seller”>

                       <output message=”buyer:Change RFQ”/>

                       <input message=”seller:Change Acknowledgement”/>

                     </operation>

                </sequence>

                <sequence name=”Cancel RFQ”>

                     <!-- Internal operation goes here -->

                    

                     <operation name=”Cancel RFQ”>

                       <participant select=”seller”>

                       <output message=”buyer:Cancel RFQ”/>

                       <input message=”seller:Cancel Acknowledgement”/>

                     </operation>

                </sequence>

                <sequence name=”Query Item”>

                     <consume>                  

                         

                     <participant select=”seller”/>

                     <input message=”Query Item”>

                </consume>

                <!-- Internal operation goes here -->

                <produce name=”Response”>

                     <participant select=”buyer”>

                       <output message=”buyer:Response”/>

                </produce>

          </sequence>

          <exception code=”TechnicalFailure”

                <complete/>

          </exception>

          </all>

     </sequence>

...

</process>

  BPML is still a work in progress. The consortium is currently working toward a precise binding to ebXML. Actually, part of the BPML metamodel is designed to support ebXML BPSS.