[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding and Document References
Dale, Your suggestions are exactly what the BPSS context mechanism draft proposes too. Here's a fragment of that XML (from figure 3.2) so you can see how you can add linkage between a business rule and a time-to-perform / respond item. <ebContext> <!-- namespace declarations and header omitted for clarity --> <conditions> <context condition="doc:orderType='URGENT'" <condition name=="bpss:timeToAcknowledgeAcceptance*" value="P10M" label=="URGENT TIMEOUT" as:member="P5M,P10M,P15M" /> </conditions> <ebContext> By placing a pointer via a URI from the CPA to this XML context instance - we have what we need here. In the CPA you can review the XML and verify the business constriants between you and your partner. In the BPSS, you can reference the CPA to retrieve the context XML and then drive the actual binding at runtime using the <context> conditions . Hope that makes this clearer. Thanks, DW. p.s. You had indicated that there is already an appropriate spot in the CPA that we can use to set this BPSScontextURI value, and it would be good if we could get agreement on this with the CPP/A team. ----- Original Message ----- From: "Dale Moberg" <dmoberg@cyclonecommerce.com> To: <martin.me.roberts@bt.com>; <ebxml-bp@lists.oasis-open.org> Sent: Tuesday, January 27, 2004 12:00 PM Subject: RE: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding and Document References Martin writes: "Late Binding has some interesting and curious requirements. We tried to model the ordering process in BT. We found that the use of the overall TimeToPerform for a BinaryCollaboration was unworkable. If I have a PO that has a standard lead teim of 5 days do I set the TTP to 5 days? But what happens if the customer does not want their goods for 30days. The process would time out. So I would like to treat all Times and possible documents as being variables that may, but not necessarily, be overidden by data sent within the Business Documents. At the moment there is lots of data that is passed between our customers that effect the times and documents which we can not use as there is no way to reference that information within the BPSS." Martin, I think you are joining other people who have commented that TimeToPerform (and also TimeToAcknowledge) can be difficult to know how to define at BP definition time. This makes me wonder whether they should be optional to place in BPSS for cases where the time constraints are known at design time? (Are there any cases of these?) In fact, the use cases being presented seem to suggest that configuration time may also be too early to decide on these values (so the CPPA really should also have some way to indicate that precise values will be set at runtime). Would it still be useful to enter into agreements on the "floor" or "ceiling" for these values? Would this interval be a configuration aspect of a CPA agreement (or part of BPSS, or in a UBAC agreement)? Is there any need to retain in CPPA or BPSS any support for declaring values for these parameters? If it is runtime only, should it be part of Messaging headers? Or possibly in business headers (such as those of ATG SBDH ?) Or both, depending on which software components need to set or get the values. It seems to me that while these values certainly pertain to the business process commitments, they are not clearly part of the design-time machinery. It is difficult to know which software components need these values, or at what layer of specification, the values that are used need to be declared. I am sorry to be raising so many questions but those are ones that occur to me while reading your remarks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]