This chapter describes all the important principles E-Bonding Runbook is based on. Understanding them is required to implement new interfaces with E-Bonding Runbook.

Principle of the InterfaceUser

The configuration of so-called "InterfaceUser" entries is needed to run the E-Bonding Runbook Event Engine trouble-free.
The configuration of InterfaceUsers can be done via the E-Bonding Runbook Platform Console.
 InterfaceUsers are needed for the E-Bonding Runbook Event Engine to decide whether an outbound event shall be sent to an interface partner system or be ignored. Events must be ignored when they have been created by E-Bonding Runbook initially.
E-Bonding Runbook uses defined Remedy ARS User, which may vary per interface partner. Every time a data record is created, modified or deleted by a E-Bonding Runbook user this event is being ignored and not sent back to the interface partner again. This is ensured by reconciliation of a list of given InterfaceUsers.

Principle of the Partner

A partner in E-Bonding Runbook is the synonym for an interface between E-Bonding Runbook and a partner ticket system.
The configuration of partners can be done via the E-Bonding Runbook Partner Console.
 A partner has miscellaneous technical characteristics and relations to other configuration data like PartnerGroups and PartnerMessages. These additional configuration data are described in the following chapters.
Technical characteristics of a E-Bonding Runbook partner:

The partner ID is one of the most important data when exchanging information with partner systems. For that the partner ID is a mandatory value within the XML message header. With the partner ID E-Bonding Runbook can decide automatically:

• Whether events will be send to one or more partners.
• Whether messages of a partner system will be accepted.

Principle of PartnerGroups

In E-Bonding Runbook PartnerGroups are deciding whether a ticket event (or task etc.) will be sent to a partner and to which partner.
The configuration of PartnerGroups can be done via the E-Bonding Runbook Partner Console.
 PartnerGroups are related to a partner. For a partner, several PartnerGroups can be configured. The PartnerGroups are references to the ITSM support groups.
Important: the names (support group name) for support groups used in E-Bonding Runbook need to be unique. It is not possible to relate the same support group to different E-Bonding Runbook partners.
 An administrator can relate PartnerGroups to E-Bonding Runbook partners. Thereby the following rules come to effect: when an Incident Request is created in ITSM the E-Bonding Runbook Event Engine checks if the owner or assignee group corresponds a PartnerGroup. If not, this event is ignored by E-Bonding Runbook. If the group in the ticket is corresponding a PartnerGroup the respective partner will be identified and the event will be processed by E-Bonding Runbook.

Principle of the TicketStore

The E-Bonding Runbook TicketStore represents the "memory" of E-Bonding Runbook. Within the TicketStore all tickets are stored which have ever been processed by E-Bonding Runbook.
 There exists a dedicated TicketStore form for any E-Bonding Runbook module (e.g. Incident or Change).
 The TicketStore cannot be configured.
To understand the TicketStore is crucial to understand the functioning of E-Bonding Runbook. The remarks in chapter 3.3 for example may reach the conclusion that Tickets trigger events to an interface partner only as long as one of the PartnerGroups is stored as Owner or Assignee Group in the ticket. But this would avoid established principles like re-assignments or similar.
Here the TicketStore comes into play. Every ticket, as well in- as outbound will be stored at the initial processing within the TicketStore by E-Bonding Runbook. The TicketStore assures that an interface partner will receive ticket related updates and/or events like Tasks, Work Info etc. even if the ticket has been assigned to other groups. The TicketStore keeps up the relation of a ticket in ITSM to one (or more) partner system over the complete ticket lifecycle. The relation can be ended explicit from the partner with a special E-Bonding Runbook message.

Principle of PartnerMessages

Every E-Bonding Runbook module comes along with an amount of messages, which are used to realize the communication with an interface partner. Messages are used synonymous for interface operations. All messages are collected in the so-called Message Libraries.
The configuration of PartnerMessages can be done via the E-Bonding Runbook Partner Console.
 Administrators can activate or deactivate each available message for the current partner. These settings are checked at every transaction processed by E-Bonding Runbook. For in- and outbound only those messages/ events will be processed, which are activated for the partner.
Custom fields that clients may have created in the ITSM system can easily extend the E-Bonding Runbook message library.
 E-Bonding Runbook covers sending and receiving attachments in a unique and highly performing way. Therefore, the E-Bonding Runbook platform requires a dedicated file store, available on the BMC Atrium Orchestrator server platform. The file store can be shared with any partner systems that want to exchange attachments with the ITSM Suite.

Principle of Platform Synchronizing

For performance reasons, the configuration data of ITSM must be synchronized with the AO platform.
The synchronization of E-Bonding Runbook configurations can be started via the E-Bonding Runbook Partner Console. A red note provides information whether a partner configuration has already been synchronized with AO or not.
 In principle, every change of the E-Bonding Runbook partner configuration is causing a non-synchronous status. An administrator can make all upcoming modifications at once and start the synchronization via the respective button.
Note: A changed partner configuration does not become active before the synchronization is finished.

Principle of Connection (Inbound)

E-Bonding Runbook represents an interface middleware between a BMC Remedy ITSM Suite and any number of interface partner systems. There are two directions of communication:

• Inbound = ingoing messages from a partner to the ITSM system (via E-Bonding Runbook)
• Outbound = outgoing messages from ITSM to a partner (via E-Bonding Runbook)

Inbound messages contain metadata and transaction data. Optionally, a partner system specific enabler module can be used to translate the partner system messages to the E-Bonding Runbook standard message.
At first, both types of data are stored in the Transaction Database and the partner system is informed about this action (confirmation response). In the next step, the Transaction Engine verifies the inbound event against the E-Bonding Runbook rules and handles the correct processing of the event in the direction of the BMC Remedy ITSM Suite. After the event has been processes, the status is updated in the Transaction Database. This triggers the Transaction Engine. A partner acknowledgement is processed.
The picture gives an overview about the inbound communication principal established with E-Bonding Runbook:

Figure 3 E-Bonding Runbook Inbound Communication Principal
Connecting a partner is done in E-Bonding Runbook with a so-called "enabler". An "enabler" module can be understood as a translator. It transforms inbound messages into the E-Bonding Runbook standard format.
Inbound an "enabler" is optional. That means: if the partner system is able to do a mapping and to generate the inbound SOAP messages defined in E-Bonding Runbook, no "enabler" module is needed to receive inbound messages from a partner.
An optional inbound "enabler" is created as an additional E-Bonding Runbook Atrium Orchestrator Module.

Principle of Connection (Outbound)

E-Bonding Runbook represents an interface middleware between a BMC Remedy ITSM Suite and any number of interface partner systems. There are two directions of communication:

• Inbound = ingoing messages from a partner to the ITSM system (via E-Bonding Runbook)
• Outbound = outgoing messages from ITSM to a partner (via E-Bonding Runbook)

Outbound messages contain metadata and transaction data. Only metadata needs to be stored in the E-Bonding Runbook Transaction Database. In the next step, the Transaction Engine reads the defined ITSM object data and handles the correct processing of the event in the direction of partner systems. In front of a partner system, E-Bonding Runbook defines a partner specific "enabler" module. The module is responsible to transform the standard message to the partner system data format. A retry mechanism takes over if the partner system doesn't acknowledge the transaction within time.
The picture gives an overview about the outbound communication principal in E-Bonding Runbook:

Figure 4 E-Bonding Runbook Outbound Communication Principal
Connecting a partner is done in E-Bonding Runbook with a so-called "enabler". An "enabler" module can be understood as a translator. It transforms inbound messages into the E-Bonding Runbook standard format.
Outbound an "enabler" is mandatory. The reason is that every interface partner must be addressed different. But there are graduates of complexity of the needed outbound "enabler". There are three types:

• Simple: the outbound "enabler" sends the E-Bonding Runbook standard messages and the transformation must be done by the partner system.
• Normal: the outbound "enabler" transforms the E-Bonding Runbook standard messages into formats, which can be processed by the partner and sends them.
• Complex: the outbound "enabler" transforms the E-Bonding Runbook standard messages into formats, which can be processed by the partner and sends them. Additionally, the sequence logic must be aligned to the partner if the partner is not able to handle the send and acknowledge mechanisms from E-Bonding Runbook.

An outbound "enabler" is created as an additional E-Bonding Runbook Atrium Orchestrator Module.

Principle of "DACK" and "PACK"

Delivery Acknowledgement
DACK stands for Delivery Acknowledgement and means that a message has been received but not processed yet. E-Bonding Runbook sends a synchronous DACK response for every inbound message.
Processed Acknowledgement
PACK stands for Processed Acknowledgement and means that an inbound message has not only been received but also processed un-/ successfully. E-Bonding Runbook sends an asynchronous PACK response for every inbound message.

Principle of "Queuing" and "Chunking"

To provide a stable system also during peak hours, E-Bonding Runbook is queuing all in- and outbound messages in the E-Bonding Runbook Transaction Database.
The final processing is executed in chunks. E-Bonding Runbook ensures, that only a maximum of concurrent operations is running at a point of time. The maximum of concurrent operations is configurable on the E-Bonding Runbook platform. The chunk size can be adjusted to your interface environment to use the system at best capacity. The chunking can be configured in the E-Bonding Runbook Core Module.
 Due to stability and optimization improvements, E-Bonding Runbook limits the number of concurrent jobs and aligns it to the configured chunk size. This ensures, that the E-Bonding Runbook platform remains stable even in peak hours.

Principle of Attachments

Within E-Bonding Runbook the complete attachment handling is split from the process transaction data. In case of attachments, the inbound message only holds a file reference to a central file share.
In front of the interface communication the interface partner must upload all necessary files to the file share. This approach offers the possibility to use the best technology like FTP or SSH to transfer big amounts of data on the one hand side and reduce the system load on the E-Bonding Runbook system on the other hand.
The consequence is: when aligning a new interface E-Bonding Runbook owner and partner system owner must agree whether attachments shall be delivered or not. In case attachments will be sent both systems need access to a central file share. This file share must be configured with the same mount point for both sides to be able to exchange path references.
E-Bonding Runbook makes use of an attachment root path that can be configured per partner. This new feature allows E-Bonding Runbook customers to define separate attachment paths per interface partner and therefore simplifies the integration for partner systems.

Principle of Retries

E-Bonding Runbook uses retries to assure that outbound messages on the one hand reach the receiver as save as possible and on the other hand that undeliverable messages do not paralyze the system. The number of retries can be configured per partner in the E-Bonding Runbook Partner Console. Retries are used at the outbound communication. In addition, an offset needs to be defined per partner configuration. The offset is added to the platform-wide retry interval. This ensures, that the retry interval can be configured per partner separately.
 If a message has been sent to a partner, E-Bonding Runbook expects a synchronous response, which is DACK for E-Bonding Runbook. A connected partner system is obligated to send a PACK after successful processing a message. When either the DACK has not been successful or a PACK has not been received by E-Bonding Runbook for a certain time the message will be sent again to the partner. This is done with identical transaction and message IDs. The automatic sending is performed as many times as retries are configured.