Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Bindingand Document References

["Anders W. Tell" <anderst@toolsmiths.se>]

Dale,

Its a complicated situation, but its clear that timeToPerform is needed 
however there are several "times" when timeToPerform  could/should be 
initiated or changed. A list of possible "times" may enrich and simplify 
the discussions in relation to current set of requirements.

1: in BPSS as default value - needed when you want to establish 
(industry) TradePractices. Here BPSS is reusable artifact that is 
related to a specific context (such as BusinessArea's, ProcessArea's ala 
Porter or SCORE). In order words it used by many legal entities.

2. in TPA as default value - needed when you want to establish bilateral 
TradePractices. This value overrides BPSS default value since agreement 
is established at a later stage

3. in Technical agreement such as CPA as default value - this value 
overrides TPA and BPSS value since agreement is established at a later 
stage.

4. in a negotiated BPSS that specializes an industry BPSS through 
negotiation process. This is done in the scope of a one more  UBAC,TPA, CPA.

5. at the time of enactment/instantiation of a BPSS. Here a specific 
timeToPerform may be proposed by initiator and accepted by responder. 
Usually not a good idea to let the initiator unilaterally decide, 
especially if the timeToPerform really means delivery date.

6.a by exchanged business information in a transaction. TimeToPerform is 
extracted from exchanged document during  transaction enactment.

6.b by exchanged business information in a transaction. TimeToPerform is 
extracted dynamically by "invocing a method", "calling a function", etc. 
during  transaction enactment.

7. by referencing a "variable" that contains a duration value that was 
extracted from an enactment of transaction/completion of another 
transaction at an earlier point in time. I.e. first transaction sets a 
variable ttp="valueFromRespondingDocument" at transaction completion 
with success status

8. by the time of enactment,execution of a bootstrap transaction named 
"ChangeTimeToPerform(bpssInstanceID, transactionActivityID, 2h)". Here a 
change is proposed and subsecuently accepted or rejected

....

99. TimeToPerform in a BPSS is not really a constraint on the message 
exchange protocol but really a delivery-date constraint, that is, a real 
world event constraint. Possibly in conjunction with a PaymentUpFront 
business rule.
However by putting a delivery-date constraint in a BPPS as TimeToPerform 
you get an approximation that both parties can live with.

Have I missed any relevant time,mechanism?


thanks
/anders


Dale Moberg wrote:

>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.
>
>
>
>
>  
>


-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////