How to connect OTRS with the OTRS CMDB

Robert Ullrich28. Jul 2017 | ConsultingUse cases

Disclaimer:

The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

With the OTRS Business Solution6 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:

  • 6.0.x

OTRS Packages

You need the following Freely selectable Features of the OTRS Business Solution6 :

  • OTRSGenericInterfaceInvokerTicket
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)
  • 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”:

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

  • CustomerID
  • DynamicField_systemfunction
  • DynamicField_product
  • Article

Create new Activity Dialog New Server Request Dialog

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

Second Activity Dialog

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

Third activity dialog

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

Process Overview

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:

CMDBConnector Genera configuration

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:

  1. ConfigItemCreate: to be able to create new CIs in our CMDBCMDBConnector Operation ConfigItemCreate
  2. ConfigItemDelete: to be able to delete existing CIs from our CMDB
    CMDBConnector Operation ConfigItemDelete
  3. ConfigItemGet: to be able to retrieve the latest data of a CICMDBConnector Operation ConfigItemGet
  4. ConfigItemSearch: to be able to search for CIsCMDBConnector Operation ConfigItemSearch
  5. ConfigItemUpdate: to update CI data:CMDBConnector Operation ConfigItemUpdate

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

CMDBConnector HTTP::SOAP Configuration

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!

CMDBConnector Invoker Configuration Part 1

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:CMDBConnector Invoker Configuration 2

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:

CMDBConnector Outgoing Mapping

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

CMDBConnector Inbound Mapping

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.

CMDBConnector Invoker Transport Configuration

Testing the CMDBConnector

Finally, we can do some tests. Just create or take an already existing process ticket and trigger the “ConfigItemCreate” Invoker.

Probably you should see something similar in the OTRS Debugger:

CMDBConnector Debugger Output

In the CMDB, we’ll now see this new CI:

CMDBConnector ConfigItemZoom

Because of the DynamicFieldConfigItem “ConfigItem”, the ticket was automatically linked to the CI and vice versa.

Further thoughts

This is only an example of what’s possible. The next step could be a process, which is updating an already existing CI. ;-)

More information about the OTRS APIs

OTRS Framework: http://doc.otrs.com/doc/api/otrs/stable/Perl/index.html (search for Kernel::GenericInterface::Operation::Ticket

Github: https://github.com/OTRS/otrs/tree/master/development/webservices (for more example scripts)

ITSM Github: https://github.com/OTRS/ITSMConfigurationManagement/tree/master/development/webservices (for more example scripts)

 

Exported Process and Webservice Configuration

In addition, I added the configuration of the Process and the CMDBConnector.

#4
Jens Bothe at 19.11.2018, 20:45

Dear Florian, this post describes a webservice which is currently not part of the process. Also the invoker modules are needed. In OTRS 7 the process can run webservices as a service task. Please contact our support team if you need some more help

#3
Florian Fischer at 01.11.2018, 16:13

Hallo Herr Ullrich, an welcher Stelle muss der folgende Schritt eingearbeitet werden? Finally, we can do some tests. Just create or take an already existing process ticket and trigger the “ConfigItemCreate” Invoker. Sollte "ConfigItemCreate" in der "Übergangs-Aktionsmodul" Auswahl zu finden sein? Die vorherigen Schritte wurden soweit erledigt - leider fehlt die Auswahl aus dem Prozess heraus das ConfigItemCreate aufzurufen. Mit freundlichen Grüßen Florian Fischer

#2
Robert Ullrich at 25.10.2017, 09:22

Hallo Herr Schwarz, bitte wenden Sie sich in solchen Fällen an unser Sales-Team (sales@otrs.com) Mit freundlichen Grüßen Robert Ullrich

#1
Alexander Schwarz at 23.10.2017, 14:19

Hallo Herr Ullrich, wir haben einige Fragen, wie wir OTRS an unser CRM anbinden können, um Daten aus dem CRM persistent zum OTRS Ticket in der OTRS Datenbank zu speichern. Können wir Sie hierfür kontaktieren? Danke Alexander Schwarz

Your email address will not be published. Required fields are marked *