SOA Suite 11g - Transaction(s) & boundaries; Part One

As we added new/updated components I figured it'd be wise to post a little bit about transaction semantics in 11g - and how they can be used to leverage the underlying JTA infrastructure that is backing the execution of components.

a) Mediator:
On the inbound side, when mediator is invoked via binding.ws it will create an manage a new transaction, otherwise (e.g. if invoked through an adapter it will inherit the existing transaction)

In more generic terms:
If a transaction is present, Mediator participates in that existing transaction. If transaction is not present, Mediatorstarts the transaction

In case of sync (aka sequential) routing rules, they will be all executed in the same transaction, and if an error occurs, a rollback will be issued.
Note: in this case even a fault policy that is configured against a mediator fault will NOT trigger.

In case of async routing rules, each rule will be executed in a new transaction, and if errors occur, a rollback will happen, and a fault policy can be configured to react to it.

b) BPEL:
By default (as in previous releases) BPEL will create a new transaction on request basis - that is if one already exists, it will be suspended, and a new one created. Upon completion of the child, the master one resumes.
However, if the request is async (that is one-way) we either inherit the transaction for the insert into the dehydration store (that is dlv_message in this case) or if one exists enlist transparently into it. So we guarantee you zero message loss. Either the invocation message is in the dehydration store, to be processed, or otherwise the consumer is notified via a fault.

In 10.1.3 we had a couple of flags that one could set on the consuming process (that is the partnerlink) as well as on the providing one, to chain an execution into a single global transaction. Namely, on the consumer side, one had to set transaction=participate on the partnerlink binding in bpel.xml, and on the providing sidetransaction=participate in the <configurations> section of bpel.xml.
In 11g BPEL - we adopted a more j(2)ee alike concept - and one only needs to set the (new) transaction flag on the calee bpel component. This can be done in the composite editor's source by adding bpel.config.transaction into a bpel component - as shown below

  <component name="InternalWarehouseService">

    <implementation.bpel src="InternalWarehouseService.bpel"/>

    <property name="bpel.config.transaction" 

         many="false" type="xs:string">required | requiresNew</property>

  </component>

The two possible values are required, which makes BPEL inherit the tx that is already there, or if not creating a new one (required), or suspending one if exists, and ALWAYS create a new one (requiresNew).

What are the implications of setting the above (the default is requiresNew)?

Case one - BPELCaller calls BPELCallee (the latter has requiresNew set)
a) BPELCallee replies (that is uses <reply>) with a fault: BPELCallee transaction is saved, BPELCaller get's the fault and can catch it
b) BPELCallee throws (that is uses <throw>) a fault, that is NOT handled: BPELCallee tx get's rolled back, BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCallee tx get's rolled back, and BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCallee tx get's rolled back, BPELCaller get's a remote fault

Case two - BPELCaller calls BPELCallee (the latter has required set)
a) BPELCallee replies (that is uses <reply>) with a fault: BPELCaller get's the fault and can catch it, BPELCaller owns the transaction - hence if he catches it - tx is committed, if BPELCaller does not handle it - global rollback.
b) BPELCallee throws (that is uses <throw>) a fault BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCaller tx get's rolled back, no way to catch it.

So with the above in place - one thing that I usually have people try when they are in my 11g courses is to create two processes (BPELMaster and BPELChild), both sync, each using the same db adapter reference that inserts the same record (and hence causes a PK violation). (And of course has set xADatasourceName)

So what happens in the default (that is without bpel.config.transaction property set). Once the fault occurs, and is not handled - the BPELChild will rollback. If the BPELMaster has a catch block his transaction will commit, so you end up with the record from the Master in the db.

If you don't catch the fault in the master as well - you get a second rollback - two different transactions though :-)

The second exercise is to set the bpel.config.transaction to required, and run the testcase again. If no fault handlers are in place - the whole tx will rollback, based on the BPELMaster's unhandled fault.

Now add a fault handler in the BPELMaster to catch the Fault from the BPELClient - and throw up a rollback fault. Globally the tx will rollback as well.

