Nella seconda parte della serie di blog su come integrare SAP utilizzando gli Snap IDoc SAP, daremo un'occhiata al comportamento degli Snap IDoc Write e alle varie impostazioni che è possibile configurare, oltre a fare luce sulla configurazione all'interno di SAP per far sì che la pipeline SnapLogic venga elaborata in modo sincrono o asincrono nel caso in cui si intenda continuare l'elaborazione della pipeline senza attendere il completamento dell'elaborazione IDoc nel sistema SAP.
Comprendere le impostazioni in IDoc Write Snap
L'impostazione più importante da effettuare è l'aggiunta del nome del modulo funzione nel campo IDoc Read BAPI Name, utilizzato per leggere lo stato dell'IDoc una volta creato nel sistema SAP. Abbiamo discusso del modulo funzione nella prima parte della nostra serie di blog e abbiamo allegato un esempio di implementazione alla fine del primo blog. Una volta creato un IDoc, lo Snap tenterà di leggere l'IDoc tramite il modulo funzione esattamente una volta per determinare lo stato attuale dell'IDoc nel sistema SAP e quindi utilizzerà questo stato per determinare se la pipeline SnapLogic deve continuare a elaborare il documento a valle o indirizzare il documento alla vista degli errori. Affinché lo Snap possa farlo, è necessario selezionare la casella di controllo Indirizza errori.
Gli stati degli IDoc nel sistema SAP sono divisi in due parti: IDoc in uscita compresi tra 01 e 42 e IDoc in entrata compresi tra 50 e 75. È possibile visualizzare un elenco completo dei codici di stato degli IDoc utilizzando la transazione WE47 nel sistema SAP. Entrare nel dettaglio dei codici di stato degli IDoc va oltre lo scopo di questo blog, ma l'elaborazione standard degli IDoc in entrata passa tipicamente attraverso queste transizioni di stato:
- 50 IDoc aggiunti
- 64 IDoc pronto per essere trasmesso
- 62 IDoc trasmesso all'applicazione
- 53 Documento di candidatura pubblicato.
Aggiungendo i codici di stato sopra indicati ai campi Codici di successo, si indica a Snap di indirizzare i documenti alla vista di output se gli IDoc creati presentano uno di questi stati al momento della lettura dello stato. Tutti gli altri documenti che hanno creato IDoc con altri stati saranno indirizzati alla vista degli errori. Anche in questo caso, poiché il modulo funzione legge lo stato una sola volta e controlla solo lo stato corrente al momento della lettura, è essenziale aggiungere tutti gli stati al campo che deve essere utilizzato per continuare l'elaborazione del documento a valle.
Il Intervallo di polling e il Timeout di polling controllano il tempo di attesa dello Snap per determinare lo stato dell'IDoc. Se l'intervallo di polling è impostato su 0, lo Snap non utilizzerà il modulo funzione e non tenterà affatto di leggere lo stato dell'IDoc. Qualsiasi impostazione superiore a 0 verrà utilizzata come tempo di attesa in secondi tra una chiamata e l'altra al sistema SAP per leggere uno stato. Il timeout di polling determinerà il tempo complessivo di attesa prima di generare un'eccezione Java. Le impostazioni possono essere utilizzate se si creano IDoc in sistemi SAP molto trafficati, per i quali è necessario determinare lo stato dell'IDoc per stabilire il percorso.
Comprendere il comportamento di elaborazione degli IDoc in SAP
Al momento della stesura del presente documento, gli IDoc SAP di SnapLogic supportano solo tRFC (Transactional Remote Function Call) e qRFC (Remote Function Call in coda) non è supportato. Inoltre, i nostri Snap IDoc utilizzano libreria JCO di SAP e la relativa libreria Java IDoc per creare IDoc. Detto questo, ci concentreremo solo sul comportamento della libreria Java IDoc quando si chiama JCoIDoc.send(..). Si tenga presente che i sistemi che non utilizzano queste librerie potrebbero presentare un comportamento diverso e opzioni diverse.
Comportamento sincrono dell'elaborazione IDoc
Quando abbiamo iniziato a studiare i vari comportamenti, abbiamo spesso trovato persone su Internet che affermavano che gli IDoc sono sempre asincroni. Tuttavia, abbiamo osservato un comportamento diverso quando abbiamo utilizzato lo snap IDoc Write, che sembrava attendere il "completamento" dell'elaborazione in SAP prima di continuare. Abbiamo quindi pubblicato una domanda su Software Developer Network di SAP. Abbiamo ricevuto subito una risposta che ci rimandava alla SAP Note 180057 che spiega che SAP ha modificato il comportamento del modulo funzione IDOC_INBOUND_ASYNCHRONOUS e non separa più la creazione dell'IDoc nel livello ALE dal trasferimento all'applicazione. IDOC_INBOUND_ASYNCHRONOUS è il modulo funzione utilizzato nella libreria Java IDoc dal metodo JCoIDoc.send(..). Ciò significa che se avete configurato il vostro IDoc proveniente da SnapLogic per essere elaborato immediatamente nella transazione WE20, come mostrato nella schermata qui sotto.
La creazione dell'IDoc nel livello ALE di SAP avverrà nello stesso processo dell'elaborazione dell'IDoc da parte dell'applicazione, e la libreria Java IDoc SAP attenderà fino a quando l'applicazione avrà terminato l'elaborazione dell'IDoc. Con la libreria in attesa, lo Snap di scrittura IDoc non può richiamare lo stato dell'IDoc, anche se l'IDoc ha già superato i codici di stato 50, 64 e 62. Questo comportamento vincola effettivamente la pipeline SnapLogic all'intera elaborazione dell'IDoc da parte dell'applicazione all'interno di SAP e la pipeline continuerà solo una volta terminata l'elaborazione dell'IDoc.
Opzioni per l'elaborazione asincrona degli IDoc
Se siete interessati a separare la vostra pipeline SnapLogic dall'elaborazione dell'IDoc in SAP Note 180057 offre diverse opzioni. Purtroppo, la prima soluzione che prevede l'uso del modulo funzione INBOUND_IDOC_PROCESS non è disponibile, poiché la libreria Java SAP IDoc non offre la possibilità di utilizzare questo modulo funzione. Inoltre, la seconda opzione, che consiste nel trasferire pacchetti IDoc più piccoli, non funziona, poiché richiederebbe comunque di attendere il completamento dell'elaborazione da parte dell'applicazione. Ciò ci lascia due opzioni: la prima sarebbe quella di passare dall'elaborazione dell'IDoc nella transazione WE20 da Trigger Immediately a Attiva in background programma.
Questa configurazione separerà la creazione dell'IDoc nel livello ALE di SAP dall'elaborazione dell'IDoc da parte dell'applicazione e consentirà a SAP IDoc Write di continuare non appena l'IDoc viene creato nel livello ALE. Ciò significa anche che lo stato che avrà il tuo IDoc quando SAP IDoc Write Snap lo leggerà non sarà mai superiore a 64.
La seconda opzione consiste nell'utilizzare una porta ABAP-PI per l'IDoc in entrata nella transazione WE21 e quindi specificare la porta ABAP-PI invece di una porta RFC transazionale nella struttura di controllo dell'IDoc.
La schermata sottostante mostra la configurazione della porta nella transazione WE21. Quando si crea la porta, è possibile scegliere qualsiasi modulo funzione. In questo caso, abbiamo utilizzato RFC_PING. È importante notare che il modulo funzione specificato non viene utilizzato durante l'elaborazione in entrata, ma è necessario per salvare la configurazione.
Una volta specificata la porta, utilizzare il nuovo nome della porta, ASYNC0001, nel nostro caso, nel campo SNDPOR della struttura di controllo del tuo IDOC. Per darti un'idea, utilizziamo il JSON riportato di seguito in uno Snap JSON Generator nella pipeline di esempio che abbiamo allegato alla prima parte della serie di blog, ma sostituiamo il campo SNDPOR con il nome della porta ABAP-PI.
{
"EDI_DC40": {
"MESTYP" : "ZPERSONDATA",
"SNDPRT" : "LS",
"SNDPRN" : "SNPCLNT000",
"SNDPOR" : "ASYNC00001",
"RCVPRT" : "LS",
"RCVPRN" : "A4HCLNT001"
},
"ZPERSONDATA01": [
{
"FIRSTNAME": "Ingo",
"LASTNAME": "Sauerzapf",
"TITLE": "Mr.",
"GENDER": "male",
"STREET": "33rd Str.",
"CITY": "New York",
"ZIP": "98632",
"COUNTRY": "United States",
"EMAIL": "[email protected]",
"PHONE": "5405883833",
"SLEEPTIME": 40
}
]
}Quando viene inviato tramite una porta ABAP-PI, il sistema SAP avvia l'applicazione per l'elaborazione diretta, ma non attende il completamento dell'elaborazione. Il tuo IDoc Write Snap sarà in grado di continuare a leggere lo stato immediatamente.
Verifica del comportamento durante il passaggio dall'elaborazione sincrona a quella asincrona
Per testare il comportamento, abbiamo creato un IDoc nel sistema SAP e realizzato una piccola applicazione che prende i dati dell'IDoc in arrivo e li scrive in una tabella nel database del sistema SAP. Per simulare un'elaborazione IDoc di lunga durata, abbiamo aggiunto un'istruzione sleep di 60 secondi. Quando creiamo un IDoc inviandolo alla porta tRFC, possiamo vedere che l'esecuzione della pipeline richiederà poco più di 1 minuto.
Se invece inviamo lo stesso IDoc tramite la porta ABAP-PI, l'elaborazione della pipeline verrà completata in pochi millisecondi.
Nella terza parte della nostra serie di blog, esamineremo gli snap IDoc Listen e IDoc Document Listen. Vedremo anche come modificare lo stato di un IDoc nel sistema SAP che abbiamo ricevuto tramite gli snap di ascolto, in modo da riflettere accuratamente il suo stato una volta elaborato dal processo SnapLogic.
