• Inok Systems

Integration between two ticketing systems

會員評等:  / 0

Integration is a common requirement in several of our Inoks’ Projects. Regional implementations in particular, where some countries might be using different ITSM tools to run their business. Without integration between them, the management will not be able to view a holistic report. Agents will also need to login to different systems when cross country tickets are created. So how do can we integrate with other ITSM tools?

 Here are the 4 general methods of integration that we can implement:

 1. Email Integration

Many ITSM tools out there allow email monitoring and with a pre-defined format of the email, you can perform create/update ticket functions. This is the simplest method of integration between 2 ticketing systems by just setting up the outgoing email templates and incoming email rules. Although cost effective, you are actually relying on the email services in-between the two systems. It will complicate troubleshooting when an email is lost or a ticket went missing. The ticket sync might not happen real time as well, depending on the email check frequency of your application.

 Pros: Cheap, fastest to deploy, least security concern (relies on email security)

Cons: Additional breaking point in the situation that email is down, maintenance on the email disk space, adds email traffic.


2. DB Integration

Ticket data must be stored in a DB in almost all of the ITSM tools. When a ticket is created, it will insert a record in the DB. In this method of integration, we can make use of "stored procedures" and "triggers" on the DB level. This method doesn’t require anything on the application level. A script will be triggered when a record is inserted/updated. This script will then update the DB on the other ITSM tool. Ports like 1433 needs to be opened on the network side between the 2 DBs, but compared to email integration, this is much more reliable and happens within afew seconds. That being said, it is not easy to implement this integration as we will need the software vendors on both sides to work together to understand the DB Schema on each ends.


Pros: Real time, just a DB connection port to be opened on the firewall, fast transaction.

Cons: Time consuming to implement, deep technical understanding of the DB is required.


3. Web services Integration

Most popular integration method which makes use of web services within both applications. We can write simple scripts that will call the web service on either side for create/update ticket functions. Real time updates, only require port 80 to be opened. Mature products in the market now already have documentations on their web services and simple to implement.


Pros: Real time, port 80 between both applications, easy to troubleshoot.

Cons: Time consuming for both sides to understand the web services to call and variables to pass over.


4. Excel file import

If real-time updates are not required, some itsm tools allow excel file imports on the tickets. We can setup the source app to generate an excel report every end of the day which will be picked up by the destination app. The records in the file will then be imported as tickets in the destination app. Field mapping rules will still need to be configured during the import.


Pros: Easy to implement, cheap and meets the requirements. Easy to understand and troubleshoot.

Cons: not real time, occurs only end of the day to sync up the 2 tools. Relies on the native import/export feature of both tools.

Random Blogpost

Let’s first take a look at the definitions in ITIL:

Call (Service Operation): A telephone call to the Service Desk from a User. A Call could result in an Incident or a Service Request being logged.

Incident (Service Operation): An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.