GGUS:Ticketing System Recommendation FAQ

GGUS wiki / GGUS FAQ / GGUS Documentation / GGUS Helpdesk

---

GGUS ticketing system recommendations

Updated

2011-10-12

Purpose

This document provides a technical description on how to interface any other ticketing system with GGUS. It describes the interface of choice and gives some examples for tools that can be used to reach this goal. It does not give a description of the things to be done on management level before implementing an interface to GGUS. As the things to be done on management level are currently not documented please submit a [ticket] or add your request for interfacing GGUS system to the GGUS shopping list at https://rt.egi.eu/rt/Dashboards/2636/GGUS-Requirements. The GGUS shopping list is a RT queue for collecting and discussing change requests for GGUS system.

Current situation

In the past many interfaces of GGUS to other systems have been implemented. Each of them was unique in its kind. They can be classified into three different groups:

• Interfaces based on email for both communication directions, from GGUS to the remote system and from the remote system to GGUS.
• Interfaces based on email for communication from GGUS to the remote system and on web services for communications from the remote system to GGUS
• Interfaces based on web services for both communication directions, from GGUS to the remote system and from the remote system to GGUS.

The goal of GGUS is to reduce the number of different interfaces for reducing complexity and maintenance effort in the system.

Interfaces based on email exchange

Email interfaces can be set up rather quick as the necessary infrastructure (mail servers etc.) is already available and ticketing tools are usually able to create and send emails. Using mail templates seems to be no problem. The receiving system of the emails has to parse the incoming mails for either adding the content to an existing ticket or creating a new one. To ease parsing the mails have to stick to an agreed format. Email exchange is sometimes not as reliable as necessary. Delays in email transmission or loss of emails can disturb the synchronization between the ticketing systems and confuse people. Manual interventions are necessary to synchronize the different ticketing systems again.

Interfaces based on SOAP web services

Web service interfaces are very reliable. The ticketing systems are synchronized permanently. Failing web services throw an error message at once. So the user gets notified about it. Most of the ticketing tools mentioned in the chapter #Tools don't provide web services out of the box. Some implementation work is needed for a web service interface.

System recommendations

Regarding the advantages and disadvantages described in chapter #Current situation an email interface can be set up rather quick but is not that reliable. SAOP web services are very reliable but need some implementation work. However the goal of GGUS is to avoid setting up new email interfaces and to replace existing ones. If setting up a new ticketing system GGUS recommends using a ticketing tool which allows the implementation of SOAP web services. RT is an example for such a tool.

Tools

The GGUS system is based on BMC Remedy Action Request System (ARS). Remedy ARS is able to provide SOAP web services as well as to consume SOAP web services. So data transfer can be done by SOAP web services in both directions. For interfacing a ticketing system with GGUS a couple of tools are available. Tools which are already interfaced in production are:

• Xoops/Xhelp,
• OneOrZero ,
• Footprints and
• RequestTracker(RT).

Xoops/Xhelp

Xoops is used for the Italian (NGI_IT) ticketing system. The SOAP web services have to be implemented additionally. More information about xoops is available at http://sourceforge.net/projects/xoops.

Footprints

The footprints ticketing system is used by the OSG in the US. The SOAP web services have to be implemented additionally. More information is available at http://www.numarasoftware.com/footprints/.

Request Tracker(RT)

There are several web service interfaces between GGUS and RT instances using SOAP web services. They are in production mode since over a year and are working properly. The implementation of the web service interface in RT is described at https://wiki.egi.eu/wiki/GGUSRT:GGUS-RT_Interface_Task_Force. Further information is also available at http://bestpractical.com/rt/.

SOAP web services provided by OneOrZero

Information on OneOrZero is available at http://www.oneorzero.com/.

Web services provided by GGUS system

The web services provided by GGUS system offer four different operations for

• creating a new ticket (OpCreate),
• modifying an existing ticket (TicketModify),
• getting data of one existing ticket (TicketGet) and
• getting a list of existing tickets (OpGetList).

These operations can be used for retrieving and modifying data in GGUS system. A detailed description of all the fields and their meaning is given in file “Mappings_for_GGUS_webservices.pdf” which can be obtained from the GGUS team.

Examples and documentation

Examples of interfaces in production are available for tools based on PHP and Perl. They can be found at https://wiki.egi.eu/wiki/Category:FAQ_Interfaces_%28GGUS%29. There is also information about available tools used for help desk systems to be interfaces with GGUS system on this page.

Developing and testing

For developing and testing an interface to GGUS a test and training system is available. This system is a copy of the production system. The WSDL-file for the web services provided for this test and training system can be found at http://train-ars.ggus.eu/arsys/WSDL/public/train-ars/Grid_HelpDesk. For further information please contact the GGUS team.

What if I have questions which are not dealt with by this FAQ?

Open a GGUS ticket

indicating that it should be directed at the GGUS team.

Search

• Please use this link to search inside the GGUS FAQ