Dynamische Funktionen

„Dynamisch Funktionen“ können bei der Arbeit im Customizing sehr hilfreich sein. Diese Funktionen werden im Customizing von B2B by practice verwendet, um zur Laufzeit Context Variablen befüllen zu können und dadurch ein verändertes Ablaufverhalten zu erreichen. Folgende Funktionen können deklarativ verwendete werden.

VAR

Mit dieser Funktion kann auf einen Wert im MessageContext zugegriffen werden. Die Funktion liest den Wert aus dem MessageCointext der unter dem übergebenen Namen gespeichert ist.

Seit der Version vom 12.04.2010 kann die Funktion noch mit weiteren Alternativen Parameternamen auf den MessageContext zugegriffen werden. Diese werden durch "|" voneinander getrennt. Die Ermittlung eines Wertes aus dem MessageContext beginnt mit dem ersten Namen. Sollte dieser einen Wert ungleich NULL liefern, wird dieser Wert zurückgeliefert. Die Funktion wird beendet. Sollte die Überprüfung für den Namen keinen Wert finden, so beginnt die Prozedur mit dem zweiten Wert. Dies wird solange weitergeführt, solange Parameternamen vorhanden sind.

Heading Beispiel	Heading Beschreibung
${var(B3P_BASE_CHANNEL_ID)}	Die Channel ID wird von jedem „2Engine“-Service in den MessageContext geschrieben.
${var(B3P_BASE_MAIL_FROM|B3P_BASE_AS2_FROM}	Beispiel für die Verwendung von Alternativen Parameternamen

Die Funktion VAR kann nicht mit weiteren „Dynamischen Funktionen“ verbunden wer-den.

TEMPLATE

Die Template-Funktion stellt eine Template-Engine zur Verfügung. Die Implementie-rung ist mittels „Velocity“ realisiert. Die Wertemenge der über Templates eingebunden Wert kommt ausschließlich aus dem MessageContext.

Heading Beispiel	Heading Beschreibung
${template(&(this.FORMAT.type))} , '${template(&(this.FORMAT.type),"UTILMD")}	Der Funktionsrumpf wird wie bei VAR definiert (${template()}). Der Übergabeparameter 1 ist ein Text, der mit den eigentlichen Templates versehen werden kann. Hier wird der Typ der Nachricht aus dem MessageContext gelesen.

Die Funktion kann auch mit einem weiteren Parameter aufgerufen werden, der im Fall zurückgegeben wird, wenn die Template-Funktion kein Ergebnis liefert. Dieser ist in Anführungszeichen anzugeben.

Das eigentliche Velocity Template muss in der Form &(objectId) angegeben werden, da es sonst als „Dynamische Funktion“ interpretiert würde. In den Template-Engine Context ist der MessageContext als „this“ übergeben worden. Alle Anfragen an den MessageContext erfolgen über diesen Bezeichner. Der Vorteil der Template-Funktion liegt darin, dass auch hierarchische Objekte genutzt werden können. Wo VAR nur den Zugriff auf das FORMAT-Objekt zulässt, kann über den Templateansatz auch auf tieferen Objekte und Attribute zugegriffen werden. Das Beispiel zeigt den Zugriff auf das Format-Objekt. Das Attribut Typ wird daraus ge-lesen. Es ist auch möglich aus den zusätzlichen Attributen des Format-.Objektes zu lesen. Diese können ja über die DIALECT.properties frei befüllt werden.

Beispiel Das Beispiel zeigt den Zugriff auf ein Attribut, welches über die DIALECT.properties definiert in das Format-Objekt geschrieben wurde. Es wird hier verwendet, um die Konvention der Betreff und Dateinamen der BDEW einzuhalten. ${template(&(this.FORMAT.attributes.Date))}

LOADEXTENSION

Die Funktion lädt eine Datei (Template) aus der Extension-Tabelle und führt diesen Text der Template-Engine automatisch zu. Dieser Mechanismus unterstützt die Be-handlung verschiedener MailTexte innerhalb von B2BBP. Ein Fallbackmechanismus ermöglicht ein rekursives Laden von Extensions.

Heading Beispiel	Heading Beschreibung
${loadExtension(errormail.txt)}	Die Funktion lädt die Datei (das Template) „errormail.txt“ aus der Extension-Tabelle und führt es der Template-Engine zu.

Ein Überladen der Funktion ist möglich. Damit ist es per Customizing möglich auf der Basis von IDs, unteschiedliche MailTexte (-Templates) zu laden.

'Beispiel: ' loadExtension mit template Funktion Bevor loadExtension hier aufgerufen wird, wird das Ergebnis von

${template(&this.FORMAT.senderCode)_mail.txt)}

ermittelt. Der Absender BDEW Code wird hier dem Dateinamen vorangestellt. Z.B. 902637467_mail.txt. Bei einem anderen Absender wird ein anderer Text geladen.

${loadExtension(${template(&this.FORMAT.senderCode)_mail.txt)})}

Über den Fallbackmechanismus ist es zudem möglich, auf allgemeinere Extensions zurückzugreifen, wenn speziellere nicht verfügbar sind. Beispiel: In der Extension Tabelle sind folgende Mailtemplates definiert:

• outbound_mail
• outbound_mail_1234567890

'Beispiel:' loadExtension mit Template-Funktion und Fallback-Logik Bevor loadExtension hier aufgerufen wird, wird das Ergebnis von <pre>${template(outbound_mail_&(this.FORMAT.senderCode))}</pre> ermittelt. Der Absender BDEW Code wird hier dem Dateinamen vorangestellt. Z.B. outbound_mail_1234567890.Da das Template existiert, wird es geladen. Ermittelt die Funktion hingegen outbound_mail_0987654321, wird der Versuch scheitern, diese Extension zu laden. Der Fallbackmechanismus versucht als nächstes die Extension outbound_mail zu laden, die ja existiert. Hierdurch kommt es nicht zu einem Fehler, sondern zu einer allgemeineren Ausprägung eines Mailtextes. ${loadExtension(${template(outbound_mail_&(this.FORMAT.senderCode))},true)}

LOADEXTENSIONPROPERTY

Die Funktion lädt eine Eigenschaft aus einer Extension Datei (Template) aus der Ex-tension-Tabelle und führt diesen Text der Template-Engine automatisch zu. Ein Fall-backmechanismus wird auf die Eigenschaften angewendet.

Heading Beispiel	Heading Beschreibung
${loadExtensionProperty(SENDER_MAIL,1234567890 )}	Die Funktion lädt die Extension Datei SENDER_MAIL und ermittlet den Wert der Eigenschaft 1234567890. Dieser Wert wird an die TemplateEngine weitergeleitet, um dynamische Werte zu ermöglichen.

Ein Überladen der Funktion ist möglich. Damit ist es per Customizing möglich auf der Basis von IDs, unteschiedliche Extension(-Templates) zu laden.

'Beispiel:' loadExtensionProperty mit Template-Funktion Bevor loadExtensionProperty hier aufgerufen wird, wird das Ergebnis von

${template(&this.FORMAT.senderCode))}

ermittelt. Die ermittelte Extension Datei wird geladen und die Eigenschaft 1234567890 wird daraus ermittelt.

${loadExtensionProperty(${template(&this.FORMAT.senderCode))},1234567890)}

Bei Fallback wird die Eigenschaft anhand des oben beschriebenen Vorgehens soweit generalisiert bis eine entsprechende Eigenschaft gefunden wurde.

'Beispiel:' loadExtensionProperty mit Template-Funktion und Fallback-Logik Bevor loadExtensionProperty hier aufgerufen wird, wird das Ergebnis von

${template(&this.FORMAT.senderCode))}

ermittelt. Die ermittelte Extension Datei wird geladen und die Eigenschaft 123_4567_890 wird daraus ermittelt. Sollte diese Eigenschaft nicht existieren, wird als nächstes versucht, die Eigenschaft 123_4567 zu laden. Sollte Eigenschaft 123 nicht gefunden werden, wird ein Fehler geworfen.

${loadExtensionProperty(${template(&this.FORMAT.senderCode))},123_4567_890, true)}

DATE

Die Funktion ermittelt das aktuelle Tagedatum (mit Uhrzeit) und übergibt es im angegebenen Format.

'Beispiel:' Die Funktion ermittelt das aktuelle Tagesdatum (Uhrzeit) und gibt es im angegebenen Format. Z.B (08312008) für 31.08.2008 ${date(MMddyyyy)}

Das Überladen der Funktion ist nicht möglich.

GETMPIDMAIL

Die Funktion ermittelt die in der MPID_SYNC Extension hinterlegte Emailadresse zu den aktuellen Sender bzw. Partner Mpids.

Es wird von folgendem Format der MPID_SYNC Extension ausgegangen:

sender.partner.MAIL={[timestampFrom1-timestampTo1, test1@next-level-integration.com],
[timestampFrom2-timestampTo2, test2@next-level-integration.com]}

Dieses Format wird automatsch verwendet, falls die MPIDs über die AS2 Oberfläche angelegt werden. Für verschiedene Zeiträume können unterschiedliche Emailadressen angegeben werden.

Heading Beispiel	Heading Beschreibung
${getmpidmail(${template(&(this.FORMAT.senderCode))},${template(&(this.FORMAT.partnerCode))})}	ermittelt die aktuell gültige Emailadresse

Falls sender.partner nicht gefunden wird, wird nach .partner gesucht und dieser Wert zurückgegeben.

GETMPIDNAME

Die Funktion ermittelt den in der MPID_SYNC Extension hinterlegten Namen zu den aktuellen Sender bzw. Partner Mpids.

Es wird von folgendem Format der MPID_SYNC Extension ausgegangen:

sender.partner.NAME=Next Level Integration

Dieses Format wird automatsch verwendet, falls die MPIDs über die AS2 Oberfläche angelegt werden.

Heading Beispiel	Heading Beschreibung
${getmpidname(${template(&(this.FORMAT.senderCode))},${template(&(this.FORMAT.partnerCode))})}	ermittelt den hinterlegten Namen

Falls sender.partner nicht gefunden wird, wird nach .partner gesucht und dieser Wert zurückgegeben.

GETUSEDSERVICES

Die dynamische Funktion getUsedServices wird verwendet, falls AS2 und Mail parallel verwendet werden und entschieden werden muss, welcher Senderservice ausgeführt werden soll (Wert von B3P_USED_SERVICES_ID). Sie versucht in den AS2 Partnerbeziehungen eine passende Beziehung zu finden. System und Partner MPID werden aus dem Format Objekt im MessageContext verwendet. Falls ein Eintrag gefunden wurde, wird in der USED_SERVICES Extension nach COMMUNICATION_AS2EXT gesucht. Falls keine Beziehung gefunden wird, wird der als Parameter übergebene Ausdruck als LOADEXTENSIONPROPERTY ausgewertet und zurückgegeben.

Heading Beispiel	Heading Beschreibung
${getUsedServices(USED_SERVICES,${template(COMMUNICATION_&(this.B3P_COMMUNICATION_TYPE))},true)}	im Mail Fall, wird der Service ausgeführt, der in der USED_SERVICES Extension unter COMMUNICATION_MAIL angegeben wurde, ausgeführt.
${getUsedServices(USED_SERVICES,${template(COMMUNICATION_&(this.FORMAT.senderCode)_&(this.FORMAT.partnerCode))},true)}	Im nicht-as2 Fall wird ein speziell für sender-partner definierter Service aus der USED_SERVICES gestartet.
${getUsedServices(USED_SERVICES,COMMUNICATION_MAIL,true)}	wählt im nicht-as2 Fall immer den Service, der über COMMUNICATION_MAIL definiert wurde.

Mit ",true" wird im nicht AS2-Fall der Fallback der LOADEXTENSIONPROPERTY aktiviert und falls z.B. COMMUNICATION_MAIL in der USED_SERVICES Extension nicht existiert, nach COMMUNICATION gesucht.