Advertisements

Archive for the 'EDN' Category

SOA 12c–EDN with Service Bus

In this post, I just want to present an idea on how to make Service Bus work with EDN in SOA Suite 12c. For demonstration purpose, I will consider Durable Subscriber functionality introduced in 12c.

You can download the SOA and Service Bus projects here and here.

My setup includes 2 business events Create Order and Update Order and have the following durable subscribers created because of SOA Composites. Refer to these articles for more information on EDN. Note that, Client ID is different as mentioned below based on the consistency level used for the event subscription.

       For Guaranteed   -> edn_wljsm_localtx_client

       For OneandOnlyOne   -> edn_wljsm_xa_client

Main idea is to create a durable subscriber for our Proxy Service similar to the ones shown below. So note down Client ID and Message Selector shown below and use it in our Proxy Service configuration. Here we are subscribing our Proxy Service to Create Order business event.

soasubscr1

soasubscrmsgslet

Now create Proxy Service and set Endpoint URI in Transport tab as shown below. EDN uses EDN Topic for storing and delivering the EDN messages to subscribers.

topicps1

Give the Message Selector and Client ID noted in previous step in Transport Details tab as shown below and select Durable Subscription option.

topicps2

Deploy you Service Bus project and observe that another durable subscriber has been created for Proxy Service as shown below.

osbdura1

To make sure that things are working as expected, push the message read by Proxy service to other JMS queue. Here I created queue named CustomJmsQ and following screenshot shows no messages are pushed yet.

customqmsg

Raise the Create Order business event from SOA Composite. And you can observe that message payload have been inserted into JMS queue.

custommsgaftrtest

evntpayloadjms

Shut down OSB managed server and observe status of  durable subscriber. As shown below the Active status is shown as false indicating that Proxy service is not longer ready to accept messages.

osbinactive

Again raise the Create Order business event. And now you can observe that message is shown in Current Count means not yet delivered to Proxy Service.

pendingmsg

pendingmsg1

Now restart your OSB managed server navigate to CustomJmsQ. Now you can observe 2 messages in this queue including the latest one as shown below.

osbsrvrrestart1

osbsrvrrestart2

Now Un-deploy Service Bus project. And you can observe that corresponding durable subscriber is deleted too.

Remember the following:

  • EDN bus comes with SOA server, so you may not be able to use EDN in OSB only deployments.
  • Since there is no native support for business events in service bus, we will not be able to set any consistency levels and even the retry would not happen similar to SOA composites.
  • Here we directly gave Endpoint URI of Proxy Service to point to EDNTopic residing different server. Ideally, you may have to go for foreign server.
  • Finally, I have not verified the same with client edn_wlsjms_xa_client. Please let me know in comments when you try.
Advertisements

SOA 12c – EDN – Mapping to Custom Topic with AQJMS

We have seen using Custom Topic with WeblogicJMS here and in this post we will see the same using AQJMS.

Creating a new Topic

Run the following script to create new AQ Topic.

define edn_user=dev12c_soainfra
define topic=EDN_AQJMS_CUST_TOPIC
define topic_table=EDN_AQJMS_CUST_TOPIC_TBL

 
begin
  DBMS_AQADM.stop_queue(queue_name => ‘&edn_user..&topic’);
  DBMS_AQADM.drop_queue(queue_name => ‘&edn_user..&topic’);
  DBMS_AQADM.drop_queue_table(queue_table => ‘&edn_user..&topic_table’);
end;
/
begin
  dbms_aqadm.create_queue_table(queue_table => ‘&edn_user..&topic_table’,
                                queue_payload_type => ‘SYS.AQ$_JMS_MESSAGE’,
                                multiple_consumers => true);
  dbms_aqadm.create_queue(queue_name => ‘&edn_user..&topic’,
                          queue_table => ‘&edn_user..&topic_table’,
                          max_retries => 256);
  dbms_aqadm.start_queue(queue_name        =>       ‘&edn_user..&topic’);
end;
/
commit;

Once script is run successfully, verify that AQ Topic and corresponding Queue Table is created as shown below.

aqcusttopic

You can also observe other tables created when you create a new topic.

aqtopictables

Now create a foreign destination in  foreign server EDNAQjmsForeignServer. So navigate to Services –> Messaging –> JMS Modules –> SoaJMSModule –> EDNAQjmsForeignServer –> Configuration –> Destinations in Weblogic Administration console and create as shown below:

aqcust1

Enter a meaningful name and Local JNDI for the topic. And the remote JNDI should be of the format Topics/<<AQ Topic Name>> as shown below.

aqcust2

Click OK and observe the new foreign destination created as shown below.

aqcust3

Modifying Business Event mapping

Navigate to SOA –> soa-infra –> SOA Infrastructure –> Business Events in EM and click JMS Mapping as shown below.

aqmapping

Modify JMS Topic Name to use newly created Topic and click Apply. Typically, you don’t have to create new Connection Factories. Restart the affected composites so that modified JMS mapping will be effective.

For demonstration purpose, here we are modifying the JMS Mapping for CreateOrder Business Event.

aqmodmapping

Raise CreateOrder Business Event and observe log (with OneandOnlyOne consistency level).

[2015-01-12T20:16:20.544+05:30] [soa_server1] [TRACE] [] [oracle.integration.platform.blocks.event.jms2.EdnBus12c] [tid: [ACTIVE].ExecuteThread: ’21’ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 5c9ca2bf-9639-4e37-a951-cb3b9fb7c06c-00000123,0:2] [APP: soa-infra] [J2EE_APP.name: soa-infra] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: RaiseEvent_ep] [WEBSERVICE_PORT.name: execute_pt] [oracle.soa.tracking.FlowId: 20002] [oracle.soa.tracking.InstanceId: 20004] [oracle.soa.tracking.SCAEntityId: 29] [composite_name: EDNConsistencyCheck] [FlowId: 0000KfUb1lY3z0WjLxyGOA1Kgxik000002] [SRC_CLASS: oracle.tip.adapter.fw.log.LogManagerImpl] [SRC_METHOD: log] eis/aqjms/EDNxaDurableTopic EdnBus12c file://wsdl/eis/aqjms/EDNxaDurableTopic-OUTBOUND.wsdl [ eis/aqjms/EDNxaDurableTopic-OUTBOUND::enqueue(part,part) ] – Starting JCA LocalTransaction
[2015-01-12T20:16:20.545+05:30] [soa_server1] [TRACE] [] [oracle.integration.platform.blocks.event.jms2.EdnBus12c] [tid: [ACTIVE].ExecuteThread: ’21’ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 5c9ca2bf-9639-4e37-a951-cb3b9fb7c06c-00000123,0:2] [APP: soa-infra] [J2EE_APP.name: soa-infra] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: RaiseEvent_ep] [WEBSERVICE_PORT.name: execute_pt] [oracle.soa.tracking.FlowId: 20002] [oracle.soa.tracking.InstanceId: 20004] [oracle.soa.tracking.SCAEntityId: 29] [composite_name: EDNConsistencyCheck] [FlowId: 0000KfUb1lY3z0WjLxyGOA1Kgxik000002] [SRC_CLASS: oracle.tip.adapter.fw.log.LogManagerImpl] [SRC_METHOD: log] eis/aqjms/EDNxaDurableTopic EdnBus12c file://wsdl/eis/aqjms/EDNxaDurableTopic-OUTBOUND.wsdl [ eis/aqjms/EDNxaDurableTopic-OUTBOUND::enqueue(part,part) ] – Invoking JCA Outbound Interaction
[2015-01-12T20:16:21.913+05:30] [soa_server1] [NOTIFICATION] [] [oracle.soa.adapter.jms.outbound] [tid: [ACTIVE].ExecuteThread: ’21’ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 5c9ca2bf-9639-4e37-a951-cb3b9fb7c06c-00000123,0:2] [APP: soa-infra] [J2EE_APP.name: soa-infra] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: RaiseEvent_ep] [WEBSERVICE_PORT.name: execute_pt] [oracle.soa.tracking.FlowId: 20002] [oracle.soa.tracking.InstanceId: 20004] [oracle.soa.tracking.SCAEntityId: 29] [composite_name: EDNConsistencyCheck] [FlowId: 0000KfUb1lY3z0WjLxyGOA1Kgxik000002] JMSMessageProducer_produce: Successfully produced message with ID ID:11F4B4F68C6A4B93B6BAB1305CA03C72 to destination jms/fabric/EDNAQjmsCustTopic
[2015-01-12T20:16:21.913+05:30] [soa_server1] [TRACE] [] [oracle.integration.platform.blocks.event.jms2.EdnBus12c] [tid: [ACTIVE].ExecuteThread: ’21’ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 5c9ca2bf-9639-4e37-a951-cb3b9fb7c06c-00000123,0:2] [APP: soa-infra] [J2EE_APP.name: soa-infra] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: RaiseEvent_ep] [WEBSERVICE_PORT.name: execute_pt] [oracle.soa.tracking.FlowId: 20002] [oracle.soa.tracking.InstanceId: 20004] [oracle.soa.tracking.SCAEntityId: 29] [composite_name: EDNConsistencyCheck] [FlowId: 0000KfUb1lY3z0WjLxyGOA1Kgxik000002] [SRC_CLASS: oracle.tip.adapter.fw.log.LogManagerImpl] [SRC_METHOD: log] eis/aqjms/EDNxaDurableTopic EdnBus12c file://wsdl/eis/aqjms/EDNxaDurableTopic-OUTBOUND.wsdl [ eis/aqjms/EDNxaDurableTopic-OUTBOUND::enqueue(part,part) ] – Committing JCA LocalTransaction

In above log, you can clearly observe that Business Event is published in our topic jms/fabric/EDNAQjmsCustTopic and default connection factory is used. You can refer to my previous post on how to generate this EDN log, if required.

You can also try with Guaranteed consistency level and can observe that the connection factory eis/aqjms/EDNLocalTxDurableTopic has been used along with new Topic we created.

SOA 12c – EDN Articles

Following bugs related to EDN have been fixed in the patch bundle (12.1.3.0.1). For the complete list of fixed bugs, one can refer to README of the patch bundle 19707784.

18860738: BACKLOG EVENTS LOST WHEN NEW REVISION OF EDN SUBSCRIBERS DEPLOYED
18632135: UPGRADE OF EDN-JMS BACKLOG EVENTS FROM 11G TO 12C
18710784: INCORRECT STATE FOR EDN SUBSCRIBER AFTER UPGRADE EDNJMSMODE=TRUE

SOA 12c – EDN – Durable Subscribers with AQ JMS

In this post, we will see how Durable Subscribers work when using AQJMS. It’s advised to have a look at previous post to understand on how to switch to AQJMS from default Weblogic JMS.

We will use the following Business Events for demonstration purpose where CreateOrder event has 3 subscriptions and UpdateOrder has 1 subscription and Durable property is set to Yes.

duraaq1

From JMS Mapping shown below, you can find out the JNDI of JMS topic which is jms/fabric/EDNAQjmsTopic.

duraaq2

In WLS Admin Console, navigate to Services –> Messaging –> JMS Modules –> SOAJMSModule –> EDNAQjmsForeignServer –> Destinations and observe Remote JNDI of corresponding JNDI of JMS topic observed in above step. From this, actual AQ topic used by EDN is EDN_AQJMS_TOPIC.

duraaq3

You can observe AQ Topic and corresponding DB table used by EDN to store messages as shown below. Remember to connect to DB using SOAINFRA schema credentials.

duraaqtable

In addition to queue table, following are other DB tables used by EDN and will be created automatically as part of SOAINRA schema creation or when you create any custom AQ topic.

duraaqtable1

Following information is an extract from this documentation and presenting for your quick reference here.

Table name

Description

AQ$_queue_table_name_D Table for storing information about propagations and apply processes that are eligible for processing each event.
AQ$_queue_table_name_E Default exception queue associated with the queue table.
AQ$_queue_table_name_H An index organized table (IOT) for storing dequeue history data.
AQ$_queue_table_name_I An index-organized table (IOT) in the case of multiple consumer queues for dequeue operations.
AQ$_queue_table_name_L Dequeue log table, used for storing message identifiers of committed dequeue operations on the queue.
AQ$_queue_table_name_P Table for storing the captured events that spill from memory.
AQ$_queue_table_name_S A table for storing information about subscribers.
AQ$_queue_table_name_T An index for the queue monitor operations

We will discuss about the important tables below from this list.

AQ$_EDN_AQJMS_TOPIC_TABLE_S

You can query this table to find the Durable subscribers as shown below.

durasubscr

You can also get information about these subscribers in following way.

subscr1

Click on Subscribers. You can observe Consumer Name, Delivery Mode and whether it’s Durable subscriber or not.

subscr

subscr2

EDN_AQJMS_TOPIC_TABLE

This is queue table associated with our AQ and you can observe the messages in this table when you raise a business event. You can also get MSGID from EDN log (refer to this post on how to generate EDN logs).

Following screenshot shows the message created when CreateOrder event is raised.

duramsg1

You can also see event payload  in USER_DATA column as shown below.

duramsg2

AQ$_EDN_AQJMS_TOPIC_TABLE_H

This table contains de-queue history for each of subscribers of an event. The following screenshot shows messages for 3 subscribers of CreateOrder event (observe subscriber# column below).

duramsg3

AQ$_EDN_AQJMS_TOPIC_TABLE_I

This table contains messages meant for de-queue operations for each of subscribers of an event. This we can observe clearly when any of the durable subscribers are down, which we will see later.

It has been observed that the messages are being purged automatically from the above tables, once all subscribers have received the event and successfully processed it.

If the business events are staged in buffer for a period of time without being de-queued, or if there is no enough space in memory to hold all of these captured events, then the tables AQ$_EDN_AQJMS_TOPIC_TABLE_P and AQ$_EDN_AQJMS_TOPIC_TABLE_D are used to store these spilled events.

Now we will observe how these subscribers get affected in the following scenarios:

  • 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. 
  • Un-deployment of the composites.
  • Redeployment of composites after modifying Durable property to No.

Durable property to Yes:

We have already seen above that subscribers have been created as expected where Subscriber/Consumer name has corresponding Business Event name.

Subscribers Down:

Shutdown one of the composites subscribing to CreateOrder business event. In this case you can observe the records in all of the above tables that we discussed as all subscribers have not processed the event.

durasubscr

EDN_AQJMS_TOPIC_TABLE

subscrdown

AQ$_EDN_AQJMS_TOPIC_TABLE_I

This table shows only one message corresponding to inactive subscriber.

subscrdown1

AQ$_EDN_AQJMS_TOPIC_TABLE_H

This table clearly shows that 2 of the messages related to active subscribers have been de-queued along with de-queue time and one more message is yet to be de=queued as the subscriber is down.

subscrdown2

AQ$_EDN_AQJMS_TOPIC_TABLE_F

This table also shows only one message corresponding to inactive subscriber along with other information present in EDN_AQJMS_TOPIC_TABLE.

subscrdown3

Now bring up the composite and query all of the above tables and you will find them empty as the message is delivered as expected.

Redeployment of Composites:

Redeployment of some composites with same revision resulted into recreation of Durable Subscribers and older ones are either completely deleted or just updated with Deletion Time but Subscriber/ Consumer name is never changed as shown below. Also Subscriber Type is set to 2 denoting UNDELIVERABLE.

subscr3

Same is the case when composites are redeployed with different revision but now Subscriber/Consumer name is also modified as shown below.

subscr4

Un-deployment of Composites:

Un-deployment of composites also resulted into either deletion of entries or Deletion Time and Subscriber Type is updated as described in previous scenario. But could not conclude on why 2 different behaviors exist.

Durable property to No:

Subscribers have been created as expected but Subscriber/Consumer name are set differently as shown below.

durableno

durableno1

Let us bring down the composite down once again to see how it’s affected the subscriber. From the below screenshot, you can observe that corresponding subscribers are marked with Deletion time and Subscriber type is set to 2 means undeliverable.

durableno3

Other Observations:

  • Subscriber Type is 193 in table aq$_edn_aqjms_topic_table_S when subscriber is active and value 2 denotes undeliverable.
  • The message assumes the following states during it’s lifecycle and the column state in table edn_aqjms_topic_table denotes this. These value are derived from definition of DB view AQ$EDN_AQJMS_TOPIC_TABLE.

State

Meaning

0 Ready
1 Wait
2 Processed
3 Expired
8 Deferred
10 Buffered Expired
  • When any one of the composites throws an exception (considering the BPEL invocation is Sync), retry is happening thrice as expected and retry count is marked in aq$_edn_aqjms_topic_table_H as shown below.

        retry

        retry1

Note: Could not conclude the purpose of tables AQ$_EDN_AQJMS_TOPIC_TABLE_F and AQ$_EDN_AQJMS_TOPIC_TABLE_G and AQ$_EDN_AQJMS_TOPIC_TABLE_T . If anybody is aware of the functionality, one can let me know through your comments. And the table AQ$_EDN_AQJMS_TOPIC_TABLE_L showing log only during events delivery and is getting cleared once all events have been processed successfully.

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.

soaproj

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.

edn1

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.

edn2

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.

edn3

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 oracle.as.soainfra. config –> SoaInfraConfig –> soa-infra in Application Defined MBeans.

edn5

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 oracle.as.soainfra.config –> EDNConfig –> edn in Application Defined MBeans.

edn4

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.

soainfra

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.

<switch>

<case executionType=”direct”

name=”Order2BPELProcess1.order2bpelprocess1_client.process”>

<action>

<transform>

<part name=”$out.payload”

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

</transform>

<invoke reference=”Order2BPELProcess1.order2bpelprocess1_client”

operation=”process”>

<onReply/>

</invoke>

</action>

</case>

</switch>

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.

edn6

Configuration:

Navigate to soa-infra-> Administration –> System MBean Browser -> Application Defined MBeans -> oracle.as.soainfra.config -> 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.

edn4

Demonstration:

 

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.

events

subscr

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.

edn9

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.

eventrecovery

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

attempt

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.

ednrecover

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

edn11

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).

abort

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

fault2

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.

asyncassync

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.

asynccache

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.

Summary:

  • 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.

Links

I will use this post as a repository of useful links and blogs which I can expect to grow exponentially over the time, so will try to include links on more generalized or important topics of much interest.

– SOA Suite PS6 New Features

Generic:

– SOA SDLC by Mark Nelson

ADF

– Understanding View Accessors

Adapters

-12c JMS Adapter Scalability

Weblogic

Cluster Messaging Protocols

Adapters

– Multiple SOA Suite Revisions with DB Adapter

Mediator

– Message Sequencing Patterns (white paper)

– Parallel Routing Rules

BPEL

BPEL Mania

List of All Instance States

– Transaction Boundaries and Rollbacks

Fault Handling

OTN Article Series

Fault Handling in SOA Suite – Advanced Concepts

Business Rules

Self-Study Course

EDN

EDN Debugging

– Fanning out Events

– SOA 12c – EDN Articles

Continuous Integration

Deploy SOA Composites using Hudson

OSB

Best Practices

– 11g Hands-on Tutorial

– WLST Fundamentals in context of OSB

– Working with Oracle Security Token Service

– One-Way Authentication Policies in OSB

– Coherence Integration

– Caching Strategies for OSB 11g

Out-of-Process Coherence Servers

– 12c Hands-on Tutorial

12c – Series of Articles

– 12c – REST enabling SOA

OWSM

Oracle Blog

BPM

    BPM vs BPEL

     Case Management

Quick Series

Case Activities, Part-I

SOA Governance

 – SOA Governance Through Enterprise Architecture

Fusion Applications

 Fusion Applications Life Cycle

 – Request Flow in Fusion Applications

 – Asynchronous Web Services in Fusion Applications

 – Oracle Fusion DOO – Integrating External Systems using EIL

Customizations

   – Translating Customizations

Business Events in Action

The purpose of this blog post is to explore subscription consistency levels. Subscriber can use any of the following consistency levels while subscribing to business events raised by publisher:

    • immediate
    • guaranteed
    • one and only one

Following is an extract from documentation explaining the functionality of each consistency level:

    • immediate – Events are delivered to the subscriber in the same global transaction and same thread as the publisher. The publish call does not return until all immediate subscribers have completed processing. If any subscribers throw an exception, no additional subscribers are invoked and an exception is thrown to publisher. The transaction is rolled back in case of any error during immediate processing
    • guaranteed – Events are delivered to the subscriber asynchronously without a global transaction. The subscriber can choose to create its own local transaction for processing, but it is committed independently of the rest of event processing. In addition, EDN does not attempt to resend an event (regardless of the backing store being AQ or JMS). If one or more subscribers fail to consume the event (while others succeed), those subscribers lose the message.
    • one and only one – Events are delivered to the subscriber in its own global (that is, JTA) transaction. Any changes made by the subscriber within that transaction are committed after the event processing is complete. If the subscriber fails, the transaction is rolled back. Failed events are retried a configured number of times.

This document shows you business events in action from the perspective of above highlighted points and might help you in choosing the right consistency level depending on the scenario.

Assumptions:

    • Using EDN-DB, though observations noted here will not vary when used EDN-JMS.
    • No clustered environment.

Use case:

A mediator raises 2 business events CreateOrder and UpdateOrder. For CreateOrder , we have the following subscribers:

    • Mediator routing the request to ASync BPEL (within same composite)
    • Mediator routing the request to Sync BPEL (within same composite)
    • Asynchronous BPEL process (within same composite)
    • Mediator throws exception while routing the request to Asynchronous BPEL (in different composite)

For UpdateOrder, we have the following subscribers:

    • Mediator routing the request to Asynchronous BPEL (in different composite)

We will observe the behavior in different scenarios by modifying event subscription consistency levels for above subscribers. The exception during the mediator routing is simulated by adding <onReply/> tag which is not needed in actual when routing to Async BPEL process. Example is shown below:

<switch>

<case executionType="direct"

name="Order2BPELProcess1.order2bpelprocess1_client.process">

<action>

<transform>

<part name="$out.payload"

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

</transform>

<invoke reference="Order2BPELProcess1.order2bpelprocess1_client"

operation="process">

<onReply/>

</invoke>

</action>

</case>

</switch>

Configuration:

The retry configuration for one and only one subscribed events and the other EDN configuration can be set in EM console by navigating to soa-infra -> Administration -> System MBean Browser -> Application Defined MBeans -> oracle.as.soainfra.config -> EDN Config -> edn. This will bring up the following screen showing the default parameters.

event retry

Demonstration:

To start with, have a look at the list of events being used and it’s subscriptions below:

events

subsc

Consistency Level – immediate:

Modify all the event subscriptions to immediate consistency level.

immediate

Now raise the CreateOrder event and observe flow trace shown below. Since consistency level is immediate and the exception is thrown by one of the subscribers not all of the subscribers have received the event at all. And also no retry happened in case of faulted subscriber.

flowtrace1

Also we can’t find this event in event recovery console which is shown below:

immediaterecover

To confirm the above observed behavior, now modify the consistency level of few of the events to either guaranteed or one and only one.

imm1

Now again raise the CreateOrder event and observe flow trace shown below. We don’t see any change in behavior from previous iteration. So if an exception is thrown by any one of the immediate consistency level subscribers, then remaining subscribers will not get the event at all irrespective of their subscription consistency levels. And also we would see the exception thrown back while executing from EM console.

imme2

exceptionimmedaite

Consistency Level – guaranteed:

Modify all the event subscriptions to guaranteed consistency level.

gua1

Now raise the CreateOrder event and observe flow trace shown below. Since consistency level is guaranteed all the subscribers have received the event though one of the subscriber is faulted. And no fault is thrown back while testing from EM console as we saw in ‘immediate’ . Also no retry happened in case of faulted subscriber and the event is lost for that subscriber.

gua2

Also we can’t find this event in event recovery console which is shown below:

immediaterecover

Consistency Level – one and only one:

Modify all the event subscriptions to one and only one consistency level.

oaoo1

Now raise the CreateOrder event and observe flow trace shown below. Since consistency level is ‘one and only one’ all the subscribers have received the event though one of the subscriber is faulted. And no fault is thrown back while testing from EM console as we saw in ‘immediate’ . Also retry happened thrice in case of faulted subscriber as we configured the NumberOfRetrys property to 3 (see Configuration section).

oaoo2

If event delivery is failed even after the configured number of retries that event will be marked for Recovery and will be shown in Faults section of Business Events screen in EM console as shown below. Use ‘Retry’ button to recover the event delivery or use ‘Abort’ button to discard.

oaoo3

Other Observations:

Scenario 1: Mediator routes the request to Sync BPEL which throws fault and not caught, then event retry is happening irrespective of the value set for property bpel.config.transaction.

obs1

Scenario 2: Mediator routes the request to ASync BPEL which throws fault and not caught, then event retry is not happened as expected, as the fault in Async BPEL process will not propagated back unless we do it by explicit callback and bpel.config.transaction is irrelevant in this case and the value of property bpel.config.oneWayDeliveryPolicy is set to async.persist.

obs2

Scenario 3: Mediator routes the request to ASync BPEL which throws fault and not caught having the value of property bpel.config.oneWayDeliveryPolicy is set to sync. As expected, the event retry happened in this case.

obs3

The same behavior isobserved, when BPEL is subscribed to event (no mediator in between) and the value of property bpel.config.oneWayDeliveryPolicy is set to sync.

obs31

Scenario 4: Event is published and one of the subscribers is not active. In this case, non-active subscriber will loose event and no event delivery happens even after bringing up the subscriber. We will simulate this case using by doing shutdown of another composite. In the below screenshot, we could see that event is not delivered to 6th subscriber as the composite is down and the flow trace will not change even after bringing up the composite.

obs4

This is due to fact that list of subscriptions no longer has this entry as shown below, so one should think about this type of possibility in real time use cases and have contingency plan in place for such cases.

obs5

References:

http://docs.oracle.com/cd/E28280_01/dev.1111/e10224/obe_intro.htm#CHDIBHBE

Download:

Sample code used in this post can be downloaded from here.


Advertisements

Pages

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

Join 337 other followers

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


%d bloggers like this: