Nomenklatur in eBiss

Um eine möglichst einheitliche und konsistente und verständliche Namensgebung der verschiedenen Objekte zu erzeugen empfiehlt der Autor folgende Vorgehensweise. Dabei orientieren wir uns an der Reihenfolge,welche sich durch die internen Abhängigkeiten in eBiss ergeben und im HowTo Einrichten einer Datenstrecke mit Konvertierung aufgezählt sind.

Für die Benennung der DLL Datei werden i.d.R. die Bezeichner des zu bedienenden Hostsystems oder der Schnittstelle allg. verwendet. Idealerweise so, dass die Bezeichnung eindeutig identifizierbar und auch sprechend bleibt. Die Bezeichnung des Namensraums sollte idealerweise identisch gehalten werden.

Typen werden Idealerweise mit einem sprechenden Typnamen versehen. Da der Namensraum bereits in der Typbibliothek definiert ist ergibt sich dann der zusammengesetzte Typname wie folgt:

namespcace.typename

Beispiel: SAP.INVOIC01 oder optional auch mit einem untergeordneten Namensraum um z.Bsp. Subtypen zu definieren.

namespcace.subnamespace.typename

Beispiel:FXL.INVRPT.STOCK und FXL.INVRPT.MOVEMENT

Hinweis: Benutze die Type Beschreibung um Hinweise auf die Nachrichten Richtung ein-, oder ausgehend zu geben.

Es bietet sich an für ein Repositorium den Gleichen Namen zu vergeben welcher auch in der Typbibliothek als Namensraum gem. Pkt.1 angegeben wurde.

1. Erkennungs Komponente = namespace¹⁾
2. Analyse Komponete = namespace²⁾
3. Schreibkomponente = namespace³⁾
4. Lesekomponente = namespace⁴⁾
5. Kontainerisierer = namespace⁵⁾ oder ggf. im Kontainerisierer verwendete Maske
6. Entitätstyp = namespace.typename

Der Autor verwendet i.d.R. den Entitätsnamen von Quell- und Zielobjekt in dieser Form:

namespace.typename.to.namespace.typename

Viele System kommen mit genau einem Standard Template Partner aus. Dieser wird auch miest aus dem Standard Template Verzeichnis importiert. Falls mehrere Templatepartner notwendig werden, bietet es sich an die Bezeichnung so sprechend zu machen, dass erkennbar ist für welchen Zweck dieser angelegt wird.

Nachrichtenkörbe werden nach unserer Philosophie idealerweise mit einem von- bzw. zu Richtungszeiger und Rollenname versehen.

Beispiele:

• From.Host
• To.Host
  • optional To.Host.Test
• From.Partner
• To.Partner
  • To.Partner.Test

Bezeichnung, welche auf einen Kommunikationskanal schliessen würde sollen vermieden werden. Denn es ist nicht auszuschliessen, dass ein Nachrichten aus verschiedenen Kommunikationskanälen bedient wird oder darin befindliche Nachrichten nur über einen dedizierten Kanal gesendet werden.

Bei den Kommunikationskanälen bietet es sich an die Kurzbezeichnung der Kanalart und der Richtung(send bzw. receive) gefolgt von einer individuellen Bezeichnung zu bilden.

Beispiele:

• SMTP.send.eGate
• POP.receive.eGate
• HD.send.Host
• HD.receive.Host
• FTP.send.Domaine
• FTP.receive.Domaine

Die Prozess- oder Jobnamen sollten immer mit einem Kennzeichen für ein oder ausgehende Prozesse und einer untergeordneten Nummerierung angelegt werden.

Wir verwenden dafür:

• den Buchstaben „i“ für eingehende Prozesse
• den Buchstaben „o“ für eingehende Prozesse
• den Buchstaben „z“ für Prozesse die weder eingehend noch ausgehend sind.

Ein anschliessende Nummerierung versucht i.d.R. die drei Stufen der Integration abzubilden. Dies ist:

1. Öffnen eines Empfangskanals Kanals oder Backendintegration und etablieren der Nachrichten in einem Nachrichtenkorb in eBiss.
2. Analysieren, und selektives Verarbeiten bzw. Transformieren der unter 1. empfangenen Nachrichten und Erzeugen neuer konvertierter Nachrichten in anderen Nachrichtenkörben oder direktes Einfügen über Backendintegration.
3. I.d.R. öffnen eines Sende-Kanals zum Übermitteln der unter 2. erstellten und nun zu sendenden Nachrichten.

Beispiele:

• i1. Fetch from eGate
  • optional: i1a. Fetch from FTP von Partner-Domain
• i2. Standard Inbound
  • optional: i2a. Process Message type XYZ
• i3. Send to Host
• o1. Fetch from Host
  • o1a. optional: Fetch from alternate Host
• o2. Standard Outbound
  • optional: o2a. Process Message type XYZ
• o3. Send to Partner
  • optional: o3a. Send to FTP.Domain
• z1. Clean Up
• z2. Discard Messages

Auch die vielen verschiedenen Jobobjekte bieten sowohl Namen als auch Bemerkungen an. Da i.d.R. die Jobobjektnamen beim Anlegen eigentlich nur generisch erzeugt werden ist es hilfreich für das Lesen und Verstehen von Trace Logs oder Prozessen, wenn die generischen Namen des Jobobjekts mit den Inhalten des wichtigsten Attributs ergänzt oder komplett umbenannt werden.⁶⁾

Beispiele:

• EntitySelector Namen werden z.Bsp. ergänzt mit dem Typnamen der selktiert werden soll.
• EntityTransformer Namen enthalten Hinweise auf die Mappings welche verwendet werden sollen.
• EntityIfCase Namen spiegeln idealerweise Ihre Schaltmechanik wieder.
• EntityMessageCreator werden ergänzt mit dem Namen der Nachrichtenbox, in welche kontainerisiert werden soll.

Für die Automatisierungen bietet es sich an, einfach den Namen des zu triggernden Jobs als Bezeichnung zu übernehmen um 1. Missverständnisse zu vermeiden und 2. das Neuerfinden eines Namens zu sparen.