Handling Rejected Messages - SOA 11G

Hi Guys,

Was busy past couple of months due to work and all. Finally got time to wrtie a new blog. Today, I would be explaining how do you handle rejection messages in BPEL. Rejection messages are basically the messages your composite receives but its not as per the format expected by your service , due to which BPEL instance do not get created. So your flow doesnot goes into your BPEL and there is no way to handle that exception in your code.

Below is the extract taken from Oracle:

The messages that error out before being posted to the service infrastructure are referred to as rejected messages. For example, the Oracle File Adapter selects a file having data in CSV format and tries to translate it to XML format (using NXSD). If there is any error in the translation, this message is rejected and are not be posted to the target composite.
Primarily, adapters and binding components are the generators of rejected messages.


To handle such scenarios where you need to take specific action if you get rejected messages, you can use fault management framework. Lets do it step by step.

To illustrate this, I have created sample interface that reads a CSV file from a location and there is only single receive activity inside the BPEL that will receive the input.

Based on the CSV file , I have created a sample schema and configured our File adapter to read the file based on this schema.

My composite is already deployed on EM. Lets test it. This is the file that I have placed in input directory.

Instance will be created , since the file is in correct format. Verify by opening the instance and checking your input.

Now create a Fault Policy file and fault bindings file and place it in the folder that has composite.xml.

Open the fault policy file and define a fault policy for the rejected messages in the fault-policies.xml file, stored with the composite.xml file in the JDeveloper project directory. In the file add the name of your service adapter in the faultname section. In our case it is "readFile". And the action define "writeTofile" that will write the rejected message in the location specified with the filename that is given.

Now associate the fault policy with a service endpoint of the composite in fault-bindings.xml, as is done in the following screenshot:

Deploy your composite and place some file in the input directory thats not as per the schema.

New instance wont get genereate. Instead you will see error message under "Faults and Rejected Messages". Click on the error message and open payload. 

Now this failed message will be writtten to the file and the location that we gave in our fault policy. Go to that location and verify the same.

This way , we can handle rejection messages and take appropriate actions depending upon the requirements.

For more information please refer Oracle Documentation: Rejection Messages

Hope this post was useful to you.

Happy Learning,
Cheers 

DB Adapter Polling using Sequencing File - SOA 11G

I will be explaining today steps to create a polling DB adapter based on sequencing file.Most commonly used After Read "Logical Delete" strategy, I have explained already in one of my previous posts.So, I will just explain configuration required for sequencing file polling DB adapter. Remaining configuration, how to configure DB adapter , please refer to my post on DB adapter tutorial.

Step1: Open up your DB adapter wizard and select "Poll for new records or changed records" in the operatrion tab and in step 8 of After Read screen, select Update a Sequencing File.

Step2: Click next. In next window that pops up, select the sequencing file by passing the complete physical path.I have created a sequencing file on my server only under my servers logs directory.In sequence ID field, select the field from table which will act as sequence ID and on basis of which DB adapter will poll for new records.In my case I have selected Transacion ID.Complete the all steps and design your BPEL process.

Step3: Now If you look at my table structure, there are two columns Transaction Id and Notes.Our DB will poll on Transaction ID. Let me explain you, how this sequencign file concept works.
You have to create one sequencing file and in that file you will enter value of only that field which will always be incremented in ascending order in the table when new records are being inserted. Lets say in table we have 3 records with transaction ID as 1,2 and 3. In my sequencing file I will enter 1 and save it.Now Our DB poller will poll for all records with transaction ID greater than 1(current value in sequencing file) and value in the sequencing will automatically will be changed to 3. Next time new records inserted with trabsactiond ID greater than 3, all those records will be polled and so on.

Step4: I have created one sequencing file with transacion ID value as 4304.Please note only sequence ID(transaction  ID in our case) value should be there in file, nothing else.

Step5: In my table I have 3 records that have transaction ID greater than 4304. All those records will be polled. Verify the same on EM under instances Tab.

Step6: Also verify your sequencing file to reflect the updated value of transaction ID as 4393.

In this way DB poller based on sequencing file works.
Hope this post is helpful to you.

Happy Learning,
Cheers,
Karan

Unable to Edit Database/File Adapter in JDev - SOA 11G

Hi All,

There is one issue that lots of people faces while importing an existing SOA project into JDeveloper.For instance, you have a composite that is polling records from DB and writing it into some file. After importing when you try to edit DB or File adapter by double clicking the wizard simply wont open up. Strange isnt it.
Even if you reimport the same project it will still not open.What could be the issue here.

The simple solution or workaround you can say is add the below line in your respective WSDL file of File or DB or JMS adapter(any JCA adapter):
<?binding.jca readFile_file.jca?>

 

where readFile_file.jca is the jca file name of your file adapter. In case of DB Adapters, it would be filename_db.jca and in case of JMS adapter would be filename_jms.jca and hence so on for all other JCA adapters.


Save your WSDL file close it and now double click on your adapter. Bingo its opening now :) Nice isn'it.

Hope this post will help many of you frustrated facing such type of issues.

Happy Learning...

Cheers,
Karan

Retry and Rollback using DB adapter - SOA Suite 11G

Hi All,

Retrying and rolling back transactions that got failed while invocation is one of the major things that needs to be keep in mind while designing the solution for any interface.As it helps in preventing any data discrepancy that can be there between source and target systems,had there not been any rollback in case of failed transaction.

I will be demonstrating,how to retry and rollback failed transactions in SOA.To illustrate this use case I will be using one JMS queue from where our composite will consume the message and, after that it will insert data in 3 tables that I have created for this usecase.you will be requiring XA JNDIs both for Database and JMS Adapters.

Three tables have been created namely Customer,Order, and Invoice.Our SOA process will insert records in table in the same order.

On weblogic console,we need to set some properties for our jms queue for retry functionality.Just go to your jms queue and navigate to "Delivery Failure" tab for your queue.Set following parameters

• Redilvery Delay Override: 10000 (10 seconds) It is the interval after which rolledback messages will be retried.
• Redilvery Limit: 2 (Number of times failed message will be retried).
• Expiration Policy: Redirect (or Discard, if you want to discard the message after retry) Redirect will move the message to "Error Destination" if even after configured retry parameters message is failed.
• Error Destination: <Queue Name> Queue to which failed message will be moved after all retry attempts.

In the BPEL process, add catch or catch all handler for your composite to handle any faults that may occur.In the Catch All block ,explicitly throw a rollback fault using throw activity.It will rollback the complete transaction i.e. undo all the data inserted in any of the tables and then request message will be rolled back to the jms queue.

NOTE: Any fault thrown using throw activity that is not being caught will result in rollback of complete transaction.

Now,first we will test the happy path.Deploy your code to EM and test the interface.Records will be inserted into all the tables successfully.

To see how rollback works,I will intentionally change the DB jndi for Invoice adapter.To do that open jca file for your Invoice DB Adapter and give some random value in that.Save and redeploy the code.Now the interface will fail while inserting the data in Invoice table and flow will got to Catch All block,where transaction will be rollbacked.

To validate this,check the tables and no new records would have been inserted into the tables.

Since we have configured,retry parameters for our request queue, the rollbacked message will be retried again after 10 seconds.Message state will be changed to "delayed" which means it is being retried.

After all failed attempts the message will be redirected into the error destination that we have configured for our queue.

In this way, you can implement retry and rollback functionality in your interfaces.
Hope this helps you.


Happy Learning,
Cheers !!!

High Availability and Scalability DB adpater - SOA Suite 11G

The Oracle Database Adapter supports two high availability setups.

• Active-Active setup
• Active Passive setup

In an active-active setup, distributed polling techniques can be used for inbound Database Adapters to ensure that the same data is not retrieved more than once.

Singleton behavior within an active-passive setup allows a high performance multithreaded inbound Oracle Database Adapter instance running in an active-passive setup, to follow a fan out pattern and invoke multiple composite instances across a cluster.

The Oracle Database Adapter also supports the high availability feature when there is a database failure or restart. The DB adapter picks up again without any message loss.

Distributed Polling

Often in production environments,servers runs in clustered mode i.e more than one managed server running under one cluster.Generally if we don't implement distributed functionality then say for eg we have 5 severs in clustered environment.Then in clustered env in case of polling DB adapter it is quite possible that all 5 nodes try to poll the same record at same time,which will result in 5 concurrent instances with same data.Clearly,we dont want that at all.

When we select Distributed polling while configuring DB adapter, it automatically uses the syntax SELECT FOR UPDATE SKIP LOCKED that means the same row cannot be processed multiple times.

SingleTon Behavior

As metioned under distributed polling,there may be times where it is best to improve performance on a single node, and then optionally do fan-out to multiple nodes in a cluster. Relying on concurrency control features of the database such as locking can be great, but these are often designed more for preserving data integrity than for high performance scalability.

