Konfiguration der Extension FLEXIBLE_INDEX

Einleitung

Die Extension FLEXIBLE_INDEX definiert, welche Informationen aus den EDIFACT-Dokumenten im CCM-Index abgelegt werden sollen. Für jede neu eintreffende Nachricht, die im CCM indiziert werden soll, wird geprüft, ob in der FLEXIBLE_INDEX für den Format-Typ (z.B. UTILMD5.2) der Nachricht ein Definitionsblock mit Indizierungsinformationen vorhanden ist. Wenn ja, wird die Nachricht indiziert, wenn nicht, wird die Nachricht nicht in den CCM-Index übernommen (-> das kann ein Grund für fehlende Nachrichten im Index sein).

Aufbau der Extension FLEXIBLE_INDEX

Die Extension FLEXIBLE_INDEX besteht aus Definitionsblöcken für Nachrichtenformatversionen. Jeder Definitionsblock beginnt und endet mit Format-Typ und Version in Großbuchstaben und ohne Leerzeichen dazwischen, z.B. UTILMD5.1H. Die Definitionsblöcke sollten durch ein oder mehrere Leerzeilen getrennt werden. Im NLI-Standard werden immer die aktuelle und die letzten Formatversion in der FLEXIBLE_INDEX belassen.

Beispiel:

UTILMD5.1H
...
UTILMD5.1H

UTILMD5.2
...
UTILMD5.2


MSCONS2.2I

MSCONS2.2I

MSCONS2.3

MSCONS2.3

Als Format-Typ sind nur von der BDEW zugelassene Formate möglich. Blöcke mit anderen Namen werden ignoriert und erzeugen eine Fehlermeldung in den Log-Files.

Extension FLEXIBLE_INDEX_CUSTOM: Verwaltung eigener, angepasster Definitionsblöcke

Zur Erstellung eigener Arbeitsvorräte / Varianten muss man manchmal einige Blöcke der Extension FLEXIBLE_INDEX anpassen. Dies kann bei Formatumstellungen zu hohen Aktualisierungaufwänden führen. Darum gibt es die Möglichkeit, anzupassende Blöcke in eine Extension FLEXIBLE_INDEX_CUSTOM zu kopieren und nur dort anzupassen. Die Extension FLEXIBLE_INDEX sollte immer mit dem NLI Standard identisch sein.

Für die beiden Extensions gelten folgende Regeln:

  • Kommt eine Formatversion in beiden Extensions vor, wird diejenige aus der FLEXIBLE_INDEX_CUSTOM verwendet.
  • Kommt eine Formatversion nur in der FLEXIBLE_INDEX_CUSTOM vor, wird diese ebenfalls verwendet.
  • Für Formatversionen, die nur in der FLEXIBLE_INDEX vorkommen, wird der NLI-Standard verwendet.

Aufbau eines Definitionsblocks

Aus jeder Edifact-Nachricht werden die vom CCM benötigten fachlichen Informationen extrahiert und in SearchDocuments geschrieben. Dies sind einfach Listen von Key-Value Paaren, z.B. CATEGORY=E01, STS=7 etc. Die Definitionsblöcke bestimmen, welche Felder mit welchen Werten für die angegebene Formatversion in die SearchDocuments geschrieben und dnn in den CCM-Index indiziert werden sollen.

Der generelle Aufbau eines Definitionsblocks sieht wie folgt aus:

UTILMD5.2             // Formatversion der Nachrichtendatei
# Daten aus dem Formatobjekt
...

# Daten aus der Nachricht
ITER.UNH=UNH..UNZ     // Iteration über Nachrichten
...                   // Nachrichtenspezifische Felder

ITER.IDE=IDE..UNT     // Iteration über Vorgänge (kann auch DOC etc. sein)
...                   // Vorgangsspezifische Felder

FLUSHITER
ENDITER
UTILMD5.2             // Formatversion

Daten aus dem Formatobjekt

Eine Reihe von benötigten Informationen sind nicht in den EDIFACT-Dateien vorhanden, sondern können aus dem Format-Objekt der Nachricht abgerufen werden. Dies geschieht durch Hinzufügen des entsprechenden Feldnamens am Anfang des Definitionsblocks.

*Beispiel:*

    # Daten aus dem Formatobjekt
    Format.Direction
    Format.Typ
    Format.Version
    Format.ReferenceId
    Format.SenderCode
    Format.PartnerCode

Iterationsschleifen: Header- und Row-Dokumente

Für jede Nachrichtendatei wird ein Header-SearchDocument angelegt und ein Row-SearchDocument pro enthaltenem Vorgang / Geschäftsvorfall. Eine CONTRL Nachricht hat nur einen Vorgang, ergibt also 1 Header und 1 Row, eine UTILMD mit 5 IDE+24 Segmenten ergibt 1 Header und 5 Rows, eine MSCONS mit 7 Nachrichten (UNH/UNT-Blöcken) 1 Header und 7 Rows. Der Typ wird im SearchDocument über das Feld TYPE=Header/Row angegeben. Die zu einer Nachrichtendatei gehörenden SearchDocuments werden in eine Liste gepackt und als ein Eintrag in die B2BBP_CCM_INDEX_SYNC Datenbanktabelle geschrieben.

Zur Erzeugung der Row-Dokumente muss über die sich wiederholenden Felder iteriert werden. Die doppelte Iterationsschleife über Nachrichten und Vorgänge ist nur bei Single-UNH-Nachrichten notwendig. Multi-UNH Nachrichten mit nur einem Vorgang pro Einzelnachricht benötigen nur die UNH-Schleife.

FLUSHITER schreibt die gesammelten Daten in das aktuell geöffnete Row-Dokument und beginnt ein neues.

EDIPATH-Felder

Informationen aus den EDIFACT-Dateien werden über EDIPATH-Ausdrücke ausgelesen und Variablennamen zugewiesen

Beispiel:

CATEGORY=BGM+2+0

Die EDIPATH-Syntax ist hier beschrieben

ARRAY-Felder

Nicht alle Edipath-Ausdrücke sind eindeutig. Oft können sie mehrere Ergebnisse haben. Bei Zuweisung zu einem normalen Feld wird dort nur der erste gefundene Wert indiziert.

WIll man alle Felder verwenden, kann vor den Feldnamen der Prefix “ARRAY_” gehängt werden.

ARRAY_MTR speichert alle Ergebnisse durch Leerzeichen getrennt in einem String, der mit “ARRAY “ beginnt.

Beispiel:

FELD=XXX+1+0 -> FELD: “Wert1”

ARRAY_FELD=XXX+1+0 -> ARRAY_FELD: “ARRAY Wert1 Wert2 Wert3”

ACHTUNG!!! ARRAY-Felder werden im Indexmanagement nicht angezeigt (????). Es kann aber über die Suche im Indexmanagement auf sie zugegriffen werden (wie????)

Template-Funktionen

Die Kommandos der FLEXIBLE_INDEX Extension werden zeilenweise abgearbeitet. Mit Template-Funktionen können neue Felder unter Verwendung vorher erstellter Felder oder von Edipath-Ausdrücken erzeugt werden. Folgende Funktionen können verwendet werden:

first

Dieses Template prüft Felder, die als Parameter übergeben werden, der Reihe nach und übernimmt den Wert des ersten nicht leeren Feldes. Die als Parameter übergebenen Felder werden als temporäre Felder betrachtet und nach Abschluss der Template-Ausführung gelöscht.

Die Funktion ermöglicht den Zugriff auf mehrere Werte, bei denen nicht sicher ist, ob sie vorhanden sind. Der Ausdruck

STREET=TEMPLATE:first(STREET1,STREET2)

bedeutet, dass STREET1 eigentlich gesucht wird. Fehlt diese Information, wird stattdessen STREET2 verwendet und in STREET gespeichert.

Ein weitere interessantes Konstrukt ist die Verwendung bei STS-Segmenten zur Unterscheidung von UTILMD-Anfragen und UTILMD-Antworten. Eine UTILMD-Anfrage besitzt nur ein STS+7 Segment, eine UTILMD Antwort ein STS+7 und ein STS+E01 Segment. Verwendet man folgende Konstruktion:

STS1=STS[1+0="E01"]+1+0
STS2=STS[1+0="7"]+1+0
STS=TEMPLATE:first(STS1,STS2)

so wird STS1 nur bei Antworten gefüllt sein. STS enthält demnach “7” für Anfragen, “E01” für Antworten.

Andere Anwendungsfälle sind RFF-Segmente mit verschiedenen Qualifiern (TN, AGO, ACW), von denen jeweils nur einer da sein kann.

concatenate

Das Template verkettet zwei oder mehrere Felder zu einem.

constant

Mit diesem Template können beliebige Textketten in beliebige Felder im CCM-Index-geschrieben werden. Mit

LEVEL=TEMPLATE:constant(UCM)

wird bei Iterationen während der Verarbeitung von CONTRL Nachrichten das Fehlerlevel markiert.

extractmalos, extractmelos

Wenn mehrere LOC+172 Segmente mit einer oder mehreren MarktLokationen (MaLo) und einer oder mehreren Messlokationen (MeLo) in einem Vorgang vorhanden sind, werden diese durch die Zeile

ARRAY_MTR=LOC[1+0="172"]+2+0

im Feld ARRAY_MTR in folgender Form abgespeichert:

ARRAY 10000000001 DE0000000000000000000000000000001 DE0000000000000000000000000000002

Mit den Template-Befehlen

MALO=TEMPLATE:extractmalos(ARRAY_MTR[,delete])
MELO=TEMPLATE:extractmelos(ARRAY_MTR[,delete])

können eventuell vorhandene MaLos / MeLos in den Feldern MALO / MELO abgespeichert. Das Ergebnis ist dabei wie folgt (am Beispiel extractmelos):

  • keine MeLo vorhanden -> Das Feld MELO ist im Index nicht vorhanden
  • eine MeLo vorhanden -> MELO = DE0000000000000000000000000000001
  • mehrere MeLos vorhanden -> MELO = ARRAY DE0000000000000000000000000000001 DE0000000000000000000000000000002 …

Für MaLos ist das Verhalten analog.

Der optionale Parameter “delete” ist dazu da, nach Abarbeitung des letzten Templates das Feld ARRAY_MTR zu löschen. Dies verhindert doppelte Daten im Index.

Die in den meisten Fällen optimale Konfiguration ist diese:

ARRAY_MTR=LOC[1+0="172"]+2+0
MALO=TEMPLATE:extractmalos(ARRAY_MTR)
MELO=TEMPLATE:extractmelos(ARRAY_MTR,delete)

Falls in einem Nachrichtenformat keine MeLos vorkommen, kann auch diese Konfiguration verwendet werden:

ARRAY_MTR=LOC[1+0="172"]+2+0
MALO=TEMPLATE:extractmalos(ARRAY_MTR,delete)

sum

Summiert die Ergebnisse des als Argument angegebenen Edipath-Ausdrucks über den Vorgang (????) auf.

AMOUNT=TEMPLATE:sum(QTY[1+0="79"]+1+1)

normalizecurrency

Normalisiert Währungsbeträge auf zwei Nachkommastellen mit “.” als Dezimaltrenner, ohne 1000er-Trennzeichen.

Beispiel:

MOA=TEMPLATE:NORMALIZECURRENCY(MOA[1+0="9"]+1+1)

1.000,2173 -> 1000.22

[zu klären: Negative Zahlen werden als MIN1000.22 dargestellt????]

preliminary_values_by_obis_13018

Durchsucht alle MSCONS 13018 Nachrichten nach den temporären Messwerten. Die Ausgabe/Indexierung passiert Lin-Block scharf und wird über die Obis-Zahlen identifiziert.

Wenn also in einem Lin-Block mit der Obis-Zahl 1-1:1.8.1 alle Mengenangaben als Vorläufiger Wert (QTY+Z18) angegeben werden, gilt 1-1:1.8.1=true. Eine Nachricht mit mehreren LIN-Blöcken (und damit auch mehreren Obis-Zahlen) enthält dann Semikolon getrennte Einträge.

PRELIMINARY_VALUES_BY_OBIS_13018()

convert_timezone

Konvertiert die UTC-Zeit in MEZ/MESZ. DTMs ohne Uhrzeit oder ohne Zeitzone werden nicht verändert.

Beispiel:

DTM_137=TEMPLATE:CONVERT_TIMEZONE(DTM[1+0="137"]+2+0)

Hiermit wird aus dem Segment DTM+137:202206082200?+00:303’ das Datum als 202206090000?+02 indiziert.

View Me   Edit Me