[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: BPEL Use Cases for Transaction handling service
Here is David’s contribution.
I will be folding these into the new Use Case templates along with the other
Use Cases we have already completed. Please let me know if you have any
questions. Thanks! John PS: Thanks especially to David for contributing
this work! From: David RR Webber
[mailto:david@drrw.info] John, As discussed. Sorry I did not get these done for
yesterdays meeting. Life intervened! Anyway - attached two HTML files describing these. Do these look OK? If so - next step I can submit them (or you can for me) to
the UC SC Kavi document system and we can get everyone's comments and thoughts. Once we have that honed - then we can proposed a BPEL / binding to implement this. Thanks, DW |
BPEL Use Case SC Use Case |
|||
UC ID: | IV-UC#1 | Priority (L/M/H) : | Medium |
Use Case : | eBusiness Transaction binding with external service - Validation | ||
Description : | An industry group needs to have a consistent way of documenting the information exchanges for the scenarios its
members are implementing. Further more implementers need a consistent way of ensuring compliance checking and testing.
Each individual participant needs a consistent way of applying context to their specific interchange transactions. This can be provided as an external service that a BPEL instance can invoke. BPEL itself has only limited transaction information management tools. Therefore BPEL should be able to receive a document transaction and then pass that XML content to an external service, along with binding information around the type of content and context details so that the external service can perform that validation. Included in the external service is the ability to report back to BPEL, and or, invoke external process step(s) that may then manage the results of the validation. The OASIS CAM TC team has created a specification and toolset that can act as an external service in this way. A WSDL definition of a CAM process can provide the linkage between the CAM process and the BPEL. The BPEL will need to package the XML content that requires validation and pass that to the CAM process. The CAM process will return to the BPEL process the outcome from the external validation service. |
||
Actors : | Trading partners wishing to exchange business transactions, implementers wishing to do industry conformance testing. | ||
Pre-Conditions: | XML content and associated CAM template of rules to be validated and applied. Where applicable a context template that defines the localization parameters and their settings to be applied during the validation. | Post-Conditions: | Return to the BPEL process a result set indicating success or failure and if failure reporting of that. The CAM template may also contain mitigation actions for various error conditions that may be performed. |
Basic Flow : |
|
||
Alternate Flow : |
|
||
Exceptions : | none | ||
Includes Use Cases: | none | Special Requirements: | None |
Assumptions: |
|
||
Use Case Relationships: | None | Issues : | none |
Examples: | Automotive industry IV&I compliance tests for the 4 supply chain inventory on-hand transactions they are implementing. | ||
proposer david@drrw.info |
Title: BPEL IV&I UC #2
BPEL Use Case SC Use Case |
|||
UC ID: | IV-UC-#2 | Priority (L/M/H) : | Medium |
Use Case : | eBusiness Transaction binding with external service - Transaction Assembly | ||
Description : | An industry group needs to have a consistent way of documenting the information exchanges for the scenarios its
members are implementing. Further more implementers need a consistent way of ensuring transaction content is assembled
according to the industry definitions of those transactions. Each individual participant needs a consistent way
of apply context to their specific interchange transaction assembly. This can be provided as an external service that a BPEL instance can invoke. BPEL itself has only limited transaction information management tools. Therefore BPEL should be able to receive information that is required to compose a document transaction and then pass that XML content to an external service, along with binding information around the type of content and context details so that the external service can perform that transaction assembly. Included in the external service is the ability to return back to BPEL the completed transaction, or dispatch it via a messaging service itself. The results of the assembly may also be returned as a success/failure report. The OASIS CAM TC team has created a specification and toolset that can act as an external service in this way. A WSDL definition of a CAM process can provide the linkage between the CAM process and the BPEL. The BPEL will need to package the XML content that requires assembly and pass that to the CAM process as an XML structure. That structure may resemble the final transaction content structure, but does not have to exactly match it. The CAM process will assemble the information into the exact structure layout and details in XML that are specifically required. CAM has an extensive set of functions that permit manipulation of data strings and content formatting. The CAM process will return to the BPEL process the outcome from the external assembly service, along with either a completed transaction document, or a delivery result status. |
||
Actors : | Trading partners wishing to exchange business transactions, implementers wishing to define industry transaction formats for members use. | ||
Pre-Conditions: | XML content and associated CAM template of rules for transaction assembly to be applied. Where applicable a context template that defines the localization parameters and their settings to be applied during the transaction assembly. | Post-Conditions: | Return to the BPEL process a result set indicating success or failure and if failure reporting of that. Optionally return to the BPEL process a completed and valid transaction document. The CAM template may also contain delivery instructions for the transaction content itself. |
Basic Flow : |
|
||
Alternate Flow : |
|
||
Exceptions : | none | ||
Includes Use Cases: | none | Special Requirements: | None |
Assumptions: |
|
||
Use Case Relationships: | None | Issues : | none |
Examples: | Automotive industry IV&I transaction formats for the 4 supply chain inventory on-hand transactions they are implementing. | ||
proposer david@drrw.info |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]