1 Reply Latest reply: Jun 11, 2009 11:32 AM by tbeets RSS

    Behaviour of EDN in RC3

      Having worked with RC3 of SOA Suite 11g, particularly the new EDN features, I have come across the following issues:

      The use case I am trying to model is that I have, for example, three orders. The first is for the physical installation of a telephone line, and the other two are for services. These orders were all raised at different times and are only connected by virtue of the fact that they are for the same customer using the same telephone number. The dependency between the orders is relevant only at a certain point, i.e. the service orders can only be tested end-to-end when the line has been installed. I therefore have three ongoing order processes, where the line order will at some stage raise the Line Installed event, with the other two order processes waiting. The correlation id is, for argument's sake, the telephone number.

      When subscribing to specific events in a BPEL process I cannot use the correlation set mechanism to have multiple instances of the same process waiting for the same event with the same correlation id, in this instance the telephone number. I get the following error:

      +Conflicting receive. A similar receive activity is being declared in the same process. Another receive activity or equivalent (currently, onMessage branch in a pick activity) has already been enabled with the partnerLink "", operation name "" and correlation set "{{http://xmlns.oracle.com/TestApp/EventListen/ProcessRequest/correlationset}TelephoneNumber={http://xmlns.oracle.com/TestApp/EventListen/ProcessRequest/correlationset}TelephoneNumber=115}" (or conversation ID). Appendix A - Standard Faults in the BPEL 1.1 specification specifies a fault should be thrown under these conditions. Redeploy the process after removing the conflicting receive activities.+

      This means I cannot have any master/detail coordination events where the key is, for example, the common order id. While this is understandable from the point of view of correlations - which are designed to support bilateral conversations - it is no good for the more generic event processing where multiple identical subscribers exist for a single event.

      A further downside of using the existing correlation functionality is that I need to initiate the correlation set with an invoke before I can subscribe to the event in a receive. This underlines the conversational nature of the design, whereas an event subscription, even for a specific key, can be entirely disconnected.

      My question now is: am I missing something or should this functionality be amended (I understand that EDN for BPEL will not actually make it to the first GA release)?

      Further to that, for a mediator component, which subscribes to an event, I can only define a filter based on the event payload. What I am looking for is a way where the event subscription takes an additional variable carrying values which can be used to construct the filter statement, e.g. an order number. It may be possible to do this, but I haven't seen any way how to.
        • 1. Re: Behaviour of EDN in RC3
          This is an interesting post from a design pattern perspective. I'm not sure what Oracle will say, although I think the nature of an event and event payload should remain disconnected from a particular component implementation requirement (such as BPEL correlation); however, I think there should be utilities and pattern support in the Mediator component (see below).

          Here's a couple thoughts:

          1. One potential workaround would be to have the three orders (in your example), write the telephone number and say the unique ID of the process instance to a custom database table (before the async Receive activity that is). Base the correlation set on the multi-part key (telephone number + process unique ID). Write the Mediator component that is fired by the LineInstalled event so that it looks up all the process instances that relate to the telephone number (from the event payload) and calls each of the three (i.e. correlated with the appropriate process ID). Each re-hydrated process should then delete the respective row from the lookup table...

          2. Oracle should make a fan-out pattern of #1 easy by providing a seeded lookup service or embedded function (that can be called by a mediator or other component) that returns from the BPEL store, all -ACTIVE- instances that match a partial-correlation key, etc.

          (Maybe this pattern and utility function exists already -- I am far from a Mediator expert...)