Q) how to rollback ?
To resolve this issue, you need to use a rethrow activity at the end of your catch all block. In this way control will go back to BPEL and it will handle transaction.
bpel.config.transaction property.
bpel.config.transaction=required
The caller's transaction is joined (if there is one) or a new transaction is created (if there is not one)
Invoked messages are processed using the same thread in the same transaction
bpel.config.transaction=requiresNew
A new transaction is always created and an existing transaction (if there is one) is suspended.
Q) Retry and Rollback using DB adapter ?
use case
1.) 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 JNDI 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.
-> if any of transaction fails then in this case we will configure retry parameter in JMS Adapter and we will also define error queue.
-> If any DB Adapter fails then it will retry and its status will be delayed and after all retry it will fails then it message will move into error queue.
-> 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 rolled-back 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.
throw-> rollback
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 roll-backed.
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 roll-backed 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 BPEL, "compensation handlers" provides a flexibility to rollback or reverse the transactions for business or/and system exceptions.
How we can do retry once message roll back to JMS queue ?.
We have “Deliver Failure” tab in JMS queue where we can set properties to do retry after certain intervals.
Jca.retry.count –> example value 3
Jca.retry.interval –> example value 2
Jca.retry.backoff –> example value 2
What parameters we need to set in Delivery Failure tab ?.
We need to set following parameters.
Re-delivery Delay Override : Time interval between retries. It is in milliseconds.
Redelivery Limit: number of retries
Expiration Policy:
Redirect : redirect message to different queue.
Log : log the message.
Discard : discard message and it will be lost.
Error Destination: If you choose “Redirect” then choose the queue to which you want to redirect message.
Q) How we can limit the number of rows per XML message while sending the message from database adapter to consumer ?.
By using “Database Rows per XML Document” property
Q) How we can limit the number of rows fetched using database adapter ?
" We can limit the number of rows fetched using ” Database Rows per Transaction” property.
For example, assume there are 10,000 rows at the start of a polling interval and this field is set to 100.
In standalone mode, a cursor alliteratively reads and processes 100 rows at a time until all 10,000 rows are processed,
dividing the work into 10,000/100=100 sequential transnational units"
Q.) How to Poll Single file from FTP/File location which has multiple files ?
Lets take one example if we have include file wild card as *.txt and there are 2 files available at File/FTP Location. So read operation will read both the file and create two instance and created time will be same for both the instance. To avoid such scenario and read only one file at a time, we need to use below property in jca file.
<property name="MaxRaiseSize" value="1"/>
Q.) I have pushed one message in queue and before consuming my server went down, so what will you do, not to lose data?
This can be achieved my using session acknowledgement.In case your application fails to post message, you can simply rollback transaction which will make the message to reappear in JMS queue. That message will be delivered again.
You should create the session like this:
Session session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
when you try to deliver the message to your third party app:
If it's working you should acknowledge the message.
If it is down you shouldn't acknowledge it, this way the JMS provider will be able to redeliver it,and the message will not be lost. message.acknowledge();
No comments:
Post a Comment