Lightweight introduction to Oracle SOA Suite 11g : Part I

Off course so much has been told and spoken about Oracle SOA Suite 11g. So to set the expectation straight there is nothing ground breaking this article would explain.

However if you are not seasoned in the soa suite of Oracle this could be your stepping stone. The article would explain in brief though the various capabilities of Oracle SOA Suite that can be leveraged while designing business processes. Off course anytime you can refer to Oracle’s use case covering everything in detail. Here is something that is ‘Stairway to Heaven’ path.

For the purpose of ease this article will take a small use case for a Sales Order Flow to explain the various components.

So here we go.

Sales Order Flow Use Case

• Develop an interface to accept Order information and process the order to downstream in BPEL.
• The BPEL interface must be developed on common organizational component viz Enterprise Business schemas/services.
• The interface must publish events stating order status within the process that can be consumed by either or both composites/agents.
• All Routing Rules must be central and Mediator to act as the Router in the Composite.
• All Order Processing rules must be part of centralized Business Rules that can be modified runtime without composite redeployments.
• An Order can be either processed automatically or manually. A business rule should decide the fitment of an order for automated processing. If the order is decided to be processed manually then create an override activity for an order USER to confirm. A UI should be presented to the user with key order indicators for him to decide so.
• Publish Key Order Indicators/Process Statistics to BAM Active Data Cache for reporting and metrics.
• Develop a robust Fault Handling and Manual/Automatic Retrying Mechanism.
• Create DVMS to hold cross system mappings.
• Configure Notification and messaging channels. 

Good enough though not exhaustive. However sufficient enough for us to get started.

Here is a pretty easy solution that we can implement to adhere to the above use case. And in the process understand Oracle SOA Suite as well.

The diagram explains the composite for the use case that has the following components.

• A BPEL Process for orchestrating the Sales Flow. 
• A Business Rules component that decides whether the Order flow should be terminated for manual process or be continued for automated processing. 
• Human Workflow to provide for manual touch point during order processing. 
• Mediator that acts as a lightweight ESB for the composite and acts as a subscriber and router. 
• Adapter Services/End Services Partnerlink Components.

The Sales Flow is based on common AIA components i.e EBO’s and EBM’sand is exposed as an enterprise Service. You can eve use your own set of schema to start.

The Sales Order Flow also acts as a Publisher of Sales Flow events that can be subscribed by various subscribers to trigger other associated processes that may include one or all of the following

• BPEL Processes/Composites.
• Database/JMS Agents.
• Other Third Party App

 

 

Business Rules Components are used to house all Order Processing Rules in the Sales Flow. 

• Facts are inputs and outputs to a business rule.
• Rules are based on predefined set of values or Bucketsets (list of Ranges or Values)
• Conditions determine which rule is picked up and is applied on the input facts.
• Actions are outcomes of rule processing and generally assert a value to the output facts.

The Business rule component can also be exposed as a standard SOAP service. Also the rules can be modified at run time from the SOA Composer UI without composite re-deployments.

The Human Workflow component is used in case the Order flow needs an interactive touch point. Human workflow’s can have a variety of approval mechanisms (role/hierarchy based etc).

Again Human Workflows are based on some Task UI (can also be auto generated) from where participants can enter responses. The OOTB UI is an ADF based one.

We can directly feed process data (Sensors/Intervals/Counters/KPIs) to BAM using BAM Adapter and choosing a sensor action to publish to BAM.



On the BAM side we can create Data Objects to hold these business indicators. We can also measure data related to instance processing using BAM. We can create custom calculated fields and look up fields while creating Data objects as well.



And finally Reports and Dashboards too.



Part Two in this series discussed Fault Handling, Domain Value Maps and User Messaging Service here