Using QOS(Store and forward,Transaction,Join) in BPMV7.5.1

 I want to share some of  features I observed in BPMv7.5.1 . i.e Usage of  Store and forward QOS and transactions :-

Quality of service (QoS) qualifiers can be specified when wiring components in the assembly editor. These qualifiers define how much management must be provided for a component at run time.
Service Components Architecture (SCA) allows QoS qualifiers, such as transactions, security, and reliable asynchronous invocation, to be applied to components without requiring programming or a change to the services implementation code. WebSphere Integration Developer gives you the tools to quickly and easily compose an integrated business application that wires together components in mediation modules that can be deployed to the WebSphere Enterprise Service Bus or to WebSphere Process Server. When wiring the components, you can specify qualifiers to provide extended quality of service to the components, as well as to the clients accessing the service. Sometimes, implementations require that qualifiers are set in particular ways; Here is the  explanation of the join transaction qualifier.

Scenario:-
 This scenario aims to know about how to use Transaction and  Join transaction qualifiers.

For this I took two JDBC outbound adapters which will store Customer details into two different services for example CRM and ERP tables.But  if one of the service is down another transaction has to be roll back.The record must be inserted into two tables.
For this I set  Transaction qualifier  as Global for implementation of mediation flow component and set join transaction as TRUE  for target Interface (CRM and ERP services interfaces)

STORE and Forward QOS:-

The core idea of the Store and forward is, when there is a runtime exception in the request flow, the exception will be propagated till the first asynchronous point. If Store and forward is configured on the component near the asynchronous point, the subsequent requests are stored at that asynchronous point instead of continuously generating failed events. When the runtime exceptions are resolved, the stored events can be replayed using the Store and Forward widget. The asynchronous points map to Service Control Points

 

In the previous releases of WebSphere Process Server, when processing asynchronous requests, failed events will be generated if there are any runtime errors. The recovery system keeps generating the failed events as the requests flow into faulty or unavailable service that is throwing the runtime errors. Once the runtime errors are resolved, administrator will have to resubmit the failed events using either admin console or scripts that make use of FEM API. Generating failed events as well as resubmitting them later is a resource intensive operation. In Process Server V7.0, the problem is elegantly addressed by the introduction of Store and forward feature.