Various support centers and virtual organizations inside OSG uses various ticketing systems. For example, GOC uses Footprints ticket system as a backend ticketing system. BNL uses RT. Fermilab uses Remedy.
When GOC receives a ticket, it often redirects the ticket to responsible support centers by forwarding the ticket using an email interface that each ticketing system provides.
GOC monitors progress made on destination ticketing system and make sure that the issue is worked on.
Since TX (Ticket Exchange) happens via sending email between GOC's footprints and the destination (or source) ticketing system. Email based TX is very unreliable since often the recipient of the emails parses the ticket to pull necessary information and this tends to break easily when slightest changes in the email format occurs. This also makes it harder for both parties to make any necessary improvements or upgrades to the ticketing system without worrying about breaking other party's TX.
Since the TX updates are usually by-directional, we often encounters ticket-looping when a ticketing system send out "Thank you for your update" type emails to the sender. We must keep maintaining special logics to prevent this looping based on source email address, message format, etc.. which tends to change more frequently than we wish.
GOC's TX was not designed from ground up and it consists of a collection of various scripts that are harder to maintain and scattered around in our systems in various programming languages.
Due to each ticketing systems not being aware of if other system has already sent out notification to who, our customer often receive 4, 5 emails per any ticket updates due to various support center involves with each sending out update notifications. This creates low signal to noise ratio which causes end users to miss important ticket updates.
When there is any issue in any part of the system involved, there is no way to get notified of such issues. Problems are usually discovered days after the initial issue has occurred.
Each ticketing system will use a special email address such as firstname.lastname@example.org with a subject line containing the source ticket ID to be synchronized (only the destination address and email header will be used). The email extension tells source / destination ticketing system and in this example, GOC-TX will pull current ticket information from GOC ticketing system, and post it to FNAL ticketing system using the best interface available for each ticketing system (usually SOAP. RT uses RESTful interface).
Using email for trigger allows various support centers to start using GOC-TX very easily - usually involving a simple email address update to one of there assignee.
Since GOC-TX is a centralized service, various ticketing system can start using our service to exchange ticket directly to one another without going through GOC. We currently have no such implementation, but we will be able to do this with simple configuration change.
When GOC-TX receives a trigger, first it tries to find if the source ticket has destination ticket ID. It will then pull the current source ticket timestamp and compare it to when the last synchronization has occurred. If the timestamp is the same, then synchronization will be aborted. This mechanism eliminates what we previously experienced as ticket looping. It also allows ticketing system to not having to worry too many triggers. They can send us triggers as many and frequently as they want and we will only synchronize when it's necessary.
We also check to see if there is a updates that was *missed* to be synchronized since previous trigger. This happens if someone updates a ticket before the trigger email was sent or processed by GOC-TX. Multiple updates will be grouped together and inserted to all destination ticketing system.
We also handle "cross-update" issue. This issue occurs when destination ticket was updated before synchronization from source ticket was performed. GOC-TX checks both source and destination ticket timestamp and handles by-directional update in this case.
GOC-TX can exchange tickets that are linked with more than 1 support centers. A single ticket can have N number of TX destinations and if any one of those support center updates the ticket linked, it will eventually synchronize the entire cluster of the tickets.
GOC-TX is implemented with OO and latest design pattern principles. It uses generic synchronization logic which was tested and common to all ticket exchanges, it can also extend its capability and allows custom logics for specific source / destination combination that are necessary to meet various ticketing system specific features. For example, BNL has requested us not to reset status from "new" to "open" if source ticket status is "open". They want to do the transition from "new" to "open" by themselves and both status are seen as "open" to other ticketing system.
We designed and implemented GOC-TX so that we can open source this application to other communities which shares similar circumstances as ours - having to exchange / synchronize tickets with diverse ticketing systems.
Please see http://docs.google.com/View?id=ddtgc5bt_205dz6998d4 for the latest design doc.
GGUS(Documentation has not been requested)Footprint(Documentation has not been requested)