With this in place - you can really control transaction boundaries and model end2end transactional flows (if your source / targets are transactional as well of course)

what is difference between Abstract wsdl & concrete wsdl ?

Abstract wsdl:-Used on server side,contains request,response and type of operation performed.
concrete wsdl:-used on client side,contains abstract wsdl and transport used.

Abstract WSDL contains only messages and operations. Abstract WSDL is used by web Server where as concrete WSDL contains messages, operations and binding/transport specific information i.e. SOAP over Http/HTTPS/JMS having wsdl style i.e. RPC/DOC literal.

Abstract WSDL consists of the structure of the message that is like what operation, what is the input and what is the ouput . Whereas in concrete WSDL has all the things that the abstract wsdl has in addition it has transport(http,jms) details.

Abstract wsdl:- Used on server side,contains request,response and type of operation performed.
concrete wsdl:- Used on client side,contains abstract wsdl and transport used.

● An abstract WSDL document describes what the web service does, but not how it does it or how to contact it. An abstract WSDL document defines:
the operations provided by the web service.
the input, output and fault messages used by each operation to communicate with the web service, and their format.
● A concrete WSDL document adds the information about how the web service communicates and where you can reach it. A concrete WSDL document contains the abstract WSDL definitions, and also defines:
the communication protocols and data encodings used by the web service.
the port address that must be used to contact the web service.
.
Including Abstract WSDL is reusable because there is no binding details in it whereas Concrete WSDL used for specific service for which it is defined.

Abstract wsdl creation:-
Drag wsdl palette from palette window to designer windoow and make configure the respective input and output schemas and create the porttype  and inside that one create the operation and configure u created the schemas inside of that operation.create one process and Drag soap event source activity and configure ur wsdl just now u created above and make the necessary transport ie http or jms and in the configuration section of ur soap event soap select wsdl source option and select and save that in ur local drive .That is nothing but ur concrete wsdl .Create one folder inside of ur projects and import ur concrete wsdl inside of that directory .create one more soap request reply activity  inside of ur newly created process and configure ur newly imported schema.


Abstract WSDL consists of the structure of the message that is; what operation, what is the input and what is the ouput . Whereas in concrete WSDL has all the things that the abstract wsdl has in addition it has transport(http,jms) details.

Lesson03-Meta Data Store Archives

MDS – Meta Data store facilitates greater re-use of SOA artifacts such as XML Schemas, EBMs, WSDLs, DVMs, Fault Policies, Rule repositories and Service Data Objects (SDOs) among others.

Here we are going to discuss how to use Database based MDS for storing application specific artifacts mentioned above.

Each MDS repository can have multiple partitions. Partitions are logical separations in the tables to enable metadata from different applications to co-exist in the same physical repository schema without conflicting with each other. We can edit partitions in a repository using EM console or WLST commands.

Each MDS partition should have a well defined directory structure as this affects the way you are going to access the artifacts from your composite applications. Any change in the MDS structure results in change to the composite application.

A typical MDS structure for SOA11g direct integration without using AIA would look as follows. Here SAP2-EBS2 highlighted in yellow is the name of the partition which you want to be created in MDS. This structure is derived from AIA application for the sake of consistency and standardization however it could be anything.


Now that we have the directory structure in place we will write ant scripts to create a zip archive and deploy it to the server using ant script MDSLifecycle.xml. Please go through the comments in the ANT file to understand the variables that we have to set.

Copy MDS artifacts / directory structure to your local machine or to the server and set the variables as specified in the sample. Following commands can be used for deploying / undeploying all the artifacts.

ant -f MDSLifecycle.xml deployMDSArtifacts
ant -f MDSLifecycle.xml undeployMDSArtifacts

We have to establish connection using JDeveloper with the database which is being used for the MDS and then verify if the artifacts are getting deployed or un-deployed from the MDS after executing the commands mentioned above.

In JDeveloper -> Application resources –> connection -> SOA-MDS –> following screen will appear and you have to provide Database connection details.
Once the connection is established through JDeveloper and ant commands are successfully executed we can verify the deployment as shown in following screen.

