How to connect OTRS with the OTRS CMDB
Robert Ullrich28. Jul 2017 | ConsultingUse cases
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 Solution™ 6 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:
The following OTRS framework is required:
You need the following Freely selectable Features of the OTRS Business Solution™ 6 :
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)
(A reference table tool to add/update items)
(Provides basic functionality for all other ITSM packages)
(Implements all ITSM configuration management features)
(Dynamic field backend for Config Items.)
Third Party Software
You need this third party software:
- DynamicField “ConfigItem” of type „Configuration Item“
- DynamicFields which are used in our Process
- hostname of type “Text”
- agentinstallation of type “Dropdown”
- Yes: Yes
- No: No
- ipaddress of type “Text”
- location of type “Dropdown”
- Amsterdam: Amsterdam
- Dusseldorf: Dusseldorf
- Frankfurt: Frankfurt
- Hamburg: Hamburg
- London: London
- machinestyle of type “Dropdown”
- physical: physical
- virtual: virtual
- product of type “Dropdown”
- Windows: Windows
- Comment of type “TextArea”
- ePRO of type “Text”
- systemfunction of “Dropdown”
- DHCP Server:DHCP Server
- DNS Server:DNS Server
- Domain Controller:Domain Controller
- Monitoring System:Monitoring System
- 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”:
Again we’ve to create a new activity and activity dialog:
Add the following fields to the 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:
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.
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:
In the CMDB, we’ll now see this new CI:
Because of the DynamicFieldConfigItem “ConfigItem”, the ticket was automatically linked to the CI and vice versa.
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)