OSB 11g R1 does not have DVM support. Now this is perfectly fine for clients who are using DVMs as part of the SOA Composites. But considering the fact that Oracle Mediator 11g has DVM functionality, and that many clients would have a migration path from Mediator based artifacts to OSB 11g, this can be a problem.
Clients can wait till Oracle releases the official support or resort to some ad hoc measures. Let’s look at such a solution. The solution is based on custom OSB XPaths.
1. An OSB Proxy Service DVMLookup exposes DVMs and is based on the following xml input:

This matches closely with the Oracle SOA 11g DVM lookup XPAth lookupValue(DVM_TABLE_NAME,SOURCE_COLUMN_NAME,SOURCE_COLUMN_VALUE,TARGET_COLUMN_NAME,DEFAULT_VALUE)
2. The customer DVMs can be added to the CommonServices/DVMs

3. This Service gets called via a Java class that is exposed as an OSB Custom XPath. The signature for the method call is
public static String lookupValue(String DVMTableName,String SourceColumnName,String SourceColumnValue,String TargetColumnName,String DefaultValue)
4. The dvm-custom xpath config file looks like this:

II. Installation

1. Download the package DVMLookup.zip. This contains the following:
a. OSB_Artifacts.jar: Contains the OSB Artifacts CommonServices and TestDVMLookup
b. CustomXPath : Contains the custom xpath components viz. dvm-custom.xml, dvmLookup.jar and dvm-custom.properties
c. SimpleDVMLookup: Contains the Eclipse project for the dvmLookup Java classes

2. Deploy the CommonServices and TestDVMLookup in OSB. In addition import these projects into OEPE.
3. Copy all the contents of CustomXPath into the location %OSB_HOME%/config/ xpath-functions
4. Restart Weblogic and OEPE. Weblogic admin startup log should show the DVM client successfully initiated

5. OEPE should show the custom xpath as follows:

III. Post – Installation Checks
1. The current Setup contains a predefined set of DVMs within CommonServices/DVMs folder:

2. Test the DVMLookup proxy service within DVMLookupTest /DVMTest with the following input in the body

3. The result response should be:

This completes the Post installation check

IV. Customizations
1. As already mentioned, the CommonServices/DVMs contains predefined DVMs. You would now need to insert your own dvms. Open your existing DVM and create a new XQuery Resource within the CommonServices/DVMs folder in OEPE or the OSB Console. You can use of the existing DVMs to insert your own values or copy the values in the template dvms, create a new XQuery Resource , paste the values and then modify the XQuery Resource with your own values.
2. The LoadDVM stage of the proxy loads the DVM based on the DVM Table name. Hence, you have to add another else-if condition to insert the new DVMTable you just created.

4. The Java code for the custom xpath is also included. This can be handy if you want to change the namespaces or the hostname for the DVM Proxy.

V. Usage
1. A typical XSLT transformation with the DVM Xpath looks like this:

2. Clearly, the only change is the namespace of the XPAth function. The new namespace is:

http://www.soa-utilities.com/osb/custom/xpath/soa.utilities.dvm.LookupTable

3. Each lookup call takes an average of 7 ms on a 4 GB Intel Core2 Duo@2.40 GHz running Weblogic Server and OSB. This would definitely perform a lot better in production boxes. To check for the exact lookup time, please execute the dvmLookup.jar on the installed machine. The default run tests for 100 lookups on one of the predefined DVMs.
java –jar %OSB_HOME%/config/xpath-functions/dvmLookup.jar

Resources:

1. DVMLookup Package (500 KB)

2. PDF whitepaper (200 KB)

One of the easiest  ways of doing  this is to take all the xpath functions that are defined in the soa-xpath-exts.jar and soa-xpath-functions-config.xml and dump em into OSB XPath config as a Custom XPath. Here are the steps:

1. Get the fabric-runtime.jar and the soa-xpath-exts.jar from %SOA_HOME%\soa\modules\oracle.soa.fabric_11.1.1

2. Get the soa-xpath-functions-config.xml from %JDEVELOPER_HOME%\jdeveloper\integration\seed\soa\configuration. This file contains a list of all the XPath functions. We wont do anything to this….just for reference.

3. Now, get the osb-built-in.xml and osb-built-in.properties files from%OSB_HOME%\config\xpath-functions. Create copies of these files. We will modify these copies to include the migrated XPath Functions.

4. Now the task is to map the XPath functions defined in soa-xpath-functions-config.xml to the copy of the osb-built-in.xml that you just built. Almost for all the XPaths the only thing that needs to be changed is <xpf:name>,<xpf:comment>,<xpf:namespaceURI>,<xpf:className> and the <xpf:method>. Rest of the elements can be safely kept as is. The mentioned five elements can be directly mapped from the soa-xpath-functions-config.xml. But note that OSB XPath functions doesnt support inner classes and there are a hell lot of inner classes in the soa-xpath-functions-config.xml. So inorder to get over this, you have to somehow get the source code of the custom xpath functions, check which method of a particular class gets called and use that in the <xpf:className> and the <xpf:method>.

