Konfiguration der Arbeitsvorräte in der Extension FLEXIBLE_INDEX_UI

Einleitung

Die Extension FLEXIBLE_INDEX_UI enthält die technischen Definitionen der Arbeitsvorräte (“Varianten”). Für jede Variante wird der Name und Suchtyp des Arbeitsvorrats, die angezeigten Spalten, die Korrelationsbedingungen, die StateChecks zur Fristenprüfung sowie die die unsichtbaren und sichtbaren Suchfilter definiert.

Aufbau der Extension FLEXIBLE_INDEX_UI

Die Extension FLEXIBLE_INDEX_UI besteht aus Definitionsblöcken für Arbeitsvorräte, auch Varianten genannt. Jeder Definitionsblock beginnt mit dem Schlüsselwort “#VARIANT-START” und dem technischen Namen des Arbeitsvorrats (dieser endet immer auf “$PRE”) und endet mit dem Schlüsselwort “#VARIANT-END”. Vor “#VARIANT-START” können noch einige Kommentarzeilen stehen. Diese werden ignoriert. Die Definitionsblöcke sollten durch ein oder mehrere Leerzeilen getrennt werden.

Beispiel:

###################################################################
# UTILMD Fristenmanagement: Lieferbeginn Einzug (E01 / E01)
###################################################################
#VARIANT-START Lieferbeginn (E01 / E01) $PRE
...
#VARIANT-END


###################################################################
# UTILMD Fristenmanagement: Lieferanmeldung Wechsel (E01 / E03)
###################################################################
#VARIANT-START Lieferanmeldung (E01 / E03) $PRE
...
#VARIANT-END


###################################################################
# UTILMD Fristenmanagement: Lieferanten Storno der Anmeldung (E01 / E05)
###################################################################
#VARIANT-START Lieferanten Storno der Anmeldung (E01 / E05) $PRE
...
#VARIANT-END

Extension FLEXIBLE_INDEX_UI_CUSTOM: Verwaltung eigener und angepasster Arbeitsvorräte

Die Hinzufügen eigener Arbeitsvorräte zur Extension FLEXIBLE_INDEX_UI sowie das Verändern der NLI-Standards kann bei Formatumstellungen zu hohen Aktualisierungaufwänden führen. Darum gibt es die Möglichkeit, anzupassende Arbeitsvorräte in eine Extension FLEXIBLE_INDEX_CUSTOM zu kopieren und nur dort anzupassen. Die Extension FLEXIBLE_INDEX_UI sollte immer mit dem NLI Standard identisch sein.

Für die beiden Extensions gelten folgende Regeln:

  • Kommt ein Arbeitsvorrat in beiden Extensions vor, wird derjenige aus der FLEXIBLE_INDEX_UI_CUSTOM verwendet.
  • Kommt ein Arbeitsvorrat nur in der FLEXIBLE_INDEX_UI_CUSTOM vor, wird dieser ebenfalls verwendet.
  • Für Arbeitsvorräte, die nur in der FLEXIBLE_INDEX_UI vorkommen, wird der NLI-Standard verwendet.

Aufbau einer Variantendefinition / eines Arbeitsvorrats

In der Extension können # als Kommentarzeichen verwendet werden, teilweise sind sie allerdings auch Teil von Schlüsselwörtern. Der Grundaufbau einer Variantendefinition / eines Arbeitsvorrats ist wie folgt:

########################################
# Kommentarzeilen mit beliebigem Titel
########################################
#VARIANT-START Variantenname $PRE
ACTION=Typ des Arbeitsvorrats
ACTION.verschiedeneZusatzfeatures

#DISPLAY-START
Definition der Spalten für die Suchergebnisse
#DISPLAY-END

#CORRELATE-START
Verwendete Korrelationsbedingung
#CORRELATE-END

#STATECHECK-START
Verwendeter Statecheck (Fristenprüfung)
#STATECHECK-END

#SEARCHFILTER-START
Definition der Suchfilter
#SEARCHFILTER-END

#VARIANT-END

Es folgen die Blöcke im Einzelnen

#VARIANT-START/END

########################################
# 10 INVOIC-MSCONS Abgleich
########################################
#VARIANT-START INVOIC-MSCONS Abgleich $PRE

Definition des Arbeitsvorrats

#VARIANT-END INVOIC-MSCONS Abgleich $PRE

Die Tags #VARIANT-START und #VARIANT-END begrenzen die Definition des Arbeitsvorrats. Die Kommentarzeilen davor dienen nur der Information (und manchmal Konfusion, wenn sie vom eigentlichen Variantennamen abweichen) und werden programmtechnisch nicht berücksichtigt. Die Zeile #VARIANT-START enthält den wichtigen Variantennamen, den Namen des Arbeitsvorrats, der immer auf $PRE enden muss. Arbeitsvorräte mit Variantennamen ohne $PRE sind veraltet (CCM 1.0) und werden nicht mehr unterstützt.

ACTION-Einstellungen

Dieser Bereich ist nicht durch START/END markiert, sondern hier können einzelne Zeilen stehen, die mit dem Schlüsselwort ACTION beginnen. Die Definition des Suchtyps muss vorhanden sein, alle anderen Einstellungen sind optional

Suchtyp

Die Aufgabe jedes Arbeitsvorrats ist, Nachrichten mit bestimmten Eigenschaften zu suchen. Zusätzlich kann aber für die so gefundenen Nachrichten noch nach zugehörigen (korrelierten) Nachrichten gesucht werden.

Die erste Zeile des Arbeitsvorrats gibt den Suchtyp an:

ACTION=SEARCH             (Kurzform: ACTION=S)

oder

ACTION=SEARCH+CORRELATE   (Kurzform: ACTION=SC)

gibt an, ob der Arbeitsvorrat nur suchen oder zusätzlich auch korrelierte Nachrichten ermitteln soll. Die Haupt-Korrelationsbedingung wird im Block #CORRELATE-START/END definiert, zusätzliche Korrelationsbedingungen in der optionalen Zeile ACTION.additionalCorr

[ToDo:]
EXTERNAL_CORRELATOR
NONE
[TODO Text]

ACTION.additionalCorr: Zusätzliche Korrelationen

Neben der Haupt-Korrelationsbedingung im Block #CORRELATE-START/END können zusätzliche Korrelationsbedingungen definiert werden, die mit einem logischen AND an die Haupt-Bedingung angehängt werden und die Haupt-Bedingung weiter einschränken. Zusammengesetzte Bedingungen sollten in Klammern gesetzt werden, damit sie als Block ausgeführt werden.

ACTION.additionalCorr=(Format.Typ:MSCONS AND CCI_REQ:COM)

Werden keine Klammern gesetzt, kann durch eine OR-Verknüpfung eine komplett unabhängige weitere Korrelation angehängt werden.

ACTION.SecondCor

Wenn es zu einem Dokument mehrere mögliche Typen von korrelierten Dokumenten gibt, kann eine zweite Korrelationsbedingung angegeben werden. Z.B. Wenn als Antwort auf eine UTILMD eine MSCONS oder eine weitere UTILMD kommen kann.

ACTION.additionalSearch: Zusätzliche Suche

Auf die normale Suche kann eine zusätzliche Suche aufgesetzt werden. Diese wird ähnlich wie eine Korrelationssuche für jedes gefundene Dokument ausgeführt. Die AdditonalSearch wird in konkreten Klassen durchgeführt, welche in der Konfiguration referenziert werden, so z.B.:

ACTION.additionalSearch=external:com.nextlevel.ccm.indexing.precorrelate.action.addsearch.UtilmdLieferAnmWT8

oder

ACTION.additionalSearch=external:com.nextlevel.ccm.indexing.precorrelate.action.addsearch.UtilmdLieferAnmWT4

UtilmdLieferAnmWT8 sucht dabei mit der folgenden Lucene-Query

Format.Typ:UTILMD AND CATEGORY:E44 AND STS:7 AND TAK:Z26 AND Format.Direction:<direction> AND INCIDENTIDREF:<incidentId>

<direction> ist die umgedrehte Richtung und <incidentId> die Vorgangsnummer des eigentlichen gefundenen Dokuments. Es werden also bereits bei der initialen Suche (vor der Korrelation) alle Dokumente ausgeschlossen, die keine Antwortnachrichten im Index haben.

UtilmdLieferAnmWT4 negiert lediglich UtilmdLieferAnmWT8

ACTION.claimType: Einstellung für Nachforderungsmails (NFM)

Falls für den Arbeitsvorrat der Versand von Nachforderungsmails (NFM) aktiviert werden soll, muss hier der Nachforderungstyp eingestellt werden. Dies ist in der Regel das Format der Nachrichten, für die NFM versendet werden sollen. Der Nachforderungstyp bestimmt, welche Felder im CCM für die Markierung der nachgeforderten Nachrichten verwendet wird.

ACTION.claimType=UTILMD

oder

ACTION.claimType=CONTRL

