====== 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 [[howtos:data_rail|]] aufgezählt sind. ===== 1. Schnittstellen Typen benennen ===== ==== Typbibliothek benennen ==== 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. ==== Systemverwaltete Typen benennen ==== 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** {{:images:sign_warning.png?nolink|}}**Hinweis:** Benutze die Type Beschreibung um Hinweise auf die Nachrichten Richtung ein-, oder ausgehend zu geben. ===== 2. Repositorien benennen ===== Es bietet sich an für ein Repositorium den Gleichen Namen zu vergeben welcher auch in der Typbibliothek als Namensraum gem. [[:howtos:namingconventions#schnittstellen_typen_benennen|Pkt.1]] angegeben wurde. - Erkennungs Komponente = namespace((oder optional falls mehrere unterschiedliche nötig individuell **namespace.typename**)) - Analyse Komponete = namespace((oder optional falls mehrere unterschiedliche nötig individuell namespace.typename)) - Schreibkomponente = namespace((oder optional falls mehrere unterschiedliche nötig individuell namespace.typename)) - Lesekomponente = namespace((oder optional falls mehrere unterschiedliche nötig individuell namespace.typename)) - Kontainerisierer = namespace((oder optional falls mehrere unterschiedliche nötig individuell namespace.typename)) oder ggf. im Kontainerisierer verwendete Maske - Entitätstyp = namespace.typename ===== 3. Mappingdefinitionen benennen ===== Der Autor verwendet i.d.R. den Entitätsnamen von Quell- und Zielobjekt in dieser Form: namespace.typename.to.namespace.typename ===== 4. Standard Template Partner benennen ===== 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. ===== 5. Nachrichtenboxen benennen ===== 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. ===== 6. Kommunikationskanäle benennen ===== 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 ===== 7. Prozesse benennen ===== 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: - Öffnen eines Empfangskanals Kanals oder Backendintegration und etablieren der Nachrichten in einem Nachrichtenkorb in eBiss. - 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. - 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. prozess Message type XYZ * **i3.** Send to Host * **o1.** Fetch from Host * o1a. optional: Fetch from alternate Host * **o2.** Standard Outbound * o2a. optional: prozess Message type XYZ * **o3.** Send to Partner * o3a. optional: Send to FTP.Domain * **z1.** Clean Up * **z2.** Discard Messages ==== Jobobjekte benennen ==== 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.((z.Bsp. per Copy Paste der Hauptattributeigenschaft.)) **Beispiele:** * [[prozessdefinition:jobs:jobsteps:allgemein:entityselector|]] Namen werden z.Bsp. ergänzt mit dem Typnamen der selktiert werden soll. * [[prozessdefinition:jobs:jobsteps:allgemein:entitytransformer|]] Namen enthalten Hinweise auf die Mappings welche verwendet werden sollen. * [[prozessdefinition:jobs:jobsteps:allgemein:entityifcase|]] Namen spiegeln idealerweise Ihre Schaltmechanik wieder. * [[prozessdefinition:jobs:jobsteps:allgemein:entitymessagecreator|]] werden ergänzt mit dem Namen der Nachrichtenbox, in welche kontainerisiert werden soll. ===== 8. Automatisierung benennen ===== 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.