kwchiu@acm.org, dicksonchiu@ieee.org
{scc, till}@cs.ust.hk
1





 e-service - service provided over the Internet adoption of e-services for B2B process collaboration need for a more in depth study
 not just “regular” process enactment – basic knowledge
 requirement engineering beyond basic enactment is almost unexplored
Enforcement


Exception detection – how do you know what is happening inside your partners’ organization?
Exception handling – how deviations can be controlled or compensated
Business relationship management

 quality collaboration need to do extra things
 process “transparency” eService Collaboration-2







My PhD thesis research on exceptions in WFMS
D.K.W. Chiu, Q. Li and K. Karlapalem. A Meta Modeling Approach for
Workflow Management System Supporting Exception Handling. Information
Systems , 24(2):159-184, 1999.
D.K.W. Chiu, Q. Li and K. Karlapalem. Web Interface-Driven Cooperative
Exception Handling in ADOME Workflow Management System. Information
Systems , 26(2):93-120, 2001.
Extension to cross-organization workflows


D.K.W. Chiu, K. Karlapalem, Q. Li and E. Kafeza. Workflow Views Based E-
Contracts in a Cross-Organization E-Service Environment. Distributed and
Parallel Databases , 12(2-3):193-216, 2002.
CRM
D.K.W. Chiu, et al. An Event Driven Approach to Customer Relationship
Management in an e-Brokerage Environment. HICSS36, IEEE Computer
Society Press, Jan 2003.

Conference Paper
D.K.W. Chiu, S.C. Cheung, and S. Till. An Architecture for E-Contract
Enforcement in an E-service Environment. HICSS36 best paper nomination.
eService Collaboration-3





 a methodology to structure B2B process collaboration in multiple layers and multiple perspectives


Conceptual models expressed in UML life cycle similar to that of a software system, i.e., definition, analysis, and realization a more thorough understanding of B2B process collaboration from its fundamentals to system design a methodology is presented for the engineering of e-service process collaboration from high-level business requirements down to system design details a system architecture and feasible implementation outline with
Enterprise Java Bean (EJB) and Web services evaluate our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers eService Collaboration-4

Contract
Enactment
Business
Information
Exchange
Contract
Negotiation
Contract
Enforcement





Based on business experience and requirements, contract templates
(with variables) are abstracted from previous contracts
A contract template is modeled as an e-Contract template
Each successful e-Negotiation will lead to an e-Contract
Enforcement and enactment are executed differently and in parallel
CRM should be anywhere anytime … eService Collaboration-5

End-User
Begin
Begin
En qu iry
Quotation
Enquiry
Check
Parts Info
Quotation
Evaluation
Purchase
Order
R e qu e
S u p st
E xt ra
In p ly
E xtr a fo
I nf o
Prepare
Quotation
Prepare
Extra Info
O rd er
Check &
Receive
System
Service
Preparation
Payment
Authorization
Deliver &
Install
P a ym e n t
End
End
System Integrator
E n q u ir y
Parts Vendor
Begin
U p d a te d
P a rts
I n fo
Service Preparation Sub-process
Begin
O rd er
w pa ym ith en t
De liv er y
Deliver
Parts
Order
Missing
Parts
End
Assemble
System
Install
Software
System
Testing
End
Parts
Quotation
Can this show anything beyond regular process execution enforcement and relationship management?
eService Collaboration-6







End user notify system integrator: changes in delivery requirements or payment arrangement -
System integrator notify end user - changes in delivery date
When a vendor changes the lead-time but the delivery schedule can still be met within the end user’s deadline, the change can be tolerated.
The system integrator should present a revised delivery schedule to the end user according to the parts vendor’s reported leadtime.
When a certain part is stopped from production, the system integrator request the end user’s approval of using an alternative part.
When there is a significant aggregated price change in parts during the end user’s evaluation, a revised quotation (price) is sent to the end user through an event-triggering mechanism.
Most of the above are related to exception handling… eService Collaboration-7






Recognition (monitoring) and handling of contract breaches
Enforcement and enactment are handled differently
(enactment deals with regular activities)
Compliance of a contract has to be kept under constant surveillance
Monitoring of variables – states of the business process
Challenges

 constantly checking validity of all these variables incurs tremendous overheads extended across organizational boundaries
 may include confidential information, e.g., bank accounts eService Collaboration-8




Any involved organization wants to be able to inquire the progress of business processes at other business partners’ side such as order processing, payment.
A service provider wants to relay relevant information to business partners from other sources or upon enquiry, such as technical information, drivers update, product news.
Effective measures for handling complaints and feedbacks from business partners are essential to help rescue threatened relationship and reduce attrition.
eService Collaboration-9

