OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Requirement: UMM Transaction Patterns


 

Requirement Type: Use Cases

Requirement Name: UMM Transaction Patterns (UMM_MetaModel: Foundation_Module 1.0, 2006).

Requirement Rationale: these patterns are the result of UN/CEFACT abstraction work on a large number of message business transactions. Covering their monitoring and testing will guarantee a broad coverage of real world transactions, while concentrating efforts on a few patterns only.

 

 

The business transaction type determines a corresponding business transaction pattern. A business transaction pattern provides a language and grammar for constructing business transactions. The business transaction type follows one of the following six property-value conventions:

(1) Commercial Transaction - used to model the “offer and acceptance” business transaction process that results in a residual obligation between both parties to fulfill the terms of the contract

(2) Query/Response – used to query for information that a responding partner already has e.g. against a fixed data set that resides in a database

(3) Request/Response - used for business contracts when an initiating partner requests information that a responding partner already has and when the request for business information requires a complex interdependent set of results

(4) Request/Confirm - used if an initiating partner asks for information that requires only confirmation with respect to previously established contracts or with respect to a responding partner’s business rules

(5) Information Distribution - used to model an informal information exchange business transaction that therefore has no non-repudiation requirements

(6) Notification - used to model a formal information exchange business transaction that therefore has non-repudiation requirements

 

Some of the parameters of these transactions:

 

BusinessAction:

 

- isAuthorizationRequired

 - isNonRepudiationRequired

- isNonRepudiationReceiptRequired

 - timeToAcknowledgeReceipt

- timeToAcknowledgeAcceptance

- isIntelligibleCheckRequired

 

RequestingActivity:

 

-          timeToRespond

-          retryCount



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]