2010/05/26

Cordys - Exposing business process as webservice

In our project we have to trigger a business process within Cordys. In Cordys it is possible to expose the process as a webservice.
This blog item describes a simple example how to do this.

1) First we create a simple business process.


2) We expose the process as a webservice. Select the process in the Cordys WorkSpace (CSP) and select Business Process Execution > Generate Web Service


3) Fill in the next window and click Finish



3) Now you have to add the Web Service to a service group, so go to the System Resource Manager and select the Cordys Services Service
Add Web Service Interfaces
Select Organization1 and select the ExampleProcess interface. Click Save.

4) Now you are able to call the Webservice. You can test the webservice. Select starProcess > Test Web Service Operation > Invoke


5) But how do you call this webservice from outside the Cordys environment to start a Business Process ?
You can view the WSDL of this interface by startProcess > Show WSDL
What I noticed was the strange looking endpoint:
<wsdl:service xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="ExampleProcessService" >
   <wsdl:port xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="ExampleProcessPort" binding="tns:ExampleProcess" >
<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" location="com.eibus.web.soap.Gateway.wcp" />
</wsdl:port>
</wsdl:service>
I used the Fiddler tool and the Test Web Service tool (described in step 4) to see what the endpoint must be:
In the VM image of this Cordys installation this is http://192.168.154.128/cordys/com.eibus.web.soap.Gateway.wcp
In fact this is the Gateway endpoint of Cordys.
So now you can use the WSDL and this endpoint to test it within soapUI.

2010/05/25

Cordys: The ESB

I sometimes hear that Cordys is only a BPM tool. This blog item describes the ESB of the Cordys platform, also known as the SOA Grid.

Introduction

The BPM layer of Cordys is built and runs on the SOA grid of the BOP4 platform. This SOA Grid is the integration ESB of Cordys.
It also has, like other ESBs, adapters to files, webservices, databases etc. It has transformation logic.
It is all on board but maybe somewhat hidden because it is integrated within the platform. All components are services and run on the SOA Grid.
It also uses maybe somewhat other terms you are already familiar with, like Service Groups, Service Containers, Application Connectors.

Service Messages

SOAP Messages over http are used to transfer service messages. Calling a service is done by sending a soap request.



The soap messages arrives at the webserver (Apache or IIS) and there the user is authenticated. The message is sent to the Cordys Web Gateway. There the message
is transferred to a Service Container. This is a container that processes the service request. In fact the service container is just one part of the implementation
of a Service Provider.

Such a Service Provider contains Connection Points, that defines the entry point of the service container. Several protocols can be used here like JMS, TCP/IP, MSMQ.
The Service Container part is responsible for the routing and for passing the request to the proper Application Connector (also known as Adapter).
This Application Connector is the connection to the backend systems.
So how gets a service request routed to the correct Service Container.

Service Groups and Service Containers

Each web service operation has a namespace attribute and these operations are grouped in Web Service Interfaces. These are stored in LDAP.

Service Groups are also stored in LDAP and they contain access and routing information. It is a logical entity to group a set of service containers.
All interfaces in the service group share the same namespace and together with the operation name the request can be routed to the correct container.



More info can be found on http://wiki.cordys.com

2010/05/23

SOA Service Design Principles by example

First some context

I a project i had to couple a PeopleSoft system with Planon.
PeopleSoft is a HRM system used to store information about employees (in this case) and Planon is a facility management tool so that employees can order facilities.
When a employee is employed within the company, this employee has to added to the HRM system and this employee has to be authorised within the Planon system.
In the past this synchronization was done (as you see often) through a CSV file.
In the new architecture this kind of synchronization has to be done through a ESB (Enterprise Service Bus). In this case the Oracle Service Bus.

Service Naming

I wanted to add a new Service for this, so the first thing you do it to come up with a Service Name.
A couple of mistakes you often see is:
* The name is the same as the project name.
This is of course not done, because in a couple of months this name is forgotten and has nothing to with the functionality of the service at all (most of the time).
So the Discoverablity service design principle is also jeopardized.
* The name is the same as the name of the system (in this case Planon).
This goes against one of the overall goal of Service Oriented Architecture, namely vendor diversity.
In case you happen to change the system, the name of the service is useless but already Service Consumer may use the service.

The name I have chose is FacilityManagementAuthorisation.
The reason is that the functionality of this service is about authorising employees within the facility management system.
So this is the service naming design part, next is the Loose Coupling.

Loose Coupling

We use the Oracle Service Bus to decouple the service interface of the service from the actual implementation.
The OSB has the concepts of ProxyServices and BusinessServices.
If you ever worked with Planon and its webservices you may have noticed that these webservices are exactly that, without considering service oriented principles.
They are generated straight from the database tables and for each entity a webservice is generated.
For example you have a Person entity that contains information about the employees.
Before you can create Person entities you have to use the Session webservice to login.
Then change some Person attributes, Save, logout.
This is not the way you want to expose this as a Service. This is not the correct Abstraction. This way you would create a Service Contract - Implementation coupling.

So what should be done instead. This is where BPEL comes in! This is a technical orchestration language that is used to chain some backend calls to the Planon webservice.
In this case i created the following Service Interface:
* authoriseEmployee( Employee ), This operation authorises an Employee within the facility management system.
* removeEmployee( EmployeeNr ), This operation removes the employee from the facility management system.

I hope this small blog item gives you some insight in the choices you have to make when delivering SOA Services.
Comments and Additions are welcome!