On The Road Services

Stories of the OTRS Consultant Road Warriors

Dateline: Washington DC July 2010

Rob Donath/Francisco “Paco” Cruz

Project Scope: 2 day deployment update and training on OTRS for a company that provides support services and applications primarily to the US Senate and Congressional Members and their staffs.

This consultation was a follow on to a week-long engagement that Paco conducted one month earlier with several of the principal stake holders of the OTRS system there.

Those of you in the business know that during most consulting engagements something unexpected happens to make the trip interesting (or at least challenging) and of course this time was no exception.

It was a typical July in DC, hot (90+F/30+C) and very humid due to thunderstorms in the area. With the Worldwide Microsoft Developers conference in town, we had to stay at a hotel a little further than usual from the client’s offices. Fortunately the DC metro system was close by and after a trip of 15 minutes that cost $2.80, we had just a short walk to their offices.

On the first day, Paco ran several training sessions and went over the various queues and services structures that were deployed in the early visit with key members of the various teams. As always this lead to numerous di

scussions about the queues and ticket routing. This open dialog provided information that Paco used to fine-tune the queues later that day for better internal workflow use.

While Paco was busy working on that, I set about modifying the Customer and Agent web front end to fit their corporate web site look and feel as well as getting an idea of their particular environment configuration.

Following a later evening at the client’s office than we had originally planned and a short sleep, we were hard at it the following morning. Paco made some additional role-based security changes to the queues and then continued on with the training. That day’s training sessions included the rest of the internal agents located in DC as well as providing training to group based in Los Angeles, CA using an online meeting tool that the client company sells and supports.

Of course I kept busy by making some customizations in the Company and Customer database structures, mapping the changes to the user front end including some pick lists for products and support services levels. With these changes in place I began the process of importing in the client’s customer data. This data was extracted from their old CRM tool into a series of nearly 10 spreadsheet forms each of which was slightly different than the other. Oh, that was unexpected! Therefore I had to build a new import file for each sheet. This takes a while since the field matches are different each time.

Oh well, not enough hours in a couple of days to do the work and spend any time to see the US Capitol. Perhaps on my next visit to a client here I’ll try to take an extra day to visit the museums or memorials or some of the great restaurants I have heard about. Unless of course the unexpected happens again!

State machines for tickets via ACL

Some of you may already know OTRS::ITSM 2.0 and the brand-new Change Management which contains 2 state machines – one for the change itself and a second for the work orders.

Change state machine

Well, a customer knew them and asked to implement something similar for his ticket handling.

Idea

The OTRS contains a mechanism called Access Control Lists (ACL; see [ACL] for detailed discussion in the OTRS Admin Manual) which are in fact rule sets matching on certain ticket properties and allow or prevent other properties/actions/states.

An example says more than 100 words – ACL which only allows to move tickets with ticket priority 5 into a queue:

    # ticket acl
    $Self->{TicketAcl}->{'ACL-Name-2'} = {
        # match properties
        Properties => {
            # current ticket match properties
            Ticket => {
                Queue => ['Raw'],
                Priority => ['5 very high'],
            }
        },
        # return possible options (white list)
        Possible => {
            # possible ticket options (white list)
            Ticket => {
                Queue => ['Alert'],
            },
        },
    };

Theory

Together with the customer we defined 3 state machines and their transitions for Incident-, Problem- and RfC-tickets.

Some facts about the setup:

• no Agent has the permission to “close” a ticket
• the status “solved” is a of the type “pending auto”
• after a “solved” ticket reached its pending time, it will be set to “closed” automatically
• customers are not allowed to reopen a ticket (thus the grace period for ticket closing)

Some warning words about ACLs in the OTRS.
ACL don’t sum up! There is only 1 ACL defining the ticket/action/possible properties!

state machine - Incident

state machine - Problem

state machine - RfC

Practice

Defining the ACL follows a simple principle – first forbid anything, then define possible transitions.

Here’s the start of the Incident state machine:

12     ##########################################################################
13     # Statemachine - Incident
14     # by default - forbid everything
15
16     $Self->{TicketAcl}->{'ACL-ZZ-Incident-00'} = {
17         Properties => {
18             Ticket => {
19                 Type    => [ '[RegExp]^Incident', ],
20             },
21         },
22         Possible => { Ticket => { State => [ ], }, },
23     };
24
25     # new -> open
26     $Self->{TicketAcl}->{'ACL-ZZ-Incident-10'} = {
27         Properties => {
28             Ticket => {
29                 Type    => [ '[RegExp]^Incident', ],
30                 State   => [ 'new', ],
31             },
32         },
33         Possible => {
34             Ticket => {
35                 State => [ 'open', ],
36             },
37         },
38     };

So far, ACLs cannot be created using the SysConfig interface but must be entered manually into Kernel/Config.pm. Depending on the amount of ACL rulesets the Config.pm will become bloated and hard to read so I created a dedicated ACL.pm configuration file in Kernel/Config/Files. There is no special notation, just add the ACLs as needed and a single 1; at the end of the file.

Keep in mind

• ACL have no effect for the user with the ID 1 (normally root@localhost)
  use a real user account for testing
• turn on debugging in Kernel/System/Ticket.pm while testing
  111     # 0=off; 1=on;
  112     #$Self->{Debug} = $Param{Debug} || 0;
  113     $Self->{Debug} = 9;
• run grep in a separate shell to see which ACL is really used
  tail -f var/log/otrs.log | grep –line-buffered “Workflow .* used”

Download

The complete ACL file can be downloaded here → TicketStateMachine-ACL.pm

The whole package including OmniGraffle, PNG and ACL can be downloaded here → state machines in ACL

Further reading

[ACL]

http://doc.otrs.org/2.4/en/html/c2177.html

PS

Please don’t discuss the state machines – they aren’t the real ones the customer has in use. Please adopt them to your needs.

Some days ago I found a quite interesting article on Change Management. But there is a better way than to work with Templates for Word or Excel is to use a Change Management System like the Change Management Module of OTRS::ITSM.

Right now our Development Team works on the interface of OTRS::ITSM to modernize it also, like the base Framework to a new CSS based  frontend.

Situation

Imagine a nicely built CMDB with a lot of interconnected items. You can follow the links manually in your browser but sometimes you get a better hold on information and structures by visualizing them.

The OTRS CMS is such a case: many classes, items and connections between them. I hacked a small bash script which reads the database and generates a file suitable as input for the graphviz project’s [graphviz] dot program.

Example output

Example output

How to use

Please follow these simple (ymmv) steps

1. grab a *ix of choice
2. install graphviz
3. download the zip archive containing
   - prepare_dot.sh (the mentioned bash-script)
   - test.dot (some example data)
   - test.pdf (example result as PDF)
   - test.png (example result as PNG)
4. modify the script at the beginning
   Please insert the correct credentials to have read permissions on the OTRS database
5. run the script and save the output to e.g. test.dot

   sh prepare_dot.sh > test.dot

6. run dot to generate the diagram

   dot -Tpdf test.dot -o test.pdf

Be warned

The script relies on some shell functionality and built-in functions and was tested with a current Bash on Debian stable. It may or may not run with other shells. Please adopt the script to your needs.

The script uses mysql to gather the nessesary data from the DB. It may be possible to use a PostgreSQL or other command line client – please adjust to your needs too.

The output may be strange and not satisfying for your data model – graphviz was developed for interconnected data. If your CMDB is just plain storage, then a visualization doesn’t make sense.

Further Reading

[graphviz] – http://www.graphviz.org/

Download

→ visualCMDB

Have ((fun))

Sometimes the basic authentication provided by OTRS via database or LDAP is not enough for securing the access to an application. RFC 4226 describes the generation and usage of one time passwords and two way authentication.

To make OTRS using OTP for the login of the agents we need to install mod-authn-otp as apache auth module. After downloading and compiling the module we need to activate it in the apache configuration.

Now we’ll start with the configuration of OTRS to use the OTP mechanism. First we need to tell OTRS to use the authenitfication provided by the webserver.

In Config.pm these lines need to be added:

# Basic Auth stuff for OTP
    $Self->{AuthModule} = 'Kernel::System::Auth::HTTPBasicAuth';

No, apache needs the information that for the otrs directory the auth module should be used. So we need to adjust the settings in the otrs.conf webserver config file:

    # set mod_perl2 options
    <Location /otrs>
        ErrorDocument 403 /otrs/index.pl
        SetHandler  perl-script
        PerlResponseHandler ModPerl::Registry
        Options +ExecCGI
        PerlOptions +ParseHeaders
        PerlOptions +SetupEnv
        Order allow,deny
        Allow from all
        AuthType                basic
        AuthName                "Protected OTRS Area"
        AuthBasicProvider       OTP
        Require                 valid-user
        OTPAuthUsersFile        "/etc/otp-users/otp-users"
        OTPAuthMaxLinger        3600
    </Location>

You’ll find some documentation on the used parameters on the mod_authn-otp config page.

Now create the /etc/otp-users/otp-users file with the usernames, the PIN and the key:

HOTP    jb        1234   e942415c9e24768bb193f572fb272a3198def1a3

