Ayuda sobre productos BOLD:
RTI – Real Time Interface
Introducción
La integración entre varios sistemas se suele plantear mediante cargas batch programadas con una frecuencia determinada. Dependiendo de la entidad a sincronizar entre las aplicaciones BOLD y los sistemas corporativos, esta frecuencia es diferente. Por ejemplo, en el caso del traspaso de días festivos, es suficiente con una o dos cargas anuales, pues se trata de una información que no suele cambiar repetidas veces. Sin embargo para entidades como los empleados en plantilla, es necesario aumentar la frecuencia, para evitar que los diferentes sistemas relacionados trabajen con información diferente.
En entornos donde se trabaja con múltiples aplicaciones interdependientes, resulta fundamental que éstas compartan los datos de la forma más rápida posible. De no ser así es inevitable que los procesos de trabajo se acaben por amoldar a la velocidad en que los datos se trasladan. Por poner un ejemplo, si la sincronización de contratos nuevos se realiza una vez al día, eso supone que tras la generación de un contrato en los sistemas de información correspondientes, resulte imposible trabajar con él desde el punto de vista de planificación hasta pasado un día, momento en el cual el nuevo contrato será trasladado a otras aplicaciones. Este problema lleva a la necesidad de incrementar la frecuencia de traspaso de datos. Al llevar esta solución al límite nos encontramos con una barrera insuperable: la duración de la tarea batch. No tiene sentido volver a lanzar una tarea antes de haber terminado su anterior ejecución. Así, si el proceso de carga de empleados dura una hora, nos veremos forzados a efectuar sincronizaciones como máximo cada hora. Lo cual es un grave inconveniente por la carga de CPU que conlleva, siendo ésta, continua y afectando directamente a los usuarios. Al existir estas dificultades, tanto de limitación en la frecuencia máxima y de consumo de CPU elevado, es necesario plantearse otro método de sincronización de sistemas cuando el tiempo resulta un factor fundamental a la hora de trabajar con varias aplicaciones que comparten datos.
BOLD Real Time Interface aparece por la necesidad de conseguir una integración incremental y en tiempo real de las aplicaciones BOLD con los sistemas corporativos del cliente. La idea es transferir la información en el mismo momento en que ésta se introduce en alguna de las aplicaciones implicadas en el proceso de sincronización. Con ello conseguimos, por una parte que el proceso sea incremental (solo transferimos la entidad afectada), logrando por tanto que los requerimientos de CPU sean mucho menores, y por otra parte, conseguimos también que la información esté disponible en los diferentes sistemas de forma inmediata, pues la transferencia se inicia justo cuando se produce un cambio en alguno de los sistemas. BOLD Real Time Interface se ocupa de almacenar, traducir y transmitir de forma ordenada los mensajes que se producen en las diferentes aplicaciones de forma que todas ellas se encuentren sincronizadas.
El sistema BOLD Real Time Interface
BOLD Real Time Interface utiliza protocolo SOAP para recibir los mensajes procedentes de las diferentes aplicaciones. Estos mensajes se reciben a través de una serie de WebServices publicados directamente por el servidor BOLD RTI. Existe la posibilidad de comunicar la nueva información directamente sobre una base de datos SQL Server. BRTI es un servidor de webservices que se instala como servicio de sistema y permanece a la espera de que le sea comunicada información a transmitir al resto de aplicaciones. El sistema permite la recepción de los mensajes en cualquier formato (siempre dentro de los standards XML), pues antes de que los mensajes sean enviados a los destinatarios, se efectúa una, o varias, traducciones. De esta forma al contar con BRTI como intermediario a la hora de transmitir información aseguramos las transformaciones necesarias para trasladar un mismo dato que en varias aplicaciones se representa de forma diferente.
Arquitectura del sistema BOLD RTI
Es importante comprender que BOLD RTI es un sistema bidireccional, con lo cual los mensajes pueden partir tanto de las aplicaciones BOLD y continuar con el traslado de información hacia el resto de sistemas corporativos como en sentido contrario. Podría darse el caso incluso de utilizar BRTI para comunicar dos sistemas corporativos entre sí, sin necesidad de que intervengan en el proceso otras aplicaciones BOLD aparte de BRTI. La dirección y procedencia de los mensajes se indican mediante información extra que añaden los emisores a los mensajes SOAP.
Detalles de funcionamiento
Estados:
Cada operación del RTI tiene asociado un estado que indica como se encuentra actualmente. Los diferentes estados posibles y su significado se explican a continuación:
- Estado = 0 (Pendiente de validar); Son aquellas operaciones que han llegado a la BD pero que no han sido confirmadas como tratables y por tanto se omiten.
- Estado = 1 (Validado); Es el primer estado en que figuran las operaciones cuando llegan al BRTI. Son operaciones completamente pendientes de tratar.
- Estado = 2 (Transformado); Aparece normalmente despues del estado 1. Se corresponde con las operaciones a las que se les ha aplicado su transformación, quedando entonces pendiente solamente el envío del mensaje.
- Estado = 3 (Encolado); No se utiliza.
- Estado = 4 (Enviado); Este estado indica que una operación se ha enviado correctamente al otro sistema y estamos esperando su ACK (negativo o positivo). Los mensajes que viajan desde un sistema externo a WP no utilizan este estado pues WP no retorna ACK.
- Estado = 5 (Error); Este estado indica que se ha producido un error durante el tratamiento del mensaje.
- Estado = 6 (Descartado); La operación se ha descartado manualmente, esta marca indica que no se ha de tratar.
- Estado = 7 (Correcto); La operación ha completado todas sus etapas y se puede considerar como completada.
Recepción:
Tal y como se ve en el gráfico, BRTI comienza su secuencia de trabajo al recibir un mensaje webservice. Este mensaje WebService ha de contener:
- Información acerca del origen del mensaje.
- Destino deseado del mensaje (puede ser múltiple)
- Tipo de entidad. (por ejemplo… calendarios)
- Identificador de objeto. (por ejemplo… 000654)
- Contenido con información de la operación (alta, baja, modificación…)
Validación
Una vez el mensaje ha llegado al servidor BRTI se efectúan unas validaciones técnicas básicas que indicarán si almacenamos el mensaje como adecuado para ser tratado o se ha de rechazar:
- El origen y el destino han de estar definidos como válidos en BRTI.
- El mensaje XML ha de ser válido.
- No pueden existir operaciones sin completar en BRTI sobre el mismo objeto y que tengan diferente origen. (Ver punto 3.4. Gestión de colas)
Si el mensaje que se ha recibido pasa estas comprobaciones, será grabado en la base de datos de BRTI, para que posteriormente sea transformado y transferido al destino correspondiente.
Tanto si la validación acaba correctamente como si no lo hace, se informa al sistema de origen del mensaje. Si se ha producido un error, es necesario comunicarlo para que al emisor le conste que ha de realizar alguna acción (modificar algún dato, comprobar las comunicaciones, esperar a que todas las operaciones con otro origen se completen…) y volver a repetir el mensaje. Si se ha conseguido almacenar el mensaje correctamente en BD, lo comunicaremos también para que el emisor del mensaje pueda dar por válida su operación.
Gestor traducción
De forma continua, BRTI procesa los mensajes. –Incompleto-…
Gestión de colas
TBF
Requerimientos técnicos
BRTI en su modo más básico necesita únicamente de la instalación de MS SQL Server. Sin embargo, dependiendo de la complejidad de las transformaciones necesarias para traducir los mensajes que se intercambiarán las aplicaciones, es posible necesitar • Windows Script 5.6 (o superior) • MSXML4 (o superior) • BOLD XML (Para comunicar los mensajes con aplicaciones BOLD APS/WP)
Configuración de BOLD RTI
Instalación
TBF
Árbol de instalación
TBF
Carpetas de integración
TBF
URL’s WP y EXT
Para poder modificar las URL’s donde se envían los mensajes, hay que entrar en Workplanner e ir al icono: 
(actualizar icono)
Existen dos nodos “ConfigSystem” uno para cada sentido de la comunicación.
- EXT-WP: entrada de información de un sistema externo hacia WorkPlanner
- WP-EXT: envío de información de WorkPlanner hacia un sistema externo
La variable “ComunicationDir” de los nodos “ConfigSystem” nos indica donde están los ficheros de importación, en esas ubicaciones debe existir un bat llamado configure.bat que defina las variables de configuración.
Las variables relevantes para indicar los sistemas a comunicar son:
- SERVER_SAP: establece si la comunicación será con un servidor de SAP de productivo, desarrollo, integración, etc.
- BOLD_WP_SERVER: indica con que servidor WorkPlanner se está realizando la comunicación.
IMPORTANTE: como existen dos ComunicationDir diferentes, existirán dos configure.bat, uno en cada ubicación. Es importante modificar las variables existentes en ambos ficheros de configuración para que el sistema conserve su coherencia.
Nota: Los paths mencionados se pueden encontrar en la máquina de instalación de BRTI. Sólo existe una instalación de BRTI en cada máquina, por lo que se ha de tener en cuenta a cual se está accediendo antes de modificar los valores de las variables.