Top 10 wish list for BOP4 fix pack 1.

2011 will be an exciting year!

One of the reasons is the expected major release for Cordys BOP4: Fix Pack 1! (Maybe already in Q1?)

Though already am a “fan” of the current product (See my blog: Why Cordys BOP4) I have my top 10 wish list ready:


1. BPMN 2.0
As the formal release of BPMN 2.0 is due soon, and 99 percent of the standard is stable I hope for a solid support of this standard in FP1.

Especially extension of the event- and signaling mechanisms, and the addition of compensation constructs would be valuable features!

2. Data modeling
Currently it is possible to define data structures in BOP4. Additional UML class diagram-like modeling would greatly support the process of defining and communicating the business object model in a graphical way. Obviously MDM would profit too.

3. BAM Usability
As I already wrote in an earlier BLOG BAM Imperfections there are several possibilities to improve usability and flexibility of BAM. The good news is that Cordys already committed to these improvements, so expectations are high!

4. Document support BPM
Case Management already supports a kind of out-of-the-box document management. It seems little investment to allow documents to be attached to BPM Instances as well. This would prevent the need for a custom solution based on an external DMS or database solution.

5. Simulation
A fair simulation environment would be a welcome extension to the BOP4 stack. It should allow for defining the expected loads and spread, and the characteristics of the resource capacity. Reports over the simulation runs should allow for proper analysis and process optimization.

6. Complex Event Processing (CEP)
In automated environments where decision making is depending on the combination of several (types of) events Complex Event Processing (CEP) is a must-have. Addition of a CEP module would greatly increase the applicability of BOP4.

7. “Hot” business rules
BOP4 offers great facilities of defining business rules and decision tables. The feature of allowing business to “hot modify” the (values/business parameters of) rules without having to republish or redeploy them would increase the flexibility of the concerned business processes.

8. User interface: modeling versus scripting
For some fairly basic UI functions it takes java scripting in BOP4 (Example: the invocation of a business process). It would improve development efficiency to allow developers to model such behavior instead of scripting it.

9. BPM Complex Mapping
The BPM data mapping possibilities in BOP4 are quiet sophisticated. However certain types of mappings are not yet supported in the BPM mapping tool, where the underlying technology XSLT would allow so. Example: the mapping of two lists onto each other. One of the work arounds is to model these mappings in the BPM itself, obscuring the intended business functionality. Extension of the mapping functionality would prevent this necessity.

10. Reporting
Where BOP4 offers fairly advanced BAM functionality, plain reporting functionality is missing.
As the Cordys Process Factory (CPF) offers reporting functionality it should also not be rocket science to get it available for BOP4 too.

As Cordys claims the BOP4 product itself is the most valuable marketing instrument I have great expectations and I hope that (a late Santa) will generously fill my sock!


Harald van der Weel

Getting started with BOP4: Cordys Academy self study Training

 
I have received several requests to inform people on “how to start off with BOP4”:
Where to begin, how to learn about the features and how to get hands-on experience?

The good news: Cordys has recognized this need!
One of the reasons I have become eager to adopt Cordys BOP4 is the simple fact that Cordys Academy offers high quality training facilities.

Not just the conventional classroom courses: Also a great computer based BOP4 fundamentals! For free, and it can be taken anytime, anywhere!

The Cordys Academy is offering basically a complete package, consisting of the following:

-          Self study environment

Link: https://wiki.cordys.com/display/acorg/Cordys+BOP-4+Self+Study+Training+Environment

-          Fundamentals Tutorial

Link: https://wiki.cordys.com/display/acorg/Cordys+Fundamentals+BOP-4

-          Several advanced topics (“Training extensions”)

Link: https://wiki.cordys.com/display/acorg/Training%20extensions

Access to these sites only requires registration.
This can be arranged instantly through any of the links above. Each will result in the login screen below:



Selecting “New User? Register here” will show the form below.

 
Complete the form and follow further instructions to register.

Once done… you are ready to “play”!
 
Self study environment

The self study environment (I’ll call it “sandbox”) is nothing but a single downloadable VM-ware image!
It is configured as a complete Cordys server the provides all main functionality.
Apart from allowing “students” to do all practical exercises in the tutorials, it even would allow you to do a complete project (for the 3 months license period at least)

Provided you have a VM Ware player (free downloadable at http://www.vmware.com/ ), setting it up simply requires the following steps:

1.       Download the zipped VM Ware environment (It is rather big: Zipped about 2Gb, unzipped about 6Gb)

2.       Unzip the VM environment

3.       Run the VM image

4.       Start a browser session (for the moment IE7 or IE8)

5.       Go to the startup URL (Specified in the Setup and User guide)

6.       Start using Cordys BOP4, provided a default Student1

(If still more info is required: The steps above are well explained in a “Setup and User guide”, that can be downloaded from the “self study environment” page)

This sandbox allows to manage users and provide them with the necessary roles to develop, test, deploy, execute and monitor almost any Cordys work product. The sandbox even allows to use an external SVN version control system to store and version all work products externally from the VM Environment.
The sandbox even provides an example MySQL database with content and web services.

The link to the Self Study Environment is: https://wiki.cordys.com/display/acorg/Cordys+BOP-4+Self+Study+Training+Environment, which invokes the page below.


Fundamentals tutorial

The fundaments tutorial teaches novice Cordys BOP4 users everything to know about the BOP4 environment.

Multiple tutorial “chapters” take the user sequentially through all necessary subjects, in order to make a start with Cordys BOP4.
Each chapter contains theoretical information (documents and presentations) and hands-on exercises to practice the learned skills. The exercises are very concise and even suitable for people with very limited technical skills.

Subjects that are covered are:

-          Overview and introduction to the Cordys environment

-          Managing users and setting up a new project

-          Developing business processes (BPMN models)

-          Developing and using services

-          Developing user interfaces

-          Developing workflows

The exercises of each module should be executed sequentially, because there are certain dependencies between them.
They will provide a starting developer with the basic skills to build and run simple BPM solutions.

Note that doing all tutorials will take between about 3 and 5 days to finish, depending on your experience in similar environments.

The link https://wiki.cordys.com/display/acorg/Cordys+Fundamentals+BOP-4 takes you to the page below. The order of the modules is Top-Down


Training extensions

A number of advanced BOP4 topics are offered in “Training Extensions”.

This concerns topics that elaborate certain topics in the fundamentals, but also subjects that have not been covered yet before (like Business Activity Monitoring (BAM) or Case Management).

In case of requiring more in-depth knowledge or considering certification these training extensions are a valuable source of information.

The link https://wiki.cordys.com/display/acorg/Training%20extensions will take you to the following page:


Conclusion

Cordys provides great means for organizations and users to gain knowledge about the BOP4 product from scratch at no (direct) cost.

Please bear in mind:
A computer based training may provide you a good starting point. Effective skills are mostly built up by actually applying them in a practical situation.
I would advise starting teams to involve an experienced developer/solution architect, for a number of reasons, like:

-          It provides a direct productivity gain

-          It helps to properly setting up the project and guidelines

-          It will (cross)-train your inexperienced team

-          It will solve “blocking issues” faster

-          You may profit of the network of the experienced developer

Good luck to all new Cordys BOP4 adopters.

Hope to meet you in a future project!

Business Objects in BOP4

 

Introduction

Maintenance of Business Objects is required for most business processes.

MDM has an important role in enterprise data management and quality. It provides a “single point of truth” in the enterprise and allows connected  processes and service to use “the latest and greatest” and clean business data. MDM therefore is the preferred way to manage business data.

 

If MDM is not in place, and business objects are not maintained in backend-applications there are mainly two ways how to maintain and persist business objects:

1. A dedicated solution database
2. Object Templates

 

This blog will briefly zoom in into these options

 

Options

 

1: Dedicated database

 

This option can be compared to the traditional application development approach. From the logical data/object model a technical data model is developed. This model describes the database tables and the constraints like primary keys and relations. Based on this a database can be created, preferably separate from the Cordys database instance.

Cordys BOP4 provides the feature to query the metadata of a database, and to generate standard or customized web-services to access the database tabels. These web services should be deployed on a WS-AppServer container, before they can be used e.g. in XForms or BPM-s

 

Cordys allows developers to add business rules to these web servcies in order to perform additional validations and control the lifecycle of these business objects, represented by the database tables.

 

2. Object Templates

 

Object Templates are a construct that is offered by Cordys BOP4.

 

It allows to define data objects based on Schema fragments. The developer may specify constraints and validations, attach (execution-) rules en specify whether or not changes to the the object are subject to audits. Besides that it is possible to specify if the object should be persisted by Cordys. If that option is selected the instances of the Object Template will be stored inside the CoBOC database (the database used to store information about the BPM instances).

 

Object templates can be accessed using the following CoBOC WebServices:

 - UpdateXMLObject to insert, update or delete an object

 - GetObjectsByAttribute  to retrieve a object

 

Obviously these can could be embedded in a dedicated Webservice per separate Object

 

 

Best pick?

Both approaches above have pro-s and con-s. The "best" choice depends on project or architectural requirements:

 

Dedicated database

Pro-s

• Open database format (Data can be accessed easily from outside)
• More control on data (Separate database, custimizable WS services for data access)

Con-s

• Data layer should be maintained manually
• Separate WebServices are required

 

Object templates

Pro-s

• The data-tier remains hidden
• More productive because of less required steps and objects
• Audit possibilities

Con-s

• Cordys specific data format and Web Services to access data

• Data stored in CoBOC, so it may impact BPM execution performance

 

Depending on requirements (e.g. portability, testability, traceability, maintainability) one should decide on the way to go.

 

 Regards,

 

Harald van der weel

 

Event-state modeling in Cordys

 

Case

Recently we have been working on a solution that can be considered as a message broker / hub:

It’s functionality is mainly to receive, validate and route messages between parties in a specific business segment over different channels.

 

All messages have a specific type, syntax and semantics. Messages may be interrelated; e.g. one message may be a response to another message. A business wide protocol-standard describes the complete interrelation between message types, and specifies the possible sequence of messages in a flow: A so called "conversation". In a conversation any message of a specific type can be only followed by a message of one or more other specific types.

In case we want to monitor conversations we need to model the messaging protocol. This protocol can be considered as an event-state diagram: The last received (and expected!) message in the message sequence reflects the state, and the reception of a new message reflects an event.

 

Multiple concurrent conversations may be active at a time. This requires a correlation id to link the reception of a new message (see  the previous blog “Events in Cordys”) to an active conversation (or to start a new one, if there is no flow active for that particular correlation id).

 

Implementation

What does it take to implement such an event-state diagram in Cordys BOP-4?

 

The core of the solution consists of three processes, a decision table and a database-table (with access web services):

• Monitor-process: A process that describes the state model
• HandleMessage-process: A process that is started on new receives new messages and that triggers events.
• WaitForEvent-process: A process that actually waits for an event to be triggered by HandleMessage, where the message is passed
• StateTransitions-decision table: A decision table containing all valid state transions that can be triggered by a message. 
• InstanceCorrelation- database table: A database table for storage of the instance id and correlation id

 

Monitor-process

Monitor is the main process. It describes the overal state model. At runtimes each instance reflects a conversation and it effectively keeps the current state of the “conversation”. A Correlation Id is required to correlate the messages to this conversation. The Monitor process simply consists of a number of states that are interrelated: From a particular state an occuring event may cause a transition to one of one or more possible new states. A state is in fact nothing more than a sub-process call to WaitForEvent. WaitForEvent waits for an event and after a correct (expected) message is received it returns the resulting (new) state to the monitoring process. Only in case a state may have more than 1 possible resulting states the monitoring process should use a decision to effectuate the correct transition. All other logic is handles in the WaitForEvent (by invoking the StateTransitions-decision table)

 

Because the Monitor-process is started with the first message of a new conversation it has an input message, having the same format as the messages received by WaitForEvent.

 

     Example of a monitor process

 

WaitForEvent-process

Monitor specifies two main parameters to the WaitForEvent-sub process: The current state of Monitor and the Correlation Id that belongs to the conversation.

The first step in the WaitForEvent is to store its Instance Id in a “InstanceCorrelation” table, together with the Correlation Id before invoking the “Receive Message” step. (See also my previous blog “Events in Cordys”).

Once an event has been triggeredby the HandleMessage-process the WaitForEvent event checks whether it is an event that it expected, depending on the current state. The logic for this check is implemented in the decision table "StateTransitions", that I will explain below.

 

If a message is received that is not an expected successor of the current state, an exception occurs that ought to be handled. (In our case we simply log an “Unexpected Message” error). After this the process waits for a next event to be triggered.

If the message that is received is expected however, the decision table returns the “new state”, which is returned to the monitoring process. Before returning to the monitor however first the InstanceCorrelation table is cleaned up by removing the record that was inserted at the beginning of the process.

 

    "WaitForEvent"-process  

 

HandleMessage-process

HandleMessage is triggered at reception of a new message. It first uses the correlation id in the message to look up a corresponding Instance Id of a waiting process in the InstanceCorrelation table. If no such record is found, we use the decision table to check if the event is an start-event for a new conversation. If so, a new process instance of Monitor is started -via the invokation of a generated Web Service on Monitor-  and passing the message.

In case the Instance Id is found, a notification to WaitForEvent is sent using ExecuteProcess, passing Instance Id and the message (as explained in my previous blog “Events in Cordys”).

 

    "HandleMessage"-process

 

StateTransitions-decision table

The StateTransitions decision table contains all valid "current"state - message combinations, and the resulting new state. (Similar logic may also be implemented e.g. in a matrix, implemented in a database table, see also my blog "logic in Cordys").

 

Note that actually all logic on state transitions is effectively implemented in this decision table, and not in the Monitor process: The Monitor process is only intended to keep the current state of a conversation: Not to execute any transition logic, apart from navigating to the correct new state based on the out-come of the StateTransitions decision table!

 

    "StateTransitions"-decission table

 

Later I will zoom in on the reporting over the monitoring process.

 

 

Regards,

 

Harald van der Weel,

e-mail: haraldvanderweel@gmail.com