Servicio de campañas de Web Services

Formato del mensaje del servicio de campañas de web services:

WSCAMPAIGNX|<PKEY Campaña>|<PKEY Transacción>|<Comando>[EOM]

Donde:

WSCAMPAIGNX: (Obligatorio y Fijo) Identificador del servicio de campañas de web services de EIS
<PKEY Campaña>: (Obligatorio) Pkey de la campaña
<PKEY Transacción>: (Obligatorio) Pkey de la transacción de socket con el formato del mensaje para consumir un determinado web service
<Comando>: (Obligatorio) Comando de campaña
[EOM]: (Obligatorio y Fijo) Terminador del mensaje

Los posibles comandos de campaña son los siguientes:

START([YYYY-MM-DD hh:mm:ss]): Inicia una campaña y la agrega a la lista de campañas activas. Para que este comando funcione, el ID de la campaña no debe existir en la lista de campañas activas, sin importar el estado actual de la misma. Este comando es sincrónico durante el parseo de la transacción de socket y asincrónico inmediatamente antes de iniciar las threads de trabajo (de lectura y ejecución de web services). Los posibles mensajes de retorno son: OK y ERROR

YYYY-MM-DD hh:mm:ss: (Opcional) Fecha de inicio de la campaña, con formato (AAAA-MM-DD HH:MM:SS). Si no se informa, o si la fecha informada es menor a la actual, la campaña inicia inmediatamente.

PAUSE(): Pausa una campaña. Para que este comando funcione, el ID de la campaña debe existir en la lista de campañas activas y el estado actual de la misma debe ser STARTED. Este comando será asincrónico si las threads de trabajo (de lectura y de ejecución de web services) todavía no iniciaron y sincrónico si ya lo hicieron. Los posibles mensajes de retorno son: OK y ERROR

CONTINUE(): Saca a una campaña de una pausa. Para que este comando funcione, el ID de la campaña debe existir en la lista de campañas activas y el estado actual de la misma debe ser PAUSED. Este comando es totalmente sincrónico. Los posibles mensajes de retorno son: OK y ERROR

STOP(): Finaliza una campaña. Para que este comando funcione, el ID de la campaña debe existir en la lista de campañas activas y el estado actual de la misma no debe ser un estado de terminación ni STOPPING (los estados de terminación son definitivos y cuando se llega a uno de ellos no admite el cambio a otro estado). Este comando es sincrónico sólo en el instante del cambio al estado transitorio STOPPING y asincrónico durante la transición definitiva a STOPPED (es decir, mientras la campaña realmente finaliza). Los posibles mensajes de retorno son: OK y ERROR

GETSTATUS(): Obtiene el estado actual de la campaña. Para que este comando funcione, el ID de la campaña debe existir en la lista de campañas activas, sin importar el estado actual de la misma. Este comando es totalmente sincrónico. Los posibles mensajes de retorno son: VALUE y ERROR

RESET(): Elimina definitivamente la campaña de la lista de campañas activas. Para que este comando funcione, el ID de la campaña debe existir en la lista de campañas activas y el estado actual de la misma debe ser un estado de terminación. Este comando es totalmente sincrónico. Los posibles mensajes de retorno son: OK y ERROR

Los estados posibles de la campaña son los siguientes:

UNAVAILABLE: Es el estado inicial de una campaña, antes de conocerse si debe iniciarse inmediatamete o si se debe esperar.
WAITING: Si se informa la fecha de inicio en el comando START y mientras dura la espera.
STARTED: La campaña fue iniciada mediante un comando START o sacada de una pausa mediante el comando CONTINUE.
PAUSED: La campaña fue pausada mediante un comando PAUSE.
STOPPING: La campaña está siendo detenida mediante un comando STOP.
STOPPED: (estado de terminación) La campaña fue detenida mediante un comando STOP.
FINISHED: (estado de terminación) La campaña finalizó exitosamente.
CRASHED: (estado de terminación) La campaña finalizó con errores.

El formato de los parámetros de entrada de la transacción de socket es el siguiente:

WSX|<ProxyLibraryName>|<WebServiceName>|<WebMethodName>|<CustPkey>|<JobPkey>|<UserId>|[<TransformationId>]|[<WebMethodParameters>][EOM]

Donde:

WSX: (Obligatorio y Fijo) Es el tipo de servicio y el modo del mensaje.
<ProxyLibraryName>: (Obligatorio) Nombre de la librería proxy (sin la extensión .dll)
<WebServiceName>: (Obligatorio) Nombre de la clase proxy dentro de la librería.
<WebMethodName>: (Obligatorio) Nombre del método web
<CustPkey>: (Obligatorio) Pkey del cliente
<JobPkey>: (Obligatorio) Pkey del trámite
<UserId>: (Obligatorio) Usuario Engage
<TransformationId>: (Opcional) Id de la transformación
<WebMethodParameters>: (Opcional) Lista de parámetros del método web
[EOM]: (Obligatorio y Fijo) Terminador del mensaje

La lista de parámetros del método web debe coincidir exactamente en cantidad, en ordenamiento y en los tipos de datos. EIS contempla parámetros por referencia. El formato genérico de la lista de parámetros del método web es la siguiente:
<TipoDatoSimple1>|<TipoDatoSimple2>|<TipoDatoComplejo1>|<TipoDatoSimple3>| …

Donde:
<TipoDatoSimple>: son tipos de datos básicos (Numéricos, Boolean, String, Enumeraciones, DateTime, etc)
<TipoDatoComplejo>: son estructuras o arrays.
El tipo de dato complejo, según sus características, puede informarse de dos maneras distintas:

1. En caso de tratarse de una clase que contenga sólamente atributos de tipos de datos simples, puede utilizarse la siguiente nomenclatura:

<NombreAtributo1>=<TipoDatoSimple>;<NombreAtributo2>=<TipoDatoSimple>; … ;<NombreAtributoN>=<TipoDatoSimple>

Donde:
<NombreAtributo>: es el nombre del atributo de la clase que quiere poblarse
<TipoDatoSimple>: es el valor que se le asignará al mismo, según la definición del punto anterior.

1. En caso de tratarse de un array o de clases que contengan atributos que sean arrays o clases anidadas, debe utilizarse un xml de serialización, cuyo formato puede inferirse mediante la herramienta EISProxyManager.

Consideraciones:

1. La transacción de socket debe estar asociada a un proceso que pertenezca al mismo tipo de cliente que se utiliza en la campaña.
2. La transacción de socket sólo debe tener parámetros de entrada y pueden ser de tipo FIJO, VARIABLE y FUNCTION.
3. En el caso de los parámetros variables, no se aceptan aquellos que sean parámetros de salida de otras transacciones o de stored procedures.
4. Cuanto menos parámetros variables contenga la transacción, más performante será la invocación al web service.
5. También habrá una mejor performance si en la transacción de socket no se informa un ID de transformación para el resultado del web service.