cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

400450303. La automatización de procesos nunca había sido tan valiosa

Escrito por Redacción en Secciones
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

Por Hernán Sabaté Marconi

El procesamiento batch hace mucho que ha dejado de ser terreno exclusivo del mainframe. En la actualidad, la ejecución automática de programas es una práctica establecida también en sistemas Unix, Linux y Windows y es más, tales tareas no están circunscritas dentro de los límites de una única plataforma. La gestión de estos procesos complejos requiere una tercera generación de planificadores de tareas. Estos controlan todos los procesos no interactivos, y por ende planificables, de toda la compañía desde una ubicación central –y son escalables y activados por eventos–.

El procesamiento batch no es lo que era. Durante mucho tiempo, los datos de gran volumen fueron procesados exclusivamente en el mainframe. Y este enfoque de “procesamiento en grandes volúmenes”, donde cada paso de programa individual era ejecutado periódicamente sin la interacción de ningún usuario, ha sido altamente satisfactorio.

La mejor manera para manejar procesos que contienen un volumen intensivo de transacciones es mediante su automatización completa, ya que cualquier interacción interrumpiría su flujo – sin mencionar el hecho de que todo diálogo entre usuario y máquina es relativamente caro y propenso al error-.

En particular, los sistemas informáticos grandes (y críticos para el negocio de las empresas) han permanecido fieles al método de procesamiento batch, mientras que otros rincones del mundo de las TI se entusiasmaban con el uso abundante de interfaces de usuario, GUIs y “clicks” de ratón.

((El procesamiento batch no es lo que era. Durante mucho tiempo, los datos de gran volumen fueron procesados en el mainframe))

Independientemente de que la tarea en cuestión suponga la consolidación de los ingresos en efectivo de una filial, la entrada de pedidos o la impresión de recibos, cuando esta conlleva un procesamiento de grandes volúmenes de datos tan rápidamente como sea posible, el procesamiento batch no tiene competidor. Por esta razón, una división del trabajo fue establecida entre lo interactivo y el batch: lo que captura un usuario y en lo que trabaja sobre la pantalla durante el día es procesado, registrado, etc. en una operación aparte durante la noche, cuando las pantallas se apagan.

Esta es la razón de que, incluso cuando uno realiza operaciones bancarias online en su cuenta, estas sólo tienen efecto al día siguiente. De forma particular, en grandes empresas como bancos, aseguradoras y entidades públicas, el procesamiento batch continúa siendo la parte fundamental de sus TI. El resultado es que más de dos tercios de todos los procesos de TI funcionan en batch.


El procesamiento batch empezó a perder su buena imagen cuando aparecieron los ordenadores personales. Desde su mismo inicio, en estas plataformas los trabajos batch jugaron un rol secundario. Por supuesto, incluso bajo MS-DOS había archivos con la extensión .bat, pero para la mayoría de usuarios el procesamiento batch mediante Autoexec.bat nunca fue satisfactorio. Las “killer aplications” del mundo del PC siempre fueron interactivas y basadas en atractivos cuadros de diálogo. Tan pronto como el PC se estableció en la informática empresarial, los nuevos tópicos empezaron a estar de moda también en este ámbito.

La “usabilidad” era el quid de la cuestión, y con la “información al alcance de los dedos” se podían poner en marcha las cosas más alucinantes con tan sólo un clic del ratón (pero, naturalmente, no por el arranque de una tarea batch). Al mismo tiempo se demandaba la disponibilidad de la información de una manera rápida, esto es que los sistemas de gestión de información requerían disponer de sus datos de forma inmediata.

Cuando la policía quiere saber quién es el propietario de un vehículo quiere tener la respuesta de forma inmediata en sus pantallas. No quiere esperar a que todas las preguntas sobre propietarios de vehículos de toda España se procesen durante la noche funcionando en batch (posiblemente con un rendimiento altísimo pero demasiado tarde). Y cuando SAP diseñó su R/3 como un sistema basado en diálogos, a muchos les pareció el anuncio del fin del procesamiento batch.

Soplan nuevos vientos para el procesamiento batch

De hecho ocurrió todo lo contrario: la automatización de procesos batch nunca había sido tan valiosa como lo es hoy. Los trabajos batch no sólo aumentaron cuantitativamente, sino que también son hoy más grandes, más complejos y más numerosos que nunca. Incluso su peso relativo ha ido aumentando en la medida que las empresas buscan automatizar sus procesos de TI cada vez más y, por consiguiente, sustituir procedimientos interactivos por tareas que no lo son.

Aparecen nuevos cuellos de botella porque la noche es demasiado corta para la gran cantidad de nuevas tareas batch. Además, los procesos batch siguen extendiéndose a sistemas y plataformas en los que originalmente no estaban presentes: recientemente hemos visto usar extensivamente el procesamiento batch incluso en sistemas de PC’s. ¿Cómo se puede haber llegado a esta situación?

