Corso eBIZ -Modulo 01 - introduzione (CW513-004)

Mini CORSO adozione di eBIZ

Gennaio 2017

Terminologia

Piero De Sabbata, [email protected]

Arianna Brutti, [email protected]

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

<xsd:element name="TEXDyFinOrder" type="TEXDyFinOrder_Type"/><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="[email protected]" 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 …


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;


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.


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


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


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


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


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?

Corso eBIZ -Modulo 01 - introduzione (CW513-004)

Internet

Transcript of Corso eBIZ -Modulo 01 - introduzione (CW513-004)