ebxml-bp message

Subject: Use case for BPSS long running conversations

Team,

On the IV&I call today a scenario was described that I thought

was useful for us to consider.

I'll describe the scenario first then offer how I think we should

address this - then turn it over to the floor!

So - the IV&I as Serm' outlined last week - is about

streamlining inventory management and integration with IV

products. The idea is to have a constant stream of msgs

that update on products that are being watched (kinda

event driven model).

So if someone sends out a InventoryStatusCheck request

and lists a bunch of part / product numbers and to various

suppliers - then that initiates the process.

Now each receiver potentially replies multiple times - for

different stock numbers. So some responses come in

right away - others may come weeks later.

Obviously issue #1 is timeToPerform - how to resolve that?

OK - my thoughts are -

a) John Yunkers notes on when a BPSS starts apply.

b) We could view this as the following:

Distributor sends out InventoryStatusCheck

Suppliers respond with ConfirmPartNumbers

immediately - so TimeToPerform is say P1D,

that completes the first action in the BPSS.

Next each supplier initiates the next action in

the BPSS - but there is a guard condition on this

that waits until some event or signal indicates

its ready to go (so its like the idea of a BPSS

initializing - but here it happens in the middle

of the BPSS - attached to some action sequence).

After event occurs (some change in stock status),

then send distributor stockChangeDetails - and

the distributor then responds with ContinueStockWatch,

or EndStockWatch (timetoperform on this could be P1H).

And so this continues. Now at some point the distributor

may send EndStockWatch for the original part/product

numbers - to close the BPSS completely - that would be

a fork of course - based on some end-of-process check.

Thoughts?

Thanks, DW