Metodología de desarrollo y test de Web Services con EIS

Pasos:

1)      Obtención del WSDL
2)      Creación de la clase proxy
3)      Modificación del archivo .config
4)      Inspección de la clase proxy con EISProxyManager
5)      Prueba del método web desde EISProxyManager
6)      Según la estructura de la respuesta del método web:

1. Si la respuesta es un XML que vuelve como string, obtención del XSD que define al XML de parte de quien administre el web service
2. En caso de que no nos provean de lo anterior, creación de los XSD infiriéndolos a partir del XML
3. Creación de las clases de serialización a partir de los XSD

7)      Si el método web devuelve una respuesta, creación de la transformación para procesarla
8)      Según la estructura de los parámetros de entrada del método web:

1. Creación de los XML de serialización de parámetros cuyo tipo de dato sean estructuras complejas

9)      Creación del mensaje a EIS para invocar el método web
10)   Prueba del método web desde TCPTester, con la persistencia desactivada
11)   Creación de las entidades de Engage referenciadas en la transformación
12)   Prueba del método web desde TCPTester, con la persistencia activada
13)   Según la estructura de los parámetros de entrada de un método web en particular:

1. Creación de un SP para obtener los datos que se asignarán a los parámetros de entrada
2. Con Designer, definición del SP y de la transacción de SP

14)   Con Designer, definición de la transacción de socket que se utilizará para consumir el método web
15)   Integración de la transacción de socket en un proceso Engage
16)   Prueba del método web, ejecutando el proceso Engage desde el Agente Web.

Tiempos estimados de cada tarea:

Se asume que se cuenta con todos los elementos, que no se producen errores en la interacción con el web service y que la tarea la realiza alguien con los conocimientos necesarios y cierto expertisse.

1)      Depende de lo que tarden en darnos los datos que necesitamos.
2)      De 5 a 30 minutos.
3)      De 5 a 10 minutos.
4)      De 5 a 10 minutos.
5)      De 5 a 10 minutos.
6)      Sólo si aplica:

1. Depende de lo que tarden en darnos los datos que necesitamos.
2. De 10 a 30 minutos.
3. De 5 a 10 minutos.

7)      Dependiendo de la complejidad de la respuesta, de 30 minutos a 4 horas.
8)      De 10 a 30 minutos.
9)      De 10 a 20 minutos.
10)   De 5 a 10 minutos.
11)   Dependiendo de la cantidad y complejidad de las entidades, de 15 minutos a 1 hora.
12)   De 5 a 10 minutos.
13)   Sólo si aplica:

1. Dependiendo de la complejidad de la lógica del SP, de 15 minutos a 1 hora.
2. De 10 a 20 minutos.

14)   De 10 a 20 minutos.
15)   De 10 a 30 minutos.
16)   De 5 a 10 minutos.

Total, en el mejor de los casos con poca complejidad: 5+5+5+5+30+10+10+5+15+5+10+10+5 = 120 = 2hs.
Total, en el mejor de los casos con mayor complejidad: 5+5+5+5+10+5+30+10+10+5+15+5+15+10+10+10+5 = 160 = 2hs y 40 minutos.
Total, en el peor de los casos con mayor complejidad: 30+10+10+10+30+10+240+30+20+10+60+10+60+20+20+30+10 = 610 = 10hs y 10 minutos.

Conclusión: Según la complejidad del método web que se desea ejecutar, se puede tardar entre 2 horas y un día laboral y medio.

Comentarios punto por punto:

1)      Esto es básico, si no hay WSDL no hay integración con web services. Muchas veces nos pasan una url, pero aveces nos pasan un archivo. Si nos pasan un archivo, hay que asegurarse que nos pasen también todos los XSD referenciados en el WSDL.
2)      Si nos pasaron una url o un archivo sin referencias a XSDs, entonces hay que crear directamente el .bat para generar la clase proxy (a partir de los ejemplos provistos) y luego ejecutarlo. Si nos pasan un archivo con referencias a XSDs, entonces hay que poner todos los archivos (WSDL y WSDs) en un sitio web temporal para poder ejecutar el .bat sin problemas. Esto es así, porque el utilitario de Microsoft que se usa para crear las clases proxy a partir del WSDL sólo puede resolver las referencias a los XSDs cuando el WSDL se encuentra en una url. No puede hacerlo en el file system. Si al ejecutar el .bat se producen errores (por ejemplo por inconsistencias en el WSDL), hay que informar a quién nos proveyó el WSDL. Si el WSDL tiene errores o no puede ser interpretado, entonces no podemos continuar.
3)      Al generar la clase proxy, se crea un .config de ejemplo con los bindings y los endpoints del web service. Lo que hay que hacer en este paso es copiar uno a uno los items de configuración desde el .config de ejemplo a los .config de EIS y de EISProxyManager. Esta tarea puede hacerse editando los .config con Notepad.
4)      Se abre la dll con EISProxyManager, para poder observar el contenido de la clase proxy y otras estructuras de transporte, como así, los métodos web con sus parámetros de entrada y respuesta.

Los pasos anteriores se hacen por única vez para todos los métodos web del web service. A partir de aquí, los pasos se repiten por cada método web que se desea consumir.

5)      Ejecución del método web con parámetros de entrada de prueba, para comprobar que todo funciona correctamente. Si hay problemas (por ejemplo de comunicación o de disponibilidad del web service), hay que informarlos para poder continuar.
6)      Este paso debe hacerse sólo si el método web devuelve como respuesta un XML como un tipo de dato string:

1. Si nos pasan el XSD que define al XML de la respuesta (cosa que nunca sucede), entonces hay que saltar directamente al paso “c”.
2. Si no nos pasan el XSD, tendremos que armar previamente el .bat que genera el XSD a partir de un XML de ejemplo. Luego, hay que “mejorar” el XSD manualmente.
3. Armar y ejecutar el .bat que genera la clase de serialización a partir del XSD.

7)      Sólo en caso que el método web devuelva una respuesta y que se necesite procesarla, hay que armar la transformación que la inspeccione y extraiga la información necesitada.
8)      Sólo si existen parámetros de entrada cuyos tipos de dato sean estructuras complejas:

1. Utilizando EISProxyManager, se obtendrá la “forma” del XML de serialización que representa a la estructura del tipo de dato del parámetro de entrada.

9)      Se arma el mensaje TCP que se enviará a EIS para consumir el método web, incluyendo los parámetros de entrada.
10)   Se desactiva la persistencia de EIS y se utiliza la herramienta TCPTester para enviar el mensaje creado en el punto anterior. De esta manera, se puede comprobar que la transformación definida en el punto 7 funciona correctamente.
11)   Con Designer, se crean todas las entidades que se poblarán con los datos obtenidos de la respuesta del método web, una vez aplicada la transformación.
12)   Se activa la persistencia y se vuelve a probar el método web desde TCPTester, para comprobar que los inserts en las entidades se ejecutan correctamente.
13)   Sólo si se necesita ejecutar alguna lógica para obtener los datos que deben asignarse a los parámetros de entrada :

1. Crear un SP en la base de datos que obtenga los valores de los parámetros de entrada del método web
2. Se deben definir con Designer la metadata del SP y de la transacción de SP que se utilizará dentro de un proceso Engage

14)   Se define con Designer una transacción de socket que corresponde al mensaje TCP creado en el paso 9 y que fue probado con TCPTester.
15)   Dentro de un proceso Engage, se incluye la transacción de socket y, eventualmente, también la transacción de SP que se utilizará para obtener los valores de los parámetros de entrada. También se tienen en cuenta los distintos tipos de flujos de salida de cada transacción. De esta manera, se controla el flujo del proceso en caso de que se produzcan errores en la ejecución del método web.
16)   Se ejecuta el proceso Engage desde el Agente Web y se confirma que todo funciona como se espera.