BizTalk: Architectural Tips: "Get OnlyLast Data" ("GetLastMessage") pattern

There is a case:
 
One part of the solution periodically publishes the data. 
There are two kind of subscribers. 
One kind of subscribers want to get the messages while they are published.
Second kind of subscribers poll this messages randomly:
  • the subscribers request the the LAST message randomly;
  • they want to get the last input message only;
  • if the last message was not changed since the last poll, the subscribers have to get the same last message (several times)
 
The usual publish-subscribe pattern doesn't work, because
  1. the usual subscriber MUST receive ALL published messages. It cannot omit one message and receive only the last one.
  2. After subscriber received the message, it cannot receive this message one more time. The message pops out of the query.
 
The question is: How can I do this in "BizTalk style"?
 
The orchestration implements this "Get Last Message" pattern.
"Get Last Message" orchestaration
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 receives all input messages (Trip_Canonical) in the Unifies Sequential convoy. Usually in the convoy there are two receive shapes, one before and one inside a loop. I use the receive for the control message as an activate receive, it helps me to control the life cycle of 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 Last Request message), and the send shape, which send this last message. The last message is the same as the input message, the only difference is in the value 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).

    Orchestration View window
  • 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.
  • All receives gather under one direct port. This is an Ordered delivery=True port.
    Direct port properties
    The send Control message port is also under this port.

There are the Control messages:
START:
Control START message

STOP:
STOP Control message
Input message the "Trips_Canonical":
Get Last Request message:
Last Request message
Last message:
Last message
Print | posted on Sunday, August 5, 2007 6:44 PM

Feedback

No comments posted yet.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: