Business Rules and Constraints for CPP / CPA

(very preliminary draft!)

Tony Weida

04/21/23 11:06 AM

Copyright © 2001 Edifecs

Observation Agreed behavior may depend on runtime

context

Context Dependency Runtime Context

• Document content- Geography, type of product, amount of money, …

• Prior history of the collaboration• Calendar and clock …

Dependent behavior• Allowable requests and responses• Timing of requests and responses• Choice of delivery channel …

Requirements Capture important business rules and

constraints for CPPs / CPAs that can’t be expressed (directly) via DTD or XSD• Specify (restrict) constraints according to

possible runtime context

Thus achieve context dependent validation and control of a B2BI system’s runtime operation

Business Constraints Logical assertions Required to be true Example

timeToAcknowledgeReceipt < timeToAcknowledgeAcceptance < timeToRespond

Rule Example

IF location = Scottsdale & month = July THEN temperature = hot

Chunk of inferential knowledge Typically binary

• if then• condition action• antecedent consequent• LHS RHS

Business Rules Triggered by events

• Ex: arrival or transmission of a message May be grouped into “rule sets”

• Encapsulate related rules• Activate / deactivate rule sets en masse

An event handling strategy1. Assert event2. Recognize situation (via one rule set)3. Act (via one of several alternative rule sets)

Some very informal examples …

Business Rules on Messaging IF DocType = PO and Region = Asia THEN use DeliveryChannel2

Business Rules on Performance IF DocType = PO and Amount < $10K THEN timeToRespond = 24 hours

IF TOD > 9am and TOD < 3pm THEN timeToRespond = 2 hours

Business Rules on Calendar IF cpaEndDate < today + 7 days THEN

Business Rules on Content Constrain document content at runtime Impact beyond middleware!

• Backend systems expected to conform• Rules can validate their behavior

Incoming • IF RequestDocType = PO and Product = gorp THEN business response = accept PO

Outgoing • IF RequestDocType = PO and amount < $1000 THEN payment method = credit-card

Key Issues How are the rules expressed? Where do the rules go? How does a CPP/CPA reference the rules? How do the rules reference the context? How do the rules constrain behavior?

Business Rule Mechanisms Existing technology

• XSLT• Schematron• Some other schema language• RuleML

Custom notation

XSLT Evaluation Pros

• XML syntax• Operates on XML documents• Powerful• Standard• Widely supported

Cons• Complex• External to CPP / CPA (maintained in tandem)

Schematron Evaluation Pros

• XML syntax • Operates on XML documents• Fairly powerful• Likely to persist

- Basically a few XSLT/XPATH stylesheets

• Internal and / or external to CPP / CPA Cons

• Not standard• Possibly limited support

RuleML Evaluation Pros

• XML syntax• Powerful, with formal basis

Cons• Doesn’t (specifically) operate on XML

documents• Standardization uncertain

Business Rules (in TP context) Observations

• CPP / CPA now limited to what middleware can enforce• CPP / CPA has no business content (except BPSS refs)• Collaboration protocol specs have business content• Business rules apply to business information

- Reference CPP/CPA and specification schema

Relevant goals• Modularity• B2BI vendor neutrality (some may support only basic CPA)

Possible conclusion: Business Rules Profile / Agreement

Business Rules Agreement (BRA)*

TPA

CPA

BRA

Specification Schema 1

Specification Schema 3

Specification Schema 2

* May want another acronym

.

.

.

CPP/CPA Interaction with BRA Build time

• Both reference the same collaboration protocols

Run time• Via event assertions and rule firings (including

rule set activations)

Other Business Rules Usage(long term directions more geared to spontaneous commerce than

membership in preconceived communities) Rules to create an initial CPA proposal

from the other party’s CPP Rules to respond to another party’s CPA

proposal• Decide on accept vs. reject vs.

counterproposal• Rules to construct counterproposal