About the TLOG Processor sample

The TLOG Processor samples provide the following features:

• A MIME parser for unpacking TLOG messages from stores arriving on a WebSphere MQ queue. The default configuration of this parser works in synergy with the in-store IBM Retail Store Solutions Data Interchange Facility and either IBM WebSphere MQ or IBM WebSphere MQ Everyplace (MQe) as the data transport mechanism from the stores.
• Prebuilt message sets for standard messages from IBM Retail Store Solutions 4680-4690 Supermarket Application (SA), IBM 4680-4690 General Sales Application (GSA), and SurePOS(TM) Application Client/Server Environment for 4690 OS (ACE).
• Raw TLOG to XML transformation (with style sheets), for transform to industry standard ARTS IXRetail POSLog Version 1.0 format, for SA, GSA, and ACE applications up to Version 7.0.
• Raw TLOG to XML transformation (with style sheets), for transform to industry standard ARTS IXRetail POSLog Version 2.2.1 format, for SA, GSA, and ACE applications up to Version 7 Release 3.
• Population of IBM DB2 TLOG datamart in industry standard Association for Retail Technology Standards (ARTS) Data Model format. This release follows the ARTS 4.01 Data Model.
• A batch file interface for subsequent importing of TLOG data into Retek(TM) Sales Audit (ReSA) V9.0 module.
• Monitoring of store status and accounting for each message that is received.

The TLOG Processor samples demonstrate how to receive and process the messages from IBM ACE, GSA, or SA retail applications by using TLOG message sets. The messages can be in the following formats from these applications:

• MIME
• TLOG RAW
• TLOG XML
• POSLog XML

These messages are transformed into POSLog XML by using the TLOG sample message flows. The TLOG Retek sample message flows transform POSLog XML format to Retek format, and the TLOG ARTS sample message flows store transaction information in an ARTS database in the format required by datamart standards. An optional facility to monitor the retail transaction activities is provided by each sample, which stores the transaction information into a Monitor database. These functions are provided by creating the required TLOG message sets, subflows, style sheets, database tables, and message flows.

Considerations when using POSLog v1.0 format to represent your retail transaction data

IBM has augmented the POSLog v1.0 and v2.2.1 XML Schema files with extensions to support transactions originating from IBM point of sale devices. These IBM extensions also allow customers to add their own fields to the transaction, by using the xs:any (wildcard element) feature of XML Schema. The XMLNSC domain, which processes POSLog XML transactions, fully implements XML Schema 1.0 rules, including a set known as Unique Particle Attribution (UPA) rules. Some of the wildcard extensions in the POSLog v1.0 XML Schema files violate one of the UPA rules, and the POSLog v1.0 message sets supplied with this sample have been modified to correct this violation. However, the result is that sometimes a customer defined field in a POSLog v1.0 transaction can cause a validation error during processing by the XMLNSC domain. If a validation error occurs, switch off validation at the appropriate point in the message flow. Such a validation failure is indicated by a BIP5902 message followed by other BIP5xxx messages detailing the precise failure.

If you are using the IA62 or IA64 SupportPacs you can replace your existing message flows with the flows in these samples.

Eighteen TLOG sample message flows, nine for TLOG v1.0 and nine for TLOG V2.2.1, are provided to demonstrate the following functions:

• TLOG_ARTS: These sample message flows are created to process the TLOG messages of TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats coming from the IBM retail applications ACE, GSA, and SA. It also transforms the message to POSLog XML and populates the POSLog XML transaction data into an ARTS database as required by the TLOG datamart in industry standard Association for Retail Technology Standards (ARTS) Data Model format. This release follows the ARTS 4.01 Data Model. An optional TLOG Monitor flow is provided with each sample to perform service metering of the TLOG messages. This flow can be attached with the main flow to monitor retail transaction detail.

  • The TLOG_ARTS_EXAMPLE__ACE message flow sample for an ACE application, see TLOG_ARTS_EXAMPLE__ACE.
  • The TLOG_ARTS_EXAMPLE__GSA message flow sample for a GSA application, see TLOG_ARTS_EXAMPLE__GSA.
  • The TLOG_ARTS_EXAMPLE__SA message flow sample for an SA application, see TLOG_ARTS_EXAMPLE__SA.

