DVM in SOA Suite 12c

Working with DVM in SOA Suite 12c

Today, we are going to learn the concept of Domain Value Maps(DVM) in Oracle SOA Suite 12. They enable you to map from one vocabulary used in a given domain to another vocabulary used in a different domain. For example, one domain may represent a city with a long name (Mumbai), while another domain may represent a city with a short name (MB). In such cases, you can directly map the values by using domain value maps. 

Domain value map values are static. You specify the domain value map values at design time using Oracle JDeveloper, and then at runtime, the domain value map columns are looked up for values.

Use of DVM will be demonstrated in forecoming steps.Prior to that let me give you brief overview of our usecase. We will create a synchronous BPEL process that will receive inputs such as firstname,lastname,city and will retrurn corresponding city code in the output, along with full name.

Step 1: First create a new SOA project "DVMTutorial" and create a new synchronous BPEL process named as "DVMProcess"

Step 2: Created xsd in below screenshot 

Step 3:We have create a new synchronous BPEL process.

Step 4: Now lets create DVM. Go to NEW--> SOA Tier --> Domain Value Map and click OK. 

Step 5: Wizard will open to create DVM. Give the name to dvm as "Cities.dvm" and under Domain Names add 2 fields "CityName" and "CityCode" with values as "Mumbai" and "MB" respectively.Click OK.

Step 6: Cities.dvm will get created.Kindly note the extension of dvm files are ".dvm". Now add some more data to this DVM and save all.

Step 7: Open your BPEL process.We will be manipulating the cityname in the input and will return corresponding CityCode in the output.For this, drag and drop assign activity between receive and reply activity.Drill down to City in your output variable and add expression.

Step 8:  Scroll through list of avilable function and under "DVM Functions" ,insert lookupValue onto the expression field.If you see in the description of the function: 

dvm:lookupValue(dvmMetadataURI as string, SourceColumnName as string,SourceValue as string, TargetColumnName as string, DefaultValue as string) as string. 

It expects dvm to be used,source column name and source column value to be looked for in dvm and target column name whose corresponding value will be derived from DVM.

Step 8: Insert values for source column as "CityName" and its value will be passed runtime during invocation of BPEL process,target column "CityCode" whose value will be looked upon at runtime. Your expression will look something like this: 

dvm:lookupValue("Cities.dvm","CityName",$inputVariable.payload/ns1:City,"CityCode",'NA')

Step 9:  Click OK,save all and deploy your composite to EM.

Testing your Composite:

Open up your composite from EM and click on Test Button.Pass values in all fields and under City field enter "Mumbai" and test.You will see in the response document City value "MB".

Oracle SOA Mediator Sample Example

Oracle SOA Mediator

Mediator is one of the service component of the Oracle SOA Suite, there are four main functionality of Mediator

Routing : Mediator route incoming payload to the external service based on routing rule

Validate: Mediator performs XSD schema validation , it describes the structure of xml payload

Filter: Mediator defines a filter expression that specifies the service to be invoked if the payload satisfy filter condition

Transform: Mediator performs XSLT transformation , it transforms data suitable for the target                                                                                                                                                                                                                                                                    In this Demo we will be creating a composite application that routs the incoming payload to the BPEL process based on filter expression

Step 1: Click File –> new –> project –> SOA Project 

Click OK                                                                                                                                                                     Step 2: Enter the project name and click next

 Click Finish                                                                                                                                                                  Step 3: Create a Schema for input and output 

Step 4: Expose a SOAP service, drag a Soap from component panel and drop it in exposed service 

Name it as ProductDeliver, in WSDL URL click on Generate WSDL from schema as shown above 

In Interface Type choose Synchronous Interface  and click on + sign at input and name it as Request  , browse for input schema element

Choose the input element and click OK,Do the same for output click on + sign at output and name it as Response, browse for output schema element and click OK.

 Now u have exposed a SOAP Service                                                                                                                    Step 5: Drag a mediator component from component panel and drop it in Components 

 and click OK  

Now connect SOAP service with mediator
Step 6:Drag a BPEL process from component panel and drop it in components, name it as DLF and in Template choose Synchronous BPEL Process

In input click browse and select input schema element, Click OK

 In output click browse and select output schema element, Click OK

And uncheck Expose as a SOAP Service and click OK Now that u have create a BPEL Process (DLF), Follow same steps to create two more BPEL name it as Emirates and FedEx

Now connect this three BPEL to the mediator

Double click on mediator, u will find three section pointing to DLF, Emirates and FedEx BPEL

In DLF section click on filter to specifies routing rule

In routing rule we are going to compare payload element i.e. deliveryLocation  with India,if  true it will route to DLF BPEL

Click OK

Now assign payload to the input of DLF BPEL by click Assign value in mediator

After mapping payload with input of DLF BPEL

Click OK

Now that u have mapped input to DLF BPEL, u should get the out from DLF BPEL and mapped it to SOAP response

In Synchronous reply click on Assign value

Map the out of DLF BPEL to the SOAP response, Click OK

Now that u have done with DLF BPEL, do the same for Emirates and FedEx

BPEL and assign value for request and response

If deliveryLocation  is Dubai,it will route to Emirates BPEL else if deliveryLocation  is USA,it will route to FedEX BPEL

Step 7: Click on DLF BPEL , drag  assign from components panel and place it in BPEL

Double click on assign and concat product name with courier name as shown below

Do the same for Emirates and FedEx BPEL

Save all the changes and deploy the application

Step 8: Test the Application

1)

Request

Response

2)

Request

Response

3)

Request

Response

Difference between XA and NonXA DataSource and Limitations with NonXA

Difference between XA and NonXA DataSource 

An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.

It involves more than one resource (different databases, queues, application servers) all participate in one transaction. It uses two-phase commit to ensure that all resources either all commit or rollback any particular transaction. When you have scenario like you need to connect to two different databases, JMS Queue and application server, in this case you will use XA transaction that means all resource participate in one transaction only.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.

Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).

For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".

Ref : http://www.theserverside.com/discussions/thread.tss?thread_id=21385

Limitations and Risks When Using a Non-XA Driver in Global Transactions

WebLogic Server supports the participation of non-XA JDBC resources in global transactions, but there are limitations that you must consider when designing applications to use such resources. Because a non-XA driver does not adhere to the XA/2PC contracts and only supports one-phase commit and rollback operations, WebLogic Server (through the JTS driver) has to make compromises to allow the resource to participate in a transaction controlled by the Transaction Manager.
Consider the following limitations and risks before using the Emulate Two-Phase Commit for non-XA Driver option.

Heuristic Completions and Data Inconsistency

When Emulate Two-Phase Commit is selected for a non-XA resource, (enableTwoPhaseCommit = true), the prepare phase of the transaction for the non-XA resource always succeeds. Therefore, the non-XA resource does not truly participate in the two-phase commit (2PC) protocol and is susceptible to failures. If a failure occurs in the non-XA resource after the prepare phase, the non-XA resource is likely to roll back the transaction while XA transaction participants will commit the transaction, resulting in a heuristic completion and data inconsistencies.
Because of the data integrity risks, the Emulate Two-Phase Commit option should only be used in applications that can tolerate heuristic conditions.

Cannot Recover Pending Transactions

Because a non-XA driver manipulates local database transactions only, there is no concept of a transaction pending state in the database with regard to an external transaction manager. When XAResource. recover() is called on the non-XA resource, it always returns an empty set of Xids (transaction IDs), even though there may be transactions that need to be committed or rolled back. Therefore, applications that use a non-XA resource in a global transaction cannot recover from a system failure and maintain data integrity.

Possible Performance Loss with Non-XA Resources in Multi-Server Configurations

Because WebLogic Server relies on the database local transaction associated with a particular JDBC connection to support non-XA resource participation in a global transaction, when the same JDBC data source is accessed by an application with a global transaction context on multiple WebLogic Server instances, the JTS driver will always route JDBC operations to the first connection established by the application in the transaction. For example, if an application starts a transaction on one server, accesses a non-XA JDBC resource, then makes a remote method invocation (RMI) call to another server and accesses a data source that uses the same underlying JDBC driver, the JTS driver recognizes that the resource has a connection associated with the transaction on another server and sets up an RMI redirection to the actual connection on the first server. All operations on the connection are made on the one connection that was established on the first server. This behavior can result in a performance loss due to the overhead associated with setting up these remote connections and making the RMI calls to the one physical connection.

Only One Non-XA Participant

When a non-XA resource (with Emulate Two-Phase Commit selected) is registered with the WebLogic Server Transaction Manager, it is registered with the name of the class that implements the XAResource interface. Since all non-XA resources with Emulate Two-Phase Commit selected use the JTS driver for the XAResource interface, all non-XA resources (with Emulate Two-Phase Commit selected) that participate in a global transaction are registered with the same name. If you use more than one non-XA resource in a global transaction, you will see naming conflicts or possible heuristic failures.

It involves only one resource. When you use Non-XA transaction then you can’t involve multiple resources (different databases, Queues, application servers etc), you can rollback or commit transaction for only one resource. There is not transaction manager for this transaction as we are dealing with only one resource at a time.

JMS Configuration in Weblogic server(SOA&OSB)

Introduction

• JMS stands for Java Message Service. JMS is an API that provides facility to read, create and send messages. JMS is asynchronous (To receive the message, client is not required to send request. Message will arrive automatically to the client) communication.
• JMS is mainly used to send and receive message from one application to another.
• Following are the messaging domain in JMS

  Point-to-Point messaging domain: In this model, one message is delivered to one receiver                     only. There will be a QUEUE to hold the message until the receiver is ready.

Publisher/Subscriber (Pub/Sub) Messaging domain: In this model, one message is delivered to all the subscribers. There will be a TOPIC to hold and deliver 

JMS Programming Model

JMS Queue (Point-to-Point messaging domain) configuration

In Case of Point-to-Point messaging, QUEUE will hold the message until the receiver is ready to receive the message. Here, we shall be creating two JNDI in Weblogic 12c.

• Create connection factory named queuedConnFactory
• Create destination resource named, myQueue

Once JNDI is created, server and receiver application needs to be created. Server and Receiver needs to run in two different console.

Create the following in Weblogic server

Create JMS Server

• Login to the weblogic admin console (localhost:7001/console)
• Click on JMS server as shown below and create the server called myJMSServer. Select available target in the next page

Create JMS Module

Follow the below screenshot to create JMS Module

Create Subdeployment

Follow the below screenshot to create Subdeployment

Create Connection factory

Follow the below screenshot to create Connection Factory 

Create JMS Queue

Follow the below screenshot to create JMS Queue

Done with configuration

If you see below two screens that means you are done with the configuration

Connection factory and JMS Queue under JMS module will look like this 

Connection factory and JMS Queue under Subdeployment will look like this