Architecture

The Clip integration platform is a Web-based Java application that runs on any of the supported Management Systems or a dedicated virtual or physical system. Clip does not require any software to be installed on the management systems that it interacts with.

Clip is configured to integrate a source with one or more destination targets of various types.

During operation, Clip maintains a local database to store the relationships between events and tickets along with all attributes received during create- and update operations of events and tickets for later reference and lookup via the Clip Web UI.

Event and Incident Processing

On event submission, the receiving "Integration Module" transforms the event into Clip's internal format before handing it over to Clip's Processing Engine which will then

• Assure that this event is currently not being processed in another thread or has already being processed ( this might happen when event managers like OMi perform retransmissions )
• determine the destination target(s) for this event based on the integrations configured
• invoke the destination target's Integration Module to create an incident according to it's configuration in the <createXXX/> section ( e.g. <createSN> for a ServiceNow target, <createARS/> for a BMC Remedy target ). Clip initiates the creation of an incident, and potentially performs additional API calls to determine (configurable) incident attributes like incident number, assigned user/group, priority etc. which are determined by the incident's system's workflow during incident creation. The newly created incident is passed back to Clip's processing engine.
• On successful incident creation, the processing engine can invoke event updates for the source event as configured in the <updateXXX/> section of the source target. This allows to display the incident's attributes like incident number, assigned user/group, priority etc. in the event's notes, annotations, forwarding tab, custom attributes etc.
• Clip's database is updated with all event and incident details for later review via the Clip Web UI and for lookup when event updates are received.

Once, an Incident has been created on behalf of an event, updates to the event can modify the related incident, and updates of an incident can modify the related event ( bidirectional synchronization).
For event and incident updates, the receiving "Integration Module" transforms the event update into Clip's internal format. Updates can be suppressed to avoid unnecessary overhead if they are not of interest ( e.g. increase of an event's duplicate counter ). Clip's Processing Engine will then

• Assure that the update is currently not being processed in another thread or has already being processed ( this might happen when event managers like OMi perform retransmissions )
• Assure that the update refers to an event / incident that has previously being synchronized with a peer target and has not been closed
• Optionally determine event attributes that have modified values compared to the last known values according to Clip's database
• Determine the peer target(s) that require an update
• invoke the peer target's Integration Module to update the peer event / incident according to it's configuration in the <updateXXX/> section ( e.g. <updateSN> for a ServiceNow target, <updateARS/> for a BMC Remedy target ).
• Clip's database is updated with all event and incident update details for later review via the Clip Web UI and for lookup when event updates are received.

If a synchronized event / incident is closed by the peer target, it remains in the Clip database for reviewing purposes for a configurable number of days before it is the removed by Clip's DB maintenance task.

CLIP variables and modifiers

Event and incident creation and modifications are performed by CLIP according to the specifications in the <create/> and </update> sections of the targets involved. CLIP variables can be used to fill and update field or incident values.
Each target has its own set of available variables:

• for OMi targets, please see Appendix B: OMi Event attributes. For NNMi targets, please see Appendix A: NNMi Event and filter attributes
• for ServiceNow targets, the variable names correspond to the field names of the ServiceNow "incidents" table
• for BMC Remedy targets, the variable names correspond with the field names of the form that is used for integration ( e.g. "HPD:IncidentInterface" ).

Additionally, CLIP has some "built-in" variables that can be used: