Project A7 – Business Documents and Protocols Ulrike Greiner, SAP

ATHENA M36 Final Review 27.-29. March 2007 Madeira, Portugal Project A7 – Business Documents and Protocols Ulrike Greiner, SAP

Presentation Outline • Project Goals • Building on ATHENA results • Major Achievements • Fulfilment of Work Plan • Contributions to ATHENA • Impact Made

Project Goals • Analyse business document and protocol standards and relate it to industry best practice • Methods and tools for lifecycle management of business documents and protocols: • Creation of business documents and protocols • Ensuring consistencyand reuse • Differentmodellinglayers (business – technical – execution) • Support variants of business documents • Storage and retrieval of business documents and protocols • Mapping and transformation of business documents • Creation of business content using ATHENA tools for selected industry best practice Methods and tools for efficient and easy management of Business Documents and Protocols

Building on ATHENA Results • A2: • Modelling approach for cross-organisational business processes • CBP modelling and execution infrastructure • A5: • WSDL analyzer for mapping • Agent platform as execution platform for business protocols • Service execution infrastructure • A6: • P2P infrastructure for repository services • PIM4SOA as a basis for technical level business document and protocol models • PIM->PSM transformations between modelling levels • Semaphore transformation tool • A3: • Tools and methods for semantic annotation • Reconciliation rules specification and engine for business document reconciliation • A1:MPCE based repository interface

<xml>…</xml> Definition of Basic Terms • A business document is a set of information components that are interchanged as part of a business activity • Possible components are: • Information (data) • Meaning of that information (meta-data) • Presentation information (layout) • Links to other information components • Information in business documents can be of different types: • Structured: e.g. XML documents or databases • Unstructured: e.g. text files, Word documents, Emails, most Web pages • Semi-structured: Web pages with known fields of content (annotations) • Business protocol specifies how messages have to be exchanged between different parties participating in a CBP • Business process is a goal oriented, value creating sequence of activities • in a CBP these activities are executed by more than one enterprise

Major Achievements • Analysis of industry requirements and standards • Modelling of business documents on the technical level: • Supporting re-use and variant handling • Support for business level stakeholders • Implementation of DFDL standard for non-XML data • Automated Mapping Support: • Automated assistance to mapping business documents • Repository: • P2P-based repository for flexibly storing and retrieving business documents and protocols • Protocol support: • Transformation from PIM4SOA to agent metamodel • Transformation from business level CBPs to protocols • Application of A7 results to industry scenario

As-is Situation in ATHENA Scenarios • Questionnaires to gather information from ATHENA user partners about • As-is situation in their company regarding business documents and protocols • A7 specific requirements • Several shortcomings: • Standards are very complex • Implementation of standards is complicated, complex, and time-consuming • Lots of interaction needed between the partners until integration is achieved • ICT standards are difficult to use (no compliance certification) • Rhythm of evolution is too fast for industrial needs • robust and high quality standards are needed • Overlapping and incoherency in coverage of different view points (engineering, ICT, organization, information) • Framework to coherently compose standards to cover all necessary aspects is missing

Requirements from DRDS • Business document support should fulfil the following requirements: • Coherent documents are needed instead of loosely connected messages • Re-usability, Life cycle management • Guidance for filling of document • Support for multi-user access and multi-organization use of document • Automated processing of exchanged documents • Connection of business documents with Enterprise Modelling systems • Easy implementation of business document related systems • Business protocol support should fulfil the following requirements: • Monitoring and controlling of protocols • Enacting view processes, event notification, compliance with existing solution • Technical features of the protocol system, e.g. support of technical middleware below the protocol, reconciliation of messages and the detection of incoherent message content A7.2 A7.4 A7.3 A7.4 A7.2 A7.5 A7.4 A2 A7.4

Classification of Standards (BD & BP) Collaboration Agreement ebXML CPPA Impl. Guide Variant Problem Collaboration RosettaNet PIPs STEP EDI STAR OAGI WS-CDL Business Process / Service Def. ebXML BPSS WS-BPEL XPDL Information Def. RosettaNet Data Dictionary standard product attributes ebXML CCTS EDI STAR OAGI UML UBL Infrastructure Services W3C transport protocols (HTTP, SOAP, etc.) WSDL Discovery IEEE FIPA OGSA OGSI

