Uno scambio EDI ricevuto sull'hub è, di solito, sbustato e le singole transazioni elaborate. Spesso, le transazioni EDI (come ad esempio X12 850 o EDIFACT ORDERS, che rappresenta un ordine di acquisto) vengono trasformate in un formato che può essere compreso da un'applicazione back-end. Inoltre, un riconoscimento funzionale viene spesso inviato al partecipante per indicare che lo scambio è stato ricevuto. Lo scambio di scambi EDI, di conseguenza, richiede più azioni (quali lo sbustamento, la conversione e la convalida EDI). Se, ad esempio, lo scambio contiene due transazioni e non viene richiesto alcun riconoscimento, WebSphere Partner Gateway esegue le seguenti azioni:
WebSphere Partner Gateway estrae le informazioni sullo scambio dall'intestazione della busta e i segmenti dell'elemento di coda sullo scambio, sul gruppo e sui livelli di transazione. Le informazioni includono:
Similmente, quando l'hub invia un documento o documenti che sono originati sull'applicazione back-end del Gestore comunità, i documenti vengono trasformati in transazioni EDI standard. Le transazioni EDI risultanti vengono imbustate prima di essere inviate al partecipante. Come nel caso di ricezione di uno scambio EDI, vengono richieste più azioni per creare, imbustare ed inviare uno scambio EDI.
Le transazioni, i gruppi e gli scambi vengono identificati dai numeri di controllo. WebSphere Partner Gateway imposta questi numeri quando si verifica uno scambio. Si possono personalizzare i numeri di controllo, come descritto in Numeri di controllo.
Nella seguente figura viene rappresentato come uno scambio EDI, impacchettato come AS, viene inviato dal partecipante, con l'eventuale obiettivo di consegnare due documenti XML trasformati in due gateway differenti sul sistema back-end del Gestore comunità. In questo esempio, le transazioni 850 vengono trasformate in ordini di acquisto che possono essere elaborati da un'applicazione di back-end. Le transazioni 890 vengono trasformate in ordini di spedizione di magazzino che possono essere elaborati dall'applicazione di back-end.
Invece che richiedere una connessione dal partecipante al Gestore comunità, questo scambio richiede tre connessioni:
Per le transazioni, l'impacchettamento di origine non è disponibile, poiché le transazioni entrano nell'interscambio di origine che era stato sbustato dal sistema. Pertanto, la parte di origine delle transazioni, deve disporre del seguente parametro Impacchettamento: N/D specificato nella connessione del partecipante.
Per la transazione che viene trasformata in XML e che passa all'applicazione di backend attraverso JMS, è necessario specificare il gateway di destinazione sulla connessione del partecipante della transazione come gateway del Gestore comunità. Per la transazione trasformata in XML e che passa all'applicazione di back-end sull'HTTP, è necessario specificare il gateway di destinazione sulla connessione del partecipante di questa transazione come gateway HTTP.
E' possibile utilizzare il visualizzatore di documenti per visualizzare l'interscambio e le transazioni individuali, che nei termini del visualizzatore documenti, sono i child dell'interscambio. Utilizzando il visualizzatore di documenti, è possibile visualizzare i child associati all'interscambio di origine o di destinazione ed è possibile visualizzare gli eventi associati. Il visualizzatore di documenti è descritto nella sezione "Visualizzazione di eventi e documenti" del manuale Guida dell'amministratore.
Se il mittente richiede riconoscimenti, sono necessarie connessioni aggiuntive: