Quando si configura l'interscambio di documenti tra i partecipanti e il Gestore comunità, vengono specificati molti elementi sul documento:
L'impacchettamento, il protocollo e il flusso di un documento costituiscono la definizione di flusso di documenti. La definizione del flusso di documenti fornisce informazioni sull'hub relative all'elaborazione del documento. Ad esempio, si supponga di utilizzare la definizione di flusso dei documenti fornita dal sistema di:
L'hub estrae le informazioni sull'intestazione AS (e le utilizza per stabilire l'origine e la destinazione del documento). Sa dove trovare, nel documento, certe informazioni, in base a dove sono posizionate nel documento stesso. Le tre parti della definizione di flusso di documenti hanno attributi ad esse assegnati. È possibile modificare o aggiungerli a quelli definiti dal sistema.
L'impacchettamento fornisce informazioni che riguardano la trasmissione del documento. Come descritto nella sezione precedente, se l'impacchettamento è AS, l'hub utilizza le informazioni contenute nell'intestazione AS per stabilire l'origine e le destinazione per il documento. Se un partecipante invia un PIP RosettaNet al Gestore comunità, il PIP viene impacchettato come RNIF.
Figura 3 illustra i tipi di impacchettamento che possono essere impostati per i documenti scambiati tra l'hub e un partecipante della comunità e tra l'hub e un'applicazione di backend.
I pacchetti sono associati a protocolli specifici. Ad esempio, un partecipante deve specificare l'impacchettamento RNIF quando invia RosettaNet all'hub.
Come descritto in Figura 3, l'integrazione backend è disponibile solo tra l'hub e l'applicazione back-end. Quando si specifica l'impacchettamento integrazione backend, i documenti inviati dall'hub al sistema back-end hanno informazioni speciali sull'intestazione aggiunte. Similmente, quando un'applicazione invia documenti con un impacchettamento di integrazione backend all'hub, è necessario aggiungere informazioni sull'intestazione. Il pacchetto di integrazione di backend e i requisiti per le informazioni di intestazione vengono descritti nella guida Enterprise Integration.
Il pacchetto AS è disponibile solo tra partecipanti e hub. Il pacchetto AS può essere utilizzato per i documenti che aderiscono agli standard AS1 o AS2. AS1 è uno standard utilizzato per una trasmissione protetta di documenti su SMTP e AS2 è uno standard utilizzato per la trasmissione protetta di documenti su HTTP o HTTPS. I documenti inviati da un partecipante con impacchettamento AS hanno sia informazioni sull'intestazione AS1 che sull'intestazione AS2. I documenti inviati ad un partecipante che prevede intestazioni AS1 o AS2 devono essere impacchettati (sull'hub) come AS.
Il pacchetto Nessuno può essere utilizzato per inviare e ricevere documenti tra l'hub e i partecipanti e tra l'hub e un'applicazione back-end. Non viene aggiunta alcuna informazione sull'intestazione (o prevista) quando un documento viene impacchettato come Nessuno.
Il pacchetto RNIF viene fornito sul supporto di installazione. Si carica il pacchetto RNIF (insieme ai PIP che si desidera scambiare), come descritto in Documenti RosettaNet. Il pacchetto RNIF viene utilizzato per inviare documenti RosettaNet dal partecipante all'hub o dall'hub al partecipante.
Alcuni flussi di documenti terminano in WebSphere Partner Gateway o nascono internamente da WebSphere Partner Gateway. Per i flussi di documenti che terminano in WebSphere Partner Gateway, non è richiesto alcun impacchettamento. I flussi di documenti che nascono internamente a WebSphere Partner Gateway non dispongono di un impacchettamento di origine. Pertanto, per tali flussi, l'impacchettamento è specificato come N/D.
Per la maggior parte delle trasmissioni monodirezionali tra il partecipante e il Gestore comunità (o viceversa), WebSphere Partner Gateway riceve un documento da un partecipante e lo invia al Gestore comunità. In WebSphere Partner Gateway, quando si crea una connessione del partecipante, specificare l'impacchettamento in cui WebSphere Partner Gateway riceverà il documento e l'impacchettamento che WebSphere Partner Gateway utilizzerà per inviare il documento. In Figura 4, un documento impacchettato come AS fluisce da un partecipante al back-end del Gestore comunità. Il documento viene recapitato al gateway del Gestore comunità senza intestazioni di trasposto. In Figura 4, un'azione è associata allo scambio di documenti.
Tuttavia, alcuni protocolli richiedono più attività, (come ad esempio lo sbustamento e la trasformazione) alcune delle quali si verificano come parti dello scambio globale. Se, ad esempio, un partecipante invia uno scambio EDI all'hub, per l'eventuale consegna al Gestore comunità, lo scambio viene sbustato e le singole transazioni EDI elaborate. Lo scambio EDI originale ha un pacchetto associato quando viene inviato dal partecipante. Tuttavia, poiché lo scambio non viene consegnato al Gestore comunità (viene sbustato nell'hub e non si verifica alcuna elaborazione dello scambio), non viene applicato l'impacchettamento dello scambio. Quando si configura l'interazione per lo sbustamento, di conseguenza, si immette un pacchetto sul lato dell'invio ma si specifica N/D per il lato della ricezione.
Il processo di configurazione delle definizioni di flusso di documenti richiesto per uno scambio EDI viene descritto in Configurazione dei flussi di documenti EDI.
I protocolli forniti con il sistema sono:
Il protocollo Binary può essere utilizzato con pacchetti AS, Nessuno e Integrazione backend. Un documento binario non contiene dati sull'origine o la destinazione del documento.
Questi protocolli EDI possono essere utilizzati con pacchetti AS o Nessuno. Come descritto in N/D, se la transazione EDI o l'interscambio che nasce dall'hub o termina all'hub, specificare N/D per il pacchetto. X12 e EDIFACT sono standard EDI utilizzati per lo scambio dei dati. EDI-Consent si riferisce a tipi di contenuto diversi da X12 o EDIFACT.
Le richieste del servizio Web possono essere utilizzate solo con il pacchetto Nessuno.
I documenti cXML possono essere utilizzati solo con il pacchetto Nessuno.
XMLEvent è un protocollo speciale utilizzato per fornire la notifica dell'evento per i documenti che fluiscono a e dall'applicazione back-end. Può essere utilizzato solo con il pacchetto Integrazione backend. Questo protocollo è descritto nella Guida Enterprise Integration.
Quando si caricano pacchetti RNIF, si ottengono anche i protocolli associati (RosettaNet e RNSC). RosettaNet (protocollo utilizzato tra il partecipante e l'hub) è associato al pacchetto RNIF. RNSC (protocollo utilizzato tra l'hub e l'applicazione back-end del Gestore comunità) è associato al pacchetto Integrazione Backend.
Per le transazioni EDI o i documenti XML o ROD che verranno trasformati, si importa una mappa di trasformazione dal client Data Interchange Services. Nel client Data Interchange Services, i dizionari sono definiti per il protocollo associato a questa trasformazione. Un dizionario contiene informazioni su tutte le definizioni dei documenti EDI, i segmenti, gli elementi dei dati compositi e gli elementi di dati che costituiscono uno standard EDI. Per informazioni dettagliate su un determinato standard EDI, fare riferimento ai manuali degli standard EDI appropriati. Per informazioni sul client Data Interchange Services, fare riferimento alla Guida alla mappatura o alla guida in linea fornita con il client Data Interchange Services.
E' possibile creare protocolli personalizzati per definire esattamente il modo in cui si desidera strutturare un documento. Per i documenti XML, è possibile definire un formato XLM, come descritto in Documenti XML personalizzati.
Il documento può avere vari formati. Di seguito sono riportati i flussi di documenti forniti dal sistema e protocolli associati:
Nel seguente elenco vengono descritti altri tipi di documenti e l'origine della definizione:
È inoltre possibile creare propri flussi di documenti, come descritto in Documenti XML personalizzati.