5. Make sure you know the permitted java types when you specify the <xpf:method> as in the document:  http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15866/custom_xpath.htm#CBADFJEG. Some of the methods cannot be used !!!

6. Also make sure that for each XPath defined in the copy of the osb-built-in.xml you have to specify the comments in the proeprties file as well.

7. After you are done, dump all the jars and the OSB custom XPath files into %OSB_HOME%\config\xpath-functions.

This is a lot of pain.. and it would definitely take a good 8 hours!!!

Anywayz, if you dont want to do all this re-engineering, you alternatively use the Nirvana package below This package contains support for the XPaths listed here

Unzip the folder and copy everything to %OSB_HOME%\config\xpath-functions . Restart Weblogic and Workshop. Follow the Installation Instructions in the reference for more details.

XPath Nirvana is here!!!

These XPath functions have the same name as the standard SOA 10g functions, although the namespaces are different.

The usage of these functions are different for XSLT and XQuery.

1. XQuery: The XPath functions listed in the table should be used alongwith the necessary namespaces. This means that you can directly drag from the Expressions window.
2. XSLT: For use in XSLT expressions, the Java Method name of the custom XPath function should be used alongwith the necessary namespaces.

Examples:

Note the difference in usage for the format-date XPath in XQuery and XSLT:

XQuery:

<Result><formatDate>dat:format-date(’2028-08-31T05:30:54+05:30′,’yyyy.MM.dd G HH:mm:ss z’)</formatDate></Result>

XSLT:

<xsl:stylesheet version=“1.0″ xmlns:xsl=“http://www.w3.org/1999/XSL/Transform” xmlns:dat=“http://www.soa-utilities.com/osb/custom/xpath/utilties.xpath.extensions.DateFunctions”><xsl:template match=“/”>

<Result><formatDate><xsl:value-of select=“dat:formatDate(’2028-08-31T05:30:54+05:30′,’yyyy.MM.dd G HH:mm:ss z’)” /></formatDate></Result>

</xsl:template></xsl:stylesheet>

The full list of namespaces for each XPath can be found in here.

Enjoy!!

1. Custom XPath Functions Library

2. Installation Manual for Custom XPath Functions Library

3. Full List of Supported XPath Functions

Anyways, the scope of this article is to show some small syntactical differences between XSLT and XQuery. Not an exhaustive list by any means, but the following are the most common :

1. <xsl:for-each select=”/client:process/client:result”>      ——> for $result in element(client:process/client:result)
2. <xsl:value-of select=”/client:process/client:result” />  ——> data(/client:process/client:result)
3. <xsl:if test=”/client:process/client:result gt; 10″ />    ——> where data(/client:process/client:result) gt 10
4. All XPaths including predicates are directly mapped

Then how do we re-use the BPEL XSLTs in OSB then? The trick is to include a small change in the namespace. In the imported XSLTs change the namespaces of the Source Process’s namespaces to that of the Target Process’s namespace.

Just to elucidate, imagine a hypothetical Mid BPEL process that sits between a Requestor and a Provider. This BPEL process does the following transformations at the minimum:

1.   Transform from Mid BPEL process input to that of the Provider input. (SetInput.xsl)

<xsl:stylesheet version=”1.0″
xmlns:client=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTest/MidBPELProcess”
xmlns:ns0=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”
exclude-result-prefixes=”client ns0″>
<xsl:template match=”/”>
<ns0:element2>
<xsl:value-of select=”/client:process/client:element2″/>
</ns0:element2>
</ns0:process>
</xsl:template>
</xsl:stylesheet>

2.   Transform from Provider output to that of the Mid BPEL process output. (SetOutput.xsl)

<xsl:stylesheet version=”1.0″  xmlns:client=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”
xmlns:ns0=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTest/MidBPELProcess”
exclude-result-prefixes=”client ns0″>
<xsl:template match=”/”>
<ns0:processResponse>
<ns0:element2>
<xsl:value-of select=”/client:processResponse/client:element2″/>
</ns0:element2>
</ns0:processResponse>
</xsl:template>
</xsl:stylesheet>

So, when reusing in OSB, do the following:

1.   In SetInput.xsl, change the namespace of the Source Namespace to that of the Target.

<xsl:stylesheet version=”1.0″
xmlns:client=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”
xmlns:ns0=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”
exclude-result-prefixes=”client ns0″>
<xsl:template match=”/”>
<ns0:element2>
<xsl:value-of select=”/client:process/client:element2″/>
</ns0:element2>
</ns0:process>
</xsl:template>
</xsl:stylesheet>

2.   In SetOutput.xsl, change the namespace of the Target Namespace that of the Source Namespace.

<xsl:stylesheet version=”1.0″                xmlns:client=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”       xmlns:ns0=”http://xmlns.oracle.com/migrationCompositeTest_jws/TransformCompatibilityTestProvider/TransformCompatibilityTestBPELProvider”
exclude-result-prefixes=”client ns0″>
<xsl:template match=”/”>
<ns0:processResponse>
<ns0:element2>
<xsl:value-of select=”/client:processResponse/client:element2″/>
</ns0:element2>
</ns0:processResponse>
</xsl:template>
</xsl:stylesheet>

Note: The maps have been simplified.

That’s about it! Maps can now be resued in OSB.

A pdf version of this tutorial is right here…

Behaviour: In a single global transaction, any fault within the Composite will result in a complete rollback of all transactions. However, if there are boundaries then in the event of a fault within the global transaction, local transactions will be committed while the global transaction is rollbacked. If fault happens in the partnerlink and it is not handled then the local transaction is rollbacked and a FabricInvocationExceptions is thrown back to the parent BPEL process. If fault happens in the partnerlink and it is handled then the local transaction is committed.

How to create local transactions or boundaries:

The boundaries are defined in the composite.xml of the component properties of the called process. The exact properties are dependant on the Message Exchange Pattern of the called Component[1]:

1.    If MEP is Sync Request Response, then transaction=requiresNew

2.    If MEP is Async Request Response, then transaction=RequiresNew, oneWayDeliveryPolicy=sync

3.    If MEP is One Way, then transaction=RequiresNew, oneWayDeliveryPolicy=sync

Note 1.1: The transaction parameters are only defined for BPEL Components. So, if you do want to create local transactions, you would have to embed adapters in bpel processes. I do not understand why this limitation should be there.

Steps:

1. Create a Thin XA Datasource that supports ‘Two-Phase Commit’ global transaction and a connection pool. We will require the JNDI of this pool for the project.
2. Create two OSB Business Services for inserting and updating a table in the datasource configured in Step 1. These are based on the JCA transport which is transactional in nature. A link[2] is provided in resources for the same.
3. Create Proxy Services for these Business Services based on SB-transport which is also transactional.
4. Create a composite with two BPEL processes viz. GlobalTransactionBPELRequestor which makes inserts into a table NAME_ID via OSB Proxy Service and LocalTransaction_BPEL_Insert2 which inserts into a table NAME_ID2 again via OSB Proxy Service. In addition, GlobalTransactionBPELRequestor also invokes the LocalTransaction_BPEL_Insert2 and then throws an Assert Fault based on the input.

GlobalTransactionBPELRequestor snapshot: 

The input for the GlobalTransactionBPELRequestor looks like: 

 

6.   As per the earlier discussion, we will now insert the following custom properties inside the component property of the called BPEL process viz. LocalTransaction_BPEL_Insert2.

This ensures that the LocalTransaction_BPEL_Insert2 invoke will result in a separate local transaction.

7.  Now, deploy the components and test the GlobalTransactionBPELRequestor with the following inputs

8.  The Trace in shows that the test completes successfully  and the entries for the name and id show up in both the tables:

9.  Now, test the same process with the following inputs:

The Request from OSB to SCA is sent via soa-direct transport while the callback from SCA to OSB happens via the sb transport. In essence, the flow comprises two one-way OSB flows: one for the request and the other for the response.

I fail to understand why a combination of sb and soa-direct transports are required.

Let’s go about creating it then. In our sample use case, we will use OSB to mediate between an Asynchronous Composite (C_req) and an Asynchronous Provider (C_prov). The requestor composite sends a Name, ID pair to the provider which responds back with a ‘Hello ‘+Name+’ Your ID is ‘+ID message. The OSB mediation comprises four artifacts a Requestor Proxy (P1), a Requestor Business Service (B1), a Callback Proxy (P2) and finally a Callback Business Service (B2).

Note that unlike BPEL, OSB has no OOTB support for Asynchronous Request Response Correlation and hence, this is achieved explicitly by using the WS-Addressing SOAP Header elements viz. ReplyTo and ReferenceParameters. I am assuming that you are already familiar with these WS-Addressing parameters.

The sequence of tasks to be performed for this Sample is:

1. Create the Asynchronous Composite Provider (C_prov).
2. Create the Requestor Business Service (B1).
3. Create the Callback Business Service (B2).
4. Create the Callback Proxy Service (P2)
5. Create the Requestor Proxy Service (P1)
6. Create the Asynchronous Composite Provider (C_req).

If you really don’t want to create the samples, and are more worried about the actual settings, this is the core of things happening:

