[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 1/18/2004: Work Item 55 Time To Perform Summary
Summary Statement provided by Lars Abrell 12 Jan 2004 and updates from MMartin. Note that the problem statement should be refined so we have some objectives and can derive requirements in preparation for February F2F. I think if we can solidify our business and technical impacts, we can resolve this work item. Problem statement: * Need urgent time to perform and normal time to perform. * Selected at runtime. * Used to specify when a trading partner is expected to perform a “business function." Want support for late binding with time to perform attribute. Specifying the timeToPerform to the greatest time possible in the context of this type of collaboration [1]. Need to allow late binding to accommodate logical business document requirements. BPSS is the target for the late binding of time to perform. 3 technical options: 1. standard BPSS doc header 2. change ebMS to allow timeout 3. Use CAM spec Business and/or technical options or challenges to consider: 1. Should the BPSS specify a) "if" and b) "when" the late binding may occur? 2. Such runtime impacts may be driven either by business or service level agreements, or on a case by case basis. For the latter, I would think we will have to discuss the per-instance impact and its appropriateness [1]. In addition, an agreement may specify a range or default values, and that they may be clarified or attached to real world events at runtime. * Need to differentiate notices from actual real world events. * Need to be capable of handling business entities [2]. * In call 5 Jan 2004, we discussed that multiple technical options are probable and it may be sufficient to: a) specify if such changes are allowed, and if so for what, and 2) allow the technical option to be selected outside of BPSS. * Need to model the TTP on the Binary Collaboration. 3. Can we break the response into multiple responses: where more timing applies to specific requirements (such as delivery) or either from the perspective of the requestor or the responder? Current Functionality: * The BPSS uses one flow/control. At design time, substitution sets and packages may be used to accommodate some variability. Functionality lacking for runtime. * It is possible to override BPSS attributes in the CPP/A between the parties. May complement any late binding functionality if adopted. See Section 9 of CPP/A document. o In the future, technical negotiation of business transaction characteristics may be possible with CPP/A negotiation [post v1]. Related Work Items: * 23 (more than one business document and envelope) * 25 (multiple envelopes for responding activity) * 28 (role reversal) * 46 (revocation and additional transactional support) [1] May likely not be as tight you would like given the interactions defined by internal systems to support. Which brings up an interesting point on being able to keep these systems loosely coupled. For example, we have one case where the order may go by alternate means and not logged in the B2B system, and this really complicates this company's processing. We have to account for that at the process level. We can refine/revise/expand this in our meeting 18 Jan 2004.
WorkItem55-Abrell-Proposal-121003.doc
Subject: RE: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform] From: Lars.Abrell@teliasonera.com Date: Mon, 05 Jan 2004 17:58:12 +0100 To: ebxml-bp@lists.oasis-open.org Serm, It is of course possible to create multiple separate Binary Collaborations that differs only in the timeToPerform value and where the process flow it self is exactly the same. First, IMHO I don't think the timeToPerform value is always an equally "important" business rule to be agreed to and pre-known and determined in the same way as the process flow it self is. I also believe that this approach could end of with to many Binary Collaborations to handle when you actually only need one. Second, during the Christmas holidays I have read the "UN/CEFACT - Standard Business Document Header Technical Specification Revision 2.1" (http://webster.disa.org/cefact-groups/atg/downloads/index.cfm/). It seems to me as if this specification specifies the things that I sometimes think needs to be communicated between trading partners at runtime. I believe this Standard Business Document Header to some degree overlaps the ebMS spec and especially the ConversationId, Service, Action and CPAId elements, but at the same time provide me with most (if not all) of the additional information elements I have been missing. The Standard Business Document Header has a "block" called "BusinessScope" that in turn contains a "Service Information" block and a "CorralationInformation" block. This "CorralationInformation" block contains an element called "ExpectedResponseDateTime" that could be communicated at runtime between the trading partners and seems to give me what I have been looking for. See below. <BusinessScope> <Scope> <Type>BusinessProcess</Type> ... <CorrelationInformation> ... <ExpectedResponseDateTime>2003-05-10T00:31:52Z</ExpectedResponseDateTime> ... </CorrelationInformation> </Scope> </BusinessScope> The idea and theory around BusinessScope (see appendix 3) look also very interesting. But I'm somewhat confused about when it's best to communicate the other BusinessScope kind of information in a Standard Business Document Header and when to use the elements provided by ebMS. * Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080 * Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden -----Original Message----- From: Boonserm (Serm) Kulvatunyou [mailto:serm@nist.gov] Sent: Monday, December 29, 2003 2:51 AM To: ebxml-bp@lists.oasis-open.org Subject: Re: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform] I am not sure if I understand the whole complexity of the issue or not. I preferred the BPSS being declarative at design time of business rule b/c 1) business rules are captured declaratively and 2) it supports the advance dynamic binding b/w partners. So my thought for the use case described by Lars is to create multiple Binary Collaborations with different timeToPerform's for both BC and BTA for different classes of products/services rather than overriding at the runtime. I'm not sure whether the BPSS (I mean specifically BC) is supposed to be context specific or context indenpendent according to the Architecture. My thought is that it is context specific. - serm ----- Original Message ----- From: <Lars.Abrell@teliasonera.com> To: <Monica.Martin@Sun.COM>; <ebxml-bp@lists.oasis-open.org> Sent: Wednesday, December 10, 2003 7:19 PM Subject: RE: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform] Hi, I have compiled a short summary proposal for Work Item 55 about the late binding of the timeToPerform attribute. This is my very first proposal and I'm not sure if this is sufficient, but I hope so. There are still several implications and other things that needs to be worked out, and it would be very interesting also to listen to other opinions. * Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080 * Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden -----Original Message----- From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] Sent: Sunday, December 07, 2003 10:26 PM To: ebXML BP Subject: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform] Lars, after reviewing the slides, the note and thinking about the learning session and teleconference discussions, there are several items that we should perhaps address, and talk about in the context of BPSS: * Late binding on the BPSS o Specifying the timeToPerform to the greatest time possible in the context of this type of collaboration [1] + Allowing late binding to accommodate logical business document requirements + Specifying when the late binding may occ * Potential to override BPSS attributes in the CPP/A between the parties [2] [3] * Breaking the response into multiple responses: where more timing applies to specific requirements (such as delivery) or either from the perspective of the requestor or the responder [4] I encourage the team to think about these items in the context of roles/partners, timeToPerform, and the dynamic aspects of late binding we discussed last week. [5] [1] May likely not be as tight you would like given the interactions defined by internal systems to support. Which brings up an interesting point on being able to keep these systems loosely coupled. For example, we have one case where the order may go by alternate means and not logged in the B2B system, and this really complicates this company's processing. We have to account for that at the process level. [1] Determine if this could meet your needs: See Section 9 of CPP/A document. [3] May complement any late binding functionality if adopted. [4] This may be driven either by business or service level agreements, or on a case by case basis. For the latter, I would think we will have to discuss the per-instance impact and its appropriateness. [5] Related Work Items 23, 25, 28, 46 and 55. -------- Original Message -------- Subject: "Late Binding" of TimeToPerform Date: Wed, 03 Dec 2003 03:21:23 +0100 From: Lars.Abrell@teliasonera.com To: Monica.Martin@Sun.COM Monica, During our use of BPSS we have in different situations noticed a need for different values in the TimeToPerform attribute for the same Binary Collaboration. This specific use case is based on the BC:NegotiateOrder in the NeBI specification (www.nebi.biz). Please see the attached slides. This very simple use case for ordering different "Field Service Products" in the telecom industry is based on using only the BTA:OrderRequestByBuyer and the BTA:OrderAcknowledgmentBySupplier in the BC:NegotiateOrder. This simple version of the BC:NegotiateOrder is used for ordering different products using the same generic BusinessDocument (BD:Order). In the product specific part of this BD:Order (i.e, in the order rows) the different "Field Service Products" are specified. Depending on the different "Field Service Products" (or combinations of "Field Service Products") in a BD:Order or different "time to delivery" of the specified product, there is a need also to have different values in the TimeToPerform attribute of the BC:NegotiateOrder. Feel free to use this in any way you think is appropriate <<TimeToPerform.ppt>> Regards //Lars Lars Abrell, TeliaSonera
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]