• TLOG_RETEK: These sample message flows are created to process the TLOG messages in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats coming from the IBM retail applications ACE, GSA, and SA. It also transforms the message into POSLog XML and performs the message transformation from POSLog format to Retek format for the Retek Sales Audit (ReSA) application. This message is read by a separate process that writes the records to flat files for input to ReSA. An optional TLOG Monitor flow is provided with each sample to perform service metering of the TLOG messages. This flow can be attached with the main flow to monitor retail transaction detail.

  • The TLOG_RETEK_EXAMPLE__ACE message flow sample for an ACE application, see TLOG_RETEK_EXAMPLE__ACE.
  • The TLOG_RETEK_EXAMPLE__GSA message flow sample for a GSA application, see TLOG_RETEK_EXAMPLE__GSA.
  • The TLOG_RETEK_EXAMPLE__SA message flow sample for an SA application, see TLOG_RETEK_EXAMPLE__SA.

• TRANSFORMATION: These sample message flows are created to process the TLOG messages of TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats coming from the IBM retail applications ACE, GSA, and SA. It also transforms the message into POSLog XML format. An optional TLOG Monitor flow is provided with each sample to perform service metering of the TLOG messages. This flow can be attached with the main flow to monitor retail transaction detail.

  • The TRANSFORM_EXAMPLE__ACE message flow sample for an ACE application, see TRANSFORM_EXAMPLE__ACE.
  • The TRANSFORM_EXAMPLE__GSA message flow sample for a GSA application, see TRANSFORM_EXAMPLE__GSA.
  • The TRANSFORM_EXAMPLE__SA message flow sample for an SA application, see TRANSFORM_EXAMPLE__SA.

Details about each of the previous TLOG Processor message flows are provided.

TLOG_ARTS_EXAMPLE__ACE

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN, and SAMPLE_ACE_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the ACE_PreTransformProcessing subflow.

The ACE_PreTransformProcessing subflow takes a copy of the message and creates the destination Routelist in the local environment that has the value dif_TLogFormat stored in the message properties that are required by the RouteToLabel node. The subflow also adds ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the ACE Transformation subflow.

The ACE Transformation subflow performs the message transformation to POSLog based on the RouteToLabel value stored in the local environment tree. If the incoming message is in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts it into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is TLOG XML, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the ARTS Processing subflow.

The ARTS Processing subflow filters the incoming message by checking for the mandatory fields for the ARTS update. If a Transaction.RetailTransaction.LineItem element is available in the incoming message, the subflow continues the ARTS processing. The POSLog to ARTS Database node stores the transaction information into the ARTS database. The transformed message is put to the ARTS_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the ARTS_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• ACE Pre Transform Exception Handling
• ACE Transform Exception Handling
• ARTS Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TLOG_ARTS_EXAMPLE__GSA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN, and SAMPLE_GSA_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the GSA Pre Transform Processing subflow.

The GSA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties that are required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the GSA Transformation subflow.

The GSA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the ARTS Processing subflow.

The ARTS Processing subflow filters the incoming message by checking for the mandatory fields for ARTS updates. If a Transaction.RetailTransaction.LineItem element is available in the incoming message, the subflow continues the ARTS processing. The POSLog to ARTS Database node stores the transaction information into the ARTS database. The transformed message is put to the ARTS_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the ARTS_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• GSA Pre Transform Exception Handling
• GSA Transform Exception Handling
• ARTS Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TLOG_ARTS_EXAMPLE__SA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN, and SAMPLE_SA_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the SA Pre Transform Processing subflow.

The SA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties that are required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the SA Transformation subflow.

The SA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the ARTS Processing subflow.

The ARTS Processing subflow filters the incoming message by checking for the mandatory fields for ARTS updates. If a Transaction.RetailTransaction.LineItem element is available in the incoming message, the subflow continues the ARTS processing. The POSLog to ARTS Database node stores the transaction information into the ARTS database. The transformed message is put to the ARTS_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the ARTS_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• SA Pre Transform Exception Handling
• SA Transform Exception Handling
• ARTS Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TLOG_RETEK_EXAMPLE__ACE

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN, and SAMPLE_ACE_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the ACE_PreTransformProcessing subflow.

The ACE_PreTransformProcessing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties required by RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the ACE Transformation subflow.

The ACE Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the RETEK Processing subflow.

The RETEK Processing subflow transforms POSLog XML format to Retek format for the Retek Sales Audit (ReSA) application. The transformed message is put to the RETEK_EXAMPLE_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the RETEK_EXAMPLE_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• ACE Pre Transform Exception Handling
• ACE Transform Exception Handling
• RETEK Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TLOG_RETEK_EXAMPLE__GSA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN, and SAMPLE_GSA_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the GSA Pre Transform Processing subflow.

The GSA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties that are required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the GSA Transformation subflow.

The GSA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value that is stored in the local environment tree. If the incoming message is in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the RETEK Processing subflow.

The RETEK Processing subflow transforms POSLog XML format to Retek format for the Retek Sales Audit (ReSA) application. The transformed message is put to the RETEK_EXAMPLE_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the RETEK_EXAMPLE_OUT node to the In terminal of the POSLog Monitor TryCatch node.

• GSA Pre Transform Exception Handling
• GSA Transform Exception Handling
• RETEK Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TLOG_RETEK_EXAMPLE__SA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN, and SAMPLE_SA_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree that is required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the SA Pre Transform Processing subflow.

The SA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties that are required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data in the environment variable ETTP_Transform. The message is passed to the SA Transformation subflow.

The SA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is passed to the RETEK Processing subflow.

The RETEK Processing subflow transforms POSLog XML format to Retek format for the Retek Sales Audit (ReSA) application. The transformed message is passed to the RETEK_EXAMPLE_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the RETEK_EXAMPLE_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• SA Pre Transform Exception Handling
• SA Transform Exception Handling
• RETEK Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TRANSFORM_EXAMPLE__ACE

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN, and SAMPLE_ACE_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the ACE_PreTransformProcessing subflow.

The ACE_PreTransformProcessing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the ACE Transformation subflow.

The ACE Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is put to the TRANSFORM_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the TRANSFORM_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the exception handling subflows

• ACE Pre Transform Exception Handling
• ACE Transform Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TRANSFORM_EXAMPLE__GSA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN, and SAMPLE_GSA_POSLogXML_IN.

If the flow receives a MIME message, it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to GSA Pre Transform Processing subflow.

The GSA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the GSA Transformation subflow.

The GSA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, it directly transforms the message into POSLog format by using the style sheet. The transformed message is put to the TRANSFORM_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the TRANSFORM_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• GSA Pre Transform Exception Handling
• GSA Transform Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

TRANSFORM_EXAMPLE__SA

This TLOG sample message flow receives the message coming from an ACE application in TLOG MIME, TLOG RAW, TLOG XML, and POSLog XML formats by using the input nodes SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN, and SAMPLE_SA_POSLogXML_IN.

If the flow receives a MIME message it parses the MIME message by using the MIME parser in the MQInput node and passes it to the RSSDIF TO MIME subflow. The subflow processes the MIME message to construct the XML tree required by the RSSDIF Detachment subflow.

The RSSDIF Detachment subflow detaches the MIME or SOAP header from the input message, extracts the values of dif_TLogFormat, dif_POSType, and StoreNumber from the SOAP Envelope and constructs the MRM message tree for the transaction message based on the values of dif_POSType and dif_TLogFormat. The message is passed to the SA Pre Transform Processing subflow.

The SA Pre Transform Processing subflow takes a copy of the message and creates the destination Routelist in the local environment with the value dif_TLogFormat stored in the message properties required by the RouteToLabel node. The subflow adds the ApplicationType and customer specific data to the environment variable ETTP_Transform. The message is passed to the SA Transformation subflow.

The SA Transformation subflow performs the message transformation to the POSLog format based on the RouteToLabel value stored in the local environment tree. If the incoming message is already in POSLog format, the message is unchanged. If the incoming message is in TLOG RAW format, the subflow converts the message into TLOG XML format and transforms it into POSLog format by using the style sheet. If the incoming message is in TLOG XML format, the subflow directly transforms the message into POSLog format by using the style sheet. The transformed message is put to the TRANSFORM_EXAMPLE_POSLogXML_OUT queue.

The TLOG Monitor flow is not connected by default. You can connect the TLOG ARTS flow with the Monitor flow to monitor the daily transactions by connecting the Out terminal of the TRANSFORM_EXAMPLE_POSLogXML_OUT node to the In terminal of the POSLog Monitor TryCatch node.

You handle failures by using the following exception handling subflows:

• SA Pre Transform Exception Handling
• SA Transform Exception Handling
• Invalid Message Trace
• Non-Standard Message Trace

The preceding message flows consist of the following subflows:

RSSDIF TO MIME Parser subflow

The subflow parses the input message by using the MIME parser. The Parse MIME node builds the message tree that is required by the RSSDIF Detachment subflow. The output message is passed to the RSSDIF Detachment subflow.

Transformation subflow

You can include the ETTP_TRANSFORM subflow in a message flow to transform a TLOG transaction message into an IXRetail POSLog message. The Transformation subflow accepts the following message types:

• Native TLOG
• XML TLOG
• POSLog XML

The Transformation subflow is typically preceded by an MQInput node (configured for the appropriate message type) followed by a Compute node. The Compute node provides configuration information for the Transformation subflow by using a folder in the MRM section of the message. The configuration information consists of:

• A set of customer-specific or store-specific variables that are used as part of the transformation. Store-specific information might be provided by logic in the Compute node or, in the case of a large number of stores, might be retrieved from a database.
• The application (GSA, SA, or ACE) for which the transformation is to be performed.
• The location and name of the XSLT transformation files.

The Transformation subflow has an output connection for the resulting POSLog message. This output connection can be connected to other subflows or message processing nodes.

ARTS subflow

You can include the ETTP_ARTS subflow in a message flow to implement an interface from POSLog messages to a DB2 datamart in the industry standard ARTS 4.01 format. The subflow contains a Database node that populates the records in the database based on the content of a POSLog message.

Connect the input connection of the subflow to a node that outputs a POSLog message, for example, the output from the Transformation subflow, or an MQInput node that has read a POSLog message. Use the Property editor (right-click subflow > Properties) to set appropriate values for the database properties in the ARTS_DB_PROPERTIES, Data Source, Transaction, and other folders as appropriate. These properties are used to configure the Database node. For information about the Database node, see Database node in the IBM Integration Bus documentation.

The output connection can be connected to other nodes for further processing of the POSLog message.

RETEK subflow

You can include the ETTP_RETEK subflow in a message flow to implement an interface from a POSLog message to the Retek Sales Audit (ReSA) application. The subflow produces a Retek format message on an output WebSphere MQ queue based on the content of a POSLog message.

This Retek format message is read by the Appender tool, which writes the records to flat files for input to the Retek Sales Audit application.

The input connection of the subflow must be connected to a node that outputs a POSLog message; for example, the output from the Transformation subflow, or an MQInput node that has read a POSLog message.

The output connection can be connected to other nodes for further processing of the Retek format message.

Monitor subflow

You can include the Monitor subflows in a message flow to record information about the characteristics of messages that are received from the stores, the aggregate message count and transactional summations for financial data contained in the messages, and the analysis of the daily revenue by store. The monitor data is stored in the tables of the monitor database.

The ETTP_MONITOR__MESSAGE_MONITOR subflow records message identification information, store name or number, input time stamp, incoming message type, input queue, and output queue. If the incoming message is an RSSDIF message containing multiple transaction attachments, a separate database entry is recorded for each transaction attachment.

