ShariX Open Docs

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== Common Ticket Lifetime =====

  - One or several tickets might be created as a result of system events. Ticket is an instance in the database.
  - Ticket creator - a man or a system whose moves results in the ticket appearance.
  - Ticket can’t be automatically assigned to anybody. Tickets could be assigned to a group role so anyone in this group will get an acceptance notification (it might be repeated few times by service bots). If nobody accept a ticket then after period of time ticket creator got timeout out of service message.
  - Each ticket has its lifetime. Any step got monitored by a bots-services that can change the step (change ticket status and send notification to next step bot) or proceed an order the other way. Each service may result in adding new tickets with their own lifetime. Everything should be done by service bots using platform Web API, Metaservice Web API or other APIs.
  - The Idea for the bot-services moves is to make all the tickets done as soon as possible.
  - Each Metaservice has a standard set of bot-services connected to an order. Service settings (like waiting time, etc) could be adjusted in the Metaservice settings (Service settings inside administration panel - 2 parameters for each ticket type - lifetime and notification frequency).

How status codes could be stored:
<code>[[1,2],[2,3],[3,4,5]]</code>
First number is current state, others is possible next states for a ticket, second number - normal positive solution. Each state is written as a code. Codes descriptions stored in a table for Web API use.

Normally service should provide a bot that transfers ticket from current state to the next normal one. If that’s not possible it tries to process to another state if available. If that can’t be done - it keeps the current state and makes an error ticket to the group that is responsible for that process to proceed manually. Usually that means that the code running and the database doesn’t match (e.g. because of the update).

After ticket got closed, it’s stored the time specified in the service settings, then deleted or archieved.

Each bot-service operates the following way:
  - Periodically checks tickets it is responsible for. Each period of time sends notifications for unclosed ones. Executes ticket process for for missed ones.
  - Listens for notifications for the new tickets send by other bot-services. Executes base ticket process for all incoming tickets.
  - After a specified period of time creates an error message is the ticket remains in its list.
  - Listens to all the events for the current ticket state.
  - Changes the state for a ticket if needed. Sends notification for the next bot-service.

Each bot-service is named the following name: <code>$metaservice-$ticket_type_name-$state_code-$state_name</code>
Names needed to make code readable for programmers.

All bot-services should be running on the server all the time and restarted if needed. There should be a process that checks if all the bots-services are running using data from the database. Zabbix should monitor this process.

After restart process bot does 1 step before any other operations.

All bot-services should be multithreaded.

==== Common functions for bot-services ====
  - proceed_ticket(ticket_number) - name of the main function of the bot-service. For different types of tickets and services could consist of different operations. In the end function add_ticket_to_proceeded_list should be called.
  - add_ticket_to_proceeded_list(ticket_number) - adds current ticket to proceeded_list after all the operations according to the state.
  - create_ticket(current_ticket_number) - creates a ticket as a result of current one’s state
  - send_ticket(ticket_number) - send ticket to the next state.
  - get_current_ticket_list - get ticket list from the DB that needs to be proceeded by current bot-service. The result is current_ticket_list
  - check_ticket_list - compares tickets in current_ticket_list and  proceeded_list. Tickets that appears in the current_ticket_list but not in proceeded_list should be added using proceed_ticket.
  - ticket_timeout(ticket_number) - function to proceed tickets that gets timeout. That is the only  one function to get read of the stucked tickets. Normally tickets should be sent to the next step for proceeding. The last step accumulates tickets and clears it after some period of time using this function. 
  - send_bot_notification (current_ticket, bot, text) - function for sending notifications during tickets processing.
  - send_user_notification (current_ticket, user, text) - function for sending notifications during tickets processing.
  - parse_notification(notification) - parse notifications got by bot-service in order to choose the function to proceed.

What could be done in proceed_ticket function (in addition to the functions that was mentioned before):
  - get_assigned_user(ticket_number) - a call to the database to get UID for notifications;
  - set_assigned_user(ticket_number, user) - changes info about assignment (should contain checks);
  - wait(ticket_number, time) - return to the process after some period of time
  - wait_until_time(ticket_number, date) - return to the process after the time specified;
  - wait_until_ticket(current_ticket_number, ticket_to_wait) - return to the process after another ticket got closed.

There might be other functions for ticket processing that is not mentioned above.