ebBP 11/29/2005: Resolution for Recursion and Optionality

[Monica J Martin <Monica.Martin@Sun.COM>]

11/28/2005
Cristiano Novelli is working through the ebBP process definition as well 
as use of CPPA. Dale, Cristiano and I have concluded at this time we can 
proceed with ebBP schema as is. Should Cristiano find other issues he 
will raise those either in the 15-day Public Review period or we may 
choose to address later as an errata.

John, do you have any suggestions to provide any attributes here as you 
had discussed in recent calls? If not, we can discuss this resolution in 
tomorrow's call.

Thanks.

> mm3: (11/14/2005) Cristiano,
> We discussed this in further detail in last week's call and had some 
> very productive suggestions from John Yunker. Please post to me and 
> those cc: here so we can ensure you can effectively use the key ebBP 
> functions.
>
>   1. Re-enter (recursion): Use fork that sends you back into the same
>      transaction. Use conditions on that fork not to re-enter. Example:
>      Freight Status Advice, for example, has several possible values.
>      We can model in two ways - one that reoccurs many times with a
>      condition on the fork after the advice that says that if this
>      status is 'delivered', then we don't re-enter. Otherwise, we
>      recycle and look for another one.   2. Optionality: There are 
> times that you don't know if you will get
>      more (order status updates). You know at some point you are going
>      get a delivery confirmation. That could be a different document.
>      There could be a join related to this; when you receive delivery
>      advice and move on always. If this is not the case and explicit
>      closure is more difficult, suggest use a fork where parallel
>      processing occurs. Receipt Advice, Freight Status Advise - both
>      could be occurring.  Use preconditions and then could see if get
>      delivery advise, if get freight advice, the collaboration is done,
>      error occurs. Set up flows using fork-join to get to correct
>      transactions. Based on pre- and post-conditions, when you get to
>      the fork you do the right thing.
>
>        Comments courtesy of John Yunker
>
> If you can work with us, we'll be able to move forward. Other user 
> communities are at the same stage and we can help you help one 
> another. I've included an example from the CPP/A negotiation ebBP 
> instance for your review. Thanks.
>
>> mm2: 11/6/2005 As I indicated team, I've been corresponding with 
>> Cristiano on his process definition and use of condition expressions. 
>> He is interested in using OperationMapping and effectively 
>> implementing the condition expressions (including the Ends and Begins 
>> When).  I'd encourage any comments you have. Cristiano is considering 
>> how to use the expressions given his query to John Yunker, myself and 
>> Dale Moberg.  Comments encouraged. Thanks.
>>
>>>> novelli: Ok, I like "beginWhen" and "endsWhen" solution.
>>>> How can I describe the condition expression:
>>>> "the BTA X is started"?
>>>> Is it BSI dependent?
>>>> Can you do some short XML fragment examples?
>>>
>>> mm1: Section 3.4.10.1 gives an example for endsWhen, as well as 
>>> references for semantic variables and condition expressions in 
>>> general. Dale/John/Kenji, can you help Cristiano with some examples 
>>> of condition expressions? We do have their use shown in Appendix A 
>>> (for UBL example). These latter examples could help you identify 
>>> what responses are needed, Cristiano, such as you identifying what 
>>> notification is required on an Order Status Report.  As well, for 
>>> the reuse of this BT in a BTA, you could have a Commission Order 
>>> Change used if the XPath (in condition expression) shows that the 
>>> business document includes such information.
>>>
>>> Guys, I'd encourage more suggestions for Cristiano so we ensure he 
>>> has a quality example to use and we understand what other changes we 
>>> need to include in the specification.
>>>
>>>>>            2. Any BT can be part of a recursive loop that continues
>>>>>                  until explicitly terminated (explicit 
>>>>> recursions). Use
>>>>>                  endsWhen for example.
>>>>
>>>> novelli: If I don't specify endsWhen condition expression, is 
>>>> execution of a BT implicit recursive?
>>>> If false, how do I describe the loop?
>>>
>>> mm1: As John indicated in his email (see below).  We've not 
>>> encouraged the implicit recursiveness.  John, can you give Cristiano 
>>> more details? Thanks.
>>> ....Yunker: ....The "endsWhen" could be used to bound repeating BT, 
>>> making the modeling simpler in those cases.
>>>
>>>> I can't find our discussion, however the linking nature of the spec 
>>>> (decision / fork / join) allows for explicit modeling of the type 
>>>> raised by Cristiano.
>>>> Any BT can be fronted by a decision that explicitly excludes 
>>>> execution of the BT (explicit optionality)
>>>> Any BT can be part of a recursive loop that continues until 
>>>> explicitly terminated (explicit recursions)
>>>> As I ponder this, it strikes me that any declaration of optionality 
>>>> or recursion needs to include the conditions that drive recursion 
>>>> and optionality.  If the conditions are "the partner feels like 
>>>> sending that document", then we handle that already through 
>>>> parallel execution paths and beginsWhen.
>>>> I CAN see how an "optional" declaration may help with certain types 
>>>> of status messages, but when I think about it further I would like 
>>>> to see the execution paths explicitly modeled in either case, 
>>>> making the "optional" declaration "documentation" in essence.
>>>