Documentos de Académico
Documentos de Profesional
Documentos de Cultura
La URI o URL del WSDL (o del servicio Rest) del servicio a consumir desde ODI es la primera y más
importante información para requerir desde Entel.
Para el caso utilizaremos de ejemplo el servicio eUsb “GetContract” que nos retorna a partir del
número de teléfono del cliente el identificador del contrato del cliente en Entel. Para validar
primero si tenemos acceso al servicio con nuestra VPN o si está disponible dentro de la red, o en
último caso si el servicio está disponible, es suficiente con cargarlo en un navegador web. Como
muestra el ejemplo:
URI: http://10.49.15.149:7010/ES/GetContract/v1
En el ejemplo anterior la carga falla porque falta agregar al final de la URI “?wsdl”
SoapUI es un software que permite consumir servicios Soap y Rest. Para el caso se asume que el
usuario maneja SopaUI. Creamos un nuevo proyecto Soap a partir de la URI.
Lo que haremos es eliminar toda la basura que está demás. En este caso todos los comentarios
entre corchetes “<>”. Solo haremos reemplazos.
Y lo repetimos hasta que quedemos con solo el XML Request limpio.
Tomamos entonces nuestro XML resultante y lo llevamos a SoapUI. Y con el botón derecho le
damos “Format XML”
Con esto identamos y ordenamos nuestro XML.
Luego de eso debemos deshacernos de los Tag del XML que no son requeridos para nuestra
funcionalidad, como muestran los ejemplos de más abajo.
Hecho lo anterior, volvemos a validar nuestro XML con lo que vimos anteriormente. Y obtenemos
un XML más acotado a lo que necesitamos, como también se acotaron los errores como muestran
los ejemplos.
Este resultado lo llevamos a Notepad++ y le asignamos valores reales y correctos para nuestra
funcionalidad. Como muestran los ejemplos de más abajo.
Con eso vamos nuevamente a SoapUI y validamos nuestro Request.
El estatus 200 (o 204) nos indica que se comunican correctamente, y que el XML Request es
esquemáticamente correcto, basándose en el contrato WSDL.
La segunda forma es verificar si dentro de la estructura del XML Response (respuesta) viene un
estatus estandarizado, como el que muestra el ejemplo. El estatus OK nos indica que según las
reglas del servicio desarrollado se completó correctamente el consumo.
Por último, la tercera forma de validar es que recibimos en el Body del SML Response los valores
que son requeridos en nuestro desarrollo. En nuestro caso es el contrato asociado al número
telefónico.
Para el caso nos valdremos del objeto ODI “OdiInvokeWebService” de la paleta de la izquierda.
Este objeto se vale de la topología física que se crea en la pestaña Topology de ODI.
Le asignamos un nombre (Name) según el estándar y la URI que hemos estado consumiendo
desde SopaUI.
Lo segundo es crear un esquema, que resulta ser automático. Como muestra el ejemplo.
Con esta ultima le asignamos la topología lógica al objeto ODI. Como muestran las siguientes
imágenes.
Se destaca en negrita como se agrega la topología lógica.
Para la operación (en negrita) debemos bucear un poco.
Vamos de nuevo al navegador web y cargamos el WSDL del URI, si hacemos una búsqueda por
“operation name” encontraremos el nombre que debemos traspasar al objeto ODI.
Lo siguiente es traspasar el XML que conformamos anteriormente al objeto ODI, donde muestra el
ejemplo.
Lo que se muestra en el rectángulo rojo es lo que se ha estandarizado en los desarrollos similares
construidos en Entel. Lo que se modifica por desarrollo de proyecto es la ruta dinámica que
asignamos con las variables, donde muestra el rectángulo rojo.
Y verificamos que la respuesta almacenada en el archivo es consistente con la que recibimos desde
SoapUI.
4.- Consumir servicios Rest.
Lo primero y más importante es que Entel proporcione un Request Json mapeado y un ejemplo de
request con datos.
Teniendo eso lo segundo más importante es un Usuario y Password para generar el Token
requerido para invocar los servicios Rest.
cwtoken
"eyJraWQiOiJjdyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJFcmljc3NvbkFWTSIsImF1ZCI6I
mNkdjFwcmV3bHNlb2NlbDF2MDEiLCJleHAiOjE1NTM2MzMzMzIsImp0aSI6IkdTZGxnQzdtaj
hWWGNtT2hUMEVlMHciLCJpYXQiOjE1NTM2Mjk3MzIsInN1YiI6IkNBUkdBXzAwMDEiLCJ1c
2VySWQiOiJDQVJHQV8wMDAxIn0.h1khpZWzAyn0vv_zGY1Gj1FzgT3NUqYogVjXt0-
KApSuLnnh9WT1mOUjqAzcKl0UP8UzviQ-tJO7VGoquBMb-
tR4_i65nUEAFiXyq3EsUdDRmSWnqp-9pCeCZYsrUT7m9GPa-
4XzwKg7DUGl7s5ZqfIpxhU685WxiH8L4Hr9xWnk-MCKT-
GKO1DK13UfVUiHOHkq_Z7EdPhh2VhqO4AR0MhyyRz5hUNX4zxWOjwnO_2gP8N_haSqre_
ECwHQNNtYZbBtqA2G7J73qq7fSgbL1wPhxihbpRLJHDg2OIo2cPx_Qf0qWCF4M-
mts3oLRswx7VFCXX9s8KtWZvQDFFlxdA"
3. El Token tiene un tiempo de vida de 20 minutos, por lo que este se debe verificar cada 20
minutos y si el tiempo pasó se debe recuperar.
4. Ejecutar el servicio requerido para la funcionalidad
(http://10.49.23.55:7015/eoc/integration/v2/ProductOrder/) pasándole el token como
muestra el rectángulo rojo.
Agregamos el Request Json validado y ejecutamos. Si recibimos una respuesta 200 indica
que la comunicación Cliente – Servicio funciona correctamente. Una respuesta 204
además de lo anterior indica que se cumplió la funcionalidad requerida.
Tablas ejemplo.
PRC_008_RESTFUL_TOKEN
Solo debemos reutilizar el objeto (exportar/importar) y modificar las variables en las Option:
Solo debemos reutilizar el objeto (exportar/importar) y modificar las variables en las Option:
La variable ejemplo que valida el tiempo de vida del token es VL_00835_TIMELIFE_TOKEN
Finalmente respuesta 204 en el Procedure ODI indica que se cumplió la funcionalidad requerida.