Don’t forget to change owner to the webserver user and make the directory writable for the webserver. (Also have a look at http://code.google.com/p/mod-authn-otp/wiki/UsersFile)

You also should set the Lifetime of the OTRS Session to the same value as OTPAuthMaxLinger

Now you’ll need some software for your mobile phone to generate the OTP. I choosed OATH Token for the iPhone, but you’ll find some more here: http://code.google.com/p/mod-authn-otp/wiki/Tokens

After configuring the app, you’ll be able to generate your OTP if needed:

OTRS is well known for its powerful E-Mail filters. Also OTRS is used a lot in abuse departments, NOCs and CERTs.

Some years ago a messages format, called Abuse Response Format – ARF was designed to help to automate data exchange on spams, fraud or other abuse of E-Mails. AOL is using this format for their Postmaster Feedback Loop. Reviewing the setup of one of an OTRS used for security and abuse handling I had the idea to create a postmaster filter for writing some of the data into Ticket Free Fields.

Doing some research the CPAN class Email::ARF::Report attracted my attention. So I decided to build a PostmasterFilter Module using it.

First I created a testscript for checking out all of the possibilities:

#!/usr/bin/perl -w
use Email::ARF::Report;
use File::Slurp qw (slurp);
my $message = slurp ('sample2.txt');
my $report = Email::ARF::Report->new($message);
print "Report Fields\n";
print "=============\n";
foreach my $field (qw(Feedback-Type Source-IP)) {
 print ucfirst $field . ': '
 . $report->field($field) . "\n";
}
print "\n\n";
print "Original Headers\n";
print "================\n";
# Get some Original Headers
foreach my $header (qw(to date subject message-id from X-AOL-IP)) {
 print ucfirst $header . ': '
 . $report->original_email->header($header) . "\n";
}

So I was able to do some test on some AOL Feedback Reports I had in my OTRS Ticket Database.

The Postmaster Filter Module will use 6 Ticket Free Field for storing:

• Report Feedback Type
• Report Source IP
• Original To Address
• Original From Address
• Original Subject
• Original Message ID

Also the subject of the mail will be rewritten to include the Feedback Type and the Original Sender.

Some values can be set via Sysconfig, like the From Address Regex already known from the SystemMonitoring Module:

The Ticket of the ARF Formatted Message will look like this:

The Proof of Concept OPM can be downloaded here

Dear Readers,

Software Advice recently posted their favorites for customer service on the go. Software Advice stated: “A recent report from Call Center Times showed that 78 percent of consumers use mobile apps for customer service.”….”With this app, businesses can increase the productivity of their on-site support staff, as well as reduce support errors at the customer site.”

The OTRS App can be found in iTunes, and is free of charge. You will need the OTRS Extension iPhoneHandle, available via your OTRS’ Package Manager. After installation, just connect your iPhone to the JSON script provided by the package, login, and start using the application.

You can even connect to multiple OTRSs with the same application.

So, thanks to the people at Software Advice for rating the iPhone App so highly, and valuing the added productivity when using this in combination with the world leader in open source service desk solutions, OTRS.

In OTRS 3.1 the Generic Interface was introduced to ease the way of ticket creation via webservices. The interface has a wide variety of possibilities for developers like acting as a invoker, a scheduler, and a very modular setup which allows easy development of new connectors to OTRS backend functionality.

There are two ready to run connectors available for free, a generic ticket connector and a FAQ connector. This post describes how to install the generic ticket connector and use it with a remote scripts.

First you need to download the description file for the connector which can be found here. Now open the admin tab and navigate to the menu item “Web Services”. You can now upload the definition via the “Add Web Service” Button

Now Import the webservice via the offered button

Now you should have a new Webservice in your list

Now, lets try to generate a ticket via webservice. I created a script on the disk of the server (you can download the skeleton here)

The basic lines are:

Please note that you will need a valid OTRS user with permissions on the queue, a valid customer and valid states, priorities and ticket types (if switched on).

Running the script should give you a result like

As this script needs to be adjusted everytime you need to create a different text or different customer Mike wrote a standalone script which connects to the generic interface of an OTRS installation.

To install you need to download the tar.gz file on the machine which should create tickets, install the PERL libraries Getopt::Long, Pod::Usage and SOAP::Lite and unpack the directory. You can now build the script with the following commands:

Running the script via command line now will open a ticket

This script can also be used with the wrapper of reoccuring task described in the post “Proof of concept: Creating reoccuring tickets for task”

OTRS is used in security departments and companies for long time due to the well documented code and some background in the CERT area.

In one of my recent projects the team wanted to simplify some of their processes additional to the main goals of the implemenation project. We decided to start with the authorization process for taking photos inside their business locations. Until now they had a paper based permission process.

So created a small process within OTRS. Now the customer can request a permission in the customer webinterface or by sending a mail to a special email address.

For starting a process from an email you need to create a postmaster filter which points to the process ID and the activity id of the first activity in this process.

The ticket now shows up the in the Dashboard Calendar

and the agent can go through the authorization

This will trigger an automated email via notification event to the customer

In the event based notification we can use the OTRS Notification Tags to access the values of the used dynamic fields.

After the photos are taken the user needs to send them to the ticket so an agent can approve or deny the publishing of the photo.

For building this process we need:

• several dynamic fields as shown below
• an event based notification on authorized request
• an event based notification on non authorized request
• an event based notification on approval or denying the publishing request
• a process
• a post master filter as shown on top
• some ACL rules to make it smooth

Dynamic Fields

Process Config

The export can be found here (remove the .txt if needed): Export_ProcessEntityID_P5.yml

ACL

You should also add an ACL to remove closed states on sending replies or forwarding.

Small process designs like this one can really increase the acceptance of your system in simple way. Just start to imagine which processes might fit for you!

Giovanni, who uses OTRS in his security team wrote a nice article in his blog:

Thanks for the great work Giovanni :-)

With the new OTRS Business Solution™ 5s you have the possibility to create and update issues in JIRA using the JIRAConnector. The following article will explain how to configure this JIRAConnector.

Requirements for the JIRAConnector

You are able to connect to JIRA, if you meet the prerequisites which are listed below:

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.)

Third Party Software

You need this third party software:

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

DynamicFields

• DynamicField „JiraIssueID“ of type „TEXT“

When you’re done with the pre-requirements, you have to create a new web service within OTRS to set up the needed requester invokers:

Configuration of the JIRAConnector

Please select „XSLT“ for the outgoing and incoming mapping in the configuration of the invoker „IssueCreate“,

Afterwards you have to define a valid XML structure to map the OTRS structure to a structure which can be understand by JIRA.

IMPORTANT: You need some basic XML and XPATH knowledge

I use the following outgoing mapping:

Also the response format of JIRA is not in an OTRS structure. You have to specify an incoming mapping too:

Now we need to define a trigger which will execute the request to JIRA e.g.: TicketLockUpdate for test purposes.

Click on „save and finish“ when you finished the configuration

We will do the same for the invoker “IssueUpdate”. Click on it or create it, if you haven’t done until now and use the following XSLT Mapping for outgoing request data:

As you can see i will only update the Summary in JIRA and i’m using the latest OTRS Ticket Title.

When you’re satisfied with your mapping, please click on „Save and finish“.

Go to the „Network Transport“ configuration of the JIRAConnector and change the following settings.

You need at least the following information:

• Host:
  • http://<YOUR_FQDN/rest/api/2
• Controller Mapping for ‚IssueCreate’:
  • /issue (Request Command: POST)
• Controller Mapping for ‚IssueUpdate’:
  • /issue/:JIRAIssueID (Request Command: PUT)
• Username:
  • A valid user for the JIRAConnector
• Password
  • A valid password for the user

Before you can test the new web service, you have to configure a DynamicField in the SysConfig (e.g.: JIRAIssueID) which is used to store the response of JIRA.

See attached image:

 Testing the JIRAConnector

Now we can use a ticket and lock it.

The request to JIRA will look like the following, if the mapping was applied to the outgoing request. You can find this information, if you go to the Debugger of the JIRAConnector.

The request to JIRA was a success, if you see the following answer:

OTRS can only store one response value of the response, you created the incoming mapping for the response data. The result of this mapping is:

Congratulations! You successfully connected OTRS with JIRA.

More information

You can also use other resources which are provided by JIRA. Please go to the following website, if you need information: https://docs.atlassian.com/jira/REST/cloud/

The post How to connect OTRS with JIRA appeared first on The OTRS Blog.

OTRS has a deep background on handling emails. One of the most powerful tools integrated is the ability to analyze incoming emails and even fetch data to different fields of a ticket. The most known kind of filters are the “Match Filters” which can be configured through the admin panel.

These filters use Kernel::System::EmailParser to split the content of an incomming email into different parts, like the different headers and the body. Due to this splitting it is not possible to analyze parts of an email which are not stored in the headers or the body.

Solving the issue

Deeply hidden in the Sysconfig is the possible to create postmaster filters which use the raw or plaintext content. This filter can be found in the PostMaster::PreFilterModule###4-CMD section of the Ticket -> Core::PostMaster group. This filter matches if the command will create an output on STDOUT.

Let’s say I would like to set a Dynamic Field if the mail was signed by PGP/MIME. As the PGP signature is an additional MIME part within the mail this not possible with the “normal” filters.

Lets have a look on the raw email:

Subject: Some Test Mail
Message-ID: <dd5236ce@otrs.com>
Date: Wed, 21 Dec 2016 21:08:59 +0100
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="cIkbOuFPs5f5mcbVqptdx5bwHgr8Ca53h"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cIkbOuFPs5f5mcbVqptdx5bwHgr8Ca53h
Content-Type: multipart/mixed; boundary="QjgNWgJvSE4d1wRcsuMPf9MFTaAMnLIFb";
 protected-headers="v1"
From: "Jens O. Bothe" <jens.bothe@otrs.com>
To: 'Jens Bothe' <jens.bothe@otrs.com>
Message-ID: <dd5236ce0f@otrs.com>
Subject: Some Test Mail

--QjgNWgJvSE4d1wRcsuMPf9MFTaAMnLIFb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hey,
this is a test

((enjoy))
Jens

--QjgNWgJvSE4d1wRcsuMPf9MFTaAMnLIFb--

--cIkbOuFPs5f5mcbVqptdx5bwHgr8Ca53h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlha4V8ACgkQZ4I/4k742SwdBgCgnNb6NbqLNkNw75eTjeVHhVtY
QLcAoMOW/++VqAOPSwlLRd8delBY5qym
=LpXU
-----END PGP SIGNATURE-----

--cIkbOuFPs5f5mcbVqptdx5bwHgr8Ca53h--

I want to filter on the part:

Content-Type: application/pgp-signature; name="signature.asc"

So I have to add as CMD: grep “Content-Type: application/pgp-signature”

The full part in the Sysconfig

For my latest customer I created some additional filters. The XML file can be found here: PostMasterFilter.xml

The post Using PostMaster filters on raw emails appeared first on The OTRS Blog.

State machines for tickets via ACL

Some of you may already know OTRS::ITSM 2.0 and the brand-new Change Management which contains 2 state machines – one for the change itself and a second for the work orders.

Change state machine

Well, a customer knew them and asked to implement something similar for his ticket handling.

Idea

The OTRS contains a mechanism called Access Control Lists (ACL; see [ACL] for detailed discussion in the OTRS Admin Manual) which are in fact rule sets matching on certain ticket properties and allow or prevent other properties/actions/states.

An example says more than 100 words – ACL which only allows to move tickets with ticket priority 5 into a queue:

    # ticket acl
    $Self->{TicketAcl}->{'ACL-Name-2'} = {
        # match properties
        Properties => {
            # current ticket match properties
            Ticket => {
                Queue => ['Raw'],
                Priority => ['5 very high'],
            }
        },
        # return possible options (white list)
        Possible => {
            # possible ticket options (white list)
            Ticket => {
                Queue => ['Alert'],
            },
        },
    };

Theory

Together with the customer we defined 3 state machines and their transitions for Incident-, Problem- and RfC-tickets.

Some facts about the setup:

• no Agent has the permission to “close” a ticket
• the status “solved” is a of the type “pending auto”
• after a “solved” ticket reached its pending time, it will be set to “closed” automatically
• customers are not allowed to reopen a ticket (thus the grace period for ticket closing)

Some warning words about ACLs in the OTRS.
ACL don’t sum up! There is only 1 ACL defining the ticket/action/possible properties!

state machine - Incident

state machine - Problem

state machine - RfC

Practice

Defining the ACL follows a simple principle – first forbid anything, then define possible transitions.

Here’s the start of the Incident state machine:

12     ##########################################################################
13     # Statemachine - Incident
14     # by default - forbid everything
15
16     $Self->{TicketAcl}->{'ACL-ZZ-Incident-00'} = {
17         Properties => {
18             Ticket => {
19                 Type    => [ '[RegExp]^Incident', ],
20             },
21         },
22         Possible => { Ticket => { State => [ ], }, },
23     };
24
25     # new -> open
26     $Self->{TicketAcl}->{'ACL-ZZ-Incident-10'} = {
27         Properties => {
28             Ticket => {
29                 Type    => [ '[RegExp]^Incident', ],
30                 State   => [ 'new', ],
31             },
32         },
33         Possible => {
34             Ticket => {
35                 State => [ 'open', ],
36             },
37         },
38     };

So far, ACLs cannot be created using the SysConfig interface but must be entered manually into Kernel/Config.pm. Depending on the amount of ACL rulesets the Config.pm will become bloated and hard to read so I created a dedicated ACL.pm configuration file in Kernel/Config/Files. There is no special notation, just add the ACLs as needed and a single 1; at the end of the file.

Keep in mind

• ACL have no effect for the user with the ID 1 (normally root@localhost)
  use a real user account for testing
• turn on debugging in Kernel/System/Ticket.pm while testing
  111     # 0=off; 1=on;
  112     #$Self->{Debug} = $Param{Debug} || 0;
  113     $Self->{Debug} = 9;
• run grep in a separate shell to see which ACL is really used
  tail -f var/log/otrs.log | grep –line-buffered “Workflow .* used”

Download

The complete ACL file can be downloaded here → TicketStateMachine-ACL.pm

The whole package including OmniGraffle, PNG and ACL can be downloaded here → state machines in ACL

Further reading

[ACL]

http://doc.otrs.org/2.4/en/html/c2177.html

PS

Please don’t discuss the state machines – they aren’t the real ones the customer has in use. Please adopt them to your needs.

The post State machines for tickets via ACL appeared first on The OTRS Blog.

Situation

Imagine a nicely built CMDB with a lot of interconnected items. You can follow the links manually in your browser but sometimes you get a better hold on information and structures by visualizing them.

The OTRS CMS is such a case: many classes, items and connections between them. I hacked a small bash script which reads the database and generates a file suitable as input for the graphviz project’s [graphviz] dot program.

Example output

Example output

How to use

Please follow these simple (ymmv) steps

1. grab a *ix of choice
2. install graphviz
3. download the zip archive containing
   – prepare_dot.sh (the mentioned bash-script)
   – test.dot (some example data)
   – test.pdf (example result as PDF)
   – test.png (example result as PNG)
4. modify the script at the beginning
   Please insert the correct credentials to have read permissions on the OTRS database
5. run the script and save the output to e.g. test.dot

   sh prepare_dot.sh > test.dot

6. run dot to generate the diagram

   dot -Tpdf test.dot -o test.pdf

Be warned

The script relies on some shell functionality and built-in functions and was tested with a current Bash on Debian stable. It may or may not run with other shells. Please adopt the script to your needs.

The script uses mysql to gather the nessesary data from the DB. It may be possible to use a PostgreSQL or other command line client – please adjust to your needs too.

The output may be strange and not satisfying for your data model – graphviz was developed for interconnected data. If your CMDB is just plain storage, then a visualization doesn’t make sense.

Further Reading

[graphviz] – http://www.graphviz.org/

Download

→ visualCMDB

Have ((fun))

The post Proof of concept – visualizing the CMDB appeared first on The OTRS Blog.

One of the features of the OTRS 5s Security Toolbox is the information floater which allows to search for patterns in an article of a ticket. The feature was designed to enrich the content of a ticket without adding static content to it. Main usage is to give security teams valuable information at a glance without the need to lookup the information in a seperate browser tab.

Out of the box the possibility to search for CVE numbers is available via the Sysconfig settings in Ticket->Ticket::Frontend::ZoomCollectMetaFilters###CVE-Google and Ticket->Ticket::Frontend::ZoomCollectMetaFilters###CVE-Mitre. An additional usecase I had to solve lately was to check weather IP addresses were listed on realtime blackhole lists (RBL).

Highlighting IP addresses in the TicketZoom

So first I had to add an additional ZoomCollectMetaFilter which would match on IP addresses. One possible way is to extend the XML which is rendered by the Sysconfig as already described in several posts (e.g. even more RSS feeds in SysConfig). This time I directly created a perl config file “Kernel/Config/Files/ZZZIPCheck.pm” which contains the needed configuration:

$Self->{'Ticket::Frontend::ZoomCollectMetaFilters'}->{'IP-Blacklist'} =  {
  'Meta' => {
    'Name' => 'IP-Blacklist',
    'Target' => '_blank',
    'URL' => 'dnsrb.pl?ip=<MATCH1>',
    'URLPreview' => 'dnsrbl.pl?ip=<MATCH1>',
  },
  'RegExp' => [
    '(\\d{1,3}\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3}))'
  ]
};

If an IP address is found in an article the references will be displayed in the ticket zoom:

The Perl script

Next step is to create a perl cgi script in the bin/cgi-bin folder of the OTRS installation named dnsrbl.pl:

#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard);
use Net::RBLClient;
my $bl = ['ix.dnsbl.manitu.net','zen.spamhaus.org','b.barracudacentral.org','all.s5h.net','dnsbl-1.uceprotect.net','virbl.dnsbl.bit.nl','proxies.blackhole
s.easynet.nl','cbl.abuseat.org','blackholes.easynet.nl','relays.bl.kundenserver.de','agobot.bl.kundenserver.de'];
my $rbl = Net::RBLClient->new(
    lists => $bl,
    max_time => 5,
    timeout => 1,
    query_txt => 1,
    max_hits => 10,
    server => '8.8.8.8',
);
my $ip = param('ip');
print header(-type  =>  'text/html',
        'X-FRAME-OPTIONS' => 'SAMEORIGIN');
print start_html(-title  =>'IP Blacklist Check',
        -style=>{'src'=>'//cdn.jsdelivr.net/bootstrap/3.3.7/css/bootstrap.min.css'});
print '<div class="container">';
print '<div class="well">';
print h1("Checked IP: $ip");
print '</div>';
my $result = $rbl->lookup($ip);
my @listed_by = $rbl->listed_by;
my @listed_hash = $rbl->listed_hash;
my @listed_txt = $rbl->txt_hash;
 foreach my $list (keys @listed_by){
        print '<div class="alert alert-danger" role="alert">';
        print '<h4>';
        print b($listed_by[$list],": ");
        print p($listed_hash[$list]," ");
        print i($listed_txt[$list]," ");
        print '</h4>';
        print '</div>';
     }
if (! @listed_by) {
        print '<div class="alert alert-success" role="alert">';
        print '<h3>';
        print 'IP not found on blacklist';
        print '</h3>';
        print '</div>';
}
print '</div>';
print end_html;

As the script uses the Net::RBLClient class it has to be installed first. I used CPAN:

root@otrs:/opt# cpan
cpan[1]> install Net::RBLClient

Floater Output

The floater now will lookup the ip address in the configured RBL and render the page

Or if no match is found

I really would like to see your usecases and ideas to use the Information Floater of the OTRS 5s so please leave a comment.

The post Checking IP reputation via Information Floater appeared first on The OTRS Blog.

With the OTRS Business Solution™ 5s you have the possibility to create, acknowledge and resolve incidents in PagerDuty. The following article will explain how to configure the PagerDutyConnector to establish a connection between OTRS and PagerDuty.

To complete this Howto you need a PagerDuty account. Furthermore you need to configure a new service with the Integration Type “Use our API directly”. After that you’re ready to create Incidents via webservice in Pagerduty. ;-)

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.)

Third Party Software

You need this third party software:

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

DynamicFields

• DynamicField „PagerdutyID“ of type „TEXT“

Configuring the “PagerDutyConnector”

When you’re done with the pre-requirements, you have to create a new web service within OTRS. And you need to set up the needed requester invokers.

The name of the new webservice could be “PagerDutyConnector”:

General settings of the PagerdutyConnector

Configuring the Invoker “Create_Incident”

So we’re ready to start configuring our Invokers. The first Invoker is “Create_Incident”.  Select all the needed data for your outgoing requests and use “XSLT” as a mapping for your outgoing data.

If you need a working XSLT-mapping, you can use the attached one. The only thing you have to add is your personal “routing_key”.

You also need a XSLT-mapping for the incoming response data, because we need to store the “dedup_key”. Use my mapping, if you need a working example.

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the first Invoker.

Configuring the Invoker “Acknowledge_Incident”

The next invoker is “Acknowledge_Incident”.  Select all the needed data for your outgoing requests and also use “XSLT” as a mapping for your outgoing data.

If you need a working XSLT-mapping, you can use the attached mapping. As before you only need your personal “routing_key”.

You don’t need a mapping for the incoming data. PagerDuty only responds with a status, a message and the dedup_key.

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the second Invoker.

Configuring the Invoker “Resolve_Incident”

The last invoker is “Resolve_Incident”.  Select all the needed data for your outgoing requests and also use “XSLT” as a mapping for your outgoing data.

If you need a working XSLT-mapping, you can use the attached mapping. As before you only need your personal “routing_key”.

As before you don’t need a mapping for the incoming data. PagerDuty only responds with the status, a message and the dedup_key.

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the third & last Invoker.

Configuring the “Network Transport”

Furthermore we need to configure the network transport. But it’s quite easy as you can see:

Afterwards just click on “Save and finish”.

Testing the “PagerDutyConnector”

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

As result you should see something similiar in the OTRS Debugger:

In PagerDuty you’ll now see this Incident:

If we now trigger the Invoker “Acknowledge_Incident” we should receive a status “success”:

As a result the status changed from “Triggered” to “Acknowledged” in PagerDuty:

And at last the Invoker “Resolve_Incident”:

Finally the incident is also “resolved” in PagerDuty:

More information

You can also use other resources which are provided by PagerDuty.

Please go to the following website, if you need more information: https://v2.developer.pagerduty.com/docs/rest-api

The post How to connect OTRS with PagerDuty appeared first on The OTRS Blog.

With the OTRS Business Solution™ 5s you have the possibility to connect OTRS with Redmine. The following article will explain how to configure the RedmineConnector to establish a connection between OTRS and Redmine.

To complete this Howto, you need a running OTRS & Redmine. Furthermore you need to activate the REST API in Redmine first. Go to “Administration” – “Settings” – “API” and enable the checkboxes and click on “save”.

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.)

Third Party Software

You need this third party software:

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

DynamicFields

• DynamicField “RedmineID” of type „TEXT“
• DynamicField “RedmineIDJSON” of type “TEXT”
• another DynamicField “RedmineStatus” of type “TEXT”

Configuring the “RedmineConnector”

When you’re done with the pre-requirements, you have to create a new web service within OTRS. Afterwards you can set up the needed requester invokers.

The name of the new webservice could be “RedmineConnector”:

General settings of the RedmineConnector

Configuring the Invoker “CreateIssue”

Now we’re ready to start the configuration of our Invokers. The first Invoker is “CreateIssue”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing and incoming response data.

For the incoming response data we’ve to use the two dynamic fields, which we created before.

Now we can configure our outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

You also need a XSLT-mapping for the incoming response data, because we need to store the Redmine Issue ID in two ways:

The Redmine Issue ID is stored in the dynamic field “RedmineID” and is afterwards shown in the OTRS TicketZoom.

For updating Issues in Redmine we need to store the IssueID + the ending “.json” in the second dynamic field “RedmineIDJSON”. With the <xsl:value-of> element we’re modifying the response value:

<xsl:value-of select=”concat(//issue/id, ‘.json’)”/>

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the first Invoker.

Configuring the Invoker “UpdateIssue”

The next invoker is “UpdateIssue”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “RedmineIDJSON”) and use “XSLT” as a mapping for your outgoing data.

As outgoing XSLT-mapping you can use my example:

A mapping for the incoming response data is not neccessary, but maybe a good idea. ;-)

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the second Invoker.

Configuring the Invoker “GetIssue”

The next invoker is “GetIssue”.  The only field we need is the dynamic field “RedmineIDJSON”, because we want to receive the latest data from Redmine.

As outgoing XSLT-mapping you can use my example:

We need a mapping for the incoming response data, because we want to show some values in OTRS. In my example I want to see the latest Redmine Issue state in OTRS:

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the second Invoker.

Configuring the “Network Transport”

It’s necessary to configure the network transport, because we’ve to use the right requests commands towards Redmine. But it’s quite easy as you can see:

It’s important to use “BasicAuth” as authentication module. Please use a valid Redmine user for authentication!

Afterwards just click on “Save and finish”.

Testing the “RedmineConnector”

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

As result you should see something similiar in the OTRS Debugger:

In Redmine you’ll now see this Incident:

If we now trigger the Invoker “UpdateIssue” we receive an “error”:

This error is okay, because OTRS only tells us that Redmine didn’t send an answer with a body.

As a result the title changed from “A bug was found” to “A bug was found [ Updated in OTRS ]“. This is also visible in the Redmine History:

And the last the Invoker “GetIssue”:

We should now see the Redmine Issue state in OTRS.

Further thoughts

The invoker “GetIssue” can be triggered regulary. For example with the freely selectable OTRS Business Solution™ feature “Advanced GenericAgent”. This feature allows relative timestamps for date/datetime dynamic fields.

More information about the Redmine API

You can also use other ressources which are provided by the Redmine API.

Please go to the following website, if you need more information: http://www.redmine.org/projects/redmine/wiki/Rest_api

The post How to connect OTRS with Redmine appeared first on The OTRS Blog.

With the OTRS Business Solution™ 5s you have the possibility to connect OTRS with Zendesk. The following article will explain how to configure the ZendeskConnector to establish a connection between OTRS and Zendesk.

To complete this Howto, you need a running OTRS & a valid Zendesk-System. Furthermore you need a valid agent login. The REST/JSON API of Zendesk is activated by default. We should use the “Password Access” method.

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.)

Third Party Software

You need this third party software:

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

DynamicFields

• DynamicField “ZendeskID” of type „TEXT“
• DynamicField “ZendeskIDJSON” of type „TEXT“
• another DynamicField “ZendeskState” of type “TEXT”

Configuring the ZendeskConnector in OTRS

When you’re done with the pre-requirements, you have to create a new web service within OTRS. Afterwards we’ll set up the needed requester invokers.

The name of the new webservice could be ZendeskConnector:

Configuring the Invoker “TicketCreate”

Now we’re ready to start the configuration of our Invokers. To be able to create tickets in Zendesk, we’ve to set up our first Invoker called “TicketCreate”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing and incoming response data.

For the incoming response data we’ve to use the two dynamic fields, which we created before.

Now we can configure our outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

You also need a XSLT-mapping for the incoming response data, because we need to store the Zendesk Ticket ID in two ways:

The Zendesk Issue ID is stored in the dynamic field “ZendeskID” and is afterwards shown in the OTRS TicketZoom.

For updating / comment on Tickets in Zendesk we need to store the TicketID + the ending “.json” in the second dynamic field “ZendeskIDJSON”. With the <xsl:value-of> element we’re modifying the response value:

<xsl:value-of select=”concat(//issue/id, ‘.json’)”/>

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the first Invoker.

Configuring the Invoker “TicketUpdate”

The next invoker is “UpdateIssue”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “ZendeskIDJSON” in the “Ticket dynamic fields” dropdown) and use “XSLT” as a mapping for your outgoing data.

As outgoing XSLT-mapping you can use my example:

A mapping for the incoming response data is not neccessary, but maybe a good idea. ;-)

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the second Invoker.

Configuring the Invoker “TicketGet”

The next invoker is “TicketGet”.  The only field we need is the dynamic field “ZendeskIDJSON”, because we want to receive the latest data from Zendesk.

As outgoing XSLT-mapping you can use my example:

We need a mapping for the incoming response data, because we want to show some values in OTRS. In my example I want to see the latest Zendesk ticket state in OTRS:

Last point for this invoker is the used “Event trigger”. Just select one and you’re done with the next Invoker.

Configuring the “Network Transport”

It’s necessary to configure the network transport, because we’ve to use the right requests commands towards Zendesk. But it’s quite easy as you can see:

It’s important to use “BasicAuth” as authentication module. Please use a valid Zendesk user for authentication!

Afterwards just click on “Save and finish”.

Testing the ZendeskConnector

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

As result you should see something similiar in the OTRS Debugger:

In Zendesk you’ll now see this Incident:

If we now trigger the Invoker “TicketUpdate” we’ll see the following in the Debugger:

As a result the a new comment is added to the ticket in Zendesk. This is also visible in the Zendesk comment section:

And the last the Invoker “TicketGet”:

We should now see the Zendesk ticket state in OTRS.

Further thoughts

The invoker “TicketGet” can be triggered regulary. For example with the freely selectable OTRS Business Solution™ feature “Advanced GenericAgent”. This feature allows relative timestamps for date/datetime dynamic fields.

More information about the Zendesk API

You can also use other ressources which are provided by the Zendesk Core API.

Please go to the following website, if you need more information: https://developer.zendesk.com/rest_api/docs/core/introduction

The post How to connect OTRS with Zendesk appeared first on The OTRS Blog.

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:

1. ConfigItemCreate: to be able to create new CIs in our CMDB
2. ConfigItemDelete: to be able to delete existing CIs from our CMDB
   
3. ConfigItemGet: to be able to retrieve the latest data of a CI
4. ConfigItemSearch: to be able to search for CIs
5. 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.

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.

The post How to connect OTRS with the OTRS CMDB appeared first on The OTRS Blog.

With the OTRS Business Solution™ 5s, you have the possibility to connect OTRS with ServiceNOW. The following article will explain how to configure the SNOWConnector to establish a connection between OTRS and ServiceNOW.

To complete this Howto, you need a running OTRS & a valid ServiceNOW-System. Furthermore, you need a valid agent login. The REST/JSON API of ServiceNOW is activated by default. Additionally, you have to specify a user, which is allowed to use the REST/JSON API of ServiceNOW.

OTRS Requirements for this HowTo:

OTRS Framework

• at least OTRS 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.)

Third Party Software

You need this third party software:

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

DynamicFields

• “SNOWTicketNumber” of type „TEXT“ to store the ServiceNOW TicketNumber (e.g.: INC0010017)
• “SNOWSysID” of type “TEXT” to store the ServiceNOW SysID (e.g.: 33d23ade0f20030010694d9ce1050ebb)
• “SNOWLastUpdate” of type “TEXT” to store the timestamp of the last contact to ServiceNOW
• “SNOWState” of type “TEXT” to store the latest ticket state of the ServiceNOW ticket

Configuring the SNOWConnector in OTRS

After you satisfied the pre-requirements, you’re ready to create a new web service within OTRS. The name of the new web service is SNOWConnector. Afterwards, you have to set up the needed providers and invokers.

Configuring the Provider “TicketCreate”

We start with the configuration of our first Provider “TicketCreate”. ServiceNow should be able to create tickets in OTRS, if necessary.

Because ServiceNOW is able to specify the data and also the format, which is sent out, we don’t need an incoming mapping.

Configuring the Provider “TicketUpdate”

It should also be possible for ServiceNOW to update tickets in OTRS. For that reason, you have to configure a second provider which is called “TicketUpdate”.

We also don’t need an incoming mapping.

Configuring the Invoker “CreateIncident”

Now you’re ready to start the configuration of our Invokers. To be able to create tickets in ServiceNOW, you have to set up an Invoker called “CreateIncident”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing and incoming response data.

For the incoming response data, you have to select the dynamic fields (SNOWTicketNumber, SNOWSysID & SNOWState), which you created before.

Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

You also need an XSLT-mapping for the incoming response data, because you have to store the ServiceNOW TicketNumber and the ServiceNOW SysID:

OTRS stores the ServiceNOW TicketNumber in the dynamic field “SNOWTicketNumber”. Afterward, it’s shown in the OTRS TicketZoom.

For some use cases (updating a ServiceNOW ticket, upload an attachment to a ticket), you have to use the SysID of the ServiceNOW ticket. For that reason, we store the SysID in the DynamicField “SNOWSysID”. Furthermore, we want to know the latest State of the ServiceNOW ticket, for that reason, we’re using the <xsl:choose> element to convert the StateID into a readable format.

The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the first Invoker.

Configuring the Invoker “UpdateIncident”

The next invoker is “UpdateIncident”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “SNOWSysID” in the “Ticket dynamic fields” dropdown) and use “XSLT” as a mapping for your outgoing data.

As outgoing XSLT-mapping, you can use my example. I will transmit the content of an article and add this content as a comment to the ServiceNOW ticket.

A mapping for the incoming response data is necessary if you want to store the “LastUpdate” timestamp of ServiceNOW.

The used “Event Trigger” is the last point for this Invoker. Just select one and you’re done with the second Invoker. In my example I’m using an ArticleCreate event in OTRS, to trigger the Invoker.

Configuring the Invoker “CreateAttachment”

The next invoker is “CreateAttachment”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “SNOWSysID” in the “Ticket dynamic fields” dropdown) and use “XSLT” as a mapping for your outgoing data.

Please use my example as outgoing XSLT-mapping:

Furthermore, a mapping for the incoming response data is necessary, if you want to store the “LastUpdate” timestamp of ServiceNOW.

The used “Event trigger” is the last point. Select one and you’re done with the last Invoker. In my example I’m using an ArticleCreate event in OTRS, to trigger the Invoker.

Configuring the SNOWConnector “Network Transport”

Provider configuration

We have to set up the “Route mapping” and the “Valid request methods” for the provided Operations.

Make sure you use unique “route mappings” and/or “request methods” for all operations.

Requester configuration

It’s necessary to configure the network transport for the Invokers because we’ve to use the right requests commands towards ServiceNOW. But it’s quite easy as you can see:

It’s important to use “BasicAuth” as an authentication module. Please use a valid ServiceNOW user for authentication! Keep in mind, this user must be authorized to use the ServiceNOW API!

Be careful with the controller mapping for “CreateAttachment”. It’s /ecc_queue instead of /incident

Afterward just click on “Save and finish”.

Testing the SNOWConnector

Testing the Providers

Finally, we can do some tests. At first, we create a ticket in OTRS from ServiceNOW.

Now we test the second Provider “TicketUpdate”. Here’s the debug log for a ticket update from ServiceNOW:

Testing the Requester

Create or take an already existing ticket and trigger the “CreateIncident” Invoker.

As result you should see something similar in the OTRS Debugger:

In ServiceNOW you now see this Incident:

If we now trigger the Invoker “UpdateIncident” we’ll see the following in the Debugger:

ServiceNOW adds a new comment to the ticket. The comment is visible in the comment section:

And the last the Invoker “CreateAttachment”:

You can now see the ServiceNOW ticket state & last update time in OTRS.

In ServiceNOW you see the attachment in the activity stream.

More information about the ServiceNOW API

You can also use other resources which are provided by the ServiceNOW API.

If you need more information about the ServiceNOW API, please go to the following website: https://developer.servicenow.com/app.do#!/api_doc?v=jakarta&id=server

The post How to connect OTRS with ServiceNOW appeared first on The OTRS Blog.