Pascal On BPMS

Most process modeling tools and some BPM products provide “process simulation”. This is most often presented as a way to determine the business benefits that one might expect from implementing a given business process before having to actually do any implementation work. To a minimum, it simply allows to step through the business process diagram by injecting some sample conditions every time the flow needs to select a branch. More sophisticated tools provide the ability to inject different scenarios and verify the outcome or support “Monte Carlo” simulation.

Intalio|BPMS Designer does not provide such capability today. In this document, let’s describe what Intalio|BPMS can do today in this area, how it differentiates from traditional simulation and what more it could do in the future.

Today, Intalio|BPMS provides the ability to do what we call “process emulation”. This is taking advantage of the unique advantage that Intalio provides by generating executable processes directly from a BPMN diagram. No other product can do this today. Either they provide a BPMN modeler that cannot generate fully executable processes, or they generate code but they don’t support BPMN. Emulation consists in taking advantage of the BPMN “pools” that represent different types of participant by implementing people and system participants as “emulating processes”. The process participatns remain the same as if the process was to be deployed in a test or production environment, but here the people and external system that are involved in the process model are also processes. Then we leverage Intalio|BPMS Designer code generation capabilities to generate all the code and deploy the process in an “emulation environment”. This environment simply consists in Intalio|BPMS Server, where we deploy the processes together with the emulation processes that emulate people and system participant. This provides the ability to run the business processes in a fully automated environment, without having to integrate with any external system nor requiring any user interaction. In such an environment, processes can be tested to provide business information about how they should perform, should they eventually get fully implemented and deployed in a production system. With the Intalio|BPMS Console and Intalio|BAM, it is possible to get realistic, graphical, business information about the performance of such processes as they are emulated. Again, no other product provides such capabilities today.

So how is this different from typical process simulation as other tools do it? Process modeling and simulation tools do not provide the ability to generate, deploy and run executable processes. They therefore only target business analysts and enforces them not to consider any technical details. They model processes to meet certain business objectives and requirements, abstract from any technical consideration. Most process modeling tool vendors would argue that this is a better methodology to focus on the business independently from the technical constraints first, and later have other people in the IT to figure out what to do with it. BPM tries to change this by enabling collaboration between the 2 views. This is important, because when a process needs to be implemented, technical constraints can no longer be ignored, and it may require process modeling changes. As a result, the processes that are implemented end up being different than those that were modeled by the business analysts, and this breaks the assumptions upon which simulation was performed! In other words, process simulation provides business analysis of “theorical processes” that may very well have nothing to do with “real processes”.

If process simulation fails to provide information about the business performance one can expect from their processes before implementing them, then what is it worth? Is process simulation useless? No, there is still value in process simulation, but not for what it is typically presented. There is indeed a challenge in getting from busioness processes that business analysts can model to fully designed processes that can be deployed and executed. Now that business analysts and IT Engineers can use the same Intalio|BPMS Designer tool, how can they collaborate more efficiently and not just use the same tool but in two different worlds? Here, the biggest challenge is for the Business Analyst to understand whether or not their process models actually express what they wanted, and whether or not they are good enough to be implemented by the technical team. This is where process simulation can really help. With process simulation in Intalio|BPMS Designer, business analysts could test their process models against several scenarios and adapt their models until they feel confident they’re ready to be shared with the technical team.

To summarize, here is how simulation and emulation can be envisonned to be used in order to indeed provide valuable business information before deploying processes in a production environment:

1. Business Analysts create new process models in Intalio|BPMS Designer
2. Business Analysts use Intalio|BPMS Designer simulation capabilities to ensure their process models meet their objectives and requirements as far as they can tell.
3. IT Engineers add emulation processes and deploy them in the emulation environment.
4. Business Analysts analize the business reports they get from the emulation environment.
5. Based on the reports, Business Analysts may revisit their models and go back to step #2. Once they are happy with the business outcome they can truly expect to get, it’s time to actually implement those processes.
6. IT Engineers now fully implement processes by integrating external systems and users. The next steps are the traditional steps to deploy an application in a production system (test, acceptance, production)

Today, Intalio|BPMS Designer unfortunately does not provide such simulation capabilities. However, no other products do and products that offer simulation today do not help addressing the challenge of gettting from business process model to executable processes. In fact, they tend to justify the isolation of business analysts from the IT department, which goes against all the premises of BPM 2.0. It is therefore highly recommended not to let users adopt such tools and instead learn from Intalio partners about best practices that will help business analysts and IT engineers collaborating.

See also:

