PLATAFORMA DE INTEROPERABILIDAD PDI - … · 6. PLATAFORMA DE INTEROPERABILIDAD DEL ESTADO...

PLATAFORMA DE INTEROPERABILIDAD PDI

MINISTERIO DE COMUNICACIONES

IINNTTRRAANNEETT GGUUBBEERRNNAAMMEENNTTAALL:: PPLLAATTAAFFOORRMMAA DDEE IINNTTEERROOPPEERRAABBIILLIIDDAADD

MANUAL DE OPERACIÓN Y ADMINISTRACION DE PDI Derechos Reservados

Bogotá, D.C.


Documento de Operación Plataforma PDI Pagina 2 de 123

Información del Documento

Nombre del Proyecto: Plataforma de Interoperabilidad

Preparado por: Mauricio Blanco / Luis Felipe García Versión del Documento:: Definitiva

Cargo: Líder Desarrollo / Funcionario HP Fecha: 31/07/2007

Revisado Por: Fecha de revisión:

Lista de Distribución

De: Fecha Teléfono/Fax/Email

Para: Acción Fecha Teléfono/Fax/Email

Dra. Maria Isabel Mejía Aprobación 31/07/2007 [email protected]

Jose Luis Rodriguez Aprobación 31/07/2007 [email protected]

*



Tabla de Contenido

1. AVISO DE CONFIDENCIALIDAD ................................................................................................... 6

2. ACEPTACIONES ........................................................................................................................ 7

3. INTRODUCCIÓN ....................................................................................................................... 8

4. PRESENTACIÓN ........................................................................................................................ 9

5. CONCEPTOS GENERALES ......................................................................................................... 11

6. PLATAFORMA DE INTEROPERABILIDAD DEL ESTADO COLOMBIANO ............................................... 13

6.1 Concepto de la Plataforma de Interoperabilidad. .......................................................... 13

6.1.1 Usuarios de la Plataforma de Interoperabilidad ...................................................................... 15

6.2 Trámites y Servicios en la Plataforma de Interoperabilidad. ......................................... 16

6.2.1 Definición de Trámite .......................................................................................................... 16

6.2.2 Definición de Servicios. ....................................................................................................... 21

6.3 Arquitectura de la Plataforma de Interoperabilidad. ..................................................... 23

6.3.1 Implementación de trámites y servicios. ................................................................................ 23

6.3.2 Ambientes de ejecución. ...................................................................................................... 25

7. REGISTRO EN LA PLATAFORMA DE INTEROPERABILIDAD ............................................................ 29

7.1 Procedimiento para registro de ciudadanos ................................................................... 29

7.1.1 Procedimiento a seguir por el ciudadano ............................................................................... 29

7.1.2 Procedimiento a seguir por el administrador de la PDI ............................................................ 33

7.2 Procedimiento para registro de entidades .............................................................................. 37

7.2.1 Procedimiento a seguir por la entidad ................................................................................... 37

7.3 Procedimiento para registro de Usuarios Delegados ................................................................ 42

7.4 Registro de asociación de certificados digitales de clientes ...................................................... 45

7.4.1 Firma digital y validación ..................................................................................................... 45

7.4.2 Registro de asociación de certificados digitales para ciudadanos .............................................. 46

8. GESTIÓN DE TRÁMITES Y SERVICIOS DE LA PDI ......................................................................... 50

8.1 Proceso para la creación de Trámites o Servicios. .......................................................... 50

8.1.1. Diseño del flujo de ejecución del trámite o servicio. ................................................................ 52

8.1.2. Desarrollo de los servicios de soporte al trámite o servicio. ...................................................... 52



8.1.3. Requerimientos de los Adaptadores de Agencia Conectada. ..................................................... 53

8.1.4. Tipos de Web Services requeridos. ....................................................................................... 57

8.2. Registro del trámite o servicio en la plataforma de Interoperabilidad. ......................... 59

8.2.1. Creación del trámite o servicio. ............................................................................................ 59

8.2.2. Adición Trámite .................................................................................................................. 73

8.3. Gestión de trámites o servicios. ...................................................................................... 76

8.3.1. Modificación del trámite o servicio. ....................................................................................... 76

8.3.2. Eliminación del trámite o servicio. ......................................................................................... 79

8.3.3. Consultas........................................................................................................................... 82

8.3.4. Reportes. ........................................................................................................................... 85

9. UTILIZACIÓN DE LOS TRÁMITES Y SERVICIOS EXPUESTOS EN LA PLATAFORMA DE INTEROPERABILIDAD

97

9.1. Sistemas de Información ................................................................................................ 97

9.1.1. Pasos Previos y Prerrequisitos para conectar Sistemas de Información que invocan tramites/servicios publicados en la PDI ........................................................................................................... 98

9.1.2. Conexión a la Interfase de Servicios Web de la PDI ...............................................................100

9.2. Uso de tramites/servicios publicados en la PDI por el Ciudadano ................................104

9.3. Uso de tramites/servicios publicados en la PDI por el Funcionario Público .................105

9.4. Uso de tramites/servicios publicados en la PDI por el Administrador Delegado ..........105

10. COMPONENTES PLATAFORMA DE INTEROPERABILIDAD ............................................................. 106

11. ELEMENTOS A RESPALDAR EN PLATAFORMA PDI ...................................................................... 113

12. PROCEDIMIENTOS RECOMENDADOS DE OPERACION ................................................................. 114

12.1. Diaria ...............................................................................................................................114

12.1.1. Ingresar al sitio de administración de PDI .............................................................................114

12.1.2. Buscar registros de logs .....................................................................................................115

12.1.3. Depuración de logs ............................................................................................................118

12.2. Semanal ...........................................................................................................................119

12.3. Mensual............................................................................................................................120

12.4. Anual ...............................................................................................................................120

13. RECUPERACION DE DESASTRES .............................................................................................. 121

14. SECUENCIA DE ENCENDIDO – APAGADO DE LA PLATAFORMA PDI ............................................... 122



15. CONSIDERACIONES DEL ENTORNO DE PLATAFORMA DE INTEROPERABILIDAD ............................. 123

15.1. Configuración de la Plataforma: ...................................................................................... 123

15.2. Reportes: ................................................................................................................... 123



1. AVISO DE CONFIDENCIALIDAD Nota de propiedad La información y datos contenidos en todas las páginas de este documento elaborado por Colombia Telecomunicaciones S.A. ESP constituyen secretos comerciales o información confidencial y privilegiada de Colombia Telecomunicaciones S.A. ESP de naturaleza comercial o financiera. La citada información se facilita a FONADE y AGENDA DE CONECTIVIDAD bajo las más estrictas obligaciones de confidencialidad, en el bien entendido que éste no revelará la misma a ningún tercero ni la usará, sin permiso de Colombia Telecomunicaciones S.A. ESP, para propósitos distinto de uso interno del presente proyecto. Este documento contiene información confidencial de Colombia Telecomunicaciones S.A. ESP, y está sujeto a las más estrictas obligaciones de confidencialidad.



2. ACEPTACIONES Las siguientes firmas significan la aprobación por parte de Colombia Telecomunicaciones y el programa Agenda de Conectividad del presente documento.

Agenda de Conectividad Agenda de Conectividad

Nombre: Dra. Maria Isabel Mejía Nombre: Jose Luis Rodriguez Fecha: 31/07/2007 Fecha: 31/07/2007



3. INTRODUCCIÓN El presente documento corresponde a las recomendaciones de operación de la plataforma para el Proyecto PDI diseñado e implementado para El Programa Agenda de Conectividad, de manera conjunta por parte de Colombia Telecomunicaciones S.A. ESP. Esta plataforma consta de equipos de cómputo y hardware Hewlett Packard y software de Sistema Operativo y aplicación Microsoft. Estos elementos requieren de una operación correcta que permita mantener la alta disponibilidad y confiabilidad de la solución. Los procedimientos de operación claros, definidos y establecidos permiten mantener de manera segura y disponible la plataforma y sus servicios.



4. PRESENTACIÓN Los sistemas de la Administración Pública se adquieren generalmente solución a solución, determinados por la necesidad de adquirir la mejor solución para satisfacer un objetivo específico. Como resultado de esto, se crea una amplia gama de islas de información y de datos a través de la Administración Pública - sin que exista una manera sencilla de desbloquear los valiosos activos de información que todas ellas contienen en su conjunto, para dar soporte a procesos más útiles y productivos. Los programas de interoperabilidad pueden ayudar a resolver estos problemas. Un acercamiento bien estructurado a la interoperabilidad ayuda a abrir bodegas de datos y de información, y permitir que la información sea intercambiada más fácil y útilmente entre sistemas. Las aplicaciones de gestión pueden entonces aprovechar toda aquella información integrada para proporcionar una mejor percepción, un mayor control y una eficiencia operacional mejorada en la gestión de la información. Como resultado final, es posible estar mejor informados, facilitar la toma de decisiones más oportunas, y todo ello relacionado con una mejor eficiencia en los costos. Los sistemas de información de las diferentes entidades del Estado Colombiano cumplen con la misión específica para la cual fueron desarrollados, pero estos sistemas de información no siempre son compatibles entre si, dificultando el intercambio de información y, por lo tanto, haciendo menos eficiente la administración pública. Para garantizar el adecuado flujo de información y de interacción entre los sistemas de información de las entidades del Estado, se hace necesario implementar modelos de integración e interoperabilidad que permitan que sistemas de información incompatibles puedan comunicarse adecuadamente. Este conjunto de modelos es el que provee y soporta la Plataforma de Interoperabilidad de la Intranet Gubernamental, permitiendo a un sistema de información comunicarse con cualquier otro de manera adecuada. Interacción entre entidades del estado: Intercambio de Información y utilización de Trámites y Servicios. Las entidades del estado necesitan interactuar por dos razones principales:

• Intercambiar información • Utilizar los trámites y servicios integrados, ofrecidos por los sistemas de

información de las entidades. Estos dos tipos de interacción son los que provee la plataforma de interoperabilidad para satisfacer los requerimientos de las entidades del Estado.



Interacción entre las entidades del estado y los ciudadanos: Trámites y servicios en línea Los ciudadanos necesitan interactuar con las entidades del Estado, para:

• Obtener Información • Utilizar servicios en línea • Ejecutar trámites en línea

Estos tres tipos de interacción son los que debe permitir la plataforma de interoperabilidad para satisfacer los requerimientos de las entidades del Estado y los ciudadanos.



5. CONCEPTOS GENERALES La interoperabilidad en este documento está relacionada con la posibilidad de que los sistemas de las Administraciones Públicas trabajen juntos de forma satisfactoria y productiva independientemente de la tecnología o la aplicación que se utilice, o el proveedor ha suministrado el sistema subyacente. Si bien la interoperabilidad puede tener significados diferentes dependiendo del contexto, el término generalmente es entendido como “la capacidad de diferentes productos y servicios de tecnología de información para intercambiar y usar datos e información con el objetivo de funcionar juntos en un entorno conectado en red.” Varias fuentes de todo el mundo corroboran esta definición, entre estas:

• El Diccionario de Telecomunicaciones de Newton define la interoperabilidad como “la capacidad de gestionar el software y el intercambio de información en una red heterogénea, p. e. una red extensa constituida por varias redes locales diferentes.”

• El Acta de e-Government de los EE.UU. del año 2002 define la interoperabilidad como “la capacidad con la que comunican e intercambian datos diferentes sistemas operativos y de software, aplicaciones, y servicios de una manera exacta, eficaz y consistente.”

• De la misma forma, el Acta de Derechos de Autor de Milenio Digital de los EE. UU (DMCA) del año 1998 define la interoperabilidad como “la capacidad con la que programas de ordenador intercambian información, así como la de utilizar mutuamente esa información que ha sido intercambiada entre ellos.”

• Un libro blanco sobre interoperabilidad creado por EICTA (European IT trade association) en junio de 2004, define la interoperabilidad como “la capacidad de dos o más redes, sistemas, dispositivos, aplicaciones o componentes para intercambiar información entre ellos y usar la información intercambiada.”

• El Marco europeo de Interoperabilidad, una iniciativa para facilitar la interoperabilidad de servicios y sistemas a nivel pan-europeo, define la interoperabilidad como “la capacidad de los sistemas de Tecnologías de la Información y las Comunicaciones (TIC) y de los procesos de negocio que soportan, para intercambiar datos y permitir compartir la información y conocimientos.”



En su acepción más simple, la interoperabilidad trata de asegurar que los sistemas trabajen juntos. Algunos de los factores subyacentes para la puesta en práctica de programas de interoperabilidad en la Administración Pública son:

• Servicios centrados en los ciudadanos: asegurando el despliegue de servicios públicos e información de modo que tengan sentido para los ciudadanos.

• Eficacia operacional: facilitando la alineación de procesos empresariales y tecnológicos en la Administración Pública para trabajar con más eficacia, como una organización colectiva más que como un conjunto de almacenes de información separados.

• Un retorno de la inversión (ROI), la interoperabilidad entre nuevos entornos y sistemas existentes permite cualquier migración gradual, eficiente y evolutiva a nuevas plataformas.

El empleo de los estándares apropiados ayuda a establecer la interoperabilidad a través de muchos proveedores, tecnologías y productos existentes en el mercado y de ahí que permita a productos dispares el hecho de poder compartir datos para funcionar juntos en un entorno conectado en red. Puede alcanzarse mejor este objetivo propuesto mediante una combinación de aproximaciones complementarias, incluyendo estándares abiertos. La interoperabilidad puede ser simplificada enormemente:

• Una sintaxis estándar, en la cual la información de todos los sistemas pueda ser expresada inequívocamente.

• Unos modelos semánticos estándar, de modo que las organizaciones pudieran expresar sus prácticas de negocio en un lenguaje consistente.

• Unos protocolos estándar, de modo que la información pudiera traspasar fronteras entre entornos operativos y entre organizaciones.

• Un estándar intermedio para enlazar comportamientos a documentos de negocio.



6. PLATAFORMA DE INTEROPERABILIDAD DEL ESTADO COLOMBIANO La plataforma de Interoperabilidad comprende la infraestructura de interoperabilidad mediante la incorporación de estándares de intercambio de información para el gobierno (GEL-XML), y las herramientas que permiten la integración y la interacción adecuada de los sistemas de información de las entidades del estado, y establece una sólida base tecnológica para el intercambio de información, servicios, y la implementación de trámites en línea.

Gobierno en

línea

Usuarios Administradores

Usuarios Finales

Usuarios

Enrutador

Enrutador Transaccional

Funcionario

Público

Admin.

Enrutador

Transaccional

Admin. Pruebas

Admin.

Delegado

solicita

solicita

solicita

Gestiona

Valida

permite

S.I. Entidad 1S.I. Entidad 1

Registra/modifica/

ellimina tramites/

servicios

administra

S.I. Entidad 2

S.I. Entidad 3

Presta servicios

Presta servicios

Consume servicios

Web

Service

redirecciona

Usuarios

Entidades

Funcionario

Empresa

Usuarios

Empresas

Admin.

Empresa

Usuarios

Enrutador

Ciudadano

Ciudadano

Convenciones

Admin. Entidad

S.I. Empresa 1

S.I. Empresa 2

Consume servicios

Consume servicios

S.I. (Sistema de

Información)

Figura 1. Modelo Conceptual Plataforma de Interoperabilidad

6.1 Concepto de la Plataforma de Interoperabilidad.

La Plataforma de Interoperabilidad del Estado Colombiano permite la conexión de los diferentes participantes que intervienen en los procesos del Estado Colombiano que requieren de algún tipo de intercambio de información para ejecutar un proceso. De forma conceptual actúa de concentrador inteligente en un modelo radial (hub and



spoke). El concentrador es inteligente porque no solo actúa como concentrador y enrutador si no que es posible definir operaciones compuestas en el centro de la estrella que integre servicios de múltiples proveedores.

Figura 2. Modelo Hub and Spoke de la Plataforma de Interoperabilidad

Como se observa en la figura anterior, la Plataforma de Interoperabilidad se encuentra conceptualmente en el centro de la estrella integrando los satélites que interactúan en los procesos de gobierno del estado colombiano. Esto permite que actúe como gestor y mediador entre los diferentes actores que participan en los procesos.

A partir de este modelo la Plataforma de Interoperabilidad está en capacidad de ofrecer a los diferentes satélites del modelo los servicios expuestos por los otros. Así,



por ejemplo, un ciudadano puede consumir un servicio ofrecido por una Entidad Gubernamental interactuando exclusivamente con la Plataforma de Interoperabilidad. Igualmente, esto permite tener la capacidad de crear cadenas de servicios especializando cada uno los participantes como consumidor o prestador de servicios.

6.1.1 Usuarios de la Plataforma de Interoperabilidad

Los siguientes son los Actores/Usuarios identificados en la Plataforma de Interoperabilidad:

Actor/Usuario Descripción Creado en el Sistema

por Persona Natural o Ciudadano (Abstracto)

Persona Natural.

N/A

Empresa (Abstracto) Persona Jurídica N/A Entidad (Abstracto) Agencia del gobierno N/A Administrador de Plataforma de Interoperabilidad

Encargado de administrar todos los servicios de gestión que presta la Plataforma de Interoperabilidad.

La instalación del Sistema

Administrador de Pruebas Ayuda en las labores de verificación y pruebas de nuevos trámites/servicios o nuevas versiones de estos.

Administrador de la PDI

Administrador Delegado Ayuda al Administrador en las labores de gestión de la PDI

Administrador de la PDI

Administrador de Entidad Encargado de la Entidad para la efectuar toda la interacción con la Plataforma de Interoperabilidad, es el encargado de crear y modelar el trámite de su entidad, creación de usuarios delegados de su entidad, hace uso del sistema de gestión para la entidad.

Solicitado por él mismo, Autorizado por el Administrador de la PDI

Administrador Empresa Persona encargada de administrar los servicios de la Plataforma de Interoperabilidad para una empresa, esta es la encargada de crear usuarios delegado de su empresa y puede hacer uso del sistema de gestión para la empresa


Usuario Delegado persona delegada por una entidad o empresa para ejecutar y consultar trámites en nombre de la entidad o empresa

Administrador de Entidad o Empresa

Ciudadano Persona Natural que hace uso de los servicios de la Plataforma de Interoperabilidad, puede ejecutar trámites, consultar resultado de trámites efectuados.


Usuario Anónimo Persona Natural que no tiene o no necesita un usuario en el sistema para poder interactuar

N/A



con el. Sistema de Información Sistemas de Información de Entidades o

Empresas que hacen uso de los trámites expuestos a través de servicios Web (Web Services) que expone la Plataforma de Interoperabilidad. Estos sistemas de información pueden solo iniciar la ejecución de Servicios (no trámites).

Administrador de Entidad o Empresa

6.2 Trámites y Servicios en la Plataforma de Interoperabilidad.

6.2.1 Definición de Trámite Se considera un trámite a toda interacción entre un ciudadano o una empresa y una entidad del Estado, así como toda interacción entre entidades del estado. De esta manera, existirían tres tipos de trámites: � Trámites informativos o consultas a entidades gubernamentales. � Trámites normados o trámites. � Trámites no normados o servicios.

Los Trámites electrónicos buscan ofrecer una alternativa respecto a los trámites tradicionales, permitiéndole al ciudadano interactuar con el Estado a través de canales no tradicionales, y a las entidades del Estado interactuar entre ellas, a través de la Intranet gubernamental.

Un trámite tradicional puede exigir: � Que el ciudadano haga presencia física y se identifique con su documento de

identidad en el momento de realizar el trámite. � Fotocopia del documento de identidad. � Firma. � Huella Digital. � Autenticación notarial de la firma o de alguno de los documentos anexos.

Así mismo, algunos trámites, para garantizar que la información diligenciada en sus formularios no va a ser cambiada, utilizan papel de seguridad. Todos estos requerimientos van asociados a requerimientos de autenticación, integridad y no repudiación.



Para que sea viable, un trámite electrónico debe tener características equivalentes a las de su contraparte tradicional. Un trámite tradicional puede requerir del ciudadano el diligenciamiento de un formulario, una firma, una huella, que se identifique con su cédula de ciudadanía, un recibo de consignación, documentación anexa, y más. El trámite electrónico debe ofrecer a la entidad información equivalente, que tenga las mismas características y cumplan con los mismos requerimientos que se piden para el trámite tradicional. Es por ello que para analizar lo que necesita un trámite electrónico, es necesario estudiar el trámite tradicional y sus características. Un trámite tradicional puede ser estructurado de la siguiente manera:

� Datos � Documentos anexos � Documentos generados por el usuario o por terceros � Documentos generados como resultado de otro trámite � Resultado

6.2.1.1 Representación de trámites

Un Trámite (Tx) que se representa como un círculo tiene asociado un conjunto de datos de entrada y salida. Los datos de entrada corresponden a los campos necesarios para la ejecución del trámite, mientras que los de salida están relacionados a los resultados de su ejecución. La representación gráfica de este concepto es:

Figura 3. Representación grafica de un trámite o servicio.

La ejecución de un trámite solo se podrá dar si tiene todos los datos de entrada requeridos, ya sean propios u obtenidos de sus trámites prerrequisito. Un trámite puede requerir como insumo (datos de entrada) el resultado (datos de salida) de otros trámites. Así, se define una relación de dependencias entre trámites.



La ejecución de un Árbol de Trámites como el mostrado en la siguiente gráfica, requiere que se conozcan los datos de entrada de todos los trámites del árbol, conformando así una lista unificada (debido a que puede haber datos comunes) de datos de entrada (compuesta por la unión de los datos de entrada para TA, TB, TC, TE y TG) y salida para el árbol (compuesta por los datos de salida de TA), así:

Figura 4. Árbol de ejecución de trámites.

Según lo anterior, puede haber datos comunes entre todos los trámites de un árbol, estos solo deben ser solicitados una vez durante la ejecución completa del árbol. La información de entrada de un trámite padre (como TA) está compuesta por la información ingresada por el usuario, junto con un subconjunto de los datos de salida para los trámites TB y/o TC. La siguiente gráfica muestra como los datos de salida de un trámite prerrequisito (TB) alimentan algunos datos de entrada de un trámite TA:



Figura 5. Flujo de datos en trámites compuestos.

El conjunto de datos de entrada y salida para un trámite, está modelado por un esquema independiente basado en GEL-XML.

6.2.1.2 Ejecución de Trámites.

La ejecución de un trámite, puede requerir la ejecución previa de los trámites con los que se relaciona, denominados Trámites Prerrequisitos, y así recurrentemente.

Figura 6. Tramites compuestos.

La anterior figura muestra un Árbol de Trámites, donde el trámite TA, tiene como trámites prerrequisitos, los trámites TB y TC, y a su vez, TC tiene como



prerrequisitos los trámites TE y TG. Con lo anterior, el orden de ejecución final del árbol sería por niveles del árbol, como se muestra a continuación:

1. TE y TG 2. TB y TC 3. TA

En un escenario ideal, la ejecución se hará por niveles, sin embargo, puede darse el caso en que la ejecución de TE y TG tome demasiado tiempo y se pueda iniciar la de TB, sin esperar a su culminación. Adicionalmente, se pueden llegar a presentar relaciones más complejas como la mostrada a continuación.

Figura 7. Tramite compuesto con prerrequisitos compartidos.

En esta variante de la anterior, se puede notar como el trámite TE es prerrequisitos de los trámites TB y TC. La ejecución completa de un árbol consiste de varias fases:

1. Obtención de la información requerida (datos de entrada) por cada uno de los trámites que deben ser ejecutados en el árbol.

2. Ejecución de cada uno de los trámites con la información suministrada. Un árbol de trámites es recorrido de arriba hacia abajo durante la primera fase, y en sentido inverso durante la segunda.



La primera fase de la ejecución se desglosa en los siguientes pasos:

1. Obtener la información para un trámite TX 2. Según los datos ingresados para el trámite TX, se evalúa cuáles de sus

trámites prerrequisitos son necesarios de ejecutar (algunos de estos puedes ser de ejecución condicional según la información ingresada para TX).

3. Se repite recurrentemente los pasos 1 y 2 para cada uno de los trámites prerrequisitos que será necesario ejecutar según la evaluación en el paso 2.

6.2.2 Definición de Servicios.

Se considera un servicio a toda interacción entre un ciudadano o una empresa y una entidad del Estado, así como toda interacción entre entidades del estado. De esta manera, existirían dos tipos de servicios: � Servicios informativos o consultas a entidades gubernamentales. � Trámites no normados o servicios.

Los servicios electrónicos buscan ofrecer una alternativa respecto a los servicios tradicionales, permitiéndole al ciudadano interactuar con el Estado a través de canales no tradicionales, y a las entidades del Estado interactuar entre ellas, a través de la Intranet gubernamental. Un servicio tradicional puede exigir:

� Que el ciudadano haga presencia física y se identifique con su documento de

identidad en el momento de realizar el servicio. � Fotocopia del documento de identidad. � Firma. � Huella Digital. � Autenticación notarial de la firma o de alguno de los documentos anexos.

Así mismo, algunos servicios, para garantizar que la información diligenciada en sus formularios no va a ser cambiada, utilizan papel de seguridad. Todos estos requerimientos van asociados a requerimientos de autenticación, integridad y no repudiación.



Para que sea viable, un servicio electrónico debe tener características equivalentes a las de su contraparte tradicional. Un servicio tradicional puede requerir del ciudadano el diligenciamiento de un formulario, una firma, una huella, que se identifique con su cédula de ciudadanía, un recibo de consignación, documentación anexa, y más. El servicio electrónico debe ofrecer a la entidad información equivalente, que tenga las mismas características y cumplan con los mismos requerimientos que se piden para el servicio tradicional. Es por ello que para analizar lo que necesita un servicio electrónico, es necesario estudiar el servicio tradicional y sus características. Un servicio tradicional puede ser estructurado de la siguiente manera:

� Datos � Documentos anexos � Documentos generados por el usuario o por terceros � Resultado

6.2.2.1 Representación de servicios

Un Servicio (Tx) que se representa como un círculo tiene asociado un conjunto de datos de entrada y salida. Los datos de entrada corresponden a los campos necesarios para la ejecución del servicio, mientras que los de salida están relacionados a los resultados de su ejecución. La representación gráfica de este concepto es:

Figura 8. Representación grafica de un servicio.

6.2.2.2 Ejecución de servicios.

La ejecución de un servicio solo se podrá dar si tiene todos los datos de entrada requeridos.



6.3 Arquitectura de la Plataforma de Interoperabilidad.

6.3.1 Implementación de trámites y servicios. Para que una entidad pueda exponer un trámite o servicio a través de la Plataforma de Interoperabilidad debe registrarlo previamente y seguir una secuencia de pasos que lo habiliten (ver capítulo 4 Gestión de Trámites y Servicios de la PDI). De forma similar, para que un actor pueda consumir un trámite o servicio expuesto a través de la Plataforma de Interoperabilidad debe ejecutar un proceso de registro y autenticación (ver capítulo 3 Registro en la Plataforma de Interoperabilidad).

Los Trámites y servicios de las entidades gubernamentales constituyen la base de servicios de la PDI. El modelo requiere que la Entidad desarrolle Web Services con características específicas y haga referencia a estos Web Services en la PDI. En capítulos posteriores se describirán las características que deben cumplir el Web Service y el procedimiento para crear la referencia en la PDI. Un Web Service que satisfaga estos requerimientos se califica como un Adaptador de Agencia Conectada, abreviado como AAC. Un trámite puede tener relación de ejecución con otros trámites. De esta forma es posible crear trámites compuestos que integren lógica de múltiples trámites y entidades. Dentro de estos conceptos se puede entender la PDI como una pasarela de servicios de múltiples prestadores de servicio.

Adaptador de

Agencia Conectada

Entidad A

Tramite A

Adaptador de

Agencia Conectada

Entidad C

Tramite D

Adaptador de

Agencia Conectada

Entidad B

Servicio C

Adaptador de

Agencia Conectada

Entidad A

Tramite B

Ciudadano

Sistema de

Información

Ciudadano

Empresa

Figura 9. Presentación de trámites o servicios en la PDI:



Como se describe en la grafica anterior, los tramites o servicios son publicados por las Entidades o Agencias gubernamentales en la Plataforma de Interoperabilidad y expuestos a los consumidores por la PDI. De esta forma la relación del consumidor del trámite o servicio es exclusivamente con la PDI que actúa como gestor de ejecución del trámite o servicio con las entidades. Dada la capacidad de estructurar trámites compuestos en la PDI se establece que la relación de un consumidor de un trámite en la PDI no es necesariamente uno a uno con las entidades o los tramites expuestos por estas si no que es posible que cuando un ciudadano seleccione ejecutar un trámite de una entidad, este trámite establezca una relación transitiva con otro tramite de otra entidad. La siguiente figura describe este comportamiento.

Adaptador de

Agencia Conectada

Entidad A

Tramite A

Adaptador de

Agencia Conectada

Entidad C

Tramite D

Adaptador de

Agencia Conectada

Entidad B

Servicio C

Adaptador de

Agencia Conectada

Entidad A

Tramite B

Ciudadano

Sistema de

Información

Ciudadano

Empresa

Figura 10. Tramites compuestos en la PDI.

Un usuario que consume el trámite D establece una relación indirecta con el Adaptador de Agencia Conectada para el trámite D en la Entidad C sin requerir ninguna otra relación. Pero si el servicio que consume es el Trámite B, que requiere del Trámite D para la ejecución, el usuario establece una relación transitiva con la Entidad C ejecutando el Trámite D. Este modelo resalta una de las principales características de la Plataforma de Interoperabilidad que es el concepto de desarrollar dinámicamente en la PDI jerarquías de ejecución de trámites compuestos. Esta capacidad determina una



naturaleza de entorno de desarrollo en la PDI para las entidades que están definiendo los trámites y servicios que expondrán a través de la PDI, creando un modelo de múltiples ambientes de ejecución para la Plataforma de Interoperabilidad.

6.3.2 Ambientes de ejecución. La naturaleza de plataforma de desarrollo de la PDI requiere de un ambiente de desarrollo y preproducción en donde los encargados de la Entidades Gubernamentales puedan implementar el trámite y servicio y establecer los trámites prerrequisito que requiere la ejecución de este. De esta forma un administrador de entidad encargado de la definición de un trámite o servicio tiene la posibilidad de definir las relaciones entre trámites, conectar los Adaptadores de Agencia Conectada, realizar pruebas de funcionamiento todo esto en un entorno privado antes de que el servicio sea publicado efectivamente al público. Este entorno se denomina dentro de la PDI como el ambiente de Preproducción.



Ambiente de

Preproducción

AAC - Pruebas

Entidad A - Tramite A

AAC - Pruebas

Entidad A - Tramite B

Ciudadano

De prueba

Sistema de

Información

Ciudadano

De prueba

Empresa

de pruebas

Gestión de tramites

Por entidades

Administrador de

Entidad

Administración de la

Plataforma de

Interoperabilidad Administrador de

Plataforma

AAC – Pru. Rta. Aut.




AAC - Pruebas

Entidad B - Servicio C


Entidad C - Tramite D

AAC - Pruebas


Figura 11. Ambiente de Preproducción de la PDI.

El ambiente de preproducción constituye un entorno de desarrollo y pruebas para las que las Entidades puedan definir, probar, estabilizar y solicitar la publicación de los trámites y servicios que serán publicados en el Ambiente de Producción de la PDI. Este modelo exige crear y mantener usuarios finales de pruebas que deben ser administrados por cada una de las entidades que están en el proceso de pruebas. La gestión de la entidad se realiza mayoritariamente en este ambiente, es acá donde se define el trámite, se establecen las dependencias con otros trámites y se establecen las propiedades asociadas a los trámites y servicios.

En este ambiente se requieren dos tipos de Adaptadores de Agencia Conectada - AAC. Un AAC de pruebas que debe estar conectado a los sistemas de pruebas en la entidad. Es utilizado para probar puntualmente la lógica y funcionalidad de ese



trámite particular. Es un modelo idéntico al que estará implementado en producción pero conectado a los sistemas de prueba en la entidad. Además de este se requiere un segundo tipo de adaptador que permite las pruebas de trámites donde el trámite en cuestión es un prerrequisito, esto en caso de que la solicitud corresponda a un trámite.

En resumen, se identifican tres tipos de AACs:

1. AAC de producción 2. AAC de pruebas, conectado al sistema de pruebas de la entidad 3. AAC que permite las pruebas de trámites donde el trámite en cuestión es un

prerrequisito (en caso de que aplique). También denominado AAC “Dummy”.

Ambiente de

Preproducción

AAC - Pruebas


AAC - Pruebas


Tramite A

Tramite B

Servicio C

Tramite D

Ciudadano

De prueba

Sistema de

Información

Ciudadano

De prueba

Empresa

de pruebas


Por entidades

Administrador de

Entidad


Plataforma de


Plataforma

Ambiente de

Producción

AAC - Producción

Entidad A

Tramite A

AAC - Producción

Entidad C

Tramite D

AAC - Producción

Entidad B

Servicio C

AAC - Producción

Entidad A

Tramite B

Tramite A

Tramite B

Servicio C

Tramite D

Ciudadano

Sistema de

Información

Ciudadano

Empresa


Por entidades

Administrador de

Entidad


Plataforma de


Plataforma

Proceso de publicación





AAC - Pruebas

Entidad B - Servicio C



AAC - Pruebas


Figura 12. Ambientes de preproducción y producción de la PDI.



Una vez el trámite o servicio ha sido completamente probado en el ambiente de preproducción el administrador de la entidad solicita a la plataforma su publicación en el ambiente de producción, utilizando las herramientas de administración que provee la misma plataforma. Un trámite o servicio publicado puede ser accedido por los usuarios que el administrador de la entidad haya definido. La siguiente tabla indica cual tipo de AAC es llamado por cada uno de los usuarios del sistema dependiendo del ambiente en el que se encuentren:

Ambiente Preproducción Ambiente Producción

Ciudadano/Usuario Delegado AAC conectado a los sistemas de pruebas en la Entidad

AAC conectado a los sistemas de producción en la Entidad

Sistema de Información AAC conectado a los sistemas de pruebas en la Entidad

AAC conectado a los sistemas de producción en la Entidad



7. REGISTRO EN LA PLATAFORMA DE INTEROPERABILIDAD Para solicitar las credenciales de autenticación, ya sea para publicar o usar servicios, en la Plataforma de Interoperabilidad las entidades gubernamentales deben comunicarse con la Agenda de Conectividad donde se establece el procedimiento a seguir para la solicitud y emisión de las credenciales requeridas. Como respuesta a la solicitud el solicitante recibirá las instrucciones de acceso al Sitio Web para registro, previa aprobación del requerimiento. En general, el procedimiento a seguir en la solicitud y emisión de las credenciales para los ciudadanos y/o administradores es el mismo, difiere solamente los campos que se deben diligenciar.

7.1 Procedimiento para registro de ciudadanos

7.1.1 Procedimiento a seguir por el ciudadano

1. Se entra al sitio Web correspondiente en este caso el sitio de ciudadanos (URL: http://200.21.208.237/PDISitioCiudadanos/Login.aspx), se hace clic en el link Ingreso por primera vez.



2. El sistema despliega una pantalla solicitando los datos del usuario (Información Personal e Información de Seguridad) que va a ser agregado en la Plataforma de Interoperabilidad (PDI).



3. Se diligencia el formulario llenando todos los campos de manera correcta y se hace clic en el botón enviar formulario.



4. El sistema envía una notificación por pantalla de que la solicitud ha sido enviada satisfactoriamente.

7.1.2 Procedimiento a seguir por el administrador de la PDI

El proceso continúa en el sitio de Administración de la PDI, por lo tanto se mostrarán las operaciones que realizará el administrador de la PDI, una vez haya iniciado sesión en el sitio Web correspondiente.



1. Se ingresa al sitio de administración de la PDI, se digita el usuario y la contraseña correspondiente y luego se presiona el botón Aceptar.

2. El sistema despliega la pantalla de bienvenida al sitio, luego en el menú de opciones se hace click en el link (Asignar Credenciales).



3. Se busca el usuario deseado y se hace click en la opción Editar.



4. El sistema habilita una serie de opciones, en las cuales seleccionamos el checkbox Aprobar y se digita un comentario.



5. Una vez seleccionado el usuario y completadas las opciones requeridas hacemos clic en el link Modificar, con lo cual se guarda la información modificada.

7.2 Procedimiento para registro de entidades

7.2.1 Procedimiento a seguir por la entidad

1. Se entra al sitio Web correspondiente en este caso Entidades (URL: http://200.21.208.237/PDIAdminEntidades/Login.aspx), se ingresa la información solicitada (Tipo Documento, No.Documento, Nit, Contraseña) de administrador de entidad autorizado en la plataforma de interoperabilidad luego se hace click en el botón aceptar.



2. El sistema despliega la pantalla de administración de entidades, en el menú de

opciones para Sistemas de Información se observa el link (Crear) correspondiente para su creación en la plataforma de interoperabilidad.



3. El sistema despliega una pantalla solicitando los datos del usuario en este caso

usuario Sistema de Información, se diligencia el formulario llenando todos los campos de manera correcta y luego se hace click en el botón Crear Usuario.



4. El sistema envía una notificación por pantalla “Usuario creado con Éxito, se envió un correo electrónico con los datos de la credencial“ de que la solicitud ha sido procesada satisfactoriamente.



El usuario Administrador de Entidad, continua con el proceso dando click en el botón Continuar.

5. El sistema despliega la pantalla de administración de entidades, donde puede gestionar acciones para el sistema de información creado con son: editar, listar, buscar trámites para S. de I., Listar trámites ofrecidos para S. de I.



7.3 Procedimiento para registro de Usuarios Delegados 1. El administrador de la entidad entra al sitio Web correspondiente en este caso Entidades

(URL: http://200.21.208.237/PDIAdminEntidades/Login.aspx), se ingresa la información solicitada (Tipo Documento, No.Documento, Nit, Contraseña) de administrador de entidad autorizado en la plataforma de interoperabilidad luego se hace click en el botón aceptar.



2. El sistema despliega la pantalla de administración de entidades, en el menú de opciones para Administración de Usuarios Delegados se observa el link (Crear Usuario Delegado) correspondiente para su creación en la plataforma de interoperabilidad.



3. El sistema despliega una pantalla solicitando los datos del usuario en este caso Usuario Delegado.

4. Se diligencia el formulario llenando todos los campos de manera correcta y luego se

hace click en el botón Crear Usuario.



5. El sistema envía una notificación por pantalla “El usuario ha sido creado“ de que la

solicitud ha sido procesada satisfactoriamente.

7.4 Registro de asociación de certificados digitales de clientes

7.4.1 Firma digital y validación

La PDI incluye el uso de certificados digitales1 para la autenticación en el proceso de ingreso del ciudadano. En la funcionalidad se extiende el uso de certificados digitales para la firma de la información transferida entre la plataforma de interoperabilidad y las entidades y viceversa. En el numeral 4.1.3.3. Seguridad se establece el esquema de validación en conjunto con las normas de seguridad de la plataforma.

1 Certicamara, entidad certificadora y autorizada por la Superintendencia de Industria y Comercio



El uso de certificados digitales en la PDI, permite:

1. Asegurar la entrada (autenticación) a los sitios de Ciudadanos, Empresas, Entidades y Administración de la PDI.

2. Firmar mensajes asegurando su procedencia y autoría, en la plataforma de interoperabilidad.

3. Encriptar la comunicación de manera que sólo el destinatario pueda verla.

7.4.2 Registro de asociación de certificados digitales para ciudadanos

1. Se entra al sitio Web correspondiente en este caso el sitio de ciudadanos (URL: http://200.21.208.237/PDISitioCiudadanos/Login.aspx), se ingresan los datos del ciudadano a modificar, luego se hace click en el botón Aceptar.

El sistema despliega una pantalla de administración de información de ciudadanos, en menú de opciones se hace click en Actualizar Datos.



2. En la pantalla se hace click en el botón Editar, para modificar la información del ciudadano entre otros la de Asociar nuevo certificado o Eliminar certificado.



El proceso continua haciendo click en el botón Actualizar.

3. El sistema envía una notificación por pantalla de que la solicitud de modificación ha sido procesada satisfactoriamente.



8. GESTIÓN DE TRÁMITES Y SERVICIOS DE LA PDI

8.1 Proceso para la creación de Trámites o Servicios.

La publicación de un nuevo trámite o servicio por parte de una Entidad en la Plataforma de Interoperabilidad sigue el siguiente flujo de actividades:



A continuación se describen cada uno de los elementos de este proceso.

8.1.1. Diseño del flujo de ejecución del trámite o servicio.

Para poder integrar un trámite o servicio de una entidad del estado a la Plataforma de interoperabilidad, éste debe ser primero modelado. Para modelar el trámite o servicio debe seguirse el proceso descrito en el estándar GEL-XML, tanto para la especificación de datos de entrada como la especificación de datos de salida. Los detalles de las tareas sugeridas para modelar el trámite o servicio y generar los esquemas GEL-XML están relacionadas en los documentos del estándar GEL-XML. Los resultados finales de este proceso son:

o Un esquema XSD de entrada y o Un esquema XSD de salida.

Ambos esquemas existen como archivos (.XSD) y/o almacenados en un Repositorio de Esquemas GEL-XML con acceso desde la PDI.

8.1.2. Desarrollo de los servicios de soporte al trámite o servicio. Los trámites o servicios de la entidad que podrán ser habilitados para conectar desde la Plataforma de interoperabilidad deben residir en un Web Service con características específicas. Estas características requeridas serán descritas en el curso de este capítulo y calificarán el cumplimiento (compliant) del Web Service con la Plataforma de interoperabilidad. Cuando un Web Service satisface estos requerimientos y se califica como compliant, el Web Service se convierte en un Adaptador de Agencia Conectada – AAC – para la Plataforma de interoperabilidad. Los Web Services son elementos fundamentales en la evolución hacia la computación distribuida a través de redes compartidas. Se han convertido en la plataforma de integración de aplicaciones gracias a los estándares abiertos y al énfasis en la comunicación y colaboración entre organizaciones y aplicaciones. Las aplicaciones se estructuran integrando múltiples Web Services de origen distinto que funcionan conjuntamente, sin importar su ubicación o la forma en que se implementaron. La Plataforma de Interoperabilidad tiene base en Web Services entre otras por las siguientes características:



o Los Web Services ofrecen funciones muy útiles a usuarios del medio Web ya que emplean un protocolo Web estándar que, en la Plataforma de Interoperabilidad, es SOAP.

o Los Web Services permiten describir sus interfaces con suficiente detalle para que el usuario diseñe una aplicación cliente que permita comunicarse con ellas. Esta descripción se proporciona normalmente en un documento WSDL.

o Los conceptos de Web Services está muy extendido y ha sido bastante adoptado como el mecanismo de integración e interoperabilidad por excelencia.

Una de las principales ventajas de la arquitectura de los Web Services es que permite que los programas escritos en lenguajes y plataformas diferentes puedan establecer comunicación entre sí de forma estándar. Otra ventaja de los Web Services es que SOAP es bastante menos complejo que otros modelos, de modo que resulta más fácil que una implementación cumpla con los estándares de SOAP. Adicionalmente, otra ventaja importante es que los Web Services se basan en protocolos estándar, como XML, HTTP y TCP/IP. Muchas entidades gubernamentales y empresas disponen ya de una infraestructura Web, así como de personal y conocimientos para mantenerla, de modo que el esfuerzo y costo de entrada a estos servicios es mucho menor que con otras tecnologías. Por esto, la Plataforma de interoperabilidad utiliza los Web Services como las piezas de software de integración con las entidades gubernamentales y las empresas.

8.1.3. Requerimientos de los Adaptadores de Agencia Conectada. La infraestructura de Web Services se fundamenta en la comunicación por medio de mensajes basados en XML que cumplen con una descripción de servicio publicada. La descripción del servicio es un documento XML escrito en una gramática XML denominada WSDL, Web Services Description Language, que define el formato de mensaje comprensible para el Web Service. La descripción del servicio sirve como acuerdo que define el comportamiento de un Web Service e indica a la Plataforma de Interoperabilidad cómo interactuar con él. El comportamiento de un Web Service está determinado por modelos de mensajería que el servicio define y admite. Estos modelos dictan conceptualmente lo que el consumidor del servicio, en este caso la Plataforma de interoperabilidad, puede esperar que ocurra cuando se envía un mensaje con formato correcto al Web Service. Además de las definiciones de formato de mensaje y los modelos de mensajería, la descripción del servicio puede contener la dirección asociada a cada punto de entrada del Web Service. El formato de esta dirección se ajusta al protocolo utilizado para el



acceso al servicio, como una dirección URL para HTTP en el caso de la Plataforma de interoperabilidad.

8.1.3.1. Estándares soportados. Los Web Services ofrecen comunicación para sistemas con diferentes sistemas operativos y plataformas de desarrollo. Para conseguir este objetivo, se basan en una familia de especificaciones de protocolos de industria, un conjunto extendido de estos estándares se denomina WS-*. Para la versión 1.0 de la Plataforma de interoperabilidad los estándares de relacionados con Web Services soportados son:

o XML, Versión 1.1 o XML Schema, Versión 1.1 o SOAP, Versión 1.1 o WSDL, Versión 1.1 o XSL, Versión 1.0 o WS-Security 1.0

Con el cumplimiento de los anteriores estándares y versiones, se dice que el Web Service cumple con la especificación Basic Profile 1.0 de WS-I2

8.1.3.2. Interfaces mínimas requeridas. La notación que utiliza un archivo WSDL para describir formatos de mensaje se basa en el estándar XML. Esto significa que es un idioma de programación neutral y basada en estándares, lo cual es ideal para describir interfaces de Web Services que pueden consumirse desde una gran variedad de plataformas y lenguajes de programación. Además de describir el contenido de un mensaje, WSDL define el lugar en el que está disponible el servicio y qué protocolo de comunicaciones se utiliza para hablar al servicio. Esto significa que el archivo WSDL define todos los elementos necesarios para escribir un programa que pueda funcionar con un Web Service. En el Anexo A, se encuentra el esquema XML que define la estructura del WSDL que soporta la versión 1.0 de la Plataforma de interoperabilidad. De este esquema se desprende que se requieren cinco métodos obligatorios para el Adaptador de agencia conectada, estos son:

Método Descripción

Consultar Le permite consultar a la PDI si el ciudadano ya había ejecutado previamente ese trámite o servicio, en cuyo caso retorna su resultado. Utiliza como

2 Mayor información sobre la especificación Basic Profile se puede encontrar en http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html



parámetros de búsqueda, las Llaves de Consulta.

Ejecutar Permite iniciar la ejecución de un trámite o servicio en la Entidad. Si el mecanismo de respuesta al usuario es Inmediato, retorna su respuesta, sino, la respuesta puede ser consultada a través de la función ConsultarResultado.

ConsultarResultado Permite obtener la respuesta de trámites o servicios ejecutados de manera No-Inmediata.

VerificarFuncionamiento Le permite consultar a la PDI si el Web Service se encuentra en-línea

Tarifar Le permite a la entidad tarifar la ejecución de un trámite.

Las anteriores funciones (salvo VerificarFuncionamiento) reciben un documento XML como parámetro de entrada y retornan otro documento XML. La estructura de estos documentos de entrada y salida se describe como parte del Anexo B. Los parámetros de cada una de estas funciones se describen a continuación:

Consultar

Parámetro Tipo Descripción

Consultar Entrada Estructura XML que contiene la información utilizada para consultar el resultado de una ejecución previa del trámite o servicio.

ConsultarResponse Salida Estructura XML que contiene la información de salida de la consulta. En el caso que se haya encontrado una ejecución previa, retorna este resultado.

Ejecutar


Ejecutar Entrada Estructura XML que contiene la información utilizada para iniciar la ejecución de un trámite en la Entidad

EjecutarResponse Salida Estructura XML que contiene el resultado de iniciar la ejecución de un trámite o servicio en la Entidad.

ConsultarResultado


ConsultarResultado Entrada Estructura XML que contiene la información utilizada para consultar el resultado de la ejecución de un trámite o servicio en la Entidad.

ConsultarResultadoResponse Salida Estructura XML que contiene el resultado de la ejecución de un trámite o servicio, si este ya es conocido.



VerificarFuncionamiento


VerificarFuncionamiento Entrada Estructura XML que contiene la información utilizada para consultar el estado del sistema de información

booleano Salida Verdadero si el sistema se encuentra activo, de lo contrario False

Tarifar


Tarifar Entrada Estructura XML que contiene la información utilizada para tarifar la ejecución de un trámite en la Entidad.

TarifarResponse Salida Estructura XML que contiene el resultado de la tarifación de un trámite

Importante: si un trámite o servicio fue modelado por la entidad para requerir “firma digital”, el total del formulario de entrada (como formulario XHTML) diligenciado por el usuario es firmado utilizando su Certificado Digital. Esto naturalmente implica que solo aquellos usuarios que disponen de un Certificado Digital como medio de Autenticación pueden ejecutar estos trámites o servicios. Una vez firmado el formulario, este llega al Web Service de la Entidad en su versión firmada y “plana” (dentro del parámetro “formulariofirmado”), donde puede ser validado y/o almacenado como constancia de no-repudio.



8.1.3.3. Seguridad

WS-Security y en conjunto con Certificados Digitales deben ser utilizados para proporcionar la autenticación, confidencialidad, e integridad de los mensajes SOAP intercambiados entre la PDI y el Web Service que soporta el trámite o servicio en la entidad. La siguiente grafica muestra como WS-Security es utilizado en conjunto con Certificados Digitales X.509 para asegurar el intercambio de mensajes SOAP. Note como ambos sistemas deben conocer previamente las Llaves Públicas de su contraparte:

El Anexo C muestra el contenido del archivo de políticas (Policies) que describe los requerimientos de seguridad (WS-Security) que debería exigir un Web Service que soporte un Trámite/Servicio. Importante: Solo si se cumplen los requisitos de seguridad indicados en las políticas, se podrá calificar el Adaptador de Agencia Conectada – AAC –como compliant con la Plataforma de interoperabilidad.

8.1.4. Tipos de Web Services requeridos. La Plataforma de interoperabilidad requiere tres Adaptadores de agencia conectada para el soporte interno por cada uno de los trámites o servicios que sean registrados en la Plataforma. Estos adaptadores son:

o Adaptador de pruebas. o Adaptador de pruebas de respuesta automática (también conocido como

“dummy”). o Adaptador de producción.



Todos estos tres Adaptadores exponen la misma interfase de llamados (WSDL).

8.1.4.1. Adaptador de pruebas. El propósito de este adaptador es atender los requerimientos de prueba del ambiente de pre-producción de la Plataforma de interoperabilidad específicamente para el trámite o servicio que atiende el adaptador. Debe estar conectado a los sistemas de pruebas de la entidad gubernamental, igualmente debe estar en un recurso de localización URL especifico y particular para el adaptador. La naturaleza de respuesta de este adaptador puede ser sincrónica o asincrónica, así como puede requerir intervención humana para obtener la respuesta a la solicitud de servicio.

8.1.4.2. Adaptador de pruebas de respuesta automática. El propósito de este adaptador es atender los requerimientos de prueba del ambiente de pre-producción de la Plataforma de interoperabilidad para aquellos trámites o servicios para los cuales el trámite o servicio específico es un prerrequisito. Debe estar en un recurso de localización URL específico y particular para el adaptador. La naturaleza de respuesta de este adaptador puede ser sincrónica o asincrónica, pero debe producir una respuesta sin requerir intervención humana. Este adaptador debe contener la lógica de negocio internamente, y de ser la mejor opción, sin requerir conexión a los sistemas de información de la entidad. Esta característica implica que las reglas de negocio para datos de prueba del adaptador deben ser suficientemente completas para lograr modelar las diferentes respuestas que pueden entregar el trámite o servicio en diferentes escenarios de ejecución.

8.1.4.3. Adaptador de producción. El propósito de este adaptador es atender los requerimientos del ambiente de producción de la Plataforma de interoperabilidad. Debe estar en un recurso de localización URL específico y particular para el adaptador. Está conectado a los sistemas de producción de la entidad y contiene toda la lógica para resolver el trámite o servicio en producción. Es a este adaptador donde debe apuntar la Plataforma de Interoperabilidad en producción.



8.2. Registro del trámite o servicio en la plataforma de Interoperabilidad.

8.2.1. Creación del trámite o servicio. La siguiente gráfica muestra la secuencia ocurre en el proceso de registro del trámite o servicio en la Plataforma de interoperabilidad, así como el responsable de cada tarea en el flujo.

Figura 13. Secuencia de registro de un trámite o servicio en la PDI.

La imagen anterior muestra el proceso general de registro de un nuevo trámite o servicio en la PDI. Posterior a la solicitud de registro del trámite o servicio, se debe pasar por una instancia de aprobación por parte del Administrador de la PDI, quien



debe aprobar su publicación en el ambiente de producción. Es importante resaltar que toda la definición del trámite o servicio queda almacenada en un repositorio lógico independiente. De acuerdo a lo anterior, los pasos puntuales a realizar por parte del administrador de la entidad, dentro de la herramienta para la creación de un trámite o servicio, son los siguientes:

1. Seleccionar la opción Crear Trámite o Crear Servicio, según corresponda en el menú ubicado a la izquierda de la pantalla. 2. Asignar la naturaleza del procedimiento por generar (seleccionar trámite cuando corresponde a un proceso que debe ser ejecutado y procesado bajo una normatividad específica mientras que debe seleccionar servicio no cuenta con dichas características pero sí corresponde a una implementación concreta de la entidad de cara al usuario) (fig. 4.3.1.1. – A). Adicionalmente seleccione el nombre del trámite a crear (fig. 4.3.1.1. – B), el cual ya está previamente cargado en la base de datos del PEC de acuerdo a la entidad que se haya validado; para el caso de creación de servicios, el nombre debe ser digitado directamente sobre el formulario. Oprima el botón Crear para continuar con el siguiente paso.



(fig. 4.3.1.1. Creación de trámites / Crear Trámite)

3. En la página Modalidad de Respuesta encontrará su correspondiente modalidad de respuesta (fig. 4.3.1.2. – A) la cual inicialmente será Servicio Web ya que su ejecución es en línea. Seguido a ello debe señalar si el procedimiento es personal e intransferible (fig. 4.3.1.2. – B) y posteriormente asignar los esquemas GEL-XML de Entrada y Salida (fig. 4.3.1.2. – C). Cada uno de ellos corresponden a los estándares XML que van a ser implementados para favorecer la uniformidad de los trámites/servicios y de esta manera evitar errores al momento del intercambio de información.

(fig. 4.3.1.2. Creación de trámites / Modalidad de Respuesta)

4. En el siguiente paso, debe asignar los roles que pueden ejecutar el trámite/servicio, es decir, el tipo de usuario que debe llevar a cabo el procedimiento. Puede escoger entre Anónimo si el trámite/servicio puede ser ejecutado por un usuario no registrado, Ciudadano, Sistema de información, Usuario Delgado de Empresa o Usuario Delegado de Entidad (Ver numeral 2.1.1. Usuarios de la Plataforma de Interoperabilidad donde se describen los tipos de usuario).



5. Una vez asignados los roles, se procede a establecer las Llaves de Consulta las cuales corresponden a los parámetros de validación que tendrá inicialmente el trámite al momento de ser ejecutado. Dicha opción establece los parámetros de búsqueda donde se determina si la información requerida acerca del usuario y si ya está llevando a cabo el trámite/servicio, ya se encuentra en las bases de datos del sistema. En el segmento izquierdo de la pantalla encuentra el árbol de opciones que componen el esquema GEL-XML seleccionado en la pantalla anterior (fig. 4.3.1.3. – A). Haga clic sobre la opción que desea asignar como llave de consulta (fig. 4.3.1.3. – B) y oprima el botón Adicionar (fig. 4.3.1.3. – C). El campo asignado quedará listado en la primera casilla del segmento derecho (fig. 4.3.1.3. – D). Repita el procedimiento anterior si desea establecer más llaves de consulta. Finalmente puede llevar a cabo asociaciones entre los campos que ya se encuentran en el registro del usuario que está llevando a cabo el trámite/servicio y los campos que deben ser diligenciados en el trámite que se está creando. Para hacer esto, seleccione la Llave de Consulta que desea asociar en la primera casilla del segmento derecho (fig. 4.3.1.3. – D) y luego oprima el botón Asociar Credenciales (fig. 4.3.1.3. – E); en la ventana emergente seleccione el campo con el que desea realizar la asociación y oprima le botón Guardar. La asociación quedará registrada en la segunda casilla del segmento derecho (fig. 4.3.1.3. – F).



(fig. 4.3.1.3. Creación de trámites / Llaves de Consulta)

6. En la siguiente pantalla se cargan las operaciones desde tres (3) adaptadores. En cada casilla deberá ser digitado el URL en el cual se encuentra cada uno de ellos. El primero corresponde al webService de pruebas (fig. 4.3.1.4. – A) el cual asegura la respuesta con el servidor. El segundo es el webService de dummy (fig. 4.3.1.4. – B) el cual clasifica la información que será considerada como prueba. El tercero es el webService de producción (fig. 4.3.1.4. – C) el cual se encarga de la conexión con el servidor final de almacenamiento. Siendo asignados los tres (3) adaptadores de agencia conectada debe oprimir el botón Identificar Operaciones con el fin que el aplicativo reconozca las funciones de cada uno de ellos (fig. 4.3.1.4. – D). Es preciso que en el caso de publicar el trámite/servicio en Preproducción), al menos esté asignado el adaptador de pruebas. Para el caso de publicar finalmente en producción deben ser identificadas y cargadas las operaciones de los tres (3) adaptadores.



Una vez identificadas las operaciones, el sistema muestra el nombre del servicio y sus respectivas funciones para cada uno de los adaptadores. Para ver el detalle de ella, haga clic sobre el icono el cual mostrará el código de la correspondiente operación (fig. 4.3.1.4. – E). Para continuar con el siguiente paso, debe dar clic en el botón Cargar Operaciones (fig. 4.3.1.4. – F) y esperar el mensaje Operaciones cargadas satisfactoriamente y posteriormente oprimir el botón Siguiente.

(fig. 4.3.1.4. Creación de trámites / Carga Operaciones WebService)

7. Paso para Trámites: En este paso, el cual es opcional (para ser tenido en cuenta en los casos que aplique), se deben asignar los trámites prerrequisito que van asociados al trámite que se está generando. En primera instancia cuenta con una herramienta para buscar el trámite, donde selecciona el criterio de búsqueda, bajo las opciones nombre, entidad o descripción (fig. 4.3.1.5. – A); en el siguiente campo ingrese la palabra clave para llevar a cabo la búsqueda (fig. 4.3.1.5. – B). Deje los espacios en blanco para que sean listados todos los trámites. Estando listados los trámites como resultado de la búsqueda, seleccione en el trámite prerrequisito en la columna de la izquierda (fig. 4.3.1.5. – C) y luego oprima el botón Adicionar (fig. 4.3.1.5. – D). El trámite seleccionado será listado en la casilla de la



derecha (fig. 4.3.1.5. – E). Repita el procedimiento anterior si desea adicionar más trámites. Haga clic en el icono para ver la definición de cada trámite. Si desea eliminar alguno de los trámites elegidos, selecciónelo en la casilla derecha y oprima el botón Eliminar. Oprima el botón Siguiente para continuar con el siguiente paso. Nota: Si no se selecciona ningún trámite prerrequisito siga al paso 11. Paso para Servicios: Paso seguido se determina la información del servicio como la definición si se debe ejecutar en un período determinado para lo cual hace uso de los calendarios que aparecen al momento de seleccionar dicha opción, definición del mecanismo de respuesta al usuario (Inmediata / No Inmediata) y si el servicio requiere el envío de documentos, para lo cual el formulario contará con una herramienta de búsqueda dentro del disco duro del usuario y posterior carga del archivo seleccionado. Oprima el botón Siguiente para continuar el proceso.



(fig. 4.3.1.5. Creación de trámites / Gestionar Trámites Prerrequisito)

8. Paso para Trámites: A continuación se lleva a cabo las Asociaciones Datos Relevantes para cada trámite que sea necesario dentro de la selección del paso anterior. Seleccione el nombre en la casilla izquierda (fig. 4.3.1.6. – A) y luego oprima el botón Configurar (fig. 4.3.1.6. – B).



(fig. 4.3.1.6. Creación de trámites / Asociaciones Datos Relevantes)

9. Paso para Trámites: El siguiente paso corresponde a asociar campos entre la casilla izquierda que representa el esquema GEL-XML del formulario de salida del trámite prerrequisito (fig. 4.3.1.7. – A) y los que conforman el formulario del trámite que se está generando, ubicado a la derecha de la pantalla (fig. 4.3.1.7. – B). Para llevar a cabo este procedimiento, haga clic al campo que desea asociar en la izquierda (fig. 4.3.1.7. – C) y después debe hacer lo mismo en la casilla derecha (4.3.1.7. – D). Una vez seleccionados los dos campos que deben ser asociados, haga clic en Asociar (4.3.1.7. – E). Si desea reversar el procedimiento seleccione los dos campos y oprima Desasociar. Las asociaciones generadas serán listadas en la casilla inferior (fig. 4.3.1.7. – F). Terminado el procedimiento oprima le botón Grabar Asociaciones para volver al formulario. Oprima el botón Siguiente para continuar con el próximo paso.



(fig. 4.3.1.7. Creación de trámites / Asociación de Campos)

10. Paso para Trámites: Paso seguido, se establecen las condiciones de acuerdo a cada rol asignado en el paso 4. Seleccione el rol determinado y haga clic sobre el icono para editar los condicionales. Aparece una pantalla donde se listan todos los campos que conforman el formulario del trámite y junto a cada uno de ellos las posibilidades de condición, el valor de dicha condición y su correspondiente operador:

Condiciones

< | Mayor que > | Menor que

<= | Mayor o igual que >= | Menor o igual que

¡= | Diferente = | Igual

Operador

AND | y OR | o



Por ejemplo, si necesita que el campo Mayor de Edad obedezca siempre a una respuesta afirmativa, en el listado de campos a los que puede ser aplicadas las condiciones seleccione la opción = (igual) en la columna Condición (fig. 4.3.1.8. – A) y en el campo correspondiente a la columna Valor (fig. 4.3.1.8. – B) asigne el criterio correspondiente a la única respuesta para ser válido el proceso del trámite (en este caso SI). Si la condición además depende de la respuesta dada en otro campo, porque adicionalmente se cumpla asigne la opción AND en la columna Operador (fig. 4.3.1.8. – C). Si la respuesta está entre la primera condición mencionada o un valor asignado en otro campo, seleccione la opción (OR) al final de la primera condición. Las condiciones serán regidas en orden lineal y por defecto, si no es señalado ningún operador, el sistema asume AND. Pueden asignarse cuantas condiciones aplique pero teniendo en cuenta que no serán agrupables sino de ejecución lineal.

(fig. 4.3.1.8. Creación de trámites / Editor de condiciones)

Habiendo estimado las condiciones oprimir le botón Guardar o Cancelar para descartar el procedimiento. Oprimir el botón Siguiente para continuar con el proceso. 11. Paso para Trámites: Paso seguido se determina la información del trámite como la definición si el trámite se debe ejecutar en un período determinado (de acuerdo a



lo determinado por la norma que rige el trámite) para lo cual hace uso de los calendarios que aparecen al momento de seleccionar dicha opción, definición del mecanismo de respuesta al usuario (Inmediata / No Inmediata) y si el trámite requiere el envío de documentos, para lo cual el formulario contará con una herramienta de búsqueda dentro del disco duro del usuario y posterior carga del archivo seleccionado. Oprima el botón Siguiente para continuar al paso siguiente. 12. El último paso define el diseño del formulario de entrada y salida. Si el servicio/tramite que se publica está enfocado exclusivamente a sistemas de información, este paso no aplica. Desde la casilla izquierda, correspondiente al esquema de entrada del trámite/servicio (fig. 4.3.1.9. – A), tome los campos que complementarían la información del formulario resumido en la casilla derecha correspondiente al diseño del formato de salida (fig. 4.3.1.9. – B). Para llevar a cabo este procedimiento, seleccione el campo en la casilla izquierda (fig. 4.3.1.9. – C) y haciendo uso de la barra de herramientas ubicado en la mitad de la pantalla (fig. 4.3.1.9. – D) realice la inclusión del parámetro. En dicha barra también cuenta con herramientas para subir o bajar campos dentro del diseño del formulario (fig. 4.3.1.9. – E), como también para agregar subtítulos y nuevas tablas (fig. 4.3.1.9. – F). Oprima el botón Vista Previa para visualizar el diseño final del formulario (fig. 4.3.1.9. – G). Seleccionando cada campo en la casilla derecha aparecerán sus correspondientes casillas de configuración en la parte inferior de la pantalla (fig. 4.3.1.9. – H). Las definiciones de cada campo de configuración son:

� Nombre: Término con el que es llamado el campo.

� Comentario: Descripción opcional que se desee asignar al campo.

� Tool Tip de Error: Es el mensaje que aparece como texto alternativo sobre el icono de error, con el fin de señalar al usuario el motivo por le cual no es aceptada la información sugerida en el campo.

� Elemento en el esquema: La manera como es llamado el elemento desde el

GEL-XML.

� Oculto: Si se desea mantener oculto el elemento en el formulario.



� Expresión regular: Cuando el campo debe ser reconocido bajo un parámetro específico sin restricción alguna.

� Textbox Multilínea: Asignar esta opción cuando la casilla pueda contener

información que necesite suficiente espacio para ser escrita.

� Campo Calculado: Cuando el contenido del campo es el resultado de una operación realizada entre los datos de otros campos contenidos dentro del mismo formulario. Oprima el botón Editar para acceder a la ventada de configuración de dicha opción donde podrá seleccionar los campos y la correspondiente operación.

� Asociar credenciales del registro: Oprimiendo el botón editar aparecerá una

pantalla donde podrá asociar el campo bajo ciertas variables en relación a un resultado determinado.

� Tipo de Dato: Categoría del campo asignado desde el esquema GEL-XML.

� Longitud Mínima: Si el contenido del campo debe contener un número mínimo

de caracteres.

� Valores: Enumeración asignada en el caso que el campo contenga varias opciones de respuesta. Este parámetro ya viene contenido en el esquema y por lo tanto no es editable.

� Longitud Máxima: Si el contenido del campo debe contener un número máximo

de caracteres.

� Activado por: Si el campo debe ser activado dependiendo de la información incorporada en otro campo del formulario. Oprimir el botón Adicionar Regla de Activación para acceder a la ventana que lista las posibilidades de configuración.



(fig. 4.3.1.9. Creación de trámites / Formulario de Entrada y Salida)

Oprimir el botón Actualizar para llevar a cabo los cambios realizados en los nombrados campos de configuración.



Una vez finalizada la configuración del formulario oprima el botón Siguiente para llevar a cabo todo el procedimiento anterior pero para el formulario de salida. Una vez hecho la configuración necesaria, oprima el botón Siguiente para poder visualizar dicho formulario. Posteriormente el botón Crear Trámite o Crear Servicio.

8.2.2. Adición Trámite Una vez creado el trámite/servicio, se adiciona para comenzar su proceso de pruebas y posterior publicación. Para este caso, terminado el proceso del punto anterior, le es asignado el estado “Activo en pruebas” y aparecerá listado haciendo clic en el vínculo Trámites ubicado en el menú a la izquierda de su monitor (fig. 4.3.2.1. ); en dicha pantalla podrá llevar a cabo la búsqueda de los trámites/servicios generados dentro de la entidad (fig. 4.3.2.1. – A). Adicionalmente se consulta su estado y tiene acceso a las respectivas operaciones (fig. 4.3.2.1. – B), como Ver Definición del trámite/servicio , Consultar el árbol de trámites prerrequisito , Modificación , Solicitud de

Creación , Solicitar Modificación , Solicitud de Eliminación , Inactivar , Configuración de webService por defecto , y Eliminación .



(fig. 4.3.2.1. Adición de trámites / Listado de trámites/servicios) Paso 1. Para llevar a cabo la solicitud, oprima el ícono en el listado anteriormente mencionado, a lo cual aparecerá una ventana (fig. 4.3.2.2. ) que registra y envía la solicitud que será recibida por el administrador de pruebas. En dicha ventana debe digitar el texto con el que solicita la creación (fig. 4.3.2.2. – A) y debe adjuntar el instructivo que señalará al administrador de pruebas las características principales del webService correspondiente a Dummy (fig. 4.3.2.2. – B) y a Pruebas (fig. 4.3.2.2. – C), usados en la generación del trámite/servicio. Dichos documentos, los cuales pueden ser manejados en cualquier formato de texto (txt, doc, etc.), son cargados oprimiendo el botón Browse o Seleccionar (dependiendo del idioma de su sistema operativo) y posteriormente ubicándolos dentro de su disco duro. Una vez ingresados esos datos, oprimir el botón Enviar Solicitud. Le será asignado un número para llevar a cabo el seguimiento de aprobación y posterior adición.

(fig. 4.3.2.2. Adición de trámites / Solicitud Adición de trámites/servicios)

Paso 2. Una vez la solicitud llega al administrador de pruebas, este inicia la correspondiente evaluación. De acuerdo a los resultados, dicho perfil puede: A) Preaprobar el trámite/servicio para que así el administrador PDI lleve a cabo la aprobación final. B) Reportar Errores en el caso que los encuentre, los cuales serán relacionados en la bitácora asociada a la solicitud, la cual puede ser consultada haciendo clic en el número asignado por el sistema cuando fue efectuada la solicitud.



Paralelamente, dentro de sus funciones puede: C) Adicionar comentarios en la mencionada bitácora. D) Reasignar responsables a la evaluación del trámite/servicio. Siendo Preaprobada la solicitud, el administrador PDI puede: A) Aprobar la solicitud para que finalmente el administrador de la entidad se encargue de la publicación quien a ese punto ya está en disposición de hacerlo o cancelar el proceso. B) Rechazar la solicitud, agregando los respectivos comentarios a la bitácora.

