Il documento tratta dell'adozione di standard ebiz e della terminologia associata, evidenziando la necessità di una buona conoscenza di XML e XML Schema. Si discute l'importanza di una terminologia condivisa, modelli di documenti elettronici e la conformità alle specifiche per garantire l'interoperabilità tra diversi sistemi. Viene inoltre presentato un approccio per migliorare l'integrazione e superare le sfide legate all'implementazione di specifiche standard nel settore dell'e-business.

1. Mini CORSO adozione di eBIZ
Gennaio 2017
Terminologia
Piero De Sabbata, piero.desabbata@enea.it
Arianna Brutti, arianna.brutti@enea.it

2. Prerequisiti
Buona conoscenza pratica con XML
Conoscenza della semplice funzione di XML Schema

3. Obiettivi
Introdurre ai concetti e terminologia di eBIZ
Conoscere il dominio di applicazione
Elementi metodologici per utilizzare eBIZ

4. “Se avessi i dati di sell-out…”
“Se avessi i dati dell’inventario, potrei attivare un servizio di never-out-of-stock…”
“I fornitori caricano i dati quando hanno tempo e in modo incompleto…”
“Ogni ordine viene inserito manualmente e a volte ci scappa l’errore…”
“La soluzione sarebbe ottima ma il fornitore non vuole investire tanto solo per me…”
“Ogni cliente pretende gli stessi dati in formato diverso e con procedure differenti…”
Scambio dati tra sistemi informatici diversi
Diversità procedure organizzative
Costi dell’integrazione fornitori/clienti
Risultato: interazione povera
(pochi dati, autolimitazione alla propria organizzazione)
Il punto di partenza

5. Sommario
1. La terminologia
2. eBIZ
3. Il dominio applicativo di eBIZ
4. La lente su…
5. Il percorso di adozione
6. Le risorse e la documentazione
7. Validazione e controllo

6. Che cosa intendiamo per ‘Standard’?
Presupposti
– processo di definizione riconosciuto (enti riconosciuti, status)
– un contesto d’uso (scenari e attori)
– descrizione formale non ambigua delle specifiche (pubblica, magari a
pagamento) autoconsistenza (non dipende da elementi proprietari)
– consenso degli stakeholder
Standard e standard…
– standard formali (ISO xxxx, UNI-xxx, W3C, …)
– standard volontari (Eurofer, Papinet, OTA, …)
– ‘standard’ de facto (Word e Autocad)
Il ricorso a standard consente di
- dare fiducia e riconoscibilità del prodotto
(p.es. marchi qualità)
- creare nuovi servizi/mercati abilitando
l’ interoperabilità tra sistemi diversi
(p.es.telefonia mobile/vs radio)

7. 1. Modelli di DOCUMENTI elettronici: definiscono i modelli dei dati e rendono non
ambigue le informazioni scambiate (p.es. ordine, report qualità pezza, report vendite,
richiesta offerta,…). Il loro uso è obbligatorio.
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"/>
Rappresentazione con XML Schema che sono UNICA FONTE per quanto attiene alla
sintassi ed alla struttura dati da usare nei documenti XML.
Concetti chiave in eBIZ/1
Istanza XML (.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.m
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

8. 2. ATTORI o RUOLI rivestiti da diverse organizzazioni o dipartimenti indipendenti tra loro:
produttore di capi di abbigliamento, produttore di tessuti, operatore logistico, terzista
tintore …
Concetti chiave in eBIZ/2
Produttore
Filati
ConfezioneProd. Tessuti
Produttore Accessori
Retail
MP2
MP1
MP2
…
Terzista
tessuti Terzista
confezione
Terzista
filati

9. 3. PROCESSI: descrizione della sequenza in cui avvengono scambi di documenti tra ruoli
(fornitura tessuti, vendor managed inventory, lavorazione conto terzi, …).
possono suddividersi in ATTIVITA’(p.es. selezione articoli, controllo qualità,…)
In eBIZ Processi ed Attività sono un riferimento e non un obbligo;
Concetti chiave in eBIZ/3
Ogni processo si basa su
- attori
- documenti scambiati in
sequenza …
ATTENZIONE:
Il processo in eBIZ prescinde
da quanto avviene
INTERNAMENTE
al sistema dell’attore
Rappresentazione con
diagrammi di sequenza (UML)

10. 4. TRANSAZIONE: azione di scambio di un documento in un contesto specifico che, se
completata, ha un senso compiuto per le parti.
Concetti chiave in eBIZ/4
In eBIZ
un medesimo tipo di documento (ad
esempio ‘Stato Avanzamento’ o ‘Previsione
Collezione Tessuti’)
in un contesto specifico può avere un senso
diverso e costituire una transazione
differente

11. Esempio: transazioni diverse con
medesimo tipo di documento

12. Concetti chiave in eBIZ/5
Due paradigmi di Scambio dati
Procedure call vs Transazione, Messaggio, Documento
Transazione: azione di scambio di
informazioni che ha un senso compiuto
(eventualmente anche legale) per le parti in
uno specifico contesto; anche più messaggi
(ordine d’acquisto)
Messaggio: quanto viene scambiato con una
singola azione di trasferimento dati;
solitamente si compone di informazioni
relative allo scambio (un involucro) e
contenuto (payload, il documento )
Documento: l’informazione scambiata,
corrispondente al ‘foglio cartaceo’ di una
normale comunicazione (texorder.xml)
Richiede: sender, receiver e DocID
chiamata a Funzione:
- Funzione invocata
- Autorizzazione
- Dati
- Risposta

13. Concetti chiave in eBIZ/6
5. Regole di business: ulteriori regole o vincoli, espressi con testi o con Schematron (.sch),
per esempio:
− relativi alla contestualizzazione di un modello di documento in una particolare fase del
processo di business
(un ordine aperto non indica la data di consegna)
− o semplicemente non esprimibili con la sola sintassi XML Schema
(se stai usando sistema di taglie numerico non puoi assegnare taglia=“SMALL”)
Schematron (.sch)
….
<sch:pattern>
<sch:rule context="cbc:IssueDate">
<sch:assert
test="(translate($OrderResp//eBizORD:OrderResponse/cbc:IssueDate, '-', '')) &gt;= (translate(current(), '-', ''))"
>La data di emissione della risposta ordine deve essere uguale o successiva alla data di
emissione del catalogo.</sch:assert>
</sch:rule>
<sch:rule context="//cac:StandardItemIdentification">
<sch:assert test="$OrderResp//cac:StandardItemIdentification/cbc:ID = ./cbc:ID">Gli articoli
nella risposta ordine devono essere presenti nel catalogo.</sch:assert>
</sch:rule>
</sch:pattern>
…
Esprimono principalmente
regole di qualità
e, normalmente, sono
utilizzate in fase di test di
interoperabilità con appositi
validatori

14. Concetti chiave in eBIZ/7
Conformità
Conformità ad una specifica significa:
− supportare tutti i requisiti della specifica
− non violare i vincoli imposti dalla specifica
un’implementazione può essere conforme a eBIZ anche se non implementa tutte le
sue parti (parliamo di livelli di conformità)
In prima istanza i documenti XML sono
validati su XML Schema,
ma per essere veramente
interoperabili occorre verificare anche i
processi di collaborazione, regole di
business ecc.
Perché è importante la conformità:
1) Riconoscibilità dei pacchetti software che
implementano in modo corretto
(«conforme») le specifiche
2) Minimizzazione del rischio di non
interoperabilità tra applicazioni (e quindi i
tempi di messa a punto delle collaborazioni
inter-aziendali)
ATTENZIONE:
in questo campo non equivale a
‘compatibilità’, concetto meno
stringente

15. Concetti chiave in eBIZ/8
Interoperabilità vs integrazione
Integrazione: uniformarsi a principi comuni
− tendere a comportarsi come oggetto unico
− p.es. uniformare rappresentazione interna delle informazioni nel DB
Interoperabilità: concordare regole tra diversi
− loose coupling tra oggetti autonomi
− 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)
...quindi 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

16. Contraddizione tra gradi di libertà
nelle specifiche e interoperabilità
ci sono ostacoli all’interoperabilità anche in presenza di standard
- Non tutti i requisiti possibili sono supportati (standard basati sul principio di
Pareto 80/20)
- Non sempre tutti i vincoli sono chiaramente/formalmente espressi
- Sono ammessi dei GRADI di LIBERTA’
QUALUNQUE MIO SCENARIO
E’ SUPPORTATO? NO!
Requisiti
Casi
soddisfatti
100%

17. GRADI di LIBERTA’ che ostacolano scambi dati plug-&-play:
- Elementi opzionali (possibili ma non obbligatori), sono da gestire e
se sono TANTI non tutte le implementazioni li supportano per contenere i
costi
p.es. in UBL ci sono milioni di possibili XPATH per l’ordine, ma se ne usano
alcune decine (diversamente da eBIZ/Moda-ML)
- Più collocazioni di una informazione sono possibili
p.es. refDoc inserito in header o in ogni item
- Codifiche libere: p.es. testo libero anziché valori tabellati (a volte consentiti
entrambi)
p.es. payTerm(tabella) e payTermText(testo libero) oppure uso di note
- Ambiguità: differenti interpretazioni della medesima indicazione
I gradi di libertà nelle specifiche
NOTA:
Spesso codifiche libere sono preferite da
programmatori anche se non necessarie

18. Una possibile risposta: il Profilo d’Uso
− Restringere l’utilizzazione delle
specifiche a un (sotto) dominio ben
definito ed effettivamente utilizzato
− Ridurre ambiguità e incertezze
interpretative
− Coerenza degli aspetti organizzativi e contrattuali con il modello scelto
per abbassare costi di
implementazione
per migliorare
interoperabilità
Alcune ‘sfide’ nell’implementazione di specifiche standard per eBusiness:
PROFILO d’ USO è una formalizzazione di COME va implementata la specifica
in un dominio e contesto specifico (in un sottosettore, in una community, tra i
fornitori di una azienda capocommessa,…)

19. Fine dell’introduzione
Abbiamo parlato di
definizioni di standard ed interoperabilità
terminologia utilizzata in eBIZ:
concetti: processi, documenti, transazioni
rappresentazioni: diagrammi di sequenza (UML), xsd, schematron…
conformità
la contraddizione tra interoperabilità e gradi di libertà nelle specifiche
specifica standard e profilo d’uso
i profili d’uso
che cosa consentono e che cosa non consentono
chi li produce / come si usano
DOMANDE e DUBBI?