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 schemas to start.
The Sales Order Flow also acts as a Publisher of Sales Flow eventsthat 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 Componentsare 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 redeployments.
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/hierarchybased 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. 🙂
Coming to Fault HandlingOracle SOA Suite allows fault handling based on policies
- Using Fault Policies
- Using Fault Bindings
Catch and throw faults at the process level. Handle different types of faults if you have to.
Add the fault bindings and fault policies file in the same directory where the composite.xml is.
Here is a sample custom example Fault Policies
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"> <faultPolicy version="2.0.1" id="SalesCompositeFaultPolicy" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Conditions> <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault"> <condition> <test>$fault.code/code="WSDLReadingError"</test> <action ref="ora-rethrow-fault"/> </condition> <condition> <action ref="ora-retry"/> </condition> </faultName> <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault"> <condition> <action ref="ora-rethrow-fault"/> </condition> </faultName> <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault"> <condition> <action ref="ora-rethrow-fault"/> </condition> </faultName> <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:runtimeFault"> <condition> <action ref="ora-human-intervention"/> </condition> </faultName> </Conditions> <Actions> <!-- This is an action will mark the work item to be "pending recovery from console"--> <Action id="ora-human-intervention"> <humanIntervention/> </Action> <!--This is an action will bubble up the fault--> <Action id="ora-rethrow-fault"> <rethrowFault/> </Action> <!--This action will attempt 5 retries with intervals of 4 seconds retry after 120, 240, 360 seconds --> <Action id="ora-retry"> <retry> <retryCount>3</retryCount> <retryInterval>5</retryInterval> <retryFailureAction ref="ora-human-intervention"/> </retry> </Action> <!--This action will cause the instance to terminate--> <Action id="ora-terminate"> <abort/> </Action> </Actions> </faultPolicy> </faultPolicies>
And Fault Bindings
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <composite faultPolicy="SalesCompositeFaultPolicy"> </faultPolicyBindings>
We can also create DVMs (Domain Value Maps) used to lookup cross system data that can be edited at runtime using the SOA composer UI just like we can edit Business Rules
We can also use the OOTB User Messaging Serviceto configure notification channels such as
- Voice Mail
Setup user inboxes to receive the notification emails.
This is pretty much it for now. Hope this gives an overview of what we can try and do with Oracle SOA Suite.