Paso 3. Estando aprobada la creación del trámite/servicio, éste aparecerá en el listado de la sección Solicitudes (fig. 4.3.2.3.), donde estarán listadas todas las solicitudes en curso (fig. 4.3.2.3. – A ) bajo parámetros como Nombre trámite/servicio, Vida Solicitud (Abierta si tiene pasos pendientes o Cerrada si es el último paso por definir), Estado de la solicitud (Solicitar Modificación de Trámite, Aprobar Autorización, Solicitar Aprobación Modificación de Trámite, Iniciar Pruebas, Adicionar Comentarios, Reasignar, Reportar Errores, Reenviar Solicitud, Pre-Aprobar, Aprobar, Rechazar, Solicitar Eliminar Trámite, Rechazar Autorización Eliminación, Aprobar Autorización Eliminación, Eliminar Trámite, Publicar, Cancelar) , Tipo Solicitud (Adición, Autorización de Modificación/Eliminación, Modificación, Eliminación), Fecha de solicitud y Fecha de última operación. Haga clic en el ícono (fig. 4.3.2.3. – B) para llevar a cabo su publicación en el ambiente de producción.



(fig. 4.3.2.3. Adición de trámites / Listado de Solicitudes de trámites/servicios)

8.3. Gestión de trámites o servicios.

Una vez una entidad ha publicado un Trámite/Servicio en la PDI, puede ejercer labores de gestión sobre este, los siguientes son los pasos de cada una de estas labores:

8.3.1. Modificación del trámite o servicio.

Cuando el trámite/servicio está activo y la entidad considera que debe ser corregido, procede a solicitar al administrador PDI la correspondiente modificación, por medio de las opciones de administración con que dispone el administrador de la entidad.



Figura 14a. Secuencia de modificación de un trámite o servicio en la PDI.

Paso 1. En el caso de ser necesaria una modificación dentro de un trámite/servicio, se lleva a cabo la solicitud al Administrador PDI, en el listado de trámites, oprimiendo el ícono .

En ese momento se desplegará una ventana emergente la cual contiene un formulario (fig. 4.3.3.1.) que busca reunir la información necesaria para que el Administrador PDI entienda los cambios que se desean realizar. Señale los campos que van a ser



modificados (fig. 4.3.3.1. A), ingrese el comentario correspondiente dirigido al Administrador PDI (fig. 4.3.3.1. – B) y asigne los documentos de instructivo que señalan las características principales del Web Service correspondiente a Dummy (fig. 4.3.3.1. – C) y a Pruebas (fig. 4.3.3.1. – D), usados en la generación del trámite/servicio. Una vez ingresados esos datos, oprimir el botón Enviar Solicitud. Le será asignado un número para llevar a cabo el seguimiento de aprobación y posterior adición.

(fig. 4.3.3.1. Modificación de trámites / Formulario de Solicitud)

Paso 2. Una vez aprobada la solicitud por parte del Administrador PDI, el trámite aparecerá listado en la opción Solicitudes. Para proceder con la modificación, haga clic en el ícono .



El proceso de modificación será el mismo que llevó a cabo la generación del trámite, con la diferencia que el sistema carga los datos ya ingresados para ser cambiados de acuerdo a las necesidades. Habiendo efectuado los cambios, haga clic en el ícono para reportar los cambios al administrador de pruebas. A partir de este momento, el proceso es el mismo que el llevado a cabo en la solicitud de creación del trámite/servicio, desde el punto en que el administrador de pruebas lo comienza a evaluar.

Paso 3. Estando aprobada la modificación del trámite/servicio, en el listado de la sección Solicitudes, haga clic en el ícono para llevar a cabo su publicación en el ambiente de producción.

8.3.2. Eliminación del trámite o servicio.



Figura 15b. Secuencia de eliminación de un trámite o servicio en la PDI.



Paso 1. Cuando la entidad desea eliminar un trámite/servicio, debe hacer la solicitud al Administrador PDI, quien la rechaza o aprueba. Para llevar a cabo el proceso, seleccione la opción Trámites y habiendo identificado el trámite/servicio que desea eliminar haga clic sobre su correspondiente ícono . En ese momento aparecerá una ventana emergente donde puede seleccionar la fecha de eliminación del trámite/servicio (fig. 4.3.4.1. – A) y el correspondiente comentario (fig. 4.3.4.1. – B). El administrador PDI será el encargado de aprobar o rechazar. Una vez ingresados esos datos, oprimir el botón Enviar Solicitud. Le será asignado un número para llevar a cabo el seguimiento de aprobación y posterior adición.

(fig. 4.3.4.1. Eliminación de trámites / Formulario de Solicitud)

Paso 2. Una vez aprobada la solicitud, es el administrador de la entidad quien procede a eliminarlo desde el listado generado en la sección Solicitudes mediante clic al ícono .



8.3.3. Consultas

8.3.3.1. Consulta de Trámites Ofrecidos.

Una vez generados los trámites y/o servicios, puede llevar a cabo la consulta de los mismos y llevar a cabo su respectivo seguimiento. A continuación la descripción de los pasos para realizar la consulta: 1. Seleccionar la opción Trámites Ofrecidos en el menú ubicado a la izquierda de la pantalla. Dentro de esta sección podrá consultar los trámites que a la fecha están registrados como ofrecidos por la entidad a los ciudadanos. 2. Encontrará dos fragmentos, el superior (fig. 4.3.5.1. – A) donde podrá realizar la búsqueda bajo los criterios de Fecha de Solicitud (fig. 4.3.5.1. – B), Estado (fig. 4.3.5.1. – C) o Nombre del Trámite (fig. 4.3.5.1. – D). Para la primera opción, haga clic sobre cada icono tanto en la casilla Desde como en la casilla Hasta para determinar la fecha de publicación del trámite o servicio. Si la búsqueda consiste en el estado del trámite, puede seleccionar bajo los criterios Con respuesta, Con error, Rechazado, Esperando Entidad, Esperando prerrequisitos, Listo para ejecutar, Con error ejecución, Preparando ejecución los cuales son definidos en el punto de modificación de trámites. También puede llevar a cabo la búsqueda por el nombre del trámite. Deje todos los espacios en blanco si desea buscar bajo todos los parámetros. Oprima el botón Buscar para ejecutar la búsqueda.

3. En la tabla inferior aparecerán los resultados de la búsqueda (fig. 4.3.5.1. – E) los cuales podrán ser ordenados por el criterio que encabeza cada columna. Podrá ver la respuesta a cada trámite haciendo clic en el icono . Para consultar todos los registros haga uso del sistema de paginación ubicado en la parte inferior central de la tabla (fig. 4.3.5.1. – F).



(fig. 4.3.5.1. Trámites Ofrecidos / Consulta)

8.3.3.2. Consulta de Trámites Consumidos. Dentro de los trámites y/o servicios generados y que han sido consumidos por Usuarios Delegados de la Entidad (Persona delegada por una entidad o empresa para ejecutar y consultar trámites en nombre de la entidad o empresa), se encuentra esta categoría la cual puede ser consultada siguiendo los pasos que se describen a continuación. 1. Seleccionar la opción Trámites Consumidos en el menú ubicado a la izquierda de la pantalla. Dentro de esta sección podrá consultar los trámites que a la fecha están registrados como ofrecidos por la entidad a los usuarios delegados.



2. Encontrará dos fragmentos, el superior (fig. 4.3.6.1. – A) donde podrá realizar la búsqueda bajo los criterios de Nombre del Trámite (fig. 4.3.6.1. – B), Nombre del Usuario Delegado (fig. 4.3.6.1. – C), Estado (fig. 4.3. 6.1. – D), Fecha de Solicitud (fig. 4.3.6.1. – E) o Fecha de Entrega (fig. 4.3. 6.1. – F). Al igual que el punto anterior, haga clic sobre cada icono tanto en la casilla Desde como en la casilla Hasta en cualquiera de los dos parámetros (fecha solicitud y fecha entrega) para determinar el criterio de búsqueda por tiempo. Si la búsqueda consiste en el estado del trámite, puede seleccionar bajo los criterios Con respuesta, Con error, Rechazado, Esperando Entidad, Esperando prerrequisitos, Listo para ejecutar, Con error ejecución, Preparando ejecución. Deje todos los espacios en blanco si desea buscar bajo todos los parámetros. Oprima el botón Buscar para ejecutar la búsqueda. 3. En la tabla inferior aparecerán los resultados de la búsqueda (fig. 4.3.6.1- G) los cuales podrán ser ordenados por el criterio que encabeza cada columna. Para consultar todos los registros haga uso del sistema de paginación ubicado en la parte inferior central de la tabla.



(fig. 4.3.6.1. Trámites Consumidos / Consulta)

8.3.4. Reportes. La PDI cuenta con un módulo de reportes, con el cual se puede hacer seguimiento de diferentes parámetros de comportamiento de cara al usuario final y al rendimiento



mismo de la Plataforma. Esto con el fin que el administrador, tanto de las entidades como de la plataforma en sí, puedan llevar a cabo el respectivo control. Entre los reportes ofrecidos a entidades se encuentran:

o Reporte de tiempos de respuesta a usuarios de trámites. o Reporte de tiempos de respuesta de llamados de Web Services. o Reporte de trámites y servicios consumidos por la entidad. o Reporte estadístico de comportamiento. o Reporte utilización del sistema.

8.3.4.1. Reporte de tiempos de respuesta a usuarios de trámites.

Para llevar a cabo la búsqueda de un reporte específico, una vez ingresado a dicha sección (fig. 4.3.7.1.), seleccione cualquiera de los diferentes campos (fig. 4.3.7.1. –A): Naturaleza del trámite, nombre, descripción, tipo de usuario, formato y/o rango de fechas del reporte. Deje los espacios en blanco para ver el listado completo de reportes disponibles. Oprima el botón buscar (fig. 4.3.7.1. –B) para llevar a cabo el proceso. Siendo listados los reportes disponibles de acuerdo a los parámetros de búsqueda asignados (fig. 4.3.7.1. –C) , seleccione el que le interese ver en detalle haciendo clic sobre el checkbox ubicado en la columna derecha de la tabla (fig. 4.3.7.1. –D) y posteriormente en el botón Ver Reporte (fig. 4.3.7.1. –E) ubicado en la parte media de la pantalla.



(fig. 4.3.7.1. Reporte Tiempos de Respuesta a usuarios – Búsqueda)

La pantalla siguiente encontrará los resultados al(los) reporte(s) seleccionados (fig. 4.3.7.2.). En primera instancia contará en la parte superior con una barra de herramientas la cual le permitirá navegar entre páginas del reporte (fig. 4.3.7.2. – A), asignar el ancho de la página (fig. 4.3.7.2. – B), casilla de búsqueda por palabra clave (fig. 4.3.7.2. – C) y módulo de exportación en diferentes formatos (fig. 4.3.7.2. – D). También cuenta con un botón para imprimir el reporte (fig. 4.3.7.2. – E). En cuanto al detalle del reporte contará con seis (6) columnas principales a saber: Entidad, Tipo, Trámite, Prerrequisito, Vista Plataforma y Vista Ciudadano. Las cuatro primeras describen los datos básicos del trámite/servicio consultado. La columna Vista Plataforma (fig. 4.3.7.2. – F) se compone a su vez de tres (3)



columnas adicionales que son Duración promedio de ejecución del trámite, Tiempo mínimo de ejecución y Tiempo máximo de ejecución (medidos en segundos respecto al comportamiento de la plataforma). La columna Vista Ciudadano (fig. 4.3.7.2. – G) cuenta con los mismos parámetros con la diferencia que son medidos respecto al usuario. Al final se encontrarán totalizados los resultados por cada columna.

(fig. 4.3.7.2. Reporte Tiempos de Respuesta a usuarios – Resultados)

8.3.4.2. Reporte de tiempos de respuesta de llamados de Web Services.

Respecto a la búsqueda de un reporte específico correspondiente a llamados de adaptadores, debe seleccionar cualquiera de los diferentes campos (fig. 4.3.7.3. – A): Naturaleza del trámite, nombre, descripción, agrupado por, formato de promedio y/o rango de fechas del reporte. Deje los espacios en blanco para ver el listado completo de reportes disponibles. Oprima el botón buscar (fig. 4.3.7.3. – B) para llevar a cabo el proceso.



Una vez listados los reportes disponibles correspondientes a los parámetros de búsqueda seleccionados (fig. 4.3.7.3. – C), escoja el que desee ver en detalle haciendo clic sobre el checkbox ubicado en la columna derecha de la tabla (fig. 4.3.7.3. – D) y posteriormente en el botón Ver Reporte (fig. 4.3.7.3. – E) ubicado en la parte media de la pantalla.

(fig. 4.3.7.3. Reporte Tiempos de Respuesta llamados a Web Services – Búsqueda)

En la siguiente pantalla encontrará los resultados al(los) reporte(s) seleccionados (fig. 4.3.7.4.). En primera instancia contará en la parte superior con una barra de herramientas similar a la dispuesta en el reporte anteriormente descrito (fig. 4.3.7.4. – A), donde adicionalmente contará con un segmento inicial (fig. 4.3.7.4.- B) el cual señala el período de tiempo seleccionado en los parámetros de búsqueda, junto con la descripción de del año con más ejecuciones exitosas y año con más ejecuciones fallidas.



Una tabla más abajo (fig. 4.3.7.4.- C) encontrará los parámetros de descripción del trámite tales como Año, Mes, Semana/Día, Entidad, Trámite, Código, Versión y las columnas Método Ejecución y Método Consulta, las cuales a su vez se dividen en Ejecuciones Exitosas, Ejecuciones Fallidas y Tiempo Promedio de Respuesta en segundos tanto para el primer como para el segundo concepto. Estos parámetros describen los datos referentes al promedio, al máximo y al mínimo de ejecuciones. Posteriormente encontrará las gráficas que sustentan los datos anteriormente suministrados (fig. 4.3.7.4.- D).

(fig. 4.3.7.4. Reporte Tiempos de Respuesta llamados a Web Services – Resultados)



8.3.4.3. Reporte de trámites y servicios consumidos por la entidad Para esta opción, el administrador de la entidad cuenta con los parámetros de búsqueda de reportes Agrupado por (fig. 4.3.7.5. – A), Rango de fechas del reporte (fig. 4.3.7.5. – B) y la opción Comparar (fig. 4.3.7.5. – C) para ser habilitada en el caso que se desee ejecutar dicho proceso entre varios reportes. Una vez asignados los parámetros haga clic en el botón Ver Reporte (fig. 4.3.7.5. – D). Deje los espacios en blanco para ver todos los resultados disponibles.

(fig. 4.3.7.5. Reporte Trámites / Servicios consumidos por la entidad – Búsqueda)

Una vez listado el resultado de la búsqueda, y haciendo uso de la herramienta de manejo de reportes (fig. 4.3.7.6. – A) ya descrita en el primer caso, accede a los datos establecidos bajo parámetros como promedio y total (fig. 4.3.7.6. – B), sumado al listado de los 10 trámites consumidos por la entidad, los cuales serán listados bajo los criterios de Periodo, Trámite, Código, Versión, Número de Ejecuciones y Número de Consultas (fig. 4.3.7.6. – C).



(fig. 4.3.7.6. Reporte Trámites / Servicios consumidos por la entidad – Resultados)

8.3.4.4. Reporte estadístico de comportamiento.

En cuanto a la búsqueda de un reporte estadístico de comportamiento, seleccione cualquiera de los diferentes campos (fig. 4.3.7.7. – A): Naturaleza del trámite, nombre, descripción, tipo de usuario, agrupado por y/o rango de fechas del reporte. Adicionalmente cuenta con la opción comparar (fig. 4.3.7.7. – B) para ser habilitada en el caso que se desee ejecutar dicho proceso entre varios reportes. Deje los espacios en blanco para ver el listado completo de reportes disponibles. Oprima el botón buscar (fig. 4.3.7.7. – C) para llevar a cabo el proceso. Estando listados los reportes disponibles de acuerdo a los parámetros de búsqueda asignados (fig. 4.3.7.7. – D), seleccione el que le interese ver en detalle haciendo clic sobre el checkbox ubicado en la columna derecha de la tabla (fig. 4.3.7.7. – E) y posteriormente en el botón Ver Reporte (fig. 4.3.7.7. – F) ubicado en la parte media de la pantalla.



