• Templates

Contents (show)

Contents (hide)   1 Research    1.1 Query    1.2 Verify-Approve    1.3 Notification    1.4 Update-Approve (Synchronous)    1.5 Update-Approve (Asynchronous)   2 Prosero (implementation)

Templates

A template is a specific instance of the Receive-Process-Reply building-block.

There is no concrete distinction between a template and building-block.

Research

Query

Description

A query is received. The query does not require the update of the local state, except possibly for logging the fact that it was received and responded to.

1. Receive query
2. Process query
3. Respond with answer

Possible exceptions

• respond failure
• process time-out
• unauthorized query

Possible parameters

• security
• authentication
• synchronous/asynchronous

Possible variations

• Binding query, where the response is binding to the agent. May require non-repudiation and more involved logging.
• Asynchronous.

Compensation routines

• Undo logging – can also be noop.

Examples of concrete processes covered by this pattern

• inventory check
• delivery time check
• RFQ when item is in catalog

Verify-Approve

Description

This pattern covers the case where we receive a document that contains data that we need to approve. We check it against our records and if it matches our records we send a confirmation and we update our records, if needed, with the fact that we received this document and approved it (assuming we did). If it does not match, we send a disapproval message. Ideally, it should explain the problem.

1. Receive Document for verification
2. Compare against records
3. If matches records
   1. Send approval
   2. Update approval
   Else
   1. Send disapproval
4. End

Possible exceptions

• Unauthorized/incorrect message
• Send failure
• Compare timeout/failure (due to technical problems; does not imply document is incorrect)

Compensation routines

• Undo update

Possible parameters

• Security
• authentication
• synchronous/asynchronous

Possible variants

• verifyApproveList where the document is a list of items and we allow for partial approval, i.e., where some items are approved and some are not.
• VerifyApproveAmendment where the document is an amendment to a previously approved document. It seems like this only affects the specifics of the verify process.

Examples of concrete processes covered by this pattern

remittance advice, and arguably (see next pattern), receive purchase order, receive supply schedule, purchase order amendment, delivery plan change, receive invoice, self-billing invoice, etc.

Notification

Description

This pattern covers the case where we receive a document that contains data that requires us to update some information, but does not require further processing. This is a notification, and we cannot disapprove.

1. Receive Document for update
2. Perform update

Possible exceptions

• Unauthorized notification
• Incorrectly syntax
• Update time-out

Compensation routines

• Undo update

Examples of concrete processes covered by this pattern

• notification of shipment time
• notification of price change for a catalog

Update-Approve (Synchronous)

Description

Much like Verify-Approve, but where the message requires an update to our state. It is not clear whether for our purpose we need a distinct pattern here. Intuitively, the main issue is whether the update has additional ramifications.

1. Receive Document for update
2. Evaluate update
3. If acceptable
   1. Send approval
   2. Update
   Else
   1. Send disapproval
   2. Log disapproval if needed
4. End

Possible exceptions

• Unauthorized update request
• Improper syntax of update request
• Send failure
• Update failure (different from disapproval)

Compensation routines

• Undo update

Possible parameters

• Security
• authentication
• synchronous/asynchronous

Possible variants

Again, the case of the document being a list of items such that items may be processed independently and some may succeed and some may fail (e.g., in/out-of stock).

Examples of concrete processes covered by this pattern

• receive purchase order
• cancel purchase order
• amend purchase order
• receive delivery plan

Update-Approve (Asynchronous)

Description

This is similar to the previous patterns in that it based on receive/process/send. However, the process request in this case is long, requiring the spawning of a subprocess that will take sometime to complete. Therefore, the process is more involved. First, we have to notify the sender that we are handling his message. Then we have to spawn the sub-process. Then we have to wait for its completion and when it is done, we can respond to the sender. We assume that the process requires state update.

1. Receive Document for update
2. Commence Evaluate update
3. Send “evaluation commencement”
4. Wait for EvaluateResult message
5. If acceptable
   1. Send approval
   2. Update
   Else
   1. Send disapproval
   2. Log disapproval if needed
6. End

Possible exceptions

• Unauthorized update request
• Improper syntax of update request
• Send failure x 2
• Evaluate failure due to time out or other non-business condition

Compensation routines

• Undo update locally
• Compensate for spawned process

Possible parameters

• security
• authentication
• synchronous/asynchronous

Possible variants

Again, the case of the document being a list of items such that items may be processed independently and some may succeed and some may fail (e.g., in/out-of stock). There is an asynchronous variant to verify as well, as noted earlier that is similar.

Examples of concrete processes covered by this pattern

• receive purchase order
• cancel purchase order
• amend purchase order
• receive delivery plan

Prosero (implementation)

Using the building blocks to create the templates will look like this: