Iniciar/Reiniciar un proceso Engage desde una transacción de socket de otro proceso (Desde 5.4.0.3)
Se agregó un nuevo servicio a EIS, que se llama EKS y que se une a otros dos existentes que son del mismo tipo: EPS y ECS. Ninguno de los tres servicios necesitan licencia para ser utilizados y tampoco dejan rastros de su invocación en el archivo de log, a menos que den error.
El servicio de EKS se usa para invocar primitivas de Kernel a través de una transacción de socket (de la misma manera que EPS invoca a Passport y ECS al servicio de campañas). Este servicio posee un único comando hasta 5.7, que es STARTACTIVITY. A partir de 5.8 se incluye también RESTARTACTIVITY.
Los formatos son los siguientes:
EKSX|STARTACTIVITY(Ticket, JobTypeCode, CustPkey [, ParentJobPkey] [, SuccessStateCode] [, MethodParameters])[EOM]
EKSX|RESTARTACTIVITY(Ticket, JobPkey, AttPkey [, ParentJobPkey] [, SuccessStateCode] [, MethodParameters])[EOM]
Dónde:
1- EKSX: Nombre del servicio de EIS en modo extendido.
2- STARTACTIVITY/RESTARTACTIVITY: Nombre del comando
3- Ticket: Id de sesión válida.
4- JobTypeCode: Código del tipo de proceso que se quiere iniciar.
5- CustPkey: Pkey de Customer que se quiere asociar al proceso.
6- JobPkey: Pkey del proceso a retomar. (RESTARTACTIVITY)
7- AttPkey: Pkey de la actividad en la que se va a retomar. (RESTARTACTIVITY)
6- ParentJobPkey (opcional): Pkey del Job padre.
7- SuccessStateCode (opcional): Código del estado de cierre que se tomará como salida válida del proceso.
8- MethodParameters (opcional): Parámetros de inicio del proceso, con el formato: NombrePrm1=ValorPrm1; NombrePrm2=ValorPrm2;…; NombrePrmN=ValorPrmN
9- [EOM]: Terminador de mensaje extendido.
Por ejemplo:
EKSX|STARTACTIVITY(00001:c792fe14-7ad0-40c0-80a9-dd78bdba32ed, TEST_FORM, 0003916516_77, 6271fc29-1b1a-4242-81c6-0363f7705cf0, OK, CODIGO=123;FECHA=2013-01-31)[EOM]
Si se informa el parámetro “MethodParameters”, todos los valores “ValorPrmN” se guardarán en los campos de la tabla relacionada al proceso que tengan los nombres “NombrePrmN”. Para el ejemplo de arriba se espera que la tabla posea como mínimo los campos: CODIGO y FECHA. No hace falta nombrar todos los campos de la tabla, sino sólo los que se quieren poblar antes que se ejecute el primer paso del proceso.
SuccessStateCode se usa para comprobar que el proceso termina en un estado de cierre que se considera correcto. Por ejemplo, si un proceso tiene los estados de cierre OK, ERROR e INCOMPLETO y en el comando se informa OK, entonces el proceso se considerará válido sólo si termina en el estado OK. Si termina en cualquier otro estado, EIS devolverá el error: “El estado de salida ‘<código_estado>’ del proceso no es válido.”
Las posibles respuestas del servicio EKS son las siguientes:
1- VALUE|
2- ERROR|
EIS devolverá VALUE cuando el proceso haya terminado sin errores. Los valores posibles de son:
1- SCRIPT: El proceso está devolviendo una pantalla de interacción con el usuario
2- CANCEL: El proceso está devolviendo una pantalla de cancelación
3- CLOSE_JOB: El proceso está devolviendo una pantalla de cierre
4- DERIVATE_SINGLE: El proceso está devolviendo una pantalla de derivación simple
5- DERIVATE_MULTIPLE: El proceso está devolviendo una pantalla de derivación múltiple
6- FINALIZE: El proceso finalizó en un estado de cierre válido y distinto de los mencionados en 7, 8, 9, 10 y 11
7- LOGOUT: El proceso finalizó en un estado de cierre que se llama LOGOUT
8- GOTOACTIVITIES: El proceso finalizó en un estado de cierre que se llama GOTOACTIVITIES
9- GOTOCUSTOMERSEARCH: El proceso finalizó en un estado de cierre que se llama GOTOCUSTOMERSEARCH
10- GOTOHOME: El proceso finalizó en un estado de cierre que se llama GOTOHOME
11- REFRESHALL: El proceso finalizó en un estado de cierre que se llama REFRESHALL
EIS devolverá ERROR cuando:
1- Se haya producido un error al ejecutar el proceso
2- Se informó SuccessStateCode y el valor del mismo no coincide con el estado de cierre del proceso
3- El proceso devuelve una pantalla de warning (las que aparecen en un popup cuando se utiliza el agente web).
Se recomienda que el proceso Engage que se inicie con el servicio EKS quede siempre cerrado y que no necesite la interacción con el usuario. Esto es por un tema de prolijidad y para asegurarse que no aparezcan procesos pendientes en la inbox del usuario. De todas maneras, nada impide que el proceso termine de otra forma. Puede haber casos en los que sea válido que otro proceso quede iniciado en la inbox.
La ejecución del proceso Engage invocado por el servicio EKS es siempre sincrónica. Es decir, que el timeout de la transacción de socket debería contemplar el tiempo que tarda el proceso en ejecutarse. Si se necesita ejecutar en forma asincrónica, entonces se puede poner un 1 en el timeout de la transacción y contemplar el flujo de TimeOut como válido. La desventaja de esto es que no se va a poder saber cuál fue el estado de finalización del proceso.