Date post: | 13-Apr-2017 |
Category: |
Internet |
Upload: | enea-cross-tec-english |
View: | 127 times |
Download: | 0 times |
eBIZ adoption mini course
January 2017
TerminologyPiero De Sabbata, [email protected]
Arianna Brutti, [email protected]
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="[email protected]" phone="+39-051-1111111" fax="+39 051-11111111">Mario Bianchi</person> </buyer> <subContractor> <id numberingOrg="MF">UK99999999</id> <legalName>DYER LTD</legalName> <person email="[email protected]" 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, '-', '')) >= (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?