I think everyone of you have asked yourself the question if it’s possible to automatically dispatch tickets into language-specific queues. This might be useful if you have location-based sales departments/support departments a.s.o. So keep on reading, because I want to show you how to build such a “LanguageConnector”. In part 1 of this small blog article series, I want to show you how to set up the web service. If you’re looking for part 2, you can find it here.

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 post Automatically Detect the Language of Emails appeared first on The OTRS Blog.

Let’s continue with our use case from last week. In part 1 we build the pre-requirement for this web service. For sure this can also be realised with another OTRS built-in functionality called GenericAgent, but do you really want to build one GenericAgent per language? Because I really want to avoid this I’m using the OTRSConnector. This has several benefits:

1. The administration is much easier
2. A possible performance impact is much lower

So let’s start!

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 provider for the OTRSConnector

As usual the general configuration should look like the following:

In our new web service we need a provider and a requester (invoker). Let’s start with the provider, because it’s the easier one. Add a new operation “Ticket::TicketUpdate” and simply call it “TicketUpdate”. We don’t need an incoming mapping.

The last point for the provider part is the configuration of the network transport. Define a valid route mapping and a request method for the provider.

That’s all for the provider side. Let’s continue with our invoker!

Configuring the invoker for the OTRSConnector

Now we’ll configure the “magic”. Create a new invoker of type “Ticket::TicketUpdate” and include at least the TicketNumber and the dynamic field “Language” in your outgoing request data:

For our outgoing XSLT mapping, you can use my example:

The last part is the used event trigger. I want to trigger my invoker, if the dynamic field “Language” is udpated:

The last part is the configuration of the network transport. The most important here is the controller mapping, because this needs to be the same as in the configuration of our provider. Otherwise you’ll receive errors.

Testing the OTRSConnector

Depending on your configured event trigger for the invoker, please trigger at first the LanguageConnector and wait until the dynamic field “Language” is populated. You should now see something similiar in the web service debug log:

You’ll now see in the ticket history, that the queue was changed by our webservice user:

More information about the OTRS  API

Please go to the following website, if you need more information: http://doc.otrs.com/doc/api/otrs/stable/Perl/Kernel/GenericInterface/Operation/Ticket/TicketUpdate.pm.html

The post Event based ticket movement via web service appeared first on The OTRS Blog.

I think everyone of you have asked yourself the question (especially the german OTRS administrators), if it’s possible to automatically detect the gender of your customer users. This might be useful if the gender is missing in your customer user backend or someone is writing you an email, who is not stored in your backend. So keep on reading, because I want to show you how to build such a “GenderAPIConnector”. In part 1 of this small blog article series I want to show you how to set up the web service to automatically check the gender of the sender.

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

The post Automatically detect the gender of your customer user appeared first on The OTRS Blog.

One of the features of “STORM powered by OTRS” 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 having to add static content to it. The main use case is to give security teams valuable information at a glance without the need to lookup the information in a separate 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. Last time I wrote a blog article, where I described how to request information for a IP address from NeutrinoAPI. An additional use case, which I had to solve lately was to check the GEO coordinates of a 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.

The post Displaying GEO coordinates via Information Floater appeared first on The OTRS Blog.

“STORM powered by OTRS” is used in security departments and companies for long time due to the well documented code of OTRS and a huge background in the CERT area.

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

The post Use travel security information in your travel processes appeared first on The OTRS Blog.

The Back Story

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.

The post Conform to international standards; use OTRS for Process Management appeared first on The OTRS Blog.

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.

The post You can delegate authority but not accountability. appeared first on The OTRS Blog.

In life, preparation is everything. When preparing to automate (orchastrate) tasks in OTRS, the main work is not in programming the process module to do what you desire, but in the preparation. With good preparation designing processes to be use with OTRS is a breeze. Here are the 10 Steps to Process Design Preparation for OTRS Process Management.

Let’s take an 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. 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 collecting the data, or record collection.
5. Identify triggers for optional and immediate advancement to 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 pathing (i.e. escalation to 2^nd after workaround failure) paths.
   Do we have multiple escalation paths?
   
8. Set workflow requirements
   Consult the requirements of L2 or other departments where escalation is possible.
   
9. Identify loop-back possibilities
   Under which circumstances can request boomerang and why?
   
10. Draw the process ( i.e. with a tool like https://bpmn.io)
    

The post 10 Steps to Process Design Preparation for OTRS Process Management. appeared first on The OTRS Blog.