Especificaciones técnicas y funcionales para la ... · integración con la Bolsa de Valores de ... Web Services ... • Incorpora los principios de SOA en su implementación

Especificaciones técnicas y funcionales para la integración con la Bolsa de Valores de Colombia

BUS de Integración BVC Fase II Octubre 2007 Preparado por: Bolsa de Valores de Colombia

FORMATO Código :

Archivo:

Versión: 1.0

Especificaciones e Técnicas y Funcionales De Integración

Página 2 de 141

Elaborado por: Arquitectura Revisado por: Aprobado por: Vicepresidente de Tecnología y de Desarrollo e Infraes-tructura

Fecha : Septiembre 24 de 2007 Fecha : Septiembre 24 de 2007 Fecha : Septiembre 24 de 2007

Especificaciones Técnico-Funcionales para la Integración con

la Bolsa de Valores de Colombia

Preparado para: Los Afiliados de la BVC

Preparado por: BVC

Control de versiones: V3

FORMATO Código :

Archivo:

Versión: 1.0


Página 3 de 141



HISTORIA DEL DOCUMENTO

Versión Fecha Autor Comentarios

1.0 27-09-2007 Adriana Arango Guinand

Creación con servicios de Complementación

2.0 12-10-2007

Adriana Arango Guinand

Adición de servicios de Negociación y cumplimiento.

Adición de ejemplos de archivos XML para los servicios de Negociación, Complementación y cumplimiento

3.0 29-10-2007 Adriana Arango Guinand

Adición de servicio funcional de Modificación Datos Cumplimiento y ajuste en el servicio de complementación (No permitir la creación del Inversionista).

Adición de servicios NO funcionales de la Capa de Interconexión :

Servicio de Autenticación, Autorización y Fachada.

Manejo de Errores no del negocio

FORMATO Código :

Archivo:

Versión: 1.0


Página 4 de 141



Tabla de Contenido

1. Especificaciones Técnicas integración BVC ............................................................................ 7 1.1. Propósito y alcance ..................................................................................................... 7 1.2. Introducción .............................................................................................................. 7 1.3. Generalidades ............................................................................................................ 7 1.4. Marco Conceptual ....................................................................................................... 9

1.4.1. Arquitectura Orientada a Servicios (SOA)................................................................... 9 1.4.2. Reseña del estándar FIX y FIXML .............................................................................12 1.4.3. SOAP – Formato de mensajes .................................................................................13 1.4.4. WSDL – Contratos de servicios ................................................................................15 1.4.5. UDDI – Publicación de servicios ...............................................................................15 1.4.6. Web Services ........................................................................................................16 1.4.7. Patrones de comunicación.......................................................................................18 1.4.8. Enterprise Service Bus (ESB)...................................................................................24

1.5. Servicios de la BVC ....................................................................................................25 1.5.1. Interacción con servicios.........................................................................................26

1.5.1.1. Consumo de servicios .....................................................................................26 1.5.1.2. Aspectos de seguridad ....................................................................................27

1.5.2. Diseño de servicios Funcionales ...............................................................................29 1.5.2.1. Servicio de Ingreso Automático de Órdenes.......................................................32 1.5.2.1.1. Caracterización ..............................................................................................32 1.5.2.1.2. Diagrama de secuencia ...................................................................................33 1.5.2.1.3. Proceso en el bus para el uso del servicio ..........................................................34 1.5.2.1.4. Pasos del proceso...........................................................................................35 1.5.2.1.5. Escenarios de prueba (Unitarias de desarrollo)...................................................35 1.5.2.2. Servicio de Notificación de Órdenes ..................................................................37 1.5.2.2.1. Caracterización ..............................................................................................37 1.5.2.2.2. Diagrama de secuencia ...................................................................................37 1.5.2.2.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.2.4. Pasos del proceso...........................................................................................37 1.5.2.2.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.3. Servicio de Notificación de Operaciones.............................................................37 1.5.2.3.1. Caracterización ..............................................................................................37 1.5.2.3.2. Diagrama de secuencia ...................................................................................37 1.5.2.3.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.3.4. Pasos del proceso...........................................................................................37 1.5.2.3.5. Escenarios de prueba......................................................................................37 1.5.2.4. Servicio de Notificaron de Especies ...................................................................37 1.5.2.4.1. Caracterización ..............................................................................................37 1.5.2.4.2. Diagrama de secuencia ...................................................................................37 1.5.2.4.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.4.4. Pasos del proceso...........................................................................................37 1.5.2.4.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37

FORMATO Código :

Archivo:

Versión: 1.0


Página 5 de 141



1.5.2.5. Servicio de Creación de Inversionistas ..............................................................37 1.5.2.5.1. Caracterización ..............................................................................................37 1.5.2.5.2. Diagrama de secuencia ...................................................................................37 1.5.2.5.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.5.4. Pasos del proceso...........................................................................................37 1.5.2.5.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.6. Servicio de Complementación de Operaciones....................................................37 1.5.2.6.1. Caracterización ..............................................................................................37 1.5.2.6.2. Diagrama de secuencia ...................................................................................37 1.5.2.6.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.6.4. Pasos del proceso...........................................................................................37 1.5.2.6.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.7. Servicio de Notificación de Papeleta ..................................................................37 1.5.2.7.1. Caracterización ..............................................................................................37 1.5.2.7.2. Diagrama de secuencia ...................................................................................37 1.5.2.7.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.7.4. Pasos del proceso...........................................................................................37 1.5.2.7.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.8. Servicio de Notificación Inicio del Cumplimiento .................................................37 1.5.2.8.1. Caracterización ..............................................................................................37 1.5.2.8.2. Diagrama de secuencia ...................................................................................37 1.5.2.8.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.8.4. Pasos del proceso...........................................................................................37 1.5.2.8.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.9. Servicio de Estado del Cumplimiento ................................................................37 1.5.2.9.1. Caracterización ..............................................................................................37 1.5.2.9.2. Diagrama de secuencia ...................................................................................37 1.5.2.9.3. Proceso en el bus para el uso del servicio ..........................................................37 1.5.2.9.4. Pasos del proceso...........................................................................................37 1.5.2.9.5. Escenarios de prueba (Unitarias de desarrollo)...................................................37 1.5.2.10. Servicio de Modificación Datos Cumplimiento .....................................................37 1.5.2.10.1. Caracterización .............................................................................................37 1.5.2.10.2. Diagrama de secuencia..................................................................................37 1.5.2.10.3. Proceso en el bus para el uso del servicio .........................................................37 1.5.2.10.4. Pasos del proceso .........................................................................................37 1.5.2.10.5. Escenarios de prueba (Unitarias de desarrollo)..................................................37 1.5.2.11. Servicio de consulta saldo cuentas compensación...............................................37 1.5.2.11.1. Caracterización .............................................................................................37 1.5.2.11.2. Diagrama de secuencia..................................................................................37 1.5.2.11.3. Proceso en el bus para el uso del servicio .........................................................37 1.5.2.11.4. Pasos del proceso .........................................................................................37 1.5.2.11.5. Escenarios de prueba ....................................................................................37

1.5.3. Diseño de servicios No Funcionales ..........................................................................37 1.5.3.1. Servicio Capa de Interconexion ........................................................................37 1.5.3.1.1. Caracterización ..............................................................................................37 1.5.3.2. Manejo de respuestas de los servicios...............................................................37 1.5.3.3. Servicio Autenticación.....................................................................................37

FORMATO Código :

Archivo:

Versión: 1.0


Página 6 de 141



1.5.3.3.1. Caracterización ..............................................................................................37 1.5.3.4. Servicio de Autorización ..................................................................................37 1.5.3.4.1. Caracterización ..............................................................................................37 1.5.3.5. Servicio de Fachada........................................................................................37 1.5.3.5.1. Caracterización ..............................................................................................37

1.6. GLOSARIO................................................................................................................37

FORMATO Código :

Archivo:

Versión: 1.0


Página 7 de 141



1. Especificaciones Técnicas integración BVC

1.1. Propósito y alcance Presentar estándares y aspectos técnicos que regirán la implementación del proyecto Bus de Integración, para exponer servicios de negocios a los afiliados para acceder a las funcionalidades ofrecidas por los sistemas de la BVC

1.2. Introducción

La BVC es la entidad encargada de impulsar el desarrollo y crecimiento del mercado de activos financieros en el país.

En este mercado, un afiliado (por ejemplo un Comisionista de Bolsa) realiza una oferta de com-pra o venta de títulos (ya sea en renta fija o renta variable) en nombre de un inversionista o en nombre propio y la coloca en el mercado a través de la BVC. Una vez la oferta de compra en-cuentra una oferta de venta que satisfaga las condiciones, se realiza el calce y se genera una operación de bolsa.

Esta operación es enviada a los sistemas de BackOffice de la bolsa, donde posteriormente los afiliados realizan la complementación de las dos puntas (punta de compra y punta de venta), di-ligenciando los datos que no fueron ingresados en la negociación como las comisiones del afilia-do, las comisiones de la BVC, datos del cliente, impuestos a ser cobrados, etc. Una vez es dili-genciada toda esta información que complementa la operación, esta es liquidada entregándole al afiliado la papeleta de liquidación donde se indica el monto de la operación, las comisiones cobradas y los impuestos en los que se incurrió.

Estas operaciones pueden estar fraccionadas por compra o por venta, lo que indica que los títu-los están siendo vendidos o comprados por mas de un inversionista. El proceso de complemen-tación se encarga de enviar la información descrita, por cada una de las fracciones que compo-nen la operación.

1.3. Generalidades La BVC ha emprendido una serie de iniciativas tecnológicas para responder a las necesidades del mercado de manera ágil, flexible, segura y robusta. Una de estas iniciativas es el Bus de In-tegración, una plataforma para hacer posible que las funcionalidades de negocio residentes en las aplicaciones de la empresa sean accedidas, orquestadas y expuestas como servicios autó-nomos. Además, para ello el Bus de Integración comunica a los sistemas entre sí, mediando en-tre protocolos, tecnologías, transportes y formatos.

Teniendo en cuenta esos factores de motivación la BVC adopta SOA (Service Oriented Architectu-re) como estilo arquitectónico para su solución de integración de aplicaciones y terceros. Es por ello que en las próximas secciones de este documento se abordan brevemente los conceptos y

FORMATO Código :

Archivo:

Versión: 1.0


Página 8 de 141



principios asociados a este paradigma. Siendo SOA un estilo arquitectónico, no prescribe una tec-nología particular para implementar una arquitectura que cumpla con esta filosofía; sin embargo, es pertinente dedicar algunas líneas a los Web Services, puesto que representan una tecnología basada en estándares de la industria y que permite implementar una arquitectura adherida a los principios SOA.

Con el estilo arquitectónico y el conjunto de estándares que habilitan la construcción de una arqui-tectura orientada a servicios, falta definir la infraestructura para desarrollar y ejecutar una solu-ción que expone servicios y que integra recursos y funcionalidades a lo largo de todo el entorno de sistemas de la BVC. La respuesta a ello se encuentra en un componente de middleware deno-minado ESB (Enterprise Service Bus). Este componente resuelve varias necesidades:

• Incorpora los principios de SOA en su implementación.

• Permite integrar las aplicaciones y recursos de la empresa mediante una amplia gama de adapta-dores y componentes pre-construidos.

• Permite definir servicios que orquestan diversas funcionalidades distribuidas en las aplicaciones de la empresa.

• Proporciona varias opciones de exposición de los servicios construidos, entre las cuales se tiene a los Web Services.

La integración de aplicaciones y de terceros, en términos lógicos muy generales, consiste en el in-tercambio de información entre varios actores participantes, que bien pueden ser proveedores o consumidores de la información. La manera en la cual fluye esta información está determinada por la naturaleza del proceso de negocio que la involucra: en algunos casos la información se pro-duce por un evento generado por condiciones del mercado, el cual puede ocasionar la publicación de la información o la activación de otros procesos, otras veces la información se genera como respuesta explícita a una solicitud, y en otras ocasiones la información se genera de forma masiva y programada como parte de las actividades que culminan la jornada laboral. Todos estos patro-nes de comunicación están soportados por la infraestructura ESB y caracterizan a cada servicio definido, de manera que la interacción con cada uno de ellos obedece al patrón de comunicación en el cual se enmarca. Sobre estos patrones, los servicios específicos identificados por la BVC para ofrecerlos a sus afiliados y la manera de accederlos se elabora un poco más en secciones siguien-tes.

Finalmente, como referencia de carácter técnico se incluyen los estándares más relevantes que participan en la solución, como lo son:

• Convenciones de nombres adoptadas.

• Los estándares de Web Services

o SOAP, para encapsular los mensajes.

o WSDL, como formato para los contratos de los servicios. Los contratos se refieren a la caracterización de la interfaz del servicio, lo cual permite que el mismo sea invocado por un consumidor que conoce dicha interfaz.

o UDDI, para registrar los servicios y publicarlos, de manera que puedan ser descubiertos por sus consumidores potenciales.

FORMATO Código :

Archivo:

Versión: 1.0


Página 9 de 141



• FIX, particularmente FIXML como formato de contenido de la información a intercambiar.

No se incluyen en este documento reseñas a los protocolos de redes como TCP/IP, HTTP, FTP, DNS u otros.

1.4. Marco Conceptual

1.4.1. Arquitectura Orientada a Servicios (SOA)

Definición

Antes de presentar una definición formal de lo que es la arquitectura orientada a servicios, es importante que primero se haga una introducción a la definición de servicio. Un servicio es un recurso lógico que encapsula funcionalidades del negocio, las cuales expone a través de una interfaz bien formada y conocida. Un servicio es concebido bajo la filosofía de caja negra, en donde la información provista por la interfaz debe ser suficiente para conocer el propósito y funcionalidad del mismo, y finalmente es entendible sólo por componentes de software.

Otra forma de definir un servicio es a partir de cómo éste puede ser visto en la fase de di-seño. En tiempo de diseño un servicio es el encapsulamiento de un componente lógico de negocio (software), definido en términos de dos elementos independientes pero relaciona-dos: Interfaz de servicio e implementación de servicio. La siguiente figura ilustra la estruc-tura interna de un servicio desde una perspectiva de diseño.

Funcionalidad-1

Funcionalidad-3

Funcionalidad-2

Implementación

InterfazDefinición de funcionalidades y

reglas de invocación

SERVICIO

Funcionalidad-1

Funcionalidad-2

Funcionalidad-3

Funcionalidad-1

Funcionalidad-3

Funcionalidad-2

Implementación

InterfazDefinición de funcionalidades y

reglas de invocación

SERVICIO

Funcionalidad-1

Funcionalidad-2

Funcionalidad-3

Gráfica 1 Vista a nivel de diseño de un servicio

La interfaz es la parte más importante de un servicio, ya que ésta es quien define el contra-to que establece la identidad del servicio y reglas de invocación a las funcionalidades. La implementación, es la materialización en una plataforma tecnológica en particular de cada una de las funcionalidades definidas en la interfaz del servicio. Dentro de la implementación es donde se encapsulan las reglas de negocio requeridas para ejecutar cada una de las fun-cionalidades descritas en la interfaz.

FORMATO Código :

Archivo:

Versión: 1.0


Página 10 de 141



Teniendo presente el contexto de servicio definido anteriormente, una arquitectura orienta-da a servicios (SOA) puede definirse como el flujo y las relaciones coordinadas entre inter-faces de servicios. A pesar de la claridad de esta definición, existen otras importantes defi-niciones para describir lo que es una arquitectura orientada a servicios, algunas de ellas son:

• Enfoque para diseñar y construir soluciones de software a partir de componentes débilmente acoplados que exponen funciones de negocio como servicios accesibles por otros componentes a través de interfaces estándares.

• Forma de desarrollar una infraestructura empresarial de software en donde diferen-tes aplicaciones, sistemas o módulos pueden intercambiar datos independiente-mente del lenguaje de programación en el que se encuentran construidos, sistema operacional en el que se ejecutan o plataforma hardware donde residen. Esto gra-cias al nivel de desacoplamiento y estandarización que ofrecen los servicios dentro de los cuales se encapsulan las funcionalidades que definen a dichos sistemas o aplicaciones.

Independientemente de la definición que se emplee siempre habrá un factor común entre ellas: la concepción de servicio como unidad lógica débilmente acoplada.

Ventajas, Principios y Consideraciones de Diseño de Aplicaciones bajo un Enfoque SOA

Diseñar e implementar sistemas y aplicaciones bajo un enfoque orientado a servicios trae consigo varias ventajas y posibilidades para la empresa entera, sus procesos, sistemas y proyectos. A continuación se describen algunas de estas ventajas:

• Composición de aplicación: Una de las principales ventajas del diseño orientado a servicios, es la capacidad de diseñar y componer procesos del negocio a partir de servicios existentes. Es importante notar que un proceso es un conjunto de funcio-nalidades de negocio que se ejecutan coordinadamente y un servicio es el encapsu-lamiento de una funcionalidad o conjunto de funcionalidades relacionadas del nego-cio. De igual forma, una misma funcionalidad del negocio puede hacer parte de va-rios procesos.

• Promueve la filosofía de aplicaciones centradas en procesos: Debido a la fa-cilidad de componer procesos a partir de servicios existentes, el diseño orientado a servicios promueve que las aplicaciones no se centren solo en proveer una solución a una parte específica de un proceso, sino más bien en proveer una solución al pro-ceso en general. La filosofía tras esta iniciativa es pasar de un modelo de aplicacio-nes departamentales a un modelo de aplicaciones empresariales modeladas alrede-dor de procesos.

• Flexibilidad y movilidad: El nivel de independencia y desacoplamiento existente entre los procesos del negocio y la plataforma tecnológica empleada para materiali-zarlos, permite implementar de manera ágil nuevos requerimientos, modificar pro-cesos existentes y definir nuevos procesos, generando un impacto mínimo en la in-fraestructura existente.

FORMATO Código :

Archivo:

Versión: 1.0


Página 11 de 141



• Re-usable: Desde una perspectiva de procesos del negocio, los servicios son uni-dades lógicas altamente re-usables, gracias a lineamientos de diseño como granu-laridad gruesa y bajo acoplamiento que le permiten implementar funcionalidades cohesivas del negocio como una única entidad. De esta manera el desarrollo de nuevos sistemas se apoyará en gran parte en servicios existentes, reduciendo enormemente el número de funcionalidades a desarrollar. Finalmente, al ser des-arrolladores bajo estándares aprobados de la industria permiten que puedan ser usados desde varias plataformas, en varios proyectos.

• Facilidad de integración: Los servicios al estar definidos alrededor de interfaces bien formadas y conocidas, soportados en estándares de la industria e implementa-dos bajo principios de diseño como bajo acoplamiento y caja negra, permiten que la integración de aplicaciones sea más simple, eficiente y confiable.

• Promueve roles especializados de desarrolladores: Los servicios al ser unida-des enfocadas al encapsulamiento de funcionalidades altamente cohesivas del ne-gocio, permite que los desarrolladores solo se enfoquen en una sola parte del pro-blema, evitando de esta manera que éstos requiera conocer la globalidad del pro-blema a resolver. De igual forma, permite que los desarrolladores menos experi-mentados sean más productivos y generen resultados más rápidamente.

• Mejora en la calidad de software: Los servicios son unidades que pueden ser probados y validados más fácil y profundamente que las pruebas que se pueden llegar a realizar sobre una aplicación desarrollada como una única unidad. Redu-ciendo de esta manera el número de errores que se pueden presentar, una vez la aplicación se encuentre en producción.

• Mejora en la escalabilidad y disponibilidad: El diseño de soluciones de alta dis-ponibilidad estructuradas alrededor de la replicación de funcionalidades, se hace mucho más sencillo si se tienen unidades independientes, no acopladas y móviles como son los servicios, debido a que las aplicaciones o sistemas consumidores del servicio no se ven afectados si se cambia constantemente la ubicación física del mismo.

No obstante, estas ventajas y posibilidades inherentes al desarrollo de aplicaciones bajo un enfoque SOA sólo pueden ser logradas de manera exitosa sí se tienen en cuenta algunos principios mínimos de diseño e implementación, como por ejemplo: nivel de granularidad y acoplamiento de los servicios, estándares empleados, tipos de datos, orientación de los ser-vicios y niveles de abstracción de los sistemas. A continuación se describen algunos princi-pios y consideraciones de diseño que deben reflejar la arquitectura:

Servicios débilmente acoplados: Esto significa que los componentes se ejecutan inde-pendientemente de los demás, y sus operaciones no necesariamente interrumpen o afectan a otros componentes. Los sistemas altamente acoplados tienen fuertes interconexiones con otros sistemas que los hacen dependientes a nivel de ejecución y operatividad.

Granularidad gruesa del servicio: La granularidad de un servicio expresa el nivel de acoplamiento externo hacia dependencias de funcionalidades y datos residentes en otros servicios o sistemas. Cuando se tiene una granularidad muy fina, las funcionalidades encap-suladas por el servicio son altamente especializadas y una invocación al servicio requiere de la colaboración de varias funcionalidades residentes en otros sistemas o servicios; presen-

FORMATO Código :

Archivo:

Versión: 1.0


Página 12 de 141



tando de esta manera una gran cantidad de intercambios a nivel de red para ejecutar de manera exitosa las funcionalidades internas y satisfacer la invocación. Se debe buscar al máximo eliminar dependencias externas de funcionalidades y datos agrupando en un solo lugar todas las funcionalidades y datos requeridos para ejecutar el servicio como una única unidad.

Tipos de datos: Los tipos de datos empleados en los intercambios hacia y desde un servi-cio deben ser en lo posible tipo de datos atómicos y no objetos propios del modelo de clases que describe las funcionales encapsuladas por el servicio. De igual manera, estos tipos de datos deben mantenerse en cuanto a tamaño y longitud dentro de los estándares definidos por la IEEE para tipos de datos. Se debe evitar al máximo el uso de tipo de datos comple-jos y propietarios de las plataformas.

Flexibilidad: La arquitectura debe posibilitar cambios, substitución o incorporación de componentes con el menor impacto en el resto de los sistemas. La substitución o cambio de un sistema no debería ser transparente a los sistemas usuarios de los servicios que aquél ofrece a través de sus interfaces. Por otra parte, el principio de interfaces de uso general permite que los sistemas nuevos se incorporen a la arquitectura usando las interfaces exis-tentes, sin imponer cambios a las mismas.

Basados en estándares abiertos: La descripción, ubicación e invocación de los servicios debe realizarse bajo tecnologías implementadas sobre estándares reconocidos de la indus-tria y adoptados por varios fabricantes. Se debe evitar al máximo apoyarse en tecnologías propietarias.

Naturaleza caja negra de los servicios: Esto significa que la información provista por la interfaz debe ser suficiente para conocer el propósito y funcionalidad del servicio, y no se debe requerir otro tipo de información extra o metadata para interactuar con el servicio.

Los servicios son dirigidos por el negocio: La definición de servicios debe ir acorde a los lineamientos y procesos del negocio. Estos deben abstraerse de las tecnologías y plata-formas tecnológicas existentes dentro de la organización.

Orientación a uso en la red: Los servicios deben habilitarse para comunicarse a través de la intra/extra/inter net.

1.4.2. Reseña del estándar FIX y FIXML El Protocolo FIX (Financial Information eXchange) es una especificación técnica para las comunicaciones basadas en el uso de mensajes. En más detalle, el Pro-tocolo FIX son una serie de especificaciones de mensajería desarrolladas en cola-boraciones con bancos, brokers, intercambiadores, utilidades industriales y aso-ciaciones, investigadores y proveedores de tecnologías de la información de todo el mundo. Toda esta gran cantidad de participantes ofrecen una visión común, un lenguaje común para la automatización de intercambio de elementos financieros.

El protocolo FIX es un protocolo abierto y gratuito, pero no es un software. El pro-tocolo se utiliza para que los desarrolladores de software puedan crear productos comerciales o productos open-source.

FORMATO Código :

Archivo:

Versión: 1.0


Página 13 de 141



El protocolo FIX contiene unas especificaciones integrales de muchos tipos de ór-denes y sistemas de intercambio.

La razón de que exista un protocolo asentado y considerado como estándar pro-voca una simplicidad y una elegancia en el mundo financiero.

FIX nació en el año 1992, construido para establecer comunicación entre dos em-presas, las empresas Fidelity Investments y Salomon Brothers. Hoy en día, FIX ha evolucionado mucho, y al igual que las tecnologías, se ha ido mejorando, evo-lucionando y ampliado. FIXML es el resultado de dicha evolución.

FIXML es un protocolo FIX con todas las especificaciones, reglas y normas del FIX pero con la diferencia de que éste se ha adecuado a las nuevas tecnologías, con-cretamente FIXML está basado en las reglas del lenguaje XML.

FIXML, para entendernos, define exactamente lo mismo que FIX, solo que los 2 sistemas tienen formas distintas de expresarlo donde los archivos de FIX ocupan mucho menos espacio que los de FIXML pero estos últimos son mucho mas en-tendibles y fáciles de manejar.

Para más información de este estándar www.fixprotocol.org

1.4.3. SOAP – Formato de mensajes SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de inter-cambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web.

A diferencia de DCOM y CORBA, que son binarios, SOAP usa el código fuente en XML. Esto es una ventaja ya que facilita su lectura por parte de humanos, pero también es un inconveniente dado que los mensajes resultantes son más largos. El intercambio de mensajes se realiza mediante tecnología de componentes (soft-ware componentry, ver ingeniería de software). El término Object en el nombre significa que se adhiere al paradigma de la programación orientada a objetos.

SOAP es un marco extensible y descentralizado que permite trabajar sobre múlti-ples pilas de protocolos de redes informáticas. Los procedimientos de llamadas remotas pueden ser modelados en la forma de varios mensajes SOAP interac-tuando entre sí.

SOAP funciona sobre cualquier protocolo de Internet, generalmente HTTP, que es el único homologado por el W3C. SOAP tiene como base XML, con un diseño que cumple el patrón Cabecera-Desarrollo de diseño de software, como otros muchos diseños, verbigracia HTML. La cabecera Header es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones. El desarrollo Body con-tiene la información principal, que se conoce como carga útil (payload). La carga útil se acoge a un XML Schema propio.

FORMATO Código :

Archivo:

Versión: 1.0


Página 14 de 141



Ejemplos de mensajes SOAP: Como ejemplo se muestra la forma en que un cliente solicitaría información de un producto a un proveedor de servicios Web:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<getProductDetails xmlns="http://warehouse.example.com/ws">

<productId>827635</productId>

</getProductDetails>

</soap:Body>

</soap:Envelope>

Y esta sería la respuesta del proveedor:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">

<getProductDetailsResult>

<productName>Toptimate 3-Piece Set</productName>

<productId>827635</productId>

<description>3-Piece luggage set. Black Polyester.</description>

<price>96.50</price>

<inStock>true</inStock>

</getProductDetailsResult>

</getProductDetailsResponse>

</soap:Body>

</soap:Envelope>

HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por ejemplo. Otros protocolos como GIOP/IIOP o DCOM suelen ser repelidos por estos cortafuegos.

La especificación completa se puede consultar en el siguiente enlace

http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

FORMATO Código :

Archivo:

Versión: 1.0


Página 15 de 141



1.4.4. WSDL – Contratos de servicios WSDL son las siglas de Web Services Description Language, un formato XML que se utiliza para describir servicios Web. La versión 1.0 es la que existe como reco-mendación por parte del W3C. La versión 1.1 no alcanzó tal estatus. Se espera que la versión 2.0, de la cual ya existen varios borradores, se convierta en la próxima recomendación.

WSDL describe la interfaz pública a los servicios Web. Está basado en XML y des-cribe la forma de comunicación, es decir, los requisitos del protocolo y los forma-tos de los mensajes necesarios para interactuar con los servicios listados en su ca-tálogo. Las operaciones y mensajes que soporta se describen en abstracto y se li-gan después al protocolo concreto de red y al formato del mensaje.

Así, WSDL se usa a menudo en combinación con SOAP y XML Schema. Un pro-grama cliente que se conecta a un servicio web puede leer el WSDL para determi-nar que funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL.

La especificación completa puede consultarse en el siguiente enlace

http://www.w3.org/TR/wsdl

1.4.5. UDDI – Publicación de servicios UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres par-tes:

• Páginas blancas - dirección, contacto y otros identificadores conocidos.

• Páginas amarillas - categorización industrial basada en taxonomías.

• Páginas verdes - información técnica sobre los servicios que aportan las propias empresas.

UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

El sitio Web que mantiene el estándar UDDI es

http://www.uddi.org/

El conjunto de especificaciones de UDDI se pueden consultar a través del siguien-te enlace

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv2

FORMATO Código :

Archivo:

Versión: 1.0


Página 16 de 141



1.4.6. Web Services Web Services significa muchas cosas para diferentes personas, pero en términos generales se trata de una colección de protocolos y estándares que sirven para intercambiar datos en-tre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programa-ción diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares.

Ahora bien, para no prescindir de una definición más formal, se puede decir que un Web service es un sistema de software diseñado para soportar interacción de máquina a máqui-na sobre una red. Este sistema tiene una interfaz descrita en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el Web service de la for-ma aprescrita por su descripción usando mensajes SOAP, típicamente usando HTTP sobre una serialización XML en conjunto con otros estándares Web.

Agentes y Servicios

Un Web service es una noción abstracta que debe ser implementada por un agente concre-to (ver la figura 1). El agente es la pieza concreta de software o hardware que envía y reci-be mensajes, mientras que el servicio es el recurso caracterizado por el conjunto abstracto de funcionalidades provistas. Para ilustrar esta distinción, se puede implementar un Web service particular usando un agente un día (quizá escrito en algún lenguaje de programa-ción particular) y un agente diferente al día siguiente (usando otro lenguaje de programa-ción) con la misma funcionalidad. Aunque el agente haya cambiado, el Web service sigue siendo el mismo.

Solicitantes y Proveedores

El propósito de un Web service es proveer alguna funcionalidad a petición de su propietario (una persona u organización). La entidad proveedora es la persona u organización que pro-vee el agente apropiado para implementar un servicio particular (Ver figura 1-1: Roles bási-cos)

Una entidad solicitante es una persona u organización que desea hacer uso del Web service de la entidad proveedora. Para ello usará un agente solicitante para intercambiar mensajes con el agente de la entidad proveedora.

FORMATO Código :

Archivo:

Versión: 1.0


Página 17 de 141



Descripción del servicio

El mecanismo del intercambio de mensajes están documentadas en la descripción del servi-cio (WSD, ver figura 1-1). El WSD es una especificación procesable por máquina de la inter-faz del Web service, escrita en WSDL. Define el formato del mensaje, tipos de datos, proto-colos de transporte y formatos de serialización de transporte que deberían ser usados entre el agente solicitante y el agente proveedor. También especifica una o más ubicaciones de red en la cual puede ser invocado el agente proveedor, y puede proporcionar alguna infor-mación acerca del patrón de intercambio de mensajes esperado. En esencia, la descripción del servicio representa un acuerdo que gobierna las mecánicas de interacción con el servi-cio.

Semántica

La semántica de un Web service es la expectativa compartida del comportamiento del servi-cio, en particular en respuesta a mensajes que le son enviados. En efecto, este es el “con-trato” entre la entidad solicitante y la entidad proveedora considerando el propósito y con-secuencias de la interacción. Aunque este contrato representa el acuerdo general entre las entidades sobre cómo y por qué sus respectivos agentes interactúan, no está necesaria-mente escrito o explícitamente negociado. Puede ser explícito o implícito, oral o escrito, procesable por máquina u orientado al humano, y puede ser un acuerdo legal o un acuerdo informal.

Aunque la descripción del servicio representa un contrato que gobierna la mecánica de in-teracción de un servicio particular, la semántica representa un contrato que gobierna el sig-nificado y el propósito de la interacción. La línea divisoria entre las dos no es necesariamen-te rígida.

Resumen de la interacción con un Web service

Hay muchas formas en las cuales una entidad solicitante puede usar un Web service. En general, los siguientes grandes pasos se requieren (figura 1-1): (1) las entidades solicitante

y proveedora se conocen entre sí (o al menos una es conocida por la otra); (2) las entida-des solicitante y proveedora de alguna manera acuerdan la descripción del servicio y la se-mántica que gobernará la interacción entre los respectivos agentes; (3) la descripción del servicio y la semántica son conocidas por los agentes solicitante y proveedor; y (4) los agentes solicitante y proveedor intercambian mensajes, con lo cual se ejecuta alguna tarea a petición de las entidades solicitante y proveedora; es decir, el intercambio de mensajes con el agente proveedor representa la manifestación concreta de de la interacción con el Web service de la entidad proveedora. Algunos de estos pasos pueden estar automatizados, otros pueden ser ejecutados manualmente.

FORMATO Código :

Archivo:

Versión: 1.0


Página 18 de 141



Figura 1-1. Proceso general de consumo de un Web Service

1.4.7. Patrones de comunicación Los patrones arquitectónicos de mensajes pretender mostrar los diferentes modelos o me-canismos lógicos por medio de los cuales se puede implementar una interfaz proveedora de servicios. Estos patrones están estrechamente relacionados con los mecanismos lógicos empleados en la documentación de los objetos de integración (FOI).

Por otra parte, es importante resaltar que para efectos prácticos de la explicación que a continuación de presenta para los diferentes patrones de mensajería, llamaremos solici-tante a la aplicación origen del mensaje y proveedor al sistemas recibe el mensaje, pro-cesa la operación y de acuerdo al caso, devuelve una respuesta.

Operación Sincrónica (Request/Reply)

• Propósito : Habilitar un protocolo seudo-sincrónico para operaciones. Estas opera-ciones pueden ser consultas repetibles o actualizaciones que originen cambios en el estado del sistema que provee el servicio.

• Motivación: El solicitante desea una respuesta sincrónica a una operación, pero no puede esperar indefinidamente.

• Aplicabilidad: El solicitante desea ejecutar una operación en el proveedor. La apli-cación del solicitante debe ser capaz de reestablecerse de un error de time out o fa-lla de la aplicación que impida la recepción del acuse de recibo. Esto puede requerir

FORMATO Código :

Archivo:

Versión: 1.0


Página 19 de 141



que el solicitante sea capaz de reconciliar su estado con el estado del proveedor del servicio.

• Descripción :El solicitante realiza una llamada al proveedor para que este le preste un servicio. La operación devuelve un estatus indicando los resultados de la opera-ción o un error de time out en caso de que el proveedor no conteste dentro de un período de tiempo determinado. El resultado de la operación puede ser arbitraria-mente complejo, sin embargo, se espera una sola respuesta. La operación es perci-bida como sincrónica desde el punto de vista del solicitante.

• Estructura :El proveedor usa una cola simple que puede ser exclusiva o comparti-da, permitiendo balance de carga en un conjunto de proveedores. La cola que utili-za el solicitante para recibir la respuesta es exclusiva. En caso de que la operación sea repetible (puede ejecutarse más de una vez) la cola del solicitante no debe ser persistente ya que implica una sobrecarga innecesaria en el sistema. Si la operación no es repetible (sólo puede ejecutarse una vez) la cola del solicitante debe ser per-sistente para confirmar la ejecución de la operación aun cuando el sistema presente fallas.

Proveedor : Cola

Solicitante : Cola

: Proveedor : Solicitante

3: Procesar Consulta

4: Respuesta(PUT)

2: Operación (GET)

6: Time Out

1: Operación (PUT)

5: Respuesta (GET)

Figura. Modelo dinámico patrón request-reply

• Notas de Implementación :El solicitante debe estar preparado para manejar el caso en el cual la operación no es respondida durante el período de time out.

Un aspecto crucial de realizar operaciones de actualización sincrónica es el caso en que la operación falla o genera un error de time out antes de que el acuse de recibo sea recibido por el solicitante. En esta situación, el solicitante no sabe si la actualización fue exitosa. De todas maneras, si se usa un mecanismo confiable de transporte de mensa-jes, el solicitante puede asumir que la petición ha sido delegada de manera segura al proveedor y que éste ejecutará la actualización de ser posible. Esto induce al solicitante a no emitir la actualización más de una vez, inclusive cuando exista la posibilidad de que la actualización no haya sido ejecutada. Es necesario que la aplicación pueda ma-nejar esta potencial incertidumbre. Existen varios enfoques posibles para manejar esta incertidumbre:

FORMATO Código :

Archivo:

Versión: 1.0


Página 20 de 141



No es crítico para el solicitante si la actualización fue exitosa. En otras palabras, el acu-se de recibo es meramente por conveniencia del solicitante, pero no es parte esencial del mismo.

El solicitante provee un mecanismo para verificar el estado del proveedor

luego de la operación de actualización y reconciliar el estado si es necesario. Este caso demuestra que la diferencia entre actualizaciones sincrónicas y asíncronas es sutil.

El solicitante revierte los cambios locales y envía al proveedor una solicitud de

reversar la operación realizada y espera una respuesta. De esta nabera se restaura el estado a su punto original. Entonces el solicitante puede reinten-tar la operación.

Si múltiples solicitantes pueden actualizar el mismo recurso de manera con-

currente, es necesario proveer un mecanismo de coordinación en un nivel su-perior. De manera análoga, si un solicitante tiene la posibilidad de ejecutar varias operaciones relacionadas, es necesario implementar un mecanismo que permita garantizar el orden de ejecución de las operaciones, ya que, por ejemplo, el orden de despacho de mensajes generalmente no está garantiza-do.

En general, el período máximo de espera o time out es configurado de manera que la mayor cantidad de operaciones de actualización reciban el acuse de recibo de la opera-ción. Si este no es el caso, entonces es posible que el patrón Notificación sea más apro-piado.

Notificación • Propósito: Permitir a un solicitante la petición de una operación en un proveedor

sin esperar notificación alguna; el patrón asume que la operación no es repetible.

• Motivación: El solicitante desea ejecutar una operación que altera el estado de un recurso, pero no requiere confirmación.

• Aplicabilidad: El proveedor es confiable para procesar la petición y, además, no es de incumbencia del solicitante el resultado de la operación. Notificación delega de manera transparente la responsabilidad de la operación al proveedor.

• Descripción: El solicitante invoca actualizaciones en un proveedor. La responsabi-lidad del solicitante es invocar cada operación una y sólo una vez. La operación es percibida como sincrónica por el solicitante ya que este está seguro de que va a ser procesada. El proveedor inicia y espera por peticiones entrantes. La responsabilidad del proveedor es asegurar que cada petición de actualización sea procesada exac-tamente una vez. La aplicación del proveedor es responsable por autenticar la peti-ción. Para leer la petición, la operación del lado del proveedor debe ser transaccio-nal, es decir, si la operación falla al ejecutarla, debe volverse a ejecutar la opera-ción.

FORMATO Código :

Archivo:

Versión: 1.0


Página 21 de 141



• Estructura: El proveedor usa una cola simple, la cual puede ser exclusiva o com-partida, permitiendo balance de carga entre múltiples proveedores, esta cola debe ser persistente para garantizar que no se pierdan las operaciones si se interrumpe el proceso del proveedor. El solicitante no necesita una cola para recibir la respues-ta.

El siguiente diagrama muestra la interacción entre los componentes para implementar este patrón:

Proveedor : Cola

: Proveedor : Solicitante

3: Procesar Actualización

2: Actualización (GET)

1: Actualización (PUT)

Figura. Modelo dinámico patrón notificación

El solicitante simplemente envía la petición al proveedor una y sólo una vez y asume que éste procesará la operación una y sólo una vez.

• Notas de Implementación: Este patrón garantiza uno y sólo un despacho del mensaje al proveedor. Si la aplicación del lado del proveedor corre bajo el control de un monitor de transacciones, el alcance de la transacción debe ser extendido pa-ra incluir la lectura de la petición. El proveedor es responsable de tratar con la peti-ción del solicitante de manera satisfactoria, típicamente invocando alguna operación de negocios en un punto de sincronización antes de aprobar la operación. El pro-veedor puede utilizar llamadas a un coordinador global de transacciones.

Solicitud Diferida

• Propósito: Habilitar un protocolo asíncrono para ejecutar operaciones. Estas ope-raciones pueden ser consultas repetibles o actualizaciones que originen cambios en el estado del sistema que provee el servicio.

• Motivación: El solicitante desea ejecutar una operación, pero no requiere el resul-tado para continuar su proceso. El resultado será requerido posteriormente por el mismo solicitante u otra aplicación. Por ejemplo, la solicitud de recuperación de in-formación histórica (Recall desde un archive).

• Aplicabilidad: El resultado será devuelto después de un tiempo de haber sido emi-tida la petición, hacia la aplicación que originó la petición o hacia otro proceso. El proceso que consume la respuesta es llamado recolector. Al menos un recolector debe ser registrado para recibir las respuestas antes de que alguna petición sea emitida por el solicitante. Todas las respuestas serán entregadas a los recolectores

FORMATO Código :

Archivo:

Versión: 1.0


Página 22 de 141



registrados. Si no existen recolectores registrados, entonces la respuesta será des-echada. La operación puede ser arbitrariamente compleja, pero se espera sólo una respuesta del proveedor.

• Descripción: El solicitante realiza operaciones simples. De manera asíncrona, la operación devuelve un código de estatus indicando que ésta fue aceptada. El solici-tante debe tener registrado al menos un recolector para recibir la respuesta del proveedor.

• Estructura: El proveedor usa una cola simple, la cual puede ser exclusiva o com-partida, permitiendo balance de cargas entre múltiples proveedores. La cola de res-puestas del solicitante es exclusiva y su persistencia depende de la criticidad de capturar la respuesta. El acceso a la cola del solicitante lo realiza un manejador de recolectores, este componente tiene la responsabilidad de tomar mensajes de la co-la de respuestas y propagarlo a los recolectores registrados en él.

Proveedor : Cola

Solicitante : Cola

: Proveedor

: Solicitante

Recolector 1

Recolector n

Manejador de Recolectores

3: Procesar Operación

2: Operación (GET)

4: Respuesta(PUT)

1: Operación (PUT)

5: Respuesta (GET)

6: Respuesta

7: Respuesta

Figura. Modelo dinámico patrón solicitud diferida.

Notas de Implementación

Este patrón implementa una forma de publicador – subscriptor dentro del proceso de una aplicación. El manejador de recolectores ejecuta un hilo adicional para tratar cada opera-ción. Este hilo puede ser configurado con una duración máxima de espera de la respuesta o time out.

Aunque una petición puede generar un error de time out, este período generalmente es mucho más prolongado que el del patrón Request/Reply. Si la respuesta es recibida en el período esperado, el manejador la despacha entre los recolectores registrados, en caso con-trario, el hilo termina sin despachar respuestas. El manejador se encarga de mantener lim-pia la cola luego de terminar un hilo.

FORMATO Código :

Archivo:

Versión: 1.0


Página 23 de 141



Publicador / Subscriptor (Publish / Subscribe)

Propósito

Desconectar al publicador del mensaje del consumidor del mismo. El destino de un mensaje es un tópico, no un consumidor en particular.

Motivación

Un sistema desea enviar un mensaje a todos los sistemas interesados en recibirlo, sin em-bargo, el sistema fuente no conoce cuáles son los interesados.

Aplicabilidad

Use el patrón de publicador-suscriptor cuando se agreguen y eliminen miembros de un gru-po de distribución dinámicamente, de forma que el nodo de publicación no conozca a todos los nodos de suscripción. En este caso, se usa un proceso intermedio que conoce los desti-nos de un mensaje de acuerdo a su tópico. Este patrón permite al publicador estar desaco-plado del subscriptor.

Descripción

Los mensajes generados por el publicador no están asociados a un destino en particular si-no a un tópico. Los subscriptores están subscritos a uno o más tópicos. Una aplicación in-termedia llamada broker se encarga de mantener la lista de subscriptores por tópico y de despachar los mensajes a los subscriptores asociados.

Estructura

El broker usa una cola simple, la cual puede ser exclusiva o compartida, permitiendo balan-ce de cargas entre múltiples proveedores. Los consumidores tienen una cola exclusiva. Cuando un mensaje es colocado en la cola del broker este lo despacha a las colas de los consumidores subscritos al tópico del mensaje. Para mantener estas relaciones, el broker tiene una lista de distribución.

: Publicador

: Subscriptor

Broker : Cola

: Cola

: Cola : Subscriptor

: Subscriptor : Cola

: Broker

no subscrito al tópico

1: Mensaje, Tópico (PUT)

3: Mensaje (PUT)

4: Mensaje (PUT)

2: Mensaje, Tópico (GET)

5: Mensaje (GET)

6: Mensaje (GET)

FORMATO Código :

Archivo:

Versión: 1.0


Página 24 de 141



Figura. Modelo dinámico patrón publicador-subscritor.

Notas de Implementación

Es necesario contar con una estructura de tópicos (pueden estar organizados de manera je-rárquica) a los cuales se subscriben los consumidores. El broker mantiene una lista de dis-tribución por cada tópico, esta lista contiene los consumidores subscritos a cada tópico.

Las colas de los consumidores y del broker pueden ser persistentes si se quiere garantizar que no se pierdan mensajes ante una falla del broker o los consumidores.

Un broker puede estar subscrito a otro, esto permite crear una red de brokers. Este hecho permite que el mecanismo de publicación - suscripción sea altamente escalable.

Se puede manejar un esquema similar en el cual los consumidores envíen acuses de recibo al broker y este a su vez al publicador (ya sea de manera sincrónica o asíncrona) para certi-ficar que todos los consumidores recibieron el mensaje.

1.4.8. Enterprise Service Bus (ESB)

El Enterprise Service Bus (ESB) está emergiendo como un componente de infraestructura middleware que soporta la implementación de SOA en una empresa. La necesidad de un ESB puede ser considerado como soporte para la implementación de conceptos de SOA pa-ra:

• Desligar un servicio desde el punto de vista del cliente a la actual implementación de un servicio; esto incrementa considerablemente la flexibilidad de la arquitectura, permi-tiendo la sustitución de un proveedor de servicio por otro sin que el cliente sea adverti-do del cambio o sin la necesidad de alterar la arquitectura para soportar dicha sustitu-ción.

• Desligar los aspectos técnicos de las interacciones de un servicio. Esto puede aplicar a aspectos de interacciones tales como:

Cómo las interacciones del servicio son asegurados. Cómo la integridad de las transacciones de los negocios y los datos son

mantenidos. Cómo la invocación de servicios alternativos de un proveedor es manejado

en el evento que el proveedor por defecto no es disponible. • Integración y administración de servicios en la compañía.

FORMATO Código :

Archivo:

Versión: 1.0


Página 25 de 141



• Estos aspectos implican la necesidad de un middleware para soportar una implementa-ción de SOA. Algunas de las funciones que pueden ser provistas por el middleware son:

• Mapa de requerimientos de servicios de un protocolo y dirección a otros. • Transformar formatos de datos. • Soportar una variedad de modelos de transacciones y seguridad entre los servicios de

los clientes y los servicios de los proveedores, y validar que clientes y proveedores pue-den soportar o requerir diferentes modelos.

• Agregar o remover requerimientos y respuestas de servicios. • Soportar protocolos de comunicación entre múltiples plataformas con la apropiada cali-

dad del servicio. • Proveer capacidad de mensajería tales como publicación/suscripción de mensajes, para

soportar diferentes modelos de mensajería tales como eventos de requisito/respuesta asíncrona.

Requisitos empresariales para un ESB

En un servicio SOA, por definición, debe ser re-usable para un número de clientes diferen-tes, por lo tanto se alcanza a reducir el número de conexiones. Además el ESB:

• Soporta altos volúmenes de interacciones individuales. • Soporta más estilos de integración, tales como message-oriented y event-driven inte-

gration, para extender el alcance de SOA. El ESB puede permitir a las aplicaciones que el SOA pueda hacerlo directamente o a través del uso de adaptadores.

1.5. Servicios de la BVC

Los servicios NO funcionales identificados para ser expuestos en la primera entrega del pro-yecto son:

• Capa de Interconexión

o Servicio de Autenticación

o Servicio de Autorización

o Servicio Fachada

Los servicios funcionales identificados para ser expuestos en la primera entrega del proyec-to son:

• Ingreso Automático de órdenes

• Notificación de Ordenes

FORMATO Código :

Archivo:

Versión: 1.0


Página 26 de 141



• Notificación de especies

• Notificación de operaciones (notificación de calce)

• Administración de Inversionista

• Complementación de la operación

• Papeleta de operación

• Notificación de inicio de cumplimiento

• Información del estado de cumplimiento

• Modificación de operación (datos de cumplimiento)

• Consulta saldo cuenta compensación

• Notificación resumen compensación

• Consulta de estado de títulos y operaciones en garantía

1.5.1. Interacción con servicios

1.5.1.1. Consumo de servicios

Se expondrán un conjunto de funcionalidades de negocio, cada una de ellas accesible me-diante un servicio que será utilizado por los afiliados de la bolsa mediante la invocación de uno o varios Web Services que la BVC tendrá disponibles.

FORMATO Código :

Archivo:

Versión: 1.0


Página 27 de 141



La BVC ofrece un esquema en el cual todos los servicios que hacen posible la interacción entre la bolsa y sus afiliados serán implementados en la BVC. Lo que esto significa es que la bolsa no impondrá requerimientos de implementación de Web Services a los afiliados para entregarles información, sino que estos desarrollarán las aplicaciones clientes para el con-sumo de los servicios.

La manera en la cual las aplicaciones clientes deben comportarse depende del patrón de comunicación de cada servicio de negocio:

• Servicios tipo requerimiento/respuesta. Se presentan en dos variantes, según sea la respuesta sincrónica o asíncrona. En el caso sincrónico, el cliente invocará un Web Service, con lo cual está realizando una solicitud, y la respuesta a la misma, positiva o negativa, se proporciona como resultado de la misma llamada. Cuando la respuesta no puede ser sincrónica (lo cual lo determina el proceso de negocio y la tecnología sobre la cual está soportado), el cliente tendrá dos interacciones. Una para colocar la solicitud en el sistema, y un segundo Web Service para consultar si ya se obtuvo la respuesta.

• Servicios tipo notificación. En este caso las variantes vienen dadas por el sentido del flujo de información. Si el afiliado desea entregar información a la bolsa sin ne-cesidad de la espera por una respuesta, invocará un servicio de notificación. Con-trariamente, si la información se genera en la BVC y debe ser conocida por los afi-liados, lo que se tendrá de cara a la BVC es un medio en el cual se almacenan los mensajes que deben ser informados; y de cara al afiliado se tiene un Web Service que debe ser invocado a discreción de la firma para acceder al medio (lo cual es transparente al consumidor) y obtener desde allí todos los mensajes cuyo destina-tario es la firma solicitante.

1.5.1.2. Aspectos de seguridad

La arquitectura del Bus de Integración incluye una capa de servicios de infraestructura para poder manejar los aspectos de seguridad que sean pertinentes. Esta capa se va a ubicar en-tre los afiliados y la plataforma de servicios de negocio. De esta manera, la capa de infraes-tructura enmascara los servicios implementados en el Bus de Integración, añadiéndoles los elementos de seguridad pertinentes. Particularmente en un modelo de integración entre so-cios (B2B), básicamente se busca garantizar los tres requerimientos a continuación:

Confidencialidad

La confidencialidad de los datos que se intercambian estará soportada sobre el estableci-miento de un canal seguro y privado. Para ello se cuenta con un aseguramiento de canal a dos niveles: primero, el canal es dedicado, no se utilizará la red pública para el intercambio de información entre la BVC y sus afiliados; segundo, el canal será cifrado usando SSL.

SSL proporciona privacidad de la información entre extremos sobre la red mediante el uso de criptografía. El protocolo permite a las aplicaciones cliente-servidor comunicarse de una

FORMATO Código :

Archivo:

Versión: 1.0


Página 28 de 141



forma diseñada para prevenir escuchas no autorizadas, la falsificación de la identidad del remitente y mantener la integridad del mensaje.

Un cliente usa SSL para cifrar un protocolo de transporte como HTTP. SSL crea un protocolo de transporte seguro cuando al menos una de las partes firma digitalmente data aleatoria con su respectiva clave privada. El protocolo HTTP se convierte en HTTPS y funciona como una tubería opaca que protege la confidencialidad de un mensaje que viaja por le red.

SSL implica una serie de fases básicas:

• Negociar entre las partes el algoritmo que se usará en la comunicación

• Intercambio de claves públicas y autenticación basada en certificados digitales

• Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

• Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algo-rithm) o Fortezza;

• Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Stan-dard);

• Con funciones hash: MD5 o de la familia SHA.

Autenticación

La capa de infraestructura provista por la BVC tendrá un servicio de autenticación que per-mitirá establecer una sesión del afiliado en la plataforma de servicios del Bus de Integra-ción. Con esta sesión establecida el afiliado podrá acceder a las funcionalidades de negocio necesarias y a las cuales está autorizado.

Este servicio de autenticación podría trabajar según dos enfoques:

• Autenticación clásica por usuario y clave

• Autenticación basada en certificados digitales y PKI.

SSL también provee autenticación de las partes. Habitualmente, sólo el servidor es autenti-cado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenti-car; la autenticación mutua requiere un despliegue de infraestructura de claves públicas (o PKI) para los clientes.

En el caso de la BVC, se establecería el esquema de mutua autenticación, en el cual el ser-vidor autentica al cliente y viceversa, mediante el uso de los certificados digitales respecti-vos.

En este tipo de autenticación, se usa una firma digital en un mensaje público de salida. Esta firma digital está basada en la llave de identidad del emisor del mensaje.

FORMATO Código :

Archivo:

Versión: 1.0


Página 29 de 141



Autorización

Se tendrán dos niveles de autorización a controlar:

• Acceso a los servicios, mediante roles y listas de acceso se controlará el conjunto de servicios a los cuales tiene derecho un consumidor en particular. Ello estará vali-dándose en la capa de infraestructura que hace de cara o frente hacia los afiliados u otros terceros.

• Acceso a la información a nivel de aplicativo para garantizar que un consumidor de servicios solamente actúa sobre los datos que le son permitidos. Para ello la identi-dad autenticada será propagada junto con el mensaje de solicitud al servicio de ne-gocio, de forma tal que la aplicación proveedora del servicio pueda validar si la transacción es lícita sobre esos datos por parte del consumidor específico.

1.5.2. Diseño de servicios Funcionales Los servicios diseñados para ser expuestos en la primera entrega del proyecto son:

MODULO SERVICIOS DESCRIPCION

S0001-Ingreso Automático de Ordenes El objetivo principal de este servicio es automati-zar la recepción de órde-nes a los sistemas de ne-gociación de la BVC, para que los afiliados puedan implementar Ingreso Au-tomático de órdenes con sus clientes.

S0106-Notificación de Ordenes El objetivo de este servi-cio es informar a los afi-liados, los movimientos (Ingreso, eliminación, modificación, calce) de una orden en el sistema de negociación.

NEGOCIACION

S0002-Notificación de Operaciones Después de calzadas las ordenes en los sis-temas de negociación, se informará a cada afiliado protagonista de la operación, el detalle de la transacción de renta fija (Mecplus), acciones y derivados y

FORMATO Código :

Archivo:

Versión: 1.0


Página 30 de 141



los registros en Inver-lace y divisas

Adicionalmente, se noti-ficará a todo el merca-do, cada novedad que se presente con las operaciones en los sis-temas de la BVC.

S0107-Notificación de Especies El objetivo de este servicio es informar a los afiliados, los movimientos (Crea-ción, activación, inactiva-ción, modificación) de una especie en el sistema de negociación.

S0015-Creación de Inversionistas Permite crear en forma automática los inversionis-tas en BVC

S0017-Complementación Automática Servicio que permite in-gresar o modificar la in-formación completa de la complementación de ope-raciones. En el caso que los beneficiarios no exis-tan, los crea directamente en BVC

COMPLEMENTACION

S0047-Notificación Papeleta de Opera-ciones

Envió a los afiliados de las información correspon-diente a la papeleta de liquidación de cada opera-ción y fracción

S0022-Notificación Inicio del Cumpli-miento

Este servicio facilita infor-marle al modulo de cum-plimiento el momento pre-ciso en el cual puede ini-ciar el proceso ante los deposito para cada una de las operaciones que desea cumplir

CUMPLIMIENTO

S0103-Notificación Estado del Cumpli-miento

Este servicio informa al afiliado, en una forma di-námica todo el movimien-to del cumplimiento o por

FORMATO Código :

Archivo:

Versión: 1.0


Página 31 de 141



petición puntual de una operación.

S0098-ModificacionOperacionDatosCumpli-miento

Este servicio permite realizar modificaciones de los datos de cum-plimiento (Fecha de cumplimiento, tipo de compensación, etc.),

S0018-ConsultaSaldoCuentaCompensacion

Este servicio es permitir a la firmas consultar el resumen de todos los saldos de sus cuentas de compensación

FORMATO Código :

Archivo:

Versión: 1.0


Página 32 de 141



1.5.2.1. Servicio de Ingreso Automático de Órdenes

1.5.2.1.1. Caracterización

Código y nombre del servicio

S0001 – Ingreso Automático de Ordenes

Objetivos del servicio

El objetivo principal de este servicio es automatizar la recepción (Ingreso y Elimi-nación) de órdenes al actual sistema de negociación de acciones de la BVC, para los afiliados que implementen el ingreso automático de órdenes con sus clientes

Características del servicio

Este servicio debe tener las siguientes características:

Característica Valor Comentarios

Sincrónico Si

Patrón Requerimiento / Res-puesta

El solicitante ingresa una orden y espera la respuesta con la identificación de la orden.

Capa BackOffice

Frecuencia Por evento entre 8am y 5pm

Necesidad entre-ga certificada

Si

Tamaño del men-saje

600 Bytes

Dependencia de la sesión

Si

Persistencia Si La respuesta debe ser entregada al soli-citante, así se caiga la conexión

FORMATO Código :

Archivo:

Versión: 1.0


Página 33 de 141



Consideraciones del servicio

Las siguientes son las consideraciones que se deben tener para este servicio:

Item Descripción

Información de entrada al servicio

El sistema de las firmas envía el ingreso de una orden en el sistema de negociación. Este mensaje se envía en formato FIXML. El servicio lo recibe y lo envía al traductor corres-pondiente para ser enviado en formato Trama al sistema de Negociación de la BVC.

Respuesta El Sistema de Negociación envía el identificador de la orden una vez se ha ingresado.

1.5.2.1.2. Diagrama de secuencia

El siguiente es el diagrama de secuencia para el servicio:

Actor Descripción

Solicitante El solicitante es cualquier aplicación que este en la capacidad de generar y contener el XML con la estructura y datos definidos para el servicio de Ingreso Automático de órdenes. (Afiliados)

BUS Es la plataforma encargada de recibir y enviar los mensajes hacia el sistema de negociación y el solicitante respectivamente. Además cumple con las ta-reas de procesamiento de información, transformación de datos, ejecución de reglas del negocio, encriptamiento, entre otras.

FORMATO Código :

Archivo:

Versión: 1.0


Página 34 de 141



Sistema de Negociación

El Sistema de negociación ingresa la orden en el mercado y devuelve la res-puesta con el identificador de la orden.

Las especificaciones de los mensajes y las reglas de transformación se encuentran detalladas en los formatos FOI que se relacionan a continuación y los XML y XSD utilizados:

BUS_EJ_FOI_FIXMLM001IngresoOrden BUS_EJ_FOI_FIXMLM004ConfirmacionOrden

Ejemplos archivos XML

M001_FIXML_Completo.xml M004-XML-Completo.xml

1.5.2.1.3. Proceso en el bus para el uso del servicio El proceso que debe ejecutar el BUS en la ejecucion de este servicio es el siguiente:

FORMATO Código :

Archivo:

Versión: 1.0


Página 35 de 141



1.5.2.1.4. Pasos del proceso

# Paso Tipo Pa-so

Descripción

1 Error de Validación? Condición Se verifica si el XML recibido cumple con el esquema y está correctamente formado.

2 Manejo de errores Proceso Se manejan los errores que se presenten.

3 Envío de Ingreso de Orden

Proces0 Se envía al sistema de negociación la orden para que sea ingresada en el mercado.

4 Esperar Respuesta de Sist. Negociación

Proceso Se espera que el sistema de negociación genere la respuesta correspondiente a

5 Se obtuvo respuesta? Condición Se revisa si se ha obtenido la respuesta por parte del sistema de negociación

6 Pasó más del tiempo máximo de espera?

Condición Se revisa q no haya pasado más del tiempo máximo de espera ( 30 segundos )

7 Envío confirmación de ingreso de Orden

Proceso Se envía al solicitante una respuesta que contiene el identificador de la orden, lo cual indica que ha sido ingresada correctamente en el sistema de negocia-ción.

8 Hubo errores? Condición Se verifica si se han presentado errores.

9 Envío de error Proceso Se envía al solicitante una respuesta que indica que se ha presentado un error.

1.5.2.1.5. Escenarios de prueba (Unitarias de desarrollo)

Escenario 1: Ingreso de Orden Exitosa

# 0001

Nombre de la prueba Ingreso de Orden Exitosa

Tipo de Operación

Tipo de Operaciones por pun-ta

Mercado

Numero Fracciones

Punta

Resultado Esperado Se envía exitosamente el identificador de la orden ingresada al afiliado

Descripción Paso Descripción Resultado esperado

FORMATO Código :

Archivo:

Versión: 1.0


Página 36 de 141



1 El sistema de Afiliado envía la orden.

2 El servicio envía la consulta al servicio de traducción FIXML – Trama para que realice las transformaciones necesarias.

El servicio de traduc-ción genera correcta-mente la TRAMA para enviar al BackOffice BVC.

3 Se envía la orden al sistema de nego-ciación.

4 El sistema de negociación envía res-puesta indicando el Id de la Orden.

5 El servicio envía la respuesta al servicio de traducción Trama - FIXML para que realice las transformaciones necesarias.

El servicio de traduc-ción genera correcta-mente el archivo FIXML para enviar al Afiliado.

Este escenario consiste en ingre-sar una orden de compra o venta en el sistema de negociación.

El Afiliado envía la orden. El BUS se encarga de tomarla, transfor-marla y enviarla al Sistema de negociación el cual envía una respuesta con el ID de la orden.

6 Se envía la respuesta con el ID de la orden al solicitante (Afiliado)

Escenario 2: Ingreso de Orden No Exitosa (XML Inválido)

# 0002

Nombre de la prueba Ingreso de Orden No Exitosa (XML Invalido)

Tipo de Operación

Tipo de Operaciones por pun-

ta

Mercado

Numero Fracciones

Punta

Resultado Esperado


1 El Afiliado envía la orden.

2 El servicio de determina que la in-

formación recibida es inválida.

Este escenario consiste en ingre-

sar una orden al sistema de ne-gociación pero se detecta un error en la validación.

Se envía al solicitante una res-puesta indicando el error.

3 El servicio genera la respuesta de

error y se la envía al solicitante.

Se genera un registro en el

log de errores

FORMATO Código :

Archivo:

Versión: 1.0


Página 37 de 141



Escenario 3: Ingreso de Orden No Exitosa (Se genera un error en recepción de respuesta)

# 003

Nombre de la prueba Ingreso de Orden No Exitosa (se genera un error en recepción de respuesta)

Tipo de Operación

Tipo de Operaciones por punta

Mercado

Numero Fracciones

Punta

Resultado Esperado


1 El sistema de Afiliado envía la orden.

2 El servicio envía la consulta al servicio de traducción FIXML – Trama para que realice las transformaciones necesarias.

El servicio de traducción genera correctamente la TRAMA para enviar al sistema de negociación.

3 Se envía la orden al sistema de negociación.

Se presenta un error en el proce-so recibir la respuesta con el ID de la orden.

4 Se espera un tiempo máxi-mo de 30 segundos por la respuesta del sistema de negociación.

Se generan alertas y logs de erro-res.

Escenario 4: Pruebas de Stress

# 0004

Nombre de la prueba Pruebas de Stress

Tipo de Operación


ta

Mercado

Numero Fracciones

FORMATO Código :

Archivo:

Versión: 1.0


Página 38 de 141



Punta

Resultado Esperado


Se realizan pruebas de carga que permitan verificar que el servicio cumple con los requerimientos del sistema: Capacidad de proce-samiento = 1500 mensajes por segundo y Volumen = 900000 bytes por segundo.

FORMATO Código :

Archivo:

Versión: 1.0


Página 39 de 141



1.5.2.2. Servicio de Notificación de Órdenes



S0106 – Notificación Órdenes


El objetivo de este servicio es informar a los afiliados, los movimientos (Ingreso, elimina-ción, modificación, calce) de una orden en el sistema de negociación de acciones actual.




Sincrónico Si

Patrón Notificación

Capa FrontOffice

Frecuencia 1500 por segundo De 8 am a 5 pm


Si


300 Bytes


No

Persistencia Si


Item Descripción

Información de entra-da al servicio

El servicio recibirá la información en FIXML

Respuesta No existe una respuesta asociada a este servicio.

FORMATO Código :

Archivo:

Versión: 1.0


Página 40 de 141





Actor Descripción para la prueba

BUS Es la plataforma encargada de enviar los mensajes desde el FrontOffice hacia los consumidores. Además cumple con las tareas de procesamiento de infor-mación, transformación de datos, ejecución de reglas del negocio, encripta-miento, entre otras.

Adaptador Conector

Este actor se encarga de recibir la información enviada por el sistema de nego-ciación y enviarla al servicio

Sistema de Negociación

Para el momento de realización de este documento, el sistema de negociación de acciones esta en el BackOffice, sin embargo en corto tiempo entrarán en funcionamiento otros sistemas de negociación

Front Office Firmas

Son las aplicaciones que hacen parte de las firmas y que estarán encargadas de recuperar los mensajes publicados por el servicio

Sistema de Negociacion Adaptador-Conector Servicio Notificacionde Ordenes

M001

M002

BUS

M002-FIXML-NotificacionOrdenes

M001-Trama-NotificacionOrdenes

Front Office Firmas

M002

FORMATO Código :

Archivo:

Versión: 1.0


Página 41 de 141



Las especificaciones del mensaje y las reglas de transformación se encuentran detalladas en el formato FOI que se relaciona a continuación y los XML y XSD utilizados:

BUS_EJ_FOI_FIXMLM002-NotificacionOrdenes


M002-FIXML-MensajeCompleto.xml



# Paso Tipo Paso Descripción

1 Recibir Mensaje de Notificación Orde-nes

Actividad Se encarga de recibir la información y asociarla al esquema de FIXML

2 Validar Información Actividad Valida que la información contenida en el mensa-je tenga los datos obligatorios.

3 Información Inváli-da

Condición Esta condición valida si los datos fueron o no vá-lidos.

FORMATO Código :

Archivo:

Versión: 1.0


Página 42 de 141




4 Insertar Registro en log de errores

Actividad Crea un nuevo registro en la base de datos pro-pietaria con la información del error. Si el error fue debido a datos inválidos no debe generar re-proceso, en caso contrario, es necesario publicar nuevamente el mensaje

5 Enviar Mensaje Actividad Publica el mensaje

6 Mensaje Enviado? Condición Valida si el mensaje fue publicado exitosamente


Escenario 1 : Mensaje con Datos Faltantes

# 0001

Nombre de la prueba Mensaje con Datos Faltantes

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado Registro creado en la tabla de errores


1 El servicio recibe un XML con datos faltantes

2 El servicio valida que todos los campos estén llenos.

Debe encontrar que existen datos faltantes

3 El servicio inserta un registro en la base de datos.

Un nuevo registro es creado en la tabla de Log, con la información del error

Este escenario consiste en recibir un XML con datos faltantes

FORMATO Código :

Archivo:

Versión: 1.0


Página 43 de 141



Escenario 2: Enviar Mensaje cuando el Destino no está dis-ponible

# 0002

Nombre de la prueba Enviar Mensaje cuando el Destino no está disponible

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado Registro en la tabla de errores y de reproceso.


1 El servicio recibe un mensaje con todos los campos obligatorios lle-nos.

2 El servicio intenta publicar el XML. El servicio no puede ser enviado porque el com-ponente de transporte no esta disponible

Consiste en recibir un men-saje XML válido pero el ser-vicio de transporte no esta disponible

3 El servicio registra el error y una actividad de reproceso

Un registro nuevo en la tabla de errores y re-torna un mensaje de error al solicitante

Escenario 3: Notificación enviada exitosamente

# 0003

Nombre de la prueba Notificación enviada exitosamente

Tipo de Operación

Tipo de Operaciones por

punta

Mercado

Numero Fracciones

Punta

Resultado Esperado FIXML publicado exitosamente

FORMATO Código :

Archivo:

Versión: 1.0


Página 44 de 141




1 El servicio recibe un mensaje FIXML con todos los campos llenos

2 El afiliado recibe la información de la orden publicada por el sistema de negociación.

El XML es enviado al soli-citante

Este escenario consiste en notificar exitosamente una orden a los afiliados

FORMATO Código :

Archivo:

Versión: 1.0


Página 45 de 141



1.5.2.3. Servicio de Notificación de Operaciones



S0002 – Notificación Operaciones


Después de calzadas las ordenes en los sistemas de negociación, se informará a ca-da afiliado protagonista de la operación, el detalle de la transacción de renta fija (Mecplus), acciones y derivados y los registros en Inverlace y divisas

Adicionalmente, se notificará a todo el mercado, cada novedad que se presente con las operaciones en los sistemas de la BVC.




Sincrónico No


Capa BackOffice

Frecuencia 500 por segundo De 8 am a 5 pm


Si


1530 Bytes


No

Persistencia Si

FORMATO Código :

Archivo:

Versión: 1.0


Página 46 de 141



Consideraciones


Item Descripción

Información de entrada al ser-vicio





FORMATO Código :

Archivo:

Versión: 1.0


Página 47 de 141




BUS Es la plataforma encargada de enviar los mensajes desde el BackOffi-ce hacia los consumidores. Además cumple con las tareas de proce-samiento de información, transformación de datos, ejecución de re-glas del negocio, encriptamiento, entre otras.

Adaptador Backoffice

Este proceso se encarga de transformar la trama en FIXML y enviarla al servicio

Sistema de negociación

Es el sistema que realiza la operación de calce. Para el momento de realización de este documento, el sistema de negociación es el Bac-kOffice.

Back Office Firmas

Son las aplicaciones que hacen parte de las firmas y que estarán en-cargadas de recuperar los mensajes publicados por el servicio

Las especificaciones del mensaje y las reglas de transformación se encuentran detalladas en el formato FOI que se relaciona a continuación y los XML y XSD utilizados:

BUS_EJ_FOI_FIXMLM002-Notificacion Calce BUS_EJ_FOI_FIXMLM003-Notificacion CalceResumido


M002-FIXML_MensajeCompletoAcciones M002_FIXML_MensajeCompletoContinuo M003_FIXML_MensajeCompletoSerializadas M003_FIXML_MensajeCompletoAccionesResumido M003_FIXML_MensajeCompletoContinuoResumido M003_FIXML_MensajeCompletoSerializadasResumido


FORMATO Código :

Archivo:

Versión: 1.0


Página 48 de 141





1 Recibir Mensaje de Notificación Opera-ción

Actividad Se encarga de recibir la información y asociarla al es-quema de FIXML

2 Validar Información Actividad Valida que la información contenida en el mensaje ten-ga los datos obligatorios. (La especificación de los da-tos obligatorios depende del tipo de mensaje.

3 Información Invalida Condición Esta condición valida si los datos fueron o no válidos.

FORMATO Código :

Archivo:

Versión: 1.0


Página 49 de 141





Actividad Crea un nuevo registro en la base de datos propietaria con la información del error. Si el error fue debido a datos inválidos no debe generar reproceso, en caso contrario, es necesario publicar nuevamente el mensa-je

5 Enviar Mensaje Actividad Publica el mensaje


7 Firma Comprador? Condición Valida el campo “Side” e identifica si el mensaje co-rresponde al afiliado.

8 Enviar Mensaje al mercado

Actividad Envía un mensaje resumido a todo el mercado. El mensaje resumido corresponde al M003.

1.5.2.3.5. Escenarios de prueba

Escenario 1: Mensaje con Datos Faltantes

# 0001


Tipo de Operación


Mercado

Numero Fracciones

Punta








Este escenario consiste en recibir un XML con datos faltantes

FORMATO Código :

Archivo:

Versión: 1.0


Página 50 de 141




# 0002


Tipo de Operación


Mercado

Numero Fracciones

Punta



1 El servicio recibe un mensa-je con todos los campos obligatorios llenos.

2 El servicio intenta publicar el XML.

El servicio no puede ser enviado porque el compo-nente de transporte no esta disponible

Consiste en recibir un mensaje XML válido pero el servicio de transporte no esta disponible


Un registro nuevo en la tabla de errores y retorna un mensaje de error al solicitante


# 0003


Tipo de Operación


ta

Mercado

Numero Fracciones

Punta


FORMATO Código :

Archivo:

Versión: 1.0


Página 51 de 141



Descripción Paso Descripción Resultado espe-rado

1 El servicio recibe un mensaje FIXML con todos los campos llenos

2 El afiliado recibe la información de una operación exitosamente

El XML es enviado al solicitante

Este escenario consiste en notifi-car exitosamente una Operacion

3

FORMATO Código :

Archivo:

Versión: 1.0


Página 52 de 141



1.5.2.4. Servicio de Notificaron de Especies



S0107 – Notificación de Especies


El objetivo de este servicio es informar a los afiliados, los movimientos (Creación, activa-ción, inactivación, modificación) de una especie en el sistema de negociación.




Sincrónico No


Capa BackOffice

Frecuencia Por Evento


Si


Bytes


No

Persistencia Si

FORMATO Código :

Archivo:

Versión: 1.0


Página 53 de 141





Item Descripción







BUS Es la plataforma encargada de enviar los mensajes desde el BackOffice hacia los consumidores. Además cumple con las ta-reas de procesamiento de información, transformación de da-tos, ejecución de reglas del negocio, encriptamiento, entre otras.

Adaptador Conector

Este actor se encarga de recibir la información enviada por el BackOffice y enviarla al servicio

BackOffice Sistema de la Bolsa de donde se notifican los cambios y modifi-caciones de las especies, que deben ser enviados a todas las firmas

Firmas Son las aplicaciones que hacen parte de las firmas y que estarán

FORMATO Código :

Archivo:

Versión: 1.0


Página 54 de 141



encargadas de recuperar los mensajes publicados por el servi-cio.

Las especificaciones de los mensajes y las reglas de transformación se encuentran detalladas en el formato FOI que se relaciona a continuación y los XML y XSD utilizados:

BUS_EJ_FOI_FIXMLM002-NotificacionEspecies

Ejemplo Archiv XML

M002-FIXML-NotificacionEspecie




1 Recibir Mensaje de Notificación Espe-cie

Actividad Se encarga de recibir la información y aso-ciarla al esquema de FIXML

2 Validar Información Actividad Valida que la información contenida en el mensaje ten-

ga los datos requeridos y necesarios para ejecutar todo el proceso, y concuerden con los estándares definidos.

FORMATO Código :

Archivo:

Versión: 1.0


Página 55 de 141




3 Información Inválida Condición Esta condición valida si los datos fueron o no válidos.


Actividad Crea un nuevo registro en la base de datos propietaria con la información del error. Si el error fue debido a datos inválidos no debe generar reproceso, en caso contrario, es necesario publicar nuevamente el mensa-je

5 Enviar Mensaje Actividad Publica el mensaje. Este mensaje debe llegar a todos los afiliados registrados para el servicio.




# 0001

Nombre de la prueba

Tipo de Operación


Mercado Todos

Numero Fracciones

Punta

Resultado Esperado Alarma al Administrador y Registro creado en la tabla de errores


1 El BO envía las trama de notificación especies

La trama es recibida por el adaptador-traductor trama-FIXML


En esta prueba consiste en que el BackOffice envía una trama de notifi-cación especie con alguno de los datos requeridos sin ningún valor. El servicio debe validar que se encuentren los datos requeridos y generar una alarma indicando el error. 3 El servicio valida que todos los campos

estén llenos. Debe encontrar que exis-ten datos faltantes

FORMATO Código :

Archivo:

Versión: 1.0


Página 56 de 141




Un nuevo registro es creado en la tabla de Log, con la información del error y genera una alerta administrativa


# 0002


Tipo de Operación


Mercado Todos

Numero Fracciones

Punta



1 El servicio recibe un mensaje con todos los campos obligatorios lle-nos.

2 El servicio intenta publicar el XML. El mensaje no puede ser enviado porque el compo-nente de transporte no esta disponible

Este escenario consiste en que el BO envía la notificación de una especie, correctamente y el servicio de nego-cio recibe un mensaje XML válido pero el servicio de transporte no esta dis-ponible.


Se crea un registro nuevo en la tabla de errores y se genera una alerta adminis-trativa.

FORMATO Código :

Archivo:

Versión: 1.0


Página 57 de 141




# 0003


Tipo de Operación


Mercado Todos

Numero Fracciones

Punta



1 El BO notifica que una especie se ha creado o modificado

2 El servicio recibe un mensaje FIXML con todos los campos de la especie y la publica

Este escenario consiste en notificar exitosamente una especie a los afilia-dos

3 Los afiliados registrados al servicio reciben la información de la especie publicada por el BO

El XML es enviado a los afiliados regis-trados para el servi-cio.

Escenario 4: Trama de Notificación de Especie Incorrecta

# 0004

Nombre de la prueba Trama de notificación de especie incorrecta

Tipo de Operación


Mercado Todos

Numero Fracciones

Punta

Resultado Esperado Alarma al Administrador


En esta prueba consiste en que el BackOffice envía una trama de

1 El BO envía las trama de notificación de especie

FORMATO Código :

Archivo:

Versión: 1.0


Página 58 de 141



notificación de especie con una longitud diferente a la estableci-da. El servicio debe validar la longitud de la estructura y gene-rar una alarma indicando el error.

2 La trama es capturada por el adaptador-traductor trama-FIXML, para realizar las transformaciones y en-viarlas al servicio de nego-cio.

El adaptador detecta un error en la longi-tud y genera una alarma al administra-dor

Escenario 5: Los datos de la trama no corresponden con el Esquema XML definido

# 0005

Nombre de la prueba Los datos de la trama no corresponden con el esquema XML definido

Tipo de Operación


Mercado Todos

Numero Fracciones

Punta



1 El BO envía las trama de notifica-

ción especie

Esta prueba consiste en que el Bac-

kOffice envía una trama de notifica-ción especie con un campo con un valor invalido (por ejemplo Ne-mo=1234567890XXX). El servicio valida que este valor no se permita para el campo y generar una alarma indican-do el error.

2 La trama es capturada por el adap-

tador-traductor trama-FIXML, para realizar las transformaciones y enviarlas al servicio de negocio.

El adaptador detecta un

error en los datos y gene-ra una alarma al admi-nistrador

FORMATO Código :

Archivo:

Versión: 1.0


Página 59 de 141



1.5.2.5. Servicio de Creación de Inversionistas



S0015 - Creación de Inversionistas


El objetivo principal de este proceso consiste en prestar el servicio de creación de un inversionista en el Back-Office de la BVC en forma automática




Sincrónico Si

Patrón Petición/Respuesta

Capa BackOffice



Si


680 Bytes


No

Persistencia No

FORMATO Código :

Archivo:

Versión: 1.0


Página 60 de 141





Item Descripción



Respuesta Si fue posible crear o no el inversionista



Solicitante Servicio - Creacion Inversionista Traductor Back Office

M001

M002

BUS

Back Office

M001

M003

M004

M004

FORMATO Código :

Archivo:

Versión: 1.0


Página 61 de 141




BUS Es la plataforma encargada de recibir y enviar los men-sajes desde el BackOffice hacia los solicitantes (Afilia-dos). Además cumple con las tareas de procesamiento de información, transformación de datos, ejecución de reglas del negocio, encripción, entre otras.

Traductor Bac-koffice

Este proceso se encarga de transformar los mensajes enviados desde y hacia el Back Office.

BackOffice El BackOffice de la BVC está sobre un HP NonStop.

Solicitante El solicitante son los afiliados que intercambian informa-ción con el BUS


BUS_EJ_FOI_FIXMLM001.XLS BUS_EJ_FOI_FIXMLM004.xls


M001-FIXML-Completo.xml M004-FIXML-Completo.xml


FORMATO Código :

Archivo:

Versión: 1.0


Página 62 de 141





1 Recibir Mensaje de Actualización de Creación de inver-sionista

Actividad Se encarga de recibir la información y aso-ciarla al esquema de FIXML

2 Verificar Informa-ción

Actividad Valida que la información contenida en el mensaje tenga los datos obligatorios (To-dos los campos son obligatorios).

3 Información Invali-da

Condición Esta condición valida si los datos fueron o no válidos.


Actividad Crea un nuevo registro en la base de datos propietaria con la información del error. Este mensaje no debe generar registros de reproceso.

5 Enviar Mensaje Actividad Debe enviar el mensaje al back office

FORMATO Código :

Archivo:

Versión: 1.0


Página 63 de 141




6 Mensaje Enviado? Condición Valida si el mensaje fue enviado exitosa-mente

7 Esperar Respuesta Actividad Debe esperar una respuesta por parte del back office que indique que el inversionista fue creado exitosamente o no.

8 Retornar Respuesta Actividad Independientemente si la respuesta fue afirmativa o se genero un error, debe en-viarse el proceso solicitante.

9 Respuesta Exitosa Condición Si la respuesta no fue exitosa, será nece-sario crear un registro en la tabla destina-do para ello.

10 Consultar BD Única Actividad Esta actividad consulta si el inversionista que se intenta crear, existe con anteriori-dad.

11 Inversionista En-contrado

Condición En esta condición se pregunta si efectiva-mente fue encontrado un inversionista con las características de la búsqueda.



# 0001


Tipo de Operación


Mercado

Numero Fracciones

Punta



Este escenario consiste en recibir un XML en formato

1 El servicio recibe un mensaje FIXML con algún dato faltante

FORMATO Código :

Archivo:

Versión: 1.0


Página 64 de 141







FIX con datos faltantes.


# 0002


Tipo de Operación


Mercado

Numero Fracciones

Punta



1 El servicio recibe un mensaje con todos los campos obligatorios llenos.

2 El servicio intenta pu-blicar el XML.

El servicio no puede ser en-viado porque el componente de transporte no esta dis-ponible

Consiste en recibir un mensa-je XML válido pero el servicio de transporte no esta dispo-nible


Un registro nuevo en la ta-bla de errores y retorna un mensaje de error al solici-tante

FORMATO Código :

Archivo:

Versión: 1.0


Página 65 de 141



Escenario 3: Creación exitosa de inversionista

# 0003

Nombre de la prueba Creación Exitosa de inversionista

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado FIXML de respuesta exitosa.


1 El servicio recibe un mensaje FIXML con todos los campos lle-nos

2 Se busca el inversionista en la base de datos unica

Este escenario consiste en crear exitosamente un inversionista

3 El solicitante recibe la informa-ción de una creación exitosa del inversionista

El XML es enviado al solicitante

Escenario 4: XML inválido

# 0004

Nombre de la prueba XML Inválido

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado XML Inválido


FORMATO Código :

Archivo:

Versión: 1.0


Página 66 de 141



1 El servicio recibe un mensaje inválido Registro en la tabla de errores y mensa-je de respuesta al solicitante con de-talle del error

En este escenario se valida que el servicio pueda manejar XML que no cumplan con el esquema FIXML y que estén incompletos

2

FORMATO Código :

Archivo:

Versión: 1.0


Página 67 de 141



1.5.2.6. Servicio de Complementación de Operaciones



S0017- Complementación de la operación


Cuando un afiliado desea comprar o vender un titulo o especie, genera una oferta (sea de compra o de venta) que es colocada en el sistema de negocia-ción de la BVC. Una vez esta oferta encuentra alguna otra en el sistema de negociación que con la cual concuerde, se genera el calce y se genera una operación de bolsa. Esta operación tiene solo la información básica, por lo cual el paso siguiente consiste en complementarla, tanto por la punta de ventas, como por la punta de compra. Este proceso consiste en enviar la información relacionada con inversionistas, comisiones, impuestos, etc; para que después la operación pueda ser liquidada.

Especificaciones TécnicasServicio

S0017- Complementación de la operaciónPágina : de

Versión:

Fecha:

0.9

BVC

NEGOCIACIÓN

COMPLEMENTACIÓN

LIQUIDACIÓN

OFERTACOMPRA

OFERTAVENTA

OPERACIÓN SINCOMPLEMENTAR

OPERACIÓNCOMPLEMENTADA

DATOSCOMPLEMENTACIÓN

PUNTA COMPRA XFRACCION

DATOSCOMPLEMENTACIÓN

PUNTA VENTA XFRACCION

DATOS DELIQUIDACIÓN PUNTA

COMPRA X FRACCION

DATOS DELIQUIDACIÓN PUNTAVENTA X FRACCION

AFILIADOAFILIADO

Op 00001 Op 00001

FORMATO Código :

Archivo:

Versión: 1.0


Página 68 de 141



El objetivo principal de este servicio es poder permitir que se realice la complementación de una punta de una operación (desde 1 hasta 99 fracciones), recibiendo la información necesaria desde cualquier solicitante y entregándola al BackOffice de la BVC para que se realice la complementación. Finalmente debe informar al solicitante si se realizo correc-tamente la complementación o hubo algún error durante el proceso.




Sincrónico Si

Patrón Requerimiento / Respuesta

El solicitante envía las fracciones a com-plementar y espera la confirmación de si el proceso fue aprobado o no

Capa BackOffice

Frecuencia Por evento


Si


17000 bytes

Depende de la sesión

No

Si el solicitante, pierde la sesión en la mitad del proceso, este debe terminar correctamente y guardar la respuesta en un medio persistente, para entregár-selo posteriormente al solicitante

Persistencia Si La respuesta debe ser entregada al soli-citante, así se caiga la conexión

FORMATO Código :

Archivo:

Versión: 1.0


Página 69 de 141



Consideraciones


Item Descripción


El XML recibido por el servicio, contiene la información de una o varias fracciones a complementar, por lo que el BUS deberá descomponer ese XML y enviar fracción por fracción al BackOf-fice, ya que la trama dispuesta para este proceso solo envía una fracción al tiempo a complementar

Errores En el caso de que una de las fracciones no se complemente correctamente se deberá volver a enviar la complementación de todas las fracciones desde el solicitante. Es decir, si se manda un archivo XML con 10 fracciones pero al enviar al BackOffice la fracción número 5 devuelve un error, el BackOf-fice no procesará la operación del todo y por lo tanto, al solu-cionarse el problema para la fracción número 5, deberán en-viarse a complementar nuevamente todas las fracciones. Se entregara al solicitante un listado con todos los errores encon-trados durante le proceso para que estos sean corregidos.

Errores Al enviar a complementar varias fracciones, el proceso debe enviar todas las fracciones al BO aun cuando se genere un error, para capturar todos los posibles errores en las diferen-tes fracciones y enviarlos al solicitante, para que los corrija todos y en su siguiente intento tenga éxito.

Respuesta La respuesta de si la complementación fue aceptada o recha-zada en el BackOffice de la BVC en entregada fracción por fracción, por lo que el BUS deberá agruparlas para dar un solo mensaje al solicitante.

Procesamiento El servicio de complementación debe llamar al servicio de ad-ministración de inversionista para la consulta.

Error Si al momento de consultar un inversionista este se encuentra en estado invalido, se debe generar un error que será reporta-do en el XML de rechazo, junto a los otros errores que devol-viera el BO en caso de que existieran.

FORMATO Código :

Archivo:

Versión: 1.0


Página 70 de 141




El siguiente es el diagrama de secuencia para el servicio de complementación de la opera-ción:


BUS_EJ_FOI_FIXMLM001DatosCompl BUS_EJ_FOI_FIXMLM004RechAcepCompl

Ejemplos Archivos XML

M001-FIXML-DatosComplementacion.xml M001-FIXML-DatosComplFracciones.xml M004-FIXML-Respuesta.xml M004-FIXML-RespuestaFracciones.xml

Loop:fraccion <= Total Fracciones

Solicitante Servicio Complementacion BackOficce

M001_FIXML_Datos compl

M003_Trama_Rechazo/Acep Compl x Fraccion

M004_FIXML_Rech/Acep Compl

Servicio Traduccion XML-Trama

M001_FIXML_Datos Compl

M002_Trama_Datos compl por fraccion

M004_FIXML_Rech/Acep Compl

BUS

M000_FIXML_Ack

FORMATO Código :

Archivo:

Versión: 1.0


Página 71 de 141




FORMATO Código :

Archivo:

Versión: 1.0


Página 72 de 141





1 Recepción datos complementación

Transformación de Datos

En este paso el BUS se encarga de recibir los da-tos del solicitante necesarios para la complemen-tación (el XML debera tener la información de todas las fracciones a complementar), y aplicarle las reglas de transformación necesarias para en-viarlo como trama al BackOffice (Explicadas en los FPOI). Además captura los campos necesa-rios de la estructura para realizar la validación de inversionistas. Es importante aclarar que se tiene como premisas que las operaciones deben estar previamente registradas en le BackOffice y que el mensaje enviado por el solicitante contiene todas las fracciones asociadas con la operación.

2 Validación de Datos Validacion En este paso el proceso se encarga de validar que los datos recibidos estén correctos y que los campos que son requeridos para el proceso se encuentren correctamente diligenciados.

3 Manejo Error En caso de que hubiera algún error en los datos de entrada al proceso, el manejo de error debe generarle un error al solicitante para que corrija los datos y envié nuevamente la solicitud.

4 Hubo Errores? Condición Esta condición valida que en el proceso se hubie-ra generado algún error

5 Enviar Datos Com-plementación BO x Fracción

Regla Negocio Este paso se encarga de enviar al BackOffice fracción por fracción a complementar

6 Compl. Aceptada? Condición Si la complementación de una fracción se efectúa correctamente se continúa con el paso 6. Si la complementación de una fracción es rechazada por el BackOffice, salta al paso 7.

7 Enviadas todas las fracciones?

Condición Este paso valida que ya se hubieran enviado to-das las fracciones de una operación. En caso de que falten se regresa al paso 4 para enviar a complementar la siguiente fracción. Cuando es una operación entera (no fraccionada) solo se envía un mensaje de complementación.

FORMATO Código :

Archivo:

Versión: 1.0


Página 73 de 141




8 Adición log de erro-res

Regla de Ne-gocio

Este paso se encarga de ir armando el log de errores con todos los posibles problemas que den en la creación de los inversionistas y en la com-plementación de cada una de las fracciones para entregarlo finalmente unificado al solicitante. Es-tos errores se deben registrar también en el log de errores del BUS.

9 Generación XML con Aceptación complementación

Regla de Ne-gocio

Este paso se encarga de generar el XML con el mensaje de complementación exitosa

10 Generación XML con listado de erro-res

Regla de Ne-gocio

Este paso se encarga de generar el XML con el listado de los errores encontrados durante la creación y consulta de inversionistas, y durante la complementación de cada una de las fraccio-nes.

Excepciones y Rutas alternas del proceso

A continuación se presentan las excepciones y rutas alternas que puede tomar el proceso:

# Nombre Tipo Descripción

1 BackOffice Fuera de línea

Excepción Si el BackOffice se encuentra fuera de línea el servicio debe guardar el mensaje, hasta que pueda mandarlo y dar respuesta al solicitante

2 No llega respuesta del BackOffice

Excepción El servicio debe generar una alerta administrati-va, indicando que ha pasado mas de 2 minutos, sin tener respuesta de la fracción enviada a complementar, para que sea revisado

3 Se cae el servicio en el mitad del proceso

Excepción Una vez se levante el servicio, este debe conti-nuar, en el paso que iba.

FORMATO Código :

Archivo:

Versión: 1.0


Página 74 de 141




Escenario 1: Complementación Exitosa # 0001

Nombre de la prueba Complementación Exitosa

Característica Operación Entera, fraccionada, convenida, cruzada

Tipo de Operaciones Normal(Carrusel/Swap), Repo, Simultaneas, Plazo

Mercado Acciones y Renta Fija

Numero Fracciones

Punta Compra y Venta

Resultado Esperado XML con la aceptación de la complementación


1 El solicitante ejecuta el servicio de com-plementación enviando el XML con todos los datos necesarios para complementar la punta de venta.

Se debe iniciar la ejecución del servicio

2 El servicio de complementación debe invo-car al servicio de “Administración de Inver-sionista” para realizar la consulta de los inversionistas asociados en las diferentes fracciones que se van a complementar y en caso de no existir, debe crearlos.

Todos los inversionistas de-ben estar creados correcta-mente

3 El servicio debe descomponer el XML frac-ción por fracción para enviarlo al BackOffi-ce de la BVC.

4 Envió de cada fracción al BackOffice de la BVC

Todas las fracciones debe ser recibidas por el BackOffice

5 Procesamiento de la complementación en el BackOffice de la BVC

El BackOffice debe realizar la complementación de todas las fracciones y no se debe generar ningún error.

Este escenario consiste en realizar la complementación tanto de la punta de compra como la punta de ventas de una operación ya sea entera o fraccionada. El solici-tante ejecutara el servicio de complementación, para lo que enviara el XML con la información correspondiente. Luego el BUS deberá realizar las validaciones, enviar a complementar las frac-ciones una a una y una vez se complementen en el BackOffice, recibir los datos de aceptación de la complementación para generar el XML con el mensaje respectivo.

6 Envió de la aceptación de la complementa-ción del BackOffice de la BVC hacia el BUS, fracción por fracción.

El Bus debe recibir todas las aceptaciones de complemen-tación de cada una de las fracciones.

FORMATO Código :

Archivo:

Versión: 1.0


Página 75 de 141



7 Recepción de la aceptación fracción por fracción y generación del XML con el men-saje de complementación exitosa

Generación del XML con la respuesta de aceptación, ya que todas las fracciones se complementaron correcta-mente.

8 Envió del XML con el mensaje de acepta-ción al solicitante

9 Se debe repetir todos los pasos para la punta de compra

Escenario 2: Complementación no exitosa

# 0002

Nombre de la prueba Complementación no exitosa




Numero Fracciones

Punta Compra



1 El solicitante ejecuta el servicio de

complementación enviando el XML con todos los datos necesarios para complementar la punta de compra.

Se debe iniciar la ejecución del servicio Este escenario consiste en en-

viar la complementación de una punta de compras de una ope-ración ya sea entera o fraccio-nada que no se complemente por algún error generado en el BackOffice al tratar de com-plementar, como que la opera-ción no exista, o no exista la especie, que el inversionista se encuentre en un estado invali-do, etc. El servicio debe enviar todas las fracciones al BackOffi-ce y recibir los posibles errores para armar un XML con el re-sumen de todos los errores encontrados durante el proceso

2 El servicio de complementación debe

invocar al servicio de “Administración de Inversionista” para realizar la con-sulta de los inversionistas asociados en las diferentes fracciones que se van a complementar y en caso de no existir, debe crearlos.

Se deben crear en el BackOffice los

inversionistas que se encuentren de-ntro de las fracciones a complementar que no existan. Si uno de los inversio-nistas se encuentra en un estado inva-lido se debe capturar el error para ser enviado con el resto de errores encon-trados al enviar la complementación. Si no se puede establecer conexión con el BO, se debe parar el proceso y enviar un error al solicitante para que intente mas tarde, generando un log para el administrador.

FORMATO Código :

Archivo:

Versión: 1.0


Página 76 de 141



3 El servicio debe descomponer el XML fracción por fracción para enviarlo al BackOffice de la BVC.


Todas las fracciones debe ser recibidas por el BackOffice. Si no se puede esta-blecer conexión con el BO, se debe parar el proceso y enviar un error al solicitante para que intente mas tarde, generando un log para el administra-dor.


El BackOffice debe enviar los errores de las fracciones que no pudo com-plementar por algún problema.

6 Envió de la los errores del BackOffice de la BVC hacia el BUS, fracción por fracción.

El Bus debe recibir todas las acepta-ciones de complementación de cada una de las fracciones.

7 Recepción de los errores fracción por fracción y generación del XML con el listado de errores

Generación del XML con los errores de las fracciones que fallaron.

de complementación.

8 Envió del XML con los mensajes de error al solicitante

Escenario 3: Carácter especial en el XML

# 0003

Nombre de la prueba Carácter especial en el XML




Numero Fracciones

Punta Compra



Este escenario consiste en enviar

un XML con la información de una punta de compras, con algunos caracteres especiales. La com-

1 El solicitante ejecuta el servicio de com-

plementación enviando el XML con todos los datos necesarios para complementar la punta de compra.

Se debe iniciar la ejecución del

servicio

FORMATO Código :

Archivo:

Versión: 1.0


Página 77 de 141



2 El servicio de complementación debe invo-car al servicio de “Administración de Inver-sionista” para realizar la consulta de los inversionistas asociados en las diferentes fracciones que se van a complementar y en caso de no existir, debe crearlos.

Se deben crear en el BackOffice los inversionistas que se en-cuentren dentro de las fraccio-nes a complementar que no existan.

3 El servicio debe descomponer el XML frac-ción por fracción para enviarlo al BackOffi-ce de la BVC.




El BackOffice debe enviar los errores de las fracciones que no pudo complementar por algún problema.

6 Envió de la aceptación de la complementa-ción del BackOffice de la BVC hacia el BUS, fracción por fracción.

El Bus debe recibir todas las aceptaciones de complementa-ción de cada una de las fraccio-nes.

7 Recepción de la aceptación fracción por fracción y generación del XML con el men-saje de complementación exitosa

Generación del XML con la res-puesta de aceptación, ya que todas las fracciones se com-plementaron correctamente.

plementación debe terminar co-rrectamente


Escenario 4: Complementación de una punta manual y la otra por trama

# 0004

Nombre de la prueba Complementación punta manual y trama




Numero Fracciones




FORMATO Código :

Archivo:

Versión: 1.0


Página 78 de 141



1 Complementar Manualmente la punta de venta

La complementación debe eje-cutarse correctamente. No debe llegar al BUS ninguna informa-ción relacionada a la comple-mentación de esta punta.

2 El solicitante ejecuta el servicio de com-plementación enviando el XML con todos los datos necesarios para complementar la punta de compra.

Se debe iniciar la ejecución del servicio

3 El servicio de complementación debe invocar al servicio de “Administración de Inversionista” para realizar la consulta de los inversionistas asociados en las dife-rentes fracciones que se van a comple-mentar y en caso de no existir, debe crearlos.

Se deben crear en el BackOffice los inversionistas que se en-cuentren dentro de las fraccio-nes a complementar que no existan.

4 El servicio debe descomponer el XML fracción por fracción para enviarlo al BackOffice de la BVC.




El BackOffice debe enviar los errores de las fracciones que no pudo complementar por algún problema.

7 Envió de la aceptación de la complemen-tación del BackOffice de la BVC hacia el BUS, fracción por fracción.

El Bus debe recibir todas las aceptaciones de complementa-ción de cada una de las fraccio-nes.

8 Recepción de la aceptación fracción por fracción y generación del XML con el mensaje de complementación exitosa

Generación del XML con la res-puesta de aceptación, ya que todas las fracciones se comple-mentaron correctamente.

Este escenario consiste en realizar la complementación de las dos puntas de una operación. Una en forma manual (es decir como se complementa actualmente) y la otra por medio de la ejecución del servicio de complementación. La complementación de la punta que se complemento por el servicio, se debe ejecutar correctamente. Para este escenario la punta de venta se debe complementar ma-nualmente y la de compra por el servicio


FORMATO Código :

Archivo:

Versión: 1.0


Página 79 de 141



Escenario 5: Mensaje XML no corresponden con el Esquema XSD definido

# 0005

Nombre de la prueba Los datos del mensaje XML no corresponden con el esquema XSD definido




Numero Fracciones

Punta Compra

Resultado Esperado XML con error del Esquema


1 El solicitante ejecuta el servicio de comple-mentación enviando el XML con un campo que no se encuentre dentro del esquema

Se debe generar un error del esquema

Este escenario consiste en enviar un XML con la información de una punta de com-pras, con un campo que no exista en la definición de esquema. El BUS debe re-tornar el error generado.

Escenario 6: Datos Requeridos Incompletos

# 0006

Nombre de la prueba Datos requeridos incompletos




Numero Fracciones

Punta Compra

Resultado Esperado XML con error del Esquema


1 El solicitante ejecuta el servicio de

complementación enviando el XML con un campo requerido sin ningún valor o con un valor que no corres-ponda

Se debe generar un

error de validación de datos.

Este escenario consiste en enviar un XML

con la información de una punta de com-pras, con un campo requerido sin ningún valor o con un valor que no corresponda. El BUS debe retornar el error generado.

FORMATO Código :

Archivo:

Versión: 1.0


Página 80 de 141



1.5.2.7. Servicio de Notificación de Papeleta



S0047- Notificación de Papeleta


El objetivo principal de este servicio es permitir a la BVC notificar todos los datos de la papeleta por punta

Así, este servicio tiene como precondición que el proceso de comple-mentación hubiera terminado exitosamente con las dos puntas de una operación (punta de venta y punta de compra), para que mediante es-te servicio se envíen de todas las fracciones la información de la pape-leta a cada uno de los afiliados participes de la operación, donde se en-tregaran datos como montos, comisiones, impuestos, totales liquida-dos, etc.




Sincrónico Si

Patrón Notificación El BO de la BVC cada vez que detecta que se complementaron exitosamente las dos puntas de la operación, envía la notificación con los datos de liquidación a los afiliados dueños de la operación.

Capa BackOffice



Si


700 Bytes

Persistencia Si

Consideraciones

FORMATO Código :

Archivo:

Versión: 1.0


Página 81 de 141




Item Descripción


El servicio debe recibir la información de la liquidación para todas las fracciones de la operación y con esta ge-nerar un solo XML que le será entregado al afiliado co-rrespondiente. Debe esperar a que le llegue la informa-ción de todas las fracciones.

Salida del ser-vicio

El servicio debe garantizar la entrega de la información al afiliado correspondiente

BackOffice Es responsabilidad del BackOffice entregar la información de liquidación de todas las fracciones.

1.5.2.7.2. Diagrama de secuencia El siguiente es el diagrama de secuencia para el servicio de liquidación de la ope-ración:

FORMATO Código :

Archivo:

Versión: 1.0


Página 82 de 141



Las especificaciones del mensaje y las reglas de transformación se encuentran de-talladas en el formato FOI que se relacionan a continuación y los XML y XSD utili-zados:

BUS_EJ_FOI_FIXMLM002DatosPapeleta

Ejemplo Archivos XML

M002-FIXML-DatosPapeleta.xml

M002-FIXML-DatosPapeleta99.xml


Espera yrecepcion Datos

Liquidacion xFraccion

Inicio

No

Recibidastodas las

Fracciones?

Generación XML conla informacion de

liquidacion de todaslas fracciones

FIN

Si

Guardar DatosLiquidación

Fracción

Notificacion Mensaje

Manejo Error

Hubo Error?

Si

No

Validacion Datos Hubo Error? Manejo ErrorSi

No

FORMATO Código :

Archivo:

Versión: 1.0


Página 83 de 141





1 Espera y re-cepción datos liquidación x fracción

Entrada En este paso el servicio debe escuchar y recibir los XMLs con la información de liquidación por fracción. Debe agru-parlos por Folio, Fecha de la operación y Afiliado. El campo TotNoAllocs indica el número total de fracciones para esa operación que se deben esperar antes de que pueda pa-sarse a la generación del XML. La información de cada fracción debe estar contenida por el BUS para que se pue-da generar el XML de salida con toda la información reque-rida. En caso de que pasen mas de 2 minutos desde el en-vió de la primera fracción y no se hubiera recibido el total de las fracciones se debe generar una alerta al rol definido por la BVC.

2 Validación de datos

Validación En este paso el proceso valida que todos los datos recibi-dos por el proceso estén correctos y que los campos re-queridos estén diligenciados.

3 Guardar Datos Liquidación Fracción

Procesa-miento

El BUS debe guardar la información de cada fracción para después de recibir todas las fracciones poder agruparla y generar el XML completo.

4 Recibidas to-das las frac-ciones

Condicional Luego se valida si el BO ha enviado toda la información de liquidación para las fracciones de la operación. Es decir si el numero de fracciones recibidos para una operación es igual a TotNoAllocs, Si no, sigue esperando por las fraccio-nes restantes, de lo contrario pasa al siguiente paso.

5 Generación XML con la in-formación de todas las frac-ciones

Procesa-miento

Una vez recibe todas las tramas con la información de la liquidación para todas las fracciones, genera un XML con dicha información agrupada según el FOI indicado.

6 Envío Notifica-ción

Envío Esta caja se encarga de notificarle al afiliado respectivo, el XML con toda la información de la liquidación de todas las fracciones.

7 Hubo Error? Condición Detecta si al realizar el envió se genero algún error.

8 Manejo Error Error Si hubo error esta caja se debe encargar de generar un log, alertar al administrador y guardar el mensaje para después republicarlo si es el caso.

FORMATO Código :

Archivo:

Versión: 1.0


Página 84 de 141



1.5.2.7.5. Escenarios de prueba (Unitarias de desa-rrollo)

Escenario 1: Entrega liquidación una fracción

# 0001

Nombre de la prueba Entrega liquidación una fracción

Tipo de Operación Convenida o cruzada

Tipo de Operaciones por

punta

Entera

Mercado Acciones

Numero Fracciones


Resultado Esperado XML con la liquidación de la fracción

Descripción Pa-

so

Descripción Resultado esperado

1 El BO envía la trama de liqui-

dación una vez termina exi-tosamente el proceso de complementación

2 El BUS recibe la trama y

realiza reglas de transforma-ción

3 El BUS genera el XML

En este escenario el BO de

la BVC después de com-plementar exitosamente una operación con una sola fracción, envía la in-formación de liquidación para cada una de las pun-tas. El bus debe escuchar la trama con la informa-ción de la liquidación y luego generar el XML con la información recibida.

4 El BUS envía el XML al solici-

tante

XML con la información de la

liquidación, con la especifica-ción contenida en el FOI “PL_FOI_S0047_v0.9_20070625_M002_FIXML_Datos liquidacion.xls”

FORMATO Código :

Archivo:

Versión: 1.0


Página 85 de 141



Escenario 2: Entrega liquidación varias fracciones

# 0002

Nombre de la prueba Entrega liquidación varias fracciones



Fraccionada

Mercado Acciones

Numero Fracciones 10

Punta Compra y venta

Resultado Esperado XML con la información de liquidación de todas las fracciones

Descripción Pa-so


1 El BO envía las trama de liquida-ción una vez termina exitosamen-te el proceso de complementación

2 El BUS recibe y espera todas las tramas asociadas a la operación y realiza reglas de transformación

3 El BUS genera el XML con la in-formación de todas las fracciones relacionadas a la operación

En este escenario el BO de la BVC después de complementar exito-samente una operación con una sola fracción, envía la información de liquidación para cada una de las puntas. El bus debe escuchar la trama con la información de la liquidación y luego generar el XML con la información recibida.

4 El BUS envía el XML al solicitante XML con la informa-ción de la liquidación, con la especificación contenida en el FOI

FORMATO Código :

Archivo:

Versión: 1.0


Página 86 de 141



Escenario 3: Entrega liquidación varias fracciones varias operaciones

# 0003

Nombre de la prueba Entrega liquidación varias fracciones varias operaciones



Entera y fraccionada

Mercado Acciones

Numero Fracciones

Punta Compra



1 El BO envía las trama de liquidación una vez termina exitosamente el proceso de complementación, de dife-rentes operaciones al mismo tiempo.

2 El BUS recibe, espera y agru-pa todas las tramas por ope-ración y punta y realiza re-glas de transformación

3 El BUS genera los diferentes XML con la información de todas las fracciones relacio-nadas a cada punta de cada operación, que se envió con-currentemente

En esta prueba se com-plementan varias opera-ciones con varias fraccio-nes al mismo tiempo, para que se genere información de liquidación de diferentes operaciones concurrente-mente. El bus debe agru-par correctamente la in-formación de la liquidación para cada operación y afi-liado, y generar los XML pertinentes.

4 El BUS envía los diferentes XML a los receptores relacio-nados en las puntas de las diferentes operaciones.

XMLs con la información de la liquidación para cada punta de cada operación, con la especifica-ción contenida en el FOI

FORMATO Código :

Archivo:

Versión: 1.0


Página 87 de 141



Escenario 4: Alarma por retraso en la entrega de to-da la información de liquidación

# 0004

Nombre de la prueba Generación de alarma por retraso en la entrega de toda la información de liquidación



fraccionada

Mercado Acciones

Numero Fracciones 10

Punta Compra


Descripción Paso Descripción Resultado

esperado

1 El BO envía las trama de liquidación una

vez termina exitosamente el proceso de complementación, de una operación fraccionada, menos una de las fraccio-nes

2 El BUS recibe, espera y agrupa todas las

tramas por la operación, faltándole una por recibir.

En esta prueba consiste en que el

BackOffice inicie el envió de la información de liquidación para una operación fraccionada, pero le quede faltando una fracción. Después de 2 minutos, el Bus debe generar una alerta indicán-dole al administrador del error para que se tomen las medidas correspondiente, procedimental-mente.

3 Después de 2 minutos se genera una

alarma indicándole al administrador del retrazo de la información

Generación de

alarma al adminis-trador

FORMATO Código :

Archivo:

Versión: 1.0


Página 88 de 141



Escenario 5: Trama de liquidación Incorrecta

# 0005

Nombre de la prueba Trama de liquidación Incorrecta



Entera

Mercado Acciones

Numero Fracciones 1

Punta Compra



1 El BO envía las trama de liquidación Generación de alarma al administrador

En esta prueba consiste en que el BackOffice envía una trama de liquidación con una longitud dife-rente a la establecida. El servicio debe validar la longitud de la estructura y generar una alarma indicando el error.


# 0006




Entera

Mercado Acciones

Numero Fracciones 1

Punta Compra



En esta prueba consiste en que el BackOffice envía una trama de

1 El BO envía las trama de liqui-dación

Generación de alarma al administrador

FORMATO Código :

Archivo:

Versión: 1.0


Página 89 de 141



liquidación con alguno de los datos requeridos sin ningún va-lor. El servicio debe validar que se encuentren los datos requeri-dos y generar una alarma indi-cando el error.

Escenario 7: Datos no corresponden con el Esquema XML

# 0007

Nombre de la prueba Los datos de la trama no corresponden con el esquema XML definido



ta

Entera

Mercado Acciones

Numero Fracciones 1

Punta Compra



1 El BO envía las trama de liqui-

dación

Generación de alarma al

administrador

Esta prueba consiste en que el

BackOffice envía una trama de liquidación con un campo con un valor invalido (por ejemplo Side = Z). El servicio valida que este valor no se permita para el cam-po y generar una alarma indican-do el error.

FORMATO Código :

Archivo:

Versión: 1.0


Página 90 de 141



1.5.2.8. Servicio de Notificación Inicio del Cumplimiento



S0022 – Notificación Inicio de Cumplimiento


El objetivo principal de este servicio es que cada firma, autorice a la BVC para dar inicio del proceso de cumplimiento con los depósitos por cada operación. Este servicio automatiza el proceso que hoy en día se realiza en forma manual.




Sincrónico Si

Patrón Requerimiento / Res-puesta

El solicitante envía las la notificación de inicio de cumplimiento y espera la confirmación de si el proceso fue exi-toso o no.

Capa BackOffice



Si


100 Bytes

Persistencia No

FORMATO Código :

Archivo:

Versión: 1.0


Página 91 de 141



Consideraciones


Item Descripción

Información de entrada al servi-cio

El sistema de BackOffice de las firmas envía la notificación de Inicio de Cumplimiento en formato FIXML. El servicio lo recibe y lo envía al traductor correspondiente para ser enviado en formato Trama al sistema de BackOffice de la BVC.

Errores El servicio de Notificación de Inicio de Cumplimiento envía un mensaje de respuesta indicando los errores que se hayan pre-sentado.

Respuesta El Sistema de BackOffice de BVC envía respuesta al sistema de BackOffice de Firma.

Procesamiento El servicio de de Notificación de Inicio de Cumplimiento envía al BackOffice de BVC las notificaciones que envía BackOffice de las firmas.

1.5.2.8.2. Diagrama de secuencia El siguiente es el diagrama de secuencia para el servicio de Notificación de Inicio del cumplimineto para cada operación:

Las especificaciones del mensaje y las reglas de transformación se encuentran de-talladas en los formatos FOI que se relacionan a continuación y los XML y XSD utilizados:

FORMATO Código :

Archivo:

Versión: 1.0


Página 92 de 141



BUS_EJ_FOI_FIXMLM001InicioCumpl BUS_EJ_FOI_FIXMLM004RespInicioCumpl

Ejemplos Archivos XML

M001InicioCumpl.xml M004RespInicioCumpl.xml


FORMATO Código :

Archivo:

Versión: 1.0


Página 93 de 141





1 Error de Validación? Condición Se verifica si el XML recibido cumple con el es-

quema y está correctamente formado.


3 Manejo de errores Proceso Se manejan los errores que se presenten. Se

Envía trama de error al solicitante.

4 Envío de Trama de

error

Proceso Se envía al solicitante una respuesta que indica

que la notificación de inicio de cumplimiento fue exitosa.

5 Envío de Trama de

error

Proceso Por medio del envío de una trama de error al

solicitante.


Escenario 1: Notificación Inicio Cumplimiento Exitosa

# 0001

Nombre de la prueba Notificación Inicio de Cumplimiento Exitosa

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado Se envía exitosamente la notificación de inicio de cumplimiento al

BackOffice BVC


1 El sistema de BackOffice Firma envía notifi-

cación de inicio de cumplimiento.

Este escenario consiste en reali-

zar notificación de inicio de cumplimiento.

El BackOffice Firma envía la notificación. El BUS se encarga

2 El servicio envía la notificación al servicio

de traducción FIXML – Trama para que reali-ce las transformaciones necesarias.

FORMATO Código :

Archivo:

Versión: 1.0


Página 94 de 141



3 Se envía la notificación de inicio de cum-plimiento al sistema de BackOffice BVC.

4 BackOffice BVC envía respuesta indicando el éxito.

5 El servicio envía la notificación al servicio de traducción Trama - FIXML para que reali-ce las transformaciones necesarias.

de tomarla, transformarla y enviarla al BackOffice BVC.

El BackOffice BVC luego envía una respuesta indicando el éxito.

6 Se envía la respuesta de éxito al solicitante (BackOffice Firma)

Escenario 2: Notificación Inicio Cumplimiento No Exitosa (XML Inválido)

# 0002

Nombre de la prueba Notificación Inicio Cumplimiento No Exitosa (XML Invalido)

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado


1 El sistema de BackOffice Firma envía notifi-cación de inicio de cumplimiento.

2 El servicio de determina que la información recibida es inválida.

Este escenario consiste en realizar notificación de inicio de cumplimiento pero se detecta un error en la valida-ción.

Se envía al solicitante (BackOffice Firma) una respuesta indicando el error.

3 El servicio genera la respuesta de error y se la envía al solicitante (BackOffice Firma)

Se genera un registro en el log de errores

FORMATO Código :

Archivo:

Versión: 1.0


Página 95 de 141



Escenario 3: Notificación Inicio Cumplimiento No Exitosa (Se genera un error)

# 0003

Nombre de la prueba Notificación Inicio Cumplimiento No Exitosa (se genera un error)

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado


Se presenta un error en el proceso de enviar o recibir la notificación o la respuesta.

1 Se detecta un error. Los errores pueden presentarse por un fallo en la conexión con el BackOffice de BVC o por que la respuesta que envía el BackOffice BVC indica que se presentó un error en el proceso de inicio de cumplimiento.

Se genera una respuesta de error que se envía al solicitante.

FORMATO Código :

Archivo:

Versión: 1.0


Página 96 de 141



1.5.2.9. Servicio de Estado del Cumplimiento



S0103 – Información Estado de Cumplimiento


El objetivo general de este servicio consiste en obtener información sobre el esta-do de cumplimiento de una operación, conocer su detalle y determinar si se pre-sentó algún error. Este servicio posee dos modalidades, en la primera la informa-ción es solicitada siguiendo el patrón Request-Reply, mientras que en la segunda, la información es notificada sin recibir algún tipo de solicitud. Ambas modalidades del servicio serán expuestas mediante Web Services que tanto el BackOffice de las Firmas como el BackOffice, a través de un servicio de traducción, consumirán.




Si Para la Solicitud el solicitante debe esperar una respuesta.

Síncrono

No Para la notificación el solicitante envía los datos y no espera con-firmación o respuesta alguna.

Patrón Request-Reply El solicitante (BackOffice de las Fir-mas) envía una solicitud al Servicio para consultar el estado de cumpli-miento de la operación. El servicio envía la solicitud al BackOffice y espe-ra la respuesta con los datos que en-viará al solicitante como respuesta.

FORMATO Código :

Archivo:

Versión: 1.0


Página 97 de 141



Notificación El solicitante (BackOffice) envía una notificación con información sobre el estado de cumplimiento de una opera-ción al recibir información sobre su actualización. El Servicio recibe esta notificación y se la envía al BackOffice de las Firmas.

Capa BackOffice

Frecuencia Por Evento Se invocará por evento, de forma dia-ria, principalmente entre las 8AM y 5PM.

Necesidad entrega certificada

Si Se requiere certificación de entrega.

Tamaño del mensa-je

200 Bytes

Depende de la se-sión

Si Si el solicitante, pierde la sesión en la mitad del proceso, el solicitante debe realizar nuevamente la solicitud de información.

Persistencia No En caso de caerse la conexión el solici-tante debe invocar al Servicio nueva-mente para obtener la información solicitada.

Consideraciones


Item Descripción


El solicitante envía los datos del mercado, la ubicación, la hora de la adjudicación, el número de folio, el tramo y los datos del afiliado.

Error Error durante la transmisión de la solicitud.

Procesamiento El Servicio obtiene los datos de la solicitud, se los envía al BackOffice, espera la respuesta y posteriormente la envía hacia el solicitante.

Error Error durante el envío de la solicitud al BackOffice.

Respuesta En el mensaje de respuesta se envía el estado de la com-

FORMATO Código :

Archivo:

Versión: 1.0


Página 98 de 141



plementación de la operación, su detalle y el código de error en caso de que se haya presentado uno durante el procesamiento.

Error Error durante el envío de la respuesta a la solicitud o el envío de la notificación.


En las siguientes figuras se presentan los diagramas de secuencia correspondientes a ambas modalidades del Servicio de Información del Estado de Cumplimiento de una Operación.

Diagrama de secuencia (Solicitud)


BackOffice de las Firmas

El BackOffice de las Firmas es quien consumirá el Web Service de Información Estado de Cumplimiento para solicitar información so-bre el estado de cumplimiento de una operación. Posteriormente, como respuesta del Web Service, recibirá los datos solicitados.

Servicio Infor-mación Estado de Cumpli-miento

Es el encargado de recibir y enviar información hacia el BackOffice y al BackOffice de las Firmas. Además cumple con las tareas de procesamiento de información, transformación de datos, ejecución de reglas del negocio, entre otras.

FORMATO Código :

Archivo:

Versión: 1.0


Página 99 de 141



Servicio Tra-ductor FIXML-Trama

Corresponde a la entidad encargada de realizar las transformacio-nes entre el servicio y la aplicación destino, el mismo recibe men-sajes en FIXML y lo lleva a tramas.

BackOffice El BackOffice de la BVC es en donde se reciben y procesan las soli-citudes realizadas a través del Servicio de Información de Estado de Cumplimiento.

Diagrama de secuencia (Notificación)


BackOffice El BackOffice de la BVC, al recibir una actualización sobre el es-tado de cumplimiento de alguna operación, envía, a través del Servicio de Información de Estado de Cumplimiento, una notifi-cación hacía el BackOffice de las Firmas.

Servicio Tra-ductor Trama-FIXML

Corresponde a la entidad encargada de realizar las transforma-ciones entre el servicio y la aplicación destino, el mismo recibe mensajes como tramas y los transforma en FIXML.

Servicio Infor-mación Estado de Cumpli-miento

Es el encargado de recibir la notificación enviada por el BackOffi-ce y enviarla al BackOffice de las Firmas. Además cumple con las tareas de procesamiento de información, transformación de datos, ejecución de reglas del negocio, entre otras.

BackOffice de las Firmas

El BackOffice de las Firmas es quien consumirá el Web Service de Información Estado de Cumplimiento para solicitar informa-

FORMATO Código :

Archivo:

Versión: 1.0


Página 100 de 141



ción sobre el estado de cumplimiento de una operación. Poste-riormente, como respuesta del Web Service, recibirá los datos solicitados.


BUS_EJ_FOI_FIXMLM001EstadoCumplimiento BUS_EJ_FOI_FIXMLM004EstadoCumplimiento


M001EstadoCumpl.xml M001EstadoCumpl_ACK.xml M004RespEstadoCumpl.xml

1.5.2.9.3. Proceso en el bus para el uso del servicio

El proceso que debe ejecutar el BUS en la ejecucion de este servicio es el siguiente:

Envío NotificaciónEstado de

Cumplimiento[BackOffice Firmas]

Envío SolicitudEstado de

Cumplimiento alBackOffice

Recepción yValidación Datos

Inicio

FIN¿Datosinválidos?

SI

NO¿OcurrióError?

SI

NO

¿Es unaNotificación?

SI

NO

ManejoErrores

¿OcurrióError?

SI

NO

¿OcurrióError?

ManejoErrores

SI

NOObtener

Respuesta con elEstado de

Cumplimiento

FORMATO Código :

Archivo:

Versión: 1.0


Página 101 de 141





1 Recepción de datos Proceso En este paso el Servicio obtiene la solici-tud o notificación con los datos para la ejecución del servicio.

2 ¿Datos inválidos? Condición Verifica si los datos recibidos son válidos.

3 ¿Es una notificación? Condición Este paso valida si el mensaje se trata de una solicitud de información o si es una notificación del estado de cumpli-miento de una operación.

4 Envío Solicitud Estado de Cumplimiento al BackOffice

Proceso En este paso el Servicio envía la solicitud de información hacia el BackOffice.

5 ¿Ocurrió error? Condición Verifica si ocurrió un error durante el en-vío de la solicitud al BackOffice. En caso afirmativo, el término de la ejecución recae en el Manejador de Errores.

6 Obtener respuesta con el Estado de Cumplimiento

Proceso En este paso el Servicio recibe la res-puesta con la información sobre el esta-do de cumplimiento de la operación soli-citada.

7 ¿Ocurrió error? Condición Verifica si ocurrió un error al recibir la respuesta desde el BackOffice. En caso afirmativo, el término de la ejecución recae en el Manejador de Errores.

8 Envío de Notificación Estado de Cumpli-miento [BackOffice de las Firmas]

Proceso En este paso el Servicio envía la notifica-ción sobre el estado de cumplimiento de una operación hacia el BackOffice de las Firmas.

9 ¿Ocurrió error? Condición Verifica si ocurrió un error al enviar la notificación hacia el BackOffice de las Firmas. En caso afirmativo, el término de la ejecución recae en el Manejador de Errores.

FORMATO Código :

Archivo:

Versión: 1.0


Página 102 de 141




Escenario 1: Información Estado de Cumplimiento exitosa [Solicitud]

# 0001

Nombre de la prueba Información Estado de Cumplimiento exitosa [Solicitud]

Mercado Acciones

Resultado Esperado N/A


1 El BackOffice de las

Firmas envía una solici-tud al Servicio de In-formación de Estado de Cumplimiento.

Se debe iniciar la ejecución

del servicio.

2 El servicio recibe la soli-

citud en FIXML, la vali-da, verifica que los da-tos estén completos y la envía hacia el servicio de traducción.

3 El servicio de traducción

recibe el mensaje, lo transforma y envía la solicitud hacia el Bac-kOffice.

La trama con la notificación

es enviada al BackOffice

4 El BackOffice recibe la

solicitud y envía la res-puesta al Servicio a través del Servicio de Traducción.

La respuesta con formato

FIXML es recibida por el Ser-vicio.

Este escenario se corresponde al

flujo de eventos básico del servi-cio. En él, el BackOffice de las Firmas solicita al Servicio, a tra-vés del Web Service, información sobre el estado de cumplimiento d e una operación. Posteriormen-te el Servicio obtendrá el FIXML con los datos, los procesará y realizará las validaciones necesa-rias para enviar la consulta hacia el BackOffice. Una vez obtenida la respuesta con la información solicitada, a través del servicio de traducción, el Servicio envía los datos hacia el BackOffice de las Firmas.

5 El Servicio obtiene la

respuesta y la envía al BackOffice de las Fir-mas.

El mensaje de respuesta es

recibido por el BackOffice de las Firmas.

FORMATO Código :

Archivo:

Versión: 1.0


Página 103 de 141



Escenario 2: Información Estado de Cumplimiento exitosa [Notificación]

# 0002

Nombre de la prueba Información Estado de Cumplimiento exitosa [Notificación]

Mercado Acciones



1 El BackOffice envía una noti-ficación al Servicio de In-formación Estado de Cum-plimiento.

Se debe iniciar la ejecu-ción del servicio.

2 El servicio de traducción recibe la trama, la valida, la lleva a formato FIXML y la envía al Servicio.

La respuesta con formato FIXML es recibida por el Servicio.

3 El Servicio recibe la notifica-ción y la guarda.

4 El BackOffice de las Firmas realiza consultas al Servicio de Información de Estado de Cumplimiento [Consulta de Notificaciones].

El Servicio recibe la soli-citud.

Este escenario se corresponde al flujo de eventos alternativos del servicio. En él, el BackOffice tras recibir alguna actualización del estado de cumplimiento de una operación notifica al BackOffice de las Firmas, a través del Servi-cio de Información de Estado de Cumplimiento.

5 El Servicio consulta si exis-ten notificaciones por ser entregadas para el BackOffi-ce de la Firma solicitante. De ser así el Servicio le res-ponde con la notificación correspondiente

El mensaje de notifica-ción es recibido por el BackOffice de las Firmas.

FORMATO Código :

Archivo:

Versión: 1.0


Página 104 de 141



Escenario 3: Información Estado de Cumplimiento exitosa [XML con caracteres especiales]

# 0003

Nombre de la prueba Información Estado de Cumplimiento exitosa [XML con caracteres especiales]

Mercado Acciones



1 El BackOffice de las Firmas envía una solicitud al Servicio de Información de Estado de Cumplimiento.

Se debe iniciar la ejecución del servi-cio.

2 El servicio recibe la solicitud en FIXML, la valida, escapa cualquier carácter especial que encuentre, verifica que los datos estén completos y la envía hacia el servicio de traducción.

3 El servicio de traducción recibe el mensaje, lo transforma y envía la solicitud hacia el BackOffice.

La trama con la notificación es en-viada al BackOffice

4 El BackOffice recibe la solicitud y en-vía la respuesta al Servicio a través del Servicio de Traducción.

La respuesta con formato FIXML es recibida por el Ser-vicio.

Este escenario se corresponde al flujo de eventos alternativos del servicio. En él el Servicio recibe los datos de la solicitud o notifi-cación. Sin embargo, en estos datos se presentan caracteres especiales. La ejecución del Ser-vicio continúa normalmente.

5 El Servicio obtiene la respuesta y la envía al BackOffice de las Firmas.

El mensaje de res-puesta es recibido por el BackOffice de las Firmas.

FORMATO Código :

Archivo:

Versión: 1.0


Página 105 de 141



Escenario 4: Información Estado de Cumplimiento no exitosa [XML de entrada no válido]

# 0004

Nombre de la prueba Información Estado de Cumplimiento no exitosa [XML de entrada no válido]

Mercado Acciones


Descripción Paso Descripción Resultado

esperado

1 El BackOffice de las Firmas

envía una solicitud al Ser-vicio de Información de Estado de Cumplimiento.

Se debe iniciar la ejecución

del servicio.

Este escenario se corresponde al

flujo de eventos alternativos del servicio. En él, el Servicio recibe la solicitud o notificación, sin em-bargo, el mensaje FIXML no con-cuerda con el esquema corres-pondiente.

2 El Servicio obtiene el men-

saje FIXML, pero el mismo no pasa la validación co-ntra el esquema corres-pondiente.

El manejo de errores im-

plementado para el Bus registrará dicho error en el Log de errores correspon-diente.

Escenario 5: Información Estado de Cumplimiento no exitosa [Datos incompletos]

# 0005

Nombre de la prueba Información Estado de Cumplimiento no exitosa [Datos incompletos]

Mercado Acciones



Este escenario se corresponde al flujo de eventos alternativos del servicio. En él, el Servicio

1 El BackOffice de las Firmas envía una solicitud al Servicio de Informa-ción de Estado de Cumplimiento.


FORMATO Código :

Archivo:

Versión: 1.0


Página 106 de 141



recibe la solicitud o notificación, sin embargo, el mensaje gene-rado no posee toda la informa-ción necesaria para la ejecución del servicio.

2 El Servicio obtiene los datos, los valida, pero no obtiene los datos necesarios para poder ejecutar el servicio.

El manejo de erro-res implementado para el Bus registra-rá dicho error en el Log de errores co-rrespondiente.

Escenario 6: Información Estado de Cumplimiento no exitosa [Error al solicitar información al BackOffice]

# 0006

Nombre de la prueba Información Estado de Cumplimiento no exitosa [Error al solicitar infor-mación al BackOffice]

Mercado Acciones


Descripción Paso Descripción Resultado espera-do

1 El BackOffice de las Firmas envía una solicitud al Servicio de Información de Estado de Cumplimiento.


2 El servicio recibe la solicitud en FIXML, la valida, verifica que los datos estén completos y la envía hacia el servicio de traducción.

Este escenario se corresponde al flujo de eventos alternativo del servicio. En él, el BackOffice de las Firmas solicita al Servi-cio, a través del Web Service, información sobre el estado de cumplimiento de una operación. Posteriormente el Servicio ob-tendrá el FIXML con los datos, los procesará y realizará las validaciones necesarias para enviar la consulta hacia el Bac-kOffice. Sin embargo, se pre-senta un error al enviar las soli-citudes al BackOffice.

3 El servicio de traducción recibe el mensaje, lo transforma y envía la soli-citud hacia el BackOffice, pero ocurre un error al intentar entablar la co-nexión.

El manejo de errores implementado para el Bus registrará dicho error en el Log de errores corres-pondiente, almace-nando los datos ne-cesarios para ga-rantizar que la in-formación de la tra-ma no se pierda.

FORMATO Código :

Archivo:

Versión: 1.0


Página 107 de 141



1.5.2.10. Servicio de Modificación Datos Cumplimiento



S0098-ModificacionOperacionDatosCumplimiento


El objetivo principal de este servicio es permitir a los afiliados realizar modificaciones de los datos de cumplimiento (Fecha de cumplimiento, ti-po de compensación, etc.), enviando un mensaje al BackOffice de la BVC, con la nueva información. Luego la BVC realiza las modificaciones necesarias y envía respuesta al solicitante indicándole si el proceso fue exitoso o no. En caso de que se generara un error, se indicara el código y la descripción de este. Este servicio aplica para todos los mercados y ti-pos de operación.




Síncrono Si

Patrón Request-Reply

Cada vez que un afiliado necesite realizar una modificación sobre la información de cumplimiento, envía un mensaje hacia el BackOffice de la BVC indicándole el cambio y espera la respuesta donde se informe si la modificación se realizo con éxito.

Capa BackOffice



Si


600 Bytes

FORMATO Código :

Archivo:

Versión: 1.0


Página 108 de 141




No

Persistencia Si

Consideraciones


Item Descripción

Salida del ser-vicio

El servicio debe garantizar la entrega de la información al afiliado correspondiente

Solicitante El solicitante enviara la modificación de los datos de cum-plimiento y posteriormente, será su responsabilidad con-sultar el medio persistente para obtener la respuesta del proceso.


En las siguientes figuras se presentan los diagramas de secuencia correspondientes a ambas modalidades del Servicio de Información del Estado de Cumplimiento de una Operación.

FORMATO Código :

Archivo:

Versión: 1.0


Página 109 de 141




Solicitante El solicitante en este caso seria cualquier afiliado o entidad interesada en modificar los datos de cumplimiento de una operación que tenga los permisos necesarios para invocar el servicio, enviado por SOAP el XML con el estándar establecido. Además recibe la respuesta indican-do si el proceso de modificacion se ejecuto con éxito o indicando y detallando que hubo error el proceso.

BUS Posee 2 servicios, en este diagrama, 1 de traducción (FIXML-Trama) y el servicio de negocio de complementación que se encarga de hacer las validaciones y diferentes reglas del negocio. El servicio recibirá un XML con la información necesaria para realizar la modificación de los datos de cumplimiento de la operación. Luego el BackOffice responde si la modificación fue exitosa que es traducido y direccionado al servicio que se encarga de enviar finalmente la aceptación o rechazo de la modificación al solicitante.

BackOffice El BackOffice de la BVC está sobre un HP NonStop, donde se realiza la modificación de los datos de cumplimiento de la operación, para des-pués responder si el proceso tuvo éxito.


BUS_EJ_FOI_FIXMLM001InicioModCumpl BUS_EJ_FOI_FIXMLM004RespModCumpl BUS_EJ_FOI_FIXMLM000Ack


M001-FIXML-DatosModificacionCumpl.xml M004-FIXML-Respuest.xml


FORMATO Código :

Archivo:

Versión: 1.0


Página 110 de 141





Recepción DatosModificacion

Cumpl

EnviarModificacion BO Hubo Error?

Si

Inicio

No

No

FIN

Manejo Error

EsperarRespuesta

Hubo error?Enviar RespuestaSolicitante

No

Validacion Datos Hubo Error? Manejo ErrorSi

No

FIN

Manejo ErrorSi

Llego respuesta?

Si

No

FORMATO Código :

Archivo:

Versión: 1.0


Página 111 de 141




1 Recepción datos Modificacion Cumpl

Transformación de Datos

En este paso el BUS se encarga de recibir los datos del solicitante necesarios para realizar la modificación de los datos de cumplimiento de la operación. Es importan-te aclarar que se tiene como premisas que solo se pueden modificar operaciones que no hubieran iniciado su cumplimiento.

2 Validación de Da-tos

Validación En este paso el proceso se encarga de vali-dar que los datos recibidos estén correctos y que los campos que son requeridos para el proceso se encuentren correctamente diligenciados.

3 Manejo Error En caso de que hubiera algún error en el proceso, este paso se encarga de realizar la administración del error, basado en el FrameWork de Errores definido para los procesos.

4 Hubo Errores? Condición Esta condición valida que en el proceso se hubiera generado algún error

5 Enviar Modifica-ción BO

Procesamiento Este paso se encarga de enviar la solicitud de modificación hacia el BackOffice

6 Esperar Respues-ta

Procesamiento Una ves enviada la solicitud el proceso es-pera la respuesta del BackOffice donde in-dica si el proceso de modificación se realizo con éxito

7 Llego Respuesta? Condición Este paso se encarga de validar si la res-puesta fue recibida por el servicio. En caso de que no se reciba la respuesta en un pe-riodo de 2 minutos, se debe generar una alerta administrativa que indique del re-traso en la información

8 Enviar Respuesta Solicitante

Procesamiento Finalmente este paso se encarga de gene-ral el XML con la respuesta para el solici-tante, indicando si el proceso de modifica-ción tuvo éxito. En caso de que hubiera existido un error en el BackOffice se espe-cifica el código del error y su descripción.


FORMATO Código :

Archivo:

Versión: 1.0


Página 112 de 141



Escenario 1: Modificación Exitosa Datos Cumplimien-to de una Operación

# 0001

Nombre de la prueba Modificación Exitosa




Punta Compra, Venta

Resultado Esperado XML con la respuesta de la modificación exitosa de la opera-ción

Descripción Pa-so


1 El Solicitante envía los datos de la operación y la información que des-ea modificar.

Toda la información enviada por el solicitante esta de acuerdo con el FOI definido en este diseño “BUS_EJ_FOI_FIXMLM001InicioModCumpl”

2 El Servicio valida la información recibida

La información recibida es correcta

3 El servicio envía la soli-citud de modificación al traductor del BackOffice

4 El servicio de traduc-ción transforma el XML a la trama y se la envía al BackOffice

La trama generada debe estar acorde al FOI “BUS_EJ_FOI_TramaM002ModCumpl” definido en este diseño

Este escenario se refiere a la modi-ficación exitosa de los datos de cumplimiento de una operación.

5 El BO Responde indi-cando si la modificación de la operación se realizo con éxito.

La modificación se debe realizar con éxito.

6 El servicio de traduc-

ción envía la respuesta al servicio de modifica-ción datos cumplimien-to en XML

Este XML debe estar basado en FOI

“BUS_EJ_FOI_FIXMLM004RespModCumpl” especificado en este diseño

FORMATO Código :

Archivo:

Versión: 1.0


Página 113 de 141



7 El servicio de modifica-ción datos cumplimien-to envía la respuesta al solicitante indicándole que la modificación se realizo con éxito.

Escenario 2: Modificación No Exitosa Datos Cumpli-miento de una Operación

# 0002

Nombre de la prueba Modificación No Exitosa

Característica Opera-ción

Entera, fraccionada, convenida, cruzada



Punta Compra y venta

Resultado Esperado XML con la respuesta de la modificación NO exitosa de la operación


1 El Solicitante envía los datos de la operación y la informa-ción que desea modificar.

Toda la información enviada por el solici-tante esta de acuerdo con el FOI definido en este diseño “BUS_EJ_FOI_FIXMLM001InicioModCumpl”

2 El Servicio valida la informa-ción recibida


3 El servicio envía la solicitud de modificación al traductor del BackOffice

4 El servicio de traducción transforma el XML a la trama y se la envía al BackOffice


5 El BO Responde indicando si la modificación de la opera-ción se realizo con éxito.

La modificación no se debe realizar por un error de negocio en el BackOffice.

Este escenario se refiere a la modificación NO exitosa de los datos de cumplimiento de una operación.

6 El servicio de traducción en-vía la respuesta al servicio de modificación datos cumpli-miento en XML

Este XML debe estar basado en FOI “BUS_EJ_FOI_FIXMLM004RespModCumpl” especificado en este diseño

FORMATO Código :

Archivo:

Versión: 1.0


Página 114 de 141



7 El servicio de modificación datos cumplimiento envía la respuesta al solicitante indi-cándole que la modificación no se realizo.

Escenario 3: Generación de alarma por retraso en la respuesta

# 0003

Nombre de la prueba Retraso en la respuesta





Punta Compra y ventas







3 El servicio envía la solicitud de modificación al traductor del BackOffice

4 El servicio de traducción transforma el XML a la trama y se la envía al BackOffice


Esta prueba consiste en que la respuesta gene-rada por el BackOffice a la modificación solicita-da, se demora mas de 2 minutos, por lo que se debe generar una alar-ma administrativa, indi-cando de este retrazo

5 Después de 2 minutos el Bac-kOffice no responde.

Se debe generar una alarma administrati-va indicando que la respuesta para esta modificación esta retrazada.

FORMATO Código :

Archivo:

Versión: 1.0


Página 115 de 141



Escenario 4: Trama de respuesta incorrecta

# 0004

Nombre de la prueba Trama Incorrecta





Resultado Esperado Log Errores


1 El Solicitante envía los datos de la

operación y la información que desea modificar.

Toda la información enviada por

el solicitante esta de acuerdo con el FOI definido en este diseño “BUS_EJ_FOI_FIXMLM001InicioModCumpl”

2 El Servicio valida la información

recibida

La información recibida es correc-

ta

3 El servicio envía la solicitud de

modificación al traductor del Bac-kOffice

4 El servicio de traducción transfor-

ma el XML a la trama y se la envía al BackOffice

La trama generada debe estar

acorde al FOI “BUS_EJ_FOI_TramaM002ModCumpl” definido en este diseño

5 El BO Responde indicando si la

modificación de la operación se realizo con éxito enviando la tra-ma de respuesta.

La modificación se debe realizar

correctamente. La trama de res-puesta del BackOffice no debe concordar en su longitud con la definida en el FOI “BUS_EJ_FOI_TramaM003RespModCumpl”

En esta prueba consiste en

que el BackOffice envía una trama de respuesta con una longitud diferente a la estable-cida. El servicio debe validar la longitud de la estructura y generar una alarma indicando el error.

FORMATO Código :

Archivo:

Versión: 1.0


Página 116 de 141




# 0005











La información recibida no esta completa para el proceso

En este escenario se valida que la información entregada por el solicitante corresponda con el estándar definido en este diseño, con todos los campos requeridos y necesa-rios para el proceso.

3 Se genera un error indicán-dole al solicitante que faltan datos requeridos para el proceso

Escenario 6: Los datos de enviados por el solicitante no corresponden con el Esquema XML definido

# 0007

Nombre de la prueba Los datos de entrada no corresponden al XDS








FORMATO Código :

Archivo:

Versión: 1.0


Página 117 de 141




La información enviada por el solicitante NO esta de acuerdo con el FOI definido en este diseño “BUS_EJ_FOI_FIXMLM001InicioModCumpl”.

Esta prueba consiste en que el solicitante envía un XML que no concuer-da con el XSD especifi-cado para este requeri-miento.

2 Se genera un error indicán-dole al solicitante que faltan el XML enviado por el solici-tante no concuerda con el XSD definido para este pro-ceso

FORMATO Código :

Archivo:

Versión: 1.0


Página 118 de 141



1.5.2.11. Servicio de consulta saldo cuentas compensación



S0018 – Consulta Saldo Cuenta Compensación


El objetivo principal de este servicio, es permitir a las firmas consultar todos los saldos de sus cuentas de compensación. La información se recibe desde el BackOffice de la BVC y se entrega al BackOffice de la Firma. La compensación se hace solo por concepto de acciones




Síncrono Si


El solicitante envía la consulta de saldo de cuenta de compensación y espera la res-puesta con el saldo

Capa BackOffice



Si


100 bytes


No

Persistencia Si

FORMATO Código :

Archivo:

Versión: 1.0


Página 119 de 141



Consideraciones


Item Descripción


El sistema de BackOffice de las firmas envía la consulta de saldo de cuenta de compensación en formato FIXML. El servicio lo recibe y lo envía al traductor correspondiente para ser enviado en formato Trama al sistema de BackOffice de la BVC.

Errores El servicio envía un mensaje de respuesta indicando los errores que se hayan presentado.

Respuesta El Sistema de BackOffice de BVC envía el saldo de la cuenta al sistema de BackOffice de Firma.

Procesamiento El servicio envía al BackOffice de BVC las notificaciones que envía Bac-kOffice de las firmas.


La siguiente figura presenta el diagrama de secuencia:

FORMATO Código :

Archivo:

Versión: 1.0


Página 120 de 141




Solicitante El solicitante en este caso seria cualquier afiliado o entidad interesada en modificar los datos de cumplimiento de una operacion que tenga los permisos necesarios para invocar el servicio, enviado por SOAP el XML con el estándar establecido. Además recibe la respuesta indicando si el proceso de modificacion se ejecuto con éxito o indicando y detallando que hubo error el proceso.

BUS Posee 2 servicios, en este diagrama, 1 de traducción (FIXML-Trama) y el servicio de negocio de complementación que se encarga de hacer las validaciones y diferentes reglas del negocio. El servicio recibirá un XML con la información necesaria para realizar la modificación de los datos de cumplimiento de la operación. Luego el BackOffice responde si la modificación fue exitosa que es traducido y direccionado al servicio que se encarga de enviar finalmente la acepta-ción o rechazo de la modificación al solicitante.

BackOffice El BackOffice de la BVC está sobre un HP NonStop, donde se realiza la modificación de los datos de cumplimiento de la operación, para des-pués responder si el proceso tuvo éxito.


BUS_EJ_FOI_FIXMLM001ConsultaCuentaComp BUS_EJ_FOI_FIXMLM004ConsultaCuentaComp BUS_EJ_FOI_FIXMLM004ConsultaCuentaComp_Error


M001-FIXML-DatosModificacionCumpl.xml M004-FIXML-Respuest.xml

FORMATO Código :

Archivo:

Versión: 1.0


Página 121 de 141





FORMATO Código :

Archivo:

Versión: 1.0


Página 122 de 141





1 Error de Validación? Condición Se verifica si el XML recibido cumple con el esquema y está correctamente formado.

2 Manejo de errores Proceso Se manejan los errores que se presenten.

3 Envío de consulta saldo cuenta compensación

Proces0 Se envía al sistema de BackOffice la consulta del saldo de la cuenta de compensación.

4 Esperar Respuesta de Bac-kOffice BVC

Proceso Se espera que el sistema de BackOffice BVC genere la respuesta correspondiente al saldo de la cuenta de compensación.

5 Se obtuvo respuesta? Condición Se revisa si se ha obtenido la respuesta por parte del sistema de BackOffice BVC.

6 Pasó más del tiempo máxi-mo de espera?

Condición Se revisa q no haya pasado más del tiempo máximo de espera ( 2 minutos )

7 Envío Saldo cuenta compen-sación

Proceso Se envía al solicitante una respuesta que contiene la información referente al saldo de la cuenta de com-pensación.


9 Envío de error Proceso Se envía al solicitante una respuesta que indica que se ha presentado un error.

FORMATO Código :

Archivo:

Versión: 1.0


Página 123 de 141



1.5.2.11.5. Escenarios de prueba Escenario 1: Consulta Saldo Cuenta Compensación Exitosa

# 0001

Nombre de la prueba Consulta Saldo Cuenta Compensación Exitosa

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado Se envía exitosamente el saldo de la cuenta de compensación al BackOffice Firma


1 El sistema de BackOffice Firma envía consulta de

saldo de cuenta de compensación.

2 El servicio envía la consulta al servicio de traduc-

ción FIXML – Trama para que realice las transfor-maciones necesarias.

3 Se envía la consulta de saldo de cuenta de com-

pensación al sistema de BackOffice BVC.

4 BackOffice BVC envía respuesta indicando el saldo.

5 El servicio envía la respuesta con el saldo al servi-

cio de traducción Trama - FIXML para que realice las transformaciones necesarias.

Este escenario consiste en realizar una

consulta de saldo de cuenta de com-pensación.

El BackOffice Firma envía la consulta. El BUS se encarga de tomarla, trans-formarla y enviarla al BackOffice BVC.

El BackOffice BVC luego envía una respuesta con el saldo.

6 Se envía la respuesta con el saldo al solicitante

(BackOffice Firma)

FORMATO Código :

Archivo:

Versión: 1.0


Página 124 de 141



Escenario 2: Consulta Saldo Cuenta Compensación No Exitosa (XML Inválido)

# 0002

Nombre de la prueba Consulta Saldo Cuenta Compensación No Exitosa (XML Invalido)

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado


1 El sistema de BackOffice Firma envía consul-ta de saldo de cuenta de compensación.

2 El servicio de determina que la información recibida es inválida.

Este escenario consiste en realizar una consulta de saldo de cuenta de com-pensación pero se detecta un error en la validación.

Se envía al solicitante (BackOffice Firma) una respuesta indicando el error.

3 El servicio genera la respuesta de error y se la envía al solicitante (BackOffice Firma)

Se genera un registro en el log de errores

Escenario 3: Consulta Saldo Cuenta Compensación No Exitosa (Se genera un error)

# 0003

Nombre de la prueba Consulta Saldo Cuenta Compensación No Exitosa (se genera un error)

Tipo de Operación


Mercado

Numero Fracciones

Punta

Resultado Esperado


FORMATO Código :

Archivo:

Versión: 1.0


Página 125 de 141



Se presenta un error en el proceso de enviar o recibir la consulta o la res-puesta con el saldo.

1 Se detecta un error. Se genera una respuesta de error que se envía al solicitante.

FORMATO Código :

Archivo:

Versión: 1.0


Página 126 de 141



1.5.3. Diseño de servicios No Funcionales Los servicios diseñados para ser expuestos en la primera entrega del proyecto son:

MODULO SERVICIOS DESCRIPCION

Autenticación Este componente se encarga de autenticar la identidad del consumidor de servicios me-diante la validación de un usuario y su correspondiente contraseña. Este servicio se apoya en un repositorio de identidades y perfiles de ac-ceso para realizar la valida-ción.

Autorización Proveer la información de los servicios a los cuales está autorizado un usuario como una tabla en memoria, de manera que se optimice el acceso a esta información, evitando tener que hacer consultas redundantes en la base de datos

CAPA DE INTERCONEXION

Fachada El servicio fachada es la puerta de acceso a los servi-cios de negocio. Este servicio es el encargado de recibir el requerimiento, validar que el consumidor esté autorizado a acceder el servicio invoca-do y redirigir el requerimien-to a la capa de servicios de negocio, cuando el nivel de autorización es el apropiado

FORMATO Código :

Archivo:

Versión: 1.0


Página 127 de 141



1.5.3.1. Servicio Capa de Interconexion



La capa de interconexión es un componente diseñado para servir de inter-faz a los entes externos a la BVC que requieren el acceso a los servicios de negocio implementados en el Bus de Integración.

Las responsabilidades de esta capa son las siguientes:

• Autenticación de los usuarios que desean acceder a la capa de servicios de negocio.

• Autorización a los servicios de negocio según el perfil del usuario.

• Manejo de confidencialidad de la información.

• Manejo de sesión del usuario.

Manejo de concurrencia

Premisas

• La autenticación se realizará mediante usuario y contraseña. • El canal de comunicación entre los usuarios de los servicios que partici-

pan en el mercado y la BVC es un canal dedicado. • El protocolo de transporte entre los usuarios y la capa de interconexión

es HTTPS, de manera que el canal es encriptado. • La plataforma de desarrollo y ejecución de los servicios de interco-

nexión es TIBCO BusinessWorks. • Los componentes de esta capa están configurados para garantizar la

tolerancia a fallas y el balanceo de carga.

FORMATO Código :

Archivo:

Versión: 1.0


Página 128 de 141



Arquitectura

La capa de interconexión se sitúa entre los usuarios externos a la BVC (principalmente afiliados) y la capa de servicios de negocio implemen-tada en el Bus de Integración.

La siguiente figura muestra esta visión conceptual

Co

Como se aprecia en la gráfica, los usuarios no acceden directamente a los ser-vicios de negocio, sino que toda interacción es a través de la capa de interco-nexión vía HTTPS.

Servicios de la capa de interconexión

Proxy

Este componente tiene como función garantizar el manejo de los requerimien-tos HTTPS concurrentes, provenientes de los usuarios finales. De esta manera, la función de confidencialidad de la información estaría delegada en este com-

FORMATO Código :

Archivo:

Versión: 1.0


Página 129 de 141



ponente. Para ello el proxy maneja la implementación de SSL y el certificado digital respectivo. Adicionalmente este componente balancea la carga entre las instancias que soportan los servicios de autenticación y fachada.

Servicio de Autenticación

Este componente se encarga de autenticar la identidad del consumidor de ser-vicios mediante la validación de un usuario y su correspondiente contraseña. Este servicio se apoya en un repositorio de identidades y perfiles de acceso pa-ra realizar la validación.

Servicio de logout

Así como se implementa un servicio de autenticación que establece una sesión, se ofrece un servicio que termina la sesión. Para ello se usará como parámetro de entrada el identificador de sesión.

Servicio de cambio de contraseña

Para permitir que el usuario administre su contraseña se proveerá un servicio para el cambio de la misma. Este requerirá el usuario y la contraseña anterior para realizar el cambio en la base de datos de usuarios.

Servicio Fachada

El servicio fachada es la puerta de acceso a los servicios de negocio. Este ser-vicio es el encargado de recibir el requerimiento de cada servicio de negocio, validar que el consumidor esté autorizado a acceder el servicio invocado y re-dirigir el requerimiento a la capa de servicios de negocio, cuando el nivel de autorización es el apropiado.

Interacción con los servicios de negocio (vista conceptual)

Básicamente, el bus de integración tiene tres formas de interacción con las funcionalidades de negocio ofrecidas por los sistemas de la BVC:

• Solicitud diferida. (1) En esta forma de interacción el usuario invoca un servicio del bus para hacer una solicitud que debe ingresar al sistema de la BVC. (2) Este responde a la solicitud de forma asíncrona y deja el resultado en un medio que (3) finalmente el usuario puede consultar cuando lo desee.

FORMATO Código :

Archivo:

Versión: 1.0


Página 130 de 141



(1) Solicitud desde el usuario al Backoffice a través del bus.

(2) Respuesta asíncrona del sistema de la BVC, capturada por el bus y dejada en un medio de persistencia

(3) Recolección de resultados a petición del usuario. En este último pa-so la interacción del usuario es transparente al sistema de la BVC, ya que la información que el usuario solicita ya está en las colas del bus.

FORMATO Código :

Archivo:

Versión: 1.0


Página 131 de 141



• Notificación. (1) El sistema de la BVC genera información por eventos que debe ser notificada a los usuarios. Para ello, un servicio del bus deposita esa información en un medio que (2) el usuario puede consul-tar cuando lo desee.

(1) Información generada por eventos desde el sistema de la BVC, cap-turada por el bus y dejada en un medio de persistencia

(2) Recolección de resultados a petición del usuario. En este último pa-so la interacción del usuario es transparente al sistema de la BVC, ya que la información que el usuario solicita ya está en el medio de persistencia del bus.

FORMATO Código :

Archivo:

Versión: 1.0


Página 132 de 141



• Request-Reply. El usuario invoca un servicio del bus para hacer una soli-citud que requiere una respuesta inmediata, por lo cual dicho servicio ingresa la solicitud al sistema de la BVC y espera por la respuesta hasta que la misma se produce.

FORMATO Código :

Archivo:

Versión: 1.0


Página 133 de 141



1.5.3.2. Manejo de respuestas de los servicios

Cómo se especificó en la sección de estándares, el formato de los mensajes de entrada y salida de los servicios es FIXML. Los esquemas de este estándar prescriben los tags en los cuales debe observarse el resultado de una transac-ción de negocio (cada objeto de negocio FIX lo indica). Sin embargo, para las respuestas de errores técnicos o condiciones de excepción, existen dos campos en el encabezado de los esquemas FIX (no dependientes del objeto de nego-cio) que señalan cuando ocurre una excepción en el servicio:

• ErrCode: contiene el código de error.

• ErrMsg: contiene el mensaje del error ocurrido.

Las reglas para estos campos son las siguientes:

• Si el campo ErrCode va en el mensaje y además es distinto de cero “0”, ha ocurrido un error o bien se debe leer el mensaje que viene en el campo ErrMsg.

• Actualmente hay dos códigos de error definidos:

o Si ErrCode es igual a 1, no se han encontrado mensajes que en-tregar para el afiliado (sólo aplica para los servicios que emplea el afiliado para consultar si hay notificaciones o respuestas a so-licitudes diferidas en el medio de persistencia del bus).

o Si ErrCode es igual a 2, ha ocurrido una excepción en el servi-cio.

FORMATO Código :

Archivo:

Versión: 1.0


Página 134 de 141



1.5.3.3. Servicio Autenticación


Nombre del servicio

IntercnxAutenticacionServicio


Autenticar al usuario de los servicios de la BVC mediante la validación de un ID de usuario y una contraseña.

Premisas

• La identidad del usuario está registrada en el repositorio de identidades

y perfiles, si se trata de un usuario válido. • La aplicación que provee el servicio de negocio tiene la lógica para de-

terminar que una firma o entidad es la autorizada a realizar transaccio-nes sobre una operación específica identificada por un folio.



Característica Valor

Síncrono Si


Capa Interconexión



Sí

FORMATO Código :

Archivo:

Versión: 1.0


Página 135 de 141



Consideraciones


Item Descripción


Las entradas al servicio son el identificador de usuario y la contraseña respectiva. El identificador de usuario tiene una máxima longitud de 45 caracteres, y la contraseña tiene una longitud máxima de 100 caracteres. Ambos datos son sensibles al uso de minúsculas y mayúsculas para sus ca-racteres alfabéticos.

Respuesta Identificador de sesión (token) correspondiente al usuario autenticado. Se permitirán múltiples sesiones por usuario.

Respuesta Mensaje de autenticación fallida.

Respuesta Mensaje de usuario bloqueado.

Errores y Ex-cepciones

Cuando no sea posible acceder al repositorio de identida-des, por cualquier circunstancia, el servicio deberá infor-mar al usuario de esta condición. Adicionalmente esta condición debe ser registrada en log como un evento críti-co y debe generar una notificación al grupo de administra-ción.


Este servicio, al autenticar a un usuario establece una se-sión que será mantenida durante la jornada efectiva del mercado. Al final de dicha jornada las sesiones que per-manecen activas se cancelan.


El servicio de autenticación debe validar la última fecha de actualización de la contraseña con la fecha actual. Si la contraseña está vencida, emitirá un mensaje de renova-ción de contraseña. Para ello debe existir un procedimiento administrativo u otro servicio que permita realizar esta ac-ción.

FORMATO Código :

Archivo:

Versión: 1.0


Página 136 de 141



1.5.3.4. Servicio de Autorización


Nombre del servicio

IntercnxAutorizacionServicio


Proveer la información de los servicios a los cuales está autorizado un usuario como una tabla en memoria, de manera que se optimice el acceso a esta in-formación, evitando tener que hacer consultas redundantes en la base de da-tos.

Premisa

La identidad del usuario está registrada en el repositorio de identidades y per-files, si se trata de un usuario válido.




Síncrono Si


Capa Interconexión


Depende de la sesión No

FORMATO Código :

Archivo:

Versión: 1.0


Página 137 de 141



Consideraciones


Item Descripción


Identificador de sesión (token) e identificador de ser-vicio para los cuales se desea validar la autorización.

Respuesta Para un token y servicio específicos se retorna una respuesta de sí o no el usuario correspondiente posee privilegios de ejecución sobre ese servicio.


No disponibilidad de la base de datos de identidades y perfiles.

FORMATO Código :

Archivo:

Versión: 1.0


Página 138 de 141



1.5.3.5. Servicio de Fachada


Nombre del servicio

IntercnxDespachoServicio


Despachar los requerimientos provenientes de los usuarios autentica-dos hacia la capa de servicios de negocio.

Premisa

La identidad del usuario está registrada en el repositorio de identidades y perfiles, si se trata de un usuario válido.




Síncrono Si


Capa Interconexión


Depende de la se-sión

No

FORMATO Código :

Archivo:

Versión: 1.0


Página 139 de 141



Consideraciones


Item Descripción


Las entradas al servicio son el identificador de se-sión (token), servicio de negocio a acceder y cuerpo del mensaje para el servicio de negocio.

Respuesta Mensaje de respuesta del servicio de negocio (caso de requerimiento / respuesta)

Respuesta Mensaje de autorización fallida.

FORMATO Código :

Archivo:

Versión: 1.0


Página 140 de 141



1.6. GLOSARIO

Afiliado: Empresa que maneja la relación con los inversionistas facilitándoles comprar o vender sus títulos a través de la BVC. Ej: Comisionistas de Bolsa, en-tidades financieras,etc

Beneficiario : Persona a la cual se transfiere un activo financiero o a favor de quien se emite un título o un contrato de seguro.

Calce: Expresión que se utiliza para designar la realización de una operación. Se dice que hubo calce en una operación cuando la punta de oferta y la de de-manda coinciden (o se ponen de acuerdo) y efectivamente se realiza la opera-ción.

Comisión: Retribución que da un inversionista a un afiliado por ejecutar una orden de compra o venta de los valores negociables en Bolsa, por asesorarlo en la misma o por administrar los valores del cliente, según sea la solicitud del mismo.

Complementación: Actividad que realiza el afiliado al incluir los beneficiarios, el valor de la comisión, etc. O fraccionarla. En cada operación adjudicada

DCV: El Depósito Central de Valores del Banco de la República – DCV, es un sistema diseñado para el depósito, custodia y administración de títulos valores en forma de registros electrónicos (desmaterializados), con el objeto de recibir en depósito y administración los títulos que emita, garantice o administre el propio Banco y los valores que constituyan inversiones forzosas o sustitutivas a cargo de las entidades sometidas a la inspección y vigilancia de la Superinten-dencia Financiera de Colombia, distintos de acciones.

DECEVAL: Depósito Centralizado de Valores S.A. Entidad privada encargada de recibir en depósito títulos valores que se encuentren inscritos en el Registro Na-cional de Valores e Intermediarios, para cumplir la labor de administrarlos por medio de un sistema computarizado de alta tecnología, que garantiza la seguri-dad de los títulos y elimina los riesgos asociados con el manejo físico de los mismos, tales como registros, transferencias, pagos de intereses, etc

Inversionista: Persona natural o jurídica que realiza inversiones, que son una forma de darle uso productivo a sus recursos de manera eficiente con el fin de obtener más dinero. El inversionista decide a cual título valor destina su dinero para que éste obtenga un rendimiento y pueda cubrirse de riesgos como la in-flación

Liquidación: Determinación del valor en pesos de una operación, así como el de la comisión correspondiente e impuestos.

Cuentas Mancomunadas: Cuentas que tienen más de un beneficiario.

FORMATO Código :

Archivo:

Versión: 1.0


Página 141 de 141



Punta: Inversionista que compra o que vende los títulos participantes en una operación bursátil. Una operación posee punta de compra y punta de venta.

Sebra: Sistema electrónico de transferencia de pagos bajo el esquema abono en cuenta del Banco de la República.

FOI : (Formulario de Documentación de Objeto de Intercambio) Es el formato donde se identifica el intercambio según la aplicación e interfaz que ofrecen el servicio invocado o proveen la información notificada; adicionalmente se identifican los escenarios en los cuales ocurre el intercambio (documentados en la arquitectura) y las aplicaciones origen/destino del mismo, entre otros atri-butos.

En este formulario también se capturan los requerimientos no funcionales que deben satisfacer el intercambio, tales como sincronismo, características tran-saccionales, tiempo de respuesta, frecuencia, volumen, etc. Finalmente se tiene una tabla en la cual se describe la estructura del objeto de intercambio y de su implementación física (registros de un archivo, mensajes de middleware, etc.). La descripción física puede variar dependiendo del mecanismo empleado.

Documents

Especificaciones técnicas y funcionales para la ... · integración con la Bolsa de Valores de ... Web Services ... • Incorpora los principios de SOA en su implementación