Custom Healthcare Pack pattern (HCP) - reset sequence when Receiver is restarted.

Idea / RFE Review. Thank you for taking the time to raise this enhancement request ... and we also note the long-running service case you have on this issue. For the benefit of other readers / potential supporters for this request I will summarise my understanding of the issue and potential solution below ...

1. You are currently operating on a customized version of the out of the box "HL7 to HL7 DFDL pattern" which comes with the healthcare pack, which creates message flows as independent resources rather than grouped into applications. Applications are the strategic preference for the product moving forward, but this is tangential to the core of this issue.

2. The two endpoint applications where data is ultimately being sent become part of the deployed solution at different times, so at the time of your initial development, there is only a single Transform&Route flow, and a single Sender flow ... then at a later date you wish to deploy a second Transform&Route flow alongside a second Sender flow.

3. As per IBM documentation, the current sequence numbers for each active sequence group are stored on the queues named as follows:

SYSTEM.BROKER.SEQ.GROUP

SYSTEM.BROKER.SEQ.NUMBER

The storage queues used by default for the Resequence node are SYSTEM.BROKER.EDA.COLLECTION and SYSTEM.BROKER.EDA.EVENTS but in your environment you have chosen to use non-default queue prefixes (specified through configurable service) which are different for each sender:

SYSTEM.BROKER.EDA.SENDER1.COLLECTION

SYSTEM.BROKER.EDA.SENDER1.EVENTS

SYSTEM.BROKER.EDA.SENDER2.COLLECTION

SYSTEM.BROKER.EDA.SENDER2.EVENTS

4. So ... if you don't delete messages from the SYSTEM queues, then the sequence node in the receiver (of which there is only 1 in your architecture) is not currently "reset" when you add your second sender flow. As a result, the new (second) sender flow is expecting sequence number 1, which will never come along, because messages have already been processed by the receiver and the first sender, so the current sequence number has already advanced higher. If we have understood correctly, your suggestion in this idea is that when a message flow containing a sequence node is restarted the sequence node should reset the current sequence number to the start of the sequence definition literal defined on the node's properties... ie "The sequence should be reset when receiver is restarted." This would constitute a change in behaviour of the product which would not be desireable for all users. However, one could imagine a potential design whereby an additional boolean property is added to the node or perhaps through a policy (the ACE equivalent of the old IIB configurable service concept) or runtime environment variable named something like "reset sequence on restart" which is false by default to match current behaviour. Is this the kind of new behaviour you had in mind? I believe we will be discussing this idea with you directly later this week, so perhaps we can explore this suggestion then and obviously in case there are any, also correct any misunderstandings we may have of the current issue / suggestion.