The ETTP_xxx_STORE_DAY_MONITOR subflow extracts data from the TLOG messages and populates the STORE_DAY table with summary information for the store, including the count of transactions received, the closing time of the store, and the time of the last transaction received from the store. A custom Store Day Monitor subflow exists for each of the application types, ACE, GSA, and SA, and is noted in the subflow name in place of xxx in the subflow name.

The ETTP_MONITOR_ANALYTICS subflow provides data that you can use in a spreadsheet to generate a graph of daily revenue by store. You can use this graph, which shows a least squares, hourly-piecewise linear regression curve, as both a model of daily revenue activity and a monitor of system integrity. The graph is intended as a first order approximation and is not a substitute for rigorous data mining. Supporting database tables consist of a scratch table (STORE_SCRATCH) for intermediate calculations, and a STORE_HOUR table that contains records by store, day, and hour of the cumulative totals that are required for the least squares model.

Customizing the TLOG application

The TLOG application can be customized depending on the requirements of the customer. You can customize the TLOG application by using one of the following three ways:

• By changing the queue names. The queue names that are used in the MQInput or MQOutput nodes in the TLOG message flow can be changed depending on your TLOG application requirements. Changing the queue names does not affect the functions of the TLOG flows.
• By changing the ARTS database name. In the existing application, the name of the database that is used for the ARTS flows is TLOGARTS. This database name can be changed in the TLOG ARTS message flows. Changing the database names does not affect the functions of the TLOG ARTS flows.
• By enabling monitor flows. Monitor flows are required to monitor the TLOG transaction in the TLOGMON Monitor database. By default, these flows are not connected in the TLOG sample flows. If you have a requirement to record the transaction in the Monitor database, you must complete the following steps to enable the Monitor flow in the TLOG_ARTS_EXAMPLE_ACE_V2.2.1 or TLOG_ARTS_EXAMPLE_ACE_V1.0 flow:
  1. In the TLOG_ARTS_EXAMPLE_ACE_V2.2.1 or TLOG_ARTS_EXAMPLE_ACE_V1.0 message flow connect the Out terminal of the ARTS_EXAMPLE_POSLOGXML_OUT node to the In terminal of the POSLOG Monitor TryCatch node.
  2. Connect the Invalid Message Trace subflow to the INVALID Monitor TryCatch node.
  3. Connect the Non-Standard Message Trace subflow to the Non-Standard Monitor TryCatch node.
  4. Rebuild the TLOG221_ARTS_ACE1.bar or TLOGV10_ARTS.bar BAR file, deploy the BAR file on the integration server.

The preceding steps record all of the transactions in the Monitor database.

Migrating the TLOG application

The TLOG samples are available from WebSphere Message Broker v6.1.0.2 onwards. Migration of the TLOG samples from WebSphere Message Broker v6.1.0.2 to WebSphere Message Broker v6.1.0.3 is supported. To migrate your WebSphere Message Broker v6.1.0.2 TLOG flows to WebSphere Message Broker v6.1.0.3 TLOG flows that run on your WebSphere Message Broker v6.1.0.2 broker complete the following steps:

1. Remove the WebSphere Message Broker v6.1.0.2 flows that are deployed on your WebSphere Message Broker v6.1.0.2 broker.
2. Deploy the WebSphere Message Broker v6.1.0.3 flows on your WebSphere Message Broker v6.1.0.2 broker.

The TLOG sample that is available on WebSphere Message Broker v6.1.0.3 supports POSLog versions 1.0, 2.1, 2.1.2, and 2.2.1. The sample contains a POSLog v2.2.1 message set that supports parsing of POSLog v2.1 and v 2.1.2 messages.

To check the version of the deployed TLOG flows, complete the following steps:

1. Open the integration server in which the TLOG flows have been deployed in the workbench.
2. Under the integration server, select the deployed flow.
3. In the Property page of the deployed message flow, under the "Info" section, the version of the message flow is displayed as a name-value pair. The value is either v1.0 or v2.2.1 depending upon which TLOG flow has been deployed on that integration server.

The TLOG message flow versions are set in the WebSphere Message Broker v6.1.0.3 release only.