La muerte prematuramente anunciada del procesamiento batch estuvo basada en un malentendido. R/3 es de verdad un sistema interactivo pero también tiene un significativo componente batch para su procesamiento interno: tomemos como ejemplo los SAP info packages y SAP process chains.

((Los trabajos batch no sólo aumentaron cuantitativamente, sino que también son hoy más grandes, más complejos y más numerosos que nunca))

A pesar de esto, muchos expertos opinaban que la introducción de R/3 supondría el fin del procesamiento batch. El gran malentendido sobre el batch se debe al hecho de que para alguien de fuera, el procesamiento batch es tan efectivo como invisible. Los procesamientos batch son una materia para gente especializada, lo cual es de esperar debido a la naturaleza de los mismos: no tienen ningún usuario en el completo sentido de la palabra.

Realmente las tareas batch le preocupan sólo a un puñado de desarrolladores y administradores de sistemas. Además, debido a la carencia de una interfaz de usuario, los programas batch son generalmente menos propensos a errores, e incluso los fallos que a veces les ocurren normalmente no se perciben fuera del departamento de TI. Así que… ¿qué hay allí para dar que hablar a los usuarios finales, la dirección y el público de las TI en general?

Si un golpe de aire fresco está soplando sobre el mundo del batch, no es porque ahora de repente se esté publicitando el batch, sino porque los cambios masivos que han ocurrido en las TI durante los pasados años también han creado nuevas condiciones operacionales para el procesamiento batch. Así, muchas aplicaciones de negocio críticas se han movido de sus ambientes tradicionales y han migrado a otras plataformas más baratas – por ejemplo, de VSE, VMS, AS/400 ó HPe3000 hacia Unix, Linux y Windows.

Debido a que los usuarios de las aplicaciones quieren, por motivos de coste, seguir operando con las menores modificaciones posibles, las grandes aplicaciones batch de repente se han encontrado ejecutándose sobre lo que antes eran plataformas ajenas a ellas. Por ejemplo, en Suiza recientemente se ha comenzado a calcular pagos de pensiones mediante procesos batch en servidores Windows después de trasladar el programa Cobol pertinente.

((Si un golpe de aire fresco está soplando sobre el mundo del batch, no es porque ahora de repente se esté publicitando el batch))

Y esto no se para con la invasión de nuevas plataformas. Los nuevos sistemas a menudo conviven lado a lado con los ya existentes. En este caso, las tareas batch pueden funcionar a lo largo de varias plataformas totalmente dispares; por ejemplo, desde sistemas transaccionales CICS sobre un mainframe siguiendo por un sistema SAP funcionando en Linux y un datawarehouse en Unix para finalizar en un sistema de gestión de documentos que funciona en Windows.

Tal mezcla de plataformas y sistemas no es nada nuevo hoy en día; de hecho es bastante normal en casi todas las empresas. Los procesamientos batch son consecuentemente más complejos.

Otro factor en el nuevo papel del procesamiento batch son los modernos modelos de negocio como el e-commerce o el e-procurement por un lado, y las nuevas tecnologías como el data warehousing, EDI y XML ó RFID por otro. Ambos grupos dan lugar a un aumento masivo en la cantidad de datos y en el número de transacciones que un modo interactivo no podría jamás manejar. Ya sea que estén basadas en caracteres o en una Interfaz gráfica de usuario (GUI), las TI interactivas alcanzan su límite técnico en tales áreas de aplicación. Pero las consideraciones económicas también cuentan.

Por motivos de costes, las empresas están intentando automatizar sus procedimientos de TI donde quiera que sea posible; cuanto menos interacciones haya involucradas en un proceso de negocio, éste será más barato y su posibilidad de error será menor. Las tareas batch son considerablemente más fáciles de parametrizar y controlar que las sesiones interactivas.

La tendencia hacia la automatización es también, y siempre lo ha sido, una tendencia que lleva naturalmente hacia el procesamiento batch. Si los datos de gestión pueden ser intercambiados directamente entre los ERP’s de empresas diferentes, no hay obviamente ninguna necesidad de que los datos sean extraídos manualmente de documentos comerciales, pero las tareas batch si son necesarias para procesar los datos importados.

Planificación de tareas de tercera generación

Los cambios en el batch naturalmente también afectan a los sistemas de planificación de tareas, que deben ser capaces de adaptarse a los nuevos requerimientos. Mientras el procesamiento batch fue coto exclusivo de sistemas mainframe u otros sistemas propietarios de rango medio, la mayoría de las herramientas habitualmente disponibles en ellos para definir, supervisar y controlar tareas fueron suficientes.

