Please find the new translation application at translate.otrs.com. If you want, you can register for an account for free and help translate OTRS into your language.

Let’s take a Service Desk Incident Process as an example.

1. Identify activities of the process.
   These should not be TASKS like “Set queue to 2^nd Level,” but should be Create Record, Categorize Incident, Prioritize Incident, Analyze Symptom, …
2. Identify data collected by the process.
   Request Type (Tickets)
   Service Level Agreement (Time to work on ticket)
   Service Level (Criticality)
   
3. Identify the workflow of activities.
   What is done first, second, third?
   
4. Identify useful dialogs for each activity to help collect or record the data.
5. Identify triggers for optional and immediate advancement to the next activity (i.e Escalate to 2^nd Level).
6. Determine which data should be saved as process data for use in templates (i.e. Handover texts).
   Description
   Initial analysis
   Suggested workaround
   Workaround results
   Confirmation that the knowledge base was consulted
   Verification of the system version
   Attached log files
7. Identify escalation paths (i.e. Escalate to 2^nd tier after workaround failure).
   Do we have multiple escalation paths?
   
8. Set workflow requirements.
   Consult Level 2 or other departments where escalation is possible to gather their requirements.
9. Identify loop-back possibilities.
   Under which circumstances can requests boomerang and why?
   
10. Draw the process ( i.e. with a tool like https://bpmn.io).
    

Just gimme the core message.

Using OTRS and the OTRS feature add-on ticket invoker, you can create a user-driven RPC-backed process to allow customer users to create and register their own customer users.

Process Map

Above you see a process which allows the customer user to enter customer user details (dynamic fields). The process will then trigger the Generic::RPC (see Remote Administration per REST.) To call the Kernel::System::CustomerUser::CustomerUserAdd and create the customer.

If any error occurs, the ticket will be closed and the process will end. If not, the process ticket is closed successfully.

When a customer user leaves the company, the customer user administrator can easily find the closed tickets and remove the user by using the customer user maintenance activity. The customer user is then marked for removal and Kernel::System::CustomerUser::CustomerUserUpdate will set the user to invalid.

The web service setup is trivial and requires some mapping.

Web Service Details

        Source         => Hard Coded
        ID             => Mapped from DynamicField_UserLogin
        UserFirstname  => Mapped from DynamicField_UserFirstname
        UserLastname   => Mapped from DynamicField_UserLastname
        UserCustomerID => Mapped from current customer
        UserLogin      => Mapped from DynamicField_UserLogin
        UserEmail      => Mapped from DynamicField_UserEmail
        ValidID        => Mapped from DynamicField_ValidState
        UserID         => Mapped from current user

<?xml version="1.0" encoding="UTF-8"?> <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" encoding="utf-8" indent="yes" /> <!-- Don't return unmatched tags --> <xsl:template match="text()"/> <!-- Root template -->
    <xsl:template match="/">
        <RootElement>
            <UserLogin>wsusr</UserLogin>
            <Password>wsusr</Password>
            <Object>Kernel::System::CustomerUser</Object>
            <Method>CustomerUserAdd</Method>
            <Parameter>
                <Source>CustomerUser</Source>
                <UserLogin><xsl:value-of select="//Ticket/DynamicField[Name = 'UserLogin']/Value"/></UserLogin>
                <UserFirstname><xsl:value-of select="//Ticket/DynamicField[Name = 'UserFirstname']/Value"/></UserFirstname>
                <UserLastname><xsl:value-of select="//Ticket/DynamicField[Name = 'UserLastname']/Value"/></UserLastname>
                <UserEmail><xsl:value-of select="//Ticket/DynamicField[Name = 'UserEmail']/Value"/></UserEmail>
                <UserCustomerID><xsl:value-of select="//Ticket/CustomerID"/></UserCustomerID>
                <ValidID><xsl:value-of select="//Ticket/DynamicField[Name = 'ValidState']/Value"/></ValidID>
                <UserID>1</UserID>
            </Parameter>
        </RootElement>
    </xsl:template>
</xsl:transform>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" encoding="utf-8" indent="yes" />
    <xsl:template match="/RootElement">
        <xsl:choose>
            <xsl:when test="not(Result)">
                <RootElement>
                    <Ticket>
                        <DynamicField>
                            <Name>ReqestResponse</Name>
                            <Value>UnknwonError</Value>
                        </DynamicField>
                        <State>closed unsuccessful</State>
                    </Ticket>
                </RootElement>
            </xsl:when>
            <xsl:otherwise>
                <RootElement>
                    <Ticket>
                        <DynamicField>
                            <Name>ReqestResponse</Name>
                            <Value>UserAdded</Value>
                        </DynamicField>
                    </Ticket>
                </RootElement>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>
</xsl:transform>

1. A customer user will never know why a user couldn’t be created. Any error should be reported to the OTRS admin. Generally, it’s related to a duplicate UserLogin. It could also be a bad or duplicate UserEmail.
2. Any customer can create a user for his company.

1. To help customer users understand what’s happening, a status can be added, the ticket closed, and a note to “contact the admin of the system for more details” can be created.
2. Use the ACL to limit the process to a specific user or users.
3. Company tickets can be limited to only specific users.

Name:  UserLastname
Label:  User Last Name
Type:   Text
Object: Ticket

Name:   UserFirstname
Label:    User First Name
Type:    Text
Object: Ticket

Name:   UserLogin
Label:   User Login
Type:    Text
Object: Ticket

Name:   UserEmail
Label:    User Email
Type:     Text
Object:  Ticket

Name:   ValidState
Label:    User Valid
Type:     Dropdown
Object:  Ticket

Name:   ReqestResponse
Label:    Request Response
Type:     Text
Object:  Ticket

Need assistance? Contact sales@otrs.com.

Summary (TL/DR)

Some missing features can be built using a loopback request to OTRS’ internal Perl API. Using processes to control these gives you even more power.

The principle Security by Design affects different aspects of the OTRS software. It:

• Secures software architecture,
• Aids developers in writing secure code,
• Encourages users to work with their system in a responsible way, and
• Support administrators in configuring their system securely.

In the following, we’ll look at six examples of Security by Design in OTRS 8. After looking at some technical details, we’ll analyze who can benefit from each in which way.

Content Security Policy

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

You can think of this as putting the browser in a sandbox mode by instructing it what should be allowed for the current application and what should be prohibited, for example executing code or loading external resources.

With OTRS 8, Content Security Policy headers are set for the OTRS frontend application, restricting access to the current server only. All resources are restricted as much as possible. Examples:

1. JavaScript can only be loaded from the server folder where the app is statically deployed. Other scripts are discarded. This is a major improvement over ((OTRS)) Community Edition 6 in which inline scripts had to be allowed for technical reasons.
2. External images cannot be loaded within the application. If a user or attacker tries to inject external resources, the browser will refuse that request and log such an error:
   

How does this affect:

• Users: they can trust in the cooperation of OTRS and the browser to achieve a high level of built-in application security and protection against common attacks.
• Administrators: the restrictive default setting requires additional configuration if external content does need to be integrated into the application.
• Developers: they don’t have to care – this is implicitly used in all API endpoints.

JSON Web Tokens

JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties. In OTRS 8, JSON Web Tokens are used for cryptographically secured, client-side storage of authentication information. Key benefits over the previously used cookies are:

• The tokens are not visible to the user (for example, via the URL).
• They are not automatically sent by the browser.
• Their built-in cryptographic signature prevents user manipulation of the token.
• The tokens can be analyzed and revoked on the server.
  
• As before, tokens are limited to remote IP address by default (configurable).

How does this affect:

• Users & Administrators: the system continues to work in a most convenient but more secure way.
• Developers: requiring a valid token is as easy as:

with qw(
    Kernel::WebApp::Controller::API::Role::RequiresAgentAuthentication
);

Restricted Cookie Usage

The bad news about authentication information storage and transfer is that some endpoints still require cookies. ? For example, loading inline images and loading an iFrame still rely on browser built-in mechanisms of transferring the authentication data.

To mitigate the possible negative consequences of cookie usage, the following changes were made:

• Cookies contain the same JSON web token content and are therefore also cryptographically protected.
• Cookies are now restricted as much as possible to guard against CSRF:
  • Their httpOnly attribute is set, so they cannot be (easily) accessed by JavaScript.
  • Cookies are only accepted by a few endpoints that really need it: Most endpoints don’t accept them.

Deep Input Validation

Input validation is an important topic for application security. You want to make sure that data coming from the outside world to the application conforms to what is expected. In a security context, a part of this is to make sure that the data does not contain any hidden attacks like SQL Injection, Cross Site Scripting and so on.

OTRS 8 contains a new API for deep input data validation which is very easy to use:

• There is currently a growing list of 38 built-in data validation modules.
• They range from simple (e. g. “positive integer”) to complex like “valid ticket number that exists in the database” or “valid JSON document.”
• API Endpoints just need to specify what data they expect, validation happens automatically. As an example, the following snippet shows how an endpoint declares that it receives one mandatory parameter via URL, which is expected and validated to be a TicketID that exists in the database. No further code is needed, the validation happens automatically in the background:

sub ValidationUriParameters {
    return {
        Fields => {
            TicketID => [ 'Required', 'Ticket::TicketID' ],
        },
   };
}

How does this affect:

• Developers: validating input data is fun, after all!

Extended Password Policies

OTRS 8 has much more effective password policies than before:

1. Password complexity rules can be established, like in previous versions. We leave the more philosophical question »What makes a good password« to the admin to decide and configure in their system.
2. Passwords now expire automatically after 30 days by default.
3. Users are prevented from re-using their previous passwords.
4. After the first login, users have to choose a new password.

Of course, all of these are configurable – including exceptions for certain users or groups.

How does this affect:

• Users: This might make life of OTRS agent users a bit harder, but hopefully it helps them handle their credentials in a responsible way.
• Admins: The restrictive default configuration helps admins to operate their system in a secure way, while offering full flexibility to adapt.

2 Factor Authentication

OTRS 8 now has modern real-life 2 Factor Authentication support made possible with three different Authentication Methods:

• Apps – use your favorite app like Google Authenticator. Configuration is easy via QR code.
• SMS – provided via SMS cloud service from OTRS Group.
• Email – can be used as a fallback transport, since usually all agents have valid email addresses. Supports encryption.

In a new OTRS 8 system, 2 Factor Authentication is required by default. Of course, it can be made optional for all or selected users, or it can be turned off altogether. It can be used even in Single-Sign-On scenarios where agents use a central login service – then they still have to provide a token for the login to OTRS.

How does this affect:

• Users: logging into the system becomes a little more effort.
• Admins: The restrictive default configuration helps admins to operate their system in a secure way, while offering full flexibility to adapt.

Conclusion

Security by Design in OTRS 8 means:

• Making the system more secure by way of design and architecture.
• Aiding developers in writing secure code with little effort.
• Encouraging users to work in a responsible way.
• Supporting inexperienced admins in the secure operation of OTRS by way of restrictive default configuration while offering much flexibility to adapt.

BPMN 2.0 differentiates between an embedded subprocess and a call activity. From a conceptual point of view, both will initiate a subprocess when process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the subprocess is embedded within the original process definition. The main use case for a call activity is to have a reusable process definition that can be called from multiple other process definitions.

Although OTRS does not have a subprocess modeling capability as of OTRS 7 (or with upcoming OTRS 8), I will show you how to make a process modular.

Just gimme the core message.

In the above process, the “Approval” subprocess could be very detailed, and it could make designing an already detailed process more time consuming.

Subprocesses, like approvals, are often standardized processes that are needed in many areas of business from vacation requests, to hardware orders, to on-boarding tasks. Below we can see how the using a modular process called by a script task activity above can greatly increase readability in an already detailed process.

To standardize this and make the subprocess of approval reusable, BPMN 2.0 defines a call activity. Because OTRS itself doesn’t have subprocesses or call activities, we will make use of the “magic” which makes a process ticket a process ticket — dynamic fields.

A process is identified by the ProcessID and the ActivityID. Without these, it’s YAT (yet another ticket). In order to spring from one process to another, just quickly rewrite the information via a script task activity and then you’re off to the call activity (or YAP – yet another process).

You will have to remember the old ProcessID and ActivityID by saving them to dynamic fields. Additionally, you should jump back into a dummy activity to prevent a loopback situation. Therefore you will need to know the next ActivityID before you leave your process for the modular process.

You may have as many activities in your modular process as needed, and then return by simply using the saved ProcessID and next ActivityID to return.

Note: Don’t forget to remember your decision. This will be automatically processed by the sequence action flow upon returning to your calling process.

All data saved during the process Hardware Order can be used in the Approval process, and all data saved in the Approval process can be used when returning to the Hardware Order process. This is the joy of saving the data to the ticket (also known as a business object record).

This works in a serialized fashion, meaning it’s not a parallel process. The approval process must be finished before continuing, which I guess is kinda the real-world situation anyhow.

ProTip: Set the Approval process to fadeaway so that it’s not callable and you don’t have to filter it per ACL. A fadeaway process will continue to work, but is not callable in the front end.

Summary (TL/DR)
Organizing your processes and making them more readable is easy when you use a script activity and dynamic field to move between processes. This especially makes sense when you have a reusable part of a process (a.k.a. a call activity).

((enjoy))

Best Wishes,

///shawn

“Instant gratification takes too long.”,

OTRS has offered an external API since OTRS 7. This API, however, does not cover administrator actions. Many users may remember, in older versions, there was an RPC interface via the rpc.pl script. This has gone away. Fortunately, one little known fact is that the RPC feature is still available via the Generic Interface.

This allows admins to remotely administer their OTRS via a REST or SOAP call, among other methods.

Just gimme the core message.

In order to have access to the power of the perl API, you need to configure OTRS to allow access to this controller — Generic::RPC

WARNING: This is a security threat if you don’t know what you are doing.

Activate Controller

Search for Generic::RPC in the system configuration.

Set this to active and deploy.

Activate Object

Determine which object is to be used and activate it in the system configuration.

Search for GenericInterface::Operation::Generic::RPC::Modules###001-Default

Modify, if needed, by adding the system module to be used, save and deploy.

Note: In this case, we want to add or invalidate a group, so we do not need to add a new object.

Adding a Group via the Generic Interface Using the Generic::RPC Controller

In order to accomplish this, you need the documentation for the controller (Kernel::GenericInterface::Operation::Generic::RPC) and the operation (Kernel::System::Group) you want to control.

You need to configure a new web service. (Read how on-line: Web Services) For our example, we will use REST for our transport.

As you can see, we need:

• a provider operation using the controller Generic::RPC
• a defined route in the transport settings
• a tool to make the request (see Postman).

In our documentation of the controller,  we read that you need the following (as of OTRS 7).

my $Result = $OperationObject->Run(
    Data => {
        UserLogin         => 'some agent login',     # (required) 
        CustomerUserLogin => 'some customer login',  #
        SessionID         => 123,                    #
        Password          => 'some password',        # required with UserLogin or CustomerUserLogin.
        Object            => 'Ticket',               # (required)
        Method            => 'TicketGet',            # (required)
        Parameter         => { TicketID => 123, },   # (optional)
    },
);

The “Object” is always the system module to be used. The “Method” is the function to be called. We will use GroupAdd() from Kernel::System::Group

This is our example request.

The result is that a group named web-service is added (see title picture above) with the comment “added via webservice.” This group is immediately ready for use by OTRS.

Summary (TL/DR)

It is possible to access core functions of OTRS using the Generic::RPC. This will require a deeper understanding of how OTRS works and its data model, but it’s possible. Using this as a loopback web service can help administrators implement features which are not currently available.

Have more interest? Contact sales@otrs.com for a web service design workshop or administrator training.

Like moving homes, moving from one version of software to another may lead to questions like:

• Should we make a clean cut from the old OTRS installation and start a new?
• Is it time to create new queue and services?
• Do we need new users, groups, roles, etc.?

What about the old tickets? How will we deal with them?

Before you let the task of leaving the old behind and moving to new horizons overwhelm you, read further…….

The biggest issue you face after deciding to start a fresh with OTRS is: How do we handle requests which are still open? How do we redirect our mail without loosing contact with the requests which were part of the old system and still need answering?

You surely do not want to work out of two different systems. Also, changing email addresses after all those years of having your customers write to you at the current address may not be desirable.

So, how do you have your cake and eat it too?

The postal service of most countries offers mail forwarding. This means that after a move, your current address will forward mail to your new address. Similarly, with OTRS, we will arrange for something similar. Your new instance of OTRS should allow the customer to use old ticket numbers while continuing to provide agents access to the previous conversation thread.

OTRS makes this happen by this using the feature External Ticket Number Recognition.

To use this, one thing we need to understand is the ticket number structure. Each OTRS is individual. You can:

• define the type of ticket number to be used (NumberGenerator),
• make it unique (SystemID),
• define the identifier for the ticket number (Hook),
• and make it a bit more readable (HookDivider – not depicted below).

These properties allow OTRS to identify if this is a ticket number or just some random collection of identifiers in the subject (or body) of a message.

If the Hook, HookDivider, or Number do not match, then it’s not a valid ticket number. If all of these things match, then the SystemID comes into play. This is the number we will latch on to in a moment. A post office forwards its mail to the new address based on the registered last address: Our registered last address is the old SystemID.

This is where the example of the post office starts to crumble in relation to what we are trying to achieve, so let’s leave this analogy for now.

When your new system is up and running, it’s crucial that a new SystemID be chosen. Now, all of your new emails are being polled by the new system. Since the new SystemID is not found in the ticket number (as the number itself is not registered) new tickets end up being created for old requests, and you also end up having no idea what the old tickets have for content. In comes External Ticket Number Recognition and Dynamic Fields.

By configuring External Ticket Number Recognition, you can process all new emails to look for the old pattern. The key here is the SystemID, as this is the same in all tickets. When this pattern is found, OTRS saves the ticket number in a dynamic field (done automatically by OTRS for tickets not already containing an external ticket number). The dynamic field is configured to link to your old (archive) system, so that the conversation is not lost. Agents can read things from the past in the old system, but they will answer from your new system.

At this point, the new ticket number is connected via the dynamic field to the old ticket number. Your customer users can then respond to the new request using the old ticket number or the new ticket number. Eventually, all the old requests will be closed in the new system.

The only requirement you have is to keep the old system alive so that your agents can quickly reference any past conversations via the hyperlinked dynamic field.  In the example below you will see that the number is parsed from the incoming subject matched to the field OTRS4ID, and the conversation is placed in the new ticket with this matching number keeping old tickets and new tickets together.

This use case is also applicable when moving part of your teams to a separate OTRS instance to keep systems more manageable.

Need more information or want help leaving your older ((OTRS)) Community Edition for a bright new shiny OTRS, shoot us a message at sales@otrs.com.

Thanks for reading!

((enjoy))

Your Truly,

///shawn

“The great pleasure in life is doing what people say you cannot do.”,

While “free” is certainly a compelling reason for technology professionals to leverage FreeBSD, there are even greater technological advantages to its use. The OS includes mature base code that has been consistently enhanced for more than 20 years by its extensive community. FreeBSD focusses on features, speed, and stability: It performs smoothly under heavy loads and efficiently manages memory; employs modern security features, like firewalls and jails; incorporates all modern networking protocols; and is relatively easy to administer.

Given its cost (or lack of) as well as its focus on stability and security, FreeBSD has become widely used by technology professionals in a wide variety of disciplines. It can handle nearly any task, from servers and desktops to embedded and appliance applications, without any perceivable degradation of speed. Because of its wide-spread use, it is important for OTRS 7 to run smoothly on FreeBSD.

The following outlines how to install OTRS 7 on FreeBSD. Additional details can be found in the official OTRS installation manual on doc.otrs.org.

OTRS 7 Installation on FreeBSD

For this installation, we use Apache2 and MySQL. At a minimum, you will need a FreeBSD installation with a working network connection. We use ports and do not compile on our own; we use pkg to keep things simple.

Step 1: Start with the Ports

Logon with your root account, fetch the portsnap,
root@freebsd:/ # portsnap fetch && portsnap extract

and compile pkg.
root@freebsd:/ # cd /usr/ports/ports-mgmt/pkg/ && make install clean

If needed, convert it into:
root@freebsd:/ # pkg2ng

Now you can create a user in the group wheel.
root@freebsd:/ # adduser
root@freebsd:/ # pw groupmod wheel -m

Then create the /opt/ directory,
root@freebsd:/ # mkdir /opt

and fetch the latest ports.
root@freebsd:/ # portsnap fetch update

Step 2: Install Apache2

Now you have to install Apache2.
root@freebsd:/ # pkg install apache24

To run Apache HTTP Server from startup, add apache24_enable=”yes” in your /etc/rc.conf. This can be done manually or with sysrc apache2_enable=yes.

Start the webserver to begin the test.
root@freebsd:/ # service apache24 start

Step 3: Install the MySQL Database

If steps one and two are working, you can install the database next. In this case, we are using MySQL.
root@freebsd:/ # pkg install mysql57-server

To run MySQL from startup, add mysql_enable=”yes” in your /etc/rc.conf. This can be done manually or with sysrc mysql_enable=yes

Step 4: Install the Packages

The Perl packages are tricky, but they can easily found with
pkg search | grep p5

Via command, you can install the packages you need.
root@freebsd:/ # pkg install ap24-mod_perl2 p5-CryptX p5-Archive-Zip p5-Digest-Bcrypt p5-Crypt-SSLeay p5-DateTime p5-DBD-mysql p5-EV p5-JSON p5-JSON-XS p5-Moose p5-DBD-LDAP p5-Net-DNS p5-Template p5-Search-Elasticsearch p5-YAML p5-YAML-LibYAML p5-libxml p5-XML-LibXML p5-XML-XSLT p5-XML-LibXSLT p5-Text-CSV_XS p5-Template-Toolkit

If you miss modules, you can install them via cpan.
root@freebsd:/ # cpan Date::Format

Depending on the installation, if the Perl path is not recognized, then a symbolic link may be helpful.
root@freebsd:/usr/bin # ln -s /usr/local/bin/perl perl

Step 5: Adding OTRS Configurations

Now create an OTRS user.
root@freebsd:/ # adduser otrs

And activate Apache modules in
/usr/local/etc/apache24/modules.d/260_mod_perl.conf

Then enable the mod_perl
LoadModule perl_module       libexec/apache24/mod_perl.so

in
/usr/local/etc/apache24/httpd.conf

And enable the proxy modules
LoadModule proxy_module libexec/apache24/mod_proxy.so
LoadModule proxy_http_module libexec/apache24/mod_proxy_http.so
LoadModule proxy_wstunnel_module libexec/apache24/mod_proxy_wstunnel.so

Now configure the Apache conf file
root@freebsd1:/usr/local/etc/apache24/extra:/# ln -s /opt/otrs/scripts/apache2-httpd.include.conf ./zzz_otrs.conf

and include the file in /usr/local/etc/apache24/httpd.conf

Include etc/apache24/extra/zzz_otrs.conf

Then, try to start Apache with the new configuration
root@freebsd:# apachectl restart

Note: be sure to test your current setup. If you browse to your /otrs/index.pl, then an error will occur, but the error is fine at this point.
The error message:
“Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.”

At this point, it is OK to continue with your installation steps and set file permissions
root@freebsd:# perl /opt/otrs/bin/otrs.SetPermissions.pl –admin-group=wheel

Now install Elasticsearch
root@freebsd: # pkg install elasticsearch6 p5-Search-Elasticsearch
root@freebsd: # /usr/local/lib/elasticsearch/bin/elasticsearch-plugin install –batch ingest-attachment
root@freebsd: # /usr/local/lib/elasticsearch/bin/elasticsearch-plugin install –batch analysis-icu

And enable Elasticsearch in /etc/rc.conf.
elasticsearch_enable=”YES”

Then start the service.
root@freebsd: # service elasticsearch start

Wait several seconds and then test the connection.
[otrs@freebsd ~]$ /opt/otrs/bin/otrs.Console.pl Maint::DocumentSearch::Check

The connection should be successful and the following message should appear:

Getting cluster information…
+———+————————+
| Cluster | elasticsearch |
| UUID | Px2wtqcyRlumLrXKpchvzA |
| Status | Green |
+———+————————+

Getting nodes information…

+———————–+————————+
| Node | eZRpjTv |
| UUID | eZRpjTvDSxGbx3LvFnSzrg |
| Master | Yes |
| Elasticsearch version | 6.4.2 |
| JVM version | 1.8.0_192 |
| Required Plug-ins: | |
| analysis-icu | Installed |
| ingest-attachment | Installed |
| Status | On-line |
+———————–+————————+

The database is set up identically to all other Linux distributions. If you need additional help with the database setup, visit:
https://doc.otrs.com/doc/manual/installation/stable/en/content/installation.html#mysql-or-mariadb

Step 6: Finishing Up

Finally, install Python and NPM. Update the NPM.
root@freebsd: # pkg install openjdk
root@freebsd: #npm install -g npm@latest

When you have finished, restart the webserver. As a final step, check the Support Data Collector:
Running FreeBSD is appealing, affordable and accessible for all, and it certainly won’t get in your way of using OTRS. The six steps above offer a high-level overview of how to run OTRS on FreeBSD, but if you have any difficult or are interested in more detailed instructions, review the official OTRS installation documentation at:

https://doc.otrs.com/doc/manual/installation/stable/en/content/installation.html#step-9-start-the-otrs-daemon-and-web-server.

Rowing is a good sport which shows the relationship between accountability and responsibility. The coxswain (or simply the cox) is the team member who sits in the boat facing the bow, steering the boat, and coordinating the power and rhythm of the rowers. This member is accountable for the speed and direction of the boat, and making sure that it reaches its goal safly and quickly.

Like the coxswain, leaders take on more responsibility for customers today than ever before due to the growing complexity of services and the technical demands of customers. As companies are streamlined, responsibilities grow; this requires delegating of tasks to make sure the services sold are actually delivered. OTRS challenges your service desk leaders to be accountable and provides them the tools to do so.

Your team is, in many cases, globally active. You may have a smaller team led by a single indivdual or a larger team led by multiple individuals: in both cases, the leader is responsible for said team. The act of delegating gives authority to the team to provide service to the customer. This can range from sharing knowledge and resources to specialized authority, like discounting or performing out-of-the-ordinary service to make the customer happy and solve an issue. These leaders are, however, still accountable for the success or failure of the team with respect to providing the service promised to the customer.

This is where the OTRS Feature Add-on known as Queue Responsible can help. In its uncustomized state, OTRS can assign ownership of tickets to agents. This is the delegation of authority from a leader to a team member, but by transferring the ticket in this way, it does not address the need for leaders to remain ultimately responsible. Similary, OTRS uses Queues to help direct the work to the best, or most appropriate, team to deal with the customer request. While the routing helps facilitate the delegation of authority, this also doesn’t tell us who is accountable for the work.

Using the OTRS Feature Add-on Queue Responsible, it is now possible to make leaders accountable for their team by automatically assigning them as the person responsible for tickets within queues for which they are responsible.

Requirements:
OTRS or OTRS On-Premise

As a user of OTRS, you may install the Feature Add-on Queue Responsible, whereby all tickets created or moved into a queue will automatically designate a defined agent, presumably the team leader, as responsible.

An added benefit is that reports can then be used to better aid decision making based on ticket states, types, services, escalations and now the responsible party.

The responsible manager can always have his or her eye on things by using the responsible view, and can react appropriately without having to do the task themselves or asking for status updates on tickets.

This is a truly useful tool for management to keep on top of the status of service delivery. So, if you’re currently running OTRS or OTRS On-Premise, take a look at this Feature Add-On and talk to your service team if you need help with configuration.

NOTE: Currently using ((OTRS)) Community Edition – our open source and free software? Contact sales@otrs.com to discuss upgrading: you’ll get access to support and many additional Feature Add-Ons like Queue Responsible.

Business Process Model and Notation, BPMN for short, allows you to visualize the process model. A process model, written in BPMN, is an XML file at its heart. This XML format is well defined and maintained by the Object Management Group. This XML is deigned for portability, to be executable, and is currently the leading industry standard format (ISO/IEC 19510:2013). Business Process Management Suites (BPMS) and other tools use this to exchange processes. This means that most of these tools can read and or generate BPMN. Read how OTRS is leveraging this standard.

When designing a process, it should be clear to business users what is happening. This means the tasks involved and the performers are graphically represented. BPMN 2.0 has an entire library of standardized visual elements and terminology which OTRS leverages now to better conform to this standard.

BPMN describes the following two objects (narrowing it down a bit ;)) which OTRS is has adopted.

Task Objects: User, Script, Service (others not currently addressed)
Sequence Flow

In ((OTRS)) Community Edition, you have the possibility to configure:

Activities
Activity Dialogs
Transitions
Transition Actions

Automation of the workflow takes place in the transition and transition actions.

In OTRS, we now talk about

Task Activities
User Task Activity Dialogs
Sequence Flows
Sequence Flow Actions

So far no big change. We see now that OTRS uses the standard names for two elements vs. re-inventing the wheel. This makes it easier for your business team to talk with the OTRS administrators and makes integration tasks much easier. The real magic comes when we create a Task.

A Task in ((OTRS)) Community Edition is always a User Task.

A Task in OTRS can be a User, Script, or Service Task.

This means, that you can now visualize all of the elements of automation within the process manager canvas. Based on the user input of any Task, the Sequence Flow will determine the next Task. Changes in ticket data done via a Script Task (or specially programmed functions like Sending an Email), or calls to foreign systems via a Service Task, are not only presented to the process designer for ease and speed of design and troubleshooting, but notification of such tasks are now seen by agents when the system is performing them, or during errors.

Task Wokring

Taks Failed

A fully visual process, only with OTRS.

We still have some tool specifics which we will be adapting to support the standard better in the future, but for now: Service Desk Management Automation has never been easier and more compliant that with OTRS.

