Informationen zum Mustercode 'TLOG Processor'

Die TLOG Processor-Mustercodes stellen die folgenden Funktionen bereit:

Die TLOG Processor-Mustercodes zeigen, wie die Nachrichten von IBM ACE, GSA oder SA-Einzelhandelsanwendungen empfangen und verarbeitet werden, indem TLOG-Nachrichtensätze verwendet werden. Die Nachrichten können in folgenden Formaten von diesen Anwendungen vorliegen:

Diese Nachrichten werden unter Verwendung der TLOG-Beispielnachrichtenflüsse in POSLog-XML umgewandelt. Die TLOG Retek-Beispielnachrichtenflüsse wandeln das POSLog-XML-Format in das Retek-Format um und die TLOG ARTS-Beispielnachrichtenflüsse speichern Umsetzungsinformationen in einer ARTS-Datenbank im Format, das von Datamart-Standards erfordert wird. Es wird von jedem Mustercode eine optionale Funktion zum Überwachen von Einzelhandelsvorgängen bereitgestellt, welche die Umsetzungsdaten in einer Überwachungsdatenbank speichert. Diese Funktionen werden bereitgestellt, indem die erforderlichen TLOG-Nachrichtensätze, untergeordneten Nachrichtenflüsse, Formatvorlagen, Datenbanktabellen und Nachrichtenflüsse erstellt werden.

Aspekte beim Verwenden des POSLog v1.0-Formats zum Darstellen der Einzelhandelsvorgangsdaten

IBM hat die die POSLog v1.0- und v2.2.1 XML-Schemadateien entsprechend erweitert, damit Transaktionen unterstützt werden, die von IBM POS-Geräten stammen. Diese IBM Erweiterungen ermöglichen Kunden auch, der Transaktion ihre eigenen Felder hinzuzufügen, indem die xs:any-Funktion (Platzhalterelement) des XML Schemas verwendet wird. Die XMLNSC-Domäne, die POSLog XML-Transaktionen verarbeitet, implementiert XML Schema 1.0-Regeln komplett, einschließlich einer Gruppe so genannter UPA-Regeln (Unique Particle Attribution). Einige der Platzhaltererweiterungen in den POSLog v1.0 XML Schemadateien verstoßen gegen eine der UPA-Regeln und die POSLog v1.0-Nachrichtensätze dieses Mustercodes wurden modifiziert, um diesen Verstoß zu korrigieren. Dadurch kann es jedoch manchmal vorkommen, dass ein vom Kunde definiertes Feld in einer POSLog v1.0-Transaktion einen Gültigkeitsfehler bei der Verarbeitung der XMLNSC-Domäne verursacht. Wenn ein Gültigkeitsfehler auftritt, inaktivieren Sie die Überprüfung an der entsprechenden Stelle im Nachrichtenfluss. Solch ein Gültigkeitsfehler wird von einer BIP5902-Nachricht angegeben, gefolgt von anderen BIP5xxx-Nachrichten mit Zusatzinformationen zum Fehler.

Wenn Sie die IA62- oder IA64 SupportPacs verwenden, können Sie die vorhandenen Nachrichtenflüsse durch die Flüsse in diesen Mustercodes ersetzen.

Es werden 18 TLOG-Beispielnachrichtenflüsse (neun für TLOG v1.0 und neun für TLOG V2.2.1) bereitgestellt, um die folgenden Funktionen zu veranschaulichen:

Im Folgenden finden Sie ausführliche Informationen zu den einzelnen früheren TLOG Processor-Nachrichtenflüssen.

TLOG_ARTS_EXAMPLE__ACE

Nachrichtenfluss 'TLOG_ARTS'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN und SAMPLE_ACE_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Fluss 'ACE_PreTransformProcessing' übergeben.

Der untergeordnete Nachrichtenfluss 'ACE_PreTransformProcessing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' auch 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Fluss 'ACE Transformation' übergeben.

Der untergeordnete Fluss 'ACE Transformation' führt die Nachrichtenkonvertierung in POSLog auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Wenn die eingehende Nachricht das Format TLOG XML hat, wird sie unter Verwendung der Formatvorlage vom untergeordneten Fluss direkt in das POSLog-Format umgewandelt. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'ARTS Processing' übergeben.

Der untergeordnete Fluss 'ARTS Processing' filtert die eingehende Nachricht, indem er die Pflichtfelder für die ARTS-Aktualisierung prüft. Wenn in der eingehenden Nachricht ein Element 'Transaction.RetailTransaction.LineItem' verfügbar ist, fährt der untergeordnete Nachrichtenfluss mit der ARTS-Verarbeitung fort. Der Datenbankknoten 'POSLog to ARTS' speichert die Transaktionsdaten in der ARTS-Datenbank. Die umgewandelte Nachricht wird in der Warteschlange 'ARTS_EXAMPLE_POSLogXML_OUT ' eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens ARTS_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TLOG_ARTS_EXAMPLE__GSA

Nachrichtenfluss 'TLog_ARTS_GSA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN und SAMPLE_GSA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'GSA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt 'ApplicationType' und kundenspezifische Daten der Umgebungsvariablen 'ETTP_Transform' hinzu. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Transformation' übergeben.

Der untergeordnete Fluss 'GSA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'ARTS Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'ARTS Processing' filtert die eingehende Nachricht, indem er die Pflichtfelder nach ARTS-Updates durchsucht. Wenn in der eingehenden Nachricht ein Element 'Transaction.RetailTransaction.LineItem' verfügbar ist, fährt der untergeordnete Nachrichtenfluss mit der ARTS-Verarbeitung fort. Der Datenbankknoten 'POSLog to ARTS' speichert die Transaktionsdaten in der ARTS-Datenbank. Die umgewandelte Nachricht wird in der Warteschlange 'ARTS_EXAMPLE_POSLogXML_OUT ' eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens ARTS_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TLOG_ARTS_EXAMPLE__SA

Nachrichtenfluss 'TLog_ARTS_SA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN und SAMPLE_SA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'SA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'SA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Fluss 'SA Transformation' übergeben.

Der untergeordnete Fluss 'SA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'ARTS Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'ARTS Processing' filtert die eingehende Nachricht, indem er die Pflichtfelder nach ARTS-Updates durchsucht. Wenn in der eingehenden Nachricht ein Element 'Transaction.RetailTransaction.LineItem' verfügbar ist, fährt der untergeordnete Nachrichtenfluss mit der ARTS-Verarbeitung fort. Der Datenbankknoten 'POSLog to ARTS' speichert die Transaktionsdaten in der ARTS-Datenbank. Die umgewandelte Nachricht wird in der Warteschlange 'ARTS_EXAMPLE_POSLogXML_OUT ' eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens ARTS_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TLOG_RETEK_EXAMPLE__ACE

Nachrichtenfluss 'TLog_RETEK_ACE'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN und SAMPLE_ACE_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Fluss 'ACE_PreTransformProcessing' übergeben.

Der untergeordnete Fluss 'ACE_PreTransformProcessing' nimmt eine Kopie der Nachricht und erstellt die Zieladresse 'Routelist' in der lokalen Umgebung mit dem Wert dif_TLogFormat, der in den vom RouteToLabel-Knoten geforderten Nachrichteneigenschaften gespeichert ist. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Fluss 'ACE Transformation' übergeben.

Der untergeordnete Fluss 'ACE Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'RETEK Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'RETEK Processing' wandelt das POSLog XML-Format in das Retek-Format für die Anwendung Retek Sales Audit (ReSA) um. Die umgewandelte Nachricht wird in der Warteschlange RETEK_EXAMPLE_OUT eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens RETEK_EXAMPLE_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TLOG_RETEK_EXAMPLE__GSA

Nachrichtenfluss 'TLog_RETEK_GSA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN und SAMPLE_GSA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'GSA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Transformation' übergeben.

Der untergeordnete Fluss 'GSA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Wenn die eingehende Nachricht das Format TLOG XML hat, wird sie unter Verwendung der Formatvorlage vom untergeordneten Nachrichtenfluss direkt in das POSLog-Format umgewandelt. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'RETEK Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'RETEK Processing' wandelt das POSLog XML-Format in das Retek-Format für die Anwendung Retek Sales Audit (ReSA) um. Die umgewandelte Nachricht wird in der Warteschlange RETEK_EXAMPLE_OUT eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens RETEK_EXAMPLE_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TLOG_RETEK_EXAMPLE__SA

