Although BPMN 2.0 is an international standard widely used in practice, interoperability of process models is still an issue. Even between tools and engines claiming to be BPMN compliant the model exchange is often complicated or impossible as the tools produce incorrect model representations or do not support the standardized BPMN serialization format. In this position paper we present reasons for interoperability issues and show why defining a set of constraints derived from the standard is crucial to fix an important subset of those issues. We are currently developing a tool which can check this set of rules automatically.
2 see for example the “BPMN-I” initiative of Bruce Silver (http://www.brsilver.com/ 2011/04/05/a-profile-for-bpmn-interoperability/)
The reasons for incorrect models and therefore interoperability issues are manifold but can be divided into two main groups: – Vendor Policy: The usage of a proprietary serialization format, missing import and (especially) export functionality is often intentionally used by vendors. Either the ability to switch to competitive products is limited (vendor lock-in) or a simpler format is used to comply to the internal meta model. This is especially the case when a tool is not initially designed for BPMN models but an existing process and workflow modeling tool is enhanced to deal also with BPMN models.
For instance, the BizAgi Process Modeler3 is not able to handle BPMN
models saved in the format proposed by BPMN [
As vendor policies may not be affected easily, we focus on giving support for
implementation issues. In order to observe all rules it is needless to say that an
overview of all constraints stated in [
Sources for constraints in the standard document are the running text, tables, class diagrams and XSD excerpts. The extraction of rules from the latter sources is rather straightforward (e.g., mandatory attributes, cardinalities, value constraints). In contrast to this, constraints in the running text are harder to identify and frequently some interpretation of the text is needed. We worked through the standard document and in a first iteration we derived more than 300 rules.
Moreover, in about fifty cases inconsistencies between the text and/or the class diagrams and the XSD have been revealed. Frequently some attributes of elements are defined as mandatory in the text and the class diagrams, but the
schema definition marks the same attribute as optional. To give an example: Even the definition for the BPMN root element definitions is affected by this problem: Table 8.1 in [8, p. 53] states that the attribute name is mandatory. In contrast to that, this attribute is completely missing in the XSD excerpt in Table 8.3 [8, p. 54] and is defined as optional in the normative XSD schema6.
In order to improve and check the completeness and correct interpretation of our rule set, we are currently cross-checking it with other less extensive collections of BPMN constraints7 and with the consistence checks integrated in various tools8.
Based on a consolidated list of rules for BPMN models, it is possible to check whether a serialized process model is consistent to this rule set (and therefore to the standard itself).
Parts of the extracted rules can already be checked by performing a XML
schema validation. An example for such rules are value limitations, as for the
attribute gatewayDirection of a BPMN Gateway. Here only the values
’Unspecified’, ’Converging’, ’Diverging’ or ’Mixed’ are allowed. This restriction is
realized as a XSD SimpleType restricting Strings (see [
However the overwhelming majority of constraints cannot be covered by
schema validation. Specific examples can also be found in the context of BPMN
Gateways: Gateways have incoming SequenceFlows which are realized as incoming
sub elements that refer to a SequenceFlow definition using a xs:QName reference.
With XML schema validation, a reference to an arbitrary or even non-existent
BPMN element would be regarded as correct. Moreover, depending on the value of
the attribute gatewayDirection the number of incoming and outgoing sequence
flows has to be limited in a different manner (see [
To tackle these issues, we are currently developing a tool to check all extracted rules which are not covered by schema validation yet. 4
Academic research mainly concentrates on semantic validation, verification and
correctness checks for BPMN models [
Closer related to our work is [
itp-commerce.com/index.php?id=81&L=0) by now, as BPMN 2.0 provides a standardized XML interchange format. Nevertheless, the proposed usage of XML Technologies like schema validation which is now used in the current version of the standard is able to check some basic rules as stated above.
A good example for the importance and practical benefits of a list of relevant
constraints for a process language standard is the Web Services Business Process
Execution Language (BPEL) [
The main contribution of our work will be an extensive set of constraints stated in the standard and a tool checking these constraints. These contributions provide a basis for the successful practical usage of BPMN. The rule set and the tool may be used by modeling tool vendors and engine developers to check if their software generates, respectively is able to import and deploy standard compliant documents. It might be used during import stages in order to reject non-compliant models or to benchmark different tools/engines regarding their standard compliance.
As a side effect of our work we are able to report several issues to the BPMN 2.1 Revision Task Force to improve the upcoming version of BPMN.