BPMN/XPDL Execution in Papyrus

Those who follow my blogs might already be bored with my frequent bickering about process management. That I am not the only one to criticize the BPM market you can read in Terry Tschurter’s paper on the BPM State of the Nation 2009.

The worst thing I could do is to complain about something that I do not know much about. Therefore I would like to show to you that we at ISIS Papyrus are no strangers process management concepts, as easily proven by this announcement of the BPMN/XPDL Editor of our Papyrus Platform. I will not go into the details of either BPMN and XPDL here.

Keith Swenson is the authority on XPDL and BPMN and covers the relationship in this post: The Diagram is the meaning.

Let me just say that BPMN is a modeling notation for designing processes and XPDL is a superset that also contains graphical features of the actual drawing. Therefore we decided to cover both in the Papyrus Platform. Why did we do that if I am so opposed to BPM? As you might know, my opposition is mostly related to the huge, disconnected analysis and optimization process bureaucracy. Therefore we defined standard BPMN/XPDL to be used as execution engine:

BPMN/XPDL in the Papyrus Platform can be created and edited while you work and executed AS-IS.

It is fully executable by linking with the UML data models, content artifacts and Natural Language Rules defined in our Papyrus WebRepository. Also BPMN/XPDL is stored in the WebRepository using Papyrus’ change management and automatic, distributed deployment capability. All additional logic necessary is cleanly encapsulated in those classes and is not created during BPMN conversion into BPEL or by expansion with Java. BPMN in Papyrus is mostly used to define sub-processes in our Adaptive Process concept. The user interface is handled by our Papyrus EYE widgets so there is no XSD/XSLT mapping and Ajax forms programming. The business data are simply accessed through the UML classes linked to our Service Adapters (SOA and others). Finally, BPMN can be used in an Adaptive Process environment and allow 100% runtime editing.

Here is the Papyrus Platform BPMN/XPDL 2.0 Designer:


5 thoughts on “BPMN/XPDL Execution in Papyrus

  1. Executing without converting to another form is a quality called “Model Preserving Strategy”. What that means is that all parts of the system, all users of a system, if they look at a model, or manipulate a model, they always see the same thing. There may be some differences in the visual treatments of the model at different point, but the form of the model remains fundamentally the same.

    The opposite approach is called a “Model Transforming Strategy” where the process diagram is transformed from one form to another at different points in the lifecycle. Thus designing a process as BPMN and then transforming it to BPEL is a transforming strategy. This is the standard software engineering model where a 3GL source is transformed into machine code.

    See a summary of these concepts at:

    The advantages of a Model Preserving Strategy is that it is easier to debug, simulations are more representative, there is no problem with information loss due to transformation, and different roles can work simultaneously on the model, with the results being greater agility.

    There are advantages of Model Transforming Strategy around optimizing the use of different resources, providing either greater performance in the execution environment, or ability to leverage programmers without having to learn the process language.

      • Hi Keith, the benefits of the Model Transforming Strategy are also preserved with our Papyrus BPMN/XPDL implementation, i will briefly explain why.

        As Papyrus BPMN/XPDL is build as Framework in our Repository it benefits automatically from the Papyrus node architecture (peer2peer) which makes it unlimited scalable. Papyrus allows instantiation and execution of processes on any node, regardless the OS, it can even work off-line on a laptop (e.g. field worker).

        Papyrus BPMN/XPDL benefits from build in functionality as Version management, Lifecycle management and Security and integrates out-of-the-box with our other Papyrus solutions like Correspondence and Case Management. As the Papyrus Archive is using an Object Database we are able to Archive the whole process with all its content and state.

        For the Developers its good to know that its all Class and Template definitions (following XPDL 2.1). Anyone with OO and Papyrus knowledge can extend our implementation as it is not propriatary software.

        Although modeling can be done using our Business Process Modeler (business users), there is no need to do so for the developers. Developers can choose to directly instantiate classes and templates, set attribues and execute methods. This would allow developers to create and change running processes on the fly, e.g. adding a Task or re-assign a Task.

  2. Pingback: Is BPMN the DNA of Process? « Welcome to the Real (IT) World!

  3. Pingback: 2010 Blog Stats | Papyrus Platform Architecture

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s