(fig. 4.3.7.7. Reporte Estadístico de Comportamiento – Búsqueda)

La pantalla siguiente encontrará los resultados al(los) reporte(s) seleccionados (fig. 4.3.7.8.). Nuevamente podrá hacer uso de la barra de herramientas ubicada en la parte superior de la pantalla (fig. 4.3.7.8. – A). Adicionalmente encontrará una primera tabla la columna fecha en la cual estará relacionado el nombre de la entidad, el año al que corresponde el reporte, el mes y los días en curso. Por cada uno de ellos estarán relacionados el número de ejecuciones y consultas realizadas (fig. 4.3.7.8. – B). En la parte inferior del reporte se encontrarán las correspondientes gráficas que sustentan los datos suministrados anteriormente (fig. 4.3.7.8. – C).



(fig. 4.3.7.8. Reporte Estadístico de Comportamiento – Resultados)

8.3.4.5. Reporte Utilización del sistema.

Referente a la búsqueda de un reporte orientado a la utilización del sistema debe seleccionar cualquiera de los diferentes campos (fig. 4.3.7.9. – A): Naturaleza del trámite, nombre, descripción, tipo usuario, formato y/o rango de fechas del reporte. Deje los espacios en blanco para ver el listado completo de reportes disponibles. Oprima el botón buscar (fig. 4.3.7.9. – B) para llevar a cabo el proceso. Siendo listados los reportes disponibles correspondientes a los parámetros de búsqueda asignados anteriormente (fig. 4.3.7.9. – C), escoja el que desee ver en detalle haciendo clic sobre el checkbox ubicado en la columna derecha de la tabla (fig. 4.3.7.9. – D) y posteriormente en el botón Ver Reporte (fig. 4.3.7.9. – E) ubicado en la parte media de la pantalla.



(fig. 4.3.7.9. Reporte Estadístico Utilización del Sistema – Búsqueda)

En la siguiente pantalla encontrará los resultados al(los) reporte(s) seleccionados (fig. 4.3.7.10.). Como ya ha sido nombrado en los reportes anteriores, contará en la parte superior con la barra de herramientas para navegación del mismo (fig. 4.3.7.10. – A), donde también contará con un segmento (fig. 4.3.7.10. – B) el cual señala el nombre de la entidad, el tipo de ejecución (trámite ó servicio) y posteriormente los campos de seguimiento de rendimiento como Numero de Accesos, Número de Consultas, Número de Solicitudes Fallidas, Número de Solicitudes Exitosas, Número de Fallas, Duración promedio de ejecución, Tiempo mínimo de ejecución y tiempo máximo de ejecución. Para cada una de estas filas corresponde cada trámite o servicio registrado a la entidad con sus correspondientes valores y su respectivo gran total (fig. 4.3.7.10. – C).



(fig. 4.3.7.10. Reporte Estadístico Utilización del Sistema – Resultados)



9. UTILIZACIÓN DE LOS TRÁMITES Y SERVICIOS EXPUESTOS EN LA PLATAFORMA DE INTEROPERABILIDAD

9.1. Sistemas de Información

Además de interactuar con humanos (Ciudadanos, Usuarios Delegados, etc.), la PDI también puede responder a solicitudes de ejecución de Trámites o Servicios desde Sistemas de Información en Entidades Públicas o Privadas previamente registradas. El siguiente gráfico muestra este modo de operación unificado:

Figura 16. Sistema de Información utilizando la PDI.

Una de las ventajas más importantes de este modelo unificado es que los Sistemas de Información pueden aprovechar la infraestructura de hardware y software que ya existe para atender las ejecuciones de trámites o servicios hechas por humanos, además que puede hacer uso de muchos de los trámites o servicios ya modelados. En términos generales un trámite o servicio puede llegar a ser modelado para ser utilizado de igual manera por un humano y por un Sistema de Información. Sin embargo, existen algunas restricciones sobre el tipo de trámites o servicios que pueden ser ejecutados:

o Estos no pueden tener prerrequisitos o Estos no pueden requerir pagos (esto solo debido a que el actual Proveedor de

Servicios de Pagos en el país – PSE – no fue diseñado para ser utilizado por sistemas de información).

Gracias a este modelo, la PDI brinda una interfaz común de llamados, que abstrae todos los detalles funcionales y tecnológicos de los Trámites y Servicios a sus consumidores (los Sistemas de información en este caso). La naturaleza (y plataforma tecnológica) de estos sistemas de información es muy variada, debido a esto, la funcionalidad de ejecución de Trámites o Servicios se expone a



través de una Capa de Servicios Web. Esta capa expone una interfaz de llamado común, independiente del trámite o servicios que se desee ejecutar, o de su versión. Lo anterior, facilita la utilización de esta interfaz y evita cambios en el sistema de información debido a nuevas versiones de los trámites o servicios utilizados. Además de habilitar el acceso a esta interfaz a través de estándares independientes de tecnología como SOAP, también se encuentra asegurada utilizando otro estándar como lo es WS-Security. La escogencia de este estándar garantiza la autenticación, confidencialidad, e integridad de los mensajes SOAP que se intercambien entre el Sistema de Información y la PDI.

Importante: dependiendo de su modalidad de llamado, la ejecución de trámites o servicios puede realizarse de manera Inmediata (sincrónica) o No-Inmediata (asincrónica). Dependiendo de esto, el Sistema de Información debe llamar al método de ejecución correspondiente en la Capa de Servicios Web.

La siguiente información debe permitir a un Administrador de Entidad o Empresa conectar sus Sistemas de Información a la PDI, y ejecutar trámites o servicios.

9.1.1. Pasos Previos y Prerrequisitos para conectar Sistemas de Información que invocan tramites/servicios publicados en la PDI

Para que una Entidad o Empresa pueda conectar alguno de sus sistemas de información a la PDI debe cumplir los siguientes pasos y prerrequisitos: 1. Tener credencial de Administrador de Entidad o Empresa: A través de la PDI el

Administrador de Entidad o Empresa crea una cuenta de acceso al Sistema de Información, de la misma forma como puede crear una cuenta para un Usuario Delegado, con la diferencia que aquí lo esta haciendo para una aplicación. Este proceso es detallado en el punto 3 “Registro en la Plataforma de Interoperabilidad”.

2. Conocer el nombre del trámite o servicio que se quiere ejecutar, incluyendo su número de versión. Este proceso es detallado en el punto 3 “Registro en la Plataforma de Interoperabilidad”.

3. Validar a través de la PDI que la nueva cuenta de acceso al Sistema de Información tenga acceso al trámite o servicio deseado. Cada trámite o servicio orientado a Sistemas de Información puede tener una Lista de Control de Accesos que restringe de que Sistemas de Información puede recibir llamados de ejecución. La entidad que requiere hacer uso del servicio debe comunicarse con la entidad que lo provee para ser autorizado.



4. Tener acceso a los esquemas GEL-XML (XSD) de Entrada y Salida (URLs donde se encuentran publicados estos), que describen la estructura de la información de entrada y salida del tramite o servicio a ejecutar. Estos van a describir la estructura de la información XML que espera y va a devolver la versión del trámite o servicio. El acceso al esquema también lo entrega la entidad responsable de exponer el servicio.

5. Tener acceso a la descripción WSDL de Capa de Servicios Web de la PDI. Esta descripción puede ser encontrada en las siguientes URLs dependiendo del ambiente en el que se desee invocar:

Ambiente URL Preproducción http://200.21.208.237/WebServicePDI/WebServicePDI.asmx?WSDL Producción http://200.21.208.237:8077/WebServicePDI/WebServicePDI.asmx?WSDL

Con base en esta descripción, y dependiendo de la herramienta de desarrollo que se utilice, se puede crear un Proxy en el Sistema de Información que representa localmente la interfaz del servicio. El código del Sistema de Información puede entonces llamar al Web Service a través de este Proxy local. Este Proxy debe estar dirigido a las siguientes URLs dependiendo del ambiente en el que se desee invocar:

Ambiente URL Preproducción http://200.21.208.237/WebServicePDI/WebServicePDI.asmx Producción http://200.21.208.237:8077/WebServicePDI/WebServicePDI.asmx

6. Tal como se mencionó, el mecanismo de seguridad de los llamados (Autenticación

en ambos sentidos, Encripción y Firmado Digital) entre el Sistema de Información y la Interfaz de Servicios Web utiliza el estándar WS-Security. Este mecanismo de la forma como se configuró en la PDI utiliza Certificados Digitales X.509 de servidor en ambos extremos. Sabiendo esto, es necesario obtener y configurar en el servidor del Sistema de Información la llave pública del Certificado de la PDI (en Microsoft Windows se almacena como un archivo con terminación .CER) y obtener un Certificado Digital de Servidor (http://www.certicamara.com.co). Una vez la Entidad o Empresa obtenga este certificado debe hacer llegar la llave pública de este al Administrador de la PDI.

7. Cumplir con los requerimientos adicionales de seguridad a nivel de comunicaciones (protocolo) establecidos (por ejemplo: VPNs, SSL, etc.)

8. Una vez desarrollados estos pasos se procede a realizar los cambios necesarios en el código del Sistema de Información para conectarse a la Interfaz de Servicios Web de la PDI. La naturaleza de estos cambios y el esfuerzo que implica dependen



mucho de la plataforma tecnológica y ambiente de programación del Sistema de Información. La sección llamada “Conexión a la Interfaz de Servicios Web de la PDI” brinda la información que puede requerir cualquier conexión a la Interfaz de Servicios Web de la PDI independiente de la tecnología con que esté desarrollado el Sistema de Información. Verifique que el ambiente de programación de la conexión al menos soporte los siguientes estándares: XML Schema, Versión 1.1 SOAP, Versión 1.1/1.2 WSDL, Versión 1.1 WS-Security 1.0/1.1 MTOM Con el cumplimiento de los anteriores estándares y versiones, se dice que el Web Service cumple con la especificación Basic Profile 1.0 de WS-I

9.1.2. Conexión a la Interfase de Servicios Web de la PDI

Una vez se tiene acceso al WSDL que contiene la descripción XML de la interfaz del Web Service, se puede conocer la estructura de los mensajes SOAP que reciben y responden cada uno de los métodos expuestos por el Web Service.

Importante: un Sistema de Información puede ejecutar trámites o servicios tanto en el ambiente de preproducción como de producción. Las descripciones de ambos son idénticas, simplemente cambian sus URLs.

La siguiente tabla muestra los métodos expuestos por el Web Service:

Método Descripción

Ejecutar Permite ejecutar un trámite de manera Inmediata (Sincrónica)

EjecutarAsync Permite ejecutar un trámite de manera No-Inmediata (Asincrónica). Después de llamar este método, se puede consultar periódicamente (polling) el resultado de la ejecución del trámite o servicio a través del método ConsultarResultado.

ConsultarResultado Permite consultar el resultado de la ejecución No-Inmediata de un trámite o servicio con ayuda de un Tiquete y un Número de Rastreo.

Importante: la información de entrada o salida de un trámite o servicio también puede incluir un archivo adjunto (de ser necesario, mas de uno puede ser agrupado dentro de un .ZIP). Este archivo se puede serializar en un parámetro especial del método de ejecución tal como se observa a continuación. La Capa de Servicios Web



soporta el estándar MTOM que optimiza la serialización y transmisión de estos archivos en llamados SOAP. Verifique que su implementación tiene soporte a este estándar. Algunos aspectos adicionales en el tema de archivos adjuntos a tener en cuenta: • El tamaño máximo de los archivos adjuntos de entrada es de 3 MB (configurable

en la PDI). • Los archivos adjuntos de entrada y salida son sujetos a un proceso de revisión por

virus durante su paso por la PDI.

La descripción de cada método se incluye a continuación: Ejecutar


Ejecutar Entrada Estructura XML que contiene la información de entrada de la ejecución. Su estructura se describe a continuación:

• codigoTramite (entero): identifica universalmente el trámite o servicio a ejecutar.

• versionTramite (flotante): identifica la versión del trámite o servicio.

• xmlEntradaEjecucion (XML): Documento XML, representa la información de entrada del trámite o servicio. Cumple con el esquema GEL-XML de entrada del trámite o servicio.

• Documento: estructura XML con la información del archivo adjunto de entrada. Contiene:

o nombreArchivo (string): nombre del archivo.

o Archivo (base64Binary): archivo serializado base64 utilizando MTOM.

EjecutarResponse Salida Estructura XML que contiene la información de salida de la ejecución. Su estructura se describe a continuación:

• resultado (booleano): indica el éxito de la ejecución.

• resultadoEjecucion (enumeración string): información del resultado de la ejecución, que puede ser “EjecucionSatisfactoria” o “ErrorInterno”.

• motivoRechazo (string): descripción del error de ejecución (si lo hubo).

• XmlRespuesta (XML): Documento XML, representa la información de salida del trámite o servicio. Cumple con el esquema GEL-XML de salida del trámite o



servicio.

• Documento: estructura XML con la información del archivo adjunto de salida. Contiene:



EjecutarAsync


EjecutarAsync Entrada Estructura XML que contiene la información de entrada de la ejecución. Su estructura se describe a continuación:

• codigoTramite (entero): identifica universalmente el trámite o servicio a ejecutar.

• versionTramite (flotante): identifica la versión del trámite o servicio.

• xmlEntradaEjecucion (XML): Documento XML, representa la información de entrada del trámite o servicio. Cumple con el esquema GEL-XML de entrada del trámite o servicio.

• Documento: estructura XML con la información del archivo adjunto de entrada. Contiene:


o Archivo (base64Binary): archivo serializado base64.

EjecutarAsyncResponse Salida Estructura XML que contiene la información de salida de la ejecución. Su estructura se describe a continuación:

• resultado (booleano): indica el éxito de la ejecución.

• resultadoEjecucion (enumeración string): información del resultado de la ejecución, que puede ser “EjecucionSatisfactoria” o “ErrorInterno”.

• motivoRechazo (string): descripción del error de ejecución (si lo hubo).

• tiquete (entero mayor de cero): este es un consecutivo asignado por la PDI, común a cada uno de los tramites/servicios en un Árbol. Puede llegar a ser igual a numeroRastreo en el caso de árboles compuestos por un solo trámite/servicio.

• numeroRastreo (entero mayor de cero): este es un consecutivo asignado por la PDI, único para cada instancia del trámite/servicio.



ConsultarResultado


ConsultarResultado Entrada Estructura XML que contiene la información utilizada para consultar el resultado de la ejecución. Su estructura se describe a continuación:

• tiquete (entero mayor de cero):

• numeroRastreo (entero mayor de cero):

ConsultarResultadoResponse Salida Estructura XML que contiene la información de salida de la consulta. Su estructura se describe a continuación:

• resultado (booleano): indica el éxito de la operación de consulta.

• resultadoConsulta (enumeración string): información del resultado de la ejecución, que puede ser “EnEjecucion”, “SiExisteDocumento”, “NoExisteDocumento”, o “ErrorInterno”.

• motivoRechazo (string): descripción del error de consulta (si lo hubo).

• XmlRespuesta (XML): Documento XML, representa la información de salida del trámite o servicio. Cumple con el esquema GEL-XML de salida del trámite o servicio.

• Documento: estructura XML con la información del archivo adjunto de salida. Contiene:



9.1.2.1. Seguridad

Tal como ya se ha mencionado, WS-Security y los Certificados Digitales deben ser utilizados para proporcionar la autenticación, confidencialidad, e integridad de los mensajes SOAP intercambiados entre el Sistema de Información y la PDI. La siguiente grafica muestra como WS-Security es utilizado en conjunto con Certificados Digitales X.509 para asegurar el intercambio de mensajes SOAP. Note como ambos sistemas deben conocer previamente las Llaves Públicas de su contraparte:



Figura 17. Intercambio seguro en la PDI.

Adicional a los requerimientos de WS-Security, el Sistema de Información debe enviar como parte de la petición SOAP el usuario y password que le fueron asignados por el Administrador de la Entidad o Empresa en la PDI. Estos son enviados como parte del Header del mensaje SOAP (envelope), utilizando los siguientes parámetros:

Parámetro Tipo de Dato Descripción

Usuario String Cuenta del Sistema de Información en la PDI. Creada por el Administrador de Entidad o Empresa respectivo.

Clave String Password asociada a la cuenta de usuario.

El Anexo D muestra el contenido del archivo de políticas (Policies) que describe los requerimientos de seguridad (WS-Security) del Web Service.

9.2. Uso de tramites/servicios publicados en la PDI por el Ciudadano

La PDI adicionalmente interactúa con Ciudadanos, donde la PDI también puede responder a solicitudes de ejecución de Trámites o Servicios en Entidades Públicas o Privadas previamente registradas, para el detalle del proceso y las actividades relacionadas con ciudadanos se debe consultar el manual de usuario de la plataforma de interoperabilidad y el demo de la solución de acuerdo al sitio Web (Web Site) de acceso a la solución.



9.3. Uso de tramites/servicios publicados en la PDI por el Funcionario Público

La PDI adicionalmente interactúa con Funcionarios Públicos, donde la PDI también puede responder a solicitudes de ejecución de Trámites o Servicios en Entidades Públicas o Privadas previamente registradas, para el detalle del proceso y las actividades relacionadas con Funcionario Publico se debe consultar el manual de usuario de la plataforma de interoperabilidad y el demo de la solución de acuerdo al sitio Web (Web Site) de acceso a la solución.

9.4. Uso de tramites/servicios publicados en la PDI por el Administrador Delegado

La PDI adicionalmente interactúa con Administrador Delegado, donde la PDI también puede responder a solicitudes de ejecución de Trámites o Servicios en Entidades Públicas o Privadas previamente registradas, para el detalle del proceso y las actividades relacionadas con Administrador Delegado se debe consultar el manual de usuario de la plataforma de interoperabilidad y el demo de la solución de acuerdo al sitio Web (Web Site) de acceso a la solución.



10. COMPONENTES PLATAFORMA DE INTEROPERABILIDAD La Plataforma de Interoperabilidad (plataforma PDI) está conformada fundamentalmente por componentes de hardware de plataforma Hewlett Packard y de software Microsoft, tanto a nivel de sistema operativo como de aplicación. La solución involucra cinco (5) servidores HP Proliant DL580 G3 (tipo IIA), tres (3) servidores HP Proliant DL380 G4 (tipo I) y un almacenamiento externo basado en un (1) HP StorageWorks MSA1000. El sistema operativo de los servidores es Microsoft Windows 2003 R2 Enterprise Edition en idioma Inglés y como aplicativo Microsoft SQLserver 2000 SP3 Enterprise Edition. La solución requiere de un ambiente de Directorio Activo para operar correctamente y en forma segura. El cuadro adjunto relaciona los equiposinstalados para la plataforma PDI:

Los servidores HP Proliant tienen instalados el paquete de software denominado Proliant Support Pack (PSP) v7.51, que incluye entre otras la herramienta SURVEY.EXE que puede ejecutarse para generar un archivo texto SURVEY.TXT en cual describe completamente la configuración del servidora nivel de hardware, drivers instalados y servicios activos. Se recomienda generar el listado cada vez que haya cambios en el hardware, actualización de drivers. Se ejecuta C:\COMPAQ\SURVEY\survey.exe este genera el archivo � C:\COMPAQ\SURVEY\survey.txt En general esta plataforma tienen componentes redundantes en cuanto a las capas de Base de Datos, Aplicación y Front-End. Para mantener los niveles de disponibilidad HP periódicamente Hewlett Packard publica en su página web, la actualización del Proliant



Support Pack (PSP), con las versiones más recientes de Drivers, Agentes y utilitarios para su plataforma de hardware: http://welcome.hp.com/country/us/en/support.html?pageDisplay=drivers

El siguiente link corresponde a la página para el HP Proliant DL380 G4:



El link para el servidor DL580 G3, es:



El link para descargar el HP Proliant Support Pack (PSP) más reciente (v7.60) es: http://h18023.www1.hp.com/support/files/server/us/download/24184.html En cuanto a actualizaciones relacionadas con el sistema operativo, Microsoft libera mensualmente el segundo Martes un paquete de actualizaciones de seguridad disponibles mediante el link: http://windowsupdate.microsoft.com Estas actualizaciones deben ser evaluadas para medir su impacto sobre la funcionalidad que ofrece cada servidor y seleccionar aquellas que se requieran aplicar en la plataforma.



11. ELEMENTOS A RESPALDAR EN PLATAFORMA PDI Existen elementos que son necesarios respaldar (backup) para proteger la información y recuperar la funcionalidad en caso de falla. Estos elementos corresponden a: Instancia en cluster de SQL (WBOGSQL05) Bases de datos a respaldar: Bases de Datos propias de PDI

o PDI o PDILOGS o PDILOGSPROD o PDIPAGOS o PDIPAGOSPROD o PDIPROD

Bases de datos de Biztalk

o BiztalkDTADB o BiztalkMgmtDV o BiztalkMsgBoxDb o SSODB

Máquina de Reportes (WBOGRS01)

o PDIPROD o PDILOGSPROD

Recursos de archivo de cluster (WBOGDB10)

o archivosDownload (N:\PDI\archivosDownload) o archivosLogs (N:\PDI\archivosLogs) o archivosUpload (N:\PDI\archivosUpload) o instructivosPruebasUpload (N:\PDI\instructivosPruebasUpload)

Para todos los servidores de la plataforma se deben generar backups de SYSTEM STATE vía NTBACKUP y de la Metabase del IIS (Internet Information Services v6.0) desde su interface de administración.



12. PROCEDIMIENTOS RECOMENDADOS DE OPERACION

12.1. Diaria Revisión de Event Logs (Visor de Sucesos). Verificar el Event Log (Visor de Sucesos) de Aplicación de Windows Server en busca de eventos de error o warnings (avisos). Los eventos de error se visualizan con una señal roja (stop) y los eventos de aviso se visualizan con una señal amarilla (warning). Además, es conveniente observar los eventos de información (mostrados con una señal azul) para asegurarse de que el servidor está funcionando correctamente. Realizar Backup de datos de la plataforma:

• Realizar Backup del “System State” y de la Metabase IIS de los 8 servidores. o Este backup debe hacerse adicionalmente cada vez que haya un cambio en la

configuración. • Realizar Backup de las bases de datos y logs, con rotación de cintas semanal.

De igual manera se revisan los logs própios de la aplicación, se describe este procedimiento:

12.1.1. Ingresar al sitio de administración de PDI

• Ingresar al siguiente URL http://200.21.208.237/PDIAdministracion • Ingresar las credenciales



12.1.2. Buscar registros de logs • Seleccionar la opción de ver Errores técnicos o logs de auditoria como lo muestra

la siguiente figura



• Ingresar los criterios de búsqueda y oprimir buscar



• Si desea consultar el detalle del registro , seleccionar el ID del evento



12.1.3. Depuración de logs • Seleccionar la opción del menú de errores técnicos o logs de auditoria • En la sección de inferior de la pantalla ingresar los criterios para eliminar registros

• Confirmar los registros a eliminar



12.2. Semanal Definir instancias de Monitoreo del Sistema que permitan establecer una línea base del comportamiento de cada servidor. Esta línea base es una referencia que ayuda a detectar en forma temprana algún comportamiento que pueda llegar a impactar la disponibilidad de la aplicación ó del servidor mismo.

Los componentes a monitorear son PROCESSOR, MEMORY, NETWORK y DISKS. Los contadores pueden darle la pauta al administrador del sistema sobre acciones iniciales a tomar para mantenerla operación del servidor y su funcionalidad. Esta línea base puede irse moviendo en la medida que los requerimientos al sistema sean más exigente en cuanto a su poder de procesamiento. A partir de este tipo de información se puede oportunamente solicitar algún tipo de actualización (upgrade) para algún servidor.

Realizar Backup de datos de la plataforma:

o Realizar Full Backup el día Domingo del disco del sistema o Realizar Backup el día Domingo del “System State” y de la Metabase IIS de los

8 servidores.



� Este backup debe hacerse adicionalmente cada vez que haya un cambio en la configuración.

o Realizar Backup el día Domingo de las bases de datos y logs, con rotación de cintas mensual.

12.3. Mensual Realizar Backup de datos de la plataforma:

• Realizar Backup el último Domingo del mes del “System State” y de la Metabase IIS de los 8 servidores.

• Realizar Backup el último Domingo del mes de las bases de datos y logs, con rotación de cintas según los requerimientos del negocio.

12.4. Anual Realizar Backup de datos de la plataforma:

• Realizar Backup el último Domingo del año del “System State” y de la Metabase IIS de los 8 servidores.

• Realizar Backup el último Domingo del año de las bases de datos y logs, con rotación de cintas cada según los requerimientos del negocio.



13. RECUPERACION DE DESASTRES Con los esquemas de Backup anotados en los procedimientos anteriores, se construye la estrategia para recuperar la información de las bases de datos y logs de la plataforma PDI. El proceso de reinstalación de la plataforma se describe en el numeral 2 del presente documento. Componentes involucrados: o Controlador de Dominio: El servidor WBOGDC04 mantiene la información del Servicio

de Directorio Activo y de Autenticación. Si el servidor falla se debe reinstalar Sistema Operativo y recuperar Full Backup del disco del Sistema. Posteriormente recuperar el más reciente Backup de System State para restablecer la funcionalidad de los servicios de esta máquina.

o Servidor de Reportes: El servidor WBOGRS01 en caso de falla, debe reinstalarse el

Sistema Operativo y recuperar Full Backup del disco del Sistema. Posteriormente recuperar el más reciente Backup de System State, Metabase, Bases de Datos y Logs para restablecer la funcionalidad de los servicios de esta máquina.

o Capa de Aplicación: Se soporta con un Network Load Balance (NLB) que mantiene la

operación en caso de falla de uno de los servidores. Para recuperar el servidor fallido, debe reinstalarse el Sistema Operativo e integrarlo nuevamente al NLB. Posteriormente recuperar el más reciente Backup de System State y Metabase para restablecer la funcionalidad de los servicios de esta máquina.

o Front End: Se soporta también con un Network Load Balance (NLB) que mantiene la

operación en caso de falla de uno de los servidores. Para recuperar el servidor fallido, debe reinstalarse el Sistema Operativo e integrarlo nuevamente al NLB. Posteriormente recuperar el más reciente Backup de System State y Metabase para restablecer la funcionalidad de los servicios de esta máquina.

o Cluster Base de Datos: Soportado por 2 servidores en cluster de Microsoft que mantiene

la funcionalidad en caso de falla de uno de los dos servidores. Para recuperar el servidor fallido, debe reinstalarse el Sistema Operativo y agregarlo al cluster MSCS. Reinstalar aplicativo MS SQLserver y sus services packs.



14. SECUENCIA DE ENCENDIDO – APAGADO DE LA PLATAFORMA PDI Esta plataforma consta de 8 servidores HP Proliant y 1 storage MSA1000. En caso de ser necesario intervenir la plataforma y que se requiera apagar/energizar el sistema por actividades como mantenimiento eléctrico, las secuencias son las siguientes:



15. CONSIDERACIONES DEL ENTORNO DE PLATAFORMA DE INTEROPERABILIDAD

15.1. Configuración de la Plataforma: • Al instalar se deben de modificar los dominios a tramitador • Al instalar se deben de modificar los parámetros de configuración • web.config: Hay que verificar que de debe de crear el directorio virtual para almacenar los archivos, como

indica el manual • Demo: Para modificar esta información debe de dirigirse a la la página index-contactenos.htm, dentro

de la carpeta ayuda de cada sitio y colocar la información necesaria

15.2. Reportes: • Por diseño solo se consultan trámites teniendo en cuenta la llave MAXIMA_HISTORIA, la cual está en

meses, esa puede ser una causa del incidente, para ver todos los trámites o servicios hay que especificar TODAS las fechas en el detalle de la búsqueda.

• La confirmación de eliminación de LOGS es la pantalla donde se encuentra descarga del archivo de excel,

adicionalmente se genera un nuevo registro de LOG de Auditoria informando la actividad realizada sobre los datos

PLATAFORMA DE INTEROPERABILIDAD PDI - … · 6. PLATAFORMA DE INTEROPERABILIDAD DEL ESTADO...

Documents

Transcript of PLATAFORMA DE INTEROPERABILIDAD PDI - … · 6. PLATAFORMA DE INTEROPERABILIDAD DEL ESTADO...