Cordys: Sharing Message Maps

Cordys has a handy feature and that is of sharing Message Maps. A main process can share its message map with child processes.

The way to do this:

1) Select the sub process within your main process and select Properties

2) Check the Share Message Map

The Message Map is automatically copied to the subprocess. However sometimes this is not the case and the easiest way to do this is to copy
the message.

3) Goto the Mesage Map of the main process and select a Message and right click Show XML

4) Copy the XML
5) Goto subprocess and select Paste XML as Element

This feature is handy when you want to use a generic Message within your process


Exception handling in Cordys BPM

A couple of days ago I was discussing the handling of all kinds of errors within your BPM.
In this case within the Cordys BOP4 product.
To handle technical errors (like a webservice can not be reached due to system crash) and functional errors the "normal" BPM flow gets blurred with all these exceptions.

We discussed ways to handle this:
1) Using different Views on your BPM (this is not (yet?) a feature in Cordys), so viewing your BPM with/without error handling)
2) Using different colors in your BPM
3) Using Embedded Subprocess

Example of option 2

Example of option 3


Cordys BOP External Services Configurator


For external webservices within the UDDI connector you have the possibility to configure the endpoints of the webservice.
This way in each environment (Development, Test, Acceptance, Production) you have a way to configure the endpoint differently.
You can use the External Service Configuration. However when I did this i ran into a problem.

Import WSDL

To use an external webservice you can import the WSDL.
  • Goto Workspace Folder where you want to create the webservice (probably a Web Services Folder somewhere).
  • Right-click New > Other > Web Service
  • Select Import WSDL as the source, give it a name and description
  • Next you have to give up the URL where the WSDL is located
    Note: This can be ackward but for the moment not the issue i got

Give logical endpoint to the service

When you look at the properties of the imported webservice by double click on it you will see:

I advise to change the <serviceuri> into a more logical endpoint name instead of the one filled in after importing the WSDL.
This way you will be aware that the correct endpoint still has to be filled in within the External Services Configuration tool.

  • Goto External Services Configuration
  • There you will see the logical service uri and the physical endpoint

Problem when test webservice

However when i tested the webservice I got the following error:

So it appears that the logical endpoint is taken instead of the Service URL as defined within the External Services Configuration.


When you restart the UDDI connector it takes the correct endpoint.


  • Use logical names within the webservice properties
  • Define the real endpoint with External Services Configuration
  • Restart UDDI connector when the endpoint is changed


What to put in BPM?


When implementing a BPM or using a BPM tool I see a lot of functionality that (in my opinion) does not belong into that layer, but within a SOA Service.
But are there some general rules or guidelines that you use to decide what to put in BPM and what to put in a Service?
This blog item is a first try.

Put in a Service

This is a list of items/functionality that I would put in a Service:
  • Static calculations not dependant on business data (example: Fahrenheit to Celcius calculations)
  • High performance / complex calculations on data (example: complex calculations over series of data)
  • Technical orchestrations (example: Getting data out of several different databases)
  • Sending messages (in a particular format) to another department or even another organization (B2B)
    (example: ebXML messages, HL7 messages)
  • Adapters (example: database-, file-, mailadapters)
    These are always implementation specific in most cases and the implementation should be abstracted with a service.
    However in most cases you will see these adapters used within the BPM tools.

Put in a BPM

This is a list items/functionality that I would put in a BPM:

  • A step in a business process implemented in a Service operation or sub process.
  • Scheduled triggers to execute a business process (example: every day execute a particular business process)
    You can put the schedule in a business rule to make it flexible
  • Steps / Activities that mean something to the business
    Remark: Discuss in depth because even business people dive into technical details.

You are invited to increase the list !


I think there will remain discussions where to put which functionality. With the BPM tools nowadays you can use integration software that you do not want in the BPM layer, like
a database adapter or file adapter. This should be put in a Service and abstracted. However time-to-market and ease of implementation is often a (maybe valid) argument to
do it like this. But hope you take a step back and think about it when you use a BPM tool because also with this tool you can make spaghetti !
And last but not least: Do not use a BPM tool as just another visual programming tool


SOASchool: Module3

Friday I had my 3rd exam SOA Design & Architecture.
In this exam you also get 50 questions and you need to have 80% right.
This exam is about understanding the 8 principles of Service Orientation.
It has strong resemblance with the first module, but this exam was more detailed.

Up to module 8 of my SOA Architect Certification.