Le applicazioni SAP sono in auge da molto tempo, e i documenti stampati da ancora di più. Con il passare degli anni, le varie tecnologie e gli standard si sono evoluti per permettere di stampare negli ambienti SAP. Tuttavia i problemi di stampa rimangono, specialmente nelle implementazioni complesse che si espandono attraverso molteplici nazioni e linguaggi.
Lo standard Unicode è un modo universale per codificare e presentare tutti i caratteri scritti in qualunque linguaggio del mondo. Per contasto, l’approccio più vecchio tramite codepage alla gestione del carattere internazionale è in grado di presentare solo un piccolo sottoinsieme dei possibili simboli. Esiste, per esempio, una codepage specificatamente per l’Europa Occidentale (ISO-8859-1 or CP1252), l’Europa Orientale, e per i caratteri cirillici, etc. Oltre codepage chiamati “single-byte” (che possono rappresentare un massimo di 255 caratteri), ci sono anche codepage chiamati “double-byte” per i caratteri asiatici (per esempio, GB2312) che possono rappresentare più di 60.000 simboli.
Unicode, invece, fornisce altri modi di decodifica per mostrare tutti i caratteri — i cosiddetti Formati di Trasformazione Unicode (Unicode Transformation Formats o UTF).
UTF-16 è utilizzato internamente dall’ambiente SAP, e ogni carattere usa due bytes di dati. Per la rappresentazione di Unicode formati di stampa, negli XML, e nei file HTML, invece spesso è utilizzato UTF-8. Tra le altre cose, è un modo più efficiente di rappresentare i simboli ASCII e i caratteri speciali europei.
Bene… ci sono molteplici modi di gestire i caratteri stampati. Quindi questo che cosa ha a che fare con i problemi di stampa dalle applicazioni SAP?
SAP e Unicode
SAP per primo introdusse ufficialmente il supporto a Unicode nella SAP R/3 Version 4.7C. Potè così offrire una soluzione elgante per l’inserimento e l’archiviazione dei dati con vari caratteri utilizzati nei linguaggi internazionali. Nonostante ciò, quando si devono stampare documenti con Unicode — specialmente con caratteri asiatici — vari problemi possono sorgere comunque. Due dei problemi più fastidiosi sono relativi al supporto da parte del dispositivo e ai driver di output.
Molti dispositivi infatti non sono stati creati per stampare questi caratteri a doppio byte. Se per esempio inviate un documento con caratteri giapponesi ad una stampante di medie funzionalità, il driver di stampa di SAP sostituirà qualunque simbolo non supportato con il simbolo “#”.
Inoltre SAP fornisce solamente pochi tipi di dispositivo (drivers) per stampanti speciali che supportano i caratteri asiatici o cirillici. Tra le altre cose questo significa che dovrete creare più di un tipo di dispositivo per ogni stampante fisica.
Ci sono sicuramente stampanti che supportano i font asiatici. Queste stampanti, tuttavia, sono disponibili comunemente solo nella regione asiatica. Supportano solo output di stampa che includono pagine codificate esclusivamente a doppio byte. Non sono molte le stampanti che possono gestire rappresentazioni Unicode native nella forma UTF-8. Oltre al problema del supporto ad Unicode, esiste anche il problema che queste stampanti possano incorporare font specifici di SAP quali Andale.
Questo problema rappresenta una sfida maggiore per l’utente. Se volete inviare Unicode direttamente da SAP, siete limitati ad un ristretto numero di dispositivi di output e/o di vendor di hardware. Siete legati ad una piccola gamma di modelli e di costruttori, cosa che rende difficile usare dispositivi più efficienti, in termini di costi o di opzioni migliori, da parte di altre fonti. Anche aggiornare le stampanti attuali con moduli speciali per supportare la stampa da Unicode è problematico, poichè vi lega al costruttore di quel modulo e al fornitore dei dispositivi ad esso associati.
Driver di Output
Ci sono anche alcuni aspetti da considerare dal punto di vista di SAP. Per qualunque stampante che supporti Unicode vogliate usare, ci dovrà essere uno specifico tipo di dispositivo (driver) adatto a ciascuna release di SAP. Altrimenti queste stampanti non saranno di alcuna utilità. Lo stesso dicasi delle stampanti sulle quali avete installato moduli DIMM (hardware) per permettere il supporto alla stampa Unicode. Se non esistono più driver disponibili per il vostro sistema SAP ERP, l’investimento nei moduli DIMM non ha senso.
Oltre alla disponibilità di risorse, bisogna considerare anche le problematiche relative agli sforzi amministrativi necessari per installare, configurare, testare e distribuire i driver dei dispositivi nel landscape di SAP. Non è un compito banale, date le variabili coinvolte.
Soluzione
SAP offre molteplici soluzioni a questo dilemma. Tanto per cominciare, potete usare il dispositivo SAPWIN e stampare output Unicode da Windows. Ovviamente ciò rende dipendenti dalle capacità di stampa di Windows OS. Per le versioni di SAP più recenti, è possibile utilizzare SAP UPE (Unicode Printing Enhancement, disponibile a partire da SAP NetWeaver 7.02) oppure SAP Interactive forms by Adobe (SAP ADS, disponibile a partire da SAP NetWeaver 2004). Entrambi possono rendere la stampa da Unicode possibile. Il problema di supportare differenti tipi di dispositivi in SAP tuttavia esiste ancora. Inoltre queste soluzioni non sono disponibili per tutte le versioni di SAP tuttora in uso. SAP ADS non è tanto prevalente quanto SAPScript e SmartForms, che possono o non possono essere prese in considerazione.
LRS offre una soluzione tecnica molto elegante al problema della stampa Unicode, disegnata avendo in mente l’indipendenza da qualunque piattaforma e la supportabilità futura. Le componenti Transforms di LRS rendono possibile generare caratteri Unicode in un processo software anziche hardware. Questo permette di supportare la stampa da SAP e Unicode su qualunque numero di dispositivi di output di qualunque costruttore. Hardware speciale ed aggiornamenti diventano così inutili.
Esiste anche un altro vantaggio in questa soluzione. Avete bisogno solamente di un singolo tipo di dispositivo di output SAP (driver): SAPGOFU. Questo speciale tipo di dispositivo oltre a semplificare notevolmente l’amministrazione delle stampe nel vostro ambiente SAP, riduce anche in maniera significativa il carico del server SAP, necessario per generare lavori di stampa. Il modulo Transform di LRS trasferisce il carico di lavoro al server VPSX. Risultato? Una migliore ottimizzazione delle risorse di sistema SAP e sforzi amministrativi inferiori relativi alla stampa.
Così, se dovete stampare da applicazioni SAP, avete diverse possibilità. Alcune sono migliori di altre comunque. Se state valutando i pro e i contro di ciascun approccio, contattate LRS per un consiglio. Saremo felici di potervi aiutare.