The JCA Binding Component supports active fail over of inbound Adapter Services.To enable this fail over feature for a given inbound adapter endpoint, you must add the singleton JCA service binding property in the composite.xml within the <binding.jca> element and set it to a value of true as shown below:

      <binding.jca config="SchedulerPollDBAdapter_db.jca">
      <property name="singleton">true</property>
      </binding.jca>
 

Only one node of the cluster will poll for the record. If the active node goes down then other node of the cluster will active node and started polling for the record.   

Hope this post is useful to you guys.

Happy Learning
Cheers !!!

Dynamically passing JNDI name to JCA Adapters - SOA 11G

Hi All,

We can pass the JNDI name to any JCA adapter (JMS,DB,File) at runtime as well.All we need to do is configure one property inside the invoke activity that will pass jndi at runtime to the JCA adapter.Just go to the source of your invoke activity where you need to pass the jndi at runtime.

 Then inside the invoke activity add below line:
<bpelx:inputProperty name="jca.jndi" variable="jndiVar"/> in case of BPEL 1.1 and <bpelx:toProperty name="jca.jndi" variable="jndiVar"/> in case of BPEL 2.0 where "jndiVar" is a variable that will contain your jndi name that will be passed at runtime.

Now assign the value to "jndiVar" and place this assign activity before the invoke activity where dynaic jndi needs to be passed.

Deploy and test your composite to verify that jndi is being passed dynamically at runtime.

NOTE: you won't be able to see this property under Invoke --> Properties tab. You have to add it manually by going inside the source of your BPEL process.

Hope it will help you in your implementation.

Happy Learning,
Cheers !!!

Oracle Database Adapter in SOA 11G Tutorial

Hi Everyone,

I'll be demonstrating Oracle Database Adapter in today's tutorial.Oracle JCA adapter for DB enables a BPEL process to communicate with Oracle databases or third party databases through JDBC. The Oracle Database Adapter service is defined within a BPEL process partner link by using the Adapter Configuration Wizard of Oracle BPEL Process Manager (Oracle BPEL PM).

There are number of operations avilable that you can perform with DB adapter namely :

• Call a Stored Procedure or Function :Select this option if you want the service to execute a stored procedure or function.
• 
  Perform an Operation on a Table: Select this option for outbound operations. You can select Insert or Update, Insert Only, Update Only, Delete, Select, or any combination of the six. 
• 
  Poll for New or Changed Records in a Table:  Select this option for an inbound operation (that is, an operation that is associated with a Receive activity). This operation type polls a specified table and returns for processing any new rows that are added. You can also specify the polling frequency.
• Execute Pure SQL: Useful when dealing with arbitrarily complex statements, aggregate queries (result is not row-based), and XMLType columns.

Uscase Scenario: We will be using DB table for polling new records and updating the same table with some field.To execute thiw we will use one inbound DB adapter,polling for new records.One outbound adapter for updating records in a table.BPEL process that will contain our process logic.

Before starting the lab,I would like to explain dirrerent types of files that are being created while configuring DB adapter

1. <serviceName>.wsdl: This is an abstract WSDL, which defines the service end point in terms of the name of the operations and the input and output XML elements.
2. <serviceName>_table.xsd: This contains the XML file schema for these input and output XML elements. Both these files form the interface to the rest of the SOA project.
3. <serviceName>_or-mappings.xml: This is an internal file. It is a TopLink specific file, which is used to describe the mapping between a relational schema and the XML schema. It is used at run time.
4. <serviceName>_db.jca: This contains the internal implementation details of the abstract WSDL. It has two main sections, location and operations. Location is the JNDI name of an adapter instance, that is, eis/DB/SOADemo. Operations describe the action to take against that end point, such as INSERT, UPDATE, SELECT, and POLL. The contents of the db.jca file are wholly determined by choices made while running the Adapter Configuration Wizard.
5. <serviceName>.properties: This is also an internal file. It is created when tables are imported, and information about them is saved. It is used only at design time.

At run time, the location is used to look up the adapter instance which executes the service. Based on the properties in the db.jca file and the linked or-mappings.xml file, <seviceName>.properties file generates the correct SQL to execute, parses the input XML, and builds an output XML file matching the XSD file. To execute the SQL, it obtains a pooled SQL connection from the underlying data source.

Lets start with the tutorial:

Step1: Create one sample table which will be used in our tutorial.I have created "TB_USERS" table and inserted some records in it.Kindly observe the value of "ReadFlag".Its significance will be discussed later on.

Step2: Drag and drop DB adapter from service adapters onto the exposed services lane

Step3: DB Adapter configuration wizard will open up.Click next.

Step4: Give the service name as "PollerDB".

Step5: In the next window give the connection details.I presumed you guys have already created a DB connection.If not,kindly create one and use here.

Step6: Select "Poll for New or Changed Records" as a operation type.It is an inbound operation which polls for new records in a table or whenever existing records are changed.

Step7: In next window,we will import our table from database.Click on import tables.

Step8: Search for your table using Name Filter and Query,and then move it to selected section by clicking on the arrow.

Step9: Our table will be imported and shown in next window.

Step10: DB adapter requires a primary key in a table to uniquely identify a row in atable.Since while creating table we haven't created any primary key,select "FName" as primary key and move next.

Step11: We are working on single table only.No need to define relationships,move next.

Step12: Select the database columns that you want to query from table.I have selected all of them.

Step13: Next window will ask you to choose an operation that will be performed when a record is read.Select Logical Delete option.This operation employs the logical delete polling strategy. This strategy involves updating a special field on each row processed and updating the WHERE clause at run time to filter out processed rows. It mimics logical delete, wherein applications rows are rarely deleted but instead a status column isDeleted is set to true. The status column and the read value must be provided, but the modified WHERE clause and the post-read update are handled automatically by the Oracle Database Adapter.

Step14: If you go back I have created one field "ReadFlag" in the table and given value as "N" for all the records.This field will act as logical delete field.DB adapter will poll for all records having unread value (N in our case) and after processing will update the value of this field to Read Value (P in our case) after successful read.

Step15: In the next window set the values for Polling frequency,DB Rows per transaction.Also check Distributed Polling as distributed polling is used to ensure that the same data is not retrieved more than once.

Step16: Next window no change is required .Click next.

Step17: Next.

Step18: Finish.We have configured our DB adapter for polling records from a table.

Step19: Now,to write records to the same table,drag and drop one more DB adapter this time to external references lane.Give the service name as "WriteDB".

Step20: Same way we did for polling adapter,choose DB connection and click next.

Step21: Under operation type,choose "Update Only" ,since we will update the value of FullName only without modification in other column values.

Step22: Import Table.

Step23: Define Primary Key.

Step24: Since we are going to update the value for "fullname" field only.Choose fullname and click next.

Step25: Next and finish.

Step26: Drag and drop BPEL component onto the components lane and choose Define Interface Later Template and finish.

Step27: Wire both polling adapter and adapter for writing records with BPEL by dragging and dropping wires to BPEL component.

Step28: Drag and drop receive activity and link it with Polling adapter partner link.Configure receive activity and create input variable for this activity.If you dnt know how to work with and configure receive activity ,kindly refer to my initial blogs.In that I have explained in detail about using receive activity.

Step29: Likewise,drag and drop invoke activity to invoke Write DB adapter.In the same way create input variable for invoking DB adapter.

Step30: As of now your BPEL process will look like this.

Step31: Now drag and drop assign activity between receive and invoke activity.We will populate the input variable for invoking DB adapter in this assign activity.Map the first name field from receive input variable to invoke DB adapter input variable.And for full name use expression builder to concatenate the Fname and lname from Input and map it with Fullname field of invoke DB adapter input variable.

Step32: Save all and deploy your composite on EM

Step33: We have set the polling frequency to 10 seconds,so after that interval out interface will poll for new records at regular interval.Click open one composite.

Step34: Observe the input payload that is received using pollign adapter and the invoke activity input variable for invoking the Write DB adapter.

Step35: Now to verify the records are also updated in table,go back to your DB and open up your table.Fullname column is populated with values and also observe the value of read flag "P". Now poller will not poll for any records anymore as no record exists with value "N".It will poll again when some new records are inserted in the database or existing records ReadFlaf value is set back to "N".

Thats it guys.Hope you guys have understood the concept ob DB adpater in Oracle SOA Suite 11G,its use and configuration.In the coming tutorial I'll be posting blogs on using other operations of DB adapter as well.

If you guys have any concerns,coubts or issues ,please feel free to contact me by commenting here or emailing me.I'll get back with the reply at earliest.Also,if you guys need blog specific to topic you want to undertand,I Will be happy to do that as well.Till then take care

Happy Learning,
Cheers