Trasferire file da e verso un sistema SAP

Per spostare un file con un programma ABAP hai tre strade: scrivere sul file system dell'application server con OPEN DATASET, TRANSFER e CLOSE DATASET, passare dal computer dell'utente con GUI_UPLOAD e GUI_DOWNLOAD, oppure far uscire il file dal sistema con SAPFTP, una condivisione di rete o uno strumento esterno come SFTP. La scelta dipende da dove deve arrivare il file e da chi lo deve leggere.

Dove vivono i file che un programma ABAP può toccare

Un programma ABAP vede due mondi distinti. Il primo è il file system dell'application server, ispezionabile con la transazione AL11: i dataset scritti qui restano sulla macchina che esegue il programma e restano raggiungibili dai job in background anche quando nessun utente è collegato. Il secondo è il computer da cui l'utente lavora con SAP GUI, dove i file stanno nelle sue cartelle e possono viaggiare solo attraverso i metodi previsti per il dialogo. Confondere i due piani è l'errore più comune: un job schedulato di notte non può leggere il disco di un PC spento, e un report pensato per il desktop non trova la directory del server.

La distinzione conta anche per i permessi. Sull'application server il programma eredita i diritti dell'utente di sistema che fa girare SAP, non quelli di chi ha lanciato il report, mentre sul client valgono i permessi dell'utente di SAP GUI. Prima di progettare un trasferimento conviene chiedersi in quale dei due mondi il file deve nascere e in quale deve essere consumato.

Quando il file deve uscire verso un'altra macchina, metà del lavoro non è ABAP: montare una condivisione, schedulare un rsync sopra SSH o verificare una somma di controllo sono operazioni di sistema, non di programma. Il giornale pratico in inglese trasferimenti diretti con rsync e SSH copre proprio questo versante, con guide su condivisioni Samba tra Linux e Windows, copie senza cloud e controlli di integrità che completano il dataset prodotto dal tuo report.

Come funzionano OPEN DATASET e TRANSFER?

L'istruzione OPEN DATASET apre un file sull'application server, in lettura o in scrittura, in modalità testo oppure binaria. TRANSFER scrive una struttura o una riga nel file aperto, READ DATASET legge il contenuto in una variabile, CLOSE DATASET chiude il file e DELETE DATASET lo elimina. Uno scenario tipico è il job notturno che produce un file CSV o a lunghezza fissa in una directory convenuta, pronto per essere raccolto da un altro sistema o da un collega.

Sul lato client il passaggio avviene invece con i metodi della classe CL_GUI_FRONTEND_SERVICES, eredi dei moduli funzione GUI_UPLOAD e GUI_DOWNLOAD che si incontrano ancora nel codice più vecchio. Il file attraversa SAP GUI e quindi richiede un utente collegato: questa via non esiste per l'elaborazione in sfondo. Quando studi come arrivare al file partendo dai dati, vale lo stesso ordine usato per le tabelle e le viste del Dictionary: prima capisci dove stanno i dati, poi decidi come muoverli.

Cosa succede quando il file esce da SAP?

SAP include un meccanismo FTP nativo: la libreria SAPFTP, con moduli come FTP_CONNECT, FTP_SERVER_TO_R3 e FTP_COMMAND, sposta file verso un server FTP raggiunto tramite le destinazioni RFC SAPFTP o SAPFTPA. Funziona ancora, ma il protocollo FTP viaggia in chiaro e molte aziende lo hanno dismesso. Per SFTP non esiste un'istruzione ABAP diretta: si passa da un comando del sistema operativo schedulato sul server, da un middleware come SAP Process Integration oppure da un gateway esterno che parla con entrambi i mondi.

Quando conviene una condivisione di rete invece di un protocollo?

Se il sistema SAP e il destinatario vivono nella stessa rete aziendale, montare una condivisione NFS o SMB sull'application server è spesso la via più semplice: OPEN DATASET scrive in una directory che dall'altra parte appare come una cartella condivisa. I vantaggi sono zero destinazioni RFC da configurare e permessi gestiti dal sistema operativo; il limite è che la condivisione deve restare montata e protetta, altrimenti il job fallisce in silenzio o scrive nel punto sbagliato.

Per i flussi ricorrenti la coppia dataset più script esterno batte quasi sempre il trasferimento interattivo: il programma scrive, uno script fuori da SAP sposta e verifica, e i due log insieme raccontano dove si è fermata la catena. La stessa cura per i punti di contatto serve quando progetti chiamate BAPI e RFC tra sistemi, perché un file consegnato a metà crea gli stessi problemi di una risposta remota mai arrivata.

Come controlli che il trasferimento sia riuscito?

Dopo ogni istruzione sui dataset controlla SY-SUBRC, e dopo ogni chiamata ai moduli FTP leggi il codice di ritorno e il testo dell'errore. Sul file arrivato verifica almeno la dimensione, e meglio ancora una somma di controllo concordata con chi lo consuma: un file da zero byte è un trasferimento riuscito solo a metà, e chi lo legge a valle lo scopre prima di te. Quando qualcosa non torna, l'analisi degli errori con il debugger mostra in quale istruzione il flusso si interrompe davvero.

Quali limiti non perdona il file system del server?

L'application server non è un file server: lo spazio è condiviso con tutto il sistema, i percorsi cambiano tra sviluppo e produzione e i nomi assoluti non vanno mai scritti nel codice. I percorsi logici si definiscono con la transazione FILE e si risolvono a run time, così lo stesso programma scrive in posti diversi a seconda del mandante. Le destinazioni e le configurazioni che fanno parte del flusso viaggiano con gli ordini di trasporto tra i mandanti, e un percorso logico dimenticato nel trasporto è una causa classica di job fallito in produzione.

La pagina di Wikipedia dedicata al File Transfer Protocol ripercorre il protocollo su cui si appoggia SAPFTP, le modalità attiva e passiva e i motivi per cui il traffico in chiaro lo ha reso fragile nei contesti moderni. È la fonte di riferimento di questa guida e un buon punto di partenza prima di scegliere se il tuo flusso merita un protocollo diverso: File Transfer Protocol.