Enactment
Requirements
Enforcement
Requirements
Relationship Management
Requirements
Workflow
Processes
Enforcement
Policies
Relationship
Policies
ECA Rules
Enterprise
JavaBeans
Web Services
Collaboration
Requirements
Business Rules
System Design eService Collaboration-10

Layer
Collaboration requirements
Perspective
Users, managers,
Analysts
Business rules Analysts
System design Analysts &
Programmers
Artifacts

Meta-model for B2B Collaboration:

Enactment requirements (Workflow Processes)

Enforcement requirements (Enforcement Polices)

Relationship management requirements (Relationship
Management Polices)

Parties and Roles

Meta-model for process enactment and exception handling:
Business events, Business rules, Business actions and
Business entities

Task system design (Enterprise JavaBeans components)

Process system design (BPEL or workflow engine)

Cross-organizational interface (Web Services XML schemas) eService Collaboration-11

Obligation Permission Prohibition
Enforcement
Requirement
* specifies
1
Relationship Mgmt
Requirement
*
Enforcement
Policy
* realizes
1..*
Collaboration
Requirement
1 specifies realizes
1..*
*
Relationship Mgmt
Policy
Business
Rule
1..* realizes
*
Enactment
Requirement specifies
1
*
Workflow
Process
Business
Event
Exception
Temporal
Event
Event
*
*
Condition
Action
*
*
+subscriber performs
* 1
+publisher
Business
Party
1 aggregation inheritance eService Collaboration-12







Motivated by the active database paradigm
Event - occurrence of something interesting to the system itself or to user applications
Event driven execution of rules in event-condition-action (ECA) form
ECA (active) rules: On event if condition then action
Exceptions and alerts are events too ( action = handler)
Ensure efficiency and timeliness - monitor becomes only active when an interesting event occurs
Database
Other
Collaboration
Parties
Requirement
Enforcer
ECA rules
Event Repository
Event Subscribers List
Business Entities
Event Adapter
Collaboration Process
Enactor
Internet
Timer
Event Web Service Interface
A Party as an e-Service
Provider eService Collaboration-13









Event-driven workflow execution model (that is, ECA rule based)
Business partners have to trigger the corresponding start-events
(say, quotation enquiry) to start B2B process collaboration.
If the process is a composite one, the will raise a start-event collaboration process enactor for the first sub-process
This will continue recursively downward the composition hierarchy until a leaf sub-process or
The initiate it.
task.
collaboration process enactor sends a start-event to the task to
After the task is finished successfully, the task replies to the collaboration process enactor by raising a finish-event with the results (if any).
The collaboration process enactor be raised accordingly. then carries on with the next step according to the returned result.
Upon failures or timeouts, an appropriate exception event will also eService Collaboration-14




eService Collaboration-15




Improvement from deontic logic – well-defined execution semantics and when to execute
BAO stands for an object that encapsulates a business action whose execution triggers the object creation
Case study – “Terms and Conditions of Sale, Service and Technical
Support”, Dell, Hong Kong http://www.ap.dell.com/ap/hk/en/gen/local/legal_terms.htm
Clause type
Obligation
(Shall …)
Prohibition
( Shall not … )
Permission
(may …)
Event onDay(deadline
(BAO ) )
Condition
NOT occurred( BAO )
Action onOccurred( BAO) prohibitionCondition( BAO ) raise( exception(
BAO ) )
NOT permitted( BAO ) eService Collaboration-16

E: onDay( deadline( BAO ) )
C: NOT occurred( BAO )
A: raise( exception( BAO ) )



Upon reaching the deadline
Timer
T obl
, a temporal event is generated by the
Contract enforcer (of counter party of the action) check if the obliged party has performed the required business action A obl
, searching the log file for invoked actions / occurrence of related events
If the obligation has not been fulfilled, the exception contract enforcer raises an eService Collaboration-17


7.1 Dell shall deliver the Products to the place of delivery designated by Customer and agreed to by Dell as evidenced in
Customer’s invoice (“Place of Delivery”)
Enforcement rule (Customer) Enactment rule (DELL)
E: onDay( deadline( DELIVER ) )
C: NOT occurred( DELIVER )
A: raise( exception( DELIVER ) )
E: onDay( before( deadline( DELIVER ), 6 ) )
C: valid( place( DELIVER ) ) & ready( DELIVER )
A: perform( DELIVER )


10.7 …Dell shall respond to a request for such Emergency Service as soon as practicable after its receipt of such request.
Analyst has to clarify and substitute ambiguities with concrete deadline in the formulation
E: onDay( after( receiptDate( EMERGENCY_REQUEST ), N ) ) )
C: NOT responded( EMERGENCY_REQUEST ) )
A: raise( exception( EMERGENCY_REQUEST ) eService Collaboration-18

Enforcement rule form
E: onOccurred( BAO )
C: NOT permitted( BOA )
A: raise( exception( BAO ) )
Enforcement rule (Both Parties)
E: onOccurred( INFO )
C: confidential( INFO )
A: raise( exception( INFO ) )



The contract enforcer should treat an occurrence of a prohibited action as an exception.
Problem - observation of prohibitions

 if a party performs a prohibited action, the party will probably try to hide or distract this fact as long as possible unless the party does this by mistake or misunderstandings)
 autonomous nature of different organizations
Example - 14. Each party shall treat as confidential all information obtained from the other pursuant to a Contract which is marked
'confidential’ … eService Collaboration-19

Enforcement rule form
E: onOccurred( BAO )
C: prohibitionCondition( BAO )
A: raise( exception( BAO ) )
Enforcement rule example (Both Parties)
E: onOccurred( REFUSE_ORDER )
C: NOT badlisted( customer( REFUSE_ORDER ) )
A: raise( exception( REFUSE_ORDER ) )


Temporary allowance to perform an otherwise prohibited action

 within a certain allowed time period under certain situations (i.e., events plus conditions)
 otherwise exception
2.1 … Dell shall be entitled to refuse to accept orders placed by the Customer if the Customer breaches or Dell, on reasonable grounds, suspects that the Customer will breach this warranty … eService Collaboration-20

Enforcement rule form Enforcement rule example (Both Parties)
E: onOccurred( BAO ) E: onOccurred( LEVY )
C: prohibitionCondition( BAO )
A: raise( exception( BAO ) )



C: NOT ( dateOfCancellation( order( LEVY ) ) > dateOfManufacture ( order( LEVY ) ) & cancellationApproved( order( LEVY ) ) )
A: raise( exception( LEVY ) )
3.1 … If Dell allows a Customer to cancel its order after manufacture but before shipment of the Product, Dell shall be entitled to levy a cancellation charge equal to 20% of the price of the Products. …
Customer can hardly know the commencement of manufacture of the product - almost non-monitorable
Dell may improve the situation by informing the customer when the commencement starts through its enactment system. (CRM!) eService Collaboration-21





CRM help an organization to streamline customer services and maximize the value of customers
New in the B2B context – objectives:



 provision of quality service monitoring of collaborating processes better dissemination of information effective handling of complaints
Automation for CRM is even more essential for B2B
Approach





Concentrated on business rule designs for particularly for exceptions
Transform business rules from
Isolate the relevant events if-then asynchronous form to ECA form event driven record the objectives of each rule to determine its usefulness and hence its priority of implementation in a phased approach eService Collaboration-22






Often not explicitly enforced in a contract
But this should not just be optional
Do better than required or specified => competitive
Example, though some obliged actions may have a distant deadline, the management may decide to perform it as soon as feasible.
Example ECA-rule for quicker delivery



E: received (ORDER)
C: valid( place( DELIVER ) ) & ready( DELIVER )
A: perform( DELIVER ) eService Collaboration-23





Helps business partners to plan ahead and reduce uncertainties
Example: a customer can hardly tell whether the manufacture process of the product has already commenced when the order is cancelled


Improve the situation by informing the customer when the manufacturing process has commenced
Better than handling enquiries passively => reduce the need for human enquiries and thus operating costs.
Non-monitorable => monitorable
ECA rule example:



E: start (DELIVERY)
C: true
A: notify (customer (DELIVER)) eService Collaboration-24






Widely in practice for B2C relationship management.
Financial institutions often provide market information to their customers as extra services.
Facilitate the customer to make decision and in turn may help effective collaboration.
For example, system integrator forward vendor’s technical information or software updates to the relevant customers.



Prevent problems from occurring improves the service quality reduce the cost of support
Example ECA rule:



E: received (INFO)
C: relevant (INFO, customer)
A: notify (customer ( INFO) ) eService Collaboration-25





Avoids customer attrition
Help rescue threatened relationship
Complaints involve exception conditions
 need to be handled by appropriate the management manually trained personnel or even
 should be performed as soon as possible to reduce customer grievance
Example ECA rule:



E: received (COMPLAINT)
C: true
A: notify (handling_personnel (customer ( COMLAINT))) eService Collaboration-26





General measures to involves handle contract breaches or exception


 domain specific knowledge explicitly specified in other contract clauses implicitly regulated by laws and standards
Ambiguity and impreciseness of natural languages


 reference to other laws, regulations, standard trade practices parties involved should discuss and clarify the matter amend existing or forthcoming contracts accordingly
Autonomous nature of individual organizations



Required events might not be monitorable
Cooperation and trust - improves the transparency of operations
(CRM!)
Add explicit clauses in the contract to demand these events
Lack of e-services standards eService Collaboration-27

Counter Party
Web
Services event
Manager receive
Party receive
Web
Services
Manager
Database
Event Repository
Subscribers List
Security Policies publish event notify
Event
Adapter
NOTATIONS interface depend event subscription request request event event component subscribe subscribe request
 request
Event Adaptor – event publish-and-subscribe paradigm eService Collaboration-28




Publish Web service
 invoked by the event adaptor
 input parameter is the occurred event or exception
 checks the subscribers list and the security policies, and then notifies the valid subscribers (via e-mail, fax, ICQ message, or even via another Web service)
Subscribe Web service
 registers requests for an event subscription
 parameters: the requester, the subscribed event, and how the requester wants to receive the event notification
Receive Web service


 receive subscribed events published by the counter party received events are recorded at the Event Repository and forwarded to the Event Adapter in turn transforms them into the forms as required by the Contract
Enforcer and the Contract Enacter eService Collaboration-29

takeOrder Web Service
Input: OrderRequest

Buyer




Name
Address
E-Mail
ProductList


Product


Product ID
Product Name


Quantity
Price
Output: OrderResponse

OrderResult

OrderNr

Password
Estimated Delivery Date trackOrder Web Service
Input: OrderStatusRequest

OrderNr

Password
Output: OrderStatus

Progress


Estimated Delivery Date
Optional: DeliveryNr eService Collaboration-30





“Catch-all-exception” Web service

Precaution – unhandled exceptions forward to administrators
Each events / exceptions sub-class hierarchy as
Web service

Extra parameters / data
E.g., End User -> System Integrator

Cancel Order Request

Change Order Request


Change Delivery Date Request
Change Delivery Location Request


Delay Payment Request
Return Unsatisfied System Request
E.g., Part Vendor -> System Integrator

Price List Update



Price Update


New Parts Update
Part Recall Notification
Part Obsolescence Notification
Driver Update
Example Web Service
Name: ChangeOrderRequest
Input:

ChangeContractDataRequest





ChangeRequestID
Customer Id
OrderNumber
ToChangeContractData
OldValue


NewValue
ReasonOfChange
Output:


ChangeContractDataResponse

ChangeRequestID




Approved (Yes/No)
AuthorizedBy
AdditionalComment
ToChangeContractData
NewValue eService Collaboration-31




Possible because of automated receipt and sending of events
Efficient and effective knowledge dissemination
E.g., driver update:
 part vendor -> system integrator -> end user eService Collaboration-32




Name: GetProcessStatus
Input: ProcessStatusRequest


CustomerId
OrderNumber
Output: ProcessStatusResponse




CustomerID
OrderNumber
StatusReport (content depend on the customer, status, etc.)
ContactPersonInfo (for further information) eService Collaboration-33

User
General Concerns
Assist their work
Interoperability and connectivity
System / information availability
Convenience and ease of use
Management Cost vs. Benefit
Improve productivity
Scalability
Security
Reduction in total development cost
System
Developer
Communications cost
Development / Maintenance effort & cost
Requirement elicitation
Reusability
Scalability
Uncertainty in the use of new technologies
Overall system complexity
Integration with existing systems
Enactment
Workflow automation
Reliability – retries, search alternatives
Increase business opportunities
Convergence of disparate business functionalities
Phase approach that accommodate existing basic enactment information systems
Enforcement
Reduce tedious manual checking
Timeliness of services
Business process monitorability
Compliance to contracts / trade standard / regulations / laws
Exception and crisis management
Knowledge management
Event monitorability
Difficulties in programming captured knowledge
RM
Improved service call-center or web page
More transparent business processes
Improve customer relationships
Improved services
Knowledge management
Difficulties in programming captured knowledge eService Collaboration-34








A pragmatic three-layer architecture for B2B e-service process collaboration (collaboration requirement layer, business rule layer, and system design layer)
Support for enactment, enforcement, and relationship management
A meta-model for B2B collaboration based on a unified artifact of event-condition-action
A methodology for eliciting knowledge of collaboration requirements into business rules in ECA format
Typical problems that can be discovered by our methodology, together with some measures of overcoming them
A system architecture and feasible implementation outline with
Enterprise Java Bean (EJB) and Web services
Evaluation of our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers eService Collaboration-35

 Methodologies for breaches.
measures avoiding contract
 Process adaptation for interoperability with process views and event flows analysis – different partners have different interactions.
 Alerts – urgency in process integration (esp. healthcare)
 Application of this framework in other domains, particularly
B2B process enforcement (exceptions) and *CRM*
 Financial institutions, insurance, …
 e-tourism, e-government, e-learning, … eService Collaboration-36