CODEWITHSUNDEEP
biztalkbiztalk-2010
Alex In Paris
Alex In Paris

Reputation: 1077

What's the best way to create/use an ID throughout the processing of a message in Biztalk?

Our program so far: We have a process that involves multiple schemata, orchestrations and messages sent/received.

Our desire: To have an ID that links the whole process together when we log our progress into a SQL server table.

So far, we have a table that logs our progress but when there are multiple messages it is very difficult to read since Biztalk will, sometimes, process certain messages out of order.

E.g., we could have:

1 Beginning process for client1
2 Second item for client1
3 Third item for client1
4 Final item for client1

Easily followed if there's only one client being updated at a time. On the other hand, this will be much more likely:

1 Beginning process for client1
2 Beginning process for client2
3 Second item for client2
4 Third item for client2
5 Second item for client1
6 Third item for client1
7 Final item for client1
8 Final item for client2

It would be nice to have an ID throughout the whole thing so that the last listing could ordered by this ID field.

What is the best and/or quickest way to do this? We had thought to add an ID, we would create, from the initial moment of the first orchestration's triggering and keep passing that value to all the schemata and later orchestrations. This seems like a lot of work and would require we modify all the schemata - which just seems wrong.

Should we even be wanting to have such an ID? Any other solutions that come to mind?

Upvotes: 1

Views: 522

Answers (5)

Derek Beattie
Derek Beattie

Reputation: 9478

You could create a UniqueId and StepId and pass them around in the message context. When a new process for a client starts set UniqueId to a Guid and StepId to 1. As it gets passed to the next process increment the StepId.

This would allow you to query events, grouped by client id and in the order (stepId) the event happened.

Upvotes: 1

Jay
Jay

Reputation: 14471

Biztalk assigns various values in the message context that usually persist for the life of the processing of that message. Such as the initial MessageId. Will that work for you?

In our application we have to use an externally provided ID (from the customer). We have a multi-part message with this id in part of it. You might consider that as well

Upvotes: 1

Fabio
Fabio

Reputation: 730

Take a look at BAM. It's designed to do exactly what you describe: Using Business Activity Monitoring

This book has got a very good chapter about BAM and this tool, by one of the authors of the book, can help you developing your BAM solution. And finally, a nice BAM Poster.

Don't be put off by the initial complexity. When you get your head around it, BAM it's one of the coolest features of BizTalk.

Hope this helps. Good luck.

Upvotes: 1

StuartLC
StuartLC

Reputation: 107277

I'm not sure I fully understand all the details of your specific setup, but here goes:

If you can correlate the messages from the same client into a "long running" orchestration (which waits for subsequent messages from the same client), then the orchestration will have an automatically assigned ServiceId Guid, which will be kept throughout the orchestration.

As you say, for correlation purposes, you would usually try and use natural keys within the existing incoming message schemas to correlate subsequent messages back to the running orchestration - this way you don't need to change the schemas. In your example, ClientId might be a good correlation, provided that the same client cannot send multiple message 'sets' simultaneously. (and worst case, if you do add a new correlation key to the schemas, all systems involved in the orchestration will need to be changed to 'remember' this key and return it to you.) Again, assuming ClientId as a correlation key, in your example, 2 orchestrations would be running simultaneously - one for Client 1 and one for Client 2

However, for scalability and version control reasons, (very) long running orchestrations are generally to be avoided unless they are absolutely necessary (e.g. unless you can only trigger a process once all 4 client messages are received). If you decide to keep each message as a separate orchestration or just mapped and filtered on a port, another way to 'track' the sets of is by using BAM - you can use a continuation to tie all the client messages back together, e.g. for the purpose of a report or such.

Upvotes: 1

tom redfern
tom redfern

Reputation: 31760

This may not exactly be the easiest way, but have you looked at this:

http://blogs.msdn.com/b/appfabriccat/archive/2010/08/30/biztalk-application-tracing-made-easy-with-biztalk-cat-instrumentation-framework-controller.aspx

Basically it's an instrumentation framework which allows you to event out from pipelines, maps, orchs, etc.

When you write out to the event-trace you can use a "business key" which will tie mutltiple events together in a chain, similar to what you are saying.

Available here http://btscatifcontroller.codeplex.com/

Upvotes: 1

Related Questions