======= Naming conventions in eBiss =====

In order to create a naming system for the various objects that is as uniform, consistent and comprehensible as possible, the author recommends the following procedure.
We orientate ourselves on the order, which results from the internal dependencies in eBiss and which are listed in the HowTo [[howtos:data_rail|]].

===== 1. name interface types =====

==== Name type library ====

For the naming of the DLL file, the identifiers of the host system to be operated or the interface are generally used. Ideally in such a way that the designation remains uniquely identifiable and also meaningful. 
Ideally, the name of the namespace should be kept identical.

==== Naming system-managed types ===

Types are ideally given a descriptive type name. Since the namespace is already defined in the type library, the composite type name is then calculated as follows:
<code>namespcace.typename</code> Example: **SAP.INVOIC01** or optionally with a subordinate namespace, for example, to define subtypes.
<code>namespcace.subnamespace.typename</code> Example:**FXL.INVRPT.STOCK** and **FXL.INVRPT.MOVEMENT**

{{:images:sign_warning.png?nolink|}}**Note:** Use the Type Description to give hints about inbound or outbound direction.
======= 2. name repositories ====
It makes sense to give a repository the same name as the one specified in the type library as namespace according to [[[:howtos:namingconventions#interfaces_name_types_type|Pt.1]].

  - Recognition component = namespace((or optional if several different namespace.typename are necessary))
  - Analysis Component = namespace((or optional if several different namespace.typename are necessary))
  - write component = namespace((or optional if several different namespace.typename are necessary))
  - Read component = namespace((or optional if several different namespace.typename are necessary))
  - Containerizer = namespace((or optional if several different namespace.typename are necessary)) or mask used in the containerizer, if applicable.
  - Entity type = namespace.typename
====== 3. name mapping definitions =====

The author usually uses the entity name of source and target object in this form:
<code>namespace.typename.to.namespace.typenam</code>

===== 4. name default template partner =====

Many systems get by with exactly one standard template partner. This is also imported from the standard template directory.
If more than one template partner is required, it is a good idea to make the name so meaningful that it is clear for which purpose it is created.

====== 5. name message boxes =====

According to our philosophy, message baskets are ideally provided with a from/to direction pointer and role name.\\ 

**Examples**:
  *From.Host
  * To.Host
    * optional To.Host.Test
  * From.partner
  * To.partner
    * To.partner.test *

Designation, which would indicate a communication channel, should be avoided. This is because it cannot be ruled out that a message is served from different communication channels or that messages contained therein are only transmitted via a dedicated channel. 
===== 6. designate communication channels =====

For the communication channels it is useful to create the short name of the channel type and the direction (send or receive) followed by an individual name.

**Examples:**
  * SMTP.send.eGate
  * POP.receive.eGate
  * HD.send.Host
  * HD.receive.host
  * FTP.send.Domain
  * FTP.receive.Domain

===== 7th name processes =====

The process or job names should always be created with an indicator for in or outgoing processes and a subordinate numbering.

We use for this:
  * the letter **"i "** for incoming processes
  * the letter **"o "** for incoming processes
  * the letter **"z "** for processes that are neither incoming nor outgoing

Subsequent numbering usually attempts to represent the three levels of integration. This is:
  - Opening a receiving channel Channel or backend integration and establishing the messages in a message basket in eBiss. 
  - Analyzing, and selectively processing or transforming the messages received under 1. and creating new converted messages in other message baskets or direct insertion via backend integration.
  - Usually opening a send channel to transmit the messages created under 2. and now to be sent.


**Examples:**
  * **i1.** Fetch from eGate
    * optional: i1a. Fetch from FTP from 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
    * o2a. optional: process message type XYZ
  * **o3.** Send to Partner
    * o3a. optional: Send to FTP.Domain
  * **z1.** Clean Up