eBIZ adoption mini course

January 2017

TerminologyPiero De Sabbata, piero.desabbata@enea.it

Arianna Brutti, arianna.brutti@enea.it

Prerequisites

Good practical knowledge about XML

Simple function of XML Schema knowledge

Objectives

Introduction to the concepts and terminology of eBIZ

Snapshot of the the applicative domain

Methodological elements for eBIZ adoption

Summary

1. Terminology2. eBIZ3. eBIZ applicative domain4. Focus on…5. The adoption path6. Resources and documentation7. Validation and control

1. Models of electronic Documents: they define the data models and make the exchanged data not ambiguous (i.e. order, textile quality report, sales report, offer request,…). Their use is mandatory.

XML Schema (.xsd)<xsd:schema targetNamespace="urn:moda-ml:repository:schema:TEXDyFinOrder" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:moda-ml:repository:schema:TEXDyFinOrder" xmlns:ml="urn:moda-ml:repository:schema:TEXDyFinOrder" elementFormDefault="unqualified" attributeFormDefault="unqualified" version="2013-1">

<!-- Elemento radice --> <xsd:element name="TEXDyFinOrder" type="TEXDyFinOrder_Type"/> <!-- Tipo dell'elemento radice --> <xsd:complexType name="TEXDyFinOrder_Type"> <xsd:annotation> <xsd:documentation>TEXDyFinOrder - Dyeing-finishing commission order of a fabric</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="TFCOheader" type="TFCOheader_Type"/> <xsd:element maxOccurs="0" minOccurs="0" name="terms" type="terms_Type"/> <xsd:element maxOccurs="1" minOccurs="1" name="TFCObody" type="TFCObody_Type"/> </xsd:sequence> <xsd:attribute default="OR" name="msgfunction" type="msgfunction_Type" use="optional"/> <xsd:attribute name="TFCOtype" type="TFCOtype_Type" use="required"/> <xsd:attribute fixed="v2013-1" name="version" type="version_Type" use="optional"/> <xsd:attribute name="useProfile" type="useProfile_Type" use="optional"/> </xsd:complexType>….

Representation with XML Schemas which are the UNIQUE SOURCE for the syntax and the data structure to be used within the XML documents.

Key concepts in eBIZ/1

XML instance (.xml) <?xml version="1.0" encoding="UTF-8"?>

<ml:TEXDyFinOrder xmlns:ml="urn:moda-ml:repository:schema:TEXDyFinOrder" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:moda-ml:repository:schema:TEXDyFinOrder http://www.moda-ml.net/moda-ml/repository/schema/v2013-1/TEXDyFinOrder.xsd" msgfunction="OR" TFCOtype="FIN" version="2013-1" useProfile="CA">

<TFCOheader> <msgN>ODL-2013090417281122</msgN> <msgID>001 Prova Disposizione Preparazione</msgID> <msgDate>2013-09-04</msgDate> <buyer logo="FABRICSLTD_LOGO.jpg" sender="true"> <id numberingOrg="MF">IT99999999</id> <legalName>FABRICS srl</legalName> <person email="bianchi@fabrics.it" phone="+39-051-1111111" fax="+39 051-11111111">Mario Bianchi</person> </buyer> <subContractor> <id numberingOrg="MF">UK99999999</id> <legalName>DYER LTD</legalName> <person email="doe@dyer.uk" phone="2323232323" fax="23232324">Joe Doe</person> </subContractor> <note>Questo e' un esempio </note> </TFCOheader>

2. ACTORS or ROLES played different organization or independent departments: apparel producer, textile producer, logistic operator, dyeing subcontractor…

Key concepts in eBIZ/2

Yarn Producer Clothing Textile Producer

Accessory producer

Retail

MP2

MP1

MP2

…

Fabric subcontractor Clothing

subcontractor

Yarnsubcontractor

3. PROCESSES: description of the sequence of the data exchange between the different roles (fabric producer, vendor managed inventory, subcontracting,…)

they can be splitted in ACTIVITIES( i.e. articles choice, quality control,…)in eBIZ Processes and Activities are a reference and not an obligation;

Key concepts in eBIZ/3

Every process is based on- actors- Documents exchanged in

sequence …

CAUTION:In eBIZ the process is not related to what happens internally in the actor’s system

Representation with sequence diagrams (UML)

4. TRANSACTION: exchange action of a document in a specific context which, if completed, makes sense for the involved parties

Key concepts in eBIZ/4

Within eBIZ The same type of document (i.e. ‘Status’ or ‘Textile collection forecast’) in a specific context could have a different meaning and realize a different transaction

Example: different transactions with the same type of document

Key concepts in eBIZ/5

Two data exchange paradigmsProcedure call vs Transaction, Message, Document

Transaction: action of information exchange which has a full sense (legally too sometimes) for the parties in a specific context; also with a number of messages (puchase order)

Messagge: what it is exchanged with a single data transfer action; usually made of an information about the exchange (envelope) and content (payload, the document)

Document: the exchanged information, corrisponding to a ‘paper form’ in a conventional comunication (texorder.xml)Requirements: sender, receiver e DocID

Procedure call: - Invoked procedure- Authorization - Data- Answer

Key concepts in eBIZ/6

5. Business rules: further rules or constraints, expressed by texts or Schematron (.sch),

For example:

− Related to the contextualisation of a document model in a specific step of the business process(‘open order’ does not report delivery date)

− or simply impossible to express by the only XML Schema syntax (when using a numerical sizing system you cannot assign size=“SMALL”)

Schematron (.sch)….<sch:pattern> <sch:rule context="cbc:IssueDate"> <sch:assert test="(translate($OrderResp//eBizORD:OrderResponse/cbc:IssueDate, '-', '')) &gt;= (translate(current(), '-', ''))" >Date of creation must be after the publication date of the catalogue.</sch:assert> </sch:rule> <sch:rule context="//cac:StandardItemIdentification"> <sch:assert test="$OrderResp//cac:StandardItemIdentification/cbc:ID = ./cbc:ID">Article codes in the answer message must be already in the catalogue list.</sch:assert> </sch:rule> </sch:pattern>…

Mainly express quality rules

and, usually, are used in test activities supported by automatic validators

Key concepts in eBIZ/7 Conformance

Conformant to a specifications is:− Supporting all requirements of the specification− not violating explicit constraints

In general an application can be eBIZ compliant even if it satisfies only a part of the whole specification (we speak about different levels of conformance)

At a first level XML documents are validated against XML Schemas,

But, in order to achieve real interoperability also collaborative processes implementations, business rules etc. Must be checked.

Why conformance is important:1) Awareness of software packages really

implementing the specifications («conformant»)

2) Minimizing non-interoperability risk between applications (thus reduced time to setup effective inter-organisation collaborations)

WARNING: In this field ‘compatibility’ is a different and less constraining concept

Key concepts in eBIZ/8

Interoperability vs integration

Integration: uniformarsi a principi comuni− tendere a comportarsi come oggetto unico − p.es. uniformare rappresentazione interna delle informazioni nel DB

Interoperability: concordare regole tra diversi− loose coupling between autonomous objects− p.es. mantenere proprie rappresentazioni delle informazioni e concordare

regole scambio dati

Interoperabilità: la capacità di un sistema o prodotto di operare con altri senza che questo richieda sforzi particolari da parte dell’utente (whatis.com) (il modello plug&play)

...so in eBIZ:lavorare in modo indipendente al proprio interno e coordinarsi e connettersi con i partner della propria filiera a livello di front-end sulla base di scenari e standard condivisi

DEGREES of FREEDOM hamper plug-&-play data exchanges:

- Optional elements (allowed but not mandatory), to be managed and, when they are a lot, not any implementation supports them in order to limit costs

i.e. in UBL there are millions of possible XPATH in an ‘order’ document, but only some tens are used (differently from the case of eBIZ/Moda-ML)

- Many positions of an information are allowedi.e. refDoc in header or at item level

- Free coding: i.e. free texts instead of look-table (sometimes both are allowed)i.e. ‘payTerm’ (enumeration) and ‘payTermText’ (free text) or ‘note’ element

- Ambiguity: Different interpretation of the same statement

Degrees of freedom in specifications

Note: Often free coding is preferred by the programmers even if not necessary

A possible answer: the Use Profile

− Implementing the specifications only on the really used domain (a sub set of the specifications)

− Reducing ambiguities and interpretation uncertainty

− Coherence of organisational and contractual aspects with the chosen mode l

To lower implementation costs

To improveinteroperability

Some ‘drivers’ implementing standard eBusiness specifications:

USE PROFILE is a way to express HOW the specification is implemented in a specific context and domain (a supply chain, a community, …)

End of the introduction

What we have talked about Standard and interoperability definitionsterminology used within eBIZ:

concepts: processes, documents, transactionsrepresentations: sequence diagrams (UML), xsd, schematron…conformance

The contradiction between interoperability and degrees of freedom in specifications Standard specification and use profile The use profiles

What they allow and what they don’t allow who produces them / how to use them

Questions and Doubts?