Hi all,

I'm designing an "order to invoice" workflow in BTS2004, and would welcome
some advice from more established experts than myself...

All the messages are file-based. From the perspective of the seller party,
the messages are purchase order (in), despatch advice (out), goods-receipt
(in) and invoice (out). A text-book solution would assume that every
orchestration instance could begin with an order and end with an invoice.
Unfortunately, it's not that simple. For a whole bunch of reasons, the
electronic version of the PO might not be received, and so the orchestration
might begin with a shipment message. Or worse, with a goods-receipt. Just fo
r
fun, we don't want to split each message into a separate workflow, because
they're dependent on each other (where the orchestration doesn't begin with 
a
PO, of course, some data will be missing from subsequent messages), and we
want to examine orchestration instances using BAM.

I've tried my best (lots of sweat, not much muscle) to incorporate a listen
shape with a separate branch for each workflow scenario. For instance the
first branch runs PO-to-invoice, the second shipment-to-invoice, the third
GR-to-invoice etc. There's an activate receive shape at the top of each
branch (all connected to the same file-receive port, which also initialises 
a
correlation set. Subsequent receives follow the c-set, thereby forcing a
convoy. But try as I might, I can't stop multiple orchestration instances
being fired each time (say) a GR-message is received.

It'd be great if BizTalk allowed you to prioritise instance subscriptions
(correlations) over new orchestration instances, thereby not launching a new
instance when a message can be correlated to an existing instance. But I
couldn't find anything along these lines.

Has anyone got a magical solution to this? Any pointers would be greatly
appreciated.

Thanks,

Glynn

[ Post a follow-up to this message ]

I'm sorry for the duplicate posting of this thread. It was entered via
support.microsoft.com which reported an error (saying the posting was
unsuccessful) on the first two attempts. Clearly the error was the error
message itself.... perhaps the regulator could delete the duplicates - thank
s.

[ Post a follow-up to this message ]