The usecase for my sample application is:
A standalone application exists to create/update 'Departments'. Originally, it was not intended to be part of an automated process (BPEL or BPMN) but now business decided that their process for the creation of a department is actually more than just data entry in the standalone application. It also now involves an approval.
1. Every interaction with a software application in a business environment is part of some process - the process may or may not have been analysed, modelled in a standard notation or automated, but it's a process nonetheless.
2. When we interact with software applications, we generate 'events' (Order fulfilled event, Loan approved event, etc.).
3. The sample applications for this post can be downloaded from here and consist of:
a) The SOA/BPM composite application - event listener
b) The standalone ADF web application - event producer
(Instructions to setup and run the sample are towards the end of this post)
From a technical standpoint:
Before BPM was implemented, the DepartmentCreated event used to be a simple insertion of a new row in a table. Now, it will lead to a longer process involving an approval (and possibly other human/automated tasks). From a technical standpoint, we are really not looking to change an existing application such that it becomes tied up to specific API's.
With an event driven architecture, the SOA/BPM infrastructure listens to things that happen around your enterprise landscape and take appropriate action when required (in this case, it needs to start a process when a Department is created).
My simple Process model:
1. Process roles
I have created three abstract roles for the process - the 'ADF application user' always existed, because, people were always creating new rows in a table called 'Departments'.
We now have a new 'Approver' role. (For convenience, I have mapped the default 'weblogic' user to 'Approver')
The third is the automated handler for automated tasks.
2. The activity 'Create a department' is meant to represent from the perspective of the business process. The thing to note is it's represented as a manual task and not as a (initiator) human task.
As I mentioned before, it is JUST a standalone web application with a facility to create/update Departments and from a technical standpoint, it is not even 'aware' that it is a participant in a business process.
3. Structure of the composite
My process does not expose any SOAP endpoint (as it's 'Start' event is not a 'message' but a 'signal').
4. The start signal.
It's 'implementation type' is 'Signal' (not 'message', which is the default) and note the Event that it listens to.
Something interesting to note here is that my process data object is based on the same model as the domain objects (Entities) I created for the UI application i.e. we do not need to create our domain model twice - we levarage the one we have.
We can also reuse the definitions from ADFbc SDO's if we chose, to avoid duplication.
5. Raising the event.
All I had to do was to configure the Entity to raise events I was interested in and the payload I wanted to pack into the event. In my example, I chose to send the department ID and name.
We can easily expose a getByID web service so that the process can query up the whole department object when it needs to. Until then, we avoid the overhead of lugging huge DOM payloads around and the associated overhead of transformations, marshalling/unmarshalling etc.
End result: good performance. (or at least you avoid performance problems specifically due to unnecessarily large payloads later on - provided other aspects of the code+configuration are right)
All SCA components (Mediator, BPMN and BPEL process engines) can similarly listen to events.
The component that raises the events is just going about its business and doesn't know or care about who or what might be interested in these events. i.e. an existing application doesn't have to call specific API's or service end-points and is immune to changes in other components that listen to its events.
This allows a great deal of decoupling between applications to be integrated.
1. Manual activity
2. Business events
3. BPM Process data objects based on the existing domain model - I used the same XSD for my PDO as the one for my DepartmentCreated event.
When we talk Integration, SOA mostly involves SOAP web services - but just as in real life, a 'business process' doesn't necessarily need to be 'invoked' (via a web service or API call) to get initiated. We just model and implement processes to reflect real business scenarios.
Where appropriate, an 'Initiator' human task could also initiate a process - i.e. when the first activity in a business process is a human task - although, in my example, I purposely have not implemented a initiator human workflow task.
1. My development environment is a SOA/BPM suite 126.96.36.199 installation on a single server instance with no managed server. The SOA and BPM domain was created in 'developer' mode. Both my SOA/BPM suite and the standalone UI application are deployed on the same server (but this can be configured to be on different servers)
2. Create a data source jdbc/hrDS pointing to the sample HR schema.
3. Deploy the EmpDeptADFApplication and access it via http://your_server:your_port/adfedl/faces/home
4. Deploy the EmpBusinessProcess composite
5. When you create a new department (manually enter a unique departmentId) and commit it, an instance of the EmpBusinessProcess composite is created. For the approval human task, login to the BPM workspace as weblogic and just Approve or Reject the item in the worklist.
(An old post that introduces the EDN but that was before the BPM suite and BPMN processes became 'SCA-fied')
2. Start Events for a business process (Implementation type='Message' is just the default !! Just like in real life, every process does not logically start with a web service or an API call! ):