La planificación de tareas podía permanecer tan propietaria como los sistemas en los cuales se ejecutaba. Como esta situación ha cambiado, los planificadores de tareas deben seguir la misma evolución. Los planificadores de tareas deben ser independientes de la plataforma en que se ejecutan, y neutrales en cuanto a su fabricante, de la misma forma que los procesos ya no permanecen confinados dentro de las fronteras de un único sistema.

Los planificadores de tareas tradicionales, como el espartano comando “cron” de Unix o el mas serio “Advanced Job Scheduler” del AS/400, ya no son suficientes para controlar trabajos complejos, multiplataforma o funcionar ejecutar aplicaciones pre-existentes que de repente se encuentran ejecutándose sobre un servidor Windows.

Muchos usuarios que han migrado de aplicaciones desde por ejemplo sistemas HPe3000 a nuevas plataformas han aprendido que un planificador de tareas no está incluido automáticamente en su nuevo sistema operativo pero debe ser comprado e implementado de manera separada. En muchos casos, incluso la planificación de tareas batch complejas aún se sigue haciendo mediante soluciones anticuadas provenientes del mundo del mainframe o planificadores de tareas caseros.

((Los planificadores tradicionales habitualmente eran activados por condiciones de tiempo pero las soluciones modernas deben ofrecer algo más que esto))

Esto pone en juego a nuevos planificadores de tareas de última generación, la tercera generación. Estos planificadores, como Dollar Universe de ORSYP, no son sólo extensiones de un sistema operativo dado. Ofrecen soluciones autónomas, independientes de las plataformas donde se ejecutan y distribuibles, cubriendo adecuadamente todo el entorno actual en el que las tareas batch operan.

Son capaces de supervisar y gestionar todas las tareas batch que se ejecutan en los distintos sistemas desde una consola central; evitando de este modo los problemas que normalmente surgen cuando las secuencias de tareas cruzan los límites entre sistemas (por ejemplo una tarea SAP funcionando en Linux a la que se debe seguir una impresión en Windows).

El usuario consigue un mejor control, más eficacia en sus operaciones de TI, menos errores, menos crashes, menores tiempos muertos de inactividad, etc. Básicamente obtiene un sistema de procesamiento batch más fiable y eficiente.

Los planificadores tradicionales habitualmente eran activados por condiciones de tiempo pero las soluciones modernas deben ofrecer algo más que esto. Fecha y hora es, demasiado elemental para ser la única base de ejecución de los procesos complejos del moderno mundo de las TI, donde hay una necesidad de controlar trabajos de una manera mucho más sofisticada.

Para las cadenas de procesos complejas y redes de trabajo que se encuentran en las aplicaciones modernas, y que son rasgos comunes de las aplicaciones SAP por ejemplo, una planificación activada por eventos es esencial.

Esto permite que las tareas batch sean desencadenadas, por ejemplo, cuando se solicitan determinados recursos, se reciben correos electrónicos concretos, o cuando los fallos o eventos programados como los eventos SAP se producen en las aplicaciones. La ejecución automatizada de tareas no se concibe sin una planificación dirigida por eventos. Sin ella aumenta la posibilidad de tiempos muertos, fallos, retrasos y deadlocks.

Los planificadores de tareas profesionales de tercera generación – continuación de soluciones basadas en scripting y/o en herramientas de plataformas específicas – deben apoyar al procesamiento batch en su nuevo rol ampliado y en su mayor criticidad para las TI. Para que esto ocurra, las siguientes características son esenciales:

– Independencia de la plataforma.
– Operación distribuida con una estructura de control centralizada.
– Escalabilidad.
– Ejecución activada por calendario y por eventos.

Un planificador de tareas moderno, desde luego que debe tener una interfaz de usuario funcionalmente avanzada y fácil de usar para controlar y supervisar todos los procesos. Y los usuarios también necesitan herramientas para generar informes de ejecución detallados para que, en primer lugar, los procesos implicados en procesamientos batch siempre deben trazables y, en segundo lugar, los administradores de sistemas puedan identificar tendencias (por ejemplo en factores clave como la carga o el uso de recursos).

Podría ser un desastre encontrarnos de un día para otro y sin previo aviso que la ventana disponible para realizar backups o imprimir extractos bancarios se nos ha quedado insuficiente.

Como el rango funcional de los procesamientos batch y la variedad de plataformas involucradas se ha extendido por todo el espectro de la informática profesional, el ámbito operacional del planificador de tareas también se amplió. Lo que una vez fueron productos para un nicho se han convertido en herramientas estándar usadas por empresas de todo tipo y tamaño. Y solo las soluciones de tercera generación son capaces de solucionar las tareas a las que nos enfrentamos de manera eficiente y por lo tanto barata. DDJ

Hernán Sabaté Marconi, Operations Manager de ORSYP Ibérica.

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.