20
xxxxxx ESPECIFICACION TECNICA DEL SERVICIO SVC_AC_004 – SINCRONIZACION DE CATALOGOS LIMA, Octubre 2018 1
xxxxxx
ESPECIFICACION TECNICA DEL SERVICIO
SVC_AC_004 – SINCRONIZACION DE CATALOGOS
LIMA, Octubre 2018
1
ÍNDICE
HISTORIAL DE VERSIONES.......................................................................................................... 3
Objetivo Del Servicio.............................................................................................................................. 3
REQUERIMIENTOS INICIALES.............................................................................................. 3
Actividades de Negocio Relacionadas........................................................................................................3
Requerimientos Específicos de Servicio.....................................................................................................4
Integración con Otras Aplicaciones y/o Servicios......................................................................................4
FUNCIONALIDAD DEL SERVICIO......................................................................................... 4
Funcionalidad Esperada......................................................................................................................... 4
Funcionalidad de Compensación............................................................................................................ 5
MODELADO DEL SERVICIO.................................................................................................... 5
Identificación Del Servicio...................................................................................................................... 5
Definición Conceptual del Servicio......................................................................................................... 5
Mensajes de Intercambio....................................................................................................................... 7
Tipo de Mensajes de Intercambio.............................................................................................................7
DISEÑO DEL SERVICIO............................................................................................................ 8
Lógica del Negocio.....................................................................................................................................8
Diagrama de Arquitectura del Servicio......................................................................................................9
Definición de los mensajes..................................................................................................................... 9
Entradas.....................................................................................................................................................9
Salidas......................................................................................................................................................10
2
Excepciones.............................................................................................................................................10
Implementación................................................................................................................................... 11
Códigos de tablas catalogo.................................................................................................................. 14
Archivos :............................................................................................................................................. 17
HISTORIAL DE VERSIONES
FICHA DE SERVICIO
OBJETIVO DEL SERVICIO
Permitirá actualizar la Base de Datos local del sistema cliente en las IPRESS
3
VERSIÓNPARTES QUE
CAMBIAN
DESCRIPCIÓN DEL
CAMBIO
FECHA DE
CAMBIO
MODIFICADO
POR
APROBADO
POR
1.0 InspiraIT
1.1 09/07/2018 ccarrillor
1.2
Agregado
Implementación,
Códigos de
tablas catalogo y
Archivos.
Cambio en la
extensión del
archivo del
ejemplo del
método
GetCatalogoDB.
06/11/2018 ccarrillor
REQUERIMIENTOS INICIALES
ACTIVIDADES DE NEGOCIO RELACIONADAS
La actividad de negocio relacionada es la realización de la Sincronización de catálogos para el sistema Cliente desde la IPRESS.
REQUERIMIENTOS ESPECÍFICOS DE SERVICIO
El requerimiento específico para el Servicio de Actualización de Catálogos es que el sistema cliente cuente con salida a internet para invocar el servicio. Así mismo el servicio requerirá el acceso a la base de datos y el permiso respectivo de lectura para la obtención de la información
INTEGRACIÓN CON OTRAS APLICACIONES Y/O SERVICIOS
Los Sistemas asociados al servicio:
- Sistema Cliente- Base de Datos de SITEDS.
ESQUEMA DE CAJAS
1. Sincronización de Catálogos
4
Sincronizacion de Catalogos
GetCatalogosDB
FUNCIONALIDAD DEL SERVICIO
FUNCIONALIDAD ESPERADA
Realizar la búsqueda y obtención de la nueva versión de los catálogos en la el repositorio de base de datos definida para el proceso de Acreditación.
FUNCIONALIDAD DE COMPENSACIÓN
Para este servicio no se ha considerado funcionalidad de compensación.
MODELADO DEL SERVICIO
IDENTIFICACIÓN DEL SERVICIO
NOMBRE: Sincronización de Catálogos SITEDS
CÓDIGO: SVC_AC_004
Asociación: Este servicio es de tipo Base.
DEFINICIÓN CONCEPTUAL DEL SERVICIO
Realizara la búsqueda y obtención de la nueva versión de los catálogos pertenecientes al Cliente y devolverá el resultado al sistema.
SERVICIO
CODIGO SVC_AC_004
Nombre Sincronizar Catálogos SITEDS
Descripción Realizar la búsqueda y obtención de la nueva versión de Catálogos pertenecientes al SITEDS v10.
Versión 0.1
Método de Descubrimiento
Top - down
5
Función de Negocio Buscar y obtener la nueva versión de los Catálogos pertenecientes al proceso de Acreditación que es utilizado por el Sistema SITEDS v10.
REQUERIMIENTO FUNCIONAL
RF1 - Realizar la búsqueda de la existencia de una nueva versión de catálogos, obtener el resultado luego validar si la versión encontrada es superior a la enviada por la IAFAS y devolver el resultado de la validación.
Implementación Realizar la Búsqueda de Catálogos Nuevos
TAXONOMIA
Tipo Proceso
Clasificación Back-End
CAPACIDADES
Nombre de la Capacidad
GetCatalogoDB
1. GetCatalogoDB
a. Diagrama de Componentes
ACREDITACION
Enviar Peticion Logica del Negocio Mostrar Resultado_ -
--
ESB
6
b. Tabla de Descripción de la Capacidad
CAPACIDAD
Servicio Sincronizar Catálogos SITEDS
Nombre GetCatalogoDB
Fuente Legado
Precondiciones El formato del archivo de la Trama debe de ser XML
Entrada Se enviara en binario el parámetro con la estructura XML.
Salida Se enviara en binario el parámetro con la estructura XML.
EXCEPCION
Nombre de la Excepción
El servicio manejara para las excepciones un listado de mensaje de error que estarán definidos en un repositorio general.
MENSAJES DE INTERCAMBIO
TIPO DE MENSAJES DE INTERCAMBIO
Un mensaje de WebSphere MQ tiene el formato típico “encabezado-cuerpo del
mensaje”.
El formato de mensajes a través de WebSphere MQ
Propiedades del mensaje (Encabezado del Mensaje)
Datos de la Aplicación (Cuerpo del Mensaje)
1. GetCatalogoDB
Descripción Tipo Entidad
de
Modo Detalle Frecuencia Restricción
7
Negocio de Uso
Obtener el
Catálogo
Asíncrono Catalogo
DB
Entrada Buscar y obtener
la nueva versión
del catalogo
A demanda
del Servicio
Repositorio
de Base de
Datos no
disponible.
Entregar
resultado
Asíncrono Catalogo
DB
Salida Devolver el
resultado al
sistema SITEDS
A demanda
del Servicio
Comunicació
n
interrumpid
a
DISEÑO DEL SERVICIO
LÓGICA DEL NEGOCIO
Diagrama de Logica de Negocio
Descripcion de la Logica del Negocio
8
1. Paso 1: El servicio se invocara desde el sistema Cliente; se enviarán lo
parámetros requeridos por el servicio.
2. Paso 2: El servicio validará que los parámetros enviados sean correctos. De ser
correctos los parámetros continuará en el siguiente paso; de no ser así se
devolverá un mensaje de error al sistema consumidos.
3. Paso 3: Una vez validados los parámetros se realizará la búsqueda de la nueva
versión en el repositorio de SUSALUD. De obtener el resultado lo enviara al
sistema consumidor externo.
4. Paso 4 :Manejo de Errores o Excepciones;
a. No se encontró un resultado; el sistema notificara mediante el resultado
que no existe ningún dato.
b. Bloqueo en la Base de datos; el servicio notificara al responsable técnico
del proceso. Así mismo devolverá un mensaje de error al sistema
consumidor externo.
c. Perdida de Conexión; el servicio notificara al responsable Técnico del
Proceso. Así mismo devolverá un mensaje de error al sistema consumidor
externo.
DIAGRAMA DE ARQUITECTURA DEL SERVICIO
9
DEFINICIÓN DE LOS MENSAJES
ENTRADAS
1. GetCatalogoDB
a. Nombre del XSD de entrada o Descripción del REQUEST
Variables de Entrada:
Input Tipo Elemento Long. Descripción
N nuVersion 1/10 Contendrá el Número de Versión actual del sistema.
AN noArchivo 1/20 Identificador único del archivo
Ejemplo:<?xml version="1.0" encoding="utf-8"?><SincroCatalogoRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.susalud.gob.pe/acreditacion/SincroCatalogoRequest.xsd"><nuVersion xmlns="">171</nuVersion><noArchivo xmlns="">archivoPruebaCor3e18.xml</noArchivo></SincroCatalogoRequest>
SALIDAS
1. GetCatalogoDB
a. Nombre del XSD de respuesta o Descripción del RESPONSE
Input Tipo Elemento Long. Descripción
AN coError 4/4 Código de error (ver Tabla N° 0) que indica si la transacción fue exitosa o se suscitó algún problema.
AN deRespuesta 1/10000 Un String codificado en base 64 que debe ser decodificado y convertido a archivo con extensión .zip, dentro de este archivo se encuentra un archivo XML con toda la Información de las tablas a actualizar.
Ejemplo:<NS1:SincroCatalogoResponse xmlns:NS1="http://www.susalud.gob.pe/acreditacion/SincroCatalogoResponse.xsd"><coError>0000</coError><deRespuesta><
UxOKvIzckrzckHAFBLBwgTtcU3CQAAAAcAAABQSwECFAAUAAgACACFZL9ME7XFNwkAAAAHAAAAEwAAAAAAAAAAAAAAAAAAAAAAYXJjaGl2b1BydWViYUNvcmUxOFBLBQYAAAAAAQABAEEAAABKAAAAAAA=]]></deRespuesta></NS1:SincroCatalogoResponse>
EXCEPCIONES
Para este servicio no se está utilizando excepciones, ya que se está utilizando un repositorio de mensajes personalizados.
CO_ERRWS DE_ERRWS DE_ERRUS DE_ESTADO
0000 Todo correcto Todo correcto 10800 No ingreso el número de la versión No ingreso el número de la versión 1
0810 El número de la versión es un campo numérico El número de la versión es un campo numérico 1
0820 No existen actualizaciones No existe actualizaciones posteriores a la versión ingresada 1
0010 Error en estructura XML de entrada Error en estructura XML de entrada 10020 Error del sistema Error del sistema0099 Error de base de datos Error de ejecución del procedimiento 1
Tabla N° 0. Códigos de error devueltos por el servicio.
IMPLEMENTACIÓN
Luego de haber decodificado la cadena en base 64 String y haberlo convertido a un
archivo con extensión .zip, este debe descomprimirse y se obtendrá un archivo .xml con
el nombre que se especificó en el mensaje que se envió con la petición.
La estructura XML que se obtiene es la siguiente:
1 2 3 4 5 6 7 8 91011
<?xml version='1.0' encoding='utf-8' ?><Data>
<Version><Datos>
<Registo><Dato>
<Campo>IN_ACTIVO</Campo><Valor>1</Valor>
</Dato><Dato>
<Campo>CO_ID1</Campo>
11
121314151617181920212223242526272829303132333435
<Valor>20001</Valor></Dato><Tabla>70</Tabla>
</Registo></Datos><Numero>79302</Numero>
</Version><Version>
<Datos><Registo>
<Dato><Campo>IN_ACTIVO</Campo><Valor>1</Valor>
</Dato><Dato>
<Campo>CO_ID1</Campo><Valor>20001</Valor>
</Dato><Tabla>70</Tabla>
</Registo></Datos><Numero>79305</Numero>
</Version></Data>
El elemento <Data> es el elemento raíz.
El elemento <Version> engloba toda la colección de registros de un lote, pueden existir
varios elementos de este tipo dentro de la etiqueta <Data>.
El elemento <Datos> representa un registro de una tabla, contiene a <Registo> que
encierra al elemento <Campo> y <Valor> y al elemento <Tabla> que representa al
código de la tabla a actualizar.
A continuación se define los sub elementos de <Datos>:
Cada elemento <Registo> representa a un registro de la tabla, Cada sub elemento
<Dato> representa una columna, dentro se encuentra el elemento <Campo> que
representa al nombre del campo y <Valor> que representa el valor de dicho campo. El
sub elemento <Tabla>, tiene el código de la tabla catalogo que se indica en la Tabla N° 1.
El elemento <Numero> representa el código de lote.
Cada etiqueta <Datos>, traerá un conjunto de elementos que representaran el estado
del registro, las claves primarias y foráneas de la tabla y campos con su respectivo
valor.A continuación se muestra un ejemplo de la representación XML de este
12
elemento, en este caso comprende valores para la tabla catalogo (ver Tabla N° 1 – Código
de tablas catalogo) número 70: SSTM_PRODUCTO.
1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031323334353637383940414243444546474849505152
<Datos><Registo>
<Dato><Campo>IN_ACTIVO</Campo><Valor>1</Valor>
</Dato><Dato>
<Campo>CO_ID1</Campo><Valor>10001</Valor>
</Dato><Dato>
<Campo>CO_ID2</Campo><Valor>W</Valor>
</Dato><Dato>
<Campo>CO_ID3</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO1</Campo><Valor>
<![CDATA[PRUEBA W]]></Valor>
</Dato><Dato>
<Campo>DE_ATRIBUTO2</Campo><Valor>
<![CDATA[0]]></Valor>
</Dato><Dato>
<Campo>DE_ATRIBUTO3</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO4</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO5</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO6</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO7</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO8</Campo>
13
5354555657585960616263646566676869707172737475767778798081828384858687888990919293
<Valor/></Dato><Dato>
<Campo>DE_ATRIBUTO9</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO10</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO11</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO12</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO13</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO14</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO15</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO16</Campo><Valor/>
</Dato><Dato>
<Campo>DE_ATRIBUTO17</Campo><Valor/>
</Dato><Tabla>70</Tabla>
</Registo></Datos>
Para realizar la actualización de las tablas en el aplicativo cliente, se debe generar los
scripts SQL dependiendo del motor de base datos de destino.
CÓDIGOS DE TABLAS CATALOGO
14
HOMOTABLASCATALOGONU_TABCATA NO_TABCATA44 SSTM_CIE106 SSTM_TIPO_DOCUMENTO50 SSTM_TIPO_FILIACION51 SSTM_TIPO_MONEDA119 SSTM_UBIGEO115 SSTM_CALIF_SERVICIOS17 SSTM_ESPECIALIDAD105 SSTM_ESTADO_CARTA117 SSTM_TIPO_PROCEDIMIENTO7 SSTM_GENERO116 SSTM_INDIC_PROCED103 SSTM_GRUPCIE10110 SSTM_INDI_RESTRIC111 SSTM_ESTADO112 SSTM_TIPO_PLAN122 SSTM_IAFAS8 SSTM_ESTADO_CIVIL120 SSTM_TIPO_DECLARACION127 SSTM_ERROR_SOLICITUD113 SSTM_TIPO_ENFERMEDAD128 SSTM_URL_SUSALUD129 SSTM_WS_EXCEPTION118 SSTM_GRUPCIE10_DET123 SSTM_IPRESS124 SSTM_TRANSFERENCIA49 SSTM_TIPO_DIAGNOSTICO114 SSTM_USO_GRUPCIE1070 SSTM_PRODUCTO46 SSTM_TIPO_COBERTURA71 SSTM_SUB_TIPOCOBERTURA48 SSTM_TIPO_AFILIACION
Tabla N° 1 – Código de tablas catalogo
-Para generar el script se utiliza las consultas SSSP_OBTENER_HOMOTABLASCATALOGO (Figura N° 1) y SSSP_OBTENER_HOMOCAMPOSCATALOGO (Figura N° 2) que se encuentran en el archivo DBUPDATE.mdb.
Las consultas SSSP_OBTENER_HOMOTABLASCATALOGO y SSSP_OBTENER_HOMOCAMPOSCATALOGO sirven para realizar la correlación entre los campos retornados por el servicio y los campos de las tablas catalogo a actualizar.
15
Figura N° 1
16
Figura N° 2
ARCHIVOS:
17