1. The Composite Requestor is based on a BPEL process that uses content based correlation.
2. P1 receives the callback address of the Composite Requestor and stores the same in the WS-Addressing ReferenceParameters so that it gets echoed back by the Composite Provider during the Callback as a SOAP element. Also it specifies the URI of P1 to which the Provider Composite sends the callback.
3. Requestor Business Service B1 is configured as an Asynchronous Client without any Callback Address as this gets set in Step 1.
4. The Callback Proxy P2 receives the address of Composite Requestor in the SOAP Header and sets this in the URI of the routing options.
5. Callback Business Service B2 is configured as an Asynchronous Callback Service and based on the URI set in Step 3, makes the callback to the Composite Requestor.

1.  Create the Asynchronous Composite Provider (C_prov):  This Composite consists of an Async BPEL Process and a Direct Binding adapter based exposed service.

The AsyncBPELProvider process receives input based on the following schema and returns a result together with the ID for correlation.

2. The Requestor Business Service B1 consumes the WSDL of the Asynchronous Composite Provider at the Direct Service Request Binding Port SOAP 1.1.

In the SOA Direct Configuration page, we set this service as an Asynchronous Client Service. We will not set the Callback service as this will be set by the Requestor Proxy Service later and make sure the WS-Addressing Version is http://www.w3.org/2005/08/addressing.

3. Next, we create the Callback Business Service. This will also be based on the Provider Composite WSDL we created earlier. The operation is now Direct Service Callback Binding Port SOAP 1.1.

In the SOA DIRECT Service Configuration select the role as Service Callback.

Note that this inserts a default Endpoint URI in the transport setup. Don’t bother about this URI. We will override this via the Callback Proxy Service later.

4. Now, lets create the Callback Proxy Service. This service is again based on the Composite Provider’s WSDL like in the previous step. However, now we select the sb transport in the transport configuration. Note that this service will receive the client callback port in the SOAP Header as the chunk $header/osb:Callback/osb:Address/text(). This will be inserted by the Requestor Proxy as a Reference Parameter thus making the Callback Composite include it in the callback SOAP Header. We will develop this later. For now, this address is simply copied into the OSB Routing Options inside the Routing node for the Callback Business Service. Optionally we also remove the osb:Callback element from the SOAP Header.

The Outbound of the Callback Proxy Service looks something like this:
<con:endpoint name=”BusinessService$AsyncOSB2SOA$CallbackBusinessService” xmlns:con=”http://www.bea.com/wli/sb/context”>
<con:service>
<con:operation>processResponse</con:operation>
</con:service>
<con:transport>
<con:uri>t3://localhost:7001/default/AsyncCompositeRequestor!1.0*soa_9562061b-fb6e-4118-8441-0c08e14f626a/DirectReference#AsyncBPELRequestor/DirectReference</con:uri>
<con:mode>request</con:mode>
<con:qualityOfService>exactly-once</con:qualityOfService>
<con:request xsi:type=”soa:SOARequestMetaDataXML” xmlns:soa=”http://www.bea.com/wli/sb/transports/soa” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<tran:headers xsi:type=”soa:SOARequestHeadersXML” xmlns:tran=”http://www.bea.com/wli/sb/transports”>
<tran:user-header name=”SOAPAction” value=”&quot;processResponse&quot;”/>
</tran:headers>
<tran:encoding xmlns:tran=”http://www.bea.com/wli/sb/transports”>utf-8</tran:encoding>
</con:request>
</con:transport>
<con:security>
<con:doOutboundWss>false</con:doOutboundWss>
</con:security>
</con:endpoint>

The xml chunk in bold is the actual Composite Requestor’s Callback address returned as a SOAP Header by the Composite Provider.

5. Next, we will develop the Requestor Proxy Service. This Proxy is based on the same WSDL of the Async Composite Provider we have used before. The binding selected is Direct Service Request Binding SOAP 1.1.

Also we select sb as the transport for this Proxy. In the message flow there are a couple of things this service does. First, it copies the Client’s callback Address and inserts it in the WS-Addressing ReferenceParameters. Then it sets the WS-Addressing ReplyTo address with the sb transport address of the Callback Proxy Service we created in Step 4.

The resulting SOAP Header should look something like this:

<soap-env:Header xmlns:soap-env=”http://schemas.xmlsoap.org/soap/envelope/”>
<wsa:ReplyTo xmlns:wsa=”http://www.w3.org/2005/08/addressing”>
<wsa:Address>sb://7WX83BS.nsn-intra.net:7001/CallbackProxyService</wsa:Address>
<wsa:ReferenceParameters>
<osoa:callback osoa:connection-factory=”oracle.soa.api.JNDIDirectConnectionFactory” xmlns:osoa=”http://xmlns.oracle.com/soa/direct”>
<osoa:property osoa:name=”java.naming.provider.url” osoa:value=”t3://localhost:7001″/>
<osoa:property osoa:name=”java.naming.factory.initial” osoa:value=”weblogic.jndi.WLInitialContextFactory”/>
<osoa:property osoa:name=”oracle.soa.api.invocation.direct.bean” osoa:value=”SOADirectInvokerBean#oracle.integration.platform.blocks.direct.Invoker”/>
</osoa:callback>
<instra:tracking.ecid xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>0000IhiCI8lFw000jzwkno1Cdje_000585</instra:tracking.ecid>
<instra:tracking.parentComponentInstanceId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>bpel:660005</instra:tracking.parentComponentInstanceId>
<osb:Callback xmlns:osb=”http://www.osbLabs.soaDirect”>
<osb:Address>t3://localhost:7001/default/AsyncCompositeRequestor!1.0*soa_9562061b-fb6e-4118-8441-0c08e14f626a/DirectReference#AsyncBPELRequestor/DirectReference</osb:Address>
</osb:Callback>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
</soap-env:Header>