• Why a BPMS should support Process Simulation , by Ismael Ghalimi on IT|Redux.
• Process Simulation in Intalio|BPMS Designer , an Intalio|Demand Driven Development (D3) project.
• Is Simulation Fake? , by Bruce Silver on The Intelligent Enterprise.

This post was written by Jacques-Alexandre Gerber at Intalio.  Published with his permission.

I’m not going to argue that BPEL Correlations are complex and hard to use. I think what you have to do to setup a correlation speaks for itself.

I’m not going to explain how you can setup a correlation either. I’ve already covered this in Setting up a Correlation, but I’m going to use the generated BPEL Process to walk you through how the correlation actually works, and in doing so show you how each piece fits into the whole.

But just to summarize, so you know what are all the pieces needed, here is what you need for the simplest correlation example.

The Process

The 2 messages:

<xs:element name="Message1">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Age" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element><xs:element name="Message2">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Address" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Then you need to define

- at least a Property

<bpel:property name="name" type="xs:string"/>

- a correlationSet

<bpel:correlationSets>
  <bpel:correlationSet properties="tns:name" name="name-correlation"/>
</bpel:correlationSets>

- 2 property aliases (one for each message)

<bpel:propertyAlias propertyName="this:name" messageType="Client:msg1" part="Message1">
  <bpel:query>Correlation:Name</bpel:query>
 </bpel:propertyAlias>

<bpel:propertyAlias propertyName="this:name" messageType="Client:msg1" part="Message2">
  <bpel:query>Correlation:Name</bpel:query>
 </bpel:propertyAlias>

- And attach the correlation to each receive

<bpel:receive bpmn:id="ID-5938e518-bfcf-1004-8cce-0438cf81d0f0"
  name="Receive1-Receive"
  partnerLink="Client_And_Correlation_PLink"
  portType="Client:Client_To_Correlation_PortType"
  operation="Receive1" variable="msg1" createInstance="yes">
  <rdfs:label xml:space="preserve">Receive1</rdfs:label>
  <bpel:correlations>
    <bpel:correlation set="name-correlation" initiate="yes"/>
  </bpel:correlations>
</bpel:receive>

<bpel:receive bpmn:id="ID-593b12e8-bfcf-1004-8cce-0438cf81d0f0"
  name="Receive2-Receive"
  partnerLink="Client_And_Correlation_PLink"
  portType="Client:Client_To_Correlation_PortType"
  operation="Receive2" variable="msg2" createInstance="no">
  <rdfs:label xml:space="preserve">Receive2</rdfs:label>
  <bpel:correlations>
    <bpel:correlation set="name-correlation" initiate="no"/>
  </bpel:correlations>
</bpel:receive>

That’s it.

First message arrives

So now that all the pieces are in place, let’s see how they each contribute to get the right message back to the right process instance. For this, let’s walk through an actual execution and examine what happens.

A message of type Message1 is received.

A new process instance is triggered (Correlation) and while executing the first receive (Receive1-Receive), the BPEL engine finds the correlation “name-correlation“, looks up its definition, figures out that it contains a property “name“, and since the message received is of type “Message1″, finds the property alias for this message type, part and property.

From there, it will use the query for that Property Alias to know which element of the message to use. This query can be any XPath expression. Finally, since this first correlation has the attribute initiate=”yes” , the engine will initialize the property name with the value of the <name> element in the incoming message. Phew, still with me?

Correlation -> property -> property alias (for the message type) -> query -> value stored.

Second message

From there, this is easy When a message of type Message2 arrives, we can go through the same steps. Except for 2 main differences: the message type and part is different, so the BPEL engine will use the second property alias. And the correlation has “initiate=”no”, which means that instead of setting the property value, it will match the value of the property with the value of the element found by resolving the query of the property alias. In this case, it is also a <name> element, but it could be anything. The value found is what matters for matching with the right process instance.

Correlation -> property -> property alias (for the message type) -> query -> match (or not).

So are BPEL Correlations complex? You bet. Are they impossible to understand? Not if you take the time to understand each piece and how it relates to the others.

Now you are ready to tackle bigger and more complex correlations! Use more than one correlation per process, add more properties to the correlation, do more than 2 message exchanges, the possibilities are limitless…

I have just completed a second screen cast. This one shows how you can use BPMN to model the process used in the First Process Tutorial.

It shows how you can call external services by using the Wed ServiceDescriptor (WSDL). Once modeled, the process is deployed (as BPEL), and executed.

Checkout this First Process screen cast (about 10 minutes long).