There is acase:
One part of the solution periodically publishes the data.This part is out of this article.
There are two kind of subscribers.
One kind of subscribers want to get the messages while they are published.
Second kind of subscribers pool this messages randomly:
- undefined quantity of the subscribers request the undefined number times the LAST message in random interval.
- they want toget the last input message only.
The usual publish-subscribe pattern doesn’t work, because
- the usual subscriber MUST receive ALL published messages. It cannot omit several and receive only others. (It can but it have to implement this logic by itself, it is not the case.)
- After subscriber received the message, it cannot receive this message one more time. The message pops out of the query.
- After one subscriber received the message, the other subscriber cannot receive the same message if it is not subscribed to the message. It is not a “random” , “one time”, “randomly appeared/disappeared”subscriber.
The question is: How can I do this in “BizTalk style”?
The orchestration implements this “Get Last Message” pattern.
The orchestration has three parts.
One is for controlling this orchestration. It starts and stops the orchestration by the Control messages (Control START and Control STOP). That’s all.
The second part is a part of the pattern. It receive all input messages (Trips_Canonical) in the Unifies Sequential convoy. Usually in the samples there are two receive shapes, one before and one inside the loop. I use the receive for the control message as an activate receive, it helps me to simplify the orchestration.
The third part is a part of the pattern too. It is compounded from the receive shape which requests the last message (Get LastRequest message), and the send shape, which send this last message. The last message isthe same as the input message, the only difference is in thevalue of the”ProcessName” element.
This sample is used in the content routed scenario that’s why there are several interesting points.
- all messages have one first level node, right under root node with name “ProcessName”. This node holds the name of the message publisher. This helps route the messages with the same message type to different routes. For example, the input Trip_Canonical messages and the output Trip_Canonical have different values of this node, and this is the only difference.
- the messages correlated by this “ProcessName” node (the cor_ApplicationName Correlation set).
- I use the Decide shape to avoid to send the requested last message if I have nothing to send. But to get this project built I have to create the “foo” message.
- I gather all receives under one direct port. This is an Ordered delivery=True port.
Maybe it worth to include the send port under this port too.
There are the Control messages:
START:
STOP:
Input message the “Trips_Canonical”:
Get LastRequest message:
Last message: