1.

- Solicitar URI del servicio a consumir

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”

URI (wsdl): http://10.49.15.149:7010/ES/GetContract/v1?wsdl

2.- Consumo del servicio en SoapUI

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.

Punto 1: se recomienda poner un nombre identificatorio

Punto 2: URI del servicio Soap

Una vez aceptado obtenemos el request o consulta del contrato WSDL

Verificamos donde muestra el rectángulo rojo si el Request está correctamente conformado

Punto 1: Indicadores de errores de conformación

Punto 2: Detalle de los errores indicados

Tomamos el XML Request y lo llevamos a un editor de texto como Notepad++

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.

Obtenemos una validación correcta y ejecutamos el servicio con nuestro Request.

Cuando el servicio responde correctamente tenemos tres formas de validar su ejecución correcta.

La primera es validar la respuesta a nivel de Cliente (SoapUI) – Servicio (GetContract)

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.

Llegados a este punto falta traspasar nuestro XML a ODI.

3.- Consumo del Servicio desde ODI.

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.

En tercer término y último creamos una topología Lógica asociada.

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.

Para este ejemplo usaremos una ruta hardocdeada o en duro.

Vamos a realizar una ejecución de prueba, para el caso validamos que en la ruta agregada no
existan archivos.

Luego ejecutamos el package donde creamos el llamado al servicio.

Luego que validamos la correcta ejecución desde el “Operator” vamos al área de la máquina.

Y vemos que se creo un archivo.

Lo abrimos .

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.

Esto es porque siempre se sigue un flujo:

1. Se invoca el Servicio de Token: http://10.49.23.55:7015/eoc/avmSecurity/getToken

2. Se guarda el token, como el del ejemplo:

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.

Visibilidad del Request.

Los pasos antes descritos en ODI pueden ser ejecutados como se indica.

Tablas ejemplo.

STG_INT835_PARAMETROS: Tabla paramétrica que guarda la información de URI’s y

usuario/password.

STG_INT835_ENTEL_INPUT_TOKEN: Tabla que almacena el token obtenido.

STG_INT835_JSON_REQUEST: Tabla que almacena los request json por registro.

El servicio que genera los Token se invoca desde el Procedure

PRC_008_RESTFUL_TOKEN

Solo debemos reutilizar el objeto (exportar/importar) y modificar las variables en las Option:

El procedure que invoca los servicios funcionales es para el ejemplo

PRC_009_RESTFUL_PRODUCT_ORDER

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.