Die Funktion wird mit zwei Argumenten aufgerufen und gibt ein String-Literal zurück.

Zusammenfassung

Die dynamische Funktion ${getmpidsecurity(<arg1>, <arg2>)} wird mit zwei Argumenten (Sender-ILN und Empfänger-ILN) aufgerufen und gibt, abhängig einer hinterlegten Security-Regel, ein String-Literal zurück. Die Funktion dient z.B. dazu, einem Umsystem wie einem Mail- oder Sicherheits-Server ein zu definierendes String-Literal (z.B. {trust_smime}, {crypt_smime} oder {sign_smime} ) in den Namen/Betreff einer E-Mail zu schreiben, damit dieses System erkennt, ob eine Mail

  • verschlüsselt
  • signiert
  • verschlüsselt und signiert
  • oder ohne Modifikation

versendet werden soll.

Diese Regeln können und sollten, nachdem die zwei nachfolgend erläuterten Extensions angelegt wurden, über den MPID-Editor der B2B gepflegt werden.

Die Argumente der dynamischen Funktion ${getmpidsecurity(<arg1>, <arg2>)} können selber dynamische Funktionen (Template-Ausdrücke) sein. Diese werden ebenfalls angewendet und ausgewertet.

Konfiguration

Die dynamische Funktion ${getmpidsecurity(<arg1>, <arg2>)} benötigt zwei Extensions: Die Extension MPID_SECURITY, in welcher die unterschiedlichen Security-Rules für Marktpartnerbeziehungen hinterlegt werden, und die Extension MPID_SECURITY_CONF, in welcher die einzufügenden String-Literale für die vier oben erwähnten Zustände (‘verschlüsselt’, ‘signiert’, ‘verschlüsselt & signiert’ und ‘nichts von beidem’) gespeichert werden.

MPID_SECURITY

Die Extension MPID_SECURITY enthält die für Marktpartnerbeziehungen hinterlegten Security-Rules. Es werden Key-Value-Pairs gespeichert, wobei der Key eine Punkt-getrennte Kombination aus SENDER-ILN , EMPFÄNGER-ILN und dem Schlüsselwort ENCRYPT bzw. SIGN ist, und der Value den Wert true bzw. false annehmen kann..

Nachfolgend ein Beispiel:

99876543210.98876543210.ENCRYPT=true
99876543210.98876543210.SIGN=true

Um Regeln auch “gröber” definieren zu können, kann der Sender leer gelassen werden. Dann reicht eine Regel für alle eigenen Systeme (z.B. Netz, Lief etc.) und man muss bei einer Änderung nur diese und nicht alle Kombinationen anpassen. Die obigen Regeln sähen dann folgender Maßen aus, und werden für alle Sender zutreffen, die an diesen Speziellen EMPFÄNGER senden:

.98876543210.ENCRYPT=false
.98876543210.SIGN=false

Eine spezielle Regel mit <Sender>.<Empfänger>.<ENCRYPT | SIGN> wird der groben Regel mit .<Empfänger>.<ENCRYPT | SIGN> vorgezogen.

Damit würde die dynamische Funktion ${getmpidsecurity(<arg1>, <arg2>)} für alle Empfänger mit der ILN 99876543210 (unabhängig von der Sender-ILN) für ENCRYPT und SIGN false zurückliefern, außer, wenn der Sender die ILN 99876543210 hat. In diesem Fall würde die spezielle Regel von oben die generelle Regel darunter überlagern.

Wurde eine gewisse Regel für ein Argumenten-Paar (<Sender>.<Empfänger> oder nur .<Empfänger>) nicht hinterlegt, wird als Ergebnis der dynamischen Funktion der Wert des in der MPID_SECURITY_CONF-Extension hinterlegten DEFAULT-Key zurückgegeben.

Die Extension MPID_SECURITY kann leer angelegt und dann bequem über den MPID-Editor gepflegt werden.

MPID_SECURITY_CONF

In der Extension MPID_SECURITY_CONF werden die String-Literale den nachfolgend aufgelisteten Keys zugeordnet:

  • ENCRYPT_SIGN
  • ENCRYPT
  • SIGN
  • DEFAULT

Nachfolgend ein Beispiel, wo den oberen drei Zuständen Werte ({trust_smime}, {crypt_smime} und {sign_smime}) zugewiesen wurden, und beim Zustand ‘weder verschlüsseln, noch signieren’ (der als DEFAULT bezeichnet wird) nichts zugewiesen wurde.

MPID_SECURITY_CONF:

ENCRYPT_SIGN={trust_smime}
ENCRYPT={crypt_smime}
SIGN={sign_smime}
DEFAULT

Diese hier hinterlegten String-Literale ({trust_smime}, {crypt_smime} und {sign_smime}) sind das Ergebnis der Auswertung der dynamischen Funktion und werden an die Stelle “geschrieben”, an welcher ${getmpidsecurity(…)} aufgerufen wurde.

Verwendung der dynamischen Funktion

Wie jede dynamische Funktion kann auch diese hier überall dort angewendet und ausgewertet werden, wo der Context-Parser der B2B angewendet wird, z.B. für Action- und Service-Properties, in manchen ChannelDistributions oder Extensions. Nachfolgend drei Beispiele für die korrekte Anwendung der hier beschriebenen dynamischen Funktion.

Spezielle Regel mit Sender- undEmpfänger-ILN

${getmpidsecurity(99876543210,99876543210)}

Generelle/grobe Regel nur mit Empfänger-ILN

${getmpidsecurity(,99876543210)}

Spezielle Regel mit Template-Ausdruck, der Sender und Empfänger-ILN aus dem Format-Objekt lädt

${getmpidsecurity(${template(&(this.FORMAT.senderCode))},${template(&(this.FORMAT.partnerCode))})}
View Me   Edit Me