Archive for July, 2014

SOA 12c – Durable Subscribers with Weblogic JMS

Business Events are used to notify the interested parties (subscribers) about an occurrence of activity which is of important to them. On raising the business events, the subscribers would consume them and process it based on their business flows. All these things would happen in a highly loose coupled manner and business events producers may not be aware of the subscribers. So when designing an application based on business events one of the aspects requires attention is, Will there be any loss of event? This is very important as subscribers are not in a position to request providers to raise event again, even if they do its going to be a duplicate event (occurrence) for other subscribers. Technically speaking, the loss of event can be translated into any of these following scenarios:

  • Subscriber received the business event but faulted during processing.
  • Subscriber is unavailable when the business event is published.
  • The hosted server itself is down when the business event is published.

Scenario 1: For this scenario, EDN provides different Consistency levels and Auto Retry feature which you can use. The post discusses this behavior and also highlights major differences between 11g and 12c SOA Suite releases. In other cases where this feature can’t be leveraged, developer had to take care of manually storing event information and retrieving later on processing failure.

Scenario 2: Typically this scenario may not arise in production environments but there is a possibility when event producer and subscribers are deployed on different managed servers and maintenance cycles for both are different. EDN 11g does not support for this case and it mandates Subscribers to be available when event is published. But in 12c, this scenario is handled using Durable Subscribers which we see shortly.

Scenario 3: This scenario also automatically handled by EDN as it queues the events. And once the server is up, the events in queue will get delivered to their respective subscribers.

In this post, we will see how Durable property works for Business Events. We will use the same 3 composites used in previous post, where we have 3 subscribers for CreateOrder and 1 subscriber for UpdateOrder business events respectively. From here onwards, we will use subscribers or composites terminology interchangeably.

  • Deployment of composites with Durable property to Yes.
  • Any of the Composites subscribed to business events are shutdown.
  • Redeployment of composites with same revision.
  • Redeployment of composites with different default revision.
  • Server shutdown and restart when a few business events are pending to be delivered.
  • Un-deployment of the composites.
  • Redeployment of composites after modifying Durable property to No.

So let’s us get started!!!

To start with let’s have a quick look at Events and Subscriptions used for demonstration. To view these navigate to soa-infra->Business Events.


Durable property to Yes:

Set Durable property to Yes for all subscribers and do deploy.

When Durable property is set to Yes, EDN leverages Weblogic JMS durable subscriptions and creates Durable subscribers for each such subscription. Durable subscriptions mean that Weblogic server will store the messages in persistent store until it gets delivered to subscriber. This can be observed in Weblogic Admin Console by navigating to Services->Messaging->JMS Modules->SOAJMSModule->EDNTopic->Monitoring->Durable Subscribers.

You can observe 4 Durable subscribers in the above screen where 3 of them for CreateOrder and 1 for UpdateOrder business events respectively. You can find out JNDI of JMS Topic used for an event in default JMS Mapping by navigating to Business Events screen from soa-infra and you can also modify this default JMS Mapping for business events.

Subscribers Down:

Shutdown EDNSubscribeSync composite and observe durable subscribers.

In above screenshot, you can observe that corresponding durable subscriber is inactive (observe value for Active column).

Now raise CreateOrder business event. Go to flow trace and observe that event is not delivered to this composite.

Also, since it’s a durable subscriber we would ideally expect this message to be stored by Weblogic server. Now go to Durable Subscribers and you can observe a pending message to be delivered.

Click Show Messages to see all pending messages.


Click on message to see details as shown below.


Now shutdown EDNSubscribeAsync composite and observe corresponding durable subscribers.

Raise another CreateOrder business event and observe pending messages.


Bring up EDNSubscribeAsync composite and you will see a new composite instance gets generated as the pending event is delivered by EDN.


Also observe that corresponding Durable Subscribers are active.

Now bring up EDNSubscribe composite and observe 2 new composite instances are generated for both of the pending messages.

Also observe that all Durable Subscribers are up.

Redeployment of Composites:

There will be no change in Durable subscribers, when composites are redeployed with the same revision or different revision as the default.

Server shutdown:

Shutdown EDNSubscribeSync and EDNSubscribeASync composites and raise 2 CreateOrder and 1 UpdateOrder business events. As shown below, these will be shown as pending for corresponding Durable Subscribers.


Now Shutdown SOA server and restart it. Navigate to EDNTopic and observe that messages are not lost and survived the server shutdown as expected. Bring up the composites and you would observe new instances get created as shown below.


In the above screenshot, the first 2 instances are created for CreateOrder and 3rd instance is created for UpdateOrder business events respectively.

Un-deployment of Composites:

Now Un-deploy EDNSubscribeSync composite. Navigate to Durable Subscribers and observe that only 3 subscribers exist.

Un-deploy EDNSubscribeASync composite too and observe that Durable Subscribers is reduced to 1 as shown below.

Now un-deploy all the composites and observe that all Durable Subscribers are deleted automatically.

Durable property to No

When you set Durable property to No and deploy the composites, you will not see any of the Durable Subscribers for EDNTopic as shown below.


Other Observations:

  • Durable subscribers are taking a little time to become active when server is restarted and shutdown composites are started up (scenario described above in Server shutdown section).
  • Client IDs for Durable subscribers are getting created differently based on event subscription consistency level. Observed that Client ID is set as edn_wljms_xa_client for OneandOnlyOne consistency level. For Guaranteed consistency level, it’s edn_wljms_localtxn_client. This denotes Global Transaction used for OneandOnlyOne and Local Transaction used for Guaranteed consistency levels respectively.

  • 12c documentation for EDN mentions, The EDN does not support durable subscriptions (whether they are backed by native AQ or Oracle WebLogic Server JMS). The subscribing service component must be running to receive events, though we are able to achieve this using Durable Subscribers. We see the same mention in 11g documentation too.

All of the above observations are nicely summarized over here, see table 33-2.


SOA 12c – Business Events and Consistency Levels

I have chosen Business Events as first feature to explore in recent release of SOA Suite12c. Also, I want to cross verify my earlier observations in 11g.

The initial observation is, now the new SOA project will have the folders for different artifacts and the folder Events is for edl files.


Secondly, 12c   supports One and Only one and  Guaranteed consistency only and no longer supports immediate. Also new property Durable is added to event subscriptions.


Even migration of 11g composites to 12c is resulting into error, if composite uses immediate consistency level. We have to manually make this change by choosing either of the 2 supported consistency levels.


But in EM Console, we are still able to see immediate consistency level in the search region. You can navigate to this UI by selecting soa-infra –> Business Events.


Thirdly, in 11g  EDN uses DB AQ 11g by default for publish and subscribe model of business events. This can be confirmed by verifying value of MBean property EdnJmsMode.  False value denotes EDN using DB and True value denotes EDN using Weblogic JMS. You can verify by navigating to config –> SoaInfraConfig –> soa-infra in Application Defined MBeans.


But in 12c, EDN uses Weblogic JMS by default.  This can be confirmed by verifying value of MBean property JmsType .  WLJMS value denotes EDN  using Weblogic JMS and  AQJMS value denotes EDN using AQ DB . You can verify by navigating to –> EDNConfig –> edn in Application Defined MBeans.


Another quick observation is, in 12c there is no Faults tab shown in Business Events page. You can select soa-infra –> Business Events to bring up this page. In 12c, we can do manual Retry and Abort of Business Events in Flow Instances screen itself which we will observe later in this post.


Now let us start exploring functionality of Business Events from perspective of consistency levels like we did it earlier. As per 12c documentation, one of the major differences is auto retry is supported by Guaranteed consistency level too.

Use case:

We use mediator to raise  2 business events CreateOrder and UpdateOrder. We have following subscribers for CreateOrder event:

  • Mediator routing request to Async BPEL (EDNSubscribeToBPEL process in composite EDNSubscribe).
  • Mediator routing request to Sync BPEL (EDN2BPEL process in composite EDNSubscribe2 ).
  • Asynchronous BPEL process (SubscribeToEventBPELProcess  process in composite EDNConsistencyCheck).

And we have following subscribers for UpdateOrder event:

  • A mediator routing the request to ASync BPEL (in different composite)

Test EDNConsistencyCheck from EM console to raise these business events. The sample composites are available here.

Earlier to simulate Fault condition, we used <onReply/> tag  in mediator while routing to Asynchronous BPEL as shown below.


<case executionType=”direct”




<part name=”$out.payload”

function=”xslt(xsl/CreateOrder_To_process.xsl, $in.payload)”/>


<invoke reference=”Order2BPELProcess1.order2bpelprocess1_client”







The behavior is quite different in 12c when same approach has been used to simulate Fault condition. This is resulting into non-recoverable fault in all the times. Though the same behavior is expected in 11g, in actual this fault was considered as recoverable and also auto-retry is made. So here we will simulate Fault condition by throwing Remote Fault manually.



Navigate to soa-infra-> Administration –> System MBean Browser -> Application Defined MBeans -> -> EDN Config –> edn in EM Console. Here, we can set EDN configuration including properties NumberOfRetrys and QueueWaitTime.

Though 11g has QueueWaitTime property, it was not considered as the retry interval. But in 12c, this property is being honored and we will observe the same later in this post.




Verify Events and Subscriptions in Business Events. You can observe that there are 2 business events and 4 subscriptions The subscriptions page also shows you consistency level for each subscription.



Consistency Level – Guaranteed:

Make sure that all event subscriptions consistency level is set to Guaranteed and raise CreateOrder business event.

We can observe a lot of visual improvements in this Flow Trace screen. The composite instances are clearly marked as ‘Recovery Required’ and ‘Auto-retrying’ as applicable. As expected, the Asynchronous BPELs went into Auto Recovery and   Event auto retry is happening for Synchronous BPEL process. Also note that all  subscribers have received the business event raised though some faulted subscribers exist.


By clicking on the ‘Recovery Required’ link in Faults tab, we can observe that BPEL fault is pending for Invoke message recovery as shown below.

bpel recovery

You can also observe that Synchronous BPEL is marked as Recovery Required after retry is done for configurable number of times. Also the property value of QueueWaitTime is honored as the event Retry Interval.


The Faults tab is shown as below along with number of retry attempts.


By clicking on the ‘Recovery Required’ link in Faults tab for this flow instance, we can observe that fault is pending for EDN recovery as shown below. From this popup, we can again do Retry manually or abort the flow using Retry and Abort buttons respectively.


Selecting a fault from Faults tab will highlight the corresponding flow instances along with retry attempts (if any).


We can also do manual Retry or Abort from Flow Instances page. Selecting a Flow ID row will enable Abort Selected icon as shown below (if applicable).


And same Faults tab shown earlier is also available in Flow Instances page as shown below.


Now set bpel.config.oneWayDeliveryPolicy to sync for all the Asynchronous BPELs. Raise CreateOrder event and observe that all the instances are auto-retrying as the BPELs would be invoked in Synchronous manner.


Now set bpel.config.oneWayDeliveryPolicy to async.cache for all the Asynchronous BPELs. Raise CreateOrder event and observe that auto-retrying is only happening for Synchronous BPEL.


Now reset bpel.config.oneWayDeliveryPolicy to async.persist and bpel. config.transaction to requiresNew for Asynchronous and Synchronous BPEL respectively. Raise CreateOrder event and observe auto-retry is happening for Synchronous BPEL only.

Now set bpel.config.transaction  to notSupported for the Synchronous BPEL.  Raise CreateOrder event and again observe auto-retry is happening only for Synchronous BPEL.

Consistency Level – One and Only One:

