Hi all,

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

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 begi
n
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 for 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). We also want to monitor the business
process through BAM, so a single workflow is a must.

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, each of which
initialises a correlation set. In each branch, subsequent receives follow th
e
c-set, thereby forcing a sequential receive 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 subscription
matches (ie correlations) over new orchestration instances, thereby not
launching a new orchestration instance when a message can be correlated to a
n
existing instance. But I can't find anything along those lines.

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

Thanks,

Glynn

[ Post a follow-up to this message ]