We will see the advantages of this approach during development phase and how to export / import MDS artifacts and delete individual files from MDS using ant + wlst combination in next article.

VN:F [1.9.11_1134]

Lesson02-Mediator Archives

Let us see how we can utilize features of Mediator component (previously known as Oracle ESB) to implement the following use-case.

MyBay is a fictious online store that lets customers view and place orders over the internet. MyBay utilizes its logistics partner MyDel to ship orders to customers. IT systems to handle order processing are created and maintained by MyDel.

MyBay can post order information to MyDel through MyBay’s online portal using Webservices. MyBay can also batch orders and transfer the file across to MyDel using FTP.

Step 1: Design Enterprise Business Objects (EBO)
First step is to create our canonical model. We need to carefully think through data, task and functional elements so as to maximize re-usability and minimize data transformation.
Namespace: Qualify schema with a meaningful namespace. Usually this takes the form of http://<your_website_url>/<organization>/<function>/xsd/
In our case, we’ll name it http://orafmwschool.com/training/mediator/xsd/OrderProcessing

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
targetNamespace="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
elementFormDefault="qualified">

Schema Elements: At a very minimum, we need information about selected item, transaction date and address it needs to be shipped to.

<xsd:element name="orderDetails" type="tOrderDetails"/>
<xsd:complexType name="tOrderDetails">
<xsd:sequence>
<xsd:element ref="itemDetails"/>
<xsd:element ref="transactionDate"/>
<xsd:element ref="shipTo"/>
</xsd:sequence>
</xsd:complexType>

Complete Order.xsd schema can be found here. Copy this XSD file into “xsd” directory of the project.
Step 2: Design Enterprise Business Message (EBM)
Enterprise Business Message is a wrapper over EBO. It usually combines one or more elements from EBO to create a meaningful input and output messages for the SOA services. In the current example, we’ll create two message elements: OrderDetailsRequest and OrderDetailsResponse. However, we need to refer to Order.xsd in order to use elements defined in the EBO.

<xsd:import
namespace="http://orafmwschool.com/training/mediator/xsd/OrderProcessing"
schemaLocation="Order.xsd"/>

<xsd:element name="orderDetailsRequest" type="tOrderDetailsRequest"/>
<xsd:complexType name="tOrderDetailsRequest">
<xsd:sequence>
<xsd:element ref="ord:orderDetails"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="orderDetailsResponse" type="tOrderDetailsResponse"/>
<xsd:simpleType name="tOrderDetailsResponse">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="SUCCESS"/>
<xsd:enumeration value="FAILURE"/>
</xsd:restriction>
</xsd:simpleType>

Complete OrderProcessingEBM.xsd can be found here. Copy this file to “xsd” directory of the project.

Step 3: Design abstract WSDL interface
Next step is to create an abstract Webservice interface that can be used in SOA services. In our case, we shall create two message elements: OrderDetailsRequestMessage and OrderDetailsResponseMessage.

<message name="OrderDetailsRequestMessage">
<part name="payload" element="ebm:orderDetailsRequest"/>
</message>

<message name="OrderDetailsResponseMessage">
<part name="payload" element="ebm:orderDetailsResponse"/>
</message>

Now that we have request and response messages created, we shall create an operation that consumes these messages.

<portType name="WSReadOrder">
<operation name="ReadOrder">
<input message="tns:OrderDetailsRequestMessage"/>
<output message="tns:OrderDetailsResponseMessage"/>
</operation>
</portType>

Complete OrderProcessing.wsdl can be found here. Do observe the xsd import element to import schema from MDS.
Step 4: Creating SOA Composite
Shown below is the snapshot of the composite we are eventually going to create. On the left side of the picture, you can see two services:

1. Service to read order details from File. OrderFTPABCS will then transform order records into canonical form before passing them to OrderABCS.
2. Webservice that external customers can invoke to post order details. These details are read directly in canonical form.

On the right side of the picture, we can see OrderManagementDBAdapter service that updates order details into Order Management Database. OrderABCS acts as a glue between all these services.

Proceed to Mediator Example Implementation.

VN:F [1.9.11_1134]

lesson 1 Hello World BPEL Process

We are going to learn how to create our first “Hello World” process in Oracle SOA 11g today. It presumes Oracle SOA 11g is installed and started. Also, JDeveloper should have composite editor plugin installed.

Open JDeveloper 11g (11.1.1.3.0). If not already downloaded, you can get it from http://www.oracle.com/technology/software/products/jdev/htdocs/soft11.html Create a new Generic Application and name it SOATrainingSamples.


Click Next. In the next screen, specify New Project Name as HelloWorld. From available technologies, select SOA. This will import SOA relevant libraries into our project.

From next screen, select Composite with BPEL option. There are other composite options available, which we’ll explore in other samples.


Click Finish. This will prompt a “Create BPEL Process” screen. Name BPEL process as HelloWorldProcess. Select “Synchronous BPEL Service” template. Click OK.


JDeveloper creates HelloWorldProcess BPEL components and displays corresponding BPEL process.


From list of activities on the right hand navigation pane, lets drag “Assign” activity and drop between “receiveInput” and “replyOutput” activities.


Double click on “Assign_1″ activity and open it. Select “Copy Operation” from this screen.


Copy following expression into Expression Field. concat(‘Hello ‘, bpws:getVariableData(‘inputVariable’,'payload’,'/client:process/client:input’))

This can also be created from XPath Expression Builder. Assign this expression to “outputVariable” as shown above and click OK.


Compile BPEL process by clicking on “Make HelloWorld.jpr” link as shown below:


Ensure BPEL process is successfully compiled. To deploy to Weblogic server, right click on “HelloWorld” from left side navigation and select Deploy -> HelloWorld. Following images show sequence of steps to deploy BPEL executable.





Connection to SOA Server needs to be created beforehand. In this example, a connection named SOAServerConnection was already created.



A successful deployment message is displayed at the bottom of JDeveloper window.


Next, let us check the deployed process through Weblogic’s EM console. Open http://localhost:7001/em. Drill down to “default” domain from SOA node on the left side navigation bar.

Select “HelloWorld [1.0]” process and click on “Test” service.

Under “Input Arguments” section, we can see “input” as one of the fields of payload. Enter “World” in input field and click on “Test Web Service”.

Input payload can also be seen in XML format by selecting “XML View”.

Response will have “Hello” prefixed to our input string “World”.

This completes our Hello World process.

What is Fusion Middleware?

Oracle Fusion Middleware consists of several Oracle products, built over the years and recently acquired, that will help build end to end solutions. Oracle has been attempting to bring all these products under one roof. With recent release of Oracle Fusion Middleware 11g R1, I must say that it has managed to do it pretty well.
Oracle Fusion Middleware provides fully integrated products that can be divided into four important categories:

1. Data and Application Layer: Products in this category help build integration with various databases, legacy/custom applications and ERP products.
2. Business Process Layer: Products in this category utilize the integrations built in the data & application layer to create re-usable orchestrated services.
3. User Interface Layer: Products in UI Layer will assist in creating sophisticated user interfaces supporting multiple delivery channels such as web, mobile etc.,
4. Identity Management Layer: This is the security backbone of entire Fusion Middleware. We can easily plug-in authentication, authorization in standalone and/or distributed server environment. 

It is important to note that most of the products in each of these layers can also be used independently. But major value addition of Fusion Middleware is that most of these products are pre-integrated, creating grater synergy and re-usability.
Given the no. of products involved, this blog focuses on the backbone of Fusion Middleware: Business Process layer.