Nachrichtenfluss 'TLog_RETEK_SA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN und SAMPLE_SA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'SA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'SA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt 'ApplicationType' und kundenspezifische Daten der Umgebungsvariablen 'ETTP_Transform' hinzu. Die Nachricht wird an den untergeordneten Fluss 'SA Transformation' übergeben.

Der untergeordnete Fluss 'SA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird an den untergeordneten Fluss 'RETEK Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'RETEK Processing' wandelt das POSLog XML-Format in das Retek-Format für die Anwendung Retek Sales Audit (ReSA) um. Die umgewandelte Nachricht wird an die Warteschlange RETEK_EXAMPLE_OUT übergeben.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminal des Knotens RETEK_EXAMPLE_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TRANSFORM_EXAMPLE__ACE

Nachrichtenfluss 'TLog_TRANSFORM_ACE'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_ACE_RSSDIF_IN, SAMPLE_ACE_TLOGRAW_IN, SAMPLE_ACE_TLOGXML_IN und SAMPLE_ACE_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Fluss 'ACE_PreTransformProcessing' übergeben.

Der untergeordnete Fluss 'ACE_PreTransformProcessing' nimmt eine Kopie der Nachricht und erstellt die Zieladresse 'Routelist' in der lokalen Umgebung mit dem Wert dif_TLogFormat, der in den vom RouteToLabel-Knoten geforderten Nachrichteneigenschaften gespeichert ist. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Fluss 'ACE Transformation' übergeben.

Der untergeordnete Fluss 'ACE Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird in der Warteschlange TRANSFORM_EXAMPLE_POSLogXML_OUT eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminals des Knotens TRANSFORM_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TRANSFORM_EXAMPLE__GSA

Nachrichtenfluss 'TLog_TRANSFORM_GSA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_GSA_RSSDIF_IN, SAMPLE_GSA_TLOGRAW_IN, SAMPLE_GSA_TLOGXML_IN und SAMPLE_GSA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'GSA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'GSA Transformation' übergeben.

Der untergeordnete Fluss 'GSA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Wenn die eingehende Nachricht das Format TLOG XML hat, wird sie unter Verwendung der Formatvorlage direkt in das POSLog-Format umgewandelt. Die umgewandelte Nachricht wird in der Warteschlange TRANSFORM_EXAMPLE_POSLogXML_OUT eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminals des Knotens TRANSFORM_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

TRANSFORM_EXAMPLE__SA

Nachrichtenfluss 'TLog_TRANSFORM_SA'

Dieser TLOG-Beispielnachrichtenfluss empfängt unter Verwendung der Empfangsknoten SAMPLE_SA_RSSDIF_IN, SAMPLE_SA_TLOGRAW_IN, SAMPLE_SA_TLOGXML_IN und SAMPLE_SA_POSLogXML_IN die Nachricht von einer ACE-Anwendung in den Formaten TLOG MIME, TLOG RAW, TLOG XML und POSLog XML.

Wenn der Fluss eine MIME-Nachricht empfängt, analysiert er diese mithilfe des MIME-Parsers im MQInput-Knoten syntaktisch und übergibt sie an den untergeordneten Nachrichtenfluss RSSDIF TO MIME. Der untergeordnete Nachrichtenfluss verarbeitet die MIME-Nachricht, um die XML-Baumstruktur zu erstellen, die vom untergeordneten Nachrichtenfluss 'RSSDIF Detachment' benötigt wird.

Der untergeordnete Nachrichtenfluss 'RSSDIF Detachment' hängt den MIME- bzw. SOAP-Header von der Eingabenachricht ab, extrahiert die Werte dif_TLogFormat, dif_POSType und StoreNumber aus der SOAP-Rahmenanweisung und erstellt die MRM-Nachrichtenbaumstruktur für die Transaktionsnachricht, basierend auf den Werten dif_POSType und dif_TLogFormat. Die Nachricht wird an den untergeordneten Nachrichtenfluss 'SA Pre Transform Processing' übergeben.

Der untergeordnete Nachrichtenfluss 'SA Pre Transform Processing' nimmt eine Kopie der Nachricht und erstellt die Ziel-Routenliste in der lokalen Umgebung, für die der Wert 'dif_TLogFormat' in den Nachrichteneigenschaften gespeichert ist, die vom RouteToLabel-Knoten benötigt werden. Der untergeordnete Nachrichtenfluss fügt der Umgebungsvariablen 'ETTP_Transform' 'ApplicationType' und kundenspezifische Daten hinzu. Die Nachricht wird an den untergeordneten Fluss 'SA Transformation' übergeben.

Der untergeordnete Fluss 'SA Transformation' führt die Nachrichtenkonvertierung in das POSLog-Format auf Basis des RouteToLabel-Werts durch, der in der Baumstruktur der lokalen Umgebung gespeichert ist. Wenn die eingehende Nachricht bereits das Format POSLog hat, bleibt sie unverändert. Ist die eingehende Nachricht im TLOG RAW-Format, konvertiert der untergeordnete Nachrichtenfluss sie in das TLOG XML-Format und wandelt sie mithilfe der Formatvorlage in das POSLog-Format um. Ist die eingehende Nachricht im TLOG XML-Format, wandelt der untergeordnete Nachrichtenfluss sie direkt mithilfe der Formatvorlage in das POSLog-Format um. Die umgewandelte Nachricht wird in der Warteschlange TRANSFORM_EXAMPLE_POSLogXML_OUT eingereiht.

Der TLOG Monitor-Fluss ist nicht standardmäßig verbunden. Sie können den Fluss TLOG ARTS mit dem Überwachungsablauf verbinden, um die täglichen Transaktionen zu überwachen, indem Sie das Ausgangsterminals des Knotens TRANSFORM_EXAMPLE_POSLogXML_OUT mit dem Eingangsterminal des Knotens 'POSLog Monitor TryCatch' verbinden.

Sie können Fehler mithilfe der folgenden untergeordneten Nachrichtenflüsse zu Ausnahmebehandlung bearbeiten:

Die vorhergehenden Nachrichtenflüsse bestehen aus den folgenden untergeordneten Nachrichtenflüssen:

Untergeordneter Nachrichtenfluss 'RSSDIF TO MIME Parser'

Untergeordneter Nachrichtenfluss 'RSSDIF TO MIME'

Der untergeordnete Fluss analysiert die Eingabenachricht mithilfe des MIME-Parsers syntaktisch. Der Knoten 'Parse MIME' erstellt die Nachrichtenbaumstruktur, die vom untergeordneten Fluss 'RSSDIF Detachment' benötigt wird. Die Ausgabenachricht wird an den untergeordneten Nachrichtenfluss 'RSSDIF Detachment' übergeben.

Untergeordneter Nachrichtenfluss 'Transformation'

Untergeordneter Nachrichtenfluss 'Transformation'

Sie können den untergeordneten Nachrichtenfluss 'ETTP_TRANSFORM' in einen Nachrichtenfluss aufnehmen, um eine TLOG-Transaktionsnachricht in eine IXRetail POSLog-Nachricht umzuwandeln. Der untergeordnete Nachrichtenfluss 'Transformation' akzeptiert die folgenden Nachrichtentypen:

Dem untergeordneten Nachrichtenfluss 'Transformation' ist für gewöhnlich ein (für den entsprechenden Nachrichtentyp konfigurierter) MQInput-Knoten vorangestellt, gefolgt von einem Rechenknoten. Der Rechenknoten stellt die Konfigurationsdaten für den untergeordneten Transformationsnachrichtenfluss bereit, indem ein Ordner im MRM-Abschnitt der Nachricht verwendet wird. Die Konfigurationsdaten bestehen aus folgenden Punkten:

Der untergeordnete Nachrichtenfluss 'Transformation' verfügt für die resultierende POSLog-Nachricht über eine Ausgangsverbindung. Diese Ausgangsverbindung kann mit anderen untergeordneten Nachrichtenflüssen oder Nachrichtenverarbeitungsknoten verbunden sein.

Untergeordneter Nachrichtenfluss 'ARTS'

Sie können den untergeordneten Nachrichtenfluss 'ETTP_ARTS' in einen Nachrichtenfluss aufnehmen, um eine Schnittstelle zwischen POSLog-Nachrichten und einem DB2-Datamart im Branchenstandardformat ARTS 4.01 zu implementieren. Der untergeordnete Nachrichtenfluss enthält einen Datenbankknoten, der die Datensätze in der Datenbank auf Basis des Inhalts einer POSLog-Nachricht belegt.

Verbinden Sie die Eingangsverbindung des untergeordneten Nachrichtenflusses mit einem Knoten, der eine POSLog-Nachricht ausgibt, beispielsweise die Ausgabe aus dem untergeordneten Nachrichtenfluss 'Transformation', oder mit einem MQInput-Knoten, der eine POSLog-Nachricht gelesen hat. Mit dem Eigenschafteneditor (mit der rechten Maustaste auf Untergeordneter Nachrichtenfluss > Eigenschaften klicken) legen Sie die entsprechenden Werte für die Datenbankeigenschaften in den ARTS_DB_PROPERTIES-, Datenquelle-, Transaktions- und anderen Ordnern fest. Mit diesen Eigenschaften wird der Datenbankknoten konfiguriert. Weitere Informationen zum Datenbankknoten finden Sie in der Dokumentation zu WebSphere Message Broker im Abschnitt Database-Knoten.

Die Ausgangsverbindung kann zur weiteren Verarbeitung der POSLog-Nachricht mit anderen Knoten verbunden sein.

Untergeordneter Nachrichtenfluss 'RETEK'

Untergeordneter Nachrichtenfluss 'RETEK'

Sie können den untergeordneten Nachrichtenfluss 'ETTP_RETEK' in einen Nachrichtenfluss aufnehmen, um eine Schnittstelle zwischen einer POSLog-Nachricht und der Retek Sales Audit-Anwendung (ReSA-Anwendung) zu implementieren. Der untergeordnete Nachrichtenfluss erstellt in einer WebSphere MQ-Ausgabewarteschlange auf Basis des Inhalts einer POSLog-Nachricht eine Nachricht im Retek-Format.

Diese Nachricht im Retek-Format wird vom Appender-Tool gelesen, das die Datensätze zur Eingabe in der Retek Sales Audit-Anwendung in unstrukturierte Dateien schreibt.

Die Eingangsverbindung des untergeordneten Nachrichtenflusses muss mit einem Knoten verbunden sein, der eine POSLog-Nachricht ausgibt, beispielsweise die Ausgabe aus dem untergeordneten Nachrichtenfluss 'Transformation', oder mit einem MQInput-Knoten, der eine POSLog-Nachricht gelesen hat.

Die Ausgangsverbindung kann zur weiteren Verarbeitung der Retek-Nachricht mit anderen Knoten verbunden sein.

Untergeordneter Nachrichtenfluss 'Monitor'

Sie können die untergeordneten Monitor-Nachrichtenflüsse in einen Nachrichtenfluss aufnehmen, um Informationen zu den Eigenschaften von Nachrichten aufzuzeichnen, die aus den Filialen empfangen werden. Außerdem können so die zusammengefasste Nachrichtenanzahl und die Transaktionssummen für die in den Nachrichten enthaltenen Finanzdaten und die Analyse des Tagesumsatzes nach Filiale überwacht werden. Die Überwachungsdaten werden in den Tabellen der Überwachungsdatenbank gespeichert.

Untergeordneter Nachrichtenfluss 'Monitor'

Der untergeordnete Nachrichtenfluss ETTP_MONITOR__MESSAGE_MONITOR zeichnet die Informationen zu Nachrichtenkennung, Filialname oder -nummer, Eingabezeitmarke, Typ der eingehenden Nachricht, Eingabewarteschlange und Ausgabewarteschlange auf. Wenn es sich bei der eingehenden Nachricht um eine RSSDIF-Nachricht handelt, die mehrere Transaktionsanhänge enthält, wird ein separater Datenbankeintrag für jeden Transaktionsanhang aufgezeichnet.

Der untergeordnete Nachrichtenfluss ETTP_xxx_STORE_DAY_MONITOR extrahiert Daten aus den TLOG-Nachrichten und belegt die Tabelle STORE_DAY mit Übersichtsdaten für die Filiale, einschließlich der Anzahl der empfangenen Transaktionen, des Ladenschlusses der Filiale und des Zeitpunkts der letzten Transaktion aus der Filiale. Für jeden der Anwendungstypen (ACE, GSA und SA) gibt es einen angepassten untergeordneten Nachrichtenfluss des Typs 'Store Day Monitor', der anstelle von xxxim Namen des untergeordneten Nachrichtenflusses eingesetzt wird.

Der untergeordnete Nachrichtenfluss ETTP_MONITOR_ANALYTICS stellt Daten bereit, die Sie in einem Diagramm zur Generierung einer Grafik des Tagesumsatzes nach Filiale verwenden können. Sie können dieses Diagramm, das eine stündliche lineare Least-Squares-Regressionskurve zeigt, sowohl als Modell der täglichen Umsatzaktivitäten als auch als Überwachungsmethode für die Systemintegrität verwenden. Das Diagramm soll einen ersten groben Überblick geben und ist nicht als Ersatz für gründliches Data-Mining gedacht. Unterstützende Datenbanktabellen bestehen aus einer Anfangstabelle (STORE_SCRATCH) für temporäre Berechnungen und einer 'STORE_HOUR'-Tabelle, die Datensätze nach Geschäft, Tag und Stunde der Gesamtsummen enthält, die für das Least-Squares-Modell erforderlich sind.

TLOG-Anwendung anpassen

Die TLOG-Anwendung kann abhängig von den Kundenanforderungen angepasst werden. Sie können die TLOG-Anwendung auf drei verschiedene Arten anpassen:

In den vorhergehenden Schritten werden alle Transaktionen in der Überwachungsdatenbank aufgezeichnet.

TLOG-Anwendung migrieren

Die TLOG-Mustercodes sind ab WebSphere Message Broker v6.1.0.2 verfügbar. Die Migration der TLOG-Mustercodes von WebSphere Message Broker v6.1.0.2 zu WebSphere Message Broker v6.1.0.3 wird unterstützt. Um TLOG-Nachrichtenflüsse von WebSphere Message Broker v6.1.0.2 zu WebSphere Message Broker v6.1.0.3-TLOG-Nachrichtenflüsse zu migrieren, die auf dem Broker von WebSphere Message Broker v6.1.0.2 ausgeführt werden, gehen Sie wie folgt vor:

  1. Entfernen Sie die WebSphere Message Broker v6.1.0.2-Nachrichtenflüsse, die beim Broker von WebSphere Message Broker v6.1.0.2 implementiert sind.
  2. Implementieren Sie die WebSphere Message Broker v6.1.0.3-Nachrichtenflüsse auf dem Broker von WebSphere Message Broker v6.1.0.2.

Der TLOG-Mustercode, der bei WebSphere Message Broker v6.1.0.3 verfügbar ist, unterstützt POSLog-Version 1.0, 2.1, 2.1.2 und 2.2.1. Das Beispiel enthält einen POSLog v2.2.1-Nachrichtensatz, der die Syntaxanalyse von POSLog v2.1- und v2.1.2-Nachrichten unterstützt.

Um die Version der implementierten TLOG-Nachrichtenflüsse zu überprüfen, gehen Sie wie folgt vor:

  1. Öffnen Sie die Ausführungsgruppe, in der die TLOG-Nachrichtenflüsse implementiert wurden, in der Arbeitsumgebung.
  2. Wählen Sie unter der Ausführungsgruppe den implementierten Nachrichtenfluss aus.
  3. Auf der Eigenschaftsseite des implementierten Nachrichtenflusses wird im Abschnitt "Info" die Version des Nachrichtenflusses als Name/Wert-Paar angezeigt. Der Wert ist entweder v1.0 oder v2.2.1, je nachdem, welcher TLOG-Nachrichtenfluss bei der Ausführungsgruppe implementiert wurde.

Die TLOG-Nachrichtenflussversionen werden nur im WebSphere Message Broker v6.1.0.3-Release eingestellt.

Zurück zum Beginn des Mustercodes