This document provides an introduction to key concepts in electronic business or eBIZ adoption. It defines terminology like electronic documents, actors or roles, processes, and transactions. It explains how standards are represented using XML schemas and business rules are defined using schematron. The document outlines the importance of conformance for interoperability and discusses the relationship between integration and interoperability. Finally, it introduces the concept of use profiles to reduce ambiguity and improve implementation of eBIZ specifications in a given industry context.

1. eBIZ adoption mini course
January 2017
Terminology
Piero De Sabbata, piero.desabbata@enea.it
Arianna Brutti, arianna.brutti@enea.it

2. Prerequisites
Good practical knowledge about XML
Simple function of XML Schema knowledge

3. Objectives
Introduction to the concepts and terminology of eBIZ
Snapshot of the the applicative domain
Methodological elements for eBIZ adoption

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. 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>
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 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. 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. 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. 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. Example: different transactions with
the same type of document

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. 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. 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. 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

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. 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. 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?