BAPI e RFC tra sistemi SAP

Se sviluppi in ABAP e devi far parlare due sistemi SAP tra loro, oppure devi leggere dati SAP da un programma esterno, ti trovi davanti alla Remote Function Call. Capire come funziona ti aiuta a leggere il codice esistente, a distinguere una chiamata locale da una chiamata remota e a controllare dove avviene davvero l'esecuzione. In queste righe trovi cosa prevede l'interfaccia, come richiamarla da ABAP e quali versioni di dialogo puoi incontrare nei sistemi collegati.

La pagina di riferimento descrive la Remote Function Call come interfaccia proprietaria di SAP e come interfaccia standard per la comunicazione tra sistemi SAP. Il meccanismo è semplice da visualizzare: chiami una funzione che viene eseguita in un sistema remoto. Quella funzione restituisce dati al chiamante e, negli scambi di dati descritti dalla pagina, lo scambio va in due direzioni, perché puoi leggere dati dal server e puoi inserire dati negli archivi del server. SAP può assumere il ruolo di cliente oppure il ruolo di server nella chiamata.

Cosa fa una Remote Function Call in un sistema SAP

Quando scrivi codice gestionale pensi spesso a una funzione che gira nello stesso sistema dove si trova il programma chiamante. Con la Remote Function Call sposti l'esecuzione altrove. Resti nel sistema di partenza, la logica gira nel sistema di arrivo e il risultato torna indietro. Questo spiega perché nei progetti trovi un sistema che chiede e un sistema che risponde, con ruoli che possono invertirsi da una chiamata all'altra. Se leggi un programma e vedi che la destinazione è valorizzata, sai già che devi cercare la funzione nel sistema remoto, non in quello locale.

La descrizione tecnica ripresa dalla pagina parla di chiamata o esecuzione remota di un Remote Function Module in un sistema esterno. Nel sistema SAP queste funzioni sono fornite dal sistema di interfacce RFC, che rende possibili le chiamate di funzione tra due sistemi SAP. Se devi mantenere codice esistente, questo significa che esistono due livelli da controllare: il programma che chiama e il modulo funzione che gira altrove. Se uno dei due cambia, devi verificare l'altro.

Perché SAP parla di interfaccia proprietaria e standard

La definizione può sembrare contraddittoria, ma ti aiuta a collocare la RFC nel panorama SAP. È proprietaria perché appartiene a SAP e segue le sue regole. È standard perché, all'interno dei sistemi SAP, rappresenta il modo previsto per comunicare da sistema a sistema. Non devi inventare un protocollo diverso quando colleghi due ambienti SAP, perché utilizzi il canale pensato per questo scopo. La pagina Wikipedia non pubblica esempi di parametri BAPI né schemi di gestione degli errori.

Questa impostazione cambia il tuo modo di documentare un collegamento. Invece di descrivere socket o file di scambio, annoti quale sistema chiama, quale sistema esegue, quale modulo funzione viene invocato e quale utente tecnico viene usato per l'accesso. Chi legge la tua analisi capisce subito dove cercare eventuali differenze di customizing o di dati anagrafici. Puoi collegare questa abitudine alla lettura delle liste interattive e griglie ALV, dove i dati mostrati a video spesso arrivano da letture che, in un contesto distribuito, possono nascere da una chiamata remota.

Come chiami una funzione remota da un programma ABAP

Da un programma ABAP la chiamata avviene con l'istruzione CALL FUNCTION con l'aggiunta di DESTINATION. Il parametro DESTINATION segnala al sistema SAP che il modulo funzione chiamato gira in un sistema diverso rispetto al sistema chiamante. La comunicazione RFC con il sistema remoto avviene come parte dell'istruzione CALL FUNCTION. Non scrivi quindi una connessione separata prima della chiamata, perché la destinazione indicata nell'istruzione determina già l'instradamento.

Nel lavoro quotidiano ti conviene leggere l'istruzione in due tempi. Prima identifichi il nome del modulo funzione, poi controlli il valore della destinazione. Se la destinazione è fissa nel codice, sai dove punta in quel caso specifico. Se è contenuta in una variabile o in una tabella di configurazione, devi risalire al valore effettivo per capire quale sistema viene contattato. Questo controllo evita la confusione tra l'ambiente di sviluppo, quello di test e quello di esercizio, dove le destinazioni possono puntare a sistemi diversi.

Cosa significa davvero registrare un modulo come remoto

Non tutte le funzioni ABAP possono essere chiamate da remoto. I moduli funzione RFC in un sistema SAP devono essere veri e propri moduli funzione e devono essere registrati nel sistema SAP come remoti. Quando il programma chiamante e il programma chiamato sono entrambi programmi ABAP, il sistema di interfacce RFC fornisce entrambi gli interlocutori per la comunicazione. Il programma chiamante può essere qualsiasi programma ABAP, mentre il programma chiamato deve essere un modulo funzione registrato come remoto. La panoramica sulla interfaccia standard di SAP colloca questa regola nel quadro generale della comunicazione tra sistemi.

La registrazione avviene impostando l'indicatore di abilitazione remota nella scheda Attributi del Function Builder dell'ABAP Workbench, transazione SE37. Apri la funzione, controlli la scheda e verifichi se l'indicatore è attivo. Questo passaggio spiega molti errori di analisi: se cerchi di richiamare da remoto una funzione non abilitata, il collegamento non segue il percorso atteso. Prima di modificare il codice, controlla in SE37 e chiarisci se il modulo nasce per uso locale o per uso remoto.

Quali versioni di comunicazione RFC puoi incontrare?

La pagina elenca tre versioni di comunicazione RFC. La prima è la RFC sincrona, indicata come sRFC. Poi trovi la RFC transazionale, indicata come tRFC e descritta anche come denominazione originale della RFC asincrona. Infine trovi la RFC accodata, indicata come qRFC. Non devi considerarle sinonimi, perché i nomi indicano comportamenti diversi nel dialogo tra sistemi, anche se la pagina non dettaglia i flussi o i parametri.

Per orientarti nei programmi esistenti, ti basta associare ogni sigla al contesto in cui la trovi. Se vedi una chiamata sincrona, il programma chiamante attende la risposta del sistema remoto prima di proseguire. Se vedi riferimenti a chiamate transazionali o accodate, la logica è pensata per gestire sequenze e affidabilità in modo diverso rispetto a una semplice attesa di risposta. Quando documenti un'interfaccia, riporta sempre la sigla esatta che trovi nel codice o nella configurazione, senza tradurla in modo approssimativo.

Come dialoga SAP con un programma scritto in PHP o Java?

Le chiamate di funzione remota possono essere associate al software SAP e alla programmazione ABAP e offrono a un programma esterno il modo di usare i dati restituiti dal server. La pagina cita linguaggi come PHP, ASP, Java, C e C++. Puoi quindi trovare scenari in cui il programma esterno legge dati da SAP e scenari in cui inserisce dati negli archivi del server. In entrambi i casi SAP può comportarsi come cliente oppure come server, a seconda di chi avvia la chiamata.

Se uno dei due interlocutori non è un programma SAP, deve essere programmato in modo da poter svolgere il ruolo dell'altra parte nella comunicazione RFC. Per realizzare programmi RFC corrispondenti in sistemi non SAP, la pagina rimanda ai componenti della tecnologia di comunicazione SAP. Lo stesso principio vale al contrario: le interfacce supportate per RFC e quelle supportate per la parte grafica possono essere usate da programmi esterni per chiamare ed eseguire moduli funzione nei sistemi SAP, e allo stesso modo i programmi ABAP possono usare queste interfacce per utilizzare funzioni fornite da programmi esterni.

Cosa controlli prima di collegare due sistemi?

Prima di dire che un collegamento funziona, verifica la catena completa. Controlli che il modulo chiamato esista nel sistema remoto e che risulti registrato come remoto. Controlli che il programma chiamante usi l'istruzione CALL FUNCTION con la destinazione corretta. Controlli che l'utente tecnico abbia le autorizzazioni per eseguire la funzione nel sistema remoto e che i dati di test siano presenti in entrambi gli ambienti. Questo metodo ti evita di cercare un errore di rete quando il problema è una registrazione mancante in SE37.

Un caso particolare citato dalla pagina è SAPRFC, programma open source per sistemi *NIX e Windows che permette a PHP di chiamare un sistema SAP R/3 abilitato a RFC. Se erediti un'applicazione PHP datata che legge o scrive in SAP, verifica quale libreria usa per la connessione e quale funzione remota invoca. Puoi collegare questa verifica al lavoro di analisi degli errori con il debug, perché il punto in cui la chiamata parte e il punto in cui la risposta torna sono i due punti in cui concentrare l'osservazione quando i dati non corrispondono a quanto atteso.

Apri SE37 in un sistema di prova, cerca un modulo funzione già abilitato all'uso remoto, leggi la scheda Attributi e confronta la sua interfaccia con l'istruzione CALL FUNCTION presente nel programma chiamante.