¡Esta es una revisión vieja del documento!
Integria IMS propone una visión de la gestión de tickets adaptable a diferentes necesidades: se puede entender un ticket como un problema técnico, el resultado de una intervención planificada, un bug de software o una hoja de trabajo sobre un problema más complejo.
Los tickets tienen una serie de características básicas, que responden a las necesidades de entornos de trabajo con tickets habituales, tales como la gestión mediante grupos de trabajo, usuarios creadores y propietarios, comentarios y seguimiento, asociación a objetos de inventario, SLA, etc.
Caso práctico de flujo de ticketing con Integria
Nuestro equipo de soporte está formado por tres personas (Tomás, Javi, Luis) y un “jefe” de equipo (Ramón).
Tenemos varios tipos de clientes. Los que trabajan en equipo y los que actúan de forma independiente. Los que operan en equipo, tendrán a varias personas trabajando simultáneamente que podrán visualizar los tickets de sus compañeros, o bien para aportar algo, o bien para hacerse cargo de ellos. Los clientes o usuarios independientes sólo pueden ver sus propios tickets, y nadie más tiene acceso a éstos.
El primer tipo de cliente tendrá un grupo propio y varios usuarios asignados a ese grupo, los usuarios de este grupo serán de tipo “agrupado”, y sus privilegios se basarán en el perfil que tengan asociado para su grupo de trabajo. Mientras que el segundo tipo de cliente actuará de forma individual y su usuario será de tipo “independiente”, de forma que únicamente visualizará su propio contenido.
En nuestro entorno piloto, cuando un cliente de tipo agrupado abre un ticket, se asigna a un usuario genérico de Integria llamado “Soporte”, generando un email que va a “[email protected]”. Tanto el usuario por defecto como la dirección de correo se especifican en la sección de configuración de su grupo.
Esa cuenta de email es una lista de distribución que envía una copia a cada uno de los miembros del equipo de soporte. Al recibir el correo y acceder al enlace adjunto, accediendo a la herramienta se visualizará un ticket nuevo resaltado en color rojo, de esta forma:
Haciendo clic en el ticket que está en rojo entramos en la pantalla principal de gestión del ticket. Podemos cambiar su estado, o navegar por las solapas del ticket para ver su histórico, notas asociadas al ticket (workunits), ficheros, etc. Generalmente nos interesa dar la primera respuesta al problema, ya que desde que se abre, se calcula cuanto tiempo pasa sin respuesta. Si pasa el margen de tiempo establecido por el SLA asociado al grupo de ese ticket, aparecerá un warning junto al nombre del ticket, además de enviarse un mail de forma automática.
Sobre un ticket nuevo puede añadirse una primera respuesta en forma de unidad de trabajo o comentario. El ticket entonces será asignado automáticamente al usuario que escribe la unidad de trabajo, modificando el estado del ticket de “Nuevo” a “Asignado”.
Cuando se añade una Unidad de trabajo (comentario) o un fichero o se cambia su estado, se envía una notificación por email a todos los usuarios “suscritos” a ese ticket. En este caso, un usuario de soporte va a poner una nota que dice “Veo lo que me cuentas y voy a intentar reproducirlo para determinar el origen del problema”.
Al crear la WU, el ticket ha cambiado de estado a “Asignado”, y al autor del ticket le llegará un email con el comentario añadido.
En cualquier momento de la vida del ticket, si un nuevo usuario añade un comentario o realiza alguna modificación en el ticket, quedará suscrito al ticket, recibiendo todas las notificaciones sobre cambios en el ticket. En la sección “seguimiento” del ticket puede verse un registro de todos los usuarios que han participado en el ticket en algún momento.
Dependiendo del nivel de privilegios del usuario podrá símplemente visualizar tickets, añadir comentarios o incluso modificar el propietario, el tipo, etc. Finalmente cuando un ticket queda resuelto, un usuario con permisos puede cambiar el estado a “Cerrado”, desapareciendo así de la vista por defecto de tickets. Naturalmente quedará en estado cerrado para poder consultarlo en cualquier momento.
Los tipos de tickets nos permiten crear tickets con campos personalizados para diferentes grupos, además de poder añadirle partes de trabajo específicos.
Veamos un ejemplo:
Como vemos en el ejemplo anterior:
Para crear un tipo de ticket tenemos dos opciones:
Campos que se pueden definir en la creación/edición de un tipo de ticket:
Las acciones que se pueden aplicar a un tipo son:
A continuación vemos un ejemplo
Para actualizar, se hace click en el icono llave inglesa que nos llevará a la vista de edición. Una vez aquí, podremos modificar cualquier apartado.
Para borrar, se hace click en el icono papelera. Esta acción nos pedirá confirmación. Una vez aceptado, el borrado será definitivo y no se podrá deshacer esta acción.
Para añadir campos personalizados, se hace click en el icono suma.
A continuación se muestra el listado con todos los campos que se han creado.
Las columnas que componen este listado son:
Ejemplo de ordenación: Se quiere que los campos TIPO, MARCA, MODELO, MOTOR se vean los primeros, habría que seleccionar los cuatro campos en la lista y en el menú de ordenación seleccionamos la opción “antes de” y la posición que en este caso seria el primero.
Como se puede ver, ahora aparecen los campos lincados al comienzo de la lista.
La asignación de grupo a un tipo de ticket es opcional y nos permite relacionar el tipo a uno o varios grupos. Si lo dejamos vacío, este tipo de ticket se podrá asignar a cualquier grupo.
Un ticket podrá tener asociado uno o varios partes de trabajo. Un parte de trabajo es un documento que se podrá descargar para su posterior validación. Para facilitar la creación de este documento de forma sencilla y flexible, tenemos las plantillas. Un tipo de ticket sólo podrá tener asociada una única plantilla.
Creación de plantilla
Elementos que forman la plantilla:
Se pueden añadir imágenes de forma sencilla seleccionando el siguiente icono:
El siguiente paso sería añadir la url de la imagen.
También podremos Utilizar macros: Las siguientes palabras serán reemplazadas por el valor real en las plantillas que las usen:
Estas macros podrán ser utilizadas en código html:
A continuación, tenemos el listado con todas las plantillas que se han generado. En esta vista se muestra: nombre, descripción, a qué tipo de ticket está asignada, borrado y edición.
¿Qué utilidad tienen los tipos de ticket? Los tipos de ticket nos van a permitir crear tickets de una forma flexible, es decir, al seleccionar un tipo, nos van a aparecer sus campos personalizados y podremos generar partes de trabajo utilizando su plantilla. Lo vemos con un ejemplo:
Seleccionamos el tipo de ticket:
Y vemos que aparecen todos nuestros campos personalizados:
Rellenamos los campos y creamos el ticket:
Se puede encontrar un resumen con los campos personalizados asociados a un ticket en su vista general (dashboard).
Partes de trabajo asignados a un tipo de ticket
La gestión de partes de trabajo dentro de un ticket se hará en la pestaña Partes de Trabajo
Para crear un parte de trabajo simplemente clickamos en nuevo y se creará un parte de trabajo que podremos descargar, validar o borrar.
Hay que tener en cuenta que un parte de trabajo validado ya no se podrá borrar ni descargar. La única acción posible asociada a este parte será la descarga de su validación.
Uno de los campos más importantes de los tickets es el estado. Mediante este campo podremos hacer un seguimiento preciso del momento de su vida en que se encuentra el ticket, bien si es algo reciente, si está se encuentra a la espera de agentes externos, pendiente de cierre o cerrado. Este ciclo está abierto al usuario y se puede pasar de uno a otro sin restricción por defecto.
Es posible definir un flujo controlado para restringir el orden de los estados por los que un ticket puede pasar mediante la característica del Mapeo de estados. Haciendo uso del mapeo de estados podemos definir si un ticket debe pasar por diferentes fases antes de ser cerrado.
Un Ejemplo de diferentes estados de un ticket
Ejemplo práctico: tenemos un equipo de operadores responsables de la gestión de incidencias de clientes. Para asegurarnos de que el orden de resolución es respetado y garantizar una calidad de servicio al cliente, mediante el mapeo de estados indicaremos que un ticket con estado “Nuevo” únicamente puede pasar a los estados “Asignado” o “Pendiente de tercera persona”; de cualquiera de estos tres estados únicamente podrá pasar a “Pendiente de ser cierrado”, y será desde éste desde el que pueda quedar finalmente “Cerrado”. Además, desde “Cerrado” la única posibilidad será volver a “Re-abierto”. La configuración para este caso sería como esta:
Existen determinadas circunstancias que actúan automáticamente cuando pasamos de un estado a otro. Al pasar de cualquier estado, al estado «cerrado», automáticamente se activará una casilla de texto que antes no estaba accesible llamada «epílogo» que sirve para explicar cuál fué el resultado de la intervención o cambio o cual fué -en suma- la causa del problema y su solución. Como se verá más adelante, un ticket solucionado es la base para generar un artículo en la base de conocimiento que sirva para en posteriores ocasiones, solucionar un problema de forma rápida y documentada.
Existen cinco roles diferentes en un ticket:
Es el autor original del ticket. Es quien establece el responsable de ese ticket (a no ser que esto se haga automáticamente, como veremos más adelante), el grupo al que pertenece el ticket (idem) y otros parámetros como su criticidad, descripción, elementos de inventario a los que está vinculado, etc.
Como cualquier usuario con acceso a el ticket, el usuario creador puede añadir ficheros y unidades de trabajo (UT o WU en inglés).
Usuario asignado al ticket. Habitualmente en la definición de grupos se asigna un usuario predeterminado, que será el usuario al cual se le asignará el ticket por defecto, en función del grupo seleccionado por el usuario creador del ticket. Los privilegios que tendrá dependerán de su nivel de perfil para el grupo del ticket, puede ser simple lectura (usuario genérico) o permisos de gestión.
El ticket siempre pertenece a un grupo. Todos los usuarios con el flag de acceso “IW” pueden escribir UT (Unidades de Trabajo o Workunit en ingles) sobre un ticket. Estas UT son comentarios que quedan reflejados en el ticket a modo de seguimiento personal, indicando acciones realizadas o facilitando datos. Este tipo de usuario no puede modificar ningún otro detalle del ticket, tal como estado o criticidad, ni alterar la descripción principal del ticket.
Cualquier usuario que pertenezca al grupo de trabajo de un ticket y tenga el flag de acceso “IR” podrá leer los detalles del ticket, aunque no podrá modificar nada, ni agregar comentarios o fichero.
Un usuario con el bit de acceso IM sobre el grupo al que pertenece un ticket puede operar con el como si fuera el propietario del mismo. Esto implica que puede «escalar» el ticket apropiándoselo o traspasar la responsabilidad del mismo a otro usuario. Por supuesto puede agregar UT o ficheros e incluso cerrar el ticket.
Puede ser cualquier usuario con permisos de gestión sobre el ticket. A la hora de cerrar un ticket aparece un nuevo campo “Cerrado por”, pudiendo elegir cualquier usuario del grupo; naturalmente por defecto será el usuario que lleve a cabo la acción de cerrar el ticket.
Cualquier persona que haya participado en algún momento durante la vida del ticket, realizando modificaciones o añadiendo comentarios. También recibirá notificaciones con las actualizaciones que se produzcan en el ticket. En la solapa “Contactos” podemos ver la lista completa de las personas que participan en un ticket.
A la hora de crear y rellenar correctamente un ticket es importante tener claros los siguientes conceptos:
Es fundamental entender la diferencia entre usuarios agrupados e independientes, sus visibilidades y contabilizaciones a la hora de calcular el total de tickets (soft limit y hard limit):
Al crear un ticket por defecto su estado será “Nuevo”.
Existen dos valores definidos en los grupos, como se vio en la sección correspondiente, que permiten definir el límite de tickets por grupo, tanto a nivel informativo (soft limit) como restrictivo (hard limit):
Si se sobrepasan el soft limit, aparecerá una ventana de advertencia, pero podremos continuar abriendo tickets (salvo que se encuentre marcada la opción “Forzar soft limit”). Si se sobrepasa el hard limit no será posible abrir nuevos tickets asociados al grupo en cuestión:
El límite de tickets se calcula contando el número de tickets del último año a partir de la fecha actual. El soft limit cuenta los tickets en estado abierto creados en el último año. El hard limit cuenta los tickets en cualquier estado creados en el último año.
Bien, el ticket ha sido creado por un usuario (llamémosle A) y asignado a otro usuario (llamémosle B). ¿Ahora qué?
Al crear el ticket, el sistema habrá enviado un email al usuario A y otro al usuario B, informando sobre la creación del ticket. Al usuario A, este mensaje le sirve como confirmación de que el ticket ha sido correctamente registrado en el sistema.
El usuario B también recibirá un correo, al que puede contestar para añadir la primera UT (Unidad de Trabajo). También puede conectarse al sistema a través de la URL proporcionada en el mail para poder agregar manualmente la UT a el ticket.
En el momento que el ticket en estado “Nuevo” recibe una UT, automáticamente se cambia su estado a “Asignado”, indicando que ha entrado en un proceso de trabajo.
Una vez abierto el ticket, podremos operar bien con las solapas superiores o las inferiores. Las solapas superiores dan acceso a la edición del ticket, o ver/añadir adjuntos o notas. También podemos volver a la búsqueda.
En la parte inferior, podemos navegar por las solapas que presentan las notas del ticket, los ficheros, las estadísticas de esta ticket, el tracking detallado y los contactos del ticket activo.
En la sección tickets asociados vemos las relaciones entre tickets, es decir tickets relacionados (hijos) con el ticket actual (padre). Hay que tener en cuenta que al cerrar el ticket padre se cerrarán todos los tickets hijos asociados.
En la sección de comentarios o workunits veremos las notas agregadas manualmente por los usuarios, y podremos añadir nuevas unidades de trabajo.
En esta sección de archivos se pueden ver, descargar y adjuntar ficheros al ticket.
En la vista de detalle del ticket o seguimiento se muestran los tiempos totales, los tiempos que ha pasado en cada estado y los tiempos dedicados por cada persona implicada en el ticket, además de un histórico de las intervenciones de usuarios sobre el ticket.
En esta sección podremos ver los objetos de inventario asociados al ticket.
En contactos podemos ver las personas que se encuentran suscritas al ticket por haber participado en algún momento.
Las medallas sirven para controlar la calidad de nuestro servicio. Para ello podremos usar las medallas doradas cuando el nivel de soporte ha sido bueno y medallas negras para indicar que no estamos satisfechos con la resolución de la incidencia.
Para poder usar las medallas tenemos que tener habilitado el modo de edición rápida desde el setup.
Los usuarios con el permiso de Control de calidad (QA) podrán añadir o quitar medallas en los tickets en la sección de Edición rápida:
Así mismo en el listado de tickets se puede ver en la columna de Estado el número de medallas de cada tipo así como filtrar en el listado por los diferentes tipos de medallas.
En el informe mensual, sección Personas, podremos ver el número de medallas que tiene cada usuario de Integria.
Además en las reglas de workflow es posible añadir medallas automáticamente, por ejemplo se puede añadir una medalla negra al ticket que lleva una semana sin actualizarse.
Se puede usar la vista de búsqueda básica para visualizar el listado de tickets, acceder directamente al número de ticket en el menú de la izquierda o modificar opciones de filtrado. Las búsquedas por defecto muestran todos los tickets no cerrados y no solucionados.
Cualquier combinación de opciones de filtrado que utilicemos se puede guardar como búsqueda personalizada para utilizar posteriormente. Las búsquedas personalizadas son diferentes para cada usuario. También serán utilizadas en los informes de tickets.
Haciendo click sobre un ticket accederemos a los detalles y todas las secciones específicas, pudiendo añadir archivos, unidades de trabajo, etc.
Información que muestra cada columna de la lista de tickets:
Un ticket puede referirse a un fallo de software, un problema de comunicaciones, un problema de un cliente con un pedido, etc. Debido a los diferentes usos que un ticket puede tener, existen los tipos de ticket, que cuentan con una serie de campos propios que pueden ser personalizados por el usuario, modificados, o añadir nuevos.
Sobre un ticket ya creado podemos cambiar su tipo, opcionalmente, ya que existe una casilla en el setup para definir este comportamiento. Si lo hacemos, perderemos el valor que contenían los campos personalizados del tipo anterior.
Todas las búsquedas personalizadas se podrán reutilizar en la vista general de tickets además de ser los datos base para los informes estándar de tickets.
El dashboard es una vista simple que permite conocer rápidamente el estado de los tickets agrupados de diferentes maneras y tener acceso directo a las búsquedas personalizadas que hemos creado. Es la pantalla por defecto de la sección de tickets.
Esta sección nos permite construir un informe al que se le aplica una búsqueda personalizada creada previamente.
En el caso de no existir ninguna búsqueda personalizada, se mostrará una ventana que nos dirigirá a la vista de creación de búsquedas.
El contenido del informe está divido en dos secciones:
Si no se selecciona ninguna de las opciones, se mostrará una versión reducida de las estadísticas que contendrá las siguientes gráficas y tablas:
Si se selecciona la opción Mostrar estadísticas se obtendrá, además de las gráficas y tablas descritas en la vista anterior, otras adicionales:
Al seleccionar la opción Mostrar listado, obtendremos el listado de tickets completo:
Este informe podrá exportarse a PDF pinchando sobre el icono
El SLA es la forma de “comprobar” que la gestión de tickets funciona bajo unos criterios. Integria cuenta con funcionalidades de gestión automática de SLA.
El SLA se procesa conforme unos parámetros:
Significa que el sistema enviará una notificación por email al propietario del ticket, advirtiendo que el ticket no cumple los baremos establecidos en el conjunto de reglas de SLA asociada al ticket. Esto dependerá del grupo al que está asociado el ticket, ya que es en la configuración de grupo donde especificamos qué SLA se aplicará a los tickets de grupo:
Podemos ver la evolución histórica del cumplimiento de SLA de un ticket, o los valores de cumplimiento en total en los informes generales. Un SLA bajo, generalmente significa que el ticket no se ha gestionado bien. Es un indicador muy usado para ofrecer un resumen de la calidad del servicio y gestión de los tickets.
Cuando el SLA de un ticket se incumple, un indicador luminoso aparece en la vista de tickets.
Ejemplo de definición de SLA:
Los SLA están vinculados al estado de los tickets. De forma que si el tipo de SLA elegido es Normal no se aplicará el SLA para los tickets que están en estados Cerrado y Pendiente de terceras personas. Si el tipo elegido es SLA de terceros sólo se aplicará el SLA para los tickets que estén en estado Pendiente de terceras personas. Si se eligen Ambas se aplicará el SLA para todos los tickets excepto los que estén en estado Cerrado.
Utilizando el sistema de SLA, en el informe de “seguimiento” de un ticket puede verse en una escala de tiempo, cuando el ticket no ha cumplido (en rojo) y cuando ha cumplido (en verde). Además de un indicador del % de cumplimiento del ticket en toda la vida de éste.
Esta característica Enterprise permite definir reglas personalizadas que serán aplicadas en la gestión de tickets de forma automática. Ejemplo práctico: un ticket del grupo Soporte lleva 48 horas sin respuesta, se envía un email al usuario responsable informando de esta situación, ya que cumple una condición asociada a una regla workflow, ejecutando por tanto las acciones definidas, en este caso, envío de un mail.
Estas reglas sólo pueden ser definidas y gestionadas por usuarios tipo “súper administrador”, no siendo accesibles en ningún caso para usuarios agrupados que dependan de configuraciones de perfil-grupo. Por defecto las reglas serán aplicadas una única vez, a excepción de las reglas que tienen como condición la fecha de actualización del ticket. En este caso, la regla se lanzará siempre que corresponda.
En la captura mostramos una regla Añadir WU y enviar email a responsable cuando el ticket lleve 48hrs sin respuesta.
Cada regla tiene condiciones asociadas que se deberán cumplir para ejecutar las acciones. Si una regla tiene más de una condición, habrán de darse todas las condiciones para que se dispare la acción. Para poder modificar la regla o acceder a sus condiciones y acciones, hay que hacer click sobre la descripción. En la edición podremos elegir el modo de ejecución:
En Condiciones accedemos al listado donde definiremos en que casos aplicaremos la regla, definiendo una serie de condiciones. En nuestro ejemplo tenemos una condición ya definida. Podemos tener una o varias condiciones por regla workflow. En el caso de que tengamos varias condiciones, con que se cumpla una, la regla se activará y ejecutará la acción o acciones programadas. Las condiciones están compuestas por un conjunto de filtros o subcondiciones, los cuales se describen a continuación:
En el siguiente ejemplo definiríamos una regla que se cumpliese en caso de: existir un ticket de máxima prioridad asociado al usuario genérico “soporte” y que llevase al menos 1h sin ser actualizado.
En esta otro ejemplo el grupo debe ser Soporte, la prioridad debe ser Media y el estado Asignado. El campo condición elegido es Coincidir todos los campos porque queremos que se cumplan todas las subcondiciones especificadas.
A continuación, vemos las posibles acciones que puede ejecutarse si se cumplen las condiciones anteriores.
Las acciones están formadas por los siguientes campos:
Las acciones se definen según el campo Tipo de acción:
Al añadir la primera acción, se añade una acción adicional por defecto que es la modificación de la fecha de última actualización del ticket. Es posible eliminarla manualmente.
Ejemplos de uso:
En general las reglas de workflow se dispararán una sola vez, de forma que si establece una regla para cambiar por ejemplo, el usuario asignado a la incidencia cuando una incidencia tenga más de 30 días de vida, y el usuario asignado es X, pero luego manualmente alguien vuelve a poner ese usuario X, la regla no se volverá a disparar.
La única excepción de este comportamiento es cuando la condición es el tiempo de actualización. Si establece una regla para que salte cuando el ticket lleva más de X tiempo sin actualizar, se creará automáticamente una acción por defecto para “actualizar el ticket”. Esto hará que no salte continuamente la condición. Pasado ese X tiempo, el sistema podrá ejecutar de nuevo la misma regla de Workflow. Esta es la excepción, ya que para ninguna otra condición (Prioridad, Propietario, Estado, Creación ó Grupo), se podrá volver a ejecutar una regla.
Caso típico de uso para este tipo de condición:
Simplemente tiene que rellenar en la condición “Coincidir todos los campos”, el grupo específico y la prioridad muy alta, solo para incidencias asignadas. En “Fecha de actualización” escogeremos una semana.
Al añadir la acción de enviar un mail, se creará automáticamente la acción de actualizar el ticket, que dejaremos tal cual, para actualizar el ticket y evitar que siga saltando la regla.
El asunto y el cuerpo del email pueden contener las siguientes macros:
Ejemplo de la ejecución de un comando personalizado:
A través del API REST de Integria IMS es posible crear nuevos tickets, valiéndonos de esta funcionalidad podemos desarrollar formularios personalizados que nos permitan dar de alta nuevos tickets en el sistema.
El siguiente código PHP crea un formulario y recoge los datos enviados por el formulario. Con ellos compone una llamada al API de Integria IMS que crea un nuevo ticket.
Para probarlo basta con copiar este contenido en un fichero de texto, editarlo para los parámetros de nuestra instalación y ubicarlo en la ruta de la consola de integria (por defecto /var/www/html/integria), y realizar la llamada a través del navegador: http://localhost/integria/formulario.php
El formulario resultante tiene el siguiente aspecto:
A continuación comentaremos parte del código. Es importante modificar estas líneas para adaptarlas a nuestra instalación:
$integria_url = "http://inna.lab.artica.lan/integria"; // user and password for which creates the incident $user = "admin"; $integria_pass = "integria"; // integria api pass $integria_api_pass = "1234";
La siguientes variables configuran opciones generales de los tickets, en este caso el título del ticket, el grupo, la prioridad, descripción o cuerpo,etc.
// Extra - status - new $ticket_status = 1; // Set default parameters $priority = 0; $inventory = ""; $type = ""; $mail = ""; $owner = ""; $parent = ""; $title = $_POST["title"]; $group = $_POST["group"]; $description = $_POST["description"]; //Get post parameters if (isset($_POST["priority"])) { $priority = $_POST["priority"]; } if (isset($_POST["inventory"])) { $inventory = $_POST["inventory"]; } if (isset($_POST["type"])) { $type = $_POST["type"]; } if (isset($_POST["mail"])) { $mail = $_POST["mail"]; } if (isset($_POST["owner"])) { $owner = $_POST["owner"]; } if (isset($_POST["parent"])) { $parent = $_POST["parent"]; }
Para localizar los IDs de los elementos que necesitamos, por ejemplo el ID del grupo (que es un campo obligatorio), podemos acceder al correspondiente grupo dentro de Integria y veremos el ID en la barra de direcciones del navegador.
A continuación se crea una cadena de texto con la url que usaremos para crear los tickets mediante el API de Integria IMS. Además de la dirección del servidor y el usuario, se configuran los parámetros op con el valor create_incident que indica la función del API que se va a utilizar y params con los parámetros de la función.
$myurl = $integria_url."/include/api.php?user=".urlencode($user)."&user_pass=".urlencode($integria_pass)."&pass=".urlencode($integria_api_pass); $myurl .= "&op=create_incident¶ms=".urlencode($title).",".urlencode($group).",".urlencode($priority).",".urlencode($description).","; $myurl .= urlencode($inventory).",".urlencode($type).",".urlencode($mail).",".urlencode($owner).",".urlencode($parent).",".urlencode($ticket_status).",,,,";
Es importante tener en cuenta que esta URL está construida para una API con autorización por IP, si estamos utilizando en nuestra API autorización por contraseña, deberemos construir la URL correspondiente, utilizando $myurl = $integria_url.”/include/api.php?user=“.urlencode($user).”&pass=passAPI“.”&op=create_incident.
Por último el código realiza una llamada al API de Integria IMS por medio de la utilidad CURL de PHP.
// Configure curl $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $myurl); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); // Send curl request and close $ret = curl_exec($ch); curl_close ($ch); $_POST = array();
En caso de que se deje en blanco los campos obligatorios (Título, Descripción. ID Grupo y Prioridad) no permitirá la creación del ticket.
Integria permite la creación y actualización de tickets mediante el envío de mails. Esta es una característica Enterprise.
Dependiendo del cliente de correo electrónico usado el formato de los emails podría ser diferente. La gestión de emails de Integria ha sido validada con los siguientes gestores de correo: Evolution, Gmail, Outlook y Mail.
La creación de tickets y workunits por email usa los mismos principios de ACLs que el interfaz gráfico. Puedes ver estos principios en la sección Perfiles y usuarios.
La gestión de tickets por email está basada en la funcionalidad de las colas de correo, configuradas para cada uno de los grupos existentes en Integria IMS. Además deberá configurar los parámetros de correo como se indica en la sección Configuración de email.
Supongamos que tenemos habilitada la siguiente dirección de correo para recibir los email: [email protected] y configurado el parámetro Cola de emails de un grupo con la siguiente información:
[email protected]
Enviaremos un email con los siguientes datos:
Ejemplo práctico:
La siguiente imagen explica el flujo de gestión de colas de emails de una forma resumida:
Si tiene activado el sistema de envío de emails para seguir las novedades en los tickets de Integria, recibirá emails con las novedades de sus tickets.
En algunos de ellos verá que en el título tiene asignado un ticket ID, respondiendo a estos emails podrá añadir nuevas workunits al ticket correspondiente.
Para añadir una nueva workunit sólo tiene que contestar el email añadiendo en el cuerpo el contenido de la workunit. Como resultado aparecerá una nueva workunit en el ticket. Si por ejemplo responde al email con el siguiente cuerpo “Thanks. Please close the incident all its ok. Javi” aparecerá el siguiente workunit.
Al igual que la creación de tickets por email, la creación de workunits añade los archivos adjuntos en los emails a el ticket correspondiente.
Integria permite modificar los tickets por email. Para ello es necesario añadir la siguiente estructura en el cuerpo del email.
[INCIDENT] GROUP: IT ASSIGNED_TO: dario PRIORITY: 3 STATUS: Assigned RESOLUTION: Invalid [INCIDENT]
Los campos y sus posibles valores son los siguientes:
También es posible modificar algunos parámetros en la creación de la workunit usando la siguiente estructura en el cuerpo del email:
[WORKUNIT] TIME_USED: 0.05 [WORKUNIT]
Los campos y sus posibles valores son los siguientes:
Las estructuras anteriormente descritas para modificar el ticket o personalizar la workunit **no quedarán reflejadas dentro de la información del ticket en la aplicación**. Es muy importante verificar la correcta sintaxis de las estructuras anteriores, ya que un error en las cabeceras o en los parámetros resultarán en una detección incorrecta de las directivas y por ello no se aplicarán los cambios. En este caso se tratarán como otro texto cualquiera y aparecerán en la información de las workunits dentro de la aplicación.
Es posible que al crear una workunit mediante el correo electrónico aparezca en el cuerpo del mensaje alguna dirección de email fruto de usar la funcion responder a todos o por cualquier otra razón.
Si en su organización considera que esta información es sensible y no debería aparecer en los workunits. Integria le permite enmascarar las direcciones de correo, de forma que usted sabrá que ahí había una dirección de correo electrónico, pero no podrá adivinar cuál.
Puede configurar esta opción en el tab de Tickets de la Configuración General de la aplicación marcando el flag Masking email addresses.
Cuando este flag está activado Integria cambiará todas las direcciones de correo electrónico por la siguiente dirección comodín [email protected]
Documentación de Integria