Difference between revisions of "BPMN2-Modeler/DeveloperTutorials/Validation"

Revision as of 18:16, 16 June 2015

Versions

This Tutorial was developed with Eclipse 4.4 (Luna) and BPMN2-Plugin version 1.1.3.

The Basics

BPMN2 model validation builds on the EMF Validation Framework and supports both "Live" and "Batch" mode validation. There are lots of resources and tutorials on the web that discuss EMF validation; to get started, define an "org.eclipse.emf.validation.constraintProviders" extension point in your plugin. This extension point defines all of the validation constraints that will be evaluated, and when.

Live vs Batch Validation

"Live" validation is performed just prior to a model change is committed; if the validation result is anything but IStatus.OK, then the change transaction is rolled back and the error message from the constraint handler is displayed in the Workbench status bar. These types of validations are useful for preventing the model from becoming corrupted, and possibly unreadable. A good example of this is BaseElement ID validation: ID strings must follow the NCName naming convention, and they must be unique within the file since EMF uses these to resolve forward references of objects. Saving a file with an invalid ID may result in the file being unreadable since the object is not resolvable.

"Batch" validation is performed whenever the file is saved, or if the model is manually validated (right-click on the diagram, then "Validate".) This type of validation is more common and checks for semantic problems in the model; the model is essentially valid, well-formed and syntactically correct, but there may be specific conditions that must be met for the model to make sense. For example, if a Process has been defined as "executable", all data items must specify a data type (i.e., ItemAwareElement.itemSubjectRef may not be null.)

Constraint Language

EMF allows you to write your validation rules in either OCL or Java. We have found that for most situations it is best to use Java for writing validation rules simply because many of the constraints are very complex, sometimes involving lookups and validation of referenced elements as well.

Target Classes

EMF constraint providers must declare a namespace URI which defines the model being validated; in our case, this is the BPMN 2.0 model and the namespace URI should be "http://www.omg.org/spec/BPMN/20100524/MODEL-XMI". The constraints declared withing a constraint provider then simply refer to the model type to which the constraint applies.

If however, you have found it necessary to provide an external model for your extension elements (see BYOM!), and you need to perform validation on those objects, there is a caveat: the constraint definition must qualify the Target Class with the namespace URI of your external model. For example, the jBPM extension defines an object named GlobalType in an external EMF model; this model has the namespace URI "http://www.jboss.org/drools". To define a constraint for a GlobalType object, we would simply define it like so:

            <constraint
                  lang="Java"
                  class="org.eclipse.bpmn2.modeler.runtime.jboss.jbpm5.validation.JbpmModelConstraint"
                  severity="ERROR"
                  mode="Batch"
                  name="Global Type"
                  id="org.eclipse.bpmn2.modeler.runtime.jboss.jbpm5.validation.GlobalType"
                  statusCode="1">
               <message>{0}</message>
               <!-- Note use of namespace URI to qualify GlobalType -->
               <target class="GlobalType:http://www.jboss.org/drools"/>
            </constraint>