Prozess Implementation: Database Connectors | webMethods vs. Intalio

Creating a process step which is supposed to connect to a database works fine with both products. Therefore I don't need to dig deeper into this topic. Both solutions provide a tool to generate a jdbc connector.
What they both do:

• Create a connection type
• Create a Query adapter on top of an existing connection type.

webMethods and Intalio provide a mechanism to assign parameters from the process pipeline to the placeholders in prepared statement. Intalio helps with a wizard in Intalio Designer and webMethods has its wizard in the webMethods Developer.

With some practice, you can easily create and connect a databse accessor to your BPM process within 10 minutes.

In my HelloWorld example process, the process step 'PersistText' stores the text from the input signature of the process into a mySQL database.

Prozess Implementation: Starting the process | webMethods vs. Intalio

As you can see in the BPM graph, I have finished the little HelloWorld example. The input parameter for the process is one String, which gets stored in the step 'PersistText', afterwards the inputtext is presented to a user who can change the text and then submit it. The ouput of the process is the text which the user has submitted. Additionally, I added a gateway which adds an alternative path around the user interface.

Today I want to have a look only at the start event of the process and compare it to a webMethods process.

Let's start with Intalio this time.When you deploy the process onto the BPM Server (which is built upon a tomcat server) you can find some artifacts in the Axis2 container. Among schema files and the bpel file, you can find wsdl files. For every step in your process, Intalio generates an Axis2 webservice. And of course you can find a webservice for the start event.


That is a very convenient way to start your process. Just import the wsdl file into SoapUI and you are ready to test the process.


Now, how do you start a process in webMethods? You create a document type, make it publishable and syncronize it with webMethods Broker. Then you can just drag and drop this document onto your start event. That automatically generates a subscription onto this document type in webMethods Broker.




Then, you can publlish a document of this document type through the Designer to test your process.





That are two different approaches, but both work fine.
You start an Intalio process by calling a webservice, the webMethods process by publishing a document.
But I see two advantages for the webMethods way:

1. One Event can trigger several different processes.
2. How do you wait for the output of a long running process? That is no problem with the publish -and-wait implementation of webMethods. But I can't see how this could work for the http session of a SOAP Request. That much I still have to find out.

Process Design | webMethods vs. Intalio

First I want to design a very simple process with two steps. The first step is supposed to read a text from a database, the second step should be a user task. The user has the task to review and edit the text before he submits his task.
So basically there are two core functionalities in this process. An adapter task and a human task.
For comparison I use Software AG Designer 8.0 and Intalio Designer 6.0.3

I was really surprised how different this simple process can look although both Designers claim to do BPMN.

Software AG Designer:


Intalio Designer
Let's have a closer look at the differences.

1) The receive step

In webMethods, the receive step is one symbol for which you have to define a publishable document type. The receive step subscribes this document type in the webMethods broker.

In Intalio, you have to have a message connection from a step in an non-executable pool. The receive step cannot work standalone, you have to define what the trigger for the incoming message is. For this incoming message connection edge, you can define the document type by dragging a xsd document definition onto the edge.

The differences are not substantial. Intalio wants you to design the external trigger for your process also. That does add some information to you graph. The implementation of both receive steps has substantial differences but are not in focus today. I want to have a closer look at this issue in the implementation phase.

2)Meaning of a pool

As you can see, I used only one pool in webMethods, but had to use three pools in Intalio. Why that?
First of all, webMethods knows two types of pools, the external and the internal pool. Intalio uses the executable and none-executable pool. That are two different interpretations.
At that point I was wondering what the meaning of a pool according to BPMN is. As far as I know, the pool has no strict definition but helps you to outline different organizational units in you graph. Intalio stretches that definition a bit and gives the pool more technical meaning. That is the first time I got the impression that Intalio has a more technical view onto business processes while webMethods has a more business focused view onto BPM. But it will not be the last time.

OK, so in webMethods I have only one pool, because the complete process is running internally in the HelloWorldCorporation, no external stakeholders are involved.
Intalio forced me to create the client pool because you have to design the external trigger for you process. This external trigger has to reside in a non-executable pool. That makes sense from a technical standpoint, since the trigger step is outside the executable part of my process.
I was more surprised that I had to create another non-executable pool for creating my human task. I will explain that part in more detail in the next step. Only that much: The user to whom I assign the human task generally belongs to a different pool. Remember, the pool doesn't represent an organizational unit, but more a technical layer in Intalio.



3) Human task

The most obvious difference between both BPM graphs is the design of the human task. While there is only one step in webMethods, there are four steps in the Intalio graph.
The reason for this lies again in the different angles of view onto BPM.
From a business standpoint, the confirmation of the text is one 'TODO' in the process and therefore is represented by one step in the webMethods graph.
From the technical standpoint of Intalio, the confirmation of the text by a user consists of two steps. First, the creation of the human task and second, the completion of the task by the user. In the users-pool there are two additional steps which represents the UI-Form presented to the user in its two states 'Creation' and 'Completion'.
For my taste, this design is too closely related to implementation matters.

Interesting is the contrary order of how to design a human task in your BPM graph. In webMethods, you add a task, define it as a human task an then the Designer generates the web page for you.
In Intalio, you first need to create the web page before you can finish the design of your BPM graph. You can drag and drop the web page file into your graph to accomplish the human task definition.

Core BPM functionalities webMethods vs. Intalio

In my daily work I use the webMethods Suite to accomplish BPM challenges. Although these tools are pretty good I was wondering what functionalities I could get without paying money. Therefore I built up a virtual machine with components of the Intalio Community Edition. In the future posts I want to compare some key functionalities of both suites.
What are the core functionalities which I expect from a BPM solution?

• Designing the process with a graphical tool
• Generation of web forms for user tasks
• Adapters to database systems or third party software should be available or easy to create
• Monitoring of process instances

That are only basic functionalities which I want to use to analyze the degree of maturity of available open source bpm solutions. For running a productive BPM system you have to consider many other requirements, which I will have not planned to analyze in the near future.