Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Marco de Interoperabilidad para Gobierno Digital 3 PDF
Marco de Interoperabilidad para Gobierno Digital 3 PDF
Equipo de trabajo
Sylvia Cristina Constaín Rengifo – Ministra de Tecnologías de la Información y las Comunicaciones
Jehudi Castro Sierra - Viceministro de Economía Digital
Claudia Patricia Pico Quintero – Director Gobierno Digital (E)
Leydi Viviana Cristancho Cruz – Subdirectora de Estándares y Arquitectura TI
Versión Observaciones
Versión 1 Marco para la Interoperabilidad del Gobierno en línea Estrategia de Gobierno en línea de la República de
Marzo 2010 Colombia
Marco de Interoperabilidad para gobierno digital - Documento técnico dirigido a las entidades públicas del
Versión 2 Estado Colombiano, en el que se reestructura la versión anterior del Marco, se incorpora una metodología e
Marzo 2019 instrumentos y se actualiza el contenido con un enfoque de Arquitectura para realizar el intercambio de
información entre las entidades del Estado a través de la Plataforma de Interoperabilidad (PDI).
Este documento de la Dirección de Gobierno Digital se encuentra bajo una Licencia Creative Commons Atribución 4.0 Internacional.
2
Tabla de Contenido
Contenido
INTRODUCCIÓN ..................................................................................................................... 7
DEFINICIONES ........................................................................................................................ 9
ANTECEDENTES Y MARCO JURÍDICO ........................................................................................... 12
COLABORACIÓN ENTRE ENTIDADES PARA EL INTERCAMBIO DE INFORMACIÓN EN LA ADMINISTRACIÓN PÚBLICA
16
OBJETIVOS DEL MARCO DE INTEROPERABILIDAD .......................................................................... 18
¿QUIÉNES DEBEN USAR EL MARCO DE INTEROPERABILIDAD? ........................................................... 18
ÁREAS DE APLICACIÓN DE LA INTEROPERABILIDAD ........................................................................ 19
PRINCIPIOS .......................................................................................................................... 27
ENFOQUE EN EL CIUDADANO ................................................................................................... 28
COBERTURA Y PROPORCIONALIDAD ........................................................................................... 28
SEGURIDAD, PROTECCIÓN Y PRESERVACIÓN DE LA INFORMACIÓN .................................................... 28
COLABORACIÓN Y PARTICIPACIÓN ............................................................................................. 29
SIMPLICIDAD ........................................................................................................................ 29
NEUTRALIDAD TECNOLÓGICA Y ADAPTABILIDAD ........................................................................... 30
REUTILIZACIÓN ..................................................................................................................... 30
CONFIANZA ......................................................................................................................... 31
COSTO-EFECTIVIDAD .............................................................................................................. 31
DOMINIOS ........................................................................................................................... 32
DOMINIO POLÍTICO - LEGAL ..................................................................................................... 33
DOMINIO ORGANIZACIONAL ................................................................................................... 37
DOMINIO SEMÁNTICO ........................................................................................................... 43
4.3.1 LENGUAJE COMÚN DE INTERCAMBIO DE INFORMACIÓN .................................................................... 43
4.3.2 LINEAMIENTOS DOMINIO SEMÁNTICO .......................................................................................... 43
DOMINIO TÉCNICO ................................................................................................................ 47
4.4.1 ARQUITECTURA ......................................................................................................................... 47
4.4.2 METODOLOGÍA IMPLEMENTACIÓN DE SERVICIOS WEB...................................................................... 51
4.4.3 DISEÑO FUNCIONAL DEL SERVICIO WEB ......................................................................................... 57
4.4.4 DISEÑO TÉCNICO DEL SERVICIO WEB ............................................................................................. 60
4.4.5 PRUEBAS DEL SERVICIO WEB ........................................................................................................ 62
4.4.6 DESPLIEGUE DEL SERVICIO ........................................................................................................... 65
4.4.7 IMPLEMENTACIÓN SERVICIOS WEB............................................................................................... 70
3
4.4.8 MAPA DE ESTADOS DEL SERVICIO ................................................................................................. 72
ANEXOS ............................................................................................................................... 80
ANEXO 1. INTEGRACIÓN WS - PDI .................................................................................................... 81
ANEXO 2. TRANSFERENCIA DE ARCHIVOS GRANDES ............................................................................... 90
ANEXO 3. DOCUMENTO MODELO DE MADUREZ .................................................................................... 94
4
Lista de Ilustraciones
5
Lista de Tablas
Tabla 1 Actividades Dominio Político-Legal ........................................................................ 37
Tabla 2 Actividades Dominio Organizacional ...................................................................... 42
Tabla 3 Actividades Dominio Semántico ............................................................................. 46
Tabla 4 Componentes de la arquitectura de referencia...................................................... 51
Tabla 5 Roles y Responsabilidades ...................................................................................... 53
Tabla 6 Componentes Diseño Web ..................................................................................... 56
Tabla 7 Actividades Diseño Funcional ................................................................................. 60
Tabla 8 Actividades diseño técnico ..................................................................................... 62
Tabla 9 Actividades Pruebas del servicio ............................................................................ 65
Tabla 10 Actividades Despliegue del servicio ...................................................................... 70
Tabla 11 Componentes Arquitectura .................................................................................. 72
Tabla 12 Estados del servicio .............................................................................................. 73
Tabla 13 Niveles de madurez Marco de Interoperabilidad ................................................. 75
6
Introducción
7
El Marco de interoperabilidad de Gobierno Digital surge con el propósito de contribuir en
la entrega de servicios digitales, de manera completa, adecuada, minimizando los pasos y
evitando el desplazamiento del ciudadano a diversas entidades para obtener la información
necesaria de una entidad y acceder así a sus derechos y obligaciones con el Estado. La
interoperabilidad permite fortalecer la visión de unidad del Estado, al tener una mayor
capacidad de comunicación, entrega y uso de servicios digitales de valor para mejorar la
calidad de vida de los ciudadanos.
8
Definiciones
• Dato Sensible: Información que afecta la intimidad de las personas o cuyo uso
indebido puede generar discriminación.
9
• Servicios Ciudadanos Digitales: Es el conjunto de soluciones y procesos transversales
que brindan al Estado capacidades y eficiencias para su Transformación Digital, para
lograr una adecuada interacción del ciudadano con el Estado, garantizando el
derecho a la utilización de medios electrónicos ante la administración pública.
• Servicios Ciudadanos Digitales Especiales: Son aquellos que brindan soluciones que
por sus características realizan nuevas ofertas de valor y son adicionales a los
Servicios Ciudadanos Digitales Base, o bien, corresponden a innovaciones que
realizan los prestadores de servicio a partir de la integración a los Servicios
Ciudadanos Digitales Base, esto bajo un esquema coordinado por el articulador.
• Trámite: Conjunto o serie de pasos o acciones reguladas por el Estado, que deben
efectuar los usuarios para adquirir un derecho o cumplir con una obligación prevista
o autorizada por la Ley. El trámite se inicia cuando ese particular activa el aparato
público a través de una petición o solicitud expresa y termina (como trámite) cuando
la administración pública se pronuncia sobre éste, aceptando o denegando la
solicitud.
1
Definición SOA Reference Arquitecture – Open Group http://www.opengroup.org/soa/source-
book/soa/p1.htm#soa_definition
10
características: Autocontenido, puede estar compuesto por otros servicios y es una
“caja negra” para los consumidores del servicio”2
2
Marco Europeo de Interoperabilidad (EIF) (2017) Tomado de https://eur-lex.europa.eu/legal-
content/ES/TXT/DOC/?uri=CELEX:52017DC0134&from=ES
11
Antecedentes y marco jurídico
El presente documento se enmarca en la Política de Gobierno Digital, que contribuye a un
nuevo enfoque en donde las TIC son fundamentales para mejorar el funcionamiento de las
entidades públicas y su relación con otras entidades, aportando un entorno de confianza
digital entre el ciudadano y el Estado.
• La Ley 1151 de 2007 del Plan Nacional de Desarrollo, en su artículo 6, numeral 6.2.2,
establece que “se avanzará en la automatización de trámites, para lo cual cada
12
sector desarrollará los sistemas de información requeridos haciendo uso de la
Intranet Gubernamental”.
• La ley 1753 de 2015 del Plan Nacional de Desarrollo menciona en el “Artículo 45.
Estándares, modelos y lineamientos de tecnologías de la información y las
comunicaciones para los servicios al ciudadano. Bajo la plena observancia del
derecho fundamental de habeas data, el Ministerio de las Tecnologías de la
Información y las Comunicaciones (MinTIC), en coordinación con las entidades
responsables de cada uno de los trámites y servicios, definirá́ y expedirá́ los
estándares, modelos, lineamientos y normas técnicas para la incorporación de las
Tecnologías de la Información y las Comunicaciones (TIC), que contribuyan a la
mejora de los trámites y servicios que el Estado ofrece al ciudadano, los cuales
deberán ser adoptados por las entidades estatales y aplicarán, entre otros, para el
siguiente caso:
(…) j) Interoperabilidad de datos como base para la estructuración de la estrategia
que sobre la captura, almacenamiento, procesamiento, análisis y publicación de
grandes volúmenes de datos (Big Data) formule el Departamento Nacional de
Planeación. (…)”
13
organizaciones privadas y entidades del Estado para intercambiar información y
conocimiento, en el marco de los procesos de negocio, con el propósito de facilitar
la entrega de servicios a ciudadanos, empresas y a otras entidades para intercambiar
información, aporte de documentos y datos en línea”.
• Ley 1955 de 2019 por el cual se expide el Plan Nacional de Desarrollo 2018-2022.
"Pacto por Colombia, Pacto por la Equidad” en su artículo 147 Transformación
Digital Pública y el principio de “plena interoperabilidad entre los sistemas de
información públicos que garantice el suministro e intercambio de la información de
manera ágil y eficiente a través de una plataforma de interoperabilidad. Se habilita
de forma plena, permanente y en tiempo real cuando se requiera, el intercambio de
información de forma electrónica en los estándares definidos por el Ministerio TIC,
14
entre entidades públicas. Dando cumplimiento a la protección de datos personales
y salvaguarda de la información”.
Respecto a la región, en Latinoamérica se pueden destacar iniciativas que han hecho países
del cono sur del continente como Uruguay con el trabajo realizado por la Agencia de
Gobierno Electrónico y Sociedad de la Información del Conocimiento AGESIC. En síntesis,
los ámbitos de aplicación de la interoperabilidad internacional han sido fundamentales
como modelo para el desarrollo y la puesta en marcha de la actualización del Marco de
Interoperabilidad para Gobierno Digital. 4
3
Marco Europeo de Interoperabilidad (EIF) (2017) Tomado de https://eur-lex.europa.eu/legal-
content/ES/TXT/DOC/?uri=CELEX:52017DC0134&from=ES
4
Agencia de Gobierno Electrónico y Sociedad de la Información del Conocimiento – AGESIC
https://www.gub.uy/agencia-gobierno-electronico-sociedad-informacion-conocimiento/
15
Colaboración entre entidades para el
intercambio de información en la administración
pública
Un gran reto de la administración pública es hacer que el Estado funcione como una sola
entidad eficiente que le brinde a sus ciudadanos información oportuna, trámites y servicios
en línea ágiles, para esto las entidades públicas deben cooperar y estar digitalmente
conectadas de manera articulada como un único gran sistema. La sociedad y la tecnología
se encuentran en una permanente y constante evolución, por lo tanto, las relaciones entre
las entidades públicas y de estas con el ciudadano, debe mantenerse a la par de la evolución
del sector público, buscando garantizar el máximo aprovechamiento de las TIC en el
desarrollo de sus funciones, teniendo en cuenta que una Sociedad Digital debe contar con
un Gobierno Digital.
Las entidades públicas, los ciudadanos y las empresas deben inevitablemente interactuar
en diferentes momentos y para ello las entidades públicas están modernizando sus
administraciones mediante la introducción de trámites y servicios digitales. Sin embargo, al
hacerlo, se arriesgan a crear entornos digitales aislados y en consecuencia generar barreras
que impiden que las entidades públicas se conecten entre sí, con los ciudadanos y las
empresas. Adicionalmente, la falta de interoperabilidad es un obstáculo importante para el
progreso y la Trasformación Digital de las entidades públicas e impide la prestación de
trámites y servicios en línea sólidamente interconectados y construidos para ser
automáticos, con las restricciones temporales y de contenido. Una solución a esto son los
esfuerzos para digitalizar el sector público y la coordinación que ello implica a nivel nacional
que evita así la fragmentación digital de los trámites, servicios y datos.
16
Interoperabilidad es promovido y mantenido por el Ministerio de Tecnologías de la
Información y las Comunicaciones.
17
Objetivos del Marco de Interoperabilidad
Los objetivos del marco de interoperabilidad son:
• Apoyar a las entidades públicas en sus esfuerzos por diseñar y ofrecer trámites y
servicios en línea a otras entidades públicas, ciudadanos y empresas que, en la
medida de lo posible, sean digitales por defecto, es decir, que proporcionen servicios
y datos preferentemente a través de medios digitales, siendo accesibles para todas
las entidades, los ciudadanos y que permitan la reutilización, participación, acceso y
transparencia.
• Proporcionar orientación a las entidades públicas sobre el diseño y la actualización
de los mecanismos de interoperabilidad, sus políticas, estrategias y directrices, así
como la visión nacional que se promueve en interoperabilidad;
• Contribuir al fortalecimiento de mecanismos de interoperabilidad en las entidades
públicas para la prestación de trámites y servicios en línea.
18
• Organizaciones privadas involucradas en la ejecución y/o evolución de la estrategia
de Gobierno Digital.
• Miembros de gobiernos extranjeros interesados en la interoperabilidad con
entidades del Estado colombiano.
• Miembros de la comunidad académica interesados en la interoperabilidad del
Gobierno Digital.
Las distintas entidades del Estado suelen requerir información de otras entidades para
brindar servicios a los ciudadanos, empresas y a otras entidades. En múltiples casos, la
información que requiere una entidad es gestionada por otra entidad, lo que en la práctica
ha significado que el ciudadano deba desplazarse de un lugar a otro para obtener dicha
información.
19
Ilustración 1. Servicio de Intercambio de Información
20
Modelo conceptual de la
interoperabilidad
21
Modelo conceptual del marco de
interoperabilidad
22
decisiones que se tomen alrededor de los acuerdos, estructuras y responsabilidades
necesarias para realizar los ejercicios de interoperabilidad.
Para esto la interoperabilidad tendrá los resultados esperados si las directivas de todos los
actores implicados priorizan los recursos necesarios y así garantizan mantener en el tiempo
estos acuerdos de intercambio de información.
Los recursos asignados deben propender por generar las competencias y habilidades
suficientes para estandarizar, consumir y prestar servicios de intercambio de información.
Así mismo las entidades deben fomentar la colaboración y participación entre sí para
facilitar los intercambios de información, lo anterior está orientado a buscar estrategias de
interoperabilidad que contemplen los dominios de interoperabilidad definidos en este
marco.
23
veces, que será el responsable de la adopción y materialización de lo comprendido en este
Marco.
24
Ilustración 3 Procesos gobernados de interoperabilidad
o Definición de servicio
o Planeación de implementación del servicio
o Modelado de servicio
o Estandarización de la información del servicio
o Implementación, ensamblado o adquisición del servicio
o Plan de pruebas sobre el servicio
25
o Despliegue del servicio
o Gestión y monitoreo del servicio
o Soporte sobre el servicio
o Definición de solución
o Planeación de la implementación de la solución
o Planeación de reutilización de servicios
o Despliegue de la solución
o Modelado de la solución
o Implementación, ensamblado o adquisición de la solución
o Plan de pruebas sobre la solución
o Gestión y monitoreo de la solución
o Soporte sobre la solución
26
Principios
27
Los principios dentro del Marco de Interoperabilidad son aspectos fundamentales para
impulsar y orientar el desarrollo de capacidades sobre los servicios de intercambio de
información, tanto al interior de las entidades públicas u organizaciones privadas, como
para ofrecerle mejores trámites y en generar servicios digitales ágiles a los ciudadanos, a las
empresas u otras entidades públicas.
Enfoque en el ciudadano
Deberán tenerse en cuentas necesidades de los ciudadanos, empresas y otras entidades
públicas para determinar cuáles servicios de intercambio de información deben ofrecer
prioritariamente y cuál es la forma en que deben hacerlo.
Cobertura y proporcionalidad
La interoperabilidad deberá ser aplicada en cualquier tipo de entidad del orden nacional,
departamental o municipal. También deberá ser utilizado por parte de organizaciones
privadas cuando interactúen con el Estado. Así mismo, cada entidad deberá vincular los
servicios de intercambio de información a los Servicios Ciudadanos Digitales mediante el
servicio de interoperabilidad y su integración a la plataforma de Interoperabilidad, de
acuerdo con los lineamientos dados en la materia.
28
Aquellos datos que pertenezcan a ciudadanos y cuya pérdida y/o alteración pueda significar
algún tipo de inconveniente para ellos con el Estado, deberán ser especialmente protegidos
evitando el uso no autorizado y garantizando su integridad, disponibilidad y resguardo.
Colaboración y participación
Las entidades en atención a los dispuesto en la Ley 489 de 1998 respecto al principio de
coordinación y colaboración armónica entre entidades y demás normatividad aplicable,
deberán estimular y participar de los esquemas de interoperabilidad entre los sistemas de
información públicos que garantice el suministro e intercambio de la información de
manera ágil y eficiente.
Simplicidad
En la medida de lo posible, las entidades públicas deberían racionalizar y simplificar sus
trámites, servicios y otros procedimientos administrativos mediante la optimización de los
mismos, evitando exigir documentos, certificaciones, constancias u otros actos
administrativos que pueden ser verificados, compartidos o intercambiados a través de los
servicios de intercambio de información.
29
Recomendación 6: Los servicios de intercambio de información deben responder a la
necesidad concreta que buscan atender, fomentando siempre que su construcción,
operación y mantenimiento minimicen la complejidad administrativa, técnica y operativa
involucrada.
Recomendación 7: Se deben simplificar los procesos y utilizar canales digitales siempre que
sea apropiado para la prestación de trámites, servicios y otros procedimientos
administrativos, para responder rápidamente y con una calidad elevada a las solicitudes de
los usuarios y reducir la carga administrativa de las entidades públicas, las empresas y los
ciudadanos.
Recomendación 9: Garantizar la estandarización de los datos, es decir, que los datos sean
semántica y sintácticamente interpretables, transferibles entre las aplicaciones y sistemas
de información.
Reutilización
Reutilizar se interpreta como la posibilidad a través del cual las entidades públicas pueden
aprovechar el conocimiento previamente adquirido por ellos mismos u otras entidades,
sobre soluciones tecnológicas o experiencia en la implementación de servicios de
intercambio de información de una forma coordinada, de fácil acceso y adopción.
30
Recomendación 10: Reutilizar y compartir conocimiento, experiencias y cooperar en el
desarrollo de soluciones conjuntas durante la implementación de servicios de intercambio
de información para los trámites, servicios y otros procedimientos administrativos.
Recomendación 11: Siempre que sea posible reutilizar y compartir información y datos
durante la implementación de los trámites, servicios y otros procedimientos administrativos.
Confianza
Las entidades deben garantizar que los servicios de intercambio de información ofrecidos
entregan información exacta y confiable. Adicionalmente, los datos que sean
proporcionados deberán cumplir con criterios de calidad.
Costo-efectividad
Las inversiones para que las entidades públicas puedan ofrecer servicios de intercambio de
información deben generar beneficios que justifiquen, compensen e idealmente excedan
los gastos incurridos. A pesar de esto, las dimensiones de evaluación de los beneficios no se
deberán limitar a los económicos o cuantificables, a través de algún análisis financiero. Se
deberán incluir dimensiones asociadas con el aumento del bienestar de ciudadanos y
empresas, y con la calidad que ellos perciben en su relación con el Estado.
31
Dominios
32
La interoperabilidad, si bien generalmente ha sido entendida como la habilidad de dos o
más sistemas o componentes para intercambiar y utilizar información, no es un concepto
meramente técnico. Involucra retos de diversos tipos para el intercambio efectivo de
información, bajo un enfoque sistémico que redunde en mejores servicios hacia la
ciudadanía, retos relacionados con la voluntad política, la formación y apropiación al
interior de las entidades, la necesidad de integrar procesos interinstitucionales o la ausencia
de un marco legal adecuado que le otorgue las facultades a una entidad para intercambiar
su información. Es por esto que para el desarrollo de Gobierno Digital la definición de
interoperabilidad es acogida como: “La capacidad de las organizaciones para intercambiar
información y conocimiento en el marco de sus procesos de negocio para interactuar hacia
objetivos mutuamente beneficiosos, con el propósito de facilitar la entrega de servicios en
línea a ciudadanos, empresas y a otras entidades, mediante el intercambio de datos entre
sus sistemas”.
Esto supone entonces que el Marco para la Interoperabilidad del Gobierno Digital debe
contemplar una aproximación holística; es decir, desde múltiples interacciones,
denominadas dominios de interoperabilidad. El Marco para la Interoperabilidad del
Gobierno Digital contempla cuatro dominios que se presentan a continuación.
33
Lineamiento LI.IOP.LG.01: Establecer los instrumentos legales que faciliten el uso o
prestación de los servicios de intercambio de información.
34
Ilustración 4 Diagrama Dominio Político-Legal
A continuación, se describen cada una de las actividades de los procesos del instrumento:
35
Actividad Descripción Rol Artefactos generados
Determinar los mecanismos Determina los Jurídico N/A
legales mecanismos legales
necesarios para habilitar el
uso o prestación de los
servicios de intercambio
de información
identificados.
Identificar las competencias Identifica la competencia Jurídico Acto Administrativo.
legales para el intercambio de legal que la habilita para la Documento que
información prestación de servicios de contemple los
intercambio de mecanismos legales
información. necesarios para la
prestación de los servicios
de intercambio de
información.
Identificar la información de Identifica la forma en que Jurídico Acuerdo para el
carácter confidencial o reservada la información de carácter intercambio de
confidencial y personal, información, cronograma
asociada a los servicios de de entrega, plan de
intercambio de trabajo, protocolo, entre
información que se otros, de acuerdo a lo
consumirán o prestarán, definido en el Decreto
será protegida. De tal 2280 de 2010, donde se
modo, se evita la pérdida especifiquen los datos de
de su confidencialidad e naturaleza sensible o
integridad, así como su confidencial, así como la
uso no autorizado. reserva de la información.
Establecer mecanismos legales Desarrolla los mecanismos Jurídico Acuerdo de Intercambio
para la protección de la legales para la prestación y de Información,
información consumo de servicios de cronograma de entrega,
intercambio de plan de trabajo, protocolo,
información. entre otros, de acuerdo a
lo definido en el Decreto
2280 de 2010, que defina
el mecanismo mediante el
cual se va a prestar y
consumir el servicio de
intercambio de
información.
Establecer políticas de seguridad La entidad se debe Jurídico Implementación acorde al
para intercambiar información reconocer como el ente Modelo de Seguridad y
competente a nivel legal y Oficial de Privacidad de la
establecer las políticas de Seguridad Información.
seguridad para garantizar
la mitigación de los
principales riesgos de
pérdida de
confidencialidad e
integridad de la
información, así como su
36
uso no autorizado, en los
servicios de intercambio
de información que
consume o presta.
Utilizar los instrumentos legales La entidad utiliza Jurídico Acto Administrativo,
para intercambiar información instrumentos legales Acuerdo para el
generales que posibilitan intercambio de
el uso y consumo de información, cronograma
servicios de intercambio de entrega, plan de
de información. Así trabajo, protocolo, entre
mismo, realiza el otros, de acuerdo a lo
seguimiento y control de definido en el Decreto
los mecanismos legales 2280 de 2010.
habilitados para el
intercambio.
Intercambiar información La entidad provee y Jurídico Acto Administrativo.
cumpliendo con la normatividad consume los servicios de Acuerdo para el
vigente intercambio de intercambio de
información, garantizando información, cronograma
el cumplimiento de los de entrega, plan de
esquemas de seguridad trabajo, protocolo, entre
definidos. otros, de acuerdo a lo
definido en el Decreto
2280 de 2010.
Modelo de Seguridad y
Privacidad de la
Información.
Tabla 1 Actividades Dominio Político-Legal
Dominio Organizacional
Este dominio de la interoperabilidad se refiere al modo en que las misiones, políticas,
procesos y expectativas interactúan con aquellos de otras entidades para alcanzar las metas
adoptadas de común acuerdo y mutuamente beneficiosas, a través del intercambio de
información. Para lograrlo es necesario que la entidad realice actividades que permitan la
integración, adaptación o incluso la eliminación o definición de nuevos procesos, trámites,
servicios y otros procedimientos administrativos, así como realizar la identificación de los
conjuntos de datos que son pertinentes y susceptibles de ser intercambiados.
De otra parte, este dominio permite construir claramente la relación que se da entre las
entidades cuando son proveedoras o consumidoras de la información intercambiada y
formaliza la relación mutua, sus alcances y responsabilidades frente a su rol en el proceso
de interoperabilidad
37
Finalmente, en este dominio se deben considerar la generación de competencias en las
entidades para poder intercambiar información y a la habilitación de medios para la
colaboración entre entidades.
38
Ilustración 5 Diagrama Dominio Organizacional
39
A continuación, se describen cada una de las actividades del diagrama:
40
Actividades Descripción Responsable de la Entregables o
actividad Artefacto
condiciones de lo que se
espera del intercambio.
Deben identificarse los
recursos necesarios para
poder realizar su
respectiva planificación.
Identificar En conjunto con los Responsable de Documento de
oportunidades de responsables de la Interoperabilidad lecciones aprendidas
mejora en los procesos información del proceso se para la mejora de
implementando debe realizar un análisis Oficina TI procesos
servicios de intercambio que permita determinar las implementando
de información. modificaciones necesarias servicios de
para convertirlo en un intercambio de
servicio de intercambio de información.
información.
Crear Mesas de Si existe la necesidad de Responsable de Actas y listados de
Interoperabilidad establecer una mesa de Interoperabilidad asistencia a
interoperabilidad se debe reuniones.
generar un espacio para Oficina de TI
organizar las entidades
involucradas con el fin de
acordar los mecanismos
necesarios para realizar el
intercambio de
información.
41
Actividades Descripción Responsable de la Entregables o
actividad Artefacto
Divulgar/socializar los La entidad debe Responsable de Plan Estratégico de
servicios de intercambio interiorizar y apropiar los Interoperabilidad Tecnologías de la
de información al servicios de intercambio de Información - PETI
interior de la entidad. información desarrollados Oficina de TI
para mejorar sus procesos
de negocio, a través del Oficina de Planeación
desarrollo de un plan de
capacitación para generar
capacidades en
interoperabilidad para sus
funcionarios.
Publicar Servicios de La entidad realiza el Responsable de Contrato de
Intercambio de registro de los servicios de Interoperabilidad descripción del
Información en el intercambio de servicio de
Directorio de información que presta en intercambio y
Servicios. el directorio general de notificación emitida
servicios de intercambio de por MinTIC.
información. Publicación en el
La entidad puede solicitar Directorio de
acompañamiento al servicios de
equipo de Lenguaje intercambio de
Común. información.
Evaluar resultados de la La entidad debe evaluar Responsable de Documento con
implementación de periódicamente los Interoperabilidad tablero de
Servicios de informes sobre la indicadores
Intercambio de prestación de los servicios definidos en el
Información. de intercambio de contrato de
información y determinar descripción del
si los servicios ofrecidos servicio de
cumplen con las intercambio para el
expectativas de los mejoramiento
usuarios. continuo de los
servicios.
42
Dominio Semántico
El dominio semántico permite garantizar que, en el momento de intercambiar datos, el
significado de la información sea exacto y el mismo para todas las partes interesadas. De
igual manera, permite que las entidades del Estado colombiano puedan estandarizar,
gestionar y administrar su información.
Si el lenguaje no incorpora alguna definición que sea requerida por la entidad o algún sector,
la dirección de tecnologías y sistemas de la información de la entidad o quien haga sus veces
deberá solicitar la inclusión al Ministerio TIC.
43
Para la inclusión de un estándar nuevo, se debe llevar a cabo el proceso de incorporación
de estándares internacionales. El proceso consta de las etapas de recepción, validación y
cierre las cuales son explicadas en el anexo Evaluación Estándares Internacionales.
Documento publicado en la sección de documentos y manuales del portal de lenguaje
común. http://lenguaje.mintic.gov.co
La reusabilidad debe ser interpretada como el medio a través del cual las entidades públicas
pueden compartir su información ya estandarizada y publicada en el diccionario de datos
disponible para cualquier tipo de servicio de intercambio de información.
A través de la guías e instrumentos definidos en este marco, la entidad debe asegurar que
la información objeto de intercambio cumpla con el estándar de lenguaje común de
intercambio de información.
La arquitectura de datos del estándar se diseñó para que las entidades puedan estructurar,
definir, clasificar y gestionar de forma adecuada la información y los elementos de dato que
conforman y conformarán el estándar.
44
Ilustración 6 Diagrama Dominio Semántico
45
Actividad Descripción Responsable de la Entregables o artefacto
actividad
información, la entidad revisa la Oficina de TI Para más información
existencia de dichos elementos de dato consultar la Guía de Uso y
dentro del lenguaje común. Oficina de Conceptos Generales del
http://lenguaje.mintic.gov.co/diccionar Planeación Lenguaje Común en el
io-de-elementos-de-datos portal
La conceptualización de los elementos Equipo de http://lenguaje.mintic.gov
de dato debe estar dada acorde al acompañamiento .co
Estándar de Lenguaje Común de de Lenguaje
Intercambio de Información. Común.
La entidad realiza la definición
semántica de cada uno de los
elementos de dato identificados en el
catálogo. Esta definición contiene
información como la identificación, la
definición, el formato, las validaciones,
las fuentes, entre otros. Todas estas
definiciones deben ser aprobadas por la
entidad y el equipo de
acompañamiento de Lenguaje Común
de la Dirección de Gobierno Digital.
Verificar la La entidad puede consultar y verificar Responsable de Catálogo de elementos de
información en la información estandarizada en el Interoperabilidad dato.
el diccionario diccionario de datos del estándar en: en la Entidad.
de datos del http://lenguaje.mintic.gov.co/diccionar
estándar. io-de-elementos-de-datos
46
Dominio Técnico
El dominio técnico de la interoperabilidad hace referencia a las aplicaciones e
infraestructuras que conectan sistemas de información, a través de los servicios de
intercambio de información. Incluye aspectos como especificaciones de interfaz, protocolos
de interconexión, servicios de integración de datos, presentación e intercambio de datos y
protocolos de comunicación seguros.
La interoperabilidad técnica debe garantizarse, siempre que sea posible, mediante el uso
de especificaciones técnicas formales y de los Servicios Ciudadanos Digitales.
Lineamiento LI.IOP.TE.01: Utilizar los Servicios Ciudadanos Digitales, con el fin de garantizar
la interoperabilidad Verificar la información en el diccionario de datos del estándar técnica
al establecer servicios de intercambio de información que apoyen la transformación digital
de las entidades.
4.4.1 Arquitectura
En este apartado se describe la arquitectura de referencia que se debe tener en cuenta en
las entidades para la implementación de los servicios de intercambio de información
mediante servicios web. La arquitectura ha sido definida teniendo en cuenta las
recomendaciones y lineamientos de los capítulos anteriores y los siguientes requerimientos
funcionales y no funcionales:
Requerimientos funcionales
- Garantizar la exposición y consumo de los servicios de intercambio de información
por parte de las entidades en la Plataforma De Interoperabilidad en el marco de sus
funciones.
47
- Realizar el intercambio de los conjuntos de datos susceptibles a interoperar
mediante servicios de intercambio de información integrados a la plataforma de
interoperabilidad del Estado (PDI).
Requerimientos no funcionales
- Bajo acoplamiento.
- Alta cohesión.
- Alta disponibilidad.
- Escalabilidad.
- Mantenibilidad.
- Seguridad.
- Encapsulamiento.
- Reutilización.
El siguiente diagrama muestra la arquitectura de referencia.
48
Ilustración 7 Arquitectura implementación servicios web
Por medio de la siguiente tabla se describe cada uno de los componentes de la arquitectura
de referencia.
49
PDI Servidor de El servidor de seguridad interactúa con las invocaciones Entidad
seguridad al servicio de intercambio de información (entidades
públicas o privadas) y las respuestas desde el sistema
de información misional de la entidad. Adicionalmente,
administra las claves para la firma digital, autenticación
y envío de mensajes a través del canal seguro.
Este componente hace parte de los Servicios
Ciudadanos Digitales. Una descripción detallada del se
encuentra en la “Guía para la vinculación y uso de los
Servicios Ciudadanos Digitales”.
Soluciones integradas Este componente es opcional y dependerá de la Entidad
para la arquitectura de solución implementada por la entidad.
interoperabilidad Este componente podría ser implementado por
(Opcional) diferentes medios como, por ejemplo: un Bus de
servicios (ESB Enterprise Service Bus), o un API.
Dentro de este componente se recomiendan
implementar las siguientes necesidades:
- Transformación de servicios web. Implementar sobre
el protocolo SOAP, un nuevo servicio que
implemente la tecnología Rest con diferentes tipos
de mensajes (xml, json, mime), métodos (post, get,
put, delete). Adicionalmente, podrían existir
transformaciones mismas del mensaje para incluir
campos en el cuerpo del mensaje, nuevos
encabezados, entre otros.
- Orquestación de servicios. De requerirse una
orquestación de otros servicios, se recomienda
implementar adaptadores que simplifiquen la
mantenibilidad y escalabilidad de los servicios.
- Seguridad. La Plataforma de interoperabilidad – PDI
que se soporta con la herramienta X-ROAD
garantizan la seguridad en el intercambio de
información para los servicios que se exponen a otras
entidades públicas o privadas, sin embargo, cuando
se realizan servicios de intercambio de información
(especialmente para uso interno) es recomendable
incluir como buena práctica una capa de seguridad a
cada uno de los servicios expuestos por la entidad.
Para conocer mayor detalle sobre la capa de
seguridad que puede ser usada para servicio de
intercambio de información internos, consulte la
sección Seguridad de Servicios Web de este
documento.
- Auditoría: Se recomienda implementar la auditoría
de los servicios. Esta auditoría podría ser a nivel de
transacción únicamente, sin necesidad de guardar el
contenido del mensaje, o puede ser una auditoria de
la transacción completa. Al tener este atributo de
seguridad implementado, se podrán ofrecer servicios
de inteligencia de negocios al interior sobre el
consumo, exposición de los servicios de la entidad.
- Cuota de uso del servicio y demás restricciones de
negocio. Por medio de esta funcionalidad, las
50
entidades podrán agregar atributos de uso sobre el
servicio; atributos como: Horas en las que se puede
utilizar el servicio, cantidad de transacciones por
usuario, entre otros.
El contar con esta capa, se garantizan los siguientes
requerimientos no funcionales:
- Mantenibilidad
- Bajo acoplamiento
- Alta cohesión
- Seguridad
- Escalabilidad
Por último, una de las ventajas de una capa con este
componente es que permite a las entidades no estar
acopladas a una tecnología de interoperabilidad única
y el costo de modificación de adaptadores o de cada
artefacto implementado en este componente es menor
a la modificación que se debería realizar en cada uno de
los sistemas o capas de los servicios web
implementados en los sistemas misionales de las
entidades.
WS-SI Componente interno de la aplicación que expone o Entidad
consume el servicio web de la entidad. Este
componente interno hace parte de la capa lógica de la
arquitectura propuesta. Es importante mencionar que
esta capa lógica, bajo esta arquitectura, estará
encapsulada y aislada para el consumo y exposición de
servicios web ya sea directamente por medio de PDI
Security Server o haciendo uso del componente
opcional de Soluciones integradas para la
interoperabilidad, descrito anteriormente. Este
requerimiento no funcional tiene como propósito
proteger el acceso a los sistemas misionales de las
entidades.
El detalle de la descripción de la arquitectura interna de
implementación de servicios web, es descrita en la
sección Implementación Servicios Web del presente
documento.
Tabla 4 Componentes de la arquitectura de referencia.
51
Los siguientes son los roles que hacen parte de la metodología propuesta. Si bien es
importante tener la diferenciación de actividades por rol, esto no representa que se
52
necesite tener personal específico para cada uno de los roles definidos para implementar
la metodología. La siguiente tabla describe las responsabilidades y el perfil de los roles al
interior de las entidades.
53
Diseño funcional Subproceso que tiene por objetivo el - Líder funcional -Archivo de
levantamiento de las necesidades del - Arquitecto de caracterización del
intercambio de información (exposición interoperabilidad servicio web
y consumo). Se identifican todas las - Equipo de -Notificación de
reglas para el intercambio de acompañamiento cumplimiento del
información, los requisitos frente al de Lenguaje servicio en el nivel 1
dominio político-legal, campos de Común del Dominio
entrada, salida, requerimientos no Semántico.
funcionales (autenticación, - Historia de
autorización, auditoría, usuario. En el caso
confidencialidad, tecnología), reglas de servicios de
adicionales como horas de ejecución, consumo, las
cantidad de transacciones, qué entidades deberán
entidades pueden consumir el servicio,
construir este
entre otros. documento en el
que se describen
los campos que se
deberán adicionar
en las pantallas de
los aplicativos
internos de las
entidades.
Validación Una vez definidos los requerimientos Mesas técnicas de Acta de aprobación
“Cumple con las funcionales y no funcionales del servicio interoperabilidad de la
necesidades de intercambio de información, las caracterización del
identificadas del entidades involucradas, las que exponen servicio.
servicio” la información, como las que consumen
o requieren la información, validan si lo
especificado en la caracterización del
servicio de intercambio satisface las
necesidades previamente planteadas.
Si es aprobado, se inicia el diseño
técnico de la implementación del
servicio de intercambio.
De no aprobarse, se deberán levantar
las nuevas necesidades en esta mesa
para ajustar la caracterización del
servicio, volviendo al subproceso Diseño
Funcional.
Diseño Técnico Subproceso que tiene por objetivo la -Arquitecto de - Documento de
construcción del diseño técnico del interoperabilidad. diseño técnico
servicio web de consumo o exposición - Líder QA - Documento de
en la capa lógica y en el componente casos de prueba
“Soluciones integradas para la
interoperabilidad”.
En este punto, el líder de QA deberá
diseñar también los casos de prueba del
servicio.
Validación Se revisa el documento técnico y Arquitecto de
“Cumple con los documento de casos de prueba contra el interoperabilidad
requerimientos archivo de caracterización del servicio
funcionales y no creado en el Diseño Funcional.
54
funcionales Si el diseño técnico y casos de prueba
especificados” cumplen con lo especificado, se inicia la
implementación del servicio web. De lo
contrario, se deberá revisar
nuevamente la definición funcional.
Implementación del Subproceso que tiene por objetivo la Desarrollador - Código fuente. En
servicio implementación del servicio web de los casos en los que
consumo o exposición y la ejecución de el servicio es
pruebas unitarias por parte del implementando el
desarrollador. Esta implementación es protocolo SOAP,
en la capa de sistemas de información wsdl.
de la entidad, como en la capa
“Soluciones integradas para la
interoperabilidad” de la arquitectura
propuesta.
Validación Antes de finalizar como tal el desarrollo Desarrollador
“Se han ejecutado del servicio web, el desarrollador deberá
todos los casos de ejecutar los casos de prueba
prueba automatizados de la implementación.
exitosamente y no Esta ejecución automática de casos de
requiere de ajuste en prueba es la evidencia de finalización de
el diseño técnico” la fase de implementación del servicio.
La ejecución de pruebas en este punto,
se puede realizar con un servicio local
simulado, implementado en el
componente “Soluciones integradas
para la interoperabilidad”, en el caso de
consumo. Para el caso de exposición, se
recomienda tener un cliente
implementado para la ejecución de
pruebas automáticas de consumo del
servicio que se va a exponer. Otra
alternativa para las pruebas unitarias,
en caso de no contar con el cliente de
consumo de servicios web, es utilizar
herramientas de pruebas como por
ejemplo POSTMAN, SOAP UI, entre
otras herramientas de pruebas de
servicios web. Este caso representa que
el desarrollador deberá manualmente
documentar la ejecución de casos de
prueba.
Si la ejecución de pruebas automáticas
no es exitosa, se deberán realizar los
ajustes correspondientes y volver a
probar.
Por otro lado, si se han identificado
modificaciones que se deben realizar a
la implementación, como: incluir
campos técnicos de paginación, cambiar
tipos de datos por mayor longitud,
adicionar validación en el header del
mensaje, entre otros, se deberá validar
55
nuevamente el diseño técnico con el
arquitecto de interoperabilidad.
Por último, si se cumple con la ejecución
de pruebas y además no hay ajustes a la
especificación técnica inicial del servicio,
se inicia la fase de pruebas del servicio.
Pruebas del servicio En este subproceso, la ejecución de - Líder QA Documento de
web pruebas se realiza en ambiente de -Analista QA evidencia de casos
pruebas entre quién expone, como el - Líder funcional de prueba
que consume. Es decir, ya son pruebas ejecutados
de integración entre las entidades tanto
en el sistema de información, como en
la capa “Soluciones integradas para la
interoperabilidad”.
Validación “Se han Se valida si la ejecución de los casos de - Líder QA - Reporte de casos
ejecutado todos los prueba diseñados ha sido ejecutados - Analista QA de prueba
casos de prueba exitosamente en su totalidad. De ser así, - Equipo de ejecutados
exitosamente” se desplegaría el servicio en ambiente acompañamiento exitosamente
pre-productivo. De lo contrario, se debe de Lenguaje junto con su
notificar al desarrollador para realizar Común evidencia.
los ajustes correspondientes. - Líder funcional - Artefacto de la
implementación.
Archivo
desplegable de la
implementación.
- Manuales de
despliegue
- Notificación de
cumplimiento del
servicio en el
nivel 2 del
Dominio
Semántico.
Despliegue del El artefacto de la implementación es - Líder de - Notificación de
servicio desplegado en ambiente pre-productivo infraestructura cumplimiento del
y se realizan algunas pruebas básicas. Si - Equipo de servicio en el
han sido exitosas, se realizan pruebas de acompañamiento nivel 3 del
carga y estrés del servicio entre de Lenguaje Dominio
entidades. Si la ejecución de estas Común Semántico.
pruebas básicas y de rendimiento son (Publicación en el
exitosas, se procede a desplegar el Directorio de
servicio en producción, tanto en la capa servicios de
de sistemas internos de la entidad, intercambio de
como en la capa “Soluciones integradas información).
para la interoperabilidad”.
Tabla 6 Componentes Diseño Web
Cada uno de los subprocesos mencionados deberían tener una definición de ANS (acuerdos
de niveles de servicio), que se deberían acordar entre las entidades que intercambiarán
información. Los tiempos se definirán dependiendo de cada una de las necesidades de
interoperabilidad entre la entidad qué expone la información, como la que consume.
56
Las siguientes secciones describen en detalle cada uno de los subprocesos de la
metodología. El subproceso de implementación tiene una sección diferente, ya que
describe técnicamente la arquitectura recomendada, contrato de servicios en la plataforma
de interoperabilidad y lineamientos para la implementación del componente Soluciones
integradas para la interoperabilidad.
57
Ilustración 8 Diagrama Diseño Funcional
Por medio de la siguiente tabla se describen las actividades, elementos del diagrama.
58
- Tamaño máximo de mensaje
- Tamaño promedio de mensaje
- Política de reintentos
- Esquema de resultados paginados
(si se requiere)
- Indicación que tipo de servicio se
implementa según las siguientes
categorías:
o Respuesta síncrona con
procesamiento síncrono
o Respuesta síncrona con
procesamiento asíncrono
o Respuesta asíncrona
Esta información se deberá ir
detallando en el documento
Caracterización del servicio.
Identificar requerimientos no funcionales En este punto, se recomienda definir - Líder funcional
los siguientes elementos para el - Arquitecto
servicio: interoperabilidad
- Autenticación
- Autorización
- Confidencialidad
- Auditoría
- Integridad
- Disponibilidad
- Política de reintentos
- Cuota del servicio (número de
transacciones permitidas, horarios
de ejecución)
Estos requerimientos no funcionales
pueden ser implementados en la capa
Soluciones integradas para la
interoperabilidad de la arquitectura
propuesta y se documentan en el
formato de caracterización del servicio.
Diligenciar formatos de caracterización Consolidar el formato de Líder funcional
del servicio caracterización del servicio, validando
que la información levantada esté toda
contemplada en el documento
funcional. Una vez consolidada, se
enviará una solicitud de servicio al
Equipo de Acompañamiento de
Lenguaje Común, para la obtención de
la notificación de cumplimiento de
nivel 1 en caso en que el servicio a
implementar sea de exposición.
Validar contrato servicio de intercambio Validar si la definición del servicio de Equipo de
de información exposición cumple con los estándares Acompañamiento de
definidos en el Lenguaje Común de Lenguaje Común.
Intercambio de información. Para un
mayor detalle de estos estándares,
revisar la sección del Dominio
Semántico.
59
Validación “cumple con los estándares Si se cumple con el estándar, se Equipo de
del Lenguaje Común de Intercambio de notificará el cumplimiento del nivel 2. Acompañamiento de
Información” De lo contrario, se deberán realizar los Lenguaje Común.
ajustes correspondientes y volver a
solicitar la notificación.
Tabla 7 Actividades Diseño Funcional
Por medio de la siguiente tabla se describen cada una de las actividades o elementos del
diagrama.
60
- Otra posibilidad sería la
implementación del content-type
multipart form-data con dos partes:
o Application-json, text/xml o
application/xml con la metada data
del archivo como: nombre, tipo,
tamaño, entre otros.
o Octect-stream con el array de bytes
del archivo
61
documento de caracterización del
servicio.
De no contar con soluciones integradas
para la interoperabilidad, estas
implementaciones se deberían definir
para cada uno de los sistemas en donde
se implementará el servicio. Se deberá
también diseñar en particular para cada
tecnología o protocolo del servicio web,
la implementación de los requerimientos
no funcionales.
Diseñar casos de prueba Para cada una de las necesidades Líder QA
definidas en el documento de
caracterización del servicio, se deberán
definir los casos de prueba a ejecutar.
Crear documento diseño técnico Consolidar en el documento de diseño Arquitecto de
técnico las definiciones realizadas en las interoperabilidad
actividades antes mencionadas.
Tabla 8 Actividades diseño técnico
62
Ilustración 10 Diagrama pruebas servicio web
63
Por medio de la siguiente tabla se describen cada una de las actividades o elementos del
diagrama.
64
servicio da respuesta a la petición de
la entidad consumidora,
garantizando que los campos son los
que se definieron y además los
requerimientos no funcionales como
horarios de ejecución, o los definidos
en el diseño funcional, se cumplen
entre ambas entidades.
Validación “Pruebas Req no funcionales Si alguno de los casos de prueba no Analista QA
ejecutadas exitosamente” es exitoso, se deberá notificar al
desarrollador. De ser así, se esperaría
al ajuste para volver a iniciar la
actividad antes descrita.
De no haber errores, se consolida el
reporte final de las pruebas.
Consolidar reporte final de ejecución de Se genera el reporte de las pruebas Analista QA
pruebas ejecutadas junto con su evidencia. Líder funcional
Adicionalmente, se deberá realizar
esta consolidación de casos de
prueba notificándole al líder
funcional sobre la ejecución exitosa.
Junto con el analista de QA, el líder
funcional verifica esta consolidación.
Validación “Pruebas ejecutadas Si alguno de los casos de prueba Líder QA
completamente” diseñados no es ejecutado Líder funcional
exitosamente o el líder funcional no
aprueba el consolidad final, no se
solicita la validación de lenguaje
común de intercambio de
información.
Junto con el líder funcional, el líder de
QA valida que se hayan realizado
todas las pruebas y que éstas
cumplan con el visto bueno del líder
funcional
Validación “Cumple con la validación del Si cumple con la validación de Equipo de Acompañamiento
Lenguaje Común de Intercambio de Lenguaje Común de Intercambio de de Lenguaje Común.
Información” Información, se generaría el archivo
de despliegue. De lo contrario, se
inician nuevamente la ejecución de
casos de prueba para verificar si hay
alguna inconformidad con las
pruebas en cuanto al estándar.
Generar archivo despliegue Se genera el archivo a desplegar en Líder QA
Preproducción.
Tabla 9 Actividades Pruebas del servicio
65
La siguiente ilustración muestra el diagrama de actividades del subproceso Despliegue del
servicio.
66
Ilustración 11 Diagrama despliegue servicio
67
Por medio de la siguiente tabla se describen cada una de las actividades o elementos del
diagrama.
68
Ejecutar pruebas de rendimiento En coordinación con la Líder Infraestructura
entidad proveedora del
servicio, o quién consume,
se deberán realizar pruebas
de carga y estrés del servicio
en horarios establecidos en
conjunto. Esta actividad
aplica tanto para los
servicios de exposición,
como para la
implementación de
consumo de un servicio.
Validación “Pruebas de rendimiento ejecutadas Si al ejecutar las pruebas de Líder Infraestructura
exitosamente” carga y estrés no se
satisface alguno de los
requerimientos no
funcionales del servicio
especificado como:
cantidad de transacciones,
disponibilidad, se
notificarán los resultados y
se hará rollback. De lo
contrario, se valida si el
servicio en pre-producción
cumple con el lenguaje
común de intercambio.
Notificar resultados y hacer rollback Se informa al arquitecto de Líder Infraestructura
interoperabilidad y las
partes interesadas de los
resultados de la prueba de
rendimiento y se realiza
rollback en ambiente
preproductivo.
Validación “Cumple con Lenguaje Común de Se valida si el servicio Equipo de Acompañamiento
Intercambio de Información” desplegado en pre- de Lenguaje Común.
producción cumple con el
Lenguaje Común de
Intercambio de
Información. Si cumple, se
despliega en producción. De
lo contrario, se ejecuta la
actividad Notificar
resultados y hacer rollback
Desplegar en producción Se despliega el artefacto en Líder Infraestructura
producción.
Ejecutar pruebas básicas y de rendimiento Se ejecutan la siguiente Líder Infraestructura
prueba básica:
Se ejecuta un consumo del
servicio por medio de
comandos CURL o haciendo
uso de Postman, SOAP UI,
entre otros.
69
Adicionalmente se ejecutan
las pruebas de carga y
estrés. Es importante
aclarar en este punto que
las pruebas de carga y
estrés es recomendado
ejecutarlas en horarios no
operativos de las entidades.
Para el caso de un servicio
de consumo, se deberá
verificar en el sistema
misional de la entidad, en
dónde se consumiría el
servicio, que se encuentren
habilitados los
componentes gráficos para
poder disparar el consumo
del servicio. En el diseño de
pruebas definido en el
subproceso de Diseño
Técnico, se deberán poder
identificar las pruebas
básicas de un disparador o
consumo de servicio.
Validación “Pruebas ejecutadas exitosamente” Si la ejecución de las Líder Infraestructura
pruebas básicas y de
rendimiento en producción
son exitosas, se informará
de la salida en producción
del servicio. De lo contrario,
se deberá corregir el
despliegue.
Corregir De haber algún error en el Líder Infraestructura
despliegue, se deberá
corregir y desplegar
nuevamente de la manera
correcta.
Tabla 10 Actividades Despliegue del servicio
70
4.4.7.1 Implementación del servicio web de negocio
La arquitectura recomendada para la implementación de nuevos servicios web de
exposición es la Arquitectura MVC por las siguientes razones:
Por medio de la siguiente tabla se describen los componentes del patrón de arquitectura.
71
y salida. Dependiendo del tipo de contenido del servicio, se tendrían
objetos de entrada u objetos mulitpart con objetos internos, según lo
diseñado.
Modelo Componente que gestiona el acceso a la capa de datos. En este
componente se encuentran las operaciones CRUD con la base de datos
dependiendo de las operaciones expuestas en el controlador.
Adicionalmente en este componente se encuentran los objetos de
interacción Entities o DTOs entre el controlador y el modelo. Cabe aclarar
que estos objetos no son los mismos objetos que recibe o retorna el
controlador en el servicio.
DB-negocio Componente que representa la capa de datos del servicio web. Dentro
de la arquitectura MVC el acceso a esta capa en términos de visualización
está encapsulada y solo puede interactuar con el componente Modelo.
Tabla 11 Componentes Arquitectura
Por medio de la siguiente tabla se describen cada uno de los estados del servicio.
72
Especificación funcional Estado del servicio cuándo se define Diseño técnico
funcionalmente
Diseño técnico Estado del servicio cuándo se está Implementación
detallando técnicamente su Especificación funcional
implementación.
Implementación Estado del servicio cuando se Pruebas
encuentra en implementación. Diseño técnico
Pruebas Estado del servicio cuando ya se Productivo
encuentra implementado, ha sido
desplegado en ambiente de pruebas
y se están verificando sus
operaciones, características. Se
valida que operen según lo
especificado en el diseño funcional y
en el diseño técnico.
Productivo Estado del servicio cuando está en Inactivo
operación y disponible.
Inactivo Estado del servicio cuando éste no Especificación funcional
está disponible en ningún ambiente Diseño técnico
productivo posiblemente por Pruebas
alguna de las siguientes razones:
• Mantenimiento
• Mejoras
• Extensión de
funcionalidades u
operaciones
• Ajuste a problemas o
incidentes reportados en
operación
73
Modelo de madurez
74
Modelo de madurez
El modelo de madurez del Marco de Interoperabilidad permite que las entidades realicen
un diagnóstico interno sobre el avance en la implementación de los lineamientos de cada
uno de los dominios y definan las acciones que deben ejecutar para avanzar en la adopción
de los lineamientos.
El modelo de madurez tiene cinco niveles para establecer el estado actual de la adopción
de este marco así como el estado del intercambio de información en el que se encuentra
cada entidad. Este instrumento se encuentra en el Anexo 3 – Modelo de Madurez.
75
Modelo para la integración
con los Servicios Ciudadanos
Digitales
76
Marco general de los Servicios Ciudadanos
digitales
Esta sección presenta el modelo de los Servicios Ciudadanos Digitales - SCD, como
habilitador transversal de la política de gobierno digital. Los SCD son un conjunto de
soluciones tecnológicas que buscan facilitar a los ciudadanos su interacción con las
entidades públicas y optimizar la labor del Estado y que orientan a las entidades en la
planificación, desarrollo, explotación y mantenimiento de los sistemas de información y
como apoyo en su transformación digital.
a. Servicio de Interoperabilidad
b. Autenticación Digital
c. Carpeta Ciudadana Digital
El modelo de los Servicios Ciudadanos Digitales se prestará a las entidades públicas, a los
ciudadanos y a las empresas de manera integrada, generando mejoras en la calidad de vida
de los ciudadanos y eficiencia en las entidades públicas. De esta forma, los SCD son ese
conjunto de soluciones y procesos transversales que brindan al Estado las capacidades y
eficiencias para su transformación digital, logrando una adecuada interacción del ciudadano
con la administración pública a través de medios digitales.
77
El modelo de los Servicios Ciudadanos Digitales considera seis (6) actores cuyos roles se
describen a continuación:
• Los organismos y entidades son los encargados de brindar los trámites y servicios a
los ciudadanos y empresas, custodiar datos de los ciudadanos y empresas y
colaborar armónicamente con otras entidades para intercambiar información en el
ámbito de sus funciones.
• El articulador, o quien haga sus veces, es el encargado de coordinar los SCD y prestar
los Servicios Ciudadanos Digitales Base a las entidades públicas, además de apoyar
técnica y operativamente a MinTIC para garantizar el pleno funcionamiento de los
modelos de servicio. Este es el único con la potestad de ofrecer y mejorar el servicio
ciudadano digital de Interoperabilidad, siguiendo las definiciones y lineamientos que
defina MinTIC.
El modelo de los SCD se enfoca en lograr una adecuada interacción del ciudadano con el
Estado, permitiendo garantizar el derecho a la utilización de medios electrónicos ante la
administración pública, reconocido en los artículos 53 y 54 de la Ley 1437 de 2011, estos
servicios se clasifican como base y especiales.
Se consideran servicios ciudadanos digitales base, aquellos que son fundamentales para
brindarle al Estado las capacidades en su transformación digital. A continuación, se definen
de manera general las características y funcionalidades esenciales de esta clase de servicios:
Los servicios digitales especiales son aquellos que brindan soluciones que por sus
características realizan nuevas ofertas de valor y son adicionales a los servicios ciudadanos
digitales base, o bien, corresponden a innovaciones que realizan los prestadores de servicio
a partir de la integración a los Servicios Ciudadanos Digitales Base, esto bajo un esquema
coordinado por el articulador.
El servicio de Interoperabilidad para las entidades del Estado será prestado de forma
exclusiva por el Articulador, permitiendo a los prestadores de servicio conectarse con la
plataforma de Interoperabilidad del Estado de conformidad con las condiciones que sobre
el particular se definan en la Guía de integración de los prestadores de servicio a los
Servicios Ciudadanos Digitales que publique el Ministerio de Tecnologías de la Información
y las Comunicaciones.
79
Anexos
80
Anexo 1. Integración WS - PDI
Contar con este componente garantiza que se cumplan las restricciones o requerimientos
no funcionales de la arquitectura de interoperabilidad propuesta como: reutilización, bajo
acoplamiento, mantenibilidad, agilidad en la implementación, entre otros. Al no disponer
de esta capa, la entidad deberá implementar cada uno de los lineamientos y
recomendaciones acá definidas para cada uno de los servicios web expuestos en cada uno
de los sistemas misionales.
81
Transformaciones. Adicionar encabezados a un servicio o cambiar su tecnología. En el caso
de modificar el encabezado del servicio para que pueda ser expuesto en el servidor de
seguridad X-ROAD, se recomienda desarrollar un componente genérico en esta capa
“Soluciones integradas para la interoperabilidad” de cara a reutilizarlo para la exposición y
consumo de otros servicios. Para ver que encabezados deben ser agregados y en qué
tecnología, ver la sección Servicios Web en la plataforma de interoperabilidad X-ROAD. Para
el caso de tener un servicio en SOAP con adjuntos, la transformación sería a nivel de cuerpo
y se describe también en la sección Servicios Web en la plataforma de interoperabilidad X-
ROAD.
Auditoría. Habilitar el log de transacciones del componente para poder consultar y tener el
seguimiento a cada uno de los consumos de los servicios web. Se deberá definir la
estructura de este log en términos de qué datos (usuario, fecha y hora, id del servicio, entre
otros) se desean seguir.
Al contar con el Servidor de Seguridad X-ROAD, la capa de seguridad de servicios web para
el intercambio de información con entidades no sería necesario. Sin embargo, en esta
sección se describen las recomendaciones en caso de adicionar una capa adicional para el
consumo y exposición interna de servicios web.
Tomando como referencia OWASP (Open Web Application Security Project), el cual es un
Proyecto a nivel mundial que busca definir las mejores prácticas y métodos para mejorar la
seguridad del software, se listan a continuación las recomendaciones en la implementación
segura de servicios web.
82
Implementar OAuth 2.0 por medio de Json Web Tokens. Esta implementación se realiza por
medio de headers de la siguiente manera:
Ejemplo:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4
gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
El primer string (hasta el primer punto), representa el header del token. El string de la mitad
representa el payload del token y por último, la firma digital del token el cual permite validar
la integridad del token.
Identity Server
2
Validación Token
83
Con el objetivo de integrar los servicios web implementados de las entidades tanto para
exponer, como para consumir, las entidades deben implementar el protocolo X-ROAD
Message para usar el Servidor de Seguridad X-ROAD de cada entidad. Este protocolo define
unos encabezados en el mensaje dependiendo de si es Rest o SOAP, para la petición
(request) o respuesta (response) y por último, si el servicio a exponer o consumir es SOAP
con adjuntos.
En esta sección se describen los encabezados para cada uno de los casos antes mencionados
y, por último, se muestran ejemplos de cómo sería la petición. Tener en cuenta que, si bien
para la implementación de servicios SOAP se describen encabezados, dentro de la
descripción se mencionan reglas a nivel del cuerpo del mensaje que se deberán
implementar también.
84
Ejemplo de la petición
Content-Type: text/xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xro="http://x-road.eu/xsd/xroad.xsd" xmlns:iden="http://x-road.eu/xsd/identifiers"
>
<soapenv:Header>
<xro:client iden:objectType="SUBSYSTEM">
<iden:xRoadInstance>[valor del campo (cadena de
caracteres)]</iden:xRoadInstance>
<iden:memberClass>[valor del campo (cadena de caracteres)]</iden:memberClass>
<iden:memberCode>[valor del campo (cadena de caracteres)]</iden:memberCode>
<iden:subsystemCode>[valor del campo (cadena de
caracteres)]</iden:subsystemCode>
</xro:client>
<xro:service iden:objectType="SERVICE">
<iden:xRoadInstance>[valor del campo (cadena de
caracteres)]</iden:xRoadInstance>
<iden:memberClass>[valor del campo (cadena de caracteres)]</iden:memberClass>
<iden:memberCode>[valor del campo (cadena de caracteres)]</iden:memberCode>
<iden:subsystemCode>[valor del campo (cadena de
caracteres)]</iden:subsystemCode>
<iden:serviceCode>[valor del campo (cadena de caracteres)-este nombre debe
coincidir con el nombre del primer elemento del cuerpo o body]</iden:serviceCode>
</xro:service>
<xro:id>[valor del campo (UUID)]</xro:id>
<xro:userId>[valor del campo (cadena de caracteres)]</xro:userId>
<xro:protocolVersion>4.0</xro:protocolVersion>
</soapenv:Header>
<soapenv:Body>
<prod:[valor del campo serviceCode] xmlns:prod="http://test.x-road.fi/producer">
<prod:request/>
</prod: [valor del campo serviceCode]>
</soapenv:Body>
</soapenv:Envelope>
El ejemplo y contrato de servicio antes descrito, se deberá satisfacer cuándo una entidad
desea consumir un servicio SOAP de otra entidad por medio de la plataforma de
interoperabilidad. Esta implementación (transformación del servicio), es la que se
recomienda realizar en el componente “Soluciones integradas para la interoperabilidad”.
De lo contrario, la entidad debería implementar esta transformación en los sistemas
misionales donde desea consumir el servicio.
85
Nombre del encabezado Descripción
Cliente /instancia X-ROAD Se deberá tomar este valor del objeto request recibido por parte del consumidor
del servicio. Estos campos deben estar en el mismo orden.
Cliente/clase miembro Se deberá tomar este valor del objeto request recibido por parte del consumidor
(memberClass) del servicio.
Cliente/código miembro Se deberá tomar este valor del objeto request recibido por parte del consumidor
(memberCode) del servicio.
Cliente/código del subsistema Se deberá tomar este valor del objeto request recibido por parte del consumidor
(subsystemCode) del servicio.
Servicio/ instancia X-ROAD Se deberá tomar este valor del objeto request recibido por parte del consumidor
del servicio.
Servicio/clase miembro Se deberá tomar este valor del objeto request recibido por parte del consumidor
(memberClass) del servicio.
Servicio/código miembro Se deberá tomar este valor del objeto request recibido por parte del consumidor
(memberCode) del servicio.
Servicio/código del subsistema Se deberá tomar este valor del objeto request recibido por parte del consumidor
(subsystemCode) del servicio.
Servicio/código del servicio Se deberá tomar este valor del objeto request recibido por parte del consumidor
(serviceCode) del servicio. En el cuerpo del mensaje, el primer componente debe tener el
nombre de éste código de servicio, seguido de la palabra “Response”.
Id Se deberá tomar este valor del objeto request recibido por parte del consumidor
del servicio.
ID del usuario (userID) I Se deberá tomar este valor del objeto request recibido por parte del
consumidor del servicio.
Versión del protocolo Constante, su valor es 4.0
Ejemplo de la respuesta
Content-Type: text/xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xro="http://x-road.eu/xsd/xroad.xsd" xmlns:iden="http://x-road.eu/xsd/identifiers"
>
<soapenv:Header>
<xro:client iden:objectType="SUBSYSTEM">
<iden:xRoadInstance>[valor del campo (cadena de
caracteres)]</iden:xRoadInstance>
<iden:memberClass>[valor del campo (cadena de caracteres)]</iden:memberClass>
<iden:memberCode>[valor del campo (cadena de caracteres)]</iden:memberCode>
<iden:subsystemCode>[valor del campo (cadena de
caracteres)]</iden:subsystemCode>
</xro:client>
<xro:service iden:objectType="SERVICE">
<iden:xRoadInstance>[valor del campo (cadena de
caracteres)]</iden:xRoadInstance>
<iden:memberClass>[valor del campo (cadena de caracteres)]</iden:memberClass>
<iden:memberCode>[valor del campo (cadena de caracteres)]</iden:memberCode>
86
<iden:subsystemCode>[valor del campo (cadena de
caracteres)]</iden:subsystemCode>
<iden:serviceCode>[valor del campo (cadena de caracteres)-este nombre debe
coincidir con el nombre del primer elemento del cuerpo o body]</iden:serviceCode>
</xro:service>
<xro:id>[valor del campo (UUID)]</xro:id>
<xro:userId>[valor del campo (cadena de caracteres)]</xro:userId>
<xro:protocolVersion>4.0</xro:protocolVersion>
</soapenv:Header>
<soapenv:Body>
<prod:[valor del campo serviceCode]Response xmlns:prod="http://test.x-
road.fi/producer">
[datos]
</prod: [valor del campo serviceCode]Response>
</soapenv:Body>
</soapenv:Envelope>
El ejemplo y contrato de servicio antes descrito, se deberá satisfacer cuándo una entidad
desea exponer un servicio SOAP por medio de la plataforma de interoperabilidad. Esta
implementación (transformación del servicio), es la que se recomienda realizar en el
componente “Soluciones integradas para la interoperabilidad”. De lo contrario, la entidad
debería implementar esta transformación en los sistemas misionales donde desea consumir
el servicio.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart>
--MIME_boundary
Content-Type: application/octet-stream; name=[Nombre del archivo]
87
Content-Transfer-Encoding: base64 [es opcional, si se decide enviar como array de bytes,
no sería necesario.]
Content-ID: [id del contenido, definido por la entidad y Sistema misional]
Content-Disposition: attachment; name="[nombre archivo]"; filename="[nombre archivo]"
[ARCHIVO]
--MIME_boundary--
La implementación a realizar por parte de la entidad para satisfacer este contrato que hace
parte del protocolo X-ROAD Message, se recomienda realizar en el componente “Soluciones
integradas para la interoperabilidad” para no modificar la implementación en el sistema
misional.
La URL de petición debe tener la siguiente estructura. Cabe aclarar que esta estructura es
creada al momento de configurar el servicio en el servidor de seguridad de la entidad y no
hace parte de ninguna implementación en el componente “Soluciones integradas para la
interoperabilidad” o sistema misional de la entidad. En este caso de REST, se requiere
únicamente del header o encabezado antes mencionado:
88
Versión del protocolo Constante con el valor “r1”.
serviceID Representa el elemento de servicio con la siguiente estructura: X-ROAD-
INSTANCIA/Clase miembro del servicio/código miembro del servicio/código del
subsistema/código del servicio
[Headers]
X-Road-Client: [X-ROAD-INSTANCIA]/[CLASE MIEMBRO]/[CÓDIGO MIEMBRO]/[CÓDIGO
DEL SUBSISTEMA]
[Body]
[OBJETO JSON]
[URL]
http://ServidorSeguridadEntidad/r1/[X-ROAD -INSTANCIA]/[CLASE MIEMBRO DEL
SERVICIO]/[CÓDIGO MIEMBRO DEL SERVICIO]/[CÓDIGO DEL SUBSISTEMA]/[CÓDIGO DEL
SERVICIO]/URL del servicio
89
Content-type Indicar el content-type o tipo de contenido de respuesta del servicio y su
charset.
[HEADERS]
Content-Type →application/json;charset=utf-8
x-road-id →PLAYGROUND-3471aa24-72d8-41b9-a142-ef301c30f1b2
x-road-client →PLAYGROUND/COM/1234567-8/TestClient
x-road-service →PLAYGROUND/GOV/8765432-1/TestService/PTV
x-road-request-id →e82a8303-45a4-4776-b46f-f520906805f7
x-road-request-
hash →A/ZonC1EIvNN3bDy6cr3y3PzPSeDYNU0qp07J1Y65XnQFeSCdp7WLcncu9Ns2KKw8
A+r2332wGpXHLRO2F3YgQ==
[BODY]
[OBJETO JSON]
La transferencia de archivos se recomienda realizar leyendo el archivo como un array de bytes por
medio de los objetos de flujo de datos (streams). Al utilizar esta funcionalidad, se podrá:
- Transferir y manipular todos los tipos de archivos (pdf, xls, xlsx, doc, etc), ya que no se hace
ninguna manipulación a nivel de contenido de los archivos.
- Crear diferentes chunks o pequeños array de bytes para posteriormente enviar la
información por el servicio web.
En este punto es importante mencionar, si bien se está definiendo como límite y tamaño de los
chunks 5 MB, este parámetro será configurable y deberá ser validado con cada entidad al momento
de realizar el diseño técnico del servicio. En esta validación se considerarán los siguientes elementos
para modificar este parámetro:
- Capacidad del canal de comunicación
- Capacidad del servidor de la entidad que expone el servicio
90
Entidad Entidad
Consumidora Proveedora
Id, #PartesTotales
wsObtenerArchivoConsulta(Id, #Parte)
2
91
datos como Multipart ejecución de este
form-data. servicio podrá
hacerse de manera
asíncrona. Brinda la
posibilidad de
recuperar o
retransmitir chunks
que por alguna falla
de comunicación no
haya podido ser
entregada. Una vez se
transfieran todos los
archivos
exitosamente, la
entidad consumidora
deberá reconstruir el
archivo. Para llevar a
cabo esta
reconstrucción,
deberá crear un byte
array del tamaño
total del archivo y
recorrer los chunks,
concatenando estos
pequeños array de
bytes en el grande.
Por último, crear un
nuevo archivo a partir
del array de bytes
inicialmente definido.
Esta operación es
recomendada cuando
la tecnología del
servicio es SOAP, ya
que podrá hacer uso
del formato xml para
especificar y enviar el
archivo como string
codificado base 64.
Tener en cuenta que
al crear el String, el
charset (UTF-8, ASCII,
ISO) de creación
corresponde al
charset del archivo.
obtenerArchivoC POST Rest-Multipart POST / -- El response del
onsulta form-data entidadContext iE8XzPLATu3lqF9b servicio es multipar
POST SOAP MTOM /obtenerArchivo mPC50- form-data con dos
(Message Content-Type: hXQfBv_23178KS0C partes: una
transmission application/json Content- application/json y
Optimization { Disposition: form- otra octect-stream.
Mechanism) "idArchivo" : "XXXX", La segunda contiene
92
"numeroParte" : XX data; el array de bytes. De
(int) name="objJson" cara a tener el
} Content-Type: tamaño del mensaje
application/json lo más pequeño
Content-Length: 42 posible, no sería
necesario codificar el
{"idArchivo":"Servic array de bytes
ios","numeroParte" (considerando la
:25} implementación de
-- los
iE8XzPLATu3lqF9b lineamientos/recome
mPC50- ndaciones de la
hXQfBv_23178KS0C sección Seguridad en
Content- los servicios WEB del
Disposition: form- presente
data; name="file- documento), sino en
chunk" el octect-stream,
Content-Type: guardar directamente
application/octet- el array de bytes del
stream archivo. Sin embargo,
Content-Length: si la entidad desea
5242880 cifrar y adicionar una
capa de seguridad
<td>NO</td><td>N mayor al mensaje
O</td><td>SI</td> enviado, podría
<td>NO</td><td>2 codificar Base 64 el
0171228</td><td>< array de bytes y
/td><td>DHS60916 enviarlo en la parte
6</td><td Octect-Stream como
x:str>01</td><td>F un String codificado.
echa corte REPS: Jun Si la entidad desea
18 2019 enviar el archivo
3:10PM</td></tr>< como cadena String
tr><td>La base 64 del array de
Guajira</td><td>RI bytes, se recomienda
OHACHA</td><td revisar la
x:str>4484700671< implementación del
/td><td método antes
x:str>4400100671< mencionado.
/td><td
x:str>05</td><td>IP La entidad no debería
SI PALAIMA SEDE implementar las dos
RIOHACHA</td><td versiones de este
>CALLE 12 N 10 - mismo servicio, se
08</td><td>314700 recomienda
5134</td><td>ipsip únicamente o Rest-
alaima@hotmail.co Json o Multipart
m</td><td>900185 form-data.
729</td><td>9</td
><td>JURIDICO</td Las ventajas de
><td>4</td><td>P implementar el
�blica</td><td>1< multipar form-data
/td><td>Institucion son: velocidad en la
93
es - transferencia y el
IPS</td><td>NO</t tamaño del mensaje
d><td>1</td><td>I es menor siempre y
NDIGENA</td><td> cuando se haya
SI</td><td>3</td>< implementado la no
td>Consulta codificación base64.
Externa</td><td>3
40</td><td>340- Si la tecnología a
OTORRINOLARINGO implementar es
LOG�A</td><td>SI SOAP, se recomienda
</td><td>NO</td>< la implementación
td>NO</td><td>NO por SOAP-XML
</td><td>NO</ descrita en el método
-- anterior del servicio
iE8XzPLATu3lqF9b web.
mPC50-
hXQfBv_23178KS0C
--
notificarResultad POST Rest-Json POST / POST / Si el resultado de la
oOperacion POST SOAP-xml entidadContext entidadContext operación indicado
/notificarResultado /notificarResultado en el request del
Si bien ambas Content-Type: Content-Type: mensaje es 1,
tecnologías serían application/json application/json indicando éxito en la
soportadas, se { { reconstrucción del
recomienda utilizar "idArchivo" : "XXXX", "idArchivo" : archivo, la entidad
REST ya que permite "resultado" : 1,0 (int) "XXXX", quien expone, podría
una mayor } "resultado" : 1,0 eliminar el archivo y
escalabilidad para (int) sus partes o chunks.
diferentes tipos de }
datos como Multipart
form-data.
94
95