Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

eBIZ courseware -Module 01 - Introduction (CW513-015)


Published on

Short introductive course for the adoption of eBIZ, the data exchange specification for eBusiness in European textile clothing and footwear industry.
It has been produced in the framework of the eBIZ 4.0 project funded in the framework of the COSME programme of the European Union

The course is based on 7 short modules

1 Terminology
2 eBIZ
3 eBIZ applicative domain
4 Focus on…
4a Focus on… Fabric
4b Focus on… Garment
5 The adoption path
6 Resources and documentation
7 Validation and control

More information in and

The content of this course represents the views of the authors only and is their sole responsibility;
it cannot be considered to reflect the views of the European Commission and/or the Executive Agency for Small and Medium-sized Enterprises or any other body of the European Union.
The European Commission and the Agency do not accept any responsibility for use that may be made of the information it contains.

Published in: Internet
  • Be the first to comment

eBIZ courseware -Module 01 - Introduction (CW513-015)

  1. 1. eBIZ adoption mini course January 2017 Terminology Piero De Sabbata, Arianna Brutti,
  2. 2. Prerequisites Good practical knowledge about XML Simple function of XML Schema knowledge
  3. 3. Objectives Introduction to the concepts and terminology of eBIZ Snapshot of the the applicative domain Methodological elements for eBIZ adoption
  4. 4. Summary 1. Terminology 2. eBIZ 3. eBIZ applicative domain 4. Focus on… 5. The adoption path 6. Resources and documentation 7. Validation and control
  5. 5. 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="" 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> 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="" xsi:schemaLocation="urn:moda-ml:repository:schema:TEXDyFinOrder h ml/repository/schema/v2013-1/TEXDyFinOrder.xsd" msgfunction="OR" TFCOtype="FIN" version="2013-1" useProfile="C <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>
  6. 6. 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 ClothingTextile Producer Accessory producer Retail MP2 MP1 MP2 … Fabric subcontractor Clothing subcontractor Yarn subcontractor
  7. 7. 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)
  8. 8. 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
  9. 9. Example: different transactions with the same type of document
  10. 10. Key concepts in eBIZ/5 Two data exchange paradigms Procedure 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
  11. 11. 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
  12. 12. 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
  13. 13. Key concepts in eBIZ/8 Interoperability vs integration Integration: uniformarsi a principi comuni − tendere a comportarsi come oggetto unico − uniformare rappresentazione interna delle informazioni nel DB Interoperability: concordare regole tra diversi − loose coupling between autonomous objects − 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 ( (il modello plug&play) 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
  14. 14. 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 allowed i.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
  15. 15. 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 improve interoperability 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, …)
  16. 16. End of the introduction What we have talked about Standard and interoperability definitions terminology used within eBIZ: concepts: processes, documents, transactions representations: 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?