Cordys BPM Constructs 101a

I’m now really quite comfortable with Cordys process modelling and the models component constructs.  There are simple differences between certain constructs that I’ve used in other products such as MS Biztalk so I wanted to absorb the Cordys documentation and present a sort of quick and dirty intro to each construct and how Cordys uses them to execute your processes.  As there are several constructs and I wanted to go into some detail, I’ll present some of them here and the rest in a subsequent article.

If you don’t already have a copy of the Cordys community edition VM that runs C3 or BOP4 on a CentOS virtual hard disk, I’d suggest getting hold of it so you can ‘play’.

/*Note that most of the constructs can only be used if a user is granted the Business Analyst role, from the Cordys Classic Studio ISV package.*/

Start Event – Only one per process. Can have several trigger types:

– Message (a defined process specific message)
– Timer (by setting a time unit (e.g. days) and no of occurrence
– No Message or Timer

End Event – Process can have multiple end events. Error, Message and Rollback. You define an output message by dragging a ‘Document Type’ from the BPM Components repository to the end event. This then invokes a web service as the process ends. You can specify custom error XML in the ‘error details’ tab of the end event.

Activity – The activity is the construct that represents a generic step in the process and should be configured with an activity ‘type’. It can be of type ‘Application’ (web service calls) or ‘XForm’. When of type XForm, an additional XForm tab becomes available in the activity properties.  An activity can also be set to be a ‘dummy activity’ meaning it does nothing.  Each
activity can be conditionally executed based on conditional evaluation returning a boolean result.

Decision – The decision is a basic construct that allows multiple mutually exclusive outputs. It’s actual conditions are defined in the connectors that exit the decision construct and Xpath evaluations can use message map data for data driven decisions.

Intermediate Message Event – The intermediate message should have a process specific message defined and is invoked when a message is received to the process.  Normally this is used to ‘wake’ a waiting process instance. The gateway inmessage based on the process instance id (ensuring message correlation).  For asynchronous web service calls, an intermediate message can be used to receive the response message from a service operation call. Dragging the output message from message map will set this.  Therefore it is useful to know whether
the operations you are calling via your activities are sync or async.

Compensate Event – Used to rollback any effects of an activity or context or activities when an exception is caught.  A compensate event can be defined for an activity, sub-process,
context (embedded sub-process), for each, while and until loops. An activity or sub-process can only have one compensate event associated. Compensate is represented as two left pointing arrows, side by side in a circle.

Delay Event – An intermediate event that stalls the process for a configurable amount of waiting time. Delays can be of type:
– Fixed delay.  That is a set amount days, hours, minutes or seconds.
– Message read delay.  That is a delay value read from a process specific message using an Xpath reference. As with a standard activity, a delay may be conditionally executed based on a boolean return evaluation.

Exception Event – An exception is an event which is fired when a Cordys error occurs (e.g. a soap fault is detected via external service responses or via SOA grid messages).
As you would in programming code, you can specify a specific exception name to catch or just catch any exception.  Once an exception is thrown, process execution is diverted to the connected exception event where subsequent exception handling activities should follow.  There are several error types which can be caught and which are configured on the exception event construct:
– All. All exceptions are caught, regardless of the error code.
– Custom Error. You can set an error code you may expect from a service response indicating an error has occurred (e.g. a SOAP fault
– System Error. Simply put, a Cordys internal error where some part of Cordys may not be operational (a soap processor may be down for example) or syntax rules are broken.
– Communication’s Error. These errors are specific to SOAP faults returned from external service calls. Error code 11 is returned for comm’s failures.

There are error codes that are only raised when a sub-process is being invoked from a parent. These are:
– Process Loading Error
– Process Instantiation Error
– Process Model Not Found Error

… more to follow soon!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s