How to connect OTRS with the OTRS CMDB

With the OTRS Business Solution™ 5s you have the possibility to connect OTRS with the internal CMDB e.g.: if you have a process in OTRS where something is ordered and should be transmitted to the OTRS CMDB afterward. The following article will explain how to configure this CMDBConnector to establish a connection between OTRS and the OTRS internal CMDB.

OTRS Requirements for this HowTo:

OTRS Framework

The following OTRS framework is required:

5.0.x

OTRS Packages

You need the following Freely selectable Features of the OTRS Business Solution™ 5s :

OTRSGenericInterfaceInvokerTicket

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

OTRSGenericInterfaceInvokerEventFilter

(Contains additional functionalities to add conditions to events of invokers.)

GeneralCatalog

(A reference table tool to add/update items)

ITSMCore

(Provides basic functionality for all other ITSM packages)

ITSMConfigurationManagement

(Implements all ITSM configuration management features)

OTRSDynamicFieldConfigItem

(Dynamic field backend for Config Items.)

Third Party Software

You need this third party software:

XML::Simple
XML::LibXML
XML::LibXSLT

DynamicFields

DynamicField “ConfigItem” of type „Configuration Item“
DynamicFields which are used in our Process
- e.g.:
  - hostname of type “Text”
  - agentinstallation of type “Dropdown”
    - Values:
      - Yes: Yes
      - No: No
  - ipaddress of type “Text”
  - location of type “Dropdown”
    - Values:
      - Amsterdam: Amsterdam
      - Dusseldorf: Dusseldorf
      - Frankfurt: Frankfurt
      - Hamburg: Hamburg
      - London: London
  - machinestyle of type “Dropdown”
    - Values:
      - physical: physical
      - virtual: virtual
  - product of type “Dropdown”
    - Values:
      - Debian:Debian
      - RedHat:RedHat
      - Ubuntu:Ubuntu
      - Windows: Windows
  - Comment of type “TextArea”
  - ePRO of type “Text”
  - systemfunction of “Dropdown”
    - Values:
      - DHCP Server:DHCP Server
      - DNS Server:DNS Server
      - Domain Controller:Domain Controller
      - Monitoring System:Monitoring System
      - Other:Other
      - SAP System:SAP System
      - SAP System::WareHousing:WareHousing

Configuring the Process “New Server Request”

Finally, we can start configuring the Process “New Server Request”.

In the Admin-Menu go to “Process-Management” and create a new process.

Once you created the process, you can start adding new activities, activity dialogs, transitions and transition actions. Because the scope of this blog article was originally intended to be limited to web services, I only show the basic configuration of the used activities and activity dialogs. In addition please don’t forget to also add “Transitions” and “Transition Actions”.

Create the first activity “New server request”:

Afterward, create a new activity dialog “New server request dialog” and add the following fields:

CustomerID
DynamicField_systemfunction
DynamicField_product
Article

Again we’ve to create a new activity and activity dialog:

Add the following fields to the second activity dialog:

DynamicField_hostname
CustomerID
DynamicField_ipaddress
DynamicField_location
DynamicField_machinestyle
DynamicField_agentinstallation
DynamicField_product
State

And the configuration of our last activity and activity dialog of our process:

Please add the following fields to the configuration of the new activity dialog:

DynamicField_agentinstallation
DynamicField_Comment
DynamicField_ePRO
State

As a result, your configured process should look the following:

Configuring the CMDBConnector in OTRS

CMDB Provider Operations

As soon as we’re done with the pre-requirements and the “New Server Request” process, we have to create a new web service within OTRS. Afterward, we’ll set up the needed requester invokers.

First of all, we have to define a name for the new web service e.g.: CMDBConnector:

Afterward, we have to create the operations, which we want to provide to other systems (and we want to use in our example).

We’ll add the following operations:

ConfigItemCreate: to be able to create new CIs in our CMDB
ConfigItemDelete: to be able to delete existing CIs from our CMDB
ConfigItemGet: to be able to retrieve the latest data of a CI
ConfigItemSearch: to be able to search for CIs
ConfigItemUpdate: to update CI data:

After creating the operations, we have to set up the network transport “HTTP::SOAP”

Please define a useful namespace (e.g.: http://www.otrs.com/CMDBConnector) and the maximum message length for incoming requests.

Configuring the Invoker

Now we add a new invoker for the invoker backend “Ticket::TicketCreate”.

In the following screen we have to specify a name for the new invoker e.g.: ConfigItemCreate, select your outgoing data and use XSLT as mapping module for your outgoing and incoming data.

Keep in mind: If you use HTTP::SOAP the name of the invoker has to match the name of the specific provider operation!

In addition, we have to define the DynamicField “ConfigItem” as “Remote TicketID dynamic field” to store the answer of the web service. As a result of this, the newly created ConfigItem is automatically linked to the ticket. Furthermore, you have to define a trigger:

Finally, we’re done with the basic invoker setup and can continue with the outgoing XSLT-Mapping:

We need some basic knowledge about the structure of the OTRS CMDB-API. Because there are some mandatory fields for every ConfigItem like:

Class (The ConfigItem class where the ConfigItem should be created)
Name (The name of the new ConfigItem)
DeplState (The Deployment state of the new ConfigItem)
InciState (The Incident state of the new ConfigItem)

In addition, you can go to our Github to get a working example.

Here’s my outgoing XSLT-Mapping:

Furthermore, we need to set up an incoming XSLT-mapping for the response data:

And we need to configure the network transport for the invoker. Please specify the same namespace as you did in the provider network transport configuration.