0% found this document useful (0 votes)
56 views24 pages

SOA Business Events

This document provides instructions for building a demo that uses various Oracle SOA components: 1. A web application is used to create customers with an "INACTIVE" status, which raises a business event. 2. A mediator processes the business event and routes it to a BPEL process. 3. The BPEL process uses a business rule to determine if approval is needed. If so, it invokes a human workflow task for approval. 4. After approval or rejection, the customer status is updated to "ACTIVE" or "INVALID" in the database. The stages covered are: configuring the business event, mediator, BPEL process, human task, and business rule components.

Uploaded by

Rishabh Chhajer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views24 pages

SOA Business Events

This document provides instructions for building a demo that uses various Oracle SOA components: 1. A web application is used to create customers with an "INACTIVE" status, which raises a business event. 2. A mediator processes the business event and routes it to a BPEL process. 3. The BPEL process uses a business rule to determine if approval is needed. If so, it invokes a human workflow task for approval. 4. After approval or rejection, the customer status is updated to "ACTIVE" or "INVALID" in the database. The stages covered are: configuring the business event, mediator, BPEL process, human task, and business rule components.

Uploaded by

Rishabh Chhajer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

Business Events, Business Rules, Human Workflow and Oracle BAM Demo

In this demo we will be constructing the following:

1. Customer would get created in database using a Web application with 'INACTIVE' as mode.
2. This customer creation would raise a business event.
3. Business event raised would be captured by Composite process (Mediator)
4. Mediator would route this request to BPEL Process.
5. BPEL Process will take help of business rule to decide whether an approval is needed or not
6. After approval/ no approval the customer state would get updated in database from 'INACTIVE' to 'ACTIVE'
or ‘INVALID’

Stages to achieve above demo:


Stage 1: Constructing Web application with ADF BC service
Stage 2: Create One way BPEL Process that would take Customer Id as input and update Customer ActiveStatus
to ‘ACTIVE’, ‘INVALID’ from ‘INACTIVE’.
Stage 3: Enable Business Event on Entity Object within ADF-BC for Customer Create
Stage 4: Configure Mediator as Subscriber to ADF-BC’s Business Event and invoke BPEL Process.
Stage 5: Implement Human workflow allowing Human approval within BPEL Process.
Stage 6: Implement Business Rule allowing decision for Human approval invocation.

Before we begin, execute the following SQL to alter SOADEMO.CUSTOMERS table in order to add
‘ACTIVE_STATUS’ column

ALTER TABLE customers ADD active_status VARCHAR2(10);

Stage 1 and Stage 2 are already implemented, this document would guide you from Stage 3 onwards
Stage 3: Enable Business Event on Entity Object within ADF-BC for Customer Create
Double click on ‘CustomerEO’ entity object from NewCustomerADFApplication  Model then click on
‘Business Events’

Click on ‘+’ under ‘Event Definitions’ to construct EDL file


Configure the ‘Event Publication’ as mentioned below

Redeploy ‘NewCustomerADFApplication’ onto soa server

With this Stage completes, and our ADF Application would raise event as soon as user performs Create
operation on ADF-BC.
Stage 4: Configure Mediator as Subscriber to ADF-BC’s Business Event and invoke
BPEL Process
Change your focus to composite.xml file from ‘NewCustomerComposite’

Drag and drop Mediator component within ‘Components’ section  Enter name of Mediator as mentioned
below  Select template as ‘Subscribe to Events’  Then click on “+”
Select ‘Customer.edl’ file from NewCustomerADFApplication’s Model Project as mentioned below
Wire Mediator with BPEL component, this way a routing rule would get created within Mediator.

Construct the Transformation file within Mediator component, in order to route Event data (CustId) to BPEL
Component.
Construct the transformation mapping as described below

Redeploy Composite application: Right click on Composite Project  Click on Deploy  Click on
‘NewCustomer’

Access Webpage URL (http://localhost:8001/customer/faces/index.jspx) to create new Customer, after creating


Customer check for Instance in EM Console for ‘NewCustomerComposite’.

This Stage completes here.


Stage 5: Implement Human workflow allowing Human approval within BPEL
Process
Here we will try implementing Approval within BPEL process, by default approval request would go to
‘weblogic’ user. On approval ACTIVE status is updated in Database, on Reject INVALID status is updated in
Database.

Drag and drop ‘Human Task’ within components section of composite.xml

Double click on ‘CreateApproval’ human task in order to configure it.


Provide Task title as ‘Customer Create Request’

Provide Data Input for CreateApproval task  Click on Data tab  Click on “+”  Click on Add Other Payload
Select Element from XSD as mentioned below
Now configure the Assignment policy for ‘weblogic’ user
Now Wire BPEL Process with Human Task as described below

Drag and Drop Human task within BPEL Process as mentioned below
Configure the Human Task as follows

Move ‘UpdateCustomerActiveStatus’ under ‘Approve’ switch branch


Similary configure one more Assign activity under ‘Reject’ case branch, in order to update ACTIVE_STATUS with
INVALID.

Redeploy the Composite and try creating new customer again using web application, this time you would need
to give approval by accessing http://localhost:8001/integration/worklistapp

(Optionally) If you notice on selecting Approval request details are not being displayed, reason is TaskForm is
missing. In order to get TaskForm. Right click on HumanTask within BPEL Process and click ‘Auto Generate Task
Form’. This would ask project name to construct JSP pages.

This Stage is completed here


Stage 6: Implement Business Rule allowing decision for Human approval
invocation
Lets implement conditional approval functionality, as follows:

IF CUSTOMER.STATUS == “gold” or CUSTOMER.STATUS== “platinum” THEN


APPROVAL_REQUIRED  YES
APPROVER_NAME  ‘weblogic’

Before we begin we need to create Schema supporting DATA for above condition, then we will construct
Business Rule accordingly.

Create New XML Schema Document within Composite service as mentioned below
Construct Schema structure as follows

Drag and drop Business Rule within Components pane of composite.xml file
Browse and give Input and Output XSD structure for Business Rule as ApprovalData (created earlier)

Double click on ‘Business Rule’ component to lauch ‘.rules’ file as below


Configure Business rule as mentioned below

Now let’s use this Business Rule within BPEL Process, so create “WIRE” from BPEL Process to Business Rule
Create ‘approvalResponse’ variable to hold Business Rule response so that we can construct Switch activity for
Human task.

Drag and Drop switch activity Just above Human Task


Configure case condition as “approvalRequired = ‘YES’”  Drag and drop both Human task and taskSwitch
within Case branch  Finally configure an assign activity in otherwise branch to update customer status as
“ACTIVE” as mentioned below
Drag and drop Business Rule within BPEL Process just below FindCustomer
Configure Business Rule as mentioned below
Similary configure the Output Facts for Business Rules

Redeploy the process and test with any status other than ‘gold’ and ‘platinum’, ideally if business rule executes
successfully you should not see Approval Request in Worklist application.

This Stage ends here.

You might also like