IFS_S480_ValidateEquipoBlackList_EIR_0.6.docx

1. Interface Design Document [IDD]
IFS_480_ ValidateEquipoBlackList_EIR_0.6
Contenido
Interface Design Document [IDD] ......................................................................................................1
IFS_480_ ValidateEquipoBlackList_EIR_0.6.....................................................................................1
Sobre el servicio.................................................................................................................................2
Descripción del servicio..................................................................................................................2
Datos del Servicio visto desde Vlocity...............................................................................................2
Request...........................................................................................................................................2
Response........................................................................................................................................3
Errores (Retornados por Middleware)............................................................................................4
Datos del legado integrado ................................................................................................................5
Acerca del servicio legacy .................................................................................................................5
Integración con Web Service .........................................................................................................5
Ejemplos OK y NOK.......................................................................................................................6
Request...........................................................................................................................................7
Response........................................................................................................................................8
Errores (Retornados por Legacy)...................................................................................................9
Diseño Funcional Middleware ........................................................................................................9
Mapeos entre Vlocity y el legado.....................................................................................................11
Historial de cambios.........................................................................................................................12
Open Issues .....................................................................................................................................13

2. Sobre el servicio
Descripción del servicio
 Servicio que permitirá buscar imei en listas negras, el servicio se ejecutará hasta encontrar o no la
imei en todas las listas.
 La Integración es entre Vlocity y EIR (EQUIPMENT IDENTITY REGISTER).
 EIR (expone el servicio) <-- Vlocity (consume el servicio)
 Tipo de servicio: Síncrono
 Time Out: No se cuenta con esta información en este momento.
 Reintentos:No se cuenta con esta información en este momento.
 Requiere análisis de idempotencia: No
Datos del Servicio visto desde Vlocity
 HTTP METHOD:POST
Request
 Request
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
imei Si 1..1 IMEI a consultar. Equipo
listsFind No 0..1 Listado de nombres de las listas
donde se buscará, en caso de
no seguir el orden por defecto.
listsFind

3. Request/listsFind
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
listName Si 1..N Nombre de la lista donde se
realizará la búsqueda.
listName
Request/listName
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
codListaNegra Si 1..1 Lista en lacual se encuentra el
imei o imsi
listaNegra
Response
 Response
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
marcaEnListaNegra No 0..1 Código de respuesta de la
operación.
Posibles valores:
 0 si encontró
 1 si no lo encontró
listaNegra
mensaje No 0..1 Mensaje de respuesta. Se
devuelve cuando no se
encuentra el IMEI en alguna de
las listas
NoEntity/String
listaRecord No 0..1 Lista en la cual se encuentra el
IMEI
listaRecord

4.  Response/ListaRecord
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
imei Si 1..1 IMEI consultado Equipo
codListaNegra Si 1..1 Lista en la cual se encuentra el
IMEI
listaNegra
Errores (Retornados por Middleware)
Código Descripción
VAL0000868 Campo inválido
VAL0000869 Falta un campo obligatorio
VAL0060092 Operación no permitida al usuario
SEG0000870 Usuario no logueado
VAL0000871 Dato Inválido
VAL0000847 Lista incompatible con los datos enviados
TEC0000872 Server en modo pasivo
VAL0000873 NO existe el registro en la Base de datos
TEC0001000 Error de Base de datos
TEC0000473 Error interno del sistema
COM0000874 Error - Sin conexión a Base de datos
VAL0000876 Se requiere el campo listsFind porque no existe la lista por defecto

5. Datos del legado integrado
 Nombre del legado: EQUIPMENT IDENTITY REGISTER (EIR)
 Descripción: Esta consulta permite obtener los datos de un IMEI y/o IMSI en una lista.
Acerca del servicio legacy
Integración con Web Service
 WSDL (adjuntar WSDL) y Documentación del Servicio.
Este un servicio existente en el EIR. La definición del mismo fue entregada por EIR en el
documento IDS.
Ver documento de Manual de Interfaces de programación de EIR.
 EQUIPMENT IDENTITY REGISTER 5.1 - Manual de Interfaces de Programación
 Sección del documento: 4.1.1 Consultar por un IMEI y/o IMSI en una lista
DMAN_ESP_EIRS_Int
er-Prog_MC.PDF
WDSL adjunto:
WSDL Definition.zip
wdsl.txt

6. Ejemplos OK y NOK
Request Message Example
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ser="http://service.eir.mahindracomviva.com.ar/">
<soapenv:Header>
<ser:userCredentials>
<password>P@SSW0RD</password>
<organization>MCOM</organization>
<username>ADMIN</username>
</ser:userCredentials>
</soapenv:Header>
<soapenv:Body>
<ser:getDataFromList>
<!--Optional:-->
<getDataFromListRequest>
<imei>98798798798798</imei>
<imsi>987987987987980</imsi>
<listName>WLEI</listName>
<totalRecord>2</totalRecord>
</getDataFromListRequest>
</ser:getDataFromList>
</soapenv:Body>
</soapenv:Envelope>
Response Message Example: OK
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:getDataFromListResponse
xmlns:ns2="http://service.eir.mahindracomviva.com.ar/">
<return>
<key>IMEI: 98798798798798,IMSI: 987987987987980</key>
<record>
<imei>98798798798798</imei>
<imsi>987987987987980</imsi>
<list>WLEI</list>
<cause>2</cause>
<origin>WEB</origin>
<motive>1234</motive>
</record>
<code>0</code>
<description>Operation successfullycompleted </description>
</return>
</ns2:getDataFromListResponse>
</soap:Body>
</soap:Envelope>

7. Response Message Example: NOK
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>NO_DATA</faultstring>
<detail>
<ns2:DetailFault
xmlns:ns2="http://service.eir.mahindracomviva.com.ar/">
<errorCode>902</errorCode>
<errorDesc>Record does notexistin the database</errorDesc>
</ns2:DetailFault>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Request
 Request
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
imei Si 1..1 IMEI a consultar. String
imsi Si 1..1 IMSI a consultar. String
listName Si 1..1 Lista en la cual se encuentran el
IMEI o IMSI.
String
recordTotal No 0..N Máxima cantidad de registros a
obtener. Si el campo se
encuentra vacio devuelve todos
los registros encontrados
Integer

8. Response
 Response
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
key No 0..1 Representa la clave del registro
modificado.
String
listaRecord No 0..N Lista en la cual se encuentran el
IMEI o IMSI.
listaRecord
code No 0..1 Código de respuesta de la
operación.
String
descripcion No 0..1 Texto descriptivo con la
respuesta de la operación
String
 Response/listaRecord
Campo
Obligatorio
Cardinalidad
Descripción
Tipo
de
dato
imei No 0..1 IMEI consultado String
imsi No 0..1 IMSI consultado String
list No 0..1 Lista en la cual se encuentran el
IMEI o IMSI.
String
cause No 0..1 Código del motivo por el cual
se agregó en la lista indicada.
String
origin No 0..1 Origen desde el cual se
agregó en la lista.
String
motive No 0..1 Descripción por el cual se
agregó en la lista indicada
String

9. Errores (Retornados por Legacy)
Código Descripción
100 Campo inválido
101 Falta un campo obligatorio
102 Operación no permitida al usuario
103 Usuario no logueado
104 Dato Inválido
105 Lista incompatible con los datos enviados
106 Server en modo pasivo
902 NO existe el registro en la Base de datos
903 Error de Base de datos
904 Error interno del sistema
906 Error - Sin conexión a Base de datos
Diseño Funcional Middleware
1. El servicio tiene como objetivo determinar si el IMEI enviado en el request se encuentra bloqueado o no,
buscando en las listas especificadas en un listado por defecto (nameListsDefault) o en el listado enviado
como parámetro (listsFind).
 Actualmente la dinámica de búsqueda es regular en las primeras 3 listas e inversa en la última. Detalles
abajo.
 Hay 4 listas:
 LNP
 LNN
 LNI
 LBT
 A modo informativo ( No mapear por favor )
 LNP: Lista de terminales bloqueados
 LNN: Lista de terminales bloqueados
 LNI: Lista de terminales bloqueados
 LBT: Lista de terminales que NO estan bloqueados
 Como resultado obligatorio se intenciona que solo haya 3 respuestas disponibles:
 Si la respuesta a la búsqueda es exitosa, se esperará que la interfaz devuelva el IMEI y la lista en la que
lo encontró.
 "El terminal no está bloqueado"
 Error en caso de haberlo.

10.  Actualmente la lógica es la siguiente:
 Si el IMEI se encuentra en alguna de las listas primeras 3 listas (LNP, LNN y LNI) significa que está
bloqueado, debe devolver el mismo número de IMEI y el nombre de la lista en que fue encontrado.
 En cambio, si se encuentra en la última lista (LBT) significa que no está bloqueado. Ya que es una lista
"blanca", significando que los IMEIs que se encuentren ahí, no están bloqueados.
 Teniendo eso en cuenta, ejemplos:
 Si en el REQUEST se manda un IMEI deberá buscarlo en las primeras 3 listas, si lo encuentra, deberá
responder el mismo número de IMEI enviado y la lista en la que lo encontró.
 Si en el REQUEST se manda un IMEI deberá buscarlo en las primeras 3 listas, si no lo encuentra deberá
buscarlo en la cuarta, y si en la cuarta lo encuentra, significa que deberá responder "El terminal no está
bloqueado".
 Si en el REQUEST se manda un IMEI deberá buscarlo en las primeras 3 listas, si no lo encuentra deberá
buscarlo en la cuarta, y si en la cuarta NO lo encuentra, deberá responder con el mismo número de IMEI
enviado y en "codListaNegra" responderá LBT ya que fue esa la lista que develó que estaba bloqueado.
 Si el IMEI no se encuentra en las primeras 3 listas (LNP, LNN, LNI) pero si en la última (LBT), el legado
devolverá el error 902, en cuyo caso el servicio deberá responder "El terminal no se encuentra
bloqueado".
 Cualquier otro tipo de error debe mapearse y salir por soap-fault, de acuerdo a la tabla definida en el
mapeo de errores.
2. El servicio debe realizar la búsqueda en cada una de las listas pertenecientes al listado especificado (sea el
definido por defecto o el enviado como parámetro), y en el mismo orden en que se encuentran. Al momento
en que encuentre datos (O NO SE ENCUENTREN EN LA ÚLTIMA), retorna el nombre de la lista donde la
búsqueda fue exitosa y finaliza la ejecución.
3. El proveedor del servicio dispone de 4 listas (4 tablas en una misma base de datos), a saber:
 LNP: Lista Negra Personal
 LNN: Lista Negra Movistar, Claro, o Nextel
 LNI: Lista Negra Internacional
 LBT: Lista de IMEIs NO adulterados.
4. El legado espera el nombre de la lista donde se quiere realizar la búsqueda del IMEI (cuadro en verde). El
servicio debe recorrer el listado de izquierda a derecha, en el orden en que se definieron, y solicitar la
búsqueda (ejecutar el servicio getDataFromList) por cada nombre que encuentre.
 El listado de nombres de listas por defecto debe definirse en un key property para el servicio, de
nombre nameListsDefault. Los nombres de las listas debe ir separados por pipes ('|'). El orden propuesto
inicialmente es el que sigue, mas se puede cambiar de acuerdo a la necesidad del negocio:
LNP|LNN|LNI|LBT
 Si el consumidor decide cambiar este orden o reducir el número de listas donde buscar, debe definir este
nuevo orden y enviarlo como parámetro del servicio, en el tag listsFind, en donde se realizará la
búsqueda. Si este tag no es enviado, el servicio hará la búsqueda sobre el listado por defecto
(nameListsDefault).
 Acerca de las iteraciones:
 Si no existe nameListsDefault y no se envía listsFind, el servicio debe retornar error VAL0000876,
indicando que es obligatorio el envío del listado de nombres de listas donde buscar.
 Si la lista a buscar contiene solo un elemento, no llevará pipe y se iterará una única vez (se hará una
única llamada al servicio getDataFromList). Esto es, si nameListsDefault = LNN, solo se debe iterar una
vez contra el servicio getDataFromList, enviando como valor de lista a buscar “LNN”.
 Si nameListsDefault = WLEI|LNN|Black, el servicio debe iterar 3 veces contra el
servicio getDataFromList, donde la primera vez le pasará la lista WLEI, la segunda LNN y la tercera vez
le pasará la lista Black.

11.  Si el legado devuelve el código de error 902, el servicio debe seguir iterando, siempre y cuando tenga
elementos en la lista que recorrer.
5. Agregar un flag a la lista "LBT" para poder activarla y desactivarla según las necesidades del servicio.
6. En el servicio siempre se ingresarán IMEIs de 15 dígitos, pero a la hora de buscar en la 4° lista (LBT) solo se
tendrán en cuenta los primeros 8 dígitos.
 Ejemplo: Si el usuario ingresa el IMEI 123456789101112, al buscar en las primeras 3 listas (LNP, LNN,
LNI) buscará con todos los números, pero al llegar a la última lista (LBT), solo ingresará "12345678".
Mapeos entre Vlocity y el legado
 Se debe indicar la relación que exista entre los datos del “Request” o del “Response” requrido
por Vlocity y el legado. La implementación de este mapeo se resolverá en el middleware, esta
implementación no se especifica en este documento.
Campo Vlocity Campo Legado Req/Resp Descripción
imei imei REQ
listsFind - REQ
codListaNegra listName REQ
- imsi REQ Valor que siempre irá
vacío.
- recordTotal REQ Campo no necesario
- key RES Campo no necesario
listaRecord listaRecord RES
marcaEnListaNegra code RES
mensaje descripcion RES
imei imei RES
- imsi RES Campo no necesario.
codListaNegra list RES
-
cause RES Campo no necesario
-
origin RES Campo no necesario
- motive RES Campo no necesario

12. Historial de cambios
Fecha Versión ID JIRA Modificado Por Descripción
0.1 Jorge Gutiérrez Versión Inicial
0.2 Jorge Gutiérrez Del lado de MW, se
ajustó el request y el
response para usar
solo lo que en
realidad necesitan.
0.3 Jorge Gutiérrez Se ajustó la
estructura tanto en
request como en
response por parte
de Vlocity.
0.4 Jorge Gutiérrez Se ajustó la
cardinalidad y
obligatoriedad de
campos del
response de parte
del legado
0.5 Jorge Gutiérrez Se cambió la
cardinalidad del
campo RecordTotal
15/09/2018 0.6 Jorge Suppicich Se corrige codigos
de Error de MDW y
se agrega
descripcion
functional de
integracion de MDW

13. Open Issues
Open Issue Asignado a Persona responsable Descripción Resolución