consulta de escalar un ticket

[jd_munoz]

Hola a todos

tengo una pregunta.

Como puedo hacer que un ticket que no tiene respuesta en un tiempo determinado, sea escalado y reasignado a otro agente específico, que no se quede el ticket suelto, lo de configurar los tiempos de vigencia del ticket si los tengo claro, pero cuando vence el tiempo el ticket se queda en la bandeja de tickets escalados ahi sin ser liberado y re asignado a otro agente.
espero que me puedan ayudar

de ante mano gracias

[miguelmz]

Hola jd_munoz,

Puede que tenga tu respuesta, pero tendras que pegarte un poco con el cron o similares. Si vas a la pestaña administrar y pinchas en Colas veras que al editar la cola correspondiente puedes definir un tiempo de desbloqueo del ticket por inactividad, por defecto esto a 0 (disabled), con esta parte podrias definir un desbloqueo automatico digamos a las 4h dee estar bloqueado por un agente sin respuesta.

Ahora la segunda parte de reasignarlo automaticamente, Otrs dispone de una funcionalidad llamada agente generico accesible desde la pestaña administrar. Una vez dentro creas una tarea periodica, tiene diversas pestañitas a desplegar/ocultar en concreto la de ticket filter aparece una "Ticket lock". Selecciona tu casuistica con esa casilla marcada "desbloquear" y te pillara todos los tickets desbloqueados de donde quieras. Despues en Ticket Action hay otro apartado que pone "Set new agent/new owner" donde te aparece la lista de tus agentes y se lo asocias.

Todas estas plantillas son ejecutadas en x tiempo definido en la parte superior, como veras solo es minimo 10min, pero hay otras opciones. al igual que el fetchmail de correo (cada 10min) puedes configurar un cron o similar ejecutando directamente el perl asociado. Echa un vistazo a la ruta /opt/otrs/var/cron y nos cuentas

Un saludo.

[jd_munoz]

Gracias miguelmz,

Por tu ayuda, clara explicación, esta funcionando bien, solo tengo una pequeña inquietud, si tengo que cambiar el tiempo por ejemplo a cada 5 minutos en el cron /opt/otrs/var/cron. O el cron del linux mismo, cual es la diferencia o si funciona de las dos formas o cual me aconsejas tu hacer el cambio de tiempo.

saludos

[miguelmz]

Hola jd_munoz,

No me referia a eso, en dicha direccion /opt/otrs/var/cron aparece la configuracion que deberias poner el cron, esta configuracion la podias meter directamente con otro script, el cual ahora mismo no recuerdo donde esta. En cualquier caso metelo a mano, si haces un cat sobre esos archivos, en tu caso los de agente generico (generic_agent y generic_agent-database) veras lo siguiente:

GENERIC AGENT
# --
# cron/generic_agent - otrs.GenericAgent.pl cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: generic_agent.dist,v 1.13 2009/11/04 12:27:57 mn Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# start generic agent every 20 minutes
*/20 * * * * $HOME/bin/otrs.GenericAgent.pl >> /dev/null

# example to execute otrs.GenericAgent.pl on 23:00 with
# Kernel::Config::GenericAgentMove job file
#0 23 * * * $HOME/bin/otrs.GenericAgent.pl -c "Kernel::Config::GenericAgentMove" >> /dev/null

GENERIC AGENT DB
# --
# cron/generic_agent - otrs.GenericAgent.pl cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: generic_agent-database.dist,v 1.9 2009/11/04 12:27:57 mn Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# start generic agent every 10 minutes
*/10 * * * * $HOME/bin/otrs.GenericAgent.pl -c db >> /dev/null

A ti te interesa lo marcado en rojo, modifica esos tiempos 20 y 10 al tiempo que te interese (1 min minimo) y prueba. Te pongo los dos porque se que uno de ellos no era pero no recuerdo cual. Esto mismo puedes aplicarlo al fetchmail de tus cuentas de correo para recibir tickets con lo que pone en esa ruta en el archivo fetchmail.

Code: Select all

# --
# cron/fetchmail - fetchmail cron of the OTRS
# Copyright (C) 2001-2009 xxx, http://otrs.org/
# --
# $Id: fetchmail.dist,v 1.10 2009/02/16 20:53:10 tr Exp $
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

# fetch every 5 minutes emails via fetchmail
#*/5 * * * * [ -x /usr/bin/fetchmail ] && /usr/bin/fetchmail -a >> /dev/null
#*/5 * * * *    /usr/bin/fetchmail -a --ssl >> /dev/null

Si te interesa una ejecucion mas rapida puedes usar herramientas externas que permitan ejecutar estos scripts con tiempos mas acordes a tus intereses claro.

[jd_munoz]

Gracias por el dato, ahora he notado que tengo un problema

pienso que a veces el sistema no bloquea los tickets creados de forma automática y si configuro ésta opción de filtro en el agente genérico que se ejecute cuando se desbloquea un ticket pues se va a ejecutar la tarea por todos los tickets desbloqueados sean o no esclados, estaba probando otra condición de filtro Escalation times: tiempo escalado alcanzado: el ultimo minuto, pero ejecuto manualmente la tarea y no hace ninguna acción, si de pronto me podrias indicar si estoy escogiendo la opción bien

mira la idea es que solo los tickets esclados sean reasignados automaticamente a otro agente a penas se complete el tiempo que se tiene para responder a ese ticket.

espero ser claro en mi problema

espero tu ayuda gracias

[miguelmz]

Posiblemente no tengas ningun caso en el que tengas un escalado ciertamente, me explico. Otrs realiza un calculo de primera respuesta, actualizacion respuesta , cierre ticket en conjunto con los calendarios proyectados en el XML de ticket /opt/otrs/Kernel/Config/Files, en funcion de ello y el sla definido bien por servicio o cola te muestra el tiempo tope para cada caso asi como una cuenta atras en minutos.

Este tiempo tope es registrado en la BBDD tabla ticket en los campos escalation_update_time, escalation_response_time y escalation_solution_time. El tiempo es registrado como un unix_timestamp y de aqui comprueba el agente generico. No obstante, tiene una pega por defecto, una vez alcanzada la fecha tope o pasado el evento (primera respuesta, cerrado..) el ticket se mantiene como escalado si, pero la fecha es inicializada a 0 de nuevo quitando la posibilidad del filtrado de tu agente generico. Si, otrs no guarda historicos de tiempos notificacion.

Ahora puesto en situacion se te presentan varias opciones:
1 - Primero prueba en una cola aparte del flujo de trabajo o un otrs de pruebas el agente generico si funciona en tales casos ya que te sirve en el momento que alcanze el tiempo porque aun mantendra datos en la bbdd, aunque despues los borrara, teniendo asi reasignado el ticket.
2 - Si quieres evitar la inicializacion debes tocar el archivo Ticket.pm en /opt/otrs/Kernel/System funcion TicketEscalationIndexBuild.
3 - Uso de triggers a nivel BBDD, cuando observes cambios en esos campos de uno anterior!=0 a uno nuevo=0 sabes que ha sido escalado y en consiguiente llamar a un procedimiento almacenado con variables (colas, tipo ticket, id) que sean tratadas como claves de un switch para hacer directamente una reasignacion a otro agente: update ticket set user_id='tu nuevo agente' where id='var id';

Prueba y nos cuentas, yo modifique el perl de Ticket precisamente para guardar un historico en otra tabla aparte

Un saludo.

[jd_munoz]

Gracias por toda la explicación, te comento que si he echo pruebas configurando los límites de tiempo para que se escale un ticket, ahora como puedo configurar que se bloquee todos los ticket de forma automática a penas sean creados por cualquier agente, de ésta forma puede funcionar la tarea del agente genérico de que cuando se desblquee un ticket de forma automática a penas sea escalado se puede reasignar de forma a utomática a otro agente, quiero hacer esa prueba de forma manual, después para configurar en el cron de forma automática, te comento que las pruebas las estoy haciendo en un equipo de pruebas, es necesario habilitar el SLA? por inicialmente estoy haciendo las pruebas solo que expire el tiempo de la primera respuesta.
espero ser claro y que me des una guia

gracias por tu ayuda.

[miguelmz]

No te he entendido muy bien. Si activar SLA te refieres a que entras en pestaña Admin > SLA y te pide activar servicios no no es necesario, porque puedes efectuarlo desde la cola para tus pruebas, realmente ambos usan lo mismo pero bueno.

Respecto a un bloqueo nada mas la creacion de un ticket, puede ser contraproducente, ten en cuenta que el sistema de bloqueos surge de la necesidad de no realizar el mismo trabajo simultaneamiente varios agentes. Si lo bloquearas al inicio (estado abierto) estarias dejando a tus agentes sin posibilidad de hacer nada, porque por defecto OTRS asigna al ticket un propietario agente (por defecto root) haciendo solo posible a root trabajar con él.

No obstante, si ya lo tienes previsto, en el archivo Ticket.pm (/opt/otrs/Kernel/System) tienes una funcion llamada TicketCreate. Alli mismo veras un DBObject con la query de insercion en la BBDD

Code: Select all

# create db record
    return if !$Self->{DBObject}->Do(
        SQL =>
            'INSERT INTO ticket (tn, title, create_time_unix, type_id, queue_id, ticket_lock_id,'
            . ' user_id, responsible_user_id, group_id, ticket_priority_id, ticket_state_id,'
            . ' ticket_answered, escalation_time, escalation_update_time, escalation_response_time,'
            . ' escalation_solution_time, timeout, service_id, sla_id, until_time,'
            . ' valid_id, archive_flag, create_time, create_by, change_time, change_by)'
            . ' VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 0, 0, 0, 0, 0, 0, ?, ?, 0, ?, ?,'
            . ' current_timestamp, ?, current_timestamp, ?)',
        Bind => [
            \$Param{TN}, \$Param{Title}, \$Age, \$Param{TypeID}, \$Param{QueueID},
            \$Param{LockID}, \$Param{OwnerID}, \$Param{ResponsibleID}, \$GroupID,
            \$Param{PriorityID}, \$Param{StateID}, \$Param{ServiceID},
            \$Param{SLAID}, \$ValidID, \$ArchiveFlag, \$Param{UserID}, \$Param{UserID},
        ],
    );

borra el \$Param{LockID} y en la sexta "?" cambiala por un 2 (id sacado de la tabla ticket_lock_type), con eso te aseguras que entre bloqueado, pero te aviso sobre un unico propietario de forma global.

[jd_munoz]

Gracias amigo por tu tiempo y tu respuesta
Te cuento que esta todo claro, estoy haciendo pruebas y efectivamente un ticket se desbloquea en un tiempo determinado, pero tengo algunas dudas:
1.- en las propiedades de las colas donde puedo especificar el tiempo para escalar un ticket ejemplo:
Escalation - first response time (minutos): ...... Notificado por ( )
Este asunto del notificado por ? a que se refiere, ahi veo que se puede escoger en porcentajes del 10 al 90%, para que sirve eso o que impacto tiene eso?

2.- he notado que tengo un problema cuando escojo el tiempo para escalar el ticket en 10 minutos ejemplo:
Escalation - first response time (minutos): 10 Notificado por ( )

y cuando creo un ticket, reviso y el tiempo que tengo para la primera respuesta se pone 3h15m, asi cambie el tiempo de 10 a 15 , 30 o 60, siempre me pone el tiempo de 3h15m, y no se como cambio ese tiempo, antes si estaba respetando el tiempo que ponia por ejemplo de 10 minutos, este problema tengo en cualquier cola.

alguien me puede dar una guía.

gracias

[miguelmz]

El porcentaje que te viene tanto para colas como para servicos se refiere a que una vez alcanzado ese porcentaje del tiempo maximo para tu sla, genera una notificacion al agente o agentes avisandote de que se te acaba el tiempo.

Por ejemplo, podrias tener un ticket con tiempo de respuesta 60min y notiificacion al 50%, si el agente no contesta, cuando falten 30min (ojo falten, porque esta en funcion de calendarios y horarios laborales) avisara al agente o agentes. Tambien puedes tener desactivadas las notificaciones sino lo deseas.

Un saludo.

[jd_munoz]

Gracias por la respuesta, muy clara la explicación

una ultima consulta

cuando especifico el tiempo para la primera respuesta antes que se escale en una cola por ejemplo: 10 minutos y cuando creo un ticket, reviso el tiempo se pone en 3h26m, asi cambie el tiempo de 10 a 15 , 30 o 60, siempre me pone el tiempo de 3h15m, y no se como cambio ese tiempo, antes si estaba respetando el tiempo que ponia por ejemplo de 10 minutos, este problema tengo en cualquier cola, no entiendo la causa del problema, al parecer el sistema no esta tomando en cuenta el tiempo que pongo y directamente me especifica en 3h26m.

si alguien me puede dar una guía para revisar

muchas gracias

[miguelmz]

El teimpo de primera respuesta funciona en conjunto a los calendarios definidos en configuracion del sistema calendar1, 2 3 etc que tengas definido en esa cola o servicio (si usas los tiempos por relacion servicio), por lo que las 3h se referiran a que en el calculo vio que el tiempo que habias definido se cumpliria en 3h teniendo en cuneta que cuando lanzaste el ticket estabas fuera de jornada laboral del calendario.

Por otro lado, el cambiar despues de tiempos no te actualizara los tickets porque no es con efecto retroactivo.

Un saludo.

[jd_munoz]

Hola miguelmz

Quiero pedirte un favor, mira tengo una duda, he retomado el asunto de los tickets escalados y me encuentro haciendo pruebas, revisando todas las ayudas que me has proporcionado, te explico como estoy haciendo mis pruebas:

he incluido las siguientes líneas en el crontab del linux CentOs en donde corre mi aplicación:

*/2 * * * * /opt/otrs/bin/otrs.UnlockTickets.pl --timeout >> /dev/null
*/2 * * * * /opt/otrs/bin/GenericAgent.pl >> /dev/null
*/2 * * * * /opt/otrs/bin/otrs.GenericAgent.pl -c db >> /dev/null

Ya que he realiza pruebas con el cron que viene en los archivos del OTRS pero no me funcionan, como tu me indicaste que no recuerdas cual de las 2 sentencias hace correr al agente genérico, puse las dos en el crontab.

Estoy haciendo pruebas sin usar calendario en las colas y ahi si me funciona el tiempo que doy a la primera respuesta ejemplo: 5min, tengo configurado que el ticket que se desbloquee despues de 5 minutos, el ticket se escala en el tiempo establecido y se desbloquea de forma correcta (5min), estos tiempos los reviso en las trazas del sistema, todoa va bien, pero he notado que el agente genérico se activa en 30min en algunas ocaciones y en otras en 12min, te copio lo que me da la traza del sistema:

Mon Apr 2 17:00:02 2012 notice OTRS-otrs.GenericAgent.pl-10 Sent agent 'OwnerUpdate' notification to 'juan.munoz@ucuenca.edu.ec'.
Mon Apr 2 17:00:02 2012 notice OTRS-otrs.GenericAgent.pl-10 Sent agent 'AddNote' notification to 'eduardo.bernala@ucuenca.edu.ec'.
Mon Apr 2 17:00:02 2012 notice OTRS-otrs.GenericAgent.pl-10 Run GenericAgent Job 'reasignar ticket escalado' from db.
Mon Apr 2 16:48:02 2012 notice OTRS-otrs.UnlockTickets.pl-10 Sent agent 'LockTimeout' notification to 'eduardo.bernala@ucuenca.edu.ec'.
Mon Apr 2 16:42:53 2012 notice OTRS-CGI-10 Sent agent 'OwnerUpdate' notification to 'eduardo.bernala@ucuenca.edu.ec'.

Cabe indicar que en la configuración del agente genérico esta establecido Schedule minutes:00.

Mi pregunta es a que se debe el tiempo de 12min en éste caso que se demora en ejecutarse el agente genérico en el crontab.

Espero que sea claro mi problema y me puedas dar alguna guía para poder solucionar mi problema

gracias de ante mano.

[miguelmz]

Esto se debe a que a diferencia de los otros scripts ejecutados por el crontab, el agente generico se ejecuta en las horas marcadas en el schedule del agente generico.

Es decir, da igual que tengas crontab 1min ejecucion o 3 porque lo unico que hace es ejecutar el script y lo primero que hace es consultar si la hora actual del sistema corresponde con las definidas en el schedule. Si coincide, procede a ejecutarse, en caso contrario no hace nada.

A mi particularmente no me gusta demasiado, para cosas basicas de mantenimiento es suficiente pero si lo estas empleando con mas detalle como una reasignacion de colas ante algun cambio de estado o algo asi que precises un cambio mas inmediato... tienes que retocar el schedule del agente generico para que te agrege mas minutos disponibles (no de 10 en 10). ¿Como hacerlo?

Nos vamos a /opt/otrs/Kernel/Modules/AdminGenericAgent.pm y dentro buscamos $JobData{ScheduleMinutesList} en la funcion sub _MaskUpdate, veras que ahi es donde se construye el selector de minutos, pues bien tan solo añade nuevos numeros referentes a los diferentes minutos de 1 en 1, te tiene que quedar asi:

Code: Select all

$JobData{ScheduleMinutesList} = $Self->{LayoutObject}->BuildSelection(
        Data => {
            '00' => '00',
            '01'   => '01',
            '02'   => '02',
            '03'   => '03',
            '04'   => '04',
            '05'   => '05',
            '06'   => '06',
            '07'   => '07',
            '08'   => '08',
            '09'   => '09',
            10   => '10',
            20   => '20',
            30   => '30',
            40   => '40',
            50   => '50',
        },
        Name       => 'ScheduleMinutes',
        Size       => 6,
        Multiple   => 1,
        SelectedID => $JobData{ScheduleMinutes},
    );

Observa que pongo la clave del array entre parentesis, es importante porque sino te dara un error de tipo octal al construir el array. Pon el resto de minutos y actualiza tus jobs del agente generico selecionando los nuevos minutos. Con esto y el crontab al min se te ejecutara cada min con alguna pequeña despreciacion de segundos entre minuto y minuto.

Un saludo.

[jd_munoz]

Gracias por la explicación,
te cuento que segui todos los pasos al pie de la letra, hice inicialmente la prueba escogiendo en el agente genérico Schedule minutes a 02 min que ahora me aparece esos tiempos y en el crontab tambien a 2 min, realice pruebas pero se ejecutó el agente genérico a las 2 horas, no entendiendo por que motivo

gracias.

[miguelmz]

Haz la prueba con varios minutos si lo tienes cada 2 min el schedule selecciona una franja de 10min, date cuenta que el crontab no es del todo exacto y lo primero que hace el agente generico es comprobar la hora por lo que si en ese tiempo despreciable de ejecucion ha pasado el tiempo marcado, no se ejecuta.

Por otra parte revisa que la hora del servidor este actualizada, yo utilizo ntp para mantenerlo actualizado.

Un saludo.

[fosho]

Saludos Amigos


Requiero de su ayuda sobre escalamientos automáticos... implemente esta herramienta en mi trabajo y quiero saber como hacer para que un ticket se escale automáticamente a un agente... si este agente no realizó acción alguna que el ticket se desbloquee y se asigne al siguiente agente...



Por favor ayúdenme estaré agradecido

Att.

Marco
Ecuador

[FELIX7290]

Buen día me pueden indicar porque cuando capturo 1323 en el campo ESCALADO -TIEMPO PARA LA PRIMERE RESPUESTA(MINUTOS) me muestras 94 horas dentro del ticket cuando le agrego el SLA de que forma configuro el aviso a los agentes cuando se escala un ticket.
Saludos