Recuerdo que, hace algún tiempo, leí un blog sobre la impresión como servicio (PAAS, por sus siglas en inglés) de mi compañero Brent Black. En aquel momento, nunca imaginé que participaría en un proyecto basado en PAAS, pero un ejemplo reciente de un cliente cambió todo esto. Las ventajas que buscaba la compañía eran la flexibilidad para adaptarse a nuevas necesidades y la simplificación de su infraestructura de impresión.
Esta compañía minorista nos contactó porque estaban desarrollando una nueva aplicación Java que crea documentos usando las típicas bibliotecas Java para redactar documentos como iText o Crystal Reports. Estas bibliotecas producen documentos en formato PDF, que no siempre es el mejor formato para imprimir. Los tipos de documentos abarcaban desde facturas hasta recibos de compra, y contenían diferentes formatos de papel (A4, A5, A6) con diferentes fuentes y estilos. Todos estos documentos deben ser capaces de imprimir en miles de dispositivos de impresión diferentes fabricados por múltiples proveedores y soportar los diferentes lenguajes de impresión usados en impresoras láser, impresoras térmicas y otras.
Este escenario complejo requería un enorme esfuerzo de desarrollo. Además de crear una aplicación Java adecuada para gestionar la información, la aplicación tenía que controlar dónde imprimir el documento y cómo generar los formatos de documentos adecuados para cada tipo de dispositivo. Esto implica seleccionar el lenguaje de impresora correcto, así como los comandos de impresora adecuados para cada marca o modelo de impresora. Por ejemplo, producir documentos para diferentes formatos de papel requiere integrar un conjunto de comandos de impresora para seleccionar la bandeja de impresora adecuada. El riesgo es que esto provocaría que la aplicación fuera cada vez más compleja y difícil de mantener cuando se añaden nuevos dispositivos de impresión o se crean nuevos formatos de documentos.
Como muchas otras compañías minoristas, este cliente utiliza la impresión para optimizar la experiencia del cliente en el punto de compra. Cuando se genera un recibo de compra, también se imprimen una serie de cupones de descuentos y mensajes de marketing, como parte de la transacción de venta. Estos recibos están diseñados para ser impresos y recortados individualmente en las impresoras térmicas del punto de venta. A diferencia de otros dispositivos de Output, estas impresoras no utilizan lenguajes de impresión estándar sino un lenguaje especial de descripción de página (PDL, por sus siglas en inglés) que se usa principalmente para aplicaciones de etiquetado.
Para complicar las cosas todavía más, este minorista ha utilizado innovaciones como proporcionar dispositivos PDA al personal que trabaja de cara al cliente para fomentar las ventas. Esto les permite moverse por todas partes con el cliente mientras miran productos y añadirlos al pedido del cliente sobre la marcha. Cuando el cliente ha acabado de comprar, el vendedor lleva la PDA cerca de la impresora donde se suponen que deben imprimirse todos los recibos. Gracias al uso de la tecnología NFC, se identifica la impresora y la aplicación Java se usa para enviar todos los recibos hacia la impresora seleccionada.
Sin duda, todas estas necesidades provocan que la aplicación sea más difícil y cara de desarrollar y mantener con el paso del tiempo.
¿Pero qué sucedería si relegamos todas estas funciones a una capa de infraestructura específica diseñada para aliviar el resto del sistema de estas tareas relacionadas con la impresión? En los últimos años, hemos escuchado y leído sobre muchos servicios de este tipo, suministrados a menudo a través de Internet en lugar de alojados de forma local, en que el software se comercializa a través de una suscripción.
Ahora aplique este concepto a la impresión. Uno puede imaginar fácilmente un servicio que se ejecute como una única arquitectura de middleware que se comunica con varias aplicaciones. Estas aplicaciones pueden ejecutarse en Windows, UNIX, Linux u otras plataformas y enviar cualquier tipo de documento a diferentes dispositivos de impresión. El middleware necesita convertir el formato nativo creado por la aplicación en un formato listo para imprimir adaptado al dispositivo de destino. Una solución de este tipo simplifica drásticamente las aplicaciones, lo cual facilita su mantenimiento a largo plazo.
Volviendo al ejemplo del cliente... usando el software de gestión de Output de LRS, las aplicaciones que producen documentos en diferentes formatos y PDL se liberan de la carga de la impresión. Solo necesitan pasar los datos del documento y el identificador de la impresora de destino. No es necesario preocuparse por qué lenguajes son compatibles con la impresora, ni es necesario añadir comandos especiales dependiendo del dispositivo para especificar qué bandeja de entrada contiene el tamaño de papel apropiado, ni tampoco es necesario comprobar si el documento se ha impreso correctamente. El software de LRS puede gestionar todas estas tareas usando una de las muchas interfaces de programación de aplicaciones (API, por sus siglas en inglés) distribuidas con el servicio. Estas API pueden usarse no solo para enviar el documento sino también para comprobar que se ha enviado el Output adecuado a tiempo y en la forma adecuada para completar el proceso de negocio. Además, cuando se añaden nuevos modelos de impresora a la flota, están disponibles para impresión en cuanto se añaden al software LRS.
En el caso de los recibos de compra que los empleados móviles imprimen desde sus PDA, el software LRS convierte la información a un PDL que la impresora térmica del punto de venta puede entender. También agrupa los recibos de compra y los cupones o la publicidad relacionados en un único documento. De este modo, la aplicación no necesita controlar qué recibos se han enviado para cada transacción. Basta con enviar cada recibo a la solución LRS (junto con el identificador de la transacción asociada) y dejar que el software LRS los agrupe cuando se recibe el último paquete de datos. El software LRS también puede añadir los comandos especiales que se necesitan para forzar a la impresora a cortar el papel tras cada recibo individual. Así que, ahora, cuando el vendedor camina hasta la impresora con su PDA, el paquete de recibos está listo para ser enviado a la impresora sin demora y combinado en un único paquete. Esto garantiza que cada vendedor recibe solo los recibos que está esperando.
Este ejemplo muestra cómo el uso del software LRS como servicio para imprimir puede simplificar el desarrollo de aplicaciones al reducir la cantidad de tareas y proporcionar un mejor control del flujo de documentos. Las ventajas se extienden también a otros sistemas, puesto que todas las impresoras definidas por LRS también están disponibles para las otras aplicaciones que se ejecutan en diferentes plataformas. La solución LRS también establece un repositorio centralizado de controladores y un mecanismo para rastrear quién imprime qué, así como qué trabajadores cumplen las políticas de impresión diseñadas para reducir el gasto de papel. En resumen, este enfoque de impresión como servicio establece una nueva forma de imprimir que proporciona un punto central de control para todos los documentos de la organización.
Y esto no acaba aquí. Todos hemos experimentado compañías que prefieren enviar recibos y otros documentos por correo electrónico en lugar de imprimir: es más barato para el proveedor, más sencillo para el cliente y mejor para el medio ambiente. Cambiar las aplicaciones existentes por un envío electrónico de documentos puede ser complicado si las funciones de impresión están configuradas en la aplicación mediante código. Pero si ya ha adoptado una metodología de impresión como servicio, es simplemente una cuestión de realizar unos pocos cambios en la configuración.
Imagine las ventajas para su organización de adoptar un enfoque de impresión orientado al servicio. Ahora deje de imaginar y póngase manos a la obra. Es momento de hacerlo realidad y LRS puede ayudarle a lograrlo.