Selected Standards • Detailed description and analysis of the following standards: • ebXML CCTS and CPPA • RosettaNet PIPs, data dictionary and schemas • STEP • Standard Product Attributes (DIN 4002) • OAGI • Schemas for non-XML documents: • DFDL / HIPAA (Health Insurance Portability and Accountability Act) • FIPA Agent Communication Language (ACL) • Further problems investigated in A7: • Variant problem

Modeling Requirements and Approach • Re-use of model types that are modeled once and can then be used in different document models • Model representation targeted at business experts • Graphical modeling support needed • Semi-automatic transformation to technical specification • e.g. through export functionality to create XML representations • Support for handling variants of business documents: • Share most of their data fields • Differ in a limited number of data fields that depend on the context in which the document is used • Example: a purchase order that differs slightly if used in different European countries • Concept of business context defines specific circumstances in which a document is used

Document Modeling with Variant Handling • Supports variant handling: • Business document template contains all possible fields • Fields of concrete document are determined by business context • Configuration procedure to support variant handling • Outer configuration: facilitates search for appropriate variant • e.g. through questionnaire or scenario-based • Inner configuration: fine-tuning of selected variant • Janiesch, C., Dreiling, A., Greiner, U., Lippe, S.: Configuring Processes and Business Components—An Integrated Approach to Enterprise Systems Collaboration. Proc. of ICEBE 2006 • Janiesch, C., Dreiling, A., Greiner, U., Lippe, S.: Integrated Configuration of Enterprise Systems for Interoperability. Proc. of EDOC 2006

Graphical Editor for PIM4SOA • Built as a set of Eclipse plug-ins using Eclipse Graphical Modelling Framework (GMF) • Based on updated version of PIM4SOA metamodel (A6) • Added support for extending documents • Supports the graphical modelling of • Services • Processes • Information (Business Documents) • Creates models conform to PIM4SOA metamodel • Developed general Eclipse plug-in for A7 repository to allow • Connection • Browsing • Import / Export • Down-stream transformations • Eclipse plug-ins: workbench integration with existing ATHENA MDE tools • PIM4SOA editor stores natively in PIM4SOA format • Existing A6 transformations work with minor alterations

Handling non-XML data is a key requirement for a large number of SOA solutions Legacy data, X12, EDIFACT, optimized data Non-XML description is the only part of a SOA solution that is not standardized Data Format Description Language is a draft standard to address that requirement DFDL Working Group within Open Grid Forum developing specification Physical format information contained as annotations e.g. <xs:sequence dfdl:separator=","> <xs:element name="y" type="double" dfdl:initiator="baseQ" dfdl:tagSeparator="=" /> </xs:sequence> Use of XML Schema gives several benefits (e.g. existing body of tooling, can apply prior knowledge, useful document model and implementation libraries) Dealing with Non-XML Data

XQuery command line tools Adapters (e.g. DOM, SDO ) VirtualXML XQuery API Input DFDL Schema (e.g. CSV) Target DFDL Schema (e.g. ‘plain’ XML) DFDL (Parser) DFDL (Serialzer) Data Source Data Target Bob,Smith,0042,002047500 <name> <given>bob</given> <last>smith</last> </name> <age>42</age> <salary>20475.00</salary> DFDL – Tooling/ATHENA results • Reference DFDL parser and serializer developed • (similar to Xerces for XML) • Developed within/as addition to… • Virtual XML framework • Extended existing framework with improved parser and new serializer • Uses DFDL parser to make non-XML data appear to be XML to existing tools

Mapping Requirements, Problems, Goals • Requirement for document mapping • Business processes and services are developed by different groups and use different interfaces. • Standards (ebXML, RosettaNet, etc.) are too complicated for applications to implement • Document mapping bridges between requester‘s service definition and provider‘s service definition • Current problems: • Mapping is almost entirely manual • Needs domain experts • A7 goal: • Automate as much as possible • Not expecting complete automation • Build on existing mapping tools

Automatic matching Map Generator TargetSchema SourceSchema save Maps conforms to conforms to Transformationgenerator RuntimeTransformation Source Source Target Target XQuery, XSLT, Java, proprietary Mapping Architecture (1) • A mapping generator • An optional automatic map generator • A transformation generator • A runtime that executes the transformation

Automatic Map Generator • Automatically discovers mappings between elements and attributes in the source and target schema using • Examples of source and target documents (Instance level matching) • Names and structure defined in the schema only (schema level matching) • Schema level matching algorithms that can be used: lexical matcher, thesaurus matcher, type matcher, structure matcher, ontology matcher SourceDeliveryAddress TargetCustomerAddress AddrLine1CitySt AddressLine1CityState

Source Schema Target Schema PartNumber subClassOf EAN 8 EANCode type type subClassOf EAN 13 UPC Example Thesaurus matching Ontology matching Lexical matching

Semaphore Extensions • Integration with A3 repository • Connect to A3 Repository • Retrieve ontologies • Automatic conversion to UML2 models for mapping • Integration with A7 P2P repository • Allows for storage and retrieval of relevant artifacts • Schemas • Models • Mappings • Uses same component (plug-in) as PIM4SOA Editor • Extended support for complex mappings • Valuable insight gained through work with CAS pilot

Repository for Business Documents Specific requirements for business documents and protocols: • A huge number of different formats • Various origins: bodies (e.g. W³C, IEEE), companies (e.g. Scheer) • Domain-specifics as from automotive • Applicability at different business levels: • ICT, content, process, … • Size of the data objects • Lots based on XML

Application Tool GUI Business Documents Business Protocols Models Instances Models Instances Repository Architecture (I) • Joins two highlights: • Flexibility from the Standard Repository API • Robustness from the Peer-to-Peer-based data store • Based on P2P platform BRMF from A6 • Provides both local and global repository workspaces • Peers store resources and • provide workspace navigation Repository API JSR 170 Repository Standard API Information Models Repository Mapping RepositoryEngine Peer-to-PeerInformation Space Persistent Data Store

LocalRepositoryWorkspace localRepositoryWorkspace localRepositoryWorkspace localRepositoryWorkspace Clone and Update operations provide data transfer DistributedRepositoryWorkspace • from local repository workspaces • to the global workspace distributed across the P2P overlay network • and vice versa Repository Architecture (II) JSR 170 Repository Standard API Repository Mapping Separation between meta data (resources) and pure business document content Peer-to-PeerInformation Space Local Data and Resource Store Access documents in the local storage through the repository

Standard-compliantApplication Standard-compliantApplication Standard-compliantApplication Standard API JSR 170 Standard-compliantRepository Standard-compliantRepository Standard-compliantRepository Proprietary Repository API Mapping Proprietary API P2P Repository Benefits • Benefits of the API Standard JSR 170 • Interoperability of various standard-compliant applications with various standard-compliant repositories • Benefits of the Peer-to-Peer data store • Highly robust and reliable • No single point of failure • Self-organizing overlay network in case of peer break-downs • Easy scaling • Data access without network flooding (DHT approach) • Reduced Total Cost of Ownership • Benefits of the separation between local and global workspaces • Update local repository modifications into the global workspace • Load (sub-) workspaces from Peer-to-Peer network • Stäber, F., Bartlang, U. und Müller, J.-P.: Using Onion Routing to Secure Peer-to-Peer Supported Business Collaboration, Proc. of eChallenges 2006 • Fischer, K., Müller, J.-P., Stäber, F. und Friese, Th.: Using Peer-to-Peer Protocols to Enable Implicit Communication in a BDI Agent Architecture, Programming Multi-Agent Systems, Springer, to appear 2007

Business Protocol Task Model Protocol Definition (WSDL) Business Document Definition (XSD) WSDL Import (A6) WebServiceModel Web Service Parameter Interface Task Parameter Interface Business Object Model Metis BD&P Architecture Client side modeling Server side execution Parameter Mapping Engine Web Service Invoker(A6) Task Execution Engine(A2)