The changed chunks are in bold. Note that the element refered by wsa:Address points to the URI of the Callback Proxy Service and the osb:Callback referes to the address of the Composite Requestor’s Callback.

6. Finally, we create the Async Composite Requestor. This composite is based on an Async BPEL Process which invokes the Requestor Proxy Service via a Direct Reference binding. In addition, it includes a WS as an exposed service for testing. For simplicity we have used the same message schema as employed by the Composite Provider we created in Step 1 and the correlation is based on the ID.

Right then, lets test this in the em console.

A)   In the Requestor Composite’s test , we specify the following input parameters:

B)   The Asynchronous Composite Provider completes as expected and the Async BPEL Provider process completes.

C) The Asynchronous Composite Requestor and the related BPEL Async Component completes as expected.

That’s all about it. The sample source is included. Follow the sequence of deployments as followed in this tutorial.

The pdf version of this tutorial is right here…

As for example, if there are two business services eg. MultipleOperationsViaBranching and ServiceCalloutsWithErrorHandling that are each based on the same interface, we can use dynamic routing.

The core of this feature is built on the following XML element:

<ctx:route>
<ctx:service isProxy=”true|false”>{$proxy|$businessService}</ctx:service>
<!– Optional : –>
<ctx:operation>OperationName</ctx:operation>
</ctx:route>

The isProxy is true or false according to whether the dynamic route is to a Proxy Service or to a business Service.
I have no idea why it has to be either a proxy or a business service. There can be cases where we might actually need both.

Anyways, the way to go is to put the above element in the expression of a dynamic routing action inside a route node, etc.
As for eg.

<ctx:route>
<ctx:service isProxy=”false”>ServiceCalloutTest/BusinessService1</ctx:service>
</ctx:route>

Case1:

The portion denoted by ServiceCalloutTest/BusinessService1 is hardcoded for simplicity.
The same can be achived at runtime by using XQuery expressions to evaluate the input to the ProxyService.

The benefit, XQuery resources are easy to maintain. And any new business or proxy service routings can be added on the fly.

Case 2:

Now, then, lets move to a little advanced  version. In this new Dynamic Routing example, we will use an XQuery Resource as a holder for all the Dynamic Proxy Services based on the same abstract wsdl. We will then use XQuery assigns in the Dynamic Proxy Service to find a suitable Proxy based on the input. The main benefit of this sample being that we can add additional dynamic services to the Proxy Service by a simple edit of the XQuery Resource.

The flow is shown below:

The XQuery Resource used as a Routing Table is as follows:

The CopyRoutingTable stage copies the above XQueryResource into a variable called RoutingTable. This is achieved by just pointing the above XQueryResource file in the XQuery expression window.

The GetLogicalName stage then copies the Proxy Service input to the variable LogicalName.

Finally, the GetPhysicalService stage creates the Dynamic Routing XQuery into the variable PhysicalService via the expression:

The next action is a Dynamic Routing with the $PhysicalService in the Service expression.

The good thing about this setup is that it allows us to add or remove Dynamic Proxy Services in the XQueryResource and also change the logic of mapping the Logical to the Physical Service without having to change the Dynamic Proxy Service itself.

Case 3:

The above samples have not used the Operation setting for the dynamic endpoint.

Let us take a more concrete use case. Dynamic Endpoint definitions are maintained in an XQuery Resource Map as before. The user can select which service he wants to invoke based on the input. In addition, the user also specifies the operation and messages to be exchanged.  The OSB Dynamic Proxy takes the input, maps to a Physical Service and invokes it.

The XQuery Resource for the Routing Map is now changed to:

<Services>
<Service>
<logical>Service1</logical>
<physical>ServiceCalloutTest/ProxyService1</physical>
<isProxy>true</isProxy>
</Service>
<Service>
<logical>Service2</logical>
<physical>ServiceCalloutsWithErrorHandling/ProxyServices/ProxyService1</physical>
<isProxy>true</isProxy>
</Service>
</Services>

The above config contains two endpoints viz. ServiceCalloutTest/ProxyService1 and ServiceCalloutsWithErrorHandling/ProxyServices/ProxyService1 each of which is based on the same abstract wsdl and exposes operations viz. getGreeting(String name) and getCurrentGreeting(). These methods are implemented differently.

The Dynamic Proxy service is designed to accept any WSDL with SOAP 1.1.  The input looks like below:

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service1</Service>
<osb:getGreeting xmlns:osb=”http://www.osbLabs.WebServices”>
<!–Optional:–>
<arg0>Sandeep</arg0>
</osb:getGreeting>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

The Service element is a direct logical reference to the Service element in the XQuery Resource Routing Map.
This is followed by the operation to be invoked and the relevant arguments. This makes sure operations can be invoked dynamically as well.

Another input with an operation getCurrentGreeting is shown below:

<soapenv:Envelope      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header      xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute      xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service1</Service>
<osb:getCurrentGreeting xmlns:osb=”http://www.osbLabs.WebServices”>
</osb:getCurrentGreeting>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

The flow below shows the Dynamic Proxy Service:

The flow shows a series of assigns. Let me break it down bit by bit:

Heres a sample run:

Input1:

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service1</Service>
<osb:getGreeting xmlns:osb=”http://www.osbLabs.WebServices”>
<!–Optional:–>
<arg0>Sandeep</arg0>
</osb:getGreeting>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

Output from Service1 on operation getGreeting:

Input2:

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service2</Service>
<osb:getGreeting xmlns:osb=”http://www.osbLabs.WebServices”>
<!–Optional:–>
<arg0>Sandeep</arg0>
</osb:getGreeting>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

Output from Service2 on operation getGreeting:

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soapenv:Header/>
<S:Body      xmlns:S=”http://schemas.xmlsoap.org/soap/envelope/”>
<ns2:getGreetingResponse      xmlns:ns2=”http://www.osbLabs.WebServices”>
<return>Hola! Sandeep</return>
</ns2:getGreetingResponse>
</S:Body>
</soapenv:Envelope>

Input 3:

<soapenv:Envelope      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header      xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute  xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service2</Service>
<osb:getCurrentGreeting xmlns:osb=”http://www.osbLabs.WebServices”/>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

Output from Service2 on operation getCurrentGreeting:

<soapenv:Envelope      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soapenv:Header/>
<S:Body      xmlns:S=”http://schemas.xmlsoap.org/soap/envelope/”>
<ns2:getCurrentGreetingResponse      xmlns:ns2=”http://www.osbLabs.WebServices”>
<return>Hola!</return>
</ns2:getCurrentGreetingResponse>
</S:Body>
</soapenv:Envelope>

Input4:

<soapenv:Envelope      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Header      xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
</soap:Header>
<soapenv:Body>
<ds:DynamicRoute  xmlns:ds=”http://www.osbLabs.DynamicProxy”>
<Service>Service1</Service>
<osb:getCurrentGreeting xmlns:osb=”http://www.osbLabs.WebServices”/>
</ds:DynamicRoute>
</soapenv:Body>
</soapenv:Envelope>

Output from Service1 on operation getCurrentGreeting:

<soapenv:Envelope      xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”>
<soapenv:Header/>
<S:Body      xmlns:S=”http://schemas.xmlsoap.org/soap/envelope/”>
<ns2:getCurrentGreetingResponse      xmlns:ns2=”http://www.osbLabs.WebServices”>
<return>How are you</return>
</ns2:getCurrentGreetingResponse>
</S:Body>
</soapenv:Envelope>

The above examples shows how easy it is to get OSB dynamic routing up and running quickly. This can serve as a good use case for complicated Proxy Services that does a lot of processing. When new endpoints arrive, the code is left untouched and the new service can be added directly in the XQuery resource.

However, this is still very much in the domain of an experienced SOA Developer. The truth is that by the time a sequence diagram for an Integration Flow is created, the architects or analysts have a very good idea of how the flow will proceed. The only thing left to the developers is to start dragging these scenarios in JDeveloper.  I believe given the full information in a Sequence Diagram, the system is in a state to be autogenerated to an intermediate SCA composite. This can substantially reduce the effort of the developers.

This means, instead of using the SCA composite as a base for checking integrations, the Sequence Diagrams now become the single source of truth for the SOA technical designtime. Simply put, anyone who can create a Sequence Diagram, can get an end to end SOA Integration Scenario running in seconds.

Lets see how this is possible. Any composite differs from others in the following ways:

1. Messages ( Input, Output,Fault )
2. Namespaces
3. Partnerlinks
4. Transformation Activities for Process Variables and Messages and Lookups
5. Orchestration Logic
6. Fault Handling ( retry, notifications, worklists,etc)
7. Runtime and Design Properties

All of the above can be auto-generated using information present in the Sequence Diagrams and the technical specifications for the Artifact (e.g. BPEL and BPM). 1,3,5 are obtained directly from the Sequence Diagrams. 7 can be inserted after the intermediate form is generated and the rest are all reusable fixed components.

The distinction between artifacts can be made by using a well defined Naming Nomenclature for the labels used in the Sequence Diagrams.

A preview of this automation tool will be made available shortly.

This ones really handy… here are the steps:

1. Create a static inner class that implements IXPathFunction

package customFunctions.sandeepphukan.test;

import java.util.List;
import com.oracle.bpel.xml.xpath.IXPathContext;
import com.oracle.bpel.xml.xpath.IXPathFunction;
import com.oracle.bpel.xml.xpath.XPathFunctionException;

/**
* A class that echoes the parameter
* @author sphukan
*
*/
public class echo {

/**
* XPath function
*/
public static class echoXPathFunction implements IXPathFunction{

public Object call(IXPathContext arg0, List arg1) throws XPathFunctionException {
if (arg1.size()!=1){
throw new XPathFunctionException(“This custom XPath function requires exactly one argument!!!”);
}else{
return echo((String)arg1.get(0));
}

}

}

public static String echo(String text){
return text;
}

}

If you creating the java class via Eclipse then include the path %ORACLE_AS%\bpel\lib in your project.

2. Put the class as a jar in %JDEV_HOME%\jdev\lib\patches
3. Register the jar in the JDev User Defined Extension functions(Tools->Preferences->XSLMaps) file and restart JDev

<extension-functions xmlns:pcui=”http://www.oracle.com/PC/ui”>
<functions xmlns:utl=”http://www.oracle.com/XSL/Transform/java/customFunctions.sandeepphukan.test.echo”>
<function name=”utl:echo” as=”string”>
<param name=”text” as=”string”/>
</function>
</functions>
<functions xmlns:ora=”http://schemas.oracle.com/xpath/extension”>
</functions>
</extension-functions>

You should be able to see the custom Function in User Defined Extension Functions pallette:

XSL Mapper Custom Funtion Display

4. Edit the file %SOA_HOME%\bpel\system\config\xpath-functions.xml

<function id=”echo” arity=”1″> <!–Arity is the number of mandatory arguments –>
<comment><![CDATA[This function echoes the parameter....
<p/>
The signature of the function is <i>utl:echo('string')</i>.
The arguments are:
<ol type="1">
<li>string - single string parameter.
</ol>]]></comment>
<classname>customFunctions.sandeepphukan.test.echo$EchoFunction</classname> <!–Inner className –>
<property id=”namespace-uri”>
<value>http://www.oracle.com/XSL/Transform/java/customFunctions.sandeepphukan.test.echo</value>
<comment><![CDATA[Namespace URI for this function]]></comment>
</property>
<property id=”namespace-prefix”>
<value>utl</value>
<comment><![CDATA[Namespace prefix for this function]]></comment>
</property>
</function>

5. Drop the custom classes in the location %SOA_HOME%\bpel\system\classes. Incase you are using Eclipse you should be able to find these classes under EclipseWorkspace/ProjectName/bin/
6. Restart Oracle AS.

————————– For JDEV Expressions Builder ————————————
1. Copy the file %JDEV_HOME%/integration/lib/bpm-ide-common.jar to a temp directory.
2. Unjar the file %tempDir%/bpm-ide-common.jar with the following command
jar -xvf bpm-ide-common.jar oracle/tip/tools/ide/common/resource/PreBuiltExtensionFunctions.xml
3. Now edit the infalted PreBuiltExtensionFunctions.xml file and add the entry:
<functions xmlns:utl=”http://www.oracle.com/XSL/Transform/java/customFunctions.sandeepphukan.test.echo”>
<function name=”utl:echo” as=”string”>
<param name=”text” as=”string” required=”yes”/>
<pcui:ui>
<pcui:mapper palettePage=”Advanced Functions”/>
</pcui:ui>
</function>
</functions>
4. Now update the jar file with the command:
jar -uf bpm-ide-common.jar oracle/tip/tools/ide/common/resource/PreBuiltExtensionFunctions.xml
5. Finally put the jar file back into %JDEV_HOME%/integration/lib/ directory. You might want to keep a backup of the original jar before you do this.

Once done, restart JDeveloper and you should be able to see your custom function:

XPath Expressions Builder Custom Function Display

Testing it out :

1. Create a BPEL process
2. Use the transform activity and map input to output.
3. In the XSL file design mode open the components pallette and locate your function in the User Defined Extension Functions pallette.
4. Drag it and assign it.
5. Deploy it and run it in the AS.

Its pretty easy to do … just follow these steps:

1. The parameters that require to be passed to the XSLT should adhere to the following schema:

Parameter Schema

I have used a minOccurs of 2 but you may not need it …

2. Now create a variable based on this schema . Let us call it parametersVar.

create variable for parameter

3. Now set values to this variable. In this example I have taken the values from the input. A transform activity based on the xsl setParameters.xsl sets the input. you may also choose to hardcode the values.

populate the parameter variable

4.Now create another transform activity called callXSLT that maps the input to the output. This xslt defines two parameters viz. param1 and param2. The XSLT simply concats the two parameters and assigns to the output.

XSLT with Parameters

5. The BPEL process should now look like this:

BPEL process design view

6. Now open this BPEL process in source mode and edit the

<from expression=”ora:processXSLT(‘callXSLT.xsl’,bpws:getVariableData(‘inputVariable’,'payload’))

to include the parameters as this:

<from expression=”ora:processXSLT(‘callXSLT.xsl’,bpws:getVariableData(‘inputVariable’,'payload’),bpws:getVariableData(‘parametersVar’))”/>

The BPEL source should now look like this:

<?xml version = “1.0″ encoding = “UTF-8″ ?>
<!–
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Oracle JDeveloper BPEL Designer

Created: Mon Sep 08 13:47:27 IST 2008
Author: sphukan
Purpose: Synchronous BPEL Process
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
–>
<process name=”paramsFromBPELToXSLT”
targetNamespace=”http://xmlns.oracle.com/paramsFromBPELToXSLT”
xmlns=”http://schemas.xmlsoap.org/ws/2003/03/business-process/”
xmlns:bpws=”http://schemas.xmlsoap.org/ws/2003/03/business-process/”
xmlns:xp20=”http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20″
xmlns:ids=”http://xmlns.oracle.com/bpel/services/IdentityService/xpath”
xmlns:ldap=”http://schemas.oracle.com/xpath/extension/ldap”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:client=”http://xmlns.oracle.com/paramsFromBPELToXSLT”
xmlns:ora=”http://schemas.oracle.com/xpath/extension”
xmlns:xref=”http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions”
xmlns:hwf=”http://xmlns.oracle.com/bpel/workflow/xpath”
xmlns:aia=”http://www.oracle.com/XSL/Transform/java/oracle.apps.aia.core.xpath.AIAFunctions”
xmlns:ns1=”http://schemas.oracle.com/service/bpel/common”
xmlns:ehdr=”http://www.oracle.com/XSL/Transform/java/oracle.tip.esb.server.headers.ESBHeaderFunctions”
xmlns:bpelx=”http://schemas.oracle.com/bpel/extension”
xmlns:orcl=”http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc”>
<!–
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
PARTNERLINKS
List of services participating in this BPEL process
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
–>
<partnerLinks>
<!–
The ‘client’ role represents the requester of this service. It is
used for callback. The location and correlation information associated
with the client role are automatically set using WS-Addressing.
–>
<partnerLink name=”client” partnerLinkType=”client:paramsFromBPELToXSLT”
myRole=”paramsFromBPELToXSLTProvider”/>
</partnerLinks>
<!–
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
VARIABLES
List of messages and XML documents used within this BPEL process
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
–>
<variables>
<!– Reference to the message passed as input during initiation –>
<!– Reference to the message that will be returned to the requester–>
<variable name=”inputVariable”
messageType=”client:paramsFromBPELToXSLTRequestMessage”/>
<variable name=”outputVariable”
messageType=”client:paramsFromBPELToXSLTResponseMessage”/>
<variable name=”parametersVar” element=”ns1:parameters”/>
</variables>
<!–
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ORCHESTRATION LOGIC
Set of activities coordinating the flow of messages across the
services integrated within this business process
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
–>
<sequence name=”main”>
<!– Receive input from requestor. (Note: This maps to operation defined in paramsFromBPELToXSLT.wsdl) –>
<receive name=”receiveInput” partnerLink=”client”
portType=”client:paramsFromBPELToXSLT” operation=”process”
variable=”inputVariable” createInstance=”yes”/>
<!– Generate reply to synchronous request –>
<assign name=”setParameters”>
<bpelx:annotation>
<bpelx:pattern>transformation</bpelx:pattern>
</bpelx:annotation>
<copy>
<from expression=”ora:processXSLT(‘setParameters.xsl’,bpws:getVariableData(‘inputVariable’,'payload’))”/>
<to variable=”parametersVar”/>
</copy>
</assign>
<assign name=”callXSLT”>
<bpelx:annotation>
<bpelx:pattern>transformation</bpelx:pattern>
</bpelx:annotation>
<copy>
<from expression=”ora:processXSLT(‘callXSLT.xsl’,bpws:getVariableData(‘inputVariable’,'payload’),bpws:getVariableData(‘parametersVar’))”/>
<to variable=”outputVariable” part=”payload”/>
</copy>
</assign>
<reply name=”replyOutput” partnerLink=”client”
portType=”client:paramsFromBPELToXSLT” operation=”process”
variable=”outputVariable”/>
</sequence>
</process>

7. Save the file, validate and deploy the process.

8. Now initiate the process in Oracle AS and put the input as follows:

Initiate the BPEL Process

Notice that param1 and param2 are the parameters we defined earlier in the XSL file.

9. The output shows the result.

BPEL Process Flow Diagram

Output from the setParameters operation

Thats all…enjoy!!!