Bei der 2. Nachforderung von CONTRL Nachrichten muss der Arbeitsvorrat für die 2. Nachforderung den Nachforderungstyp CONTRL2 bekommen, da die Felder für CONTRL bereits für die erste Nachforderung verwendet werden.

ACTION.docFilter: Ausfiltern der bei NFM nicht zu berücksichtigenden Nachrichten

ACTION.docFilter=org.b2bbp.administration.process.monitoring.autoprocess.RefDocumentFilterNotNotifiableWithCTW,org.b2bbp.administration.process.monitoring.autoprocess.RefDocumentFilterNotified

[TODO Text]

ACTION.corFilter

[TODO Text]

ACTION.claimDirection

[TODO Text]

ACTION.checkBS

[TODO Text]

ACTION.modifier

Mit den Modifiern kann das Verhalten des AV verändert werden. Es können diverse Flags gesetzt werden.

ACTION.modifier=ONLY_ANSWERS
ACTION.modifier=CORRELATE_PARENT
ACTION.modifier=CORRELATE_CHILDREN
ACTION.modifier=SUPPRESS_WARNINGS
ignoreInCorrelation:String1;String2;String3;...

ACTION.additionalExtension

Es kann eine zusätzlich Extension definiert werden, in der z.B. ein- oder auszuschließende MPIDs gepflegt werden können.

Beispiel:

ACTION.additionalExtension=B3P_MSB Format.PartnerCode exclude

Die drei durch Leerzeichen getrennten Parameter bedeuten:

  • Name der Extension, in der z.B. MPIDs gepflegt sind. Diese wird als Properties eingelesen, muss also das Zeilenformat key=value haben. z.B.

    9900000000001=Name MSB1
    9900000000002=Name MSB2
    
  • Name des Feldes im SearchDocument / der Nachricht, das mit der Liste in der Extension abgeglichen wird, z.B. Format.PartnerCode
  • wenn dieser Parameter gleich “exclude” ist, werden alle Dokumente, bei denen der Wert des Suchfeldes in der Extension vorhanden ist, aus dem Suchergebnis ausgeschlossen. Fehlt der Parameter, werden nur die Dokumente im Suchergebnis ausgegeben, bei denen der Wert des Suchfeldes in der Extension vorhanden ist, es werden also alle anderen ausgeschlossen.

ACTION.SelectAllBehavior

[TODO Text]

DASHBOARD

#DISPLAY-START/END

In diesem Block werden die Tabellenspalten definiert, die für die gefundenen Nachrichten angezeigt werden sollen. Eine besondere Rolle spielt die erste Spalte. Diese bestimmt, wonach die gefundenen Suchergebnisse gruppiert werden.

Eine Spaltendefinition hat folgende Form:

IndexFeldname=Spaltentitel;{attribut1=wert1,attribut2=wert2,...}

Beispiele:

Format.PartnerCode=Partner;{visible=false,renderer=com.nextlevel.faces.pm.ui.renderer.EASYPlusMPVRenderer;width=80}
CATEGORY=Kategorie;{width=30}

mögliche Attribute sind:

Attribut Bedeutung
visible=true/false Soll die Spalte angezeigt werden?
width=80 Breite der Spalte in Pixel
renderer=… Hier kann eine Java-Klasse angegeben werden, die anstelle des reinen Werts der Spalte einen bearbeiteten/formatierten Wert oder ein Icon anzeigt.

Renderer müssen immer mit dem voll qualifizierten Klassennamen angegeben werden (Package com.nextlevel.faces.pm.ui).

Beispiel:

renderer=com.nextlevel.faces.pm.ui.renderer.DirectionItemRenderer

Mögliche Renderer sind z.B.:

Renderer Funktion
DirectionItemRenderer zeigt die Versandrichtung als Pfeile nach rechts oder links an.
StateItemRenderer zeigt statt dem Text von VS das entsprechende StatusIcon an
AckItemRenderer zeigt statt dem Text von BS das entsprechende StatusIcon an
DateItemRenderer zeigt ein Datum in der Form 01.01.2019 an
TimeItemRenderer Zeigt eine Zeit in Form 00:00:00 an

#CORRELATE-START/END

In diesem Block wird eine eventuelle Korrelationsbedingung definiert. Damit diese wirksam wird, muss am Anfang des Arbeitsvorrats ACTION=SEARCH+CORRELATE oder ACTION=SC gesetzt sein.

Die Korrelationsbedingung lautet allgemein:

feldInZuKorrelierendemDokument:"{feldInOriginalDokument}"

Beispiel:

INCIDENTIDREF:"{INCIDENTID}"

Diese Korrelationsbedingung bedeutet z.B. dass für jedes vom Arbeitsvorrat gefundene Originaldokument eine Korrelationssuche durchgeführt wird, bei der alle Dokumente (z.B. Vorgänge) gefunden werden, die im Feld “INCIDENTIDREF” die Vorgangsnummer “INCIDENTID” des Originaldokuments haben.

#STATECHECK-START/END

[TODO Text]

#SEARCHFILTER-START/END

Dieser Abschnitt enthält zwei wichtige Elemente des Arbeitsvorrats:

  • die unsichtbaren / verborgenen Filter, die den Arbeitsvorrat definieren
  • die sichtbaren Filter, mit denen sich später die Suchergebnisse einschränken lassen

Definition von Filtern

Filter werden in Form von Suchanfragen auf den CCM Index definiert (Syntax: Lucene 2.4.1). Jeder einzelne Filter hat dabei folgende allgemeine Form:

FilterName[variablenName;variablenTyp]{visible=false}>LuceneQuery
  • Der Filtername wird bei sichtbaren Filtern als Feld neben dem Eingabefeld angezeigt
  • variablenName und variablenTyp spielen nur bei sichtbaren Filtern eine Rolle und definieren den Typ der Variable, die den Inhalt des Filterfelds aufnimmt.
  • über sie Sichtbarkeit entscheidet der Term {visible=false} bzw. {inboxVisible=true}
  • hinter dem “>” steht der Suchterm, nach dem die Nachrichten gefiltert werden sollen

Die unsichtbaren / verborgenen Filter

Diese Filter sind die entscheidenden Einstellungen, die einen Arbeitsvorrat vom anderen unterscheiden. Sie definieren den Arbeitsvorrat. Mit den verborgenen Filtern, wird die Gesamtmenge der vorhandenen Nachrichten auf einen ganz bestimmten Typ von Nachrichten eingeschränkt, z.B. nur UTILMD mit BGM-Kategorie E01 oder mit PRUEFI 11001. Mit dem Arbeitsvorrat können nur Nachrichten dieses Typs, bzw. die damit korrelierten Nachrichten gesucht werden.

Einen verborgenen Filter erkennt man immer an dem Attribut “visible=false”. Der variablenname ist beliebig und wird nicht weiter verwendet, der variablentyp sollte String sein.

Beispiel:

Format[formatTyp0;String]{visible=false}>(Format.Typ:CONTRL OR Format.Typ:APERAK)

Die sichtbaren Filter

Mit den sichtbaren Filtern lässt sich die Menge der Nachrichten, die von dem Arbeitsvorrat nach Anwendung der verborgenen Filter gefunden worden sind, weiter einschränken. Die sichtbaren Filter erscheinen auf der UI des Arbeitsvorrats im oberen Bereich als Eingabefelder neben dem Filternamen.

  • Die Art des Eingabefelds wird durch den variablenTyp bestimmt, der variablenName nimmt den Inhalt des Eingabefelds auf. Er kann im Suchterm verwendet werden. Folgende Variablentypen sind erlaubt:
Typ Bedeutung
String Einzelne Zeichenkette
Date Datumsfeld
Array Erlaubt die Eingabe mehrerer durch Zeilenumbruch oder Komma getrennter Werte; der entsprechende Suchterm wird so interpretiert, dass die Werte durch OR-Verküpfungen gesucht werden
Check Checkbox
Boolean Spezialfeld für die Angabe zweier Checkboxen für die erlaubten Richtungen

Die angezeigten Eingebefelder erfordern zusätzliche Attribute: Width gibt bei Textfeldern die Breite des Eingabefelds an. Die Eingabefelder werden in der Reihenfolge der Definition nebeneinander angezeigt. Der Parameter [newRow=true] erzwingt, dass mit dem aktuellen Filterfeld eine neue Zeile beginnt.

Ein sichtbarer Filter hat die folgende allgemeine Form:

FilterName[variablenName;variablenTyp]{[newRow=true];width=FeldbreiteInPixeln;inboxVisible=true}>LuceneQuery({variablenName})

Beispiel:

DAR[ref0;Array]{width=220;inboxVisible=true}>Format.ReferenceId:{ref0}
[TODO: FILTER, DB. (DB-Filter statt Index-Filter)]

Gesamte Suchanfrage

Die gesamte Suchanfrage wird zusammengesetzt, indem alle Suchfilter, die unsichtbaren wie die nicht leeren sichtbaren mit AND Verknüpfungen hintereinandergeschaltet werden.

Mit der Einstellung ACTION.additionalSearch kann noch eine weitere Suche, die in Form einer Java-Klasse definiert sein muss, mit AND hinzugefügt werden.

#ADDENDER-START/END

Addender dienen dazu, in der Liste der angezeigten Suchergebnisse zusätzliche Zeilen mit Dokumenten anzuzeigen. Dies können auch virtuelle Dokumente sein, die mit beliebigen Werten gefüllt werden können.

Die Konfiguration der Zeilen geschieht in spezialisierten Java-Klassen, die für den Einzelfall entwickelt werden müssen.

[TODO Text]

Beispiel für vollständigen Arbeitsvorrat / Variantendefinition

###################################################################
# UTILMD Fristenmanagement: Lieferanmeldung alle (E01 )
###################################################################
#VARIANT-START Lieferbeginn (E01) $PRE
ACTION=SEARCH+CORRELATE

#DISPLAY-START
Format.ReferenceId=Ref Nr.;{width=120}
#first column is master column
INCIDENTID=VorgangsNr.;{width=220}
INCIDENTIDREF=VRef.Nr.;{width=220}
CATEGORY=Kategorie
VS=VS;{renderer=com.nextlevel.faces.pm.ui.renderer.StateItemRenderer;width=50}
BS=BS;{renderer=com.nextlevel.faces.pm.ui.renderer.AckItemRenderer;width=50}
CC2=CS
Format.Direction=Richtung;{renderer=com.nextlevel.faces.pm.ui.renderer.DirectionItemRenderer;width=50}
CHANNEL=Channel
PRUEFI=Prüfi
Format.AlternativeId=Alternative Id
STREET=Straße
HOUSENR=Nr
PLACE=Ort
PLZ=Plz
Format.system=System
SYSNAME=System_Name
Format.PartnerCode=Partner;{visible=false}
MPNAME=MP_System
Format.Typ=Format
Format.Version=Version
KUNDE=Kunde
STS=Qualifier
STSTEXT=Statusgrund
MTR=Meldepunkt
COUNTER=Zähler
ZVF=Bilanzierungsgrundlage
DTM93=Stichtag;{renderer=com.nextlevel.faces.pm.ui.renderer.DateItemRenderer}
B3P.Date=Datum;{renderer=com.nextlevel.faces.pm.ui.renderer.DateItemRenderer}
B3P.Time=Uhrzeit;{renderer=com.nextlevel.faces.pm.ui.renderer.TimeItemRenderer}
B3P.Notif=gesendet;{renderer=com.nextlevel.faces.pm.ui.renderer.DateTimeItemRenderer}
related.messages=RelatedMsg;{renderer=com.nextlevel.faces.pm.ui.renderer.RelatedMessagesRenderer}
B3P.MessageId=ID;{visible=false}
$refDoc.type=Format.Typ
#DISPLAY-END

#CORRELATE-START
INCIDENTIDREF:"{INCIDENTID}"
#CORRELATE-END

#STATECHECK-START GREEN
external:com.nextlevel.ccm.indexing.precorrelate.statecheck.UtilmdCheck4States.java 8 4 false
#STATECHECK-END

#SEARCHFILTER-START
Datum[date0,date1;Date]{inboxVisible=true}>B3P.Date:[{date0} TO {date1}]
Partner[partner0;String]{newRow=true;width=120;inboxVisible=true}>Format.PartnerCode:{partner0}
Ref.Nr[ref0;String]{width=140;inboxVisible=true}>Format.ReferenceId:{ref0}
Bilanzierungsgrundlage[zvf0;String]{width=50;inboxVisible=true}>ZVF:{zvf0}
STSTEXT[ststext;String]{visible=false}>STSTEXT:{ststext}
System[sender0;Array]{newRow=true;width=120;inboxVisible=true}>Format.system:{sender0}
Meldepunkte[pods0;Array]{width=250;inboxVisible=true}>MTR:{pods0}
BS[bs0;String]{width=50;inboxVisible=true}>BS:{bs0}
Richtung[dir0;Boolean]{inboxVisible=true}>Format.Direction:{dir0}
Notif[not0;Check]{inboxVisible=true}>CC2:{not0}
Format[formatTyp0;String]{visible=false}>Format.Typ:UTILMD
STS[sts0;String]{visible=false}>STS:7
Kategorie[category;String]{visible=false}>CATEGORY:E01
#SEARCHFILTER-END
#VARIANT-END
View Me   Edit Me