PaaS – Un caso reale in un’azienda retail
Qualche tempo fa, ricordo di aver letto un post sul Printing as a Service (PaaS) del mio collega Brent Black. All’epoca, non avrei mai pensato di ritrovarmi coinvolto in un progetto PaaS, ma mi sono dovuto ricredere per il caso di un cliente. L’azienda desiderava flessibilità di adattamento alle nuove esigenze e semplificazione dell’infrastruttura di stampa.
Questa azienda si è rivolta a noi perché stavano sviluppando una nuova applicazione Java che crea documenti sfruttando le librerie Java tipiche per la composizione dei documenti, quali iText o Crystal Reports. Si tratta di librerie che producono documenti in formato PDF, che non è sempre il formato migliore per la stampa. I documenti erano di tipo diverso, dalle fatture alle ricevute di vendita, e contemplavano formati cartacei variabili (A4, A5, A6) con font e stili differenti. Tutti questi documenti devono poter essere stampati su una miriade di dispositivi diversi, di più fornitori, e supportare i vari linguaggi di stampa utilizzati nelle stampanti laser, termiche e altre.
Era uno scenario complesso, che avrebbe richiesto un notevole impegno di sviluppo. Oltre a creare un’applicazione Java appropriata per gestire le informazioni, l’applicazione doveva controllare dove stampare il documento e come generare i formati appropriati per ciascun tipo di dispositivo. Questo implicava la selezione del linguaggio di stampa corretto e dei comandi di stampa appropriati per ogni marca o modello di stampante. Ad esempio, per produrre documenti per formati di carta diversi sarebbe stato necessario integrare alcuni comandi della stampante per selezionare il cassetto appropriato. Tutto ciò, però, avrebbe potuto aumentare la complessità dell’applicazione e della sua manutenzione, in seguito all’aggiunta di nuove periferiche di stampa o nuovi formati di documento.
Come molte altre aziende retail, questo cliente utilizza la stampa per migliorare l’esperienza cliente al momento dell’acquisto. La generazione della ricevuta di vendita è accompagnata dalla stampa di una serie di buoni sconto e messaggi pubblicitari che sono parte integrante della transazione di vendita. La progettazione inoltre prevede che la stampa e il taglio delle ricevute avvengano singolarmente, sulle stampanti termiche del punto vendita. A differenza di altre periferiche di output, queste stampanti non utilizzano i linguaggi di stampa standard ma un linguaggio PDL (Page Description Language) speciale, utilizzato in particolare per le applicazioni di etichettatura.
Per complicare ulteriormente la situazione, questo rivenditore ha adottato alcune strategie innovative: il personale a contatto con il cliente è dotato di dispositivi palmari per assistere le vendite, può spostarsi in negozio con il cliente per aiutarlo a trovare i prodotti e inserirli rapidamente nell’ordine. Poi, al termine degli acquisti, il commesso avvicina il dispositivo palmare alla stampante predisposta, identificata mediante tecnologia NFC, e l’applicazione Java riceve l’istruzione per inviare le ricevute alla stampante selezionata.
È chiaro che un’applicazione che soddisfi tutti questi requisiti implichi difficoltà e costi elevati, in termini di sviluppo e manutenzione.
Ma se provassimo a relegare tutte queste funzioni a uno specifico livello di infrastruttura, progettato per liberare il resto del sistema da queste attività correlate alla stampa? Negli ultimi anni, abbiamo sentito e letto molto su tali servizi, spesso erogati via Internet, anziché ospitati in locale, con licenza software basata su sottoscrizione.
Ora, applicate questo concetto alla stampa. Non è difficile immaginare un servizio eseguito come singola architettura middleware comunicante con varie applicazioni. Queste possono essere eseguite su Windows, UNIX, Linux o altre piattaforme, e possono consegnare qualsiasi tipo di documento a dispositivi di stampa diversi. Il middleware deve convertire il formato nativo creato dall’applicazione in una forma pronta per la stampante e adatta al dispositivo di destinazione. È evidente che una tale soluzione semplifica notevolmente le applicazioni, rendendole più facili da mantenere nel lungo termine.
Tornando all’esempio del cliente: il software di LRS per la gestione dell’output libera dal carico della stampa le applicazioni che producono documenti in formati e linguaggi PDL diversi. Devono solo passare i dati del documento e l’ID della stampante di destinazione. Le lingue supportate dalla stampante non sono un problema, non occorre aggiungere comandi speciali dipendenti dalla periferica per specificare il cassetto di input con il formato carta appropriato, né è necessario controllare se il documento è stato stampato correttamente: queste attività possono essere gestite dal software LRS grazie a una delle tante API distribuite con il servizio. Le API possono essere utilizzate per inviare il documento e per verificare che sia consegnato l’output corretto, nei tempi e nei modi appropriati per completare il processo aziendale. Inoltre, nel momento in cui il parco stampanti venga aggiornato con nuovi modelli, è sufficiente aggiungerli al software LRS e diventano subito disponibili per la stampa.
Le informazioni presenti sulle ricevute stampate dal palmare del personale di vendita in negozio, vengono convertite dal software LRS in un PDL comprensibile dalla stampante termica del punto vendita. E non solo: la soluzione LRS raggruppa in un unico documento le ricevute di vendita e la pubblicità o i buoni sconto associati. Così l’applicazione non deve tenere traccia degli scontrini rilasciati per le singole transazioni. Infatti è sufficiente inviare i singoli scontrini al software LRS (insieme al relativo ID transazione) che li raggruppa tutti insieme, una volta ricevuta la parte finale dei dati. Il software LRS inoltre può aggiungere i comandi speciali per forzare la stampante a tagliare la carta, dopo ogni singola ricevuta. Quando il commesso avvicina il palmare alla stampante, il gruppo di ricevute è subito pronto per l’invio, senza attese e già predisposto, e l’addetto alla vendita otterrà solo i biglietti di sua competenza.
Questo esempio dimostra chiaramente che l’utilizzo del software LRS come servizio di stampa semplifica lo sviluppo delle applicazioni, riducendo il numero di attività e offrendo un migliore controllo del flusso dei documenti. I vantaggi si estendono anche agli altri sistemi, dato che tutte le stampanti LRS sono disponibili anche per altre applicazioni eseguite su piattaforme diverse. La soluzione LRS inoltre instaura un repository centrale dei driver e offre un meccanismo che tiene traccia di “chi” stampa “cosa”, nonché dei lavoratori che rispettano i criteri di stampa attuati per ridurre gli sprechi di carta. In pratica, questo approccio di Printing as a Service offre un nuovo modo di stampare, con un punto di controllo centrale per tutti i documenti dell’organizzazione.
E non finisce qui. Abbiamo avuto tutti a che fare con aziende che preferiscono inviare ricevute e altri documenti via e-mail anziché stamparli: più economico per il venditore, più pratico per il cliente e sostenibile per l’ambiente. Indirizzare le applicazioni esistenti verso una consegna elettronica dei documenti può comportare delle difficoltà, se le funzioni di stampa sono hardcoded nell’applicazione, ma una volta adottata la metodologia di Printing as a Service, si tratta semplicemente di apportare alcune modifiche alla configurazione.
Immaginate i vantaggi che la vostra organizzazione può trarre dall’adottare questo approccio di stampa orientato al servizio. Ma ora passiamo dalle parole ai fatti: è ora di realizzare il cambiamento e LRS può aiutarvi in questa missione.