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

XQuery Profiling using Altova XMLSpy

Many of us may be working on XQuery/XSL Transformations in our OSB/BPEL projects. We might have often wondered for years as how we can check the performance of our XQuery resources at design time.

Oracle doesn’t ship any OOTB XQuery profiling tool. However we can use Altova XMLSpy for profiling our XQueries and evaluating their performance.

Here is a quick solution that we can use if needed.

I am using an existing complex XQuery Transformation that converts requests coming from one source system to another in XMLSpy.

Open the .xq/.xquery file in Altova XMLSpy.

Replace the last two lines with

xf:XFormXQ(doc('c:\ CreateSalesOrderRequest.xml')//CreateSalesOrderEBM)

Here we are directly providing an input to the XQuery. Well also place a sample request xml at the location provided so that the engine can pick the input file up.

Now click on the XSL/XQuery tab in Alto XMLSpy and check ‘Enable XSLT/XQuery Profiling’

Also enable XQuery Debugger in case you would want to set debug points.

That’s it. Now click on ALT+F10 or the XQuery Execution icon to execute the XQuery

What we see is that the XQuery is executed and we can see the response in a different pane. We can also see the detailed execution statistics for the XQuery in the profiling report.

The report can be drilled down to the narrowest element and we can gather statistics like Hit Count/ Execution Time etc. This could be of great importance if we need to find any performance bottlenecks.

Here is a sample output from the execution

Also now we get to see the execution report generated by the profiler. The report can be drilled down to the narrowest element and we can gather statistics like Hit Count/Execution Time etc. This could be of great importance if we need to find any performance bottlenecks.



You can also either create an OOTB chart from the profiling data or simply export it as XML.

Viola. Now you can pin to the deepest dungeon in your XQuery to figure out which construct is taking the maximum time to execute.

Important Consideration

One important note is that only standard XQuery functions will compile within Altova XMLSpy. If you have custom Oracle/BEA functions inside your XQuery i would suggest you comment those out.

All the files used in this demonstration can be found here at this link.