View
63
Download
1
Category
Preview:
Citation preview
Mini CORSO adozione di eBIZ
Gennaio 2017
Terminologia
Piero De Sabbata, piero.desabbata@enea.it
Arianna Brutti, arianna.brutti@enea.it
Prerequisiti
Buona conoscenza pratica con XML
Conoscenza della semplice funzione di XML Schema
Obiettivi
Introdurre ai concetti e terminologia di eBIZ
Conoscere il dominio di applicazione
Elementi metodologici per utilizzare eBIZ
“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
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
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)
1. Modelli di DOCUMENTI elettronici: definiscono i modelli dei dati e rendono nonambigue 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.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
2. ATTORI o RUOLI rivestiti da diverse organizzazioni o dipartimenti indipendenti tra loro:produttore di capi di abbigliamento, produttore di tessuti, operatore logistico, terzistatintore …
Concetti chiave in eBIZ/2
Produttore Filati
Confezione Prod. Tessuti
Produttore Accessori
Retail
MP2
MP1
MP2
…
Terzista tessuti Terzista
confezione
Terzista filati
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)
4. TRANSAZIONE: azione di scambio di un documento in un contesto specifico che, secompletata, 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
Esempio: transazioni diverse con
medesimo tipo di documento
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
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 delprocesso 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, '-', '')) >= (translate(current(), '-', ''))">La data di emissione della risposta ordine deve essere uguale o successiva alla data diemissione del catalogo.</sch:assert>
</sch:rule><sch:rule context="//cac:StandardItemIdentification">
<sch:assert test="$OrderResp//cac:StandardItemIdentification/cbc:ID = ./cbc:ID">Gli articolinella 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
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
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
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%
GRADI di LIBERTA’ che ostacolano scambi dati plug-&-play:
- Elementi opzionali (possibili ma non obbligatori), sono da gestire ese sono TANTI non tutte le implementazioni li supportano per contenere i costip.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 possibilip.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
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,…)
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?
Recommended