Like in former blog posts, there are several requirements for this HowTo:

• running OTRS 6.0.x system
• a valid Slack workspace

Prepare Slack for the integration

Follow the instructions and create a new incoming webhook.

Configure the SlackConnector on OTRS side

At first, we’ve to create the new web service.

Afterward, we need a new invoker. Attached you’ll find the first part of my config:

The most important part is (as always) the XSLT mapping. The following example is tested and working:

Here’s the XSL stylesheet:

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output method="xml" doctype-public="XSLT-compat" omit-xml-declaration="yes" encoding="UTF-8" indent="yes" />

<xsl:template match="RootElement">
<xsl:copy>
<text>New Ticket [Ticket#<xsl:value-of select="//TicketNumber"/>] created!
Title: <xsl:value-of select="//Ticket/Title"/>
Priority: <xsl:value-of select="//Ticket/Priority"/>
</text>
<attachments>
<title>https://storm-demo.managed-otrs.com/otrs/index.pl?Action=AgentTicketZoom;TicketID=<xsl:value-of select="//TicketID"/></title>
<title_link>https://storm-demo.managed-otrs.com/otrs/index.pl?Action=AgentTicketZoom;TicketID=<xsl:value-of select="//TicketID"/></title_link>
<text>Go to ticket to see more information!</text>
</attachments>
<attachments/>
</xsl:copy>
</xsl:template>
</xsl:transform>

The last part for the invoker is the used event trigger. Because I want to inform my Slack users every time when a new ticket is created, I’m using the “TicketCreate” event without any event filters:

That’s all for the invoker configuration. The next part is the configuration of the transport. I’m using a small workaround to make the integration possible. My Slack token is “T0X829D7E/BBYH0BEE4/nAFuXxXxXxXxXxXxXxXxXxX2”.  I’ve added the first part until the “/” to my endpoint address and the second part including the “/” I added to the controller mapping. Don’t forget to set “POST” as request command.

Apply all changes. Congratulations! You’re done with the invoker.

Test the SlackConnector

Let’s test our new web service. Create a new ticket and see if the invoker is triggered:

The output in the OTRS debugger should look like the following:

Because of the received JSON data from Slack, we should also see the message now in our Slack channel

More information about the Slack REST API

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

Please go to the following website, if you need more information: https://api.slack.com/web

The best thing is, that it’s also working with your web service operations which already exists in your STORM system.

If you have a STORM system, take a REST Client (e.g.: Boomerang) and send one the following JSON strings to your TicketCreate / TicketUpdate endpoint:

Example for TicketCreate with ArticleSend:

{
"Ticket": {
"Title": "Some ticket title",
"Queue": "<a valid queue name>",
"Lock": "unlock",
"Type": "<a valid ticket type>",
"State": "<a valid state e.g.: Incident>",
"Priority": "<a valid ticket priority e.g.: 3 normal>",
"Owner": "<a valid STORM user e.g.: root@localhost>",
"CustomerUser": "your@recipient.com"
},
"Article": {
"To": "your@recipient.com",
"ContentType": "text/html; charset=UTF8",
"CommunicationChannel": "Email",
"SenderType": "agent",
"Subject": "ArticleSend via REST",
"Body": "Some text send via REST",
"IsVisibleForCustomer": "1"
},
"UserLogin": "<Your_web_service_user>",
"Password": "<Password>"
}

Example for TicketUpdate with ArticleSend:

{
"Article": {
"To": "your@recipient.com",
"ContentType": "text/html; charset=UTF8",
"CommunicationChannel": "Email",
"SenderType": "agent",
"Subject": "ArticleSend via REST",
"Body": "Some text send via REST",
"IsVisibleForCustomer": "1"
},
"UserLogin": "<Your_web_service_user>",
"Password": "<Password>",
"TicketID": "<TicketID>",
}

I would really like to see your usecases, so please leave a comment.

One of the features of “STORM powered by OTRS” is the information floater which was described here. To display information, this information floater is sufficient, but what will happen if you have to work with these data in a (process) ticket?

In part 1 of this small blog article series, I will show you how to request additional information for a CVE from CIRCL. I’m calling this web service CIRCLCVEConnector.

I’m using “STORM powered by OTRS” with the OTRS Feature Add-On “OTRSTicketInvoker”.

In addition, we need some dynamic fields in OTRS:

• CVENumber – Text – used to specify the CVE number
• WSCVEID – Text – the received CVE ID from CIRCL
• WSCVESummary – TextArea – a short summary which is part of every CVE
• WSCVEReferences – TextArea – references for the CVE
• WSCVEVulnerableConfigurations – TextArea – vulnerable configurations for the CVE
• WSCVSS – Text – the CVSS score of the CVE
• WSCWE – Text – Common Weakness Enumeration of the CVE
• WSCapec – Text – Common Attach Pattern Enumeration and Classification for the CVE
• WSPacketStorm – TextArea – packetstormsecurity.com reference
• WSRefmap – TextArea – some more references
• WSPublished – Text – the date when the CVE was published
• WSModified – Text – the last modification date of the CVE
• WSAllCVEInformationReceived – Text – A trigger for a later use case ;-)

Configuring the CIRCLCVEConnector in STORM

As always we need a new web service in STORM. Call it “CIRCLCVEConnector”:

A new invoker is needed:

As you can see I removed everything, except the dynamic field “CVENumber” from my outgoing request data, because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

Incoming XSLT mapping:

Here’s the complete XSL stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:date="http://exslt.org/dates-and-times"
extension-element-prefixes="date">
<xsl:output method="xml" encoding="utf-8" indent="yes"/>
<xsl:variable name="id" select="//RootElement/id "/>
<xsl:variable name="summary" select="//RootElement/summary"/>
<xsl:variable name="references" select="//references"/>
<xsl:variable name="vulnerable_configurations" select="//vulnerable_configuration"/>
<xsl:variable name="cvss" select="//cvss"/>
<xsl:variable name="cwe" select="//cwe"/>
<xsl:variable name="capec" select="//capec"/>
<xsl:variable name="packetstorm" select="//packetstorm"/>
<xsl:variable name="refmap" select="//refmap"/>
<xsl:variable name="published" select="//RootElement/Published"/>
<xsl:variable name="modified" select="//RootElement/Modified"/>

<xsl:template match="RootElement">
<xsl:copy>
<Ticket>
<DynamicField>
<Name>WSCVEID</Name>
<Value><xsl:value-of select="$id"/></Value>
</DynamicField>
<xsl:choose>
<xsl:when test="$summary = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCVESummary</Name>
<Value><xsl:value-of select="$summary"/></Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$references = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCVEReferences</Name>
<Value>
<xsl:for-each select="$references">
<xsl:value-of select="."/><xsl:text>&#xA;</xsl:text></xsl:for-each></Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$vulnerable_configurations = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCVEVulnerableConfigurations</Name>
<Value>
<xsl:for-each select="$vulnerable_configurations">
<xsl:value-of select="id"/><xsl:text>&#xA;</xsl:text>
</xsl:for-each>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$cvss = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCVSS</Name>
<Value>
<xsl:value-of select="$cvss"/>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$cwe = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCWE</Name>
<Value>
<xsl:value-of select="$cwe"/>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$capec = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSCapec</Name>
<Value>
<xsl:for-each select="$capec">
<xsl:value-of select="name"/><xsl:text>&#xA;</xsl:text>
</xsl:for-each>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$capec = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSPacketStorm</Name>
<Value>
<xsl:for-each select="$packetstorm">
Title: <xsl:value-of select="title"/>
Source: <xsl:value-of select="data_source"/>
ID: <xsl:value-of select="id"/>
Last seen: <xsl:value-of select="last_seen"/>>
Published: <xsl:value-of select="published"/>
Reporter: <xsl:value-of select="reporter"/>
Source: <xsl:value-of select="source"/>
</xsl:for-each>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$refmap = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSRefmap</Name>
<Value>
<xsl:for-each select="refmap">
Title: <xsl:value-of select="title"/>
Source: <xsl:value-of select="data_source"/>
ID: <xsl:value-of select="id"/>
Last seen: <xsl:value-of select="last_seen"/>>
Published: <xsl:value-of select="published"/>
Reporter: <xsl:value-of select="reporter"/>
Source: <xsl:value-of select="source"/>
</xsl:for-each>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$published = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSPublished</Name>
<Value>
<xsl:value-of select="$published"/>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$modified = ''"></xsl:when>
<xsl:otherwise>
<DynamicField>
<Name>WSModified</Name>
<Value>
<xsl:value-of select="$modified"/>
</Value>
</DynamicField>
</xsl:otherwise>
</xsl:choose>
<DynamicField>
<Name>WSAllCVEInformationReceived</Name>
<Value>Yes</Value>
</DynamicField>
</Ticket>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

We should define the dynamic fields “WSCVEID, WSCVESummary, WSCVEReferences, WSCVEVulnerableConfigurations, WSCVSS, WSCWE, WSCapec, WSPacketStorm, WSRefmap, WSPublished, WSModified, WSAllCVEInformationReceived” as ticket dynamic fields in the web service, to store the CIRCLE CVE response. The last point for the invoker is the used event trigger. I’m using the event “TicketDynamicFieldUpdate_CVENumber”, because it makes most sense in my scenario:

Next point is to configure the network transport. It’s an easy job:

The used endpoint is “https://cve.circl.lu“, the controller mapping “/api/cve/:CVE” and the request method is “GET”. You’ll also find this information in the https://cve.circl.lu/api/.

Testing the CIRCLCVEConnector

Depending on your configured event trigger for the invoker, use a valid CVE number in the dynamic field “CVENumber”. You should now see something similar in the web service debug log:

In the ticket history, we can now see that the response values are stored in the dynamic fields:

More information about the CIRCL API

Please go to the following website, if you need more information: https://cve.circl.lu/api/.

In one of my recent projects, the team wanted to simplify their travel security process. An employee should start a process, where he has to specify to travel country and some other important values. Based on the travel country, OTRS should display possible travel security warnings, if there are some. We decided to use an external API to request information for the country the employee wants to travel. Until now they’re copying this information manually into STORM.

After some research, we decided that we want to use the API of https://www.reisewarnung.net for this use case.

There are no special pre-requirements regarding the API. So we don’t need an account or have to pay money to use this API.

My customer is using “STORM powered by OTRS” with the OTRS Feature Add-on “OTRSTicketInvoker”.

In addition, we need to add some dynamic fields in STORM to store the response data:

• Country – Dropdown – with ISO3166-1 compliant Alpha-2 country codes (see https://en.wikipedia.org/wiki/ISO_3166-1 for possible values)
• TravelRating – Text – to store the travel rating
• TravelLastUpdate – Text – to store the last update time (will be used in another use case)
• TravelCountryGerman – Text – to store the travel country in german
• TravelContinentGerman – Text – to store the continent in german
• TravelURLDetailsGerman – Text – to store an URL for additional information
• TravelAdviceGerman – Text – to store the travel advice in german
• TravelCountryEnglish – Text – to store the travel country in english
• TravelContinentEnglish – Text – to store the continent in english
• TravelURLDetailsEnglish – Text – to store an URL for additional information
• TravelAdviceEnglish – Text – to store the travel advice in english

Configuration of the new “STORM powered by OTRS” web service

As always we need a new web service in STORM. I call it “TravelSecurityConnector”:

Now we need a new invoker, to send requests to Reisewarnungen.net:

As you can see I removed everything, except the dynamic field “Country” from my outgoing request data because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

Incoming XSLT mapping:

Now you see, why we need so many dynamic fields. Every single value is stored in another dynamic field. It’s also possible to store this values into one dynamic field of type “TextArea”. The last point for the invoker is the used event trigger. I’m using the event “TicketDynamicFieldUpdate_Country” because it makes most sense in my scenario. In addition, we need to select the other dynamic fields (TravelRating, TravelLastUpdate, TravelCountryGerman, TravelContinentGerman, TravelURLDetailsGerman, TravelAdviceGerman, TravelCountryEnglish, TravelContinentEnglish, TravelURLDetailsEnglish, TravelAdviceEnglish) in the “ticket dynamic fields” dropdown to store the response data:

Next point is to configure the network transport. It’s an easy job:

The used endpoint is “https://www.reisewarnung.net”, the controller mapping “/api?country=:Country” and the request method is “GET”. You’ll also find this information in the Reisewarnungen.net API documentation.

Testing the TravelSecurityConnector

Depending on your configured event trigger for the invoker, use a valid IP address in the dynamic field “IPAddress”. You should now see something similar in the web service debug log:

I combined this connector with the “OTRSConnector“, which adds the travel security information to the ticket, I’m working with:

More information about the Reisewarnungen.net API

Please go to the following website, if you need more information: https://www.reisewarnung.net/en/about-the-api

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. Last time I wrote a blog article, where I described how to request information for an IP address from NeutrinoAPI. An additional use case, which I had to solve lately was to check the GEO coordinates of an IP address.

Highlighting GEO coordinates in the TicketZoom

The first action was to add an additional ZoomCollectMetaFilter which would match on GEO coordinates. Because the SysConfig structure has changed in  OTRS 6, the example Jens showed you in 2010 will not work, I had to create a new XML file in “Kernel/Config/Files/XML” called “Floater.xml” using the new SysConfig structure with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<otrs_config version="2.0" init="Framework">
<Setting Name="Ticket::Frontend::ZoomCollectMetaFilters###IP-GeoLocation" Required="0" Valid="0">
<Navigation>Frontend::Agent::View::TicketZoom</Navigation>
<Value>
<Hash>
<Item Key="RegExp">
<Array>
<Item>Long: s* ( [-]* d{1,3} . d{1,4} ) s* Lat: s* ([-]* d{1,3} . d{1,4} )</Item>
</Array>
</Item>
<Item Key="Meta">
<Hash>
<Item Key="Name">IP-GeoLocation</Item>
<Item Key="URL">https://maps.google.com/maps?q</Item>
<Item Key="URLPreview">geolocation.pl?coordinates</Item>
<Item Key="Target">_blank</Item>
</Hash>
</Item>
</Hash>
</Value>
</Setting>
</otrs_config>

After I added this XML  file to STORM, I had to run the following script as OTRS user:

bin/otrs.Console.pl Maint::Config::Rebuild

STORM will now show the found GPS coordinates in TicketZoom if the regular expression matches.

My PERL script

Now I can create my PERL script in “bin/cgi-bin” called geolocation.pl. I also attached the file at the end of this article:

Keep in mind, that this script has to be executable:
chmod +x bin/cgi-bin/geolocation.pl

Output

The Floater will now display the GPS coordinates in Google Maps. I also tried with OpenStreetMaps, but I faced some issues with the zoom within the floater.

I would really like to see your use cases and ideas to use the Information Floater of “STORM powered by OTRS“, so please leave a comment.

Geolocation.pl script

You can download my script here.

In this blog article, I’m extending the “OTRSConnector” and add a new invoker to this already existing web service.

Let’s start!

At first, we need a new invoker for the “OTRSConnector” like the one I’m using: “AddIPInformationToTicket”.

For our outgoing request data, it’s mandatory to use at least the TicketNumber and the dynamic field “IPAddressInformation”. All other fields are optional.

The next step is our XSLT mapping. As you can see, we add a new article to the ticket and use the content of the dynamic field “IPAddressInformation”:

The last point for the configuration of the invoker is the event trigger. From my point of view selecting the event “TicketDynamicFieldUpdate_IPAddressInformation” is the only one which makes sense.

The last part for this small change is to edit the transport configuration. We’re using the “TicketUpdate” operation for this use case.

From now on, the received IP address information from NeutrinoAPI, will be added as a new article to the related ticket.

In one of my recent projects, the team wanted to simplify their investigation activities. We decided to use an external API to request information for specific data we send. Until now they’re copying this information manually into STORM.

In part 1 of this small blog article series, I want to show you how to request additional information for an IP which triggered a security incident in an external system. Because I’m using the NeutrinoAPI, I’m calling this web service NeutrinoAPIConnector.

We have some pre-requirements:

1. Go to https://www.neutrinoapi.com/ and register a new account
2. Choose a plan. I’m using the “Free” plan for this example
3. Note your API key. You can also change it later if you’ve forgotten to note it.

My customer is using “STORM powered by OTRS” with the OTRS Feature Add-On “OTRSTicketInvoker”.

In addition, we need two dynamic fields in OTRS:

• IPAddress – Text – used to specify which IP should be checked
• IPAddressInformation – TextArea – to store the response of NeutrinoAPI

Configuring the NeutrinoAPIConnector in STORM

As always we need a new web service in STORM. Call it “NeutrinoAPIConnector”:

Now we need a new invoker, to send requests to NeutrinoAPI:

As you can see I removed everything, except the dynamic field “IPAddress” from my outgoing request data, because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

Incoming XSLT mapping:

We should define the dynamic field “IPAddressInformation” to store the NeutrinoAPI response. The last point for the invoker is the used event trigger. I’m using the event “TicketDynamicFieldUpdate_IPAddress” because it makes the most sense in my scenario:

Next point is to configure the network transport. It’s an easy job:

The used endpoint is “https://neutrinoapi.com”, the controller mapping “/ip-info” and the request method is “POST”. You’ll also find this information in the NeutrinoAPI API documentation.

Testing the NeutrinoAPIConnector

Depending on your configured event trigger for the invoker, use a valid IP address in the dynamic field “IPAddress”. You should now see something similar in the web service debug log:

In the ticket history, we can now see that the value was stored in the dynamic field “IPAddressInformation”:

More information about the Language Detection API

Please go to the following website, if you need more information: NeutrinoAPI API documentation.

Important note:

Keep in mind, the OTRS Blog should only show you the technical possibilities you have with OTRS, the OTRS API and other tools/services. Based on the new General Data Protection Regulation, which is enforced since may 2018, you should think about if you really need the gender of a person for your service management.

Last week I discovered another useful third-party provider, which makes it possible! The name of this provider is “Gender API“.

We have some pre-requirements before we can start:

1. Go to https://gender-api.com and register a new account
2. After registration you’ll receive 500 credits, but you can buy more
3. Note your API key. You can also find it in your Overview (at the end of the site)

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

Dynamic fields in OTRS

• Firstname – of type text – to store the firstname of the customer user
• Gender – of type text – to store the gender (response) from GenderAPI

Configuring the GenderAPIConnector in OTRS

As always we need a new web service in OTRS. Call it “GenderAPIConnector”:

Let’s continue with our invoker. The name for my invoker is “detectgender”. Because I want to reduce my payload, I’m only using the dynamic field “Firstname” in my outgoing request data. I also use “XSLT” for my outgoing an incoming mapping:

My outgoing XSLT mapping is the following:

Because the invoker will receive an answer immediately, we need a XSLT mapping for the incoming response data. You can use the following example:

The response should be stored in the dynamic field “Gender”. We also have to tell the invoker, when he should be triggered towards GenderAPI. Because of this I’m using the event “TicketDynamicFieldUpdate_Firstname”:

The last point for my first GenderAPI example is the configuration of the transport. Pay attention to the controller mapping, because GenderAPI is expecting everything as query params (also the API key). The valid request method for this controller is GET. If you do the same than I did, it should work as expected.

That’s all for this invoker. Let’s start our tests.

Testing the GenderAPIConnector

Depending on your configured event trigger for the invoker, please create a new ticket or (as I’m doing) lock the ticket to yourself. You should now see something similiar in the web service debug log:

In the ticket history of the specific ticket we now see the value for the gender:

What can we now do with this information? I’ll show you next time.

More information about the Gender API

Please go to the following website, if you need more information: https://gender-api.com/en/api-docs

So let’s create them!

Go to Admin -> Ticket Notifications and a add a new notification with the following configuration:

We have to listen to the event “TicketDynamicFieldUpdate_Language,” because we want to inform the customer in his language.

This notification should only be sent if the language is German.

We only want to inform the customer user.

Last but not least, the notification text.

Finally, we can do some tests. Write an email in German to your OTRS. You should receive the German notification.

After looking for ways to improve the situation, we decided to slightly change the default behavior of the package manager. By default, only packages verified by OTRS can be installed now; there is a new configuration option to allow installation of packages from other/untrusted sources.

Last week I discovered a useful third-party provider, which makes it possible! The name of this provider is “Language Detection API“.

We have some pre-requirements:

1. Go to https://www.detectlanguage.com and register a new account
2. Choose a plan. I’m using the “Free” plan for this example
3. Note your API key. You can also find it in your Dashboard

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

Configuring the LanguageConnector in OTRS

As always we need a new web service in OTRS. Call it “LanguageConnector”:

Now we need a new invoker, to send requests to Language Detection:

As you can see I removed everything, except the article body from my outgoing request data, because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

Incoming XSLT mapping:

The last point for the invoker is the used event trigger. For testing purposes I’m using “TicketLockUpdate”, but using “TicketCreate” event makes more sense in productive environments:

Next point is to configure the network transport. It’s an easy job:

As written in Language Detection API, you can use your API key as username and a password which can be empty or any value.

Let’s continue with our tests.

Testing the LanguageConnector

Depending on your configured event trigger for the invoker, please create a new ticket or (as I’m doing) lock the ticket to yourself. You should now see something similar in the web service debug log:

In the ticket history, we can now see that the value was stored in the dynamic field “Language”:

More information about the Language Detection API

Please go to the following website, if you need more information: https://detectlanguage.com/documentation

The first step is to create an account for the Threema Gateway (https://gateway.threema.ch/en).

Afterward you must request a new Threema ID. Pay attention because there are two types of Threema IDs:

• Basic
  • The private key will be generated and stored by Threema
  • Messages can be sent
  • Messages cannot be received
• End-to-End
  • The private key will be generated and stored by the customer
  • Messages can be sent and received, including delivery reports (delivered, read, acknowledged).

In this blog article, I’m using the Basic Threema ID.  Later I’ll also show you how to receive Threema messages in OTRS. :-)

After you registered your Threema ID and received your confirmation email, we can start with our ThreemaConnector in OTRS. As usual, there are some requirements:

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

Configure the ThreemaConnector in OTRS

Now we can start to configure our ThreemaConnector. The first task is to create a new web service in OTRS.

Now we can continue with our invoker(s). I’m saying invokers because we need one invoker per recipient.

Let’s start with the configuration for the invoker “NotifyViaThreema”:

The most important part is the XSLT mapping and the event trigger for this invoker. You can use my XSLT mapping:

Because I don’t want to send a message every time when a ticket is created, I define a condition for this invoker:

The last step is the configuration of the network transport. The Threema API is expecting everything as parameters. Because of this, we have to work with variables:

That’s all! Now we’re ready to start with our tests. At first we need a new ticket with a priority = 5 very high (my condition for the invoker).

After ticket creation, we should receive a Threema message. As an alternative we can also check the debug logs of our web service:

And on the recipient’s cell phone:

It wouldn’t be enough to just put a new design on the existing structures.

With the new design of the OTRS 7 customer interface (which will then be the “external interface”, combining both public and non-public interface into one), we’re going to implement a design process. This process is meant to make sure that we’re not only creating a one-time redesign, but know how we can proceed from there. Whenever we’re in the need of creating new features/screens/components within OTRS, this process will come into play. It consists of 5 basic elements:

1. Understand: Understand the context in which the feature/product is used.
2. Specify: Specify the requirements.
3. Solve: Develop solutions which fulfill those requirements.
4. Listen: Collect user feedback for the solutions.
5. Iterate: begin with the first step again to improve the solution.

All future design decisions will be driven and backed up by this process. It will be supported by a library of design elements (which we call “design system”), so the process will not only be applied to the redesign of the GUI as a whole, but also to the creation and evolution of each single GUI component. This OTRS Design System will be the leading resource for OTRS designers and developers.

The answer is… YES!

In the first part of a smaller blog article series, I’ll show you how to post messages in Rocket.Chat channels.

Like in former blog posts, there are several requirements for this HowTo:

• running OTRS 6.0.x system
• running RocketChat system

OTRS Requirements for this HowTo:

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-on:

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

Rocket.Chat Requirements for this HowTo:

• a working Rocket.Chat (I’m using RocketChat 0.64.1)

Prepare Rocket.Chat for the integration

Go to Administration -> Integration and click on “New integration” in the right upper corner and click on “Incoming WebHook”

I’ve attached the configuration of my webhook:

If you want, you can send the example JSON string to your incoming webhook with a local REST client. I’m using “Boomerang” which is an addon for Google Chrome.

The answer is a simple “success”: true

That’s all regarding the Rocket.Chat preparation. Let’s continue with OTRS.

Configuring the Rocket.ChatConnector on OTRS side

At first, we’ve to create a new web service. I’ll call it “Rocket.ChatConnector”.

Afterwards, we need a new invoker. Attached you’ll find my config:

The most important part is the XSLT mapping. The following example is tested and working:

The last part for the invoker is the used event trigger. Because I only want to inform my users if there’s a new ticket with a very high priority, I’m using the “TicketCreate” event with a condition (Priority = 5 very high):

That’s all for the invoker configuration. The next part is the configuration of the transport. I’m using a small workaround to make the integration possible. My token in Rocket.Chat is “9HHhoQYYEo2unZQrm/e4tWQgxcKkZdryfcMA325unkNrC2R6JPSmJXtuknhbQ4TYZh”.  I’ve added the first part until the “/” to my endpoint address and the second part including the “/” I’ve added to the controller mapping. Don’t forget to set “POST” as request command.

Apply all changes. Congratulations! You’re done with the first part.

Testing the Rocket.ChatConnector

Let’s test our new web service. Create a new ticket with a priority = 5 very high and see if the invoker is triggered:

The output in the OTRS debugger should look like the following:

Because of the received JSON data from Rocket.Chat, we should also see the message now in our RocketChat channel

More information about the Rocket.Chat REST API

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

Please go to the following website, if you need more information: https://rocket.chat/docs/developer-guides/rest-api/

Use case for this connector

If you have a Release & Deployment management process in your OTRS system and you want to transmit information automatical to Icinga2. In this small blog article, I’ll show you, how to create a web service between OTRS and Icinga2. I’ll call this integration “Icinga2Connector”.

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following Feature Add-Ons :

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

DynamicField

• “Icinga2Hostname” of type “TEXT” to specify the name of the new Icinga2 host
• “Icinga2DeleteHost” of type “Dropdown” to make a decision

Web service

In addition, part 1 & part  2 of the Icinga2Connector might be useful. You’ll find the first blog article here and the second blog article here.

Configuring the Invoker “DeleteHost”

Now we’re ready to start the configuration of our next Invoker. Create a new Invoker called “DeleteHost”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing data.

For our XSLT mapping we need the following elements:

• the hostname, which should be deleted in Icinga2 (dynamic field “Icinga2Hostname”)

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

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

Configuring the Icinga2Connector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the invoker because we’ve to use the right requests commands towards Icinga2. Otherwise, we’ll receive errors. It’s quite easy as you can see:

As authentication module please use HTTP basic auth and fill in the user credentials of the Icinga2 API user. Afterward just click on “Save and finish”.

Testing the Icinga2Connector

Testing the Requester

Create or take an already existing ticket and trigger the “DeleteHost” invoker. In the Icinga2 WebGUI, the host disappears. ;-)

More information about the Icinga2 API

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

Please go to the following website, if you need more information: https://www.icinga.com/docs/icinga2/latest/doc/12-icinga2-api/

Use case for this connector

If you have a Release & Deployment management process in your OTRS system and you want to transmit information automatical to Icinga2. In this small blog article, I’ll show you, how to create a web service between OTRS and Icinga2. I’ll call this integration “Icinga2Connector”.

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

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

• OTRSTicketInvoker

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

Third Party Software

You need this third-party software:

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

DynamicFields

• “Icinga2Hostname” of type “TEXT” to specify the name of the new Icinga2 host
• “Icinga2Address” of type “TEXT” to specify the login of the new user
• “Icinga2Command” of type “Dropdown” to specify the check command in Icinga2. Please use the following values:
  • hostalive: hostalive
  • http: http
  • ping4: ping4
• “Icinga2OS” of type “Dropdown” to specify the Host OS. Use the following values:
  • Linux: Linux
  • Windows: Windows

Web service

In addition, part 1 of the Icinga2Connector might be useful. You’ll find the first blog article here.

Configuring the Invoker “UpdateHost”

Now we’re ready to start the configuration of our next Invoker. Create a new Invoker called “UpdateHost”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing data.

For our XSLT mapping we need the following elements:

• the hostname, which should be displayed in Icinga2 (dynamic field “Icinga2Hostname”)
• the IP address of the new host (dynamic field “Icinga2Address”)
• the used Icinga check (dynamic field “Icinga2Command”)
• the OS of the Host (dynamic field “Icinga2OS”)

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

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

Configuring the Icinga2Connector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the invoker because we’ve to use the right requests commands towards Icinga2. Otherwise, we’ll receive errors. It’s quite easy as you can see:

As authentication module please use HTTP basic auth and fill in the user credentials of the Icinga2 API user. Afterward just click on “Save and finish”.

Testing the Icinga2Connector

Testing the Requester

Create or take an already existing ticket and trigger the “UpdateHost” invoker.

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

In Icinga2 a the host is updated:

Stay tuned…

Next time I’ll show you other useful examples how you could integrate OTRS with Icinga2.

More information about the Icinga2 API

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

Please go to the following website, if you need more information: https://www.icinga.com/docs/icinga2/latest/doc/12-icinga2-api/