When  above scenarios are tried using One and Only One consistency level, I observed the same behavior as Guaranteed. As per 12c documentation, the difference lies in type of transaction used (Local vs Global). Guaranteed uses Local where as One and Only one uses Global Transaction for De-queue and Delivery of Business Events.


  • When Mediator routes request to Sync BPEL that throws fault and not caught, then event auto retry is happening irrespective of consistency level and value of bpel.config.transaction.
  • When Mediator routes request to ASync BPEL that throws fault and not caught, then event auto retry is not happening irrespective of consistency level with async.persist as value for bpel.config. oneWayDeliveryPolicy.  This makes sense as the transaction can’t be  propagated and value of bpel.config.transaction is irrelevant.
  • When Mediator routes request to ASync BPEL that throws fault and not caught, then event auto retry is happening irrespective of consistency level with sync as value for bpel.config.oneWayDeliveryPolicy. This makes sense as BPEL is invoked in Synchronous manner. Also the same behavior is observed, when an Async BPEL is directly subscribed to business event.
  • When Mediator routes request to ASync BPEL that throws fault and not caught, then event auto retry is not happening irrespective of consistency level with async.cache as value for bpel.config. oneWayDeliveryPolicy.

We will explore the Durable property of Event Subscriptions in next blog.

SOA Suite 12c Installation

By this time, you might already know that SOA Suite12c released last week. The twitter world is abuzz with the most awaited SOA Suite release and gave a welcome in great fashion. I too was equally excited to get a glimpse of it and try out some hands-on the same. In this post, we will quickly go through the SOA Suite 12c installation.

We can say that installation is quite streamlined and made simple with single installer that includes JDeveloper, JDev SOA Extension, RCU, Standalone WLS and Service Bus (formerly Oracle Service Bus). The installer can be downloaded from here.

I tried this installation in Windows 7, 64-bit machine. Make sure you installed JDK and JAVA_HOME environment variable is set before  proceeding with the  installation.

Unzip the installer and start the installation as shown below.


This brings up the welcome screen.


Click Next and set Oracle Home to your desired location.


Click Next to finish Prerequisites check.


Click Next. Here you can review the installation summary and click Install.



Click Finish to complete the installation.


RCU Installation

You need to create the required schemas using RCU before proceeding with domain creation. As I mentioned earlier, no separate installer is required for RCU and comes by default with SOA Suite.

Navigate to $MW_HOME/oracle_common/bin. Locate file rcu.bat and select ‘Run as Administrator’ on right click to bring up the following welcome screen. Make sure that you installed a supported database before proceeding.


Click Next and choose default options for creating the repository.


Click Next and enter your database information with sys credentials.


Click on Next and you can Ignore the warning related to Oracle XE database as you are going to use this domain for development purpose.


RCU will perform some prerequisite checks.


Click OK to bring up following screen. Enter prefix as you desired and select SOA Infrastructure schema. This will automatically select all other dependent schemas as shown.


Click Next and enter the password for all schemas.


Click Next and proceed to next screen by accepting the defaults.





Click on Close to finish RCU installation.

Domain Creation

Navigate to $MW_HOME/oracle_common/common/bin and locate the file config.cmd. Right click and select ‘Run as Administrator’ to bring up the following screen. Enter your desired domain name.


Click Next and select the products that your domain want to support.


Click Next and proceed further by accepting the defaults.


Click Next and enter the credentials.


Click Next and choose Domain Mode. You may want to retain Development as Domain Mode. You can accept defaults for JDK or you can select any other location.


Click Next. Enter STB schema information as shown below and click Get RCU Configuration.


Once schema retrieving is successfully done, click Next.


Click Next and verify that connection test is successful for all the schemas. If not, you can go back to previous screen and modify individual schema connection information.


Once testing is done, Click Next and accept the defaults.


Click Next and in this screen you verify the domain configuration the wizard is going to create.


Click Create to start the domain creation.


Once the the domain creation is successful, Click Next.


Remember Domain Location and Admin Server URL and click Finish to exit the configuration wizard.

Start the Admin and Managed Servers by executing startWebLogic.cmd, startManagedWeblogic.cmd respectively from bin folder of Domain Location (shown above).


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 379 other subscribers

Enter your email address to follow this blog and receive notifications of new posts by email.

%d bloggers like this: