Topic
  • 3 replies
  • Latest Post - ‏2014-08-20T12:23:00Z by VenFil
VenFil
VenFil
55 Posts

Pinned topic UCA - Consume Message and Durable Subscription Behaviour

‏2014-08-11T10:51:48Z | consume durable message subcription uca

Hi everyone,


I got a problem due to use Consume Message and Durable Subscription at same time in a UCA.

I need a UCA to wait for an event send by a parallel process. To fulfill the requirements I need to maintain the messages because it is possible send a message to the UCA finish the before the wait and it is necessary consume the message just one time.

The problem is: if I need to return to this step the wait never happens again. The process just continue his flow.

If I uncheck the "Durable Subscription" check box works but only if the UCA is not invoked previously (situation that I cannot guarantee)


Can someone help me with this?


Best regards,

VF

Updated on 2014-08-11T13:09:37Z at 2014-08-11T13:09:37Z by VenFil
  • dogren@gmail.com
    dogren@gmail.com
    438 Posts
    ACCEPTED ANSWER

    Re: UCA - Consume Message and Durable Subscription Behaviour

    ‏2014-08-12T14:03:45Z  

    I don't think "consume" means what you think it does. Consume has to do with a weird edge case when there are multiple listeners on the same BPD all listening for the same UCA. What  you are seeing is the expected behavior.

    I'm not sure I understand your use case well enough to propose an answer. I think the tricky bit is under what cases would you want to return to the step, and if you do, what would you be waiting for? And if you are sending multiple messages from the parallel process, do you have to be concerned that the duplicates might overwrite previous messages? How can you know that the parallel process intends to send a second message?

    Fundamentally I think the problem might be that you are thinking of a UCA like a JMS event and there are some big differences.

    One potential solution would be to change the correlation key. Fundamentally you need to make it unique. If there is some kind of business logic that inherently sequences them, then include that. Alternatively, use a message handler that prefixes the previous correlation key with a sequential index. That way every time the IME is reached you will have a unique key that you can listen for (and therefore previous messages would be ignored). But without knowing your use case it's hard to know if that is a good solution. (There are so tricky parts to that solution, but I don't want to go into details without know if it helps your use case.)

    David

    Updated on 2014-08-12T16:36:21Z at 2014-08-12T16:36:21Z by dogren@gmail.com
  • DQ1D_Glenn_Smith
    DQ1D_Glenn_Smith
    100 Posts

    Re: UCA - Consume Message and Durable Subscription Behaviour

    ‏2014-08-12T12:20:38Z  

    Your statement of requirements seems contradictory.

     it is necessary consume the message just one time

    and

    The problem is: if I need to return to this step

    These seem mutually exclusive.  Perhaps you can explain more clearly your requirement.

  • dogren@gmail.com
    dogren@gmail.com
    438 Posts

    Re: UCA - Consume Message and Durable Subscription Behaviour

    ‏2014-08-12T14:03:45Z  

    I don't think "consume" means what you think it does. Consume has to do with a weird edge case when there are multiple listeners on the same BPD all listening for the same UCA. What  you are seeing is the expected behavior.

    I'm not sure I understand your use case well enough to propose an answer. I think the tricky bit is under what cases would you want to return to the step, and if you do, what would you be waiting for? And if you are sending multiple messages from the parallel process, do you have to be concerned that the duplicates might overwrite previous messages? How can you know that the parallel process intends to send a second message?

    Fundamentally I think the problem might be that you are thinking of a UCA like a JMS event and there are some big differences.

    One potential solution would be to change the correlation key. Fundamentally you need to make it unique. If there is some kind of business logic that inherently sequences them, then include that. Alternatively, use a message handler that prefixes the previous correlation key with a sequential index. That way every time the IME is reached you will have a unique key that you can listen for (and therefore previous messages would be ignored). But without knowing your use case it's hard to know if that is a good solution. (There are so tricky parts to that solution, but I don't want to go into details without know if it helps your use case.)

    David

    Updated on 2014-08-12T16:36:21Z at 2014-08-12T16:36:21Z by dogren@gmail.com
  • VenFil
    VenFil
    55 Posts

    Re: UCA - Consume Message and Durable Subscription Behaviour

    ‏2014-08-20T12:23:00Z  

    Hi,

     

    First of all, I want to apologize for my bad problem description.

    David explained my problem better than me. My UCA have the "Durable Subscription" option checked, so if I need to wait more than one time for the same event.

    In the first time all works correctly but the next ones I cannot wait. David option seems acceptable depending the scenario. Everything works fine if I can create a token that is known for everyone, the senders and the receivers.

    But if I can't do that? Maybe I have to create a message queue solution kind right? Do you have a simpler idea?

     

    Best regards,

    VF