210 likes | 324 Views
ECIMF Business Context Interoperability. Andrzej Bialecki ECIMF Project Chair <ab@getopt.org>. جظ غئؤةض. 5000 €/pcs. Interoperability challenge. ECIMF Interoperability Framework. Business context. Semantics. Different business cultures
E N D
ECIMF Business ContextInteroperability Andrzej Bialecki ECIMF Project Chair <ab@getopt.org>
جظغئؤةض 5000€/pcs. Interoperability challenge ECIMF Interoperability Framework Business context Semantics • Different business cultures • Different industry sectors, geographical regions, laws, user communities, corporate cultures, etc… • Different technical frameworks • Different business processes, e-commerce standards, implementations, integration to back-office systems, etc… • Standards help, sure – there are just too many of them… • Fragmented standards help only small user groups, creating large integration costs for the rest of the world • ECIMF meta-framework addresses these concerns Business processes Syntax
ECIMF Business Context Business Infrastructures • ECIMF Interoperability Model • Interop. of technical infrastructures • Interop. of business infrastructures • ECIMF Business Context Modeling • Captures economic aspects, based on REA • Resources: what is traded • Events: when and how it happens • Agents: who is involved • Agreements & Commitments: legal aspects, transactional nature • Value-chain view of commerce • Chain of business processes • Flow of resources between processes Business context Semantics Business processes Syntax Technical Infrastructures • Important for interoperability • Economic goals, business rules and legal obligations ultimately define the meaning and consequences of information exchange
ECIMF – eBTWG coordination • Informal process (email discussions) • Started from the common use of REA framework • Initial ECIMF adoption of REA and UMM • ebXML use of UMM Economic Elements (based on simplified REA)
REA Enterprise Modeling custody linkage association reserves stock-flow Economic Resource Type Economic Commitment/Event Type Economic Commitment/Event Type Economic Agent Type participation • Economic exchange as a central concept • Recently extended to provide a comprehensive meta-model • Originally used non-standard modeling notation (now uses UML) dual executes reciprocal description Knowledge Infrastructure “the type of resources an agent can provide…” typification Operational Infrastructure Commitment reciprocal Commitment reserves participation executes executes Economic Resource stock-flow Economic Event dual Economic Event participation Economic Agent custody linkage association
REA Enterprise Script labor cars other processes Return Car Update Files • Enterprise script is a series of processes, consisting of exchanges realized with recipes (ordered tasks) Check-out Car Rental Agent Customer Find Car & Keys Rental Car Rental Recipe GIVE Rental Exchange Revenue Process Assess Insurance & Credit stock-flows TAKE Fill in Contract CashRcpt Cash Check car File & Choose Assess Customer Customer Cashier cash used cars Processes Exchanges Recipes (tasks, ordering)
reserves governs role resultsIn Collaboration resultsIn UMM Business Requirements View* classifies Economic Resource Type Economic Commitment/Event Type Partner Type Agreement participation • Slightly different, but compatible with REA • More focused on technical than human aspects • Provides clear connection with the dynamic aspects • Uses standard UML diagrams establish classifies reciprocity Commitment fulfills Economic Resource resource-flow Economic Event Economic Agent duality * simplified, v. N090.R8.x
ebXML Economic Modeling Elements • Closely followed a subset of UMM-BRV • Non-normative and disconnected • Status of “Technical report” • No explicit influence on the BPSS or CPP/CPA formation • BUT: Very useful worksheets in bpWS • Useful for better understanding of the influence of economic aspects
eBTWG: BOTL and BCP/MC work • e-Business Transitionary Working Group • Continuation of ebXML (excluding TRP) • Business Information Object Types team • Business Collaboration Patterns and Monitored Commitments team
Business Object Types Core Components CC, BIE, ABIE, BOT… • BOTs consist of: • context-modified CCs • business semantics • state model (and current state) expression BOT Identity BOT Aggregate BIE Aggregate CC expression BOT Business Semantic Basic BIE Basic CC expression BOT Content expression BOT Lifecycle BOT State context dependent context independent Context and Requirements
BOTS, Commitments & Collaborations BusinessCommitmentPattern Specifies the reciprocal business commitments Uses collaboration to describe commitment execution BusinessCollaborationPattern Specifies the orchestration of business partner actions • Commitments, collaborations and processes use BOTs: • BOTs help to represent the state of all BIEs processed by each partner, in the appropriate business context Uses states to define transition conditions Uses states to define success and failure Uses process to define interactions BusinessObjectTypes Specifies the computation of named business states BusinessProcesses Specifies the interactions between business partners Uses states to define transaction success and failure
ECIMF Business Context with BOTs • Definition of Business Context: Business Context is a collection of: • Agreements / Contracts defining the Commitments • Collaboration Patterns (using Business Processes) to execute commitments • Business Objects with their semantics, lifecycle and state, which encapsulate business data and business rules • Main concepts: • Based on REA • Incorporates BOTs • Defines the relationship of Business Context to Processes and Semantics layers in the ECIMF model
Interoperability: different Business Contexts • What is required in traditional business? • Both partners need to agree on: • The type of resources exchanged • The timing (event sequences/dependencies) • The persons/organizations/roles involved • Each of the partners needs to follow the commitments under legal consequences • Business Context models need to be equivalent • Partners need to play complementary roles • Expected resources need to be equivalent • Timing constraints need to be mutually satisfiable • The sequence and dependencies between events need to be the same, even though the individual interactions may differ • Transaction boundaries need to be preserved • Especially those, which cause legal consequences • Both parties need to receive business data that is mandatory and sufficient to satisfy their internal processes
Applying Business Context models • Business Context Models help to understand business-related constraints in integration scenarios: • Economic exchange view • Events sequence constraints • Stock management constraints • Legal constraints • Business process view • High-level transaction boundaries • Relationship to business activities • Relationship to business documents • All above aspects will limit the degrees of freedom in other integration layers
Example Business Context models Customer’s view Shipping Agent’s view • Example taken from ECIMF-POC document • see complete detailed analysis there • These two models match - “let’s have a deal!”
Tx 2 Tx 1 Example: a Business Context model Rental Agent GIVE «Agent» RentalAgent • Customer and RentalAgent follow the same collaboration protocol • Customer, RentalAgent and Cashier execute commitments according to the Contract • Rental occurs first, and then CashReceipt (within time constraints) • The transaction boundaries are related to Events (and legal constraints) collaboration Assess Customer Needs role custody Update Files 1 «Event» Rental stock-flow «Resource» Car Return Car role Check Car file & Choose Customer «Agent» Customer takes Collaboration (Business interface tasks) Check Out Car gives Assess Insurance & Credit «Event» CashRcpt «Resource» Cash Find Car & Provide Keys 2 Fill in Contract collaboration «Agent» Cashier TAKE
Example: Application of the models • Business Context Equivalence: • Both partners play complementary roles • Both partners expect first Rental, then CashRcpt • They still need to agree on the exact timing! • The collaboration tasks have to be grouped into 2 transactions, which correspond to Events • Both agreed to the type of Car and amount of Cash • Conclusions from the Business Context model example: • The assessment of needs doesn’t cause any Events • I.e. the Customer can repeat this step as many times as he wants without any legal obligations on either side • The success of Return Car should depend on success of tasks related to CashRcpt • This collaboration (Customer - Cashier) should be recorded in another activity diagram
SecureFlow Process Mediator Customer Shipping REQUOTE QuoteReq (RNIF) Agency (EDI) SecureFlow QUOTES QuoteConfirm Transaction Transaction Transaction Transaction Transaction Transaction boundaries boundaries boundaries boundaries boundaries boundaries SecureFlow ORDERS (also legal) (also legal) (also legal) POReq (also legal) (also legal) (also legal) SecureFlow ORDRSP POConfirm SecureFlow INVOIC Payment Invoice ? REMADV SecureFlow ? RemAdv APERAK ? CONTRL Business Context & Business Processes • Business Context determines the business-related constraints, e.g.: • timeouts • compensation needed for failed transactions • relationships between several business processes • etc. • These constraints cannot (easily/at all) be explained at the technical level
BOT BOT BOT BOT BOT BOT SecureFlow Process Mediator Customer Shipping REQUOTE QuoteReq (RNIF) Agency (EDI) SecureFlow QUOTES QuoteConfirm Transaction Transaction Transaction Transaction Transaction Transaction boundaries boundaries boundaries boundaries boundaries boundaries SecureFlow ORDERS (also legal) (also legal) (also legal) POReq (also legal) (also legal) (also legal) SecureFlow ORDRSP POConfirm SecureFlow INVOIC Payment Invoice ? REMADV SecureFlow ? RemAdv APERAK ? CONTRL BOTs and Process Mediation • BOTs explain requirements for specific business data • BOTs allow to follow the state of collaboration • BOTs explain how to adjust missing/superfluous data between partners, to cause desired state changes • Business Context + BOTs provides good indications how to implement process mediators / brokers
Summary • ECIMF Business Context concept ties together eBTWG CCs, BOTs, Collaborations and Commitments • eBTWG work on business modeling fits well with the 4-layer model of ECIMF, and provides a detailed view of each layer
Further information • ECIMF Project Information Center • http://www.ecimf.org • UN/CEFACT eBTWG • http://www.ebtwg.org