Oracle SOA Suite 11g is the product set for Business Layer. Individual constituents of Oracle SOA Suite and their description given below:
Oracle BPEL Process Manager: BPEL stands for Business Process Execution Language. It is a XML based declarative language that can be used implement end to end business processes. Basic building block of these processes is a service, which could be a web service. BPEL utilizes various adapters to service enable legacy and custom applications before consuming them in processes. BPEL also provides human workflow that has variety of uses.
Oracle Service Bus: OSB is an enterprise level service bus that was originally part of Weblogic before acquisition. OSB offers very useful features for service virtualization, canonical models and very efficient payload transformations. OSB is normally used to complement Oracle BPEL Process Manager.
Oracle Business Activity Monitoring: BAM is a real-time service monitoring tool that can be used to track an end to end process created by BPEL/OSB. BAM offers real-time dashboards that can be help diagnose potential bottlenecks in the processes before they occur. BAM can be easily plugged into BPEL PM using simple integration.
Oracle Business Rules: As the name suggests, its a product to create and use business rules. This can act as central repository for various rule artefacts and thus facilitate greater re-usability. It can be easily integrated with rest of Fusion Middleware products.
Oracle B2B Integration: Used to connect with trading partners using industry standard protocols such as RosettaNet, EDIFACT etc., It can interface with E-Business Suite using XML Gateway and rest of Fusion Middleware using IP Queues.
Oracle Complex Event Processing: CEP provides architecture for creating, processing and publishing events in an enterprise to create an event driven environment.
Together, above products can be used to define and implement Service Oriented Architecture.

ADDING XSD AND WSDL IN MDS IN A FILE BASED MDS

SOA Suite 11gR1 has a provision for sharing SOA artifacts through MDS – Meta Data Store. This facilitates greater re-use of SOA artifacts such as XML Schemas, EBMs, WSDLs, Fault Policies, Rule repositories and Service Data Objects (SDOs) among others. MDS can be file-based or database-based. Here are the steps to create and use file-based MDS in JDeveloper.

MDS is created under <jdeveloper-home>/integration/seed directory. Default folder “soa” is used to store common system soa artifacts. All custom artifacts are supposed to be stored under a folder called “apps”, since this folder already exists in server.

Create directory structure under apps folder. In this example, I’ve created folder structure ../apps/com/wordpress/orafmw/training/xsd to store XML schema files. This ideally should match your schema structure.


In JDeveloper, expand Descriptors/ADF META-INF and open adf-config.xml.



Create an entry for metadata store location.

<metadata-namespaces>
<namespace metadata-store-usage=”mstore-usage_1″ path=”/soa/shared”/>
<namespace metadata-store-usage=”mstore-usage_2″ path=”/apps/com”/>
</metadata-namespaces>

Specify MDS storage location.

<metadata-store-usage id=”mstore-usage_2″>
<metadata-store class-name=”oracle.mds.persistence.stores.file.FileMetadataStore”>
<property value=”D:\PROGRAMS\OracleMiddleware11g\jdeveloper\integration” name=”metadata-path”/>
<property value=”seed” name=”partition-name”/>
</metadata-store>
</metadata-store-usage>

Use defined artifacts directly from MDS.

<xsd:schema elementFormDefault=”qualified”>
<xsd:import namespace=”http://orafmw.wordpress.com/training/mediator/ebm/OrderProcessing”
schemaLocation=”oramds:/apps/com/wordpress/orafmw/training/xsd/OrderProcessingEBM.xsd“/>
</xsd:schema>

Deploy MDS Repository to Weblogic Server

First, we need to create JAR file bundle to include schemas we need. Then we need to include this jar file into a SOA bundle that can be deployed to the SOA Server.
Create Generic Application – MediatorMetaData


Create a project – MediatorLib

Right click on MediatorLib and select New –> Deployment Profile –> JAR File

Enter mediatorlib as the deployment profile name.

In the JAR deployment properties dialog, click on Contributors, click on Add button and select apps directory from JDeveloper seed location – <jdeveloper_home>/integration/seed/apps.




Click on Filters and select the schemas you would like to be deployed.

Click on OK. This completes creation of JAR file. We now need to create an application deployment profile to install these schemas in SOA Server.
Right click on MediatorMetaData application and select Deploy –> New Deployment Profile. Select “SOA Bundle” as Profile type.

Enter mediatorlib for Deployment Profile Name. From the properties dialog, open Dependencies and select mediatorlib.

To deploy MediatorLib to SOA Server, right click on MediatorMetaData and select Deploy –> mediatorlib.

VN:F [1.9.11_1134]