Los ejemplos de Procesador TLOG ofrecen las siguientes características:
Los ejemplos de Procesador TLOG muestran cómo recibir y procesar los mensajes de las aplicaciones de minorista ACE, GSA o SA de IBM utilizando conjuntos de mensajes de TLOG. Los mensajes pueden tener los formatos siguientes de estas aplicaciones:
Estos mensajes se transforman en POSLog XML utilizando los flujos de mensajes de ejemplo TLOG. Los flujos de mensajes de ejemplo TLOG Retek transforman el formato POSLog XML a formato Retek y los flujos de mensajes de ejemplo TLOG ARTS almacenan la información de transacciones de una base de datos ARTS en el formato necesario para los estándares de despensa de datos. Cada ejemplo proporciona un recurso opcional para supervisar las actividades de transacciones de minorista, que almacena la información de transacciones en una base de datos de supervisor. Estas funciones se proporcionan creando los conjuntos de mensajes, los subflujos, las hojas de estilo, las tablas de base de datos y los flujos de mensajes de TLOG necesarios.
IBM ha aumentado los archivos de Esquema XML de POSLog v1.0 y v2.2.1 con ampliaciones para soportar las transacciones que se originan en dispositivos de punto de venta de IBM. Estas ampliaciones de IBM también permiten a los clientes añadir sus propios campos a la transacción, utilizando la característica xs:any (elemento comodín) de Esquema XML. El dominio XMLNSC, que procesa transacciones POSLog XML, implementa por completo las normas de Esquema XML 1.0, incluyendo un conjunto conocido como normas UPA (Unique Particle Attribution). Algunas de las ampliaciones de comodín de los archivos de Esquema XML de POSLog v1.0 violan una de las normas UPA y los conjuntos de mensajes de POSLog v1.0 proporcionados con este ejemplo se han modificado para corregir esta violación. Sin embargo, el resultado es que a veces un campo definido por el cliente de una transacción de POSLog v1.0 puede producir un error de validación durante el proceso por parte del dominio XMLNSC. Si se produce un error de validación, desactive la validación en el punto apropiado del flujo de mensajes. Una anomalía de validación de este tipo se indica mediante un mensaje BIP5902 seguido de otros mensajes BIP5xxx que detallan la anomalía precisa.
Si está utilizando los SupportPacs IA62 o IA64, puede sustituir los flujos de mensajes existentes por los flujos de estos ejemplos.
Se proporcionan dieciocho flujos de mensajes de ejemplo de TLOG, nueve para TLOG v1.0 y nueve para TLOG V2.2.1, para mostrar las siguientes funciones:
TLOG_ARTS: Estos flujos de mensajes de ejemplo se crean para procesar los mensajes TLOG de los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML que proceden de las aplicaciones de minorista de IBM ACE, GSA y SA. También transforma el mensaje a POSLog XML y llena los datos de transacción POSLog XML en una base de datos ARTS según lo requiera la despensa de datos TLOG en el formato de modelo de datos ARTS (Association for Retail Technology Standards) estándar de la industria. Este release sigue el modelo de datos ARTS 4.01. Se proporciona un flujo de supervisor TLOG opcional con cada ejemplo para realizar la medición de servicio de los mensajes TLOG. Este flujo se puede adjuntar al flujo principal para supervisar el detalle de transacciones de minorista.
TLOG_RETEK: Estos flujos de mensajes de ejemplo se crean para procesar los mensajes TLOG en formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML que proceden de las aplicaciones de minorista de IBM ACE, GSA y SA. También transforma el mensaje a POSLog XML y realiza la transformación de mensaje del formato POSLog al formato Retek para la aplicación ReSA (Retek Sales Audit). Este mensaje lo lee un proceso independiente que graba los registros en archivos sin formato para la entrada a ReSA. Se proporciona un flujo de supervisor TLOG opcional con cada ejemplo para realizar la medición de servicio de los mensajes TLOG. Este flujo se puede adjuntar al flujo principal para supervisar el detalle de transacciones de minorista.
TRANSFORMATION: Estos flujos de mensajes de ejemplo se crean para procesar los mensajes TLOG de los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML que proceden de las aplicaciones de minorista de IBM ACE, GSA y SA. También transforma el mensaje a formato POSLog XML. Se proporciona un flujo de supervisor TLOG opcional con cada ejemplo para realizar la medición de servicio de los mensajes TLOG. Este flujo se puede adjuntar al flujo principal para supervisar el detalle de transacciones de minorista.
Se proporcionan detalles sobre cada uno de los flujos de mensajes anteriores de Procesador TLOG.
Este flujo de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN y SAMPLE_ACE_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo ACE_PreTransformProcessing.
El subflujo ACE_PreTransformProcessing toma una copia del mensaje y crea la Routelist de destino en el entorno local que tiene el valor dif_TLogFormat almacenado en las propiedades de mensajes necesarias para el nodo RouteToLabel. El subflujo también añade ApplicationType y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo ACE Transformation.
El subflujo ACE Transformation realiza la transformación de mensajes a POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo lo convierte a formato TLOG XML y los transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada es TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo ARTS Processing.
El subflujo ARTS Processing filtra el mensaje entrante comprobando los campos obligatorios para la actualización de ARTS. Si hay un elemento Transaction.RetailTransaction.LineItem disponible en el mensaje de entrada, el subflujo continúa el proceso ARTS. El nodo de base de datos POSLog to ARTS almacena la información de transacción en la base de datos de ARTS. El mensaje transformado se pone en la cola ARTS_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo ARTS_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo de mensajes de ejemplo TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN y SAMPLE_GSA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo GSA Pre Transform Processing.
El subflujo GSA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo GSA Transformation.
El subflujo GSA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo ARTS Processing.
El subflujo ARTS Processing filtra el mensaje entrante comprobando los campos obligatorios para las actualizaciones de ARTS. Si hay un elemento Transaction.RetailTransaction.LineItem disponible en el mensaje de entrada, el subflujo continúa el proceso ARTS. El nodo de base de datos POSLog to ARTS almacena la información de transacción en la base de datos de ARTS. El mensaje transformado se pone en la cola ARTS_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo ARTS_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN y SAMPLE_SA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo SA Pre Transform Processing.
El subflujo SA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo SA Transformation.
El subflujo SA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo ARTS Processing.
El subflujo ARTS Processing filtra el mensaje entrante comprobando los campos obligatorios para las actualizaciones de ARTS. Si hay un elemento Transaction.RetailTransaction.LineItem disponible en el mensaje de entrada, el subflujo continúa el proceso ARTS. El nodo de base de datos POSLog to ARTS almacena la información de transacción en la base de datos de ARTS. El mensaje transformado se pone en la cola ARTS_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo ARTS_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo
de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación
ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando
los nodos de entrada SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN,
SAMPLE_ACE_TLOGXML_IN y SAMPLE_ACE_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo ACE_PreTransformProcessing.
El subflujo ACE_PreTransformProcessing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo ACE Transformation.
El subflujo ACE Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo RETEK Processing.
El subflujo RETEK Processing transforma el formato POSLog XML al formato Retek para la aplicación Retek Sales Audit (ReSA). El mensaje transformado se pone en la cola RETEK_EXAMPLE_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo RETEK_EXAMPLE_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo de mensajes de ejemplo TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN y SAMPLE_GSA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo GSA Pre Transform Processing.
El subflujo GSA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo GSA Transformation.
El subflujo GSA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo RETEK Processing.
El subflujo RETEK Processing transforma el formato POSLog XML al formato Retek para la aplicación Retek Sales Audit (ReSA). El mensaje transformado se pone en la cola RETEK_EXAMPLE_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo RETEK_EXAMPLE_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:Este flujo de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN y SAMPLE_SA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo SA Pre Transform Processing.
El subflujo SA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo SA Transformation.
El subflujo SA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pasa al subflujo RETEK Processing.
El subflujo RETEK Processing transforma el formato POSLog XML al formato Retek para la aplicación Retek Sales Audit (ReSA). El mensaje transformado se pasa a la cola RETEK_EXAMPLE_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo RETEK_EXAMPLE_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN y SAMPLE_ACE_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo ACE_PreTransformProcessing.
El subflujo ACE_PreTransformProcessing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo ACE Transformation.
El subflujo ACE Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pone en la cola TRANSFORM_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo TRANSFORM_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los subflujos de manejo de excepciones
Este flujo de mensajes de ejemplo TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN y SAMPLE_GSA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo GSA Pre Transform Processing.
El subflujo GSA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo GSA Transformation.
El subflujo GSA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pone en la cola TRANSFORM_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo TRANSFORM_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Este flujo de mensajes de ejemplo de TLOG recibe el mensaje procedente de una aplicación ACE en los formatos TLOG MIME, TLOG RAW, TLOG XML y POSLog XML utilizando los nodos de entrada SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN y SAMPLE_SA_POSLogXML_IN.
Si el flujo recibe un mensaje MIME, lo analiza utilizando el analizador MIME del nodo MQInput y lo pasa al subflujo RSSDIF TO MIME. El subflujo procesa el mensaje MIME para construir el árbol XML que necesita el subflujo RSSDIF Detachment.
El subflujo RSSDIF Detachment separa la cabecera MIME o SOAP del mensaje de entrada, extrae los valores de dif_TLogFormat, dif_POSType y StoreNumber del Sobre SOAP y construye el árbol de mensaje MRM para el mensaje de transacción basándose en los valores de dif_POSType y dif_TLogFormat. El mensaje se pasa al subflujo SA Pre Transform Processing.
El subflujo SA Pre Transform Processing realiza una copia del mensaje y crea la Routelist de destino en el entorno local con el valor dif_TLogFormat almacenado en las propiedades de mensaje necesarias para el nodo RouteToLabel. El subflujo añade el tipo de aplicación (ApplicationType) y datos específicos de cliente a la variable de entorno ETTP_Transform. El mensaje se pasa al subflujo SA Transformation.
El subflujo SA Transformation realiza la transformación de mensajes al formato POSLog basándose en el valor de RouteToLabel almacenado en el árbol del Entorno local. Si el mensaje de entrada ya está en formato POSLog, el mensaje no se modifica. Si el mensaje de entrada está en formato TLOG RAW, el subflujo convierte el mensaje a formato TLOG XML y lo transforma a formato POSLog utilizando la hoja de estilo. Si el mensaje de entrada está en formato TLOG XML, el subflujo transforma directamente el mensaje a formato POSLog utilizando la hoja de estilo. El mensaje transformado se pone en la cola TRANSFORM_EXAMPLE_POSLogXML_OUT.
El flujo de supervisión TLOG no está conectado de forma predeterminada. Puede conectar el flujo TLOG ARTS con el flujo de supervisión para supervisar las transacciones diarias conectando el terminal de salida (Out) del nodo TRANSFORM_EXAMPLE_POSLogXML_OUT al terminal de entrada (In) del nodo POSLog Monitor TryCatch.
Puede gestionar los errores utilizando los siguientes subflujos de manejo de excepciones:
Los flujos de mensajes anteriores constan de los siguientes subflujos:
El subflujo analiza el mensaje de entrada utilizando el analizador MIME. El nodo Parse MIME crea el árbol de mensaje necesario para el subflujo RSSDIF Detachment. El mensaje de salida se pasa al subflujo RSSDIF Detachment.
Puede incluir el subflujo ETTP_TRANSFORM en un flujo de mensajes para transformar un mensaje de transacción TLOG en un mensaje IXRetail POSLog. El subflujo Transformation acepta los siguientes tipos de mensaje:
Normalmente el subflujo Transformation va precedido de un nodo MQInput (configurado para el tipo de mensaje apropiado) seguido de un nodo Compute. El nodo Compute proporciona información de configuración para el subflujo Transformation utilizando una carpeta de la sección MRM del mensaje. La información de configuración consta de:
El subflujo Transformation tiene una conexión de salida para el mensaje POSLog resultante. Esta conexión de salida se puede conectar a otros subflujos o nodos de proceso de mensajes.
Puede incluir el subflujo ETTP_ARTS en un flujo de mensajes para implementar la interfaz de los mensajes POSLog en una despensa de datos DB2 en el formato de ARTS 4.01 estándar de la industria. El subflujo contiene un nodo Database que llena los registros de la base de datos basándose en el contenido de un mensaje POSLog.
Conecte la conexión de entrada del subflujo a un nodo que dé como salida un mensaje POSLog, por ejemplo, la salida del subflujo Transformation o un nodo MQInput que haya leído un mensaje POSLog. Utilice el editor de propiedades (pulse el botón derecho del ratón en Subflujo > Propiedades) para establecer los valores apropiados para las propiedades de base de datos de las carpetas ARTS_DB_PROPERTIES, Data Source, Transaction y otras, según sea apropiado. Estas propiedades se utilizan para configurar el nodo Database. Para obtener información sobre el nodo Database, consulte Nodo Database en la documentación de WebSphere Message Broker.
La conexión de salida se puede conectar a otros nodos para realizar un proceso adicional del mensaje POSLog.
Puede incluir el subflujo ETTP_RETEK de un flujo de mensajes para implementar una interfaz de un mensaje POSLog en una aplicación Retek Sales Audit (ReSA). El subflujo produce un mensaje de formato Retek en una cola de WebSphere MQ de salida basándose en el contenido de un mensaje POSLog.
Este mensaje de formato Retek lo lee la herramienta Appender, que graba los registros en archivos planos para la entrada a la aplicación Retek Sales Audit.
La conexión de entrada del subflujo se debe conectar a un nodo que produzca un mensaje POSLog; por ejemplo, la salida del subflujo Transformation o un nodo MQInput que ha leído un mensaje POSLog.
La conexión de salida se puede conectar a otros nodos para realizar un proceso adicional del mensaje de formato Retek.
Puede incluir los subflujos de supervisión en un flujo de mensajes para registrar información sobre las características de los mensajes recibidos de las tiendas, el recuento de mensajes agregados y las sumas de transacciones para los datos financieros contenidos en los mensajes y el análisis de los ingresos diarios por tienda. Los datos de supervisión se almacenan en las tablas de la base de datos de supervisión.
El subflujo ETTP_MONITOR__MESSAGE_MONITOR registra la información de identificación de mensaje, el nombre o el número de tienda, la indicación de fecha y hora de entrada, el tipo de mensaje de entrada, la cola de entrada y la cola de salida. Si el mensaje de entrada es un mensaje RSSDIF que contiene varios adjuntos de transacción, se registra una entrada de base de datos independiente para cada conexión de transacción.
El subflujo ETTP_xxx_STORE_DAY_MONITOR extrae datos de los mensajes TLOG y llena la tabla STORE_DAY con información de resumen para la tienda, incluyendo el recuento de transacciones recibidas, la hora de cierre de la tienda y la hora de última transacción recibida de la tienda. Existe un subflujo Store Day Monitor personalizado para cada uno de los tipos de aplicación, ACE, GSA y SA, y dicho subflujo se anota en el nombre de subflujo en lugar del nombre de subflujo xxx.
El subflujo ETTP_MONITOR_ANALYTICS proporciona datos que se pueden utilizar en una hoja de cálculo para generar un gráfico de los ingresos diarios por tienda. Puede utilizar este gráfico, que muestra una curva de regresión lineal a intervalos horarios de los cuadrados mínimos, como modelo de la actividad de ingresos diarios y como supervisor de integridad del sistema. El gráfico está destinado a utilizarse como aproximación de primer orden y no es un sustituto de la minería de datos rigurosa. El soporte de tablas de base de datos consta de una tabla reutilizable (STORE_SCRATCH) para cálculos intermedios y una tabla STORE_HOUR que contiene registros por tienda, día y hora de los totales acumulativos que son necesarios para el modelo de cuadrados mínimos.
La aplicación TLOG se puede personalizar en función de los requisitos del cliente. Puede personalizar la aplicación TLOG utilizando uno de los tres procedimientos siguientes:
Los pasos anteriores registran todas las transacciones en la base de datos de supervisor.
Los ejemplos de TLOG están disponibles a partir de WebSphere Message Broker v6.1.0.2. Se soporta la migración de los ejemplos de TLOG de WebSphere Message Broker v6.1.0.2 a WebSphere Message Broker v6.1.0.3. Para migrar los flujos TLOG de WebSphere Message Broker v6.1.0.2 a flujos TLOG de WebSphere Message Broker v6.1.0.3 que se ejecutan en el intermediario de WebSphere Message Broker v6.1.0.2, realice los pasos siguientes:
El ejemplo de TLOG que está disponible en WebSphere Message Broker v6.1.0.3 soporta las versiones 1.0, 2.1, 2.1.2 y 2.2.1 de POSLog. El ejemplo contiene un conjunto de mensajes de POSLog v2.2.1 que soporta el análisis de los mensajes de POSLog v2.1 y v 2.1.2.
Para comprobar la versión de los flujos de TLOG desplegados, realice los pasos siguientes:
Las versiones de flujo de mensajes TLOG sólo se establecen en el release de WebSphere Message Broker v6.1.0.3.
Volver a la página inicial del ejemplo