Automatically detect the gender of your customer user

Robert Ullrich21. Jun 2018 | Best PracticesCase studyConsultingUse cases

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

• 0