Model-driven generation of executable protocols • Problem: • PIM4SOA ‚as is‘ concentrates on simple request/response patterns • E.g. patterns that deal with multiple partners cannot be modelled • Extend PIM4SOA to model service interaction patterns • ‚Conservative‘ extension • Existing transformations should still work • Enrich PIM4SOA with agent-related concepts • Transformation from PIM4SOA to Agent Metamodel

Model-driven generation of executable protocols (2) specify transform Protocol description PIM4SOA model Jack Agent Model • Kahl, T.; Zinnikus, I.; Roser, S.; Hahn, C.; Ziemann, J.; Mueller, J.; Fischer, K.: Architecture for the design and agent-based implementation of CBPs. I-ESA Conference, Funchal/Portugal, 28.-30. März 2007 • Hahn, C:, Neple, T. Limyr, A.,: Comparing model-transformation approaches. Workshop on PRO-VE, I-ESA Conference, Funchal/Portugal, 28.-30. März 2007 • Hahn, C., Madrigal-Mora, C., Fischer, K.: Interoperability through a platform-independent model for agents. I-ESA Conference, Funchal/Portugal, 28.-30. März 2007

Protocol Extensions • Enhancements for transformations from business level CBP models to executable process models • Steps for Transforming Event-driven Process Chain (EPC) to WS-BPEL model: • Complex semi-formal private processes are available • Business analyst describes interactions activities with EPC View Processes • No technical knowledge is needed, EPC is well known • System Designer enriches EPC with technical details • Names of involved Web Services, ports, types of XML messages • Structure of the EPC stays the same! • Formalized model to derive technical level models • Use transformations from A2 and A6 to convert technical EPC to PIM4SOA and then to BPEL • Kahl, T., Ziemann, J., Greiner, U., Lippe, S.: Enterprise Model Driven Creation of Business Protocols. Proc. of eChallenges 2006

Application of A7 Results • A7 results have been applied in the following scenarios: • eProcurement scenario from the furniture pilot • car configuration scenario from the outbound logistics pilot • strategic sourcing scenario from the automotive pilot • process for ordering a new vehicle from the manufacturer based on the STAR standard • Main findings: • results are well suited to handleindustry scenarios and standards • results made a significant contribution to the outbound logistics pilot • A7 complements A2 results on modeling and enactment of CBPs • provide means to also involve business users in the modelling effort thus abstracting from the purely technical representation provided e.g. by XML messages • protocol extensions target different execution platforms thus considering different infrastructures already existing at partners • Peer-to-Peer based repository facilitates an easy exchange of document and protocol models • provides a robust and decentrally organized platform

Summary of Achievements • Many standards and specifications of business documents and protocols are available • Users need guidance and support for implementation throughmodeling guidelines and tools: • Different stakeholders with different information needs have to be supported • Transformation mechanisms are needed to cover different pre-existing system landscapes • To reduce modeling effort users need meansto re-use document models and handle variants • Just dealing with the process level is insufficient: Business protocols have to be considered as a representation for more detailed interactions • Prototype: Graphical modeling support for business users is combined with semi-automatic transformations to create executable representations • processes, protocols and documents cover the most important aspects of modeling B2B collaborations • actors, product structures etc. must also be managed

Fulfilment of Work Plan    

Overall Contribution to ATHENA EPC Tasks Business Business BPEL Engine ARIS Metis BPEL Processes Processes Transfor-mations PIM4SOA Extended JACK Semantic PIM4SOA Editor MDD WSDL Services Services DFDL parser & serializer Automated Mapping Maestro for BDM Data Data P2P Repository Semaphore A7 provides lifecycle management for business documents and enhances CBPs with protocol support

Impact Made • Extension and completion of ATHENA results on CBPs • Contribution to outbound logistics pilot • DFDL - Implementation and status: • Parsers and Serializers can make use of physical annotations to read and write data in the described format • Prototype making use of the current version of specification available (within Virtual XML Framework from IBM, http://www.ibm.com/alphaworks) • Metis A7 implementation applied in two pilots in another EU project, and for demonstrations on ISO 15926 reference model import for the oil&gas industry

Q&A

Project A7 – Business Documents and Protocols Ulrike Greiner, SAP