Contents (hide)
  1 Research
   1.1 How to specify constraints
   1.2 How to suggest errors
  2 Prosero (implementation)

Tokens (commitment)

Research

After identifying the Error Categories, we now realize how important tokens really are. Only errors related to tokens/commitments are errors that can be checked directly at the process level, without requiring the underlying levels to raise exceptions. We’re still not sure how to handle them in a generic way. They are closely related to pre/post conditions. It remains to be seen whether we can do more than ask the analyst to specify them explicitly.

TODO: How to model the tokens?

Tokens are hard because they are unlikely to be specified generically. Q: Can you define tokens for any DO.

Without real concrete examples, the intuition is that there are no generic tokens, unless we could find generic data objects and that they correspond to constraints on values.
For instance, constraint on address, on price, on dates etc.

TODO: Check UBL - BIE, ABIE, BBIE
UBL-CommonLibrary-2.0.xls
http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html

If that is the case, it seems that the support mechanism would work as follows:
  1. Analysts could specify constraints (on a data-object)
  2. The system would automatically provide suggestions for error path due to constraint violation, anywhere else the same data=object appears.

How to specify constraints

This is a main issue. It is closely related to the data model.

Data (in general) has the following meta-data:

  • Holder - what holds the data currently.
  • Origin - from where did the data come.
  • Time - since when the 'Holder' holds the data
  • Commitment toke:
    • commitment conditions:
      • time - data is valid only from time1 to time2.
      • misc - using condional expreession. Example 1. data is valid if current-data = data-time + X. Exmaple 2: Data is valid only if Holder has a MasterCard.

By the way, obviously the data plus its meta-field is a new data on its own. But the meta-data is given by our system and therefore is of no interest to us. But it could lead to an nice philosophical discussion :).

Note - In UBL-common-library, Cataloge Line has a "LineValidityPeriod" field.

Should the commitment be applied to Data-Object anywhere?

It could. There is no real harm. But when data is passed from local-service to a local-service, we can usually trust our own services. We would say its the external services that we don't trust. So, the act of saving the commitment token of a data-object should take place only for the Receive activity.

How would the commitment notation look in BPeMN diagram?

Step 0) No Commitment

Step 1) Use BPMN annotaion element with XPath identifier.
Link to the Data-Object an Annotation with either of the following texts:
@save-commitment {activity:InvoiveRquest} Invoice[2]/InvoiceLine[ID=3463]/Price
@check-commitment {activity:InvoiveRquest} Invoice[2]/InvoiceLine[ID=3463]/Price ; Bill[0]/LineItem[ID=443]/Price

Step 2) @check-commitment will not be needed if we can identify a data-element without a XPath. For example, by a name. And the service will look for all saved identifiers in all recieved Data-Objects.

Step 3) Replace the XPath with a form

How to suggest errors

This is a minor issue.

Options:
  • 1 per constraint violation
  • 1 for any constraint violation followed by a decision node

Tokens require support at 3 levels:
  1. Token definition. Three fields: data-object selection, constraint, expiry. For example: 
    select field::product-price
from data-object
when data-object-id = 76534 and field::product-name = "PC"

Expiry - 30 days
  2. Error detection. Detecting that a possible constraint violation is relevant. E.g., when we receive the invoice, an exception is raised if its price is different.
  3. Error handling at run-time. Requires appropriate translation into BPEL (i.e., identifying the error in run-time).

Prosero (implementation)

TODO: How to integrate the tokens?