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 Einrichten einer Datenstrecke mit Konvertierung.

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.

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:

namespcace.typename

Example: SAP.INVOIC01 or optionally with a subordinate namespace, for example, to define subtypes.

namespcace.subnamespace.typename

Example:FXL.INVRPT.STOCK and FXL.INVRPT.MOVEMENT

Note: Use the Type Description to give hints about inbound or outbound direction.

It makes sense to give a repository the same name as the one specified in the type library as namespace according to Pt.1.

1. Recognition component = namespace¹⁾
2. Analysis Component = namespace²⁾
3. write component = namespace³⁾
4. Read component = namespace⁴⁾
5. Containerizer = namespace⁵⁾ or mask used in the containerizer, if applicable.
6. Entity type = namespace.typename

The author usually uses the entity name of source and target object in this form:

namespace.typename.to.namespace.typenam

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.

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.

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

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:

1. Opening a receiving channel Channel or backend integration and establishing the messages in a message basket in eBiss.
2. 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.
3. 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