Ticket Flow Between ROC and Local User Support

Ticket Flow between ROC and Local User Support

Implementation Concept Draft

JO 2005-2-14

Abstract

This document describes how is possible to handle solution

of tickets whose coudn't be solved without help of any other site.

Ticket comes from Global Grid User Support (GGUS) into ROC or can

come from Local Support site (LS) to given appropriate ROC. The document

shows how a ROC could solve it or forward it to furher supporters (and

vice versa) and how to manage to let all participants be informed about

ticket solution.

Case Study

1. Ticket is submitted by GGUS to ROC

a) Ticket is solved directly at ROC

b) Ticket can't be solved at ROC

c) Ticket should be solved by a LS

d) Ticket should be solved by more than one LS

2. Ticket is submitted by User to LS (or ROC)

a) Ticket should be solved by ROC (or within its another LS)

b) Ticket should go to GGUS => be solved by other ROC (its LS)

3. Ticket is submitted by LS

Suggested ticket flow in given cases:

1a)

(pseudo) on-line scenario:

i] GGUS sends a .xml formatted e-mail into ROC with GGUS ticket Id

ii] ROC creates a ticket with its local ticket Id and saves GGUS ticket Id

iii] ROC support stuff accepts its responsibility for solving of the ticket

and send back the local ticket Id

iv] support stuff solves given problem and replies the solution (history)

onto GGUS identified by GGUS ticket Id via defined interface

v] GGUS acknowledges/accepts the solution and local ticket is closed too

off-line scenario:

i] GGUS sends an e-mail into ROC mailing list

(i.e. at )

ii] a ROC supporter logs into GGUS Web site and solves given ticket directly

iii] GGUS sends notification about this into given ROC mailing list

1b)

(pseudo) on-line scenario:

i] GGUS sends a .xml formatted e-mail into ROC with GGUS ticket Id

ii] ROC creates a ticket with its local ticket Id and saves GGUS ticket Id

iii] ROC support staff refusesits responsibility and sends back

a notification reply about it

iv] GGUS replyies with acknowledge of service refuse and local ticket is closed.

off-line scenario:

i] GGUS sends an e-mail into ROC mailing list

(i.e. at )

ii] a ROC supporter logs into GGUS Web site and modifies the responsible group

of ticket (re-assignes) directly

iii] GGUS sends notification about this into given ROC mailing list

1c)

(pseudo) on-line scenario:

i] GGUS sends a .xml formatted e-mail into ROC with GGUS ticket Id

ii] ROC creates a ticket with its local ticket Id and saves GGUS ticket Id

iii] ROC support stuff accepts its responsibility for solving of the ticket

and send back the local ticket Id

iv] support staff assignes given problem to the problem specific LS

identified by ROC's local ticket Id. This operation sends a .xml formatted

e-mail into specific LS

v] LS creates a local ticket with its LS's local ticket Id and savesROC's ticket Id (all actual ticket history is being sent too)

vi] LS accepts its responsibility for solving of the ticket

and send back theLS's ticket Id

vii] ROC acknowledges LS's ticket Id and optionally sends ongoing ticket

history/diary created meanwhile

viii] Now tickets are fully linked and any modification done by LS stuff

are being send do ROC or modification made at ROC are being send do LS

ix] Ticket status change (i.e. close) at LS are reported to ROC. ROC will close

its own linked ticket by its representative staff (not automaticaly). Possible

further communication from ROC will re-open the ticket at LS too.

off-line scenario:

supporters at ROC will probably lost in amount of tickets links needed

to be handled by hand

1d)

(pseudo) on-line scenario:

i] GGUS sends a .xml formatted e-mail into ROC with GGUS ticket Id

ii] ROC creates a ticket with its local ticket Id and saves GGUS ticket Id

iii] ROC support stuff accepts its responsibility for solving of the ticket

and send back the local ticket Id

iv] support staff assignes given problem to the problem specific LS

identified by ROC's local ticket Id. This operation sends a .xml formatted

e-mail into specific LS

v] LS creates a local ticket with its LS's local ticket Id and saves

ROC's ticket Id (all actual ticket history is being sent too)

vi] LS accepts its responsibility for solving of the ticket

and send back theLS's ticket Id

vii] ROC acknowledges LS's ticket Id and optionally sends ongoing ticket

history/diary created meanwhile

viii] Now tickets are fully linked and any modification done by LS stuff

are being send do ROC or modification made at ROC are being send do LS;

LS decide, that they need to solve the ticket with other LS2 staff and

sends this update/request to ROC ROC's ticket Id

ix] ROC assignes (adds) given ticket to LS2 (ROC ticket has fields for more than

one LS ticket Id and LS identifies) by similar steps (iv..viii) above with LS2

x] Now any replies (or state update informations) from LS2 go to ROC and ROC

resents these into LS and vice versa.

xi] Information about resolved ticket is at the end sent by ROC staff

into GGUS via defined interface (WebServices/Perl-SOAP or .xml

formatted e-mail)

off-line scenario:

supporters at ROC will probably lost in amount of tickets links needed

to be handled by hand

2a)

(pseudo) on-line scenario:

i] User enters his request/ticket in english language - the user is

already registered via Web (LS gets his valid e-mail, Real Name etc.)

or is autoregistered via e-mail (depending on kind of his ticket

submission)

ii] LS sends via e-mail an autoreply with LS's ticket Id to user (used for

further user replies to go to the ticket history or further) and notifies

specifis LS support staff group

iii] LS staff decides that help from ROC or above (means GGUS) is needed,

iv] LS sends a .xml formatted e-mail (containing actual ticket history)

into ROC with LS's ticket Id

v] ROC creates its new ticket with ROC's ticket Id and confirms that

into LS by sending it.

vi] LS acknowledges saving of ROC's ticket Id and optionally sends ongoing

ticket history/diary created meanwhile

vii] Now are tickets fully linked and any history updates could be interchanged

(that means ROC could linked with others Lss too as in the case 1d above);

Replies from another LS or ROC are there propagated via LS to the end user

2b)

(pseudo) on-line scenario:

Steps i..vii are similar or same (If user do can not contact GGUS directly

without using his LS)

viii] When ROC staff decides to get help from GGUS then it creates via

defined interface new GGUS ticket linked into ROC's ticket Id and saves

GGUS's ticket Id

ix] Further replies from user are automaticaly (or could be moderated)

forwarded from ROC into GGUS and vice versa (unaltered)

3) Ticket is submitted by LS

Steps are same as 2b, because only ROC is a valid contact to GGUS so

LS replies are on same level as user replies.

Comments

Uses is known registered only at him contacted place and from his point of view

communicate only with this place. Contacted place means his support web portal

e-mail contact (in case of direct GGUS support contact, there is maybe possibility

to be contacted back directly from ROC supporters, but their address should

be same...we hope)

There could be set up an internal support policy defining internal communication

between support centers which shall never go to the end user (in Request Tracker

called as Comments, common communication with users are called Replies)