Transcript Integración y transformación de mensajes financieros

Transformación de mensajes
www.volantetech.com
2014-08-08
OTN Tour 2014
México, DF
Datos personales
 Arturo Moreno.
 5 años como arquitecto de soluciones en Volante Technologies.
 Proyectos de integración:
 General Electric.
 Ford Motor Company.
 Bank of New York Mellon.
 MasterCard.
 HSBC.
Integración de sistemas
www.volantetech.com
Una definición de integración
Conectar sistemas, compañías y gente.
¿Por qué es necesaria la integración?
 Una sola aplicación no es capaz de resolver todos los problemas
del negocio.
 La resolución de un problema puede involucrar a más de una
aplicación.
 Necesidad de comunicarse con el exterior.
 Intercambiar información.
 Compartir funcionalidad.
Impulsores de la integración
Cambio regulatorio
Agilidad del negocio
(tiempo de lanzamiento de
productos y servicios)
Nuevos servicios
Instituciones
financieras
Corporativos
Reducción de costos
Consolidación geográfica
Industria
Gobierno
Actualizaciones y adiciones
a estándares
Incorporación de nuevos clientes
/ proveedores
Cambio tecnológico
Técnicas de integración
www.volantetech.com
¿Cómo integrar sistemas?
 Transferencia de archivos (FTP, SMB)
 Base de datos (RDBM, NoSQL)
 Invocación remota (RMI, CORBA, Web services)
 Mensajería (MQ, JMS)
Transferencia de archivos
Aplicación
A
E
x
p
o
r
t
Datos
compartidos
I
m
p
o
r
t
Aplicación
B
Transferencia de archivos
Ventajas
 Funcionalidad disponible en prácticamente cualquier plataforma.
 Transmisión de información en múltiples formatos.
 Desacoplamiento entre aplicaciones.
 Transmisión de grandes volúmenes de información en pocos
intercambios.
Transferencia de archivos
Desventajas
 Funcionalidad avanzada debe implementarse desde cero.
 No recomendable en casos donde la transmisión de información
deba ocurrir rápidamente.
 Sincronización entre aplicaciones se vuelve problemática.
 Sólo permite compartir datos, no funcionalidad.
Base de datos
Aplicación
A
Aplicación
B
Datos
compartidos
Aplicación
C
Base de datos
Ventajas
 Se puede compartir información de forma rápida.
 Consistencia. Todas las aplicaciones comparten la misma fuente de
datos con la misma estructura.
 Transaccionalidad manejada por la base de datos.
Base de datos
Desventajas
 Diseñar una base de datos que satisfaga los requerimientos de todas las
aplicaciones.
 Acoplamiento de aplicaciones a través de la base de datos.
 Casi imposible integrar aplicaciones de terceros con este método.
 Base de datos puede volverse un cuello de botella.
 Acceso a base de datos se vuelve lento si las aplicaciones están
distribuidas en distintos lugares geográficos.
 Sólo permite compartir datos, no funcionalidad.
Invocación remota
Función
Aplicación
A
S
t
u
b
Resultado
S
k
e
l
e
t
o
n
Aplicación
B
Invocación remota
Ventajas
 Ideal si se busca compartir funcionalidad entre aplicaciones.
 Cada aplicación es responsable de mantener la integridad de su
información.
Invocación remota
Desventajas
 Es necesario, en muchos casos, conocer las interfaces de
comunicación de antemano.
 Si no se toman las medidas correctas el desempeño puede volverse
lento e impredecible.
 Aplicaciones no están completamente desacopladas.
 Funcionamiento síncrono.
 Compartición limitada de datos.
Mensajería
Aplicación
A
Aplicación
B
Evento
Bus de mensajes
Aplicación
C
Mensajería
Ventajas
 Permite compartir datos y funcionalidad entre aplicaciones.
 Ideal para comunicación en tiempo real.
 Transmisión asíncrona. Las aplicaciones no tienen que estar
corriendo al mismo tiempo.
 Completo desacoplamiento entre aplicaciones.
 Manejo de grandes volúmenes de información.
Mensajería
Desventajas
 Aumenta la complejidad de la integración.
 No es ideal cuando se comparte una gran cantidad de información
en pocos intercambios.
Mensajería a detalle
www.volantetech.com
Características
 Comunicación asíncrona.
 Aplicaciones completamente desacopladas.
 Las aplicaciones se preocupan de la información que
quieren compartir, no de cómo hacerlo.
 La responsabilidad de transferir información recae en un
sistema de mensajería.
Sistema de mensajería
Mensaje
Canal
Aplicación
Ruteo
Traducción
Aplicación
Administración de sistemas
Sistema de mensajería
Conceptos
 Canales.
 Filtros y tuberías (pipes and filters)
 Ruteo.
 Endpoints.
 Mensajes.
 Transformación.
Canales
Aplicación
A
Sistema
de
Mensajería
Aplicación
B
Canales
Canal de mensajes
Aplicación
Emisora
Aplicación
Receptora
Sistema de Mensajería
Filtros y tuberías
Cola
Orden
Entrante
Cola
Cola
Cola
Decodifica
Autentica
Desduplica
Filtro
Filtro
Filtro
Orden
Limpia
Ruteo
outQueue 1
Aplicación
inQueue
outQueue 2
Ruteador de
mensajes
Aplicación
Endpoints
Dato
Dato
Endpoint
Aplicación emisora
Mensaje
Canal
Endpoint
Aplicación receptora
Mensajes
Emisor
Receptor
Mensaje
Transformación
Traductor
Mensaje entrante
Mensaje traducido
Transformación de mensajes
www.volantetech.com
Transformación de mensajes
xml
<xml>
<values>
<value>abc</ value>
<value>def</ value>
<value>ghi</ value>
</ values>
</ xml>
Traductor
txt
abc
def
ghi
Niveles de transformación
 Estructuras de datos.
 Tipos de dato.
 Representación.
 Transporte.
Nivel de transformación – Estructuras de datos
¿Qué comprende?
 Entidades.
 Asociaciones.
 Cardinalidad.
Herramientas y técnicas
 Mapeos.
 Código.
Nivel de transformación – Estructuras de datos
Ejemplo
La misma información representada a través de entidades distintas.
Nivel de transformación – Tipo de dato
¿Qué comprende?
 Nombres de campos.
 Tipos de dato.
 Valores específicos.
Herramientas y técnicas
 Mapeos.
 Búsqueda en bases de datos.
 Código.
Nivel de transformación – Tipo de dato
Ejemplo
Reemplazar el nombre de un país por su código ISO 3166-1 alpha-3
México  MEX
Estados Unidos de América  USA
Modificar el formato de una fecha
8 Agosto, 2014  2014/08/08 (yyyy/MM/dd)
Nivel de transformación – Representación
¿Qué comprende?
 Formatos.
 Codificación de caracteres (charset).
 Encripción.
 Compresión.
Herramientas y técnicas
 Parsers.
 APIs.
Nivel de transformación – Representación
Ejemplo
Parsear datos en un formato y representarlos en otro formato.
XML  JSON
Nivel de transformación – Transporte
¿Qué comprende?
 Protocolos de comunicación.
 Socket TCP/IP.
 HTTP.
 FTP.
 JMS.
Herramientas y técnicas
 Adaptadores.
 ESB.
 Código.
Nivel de transformación – Transporte
Ejemplo
Enviar datos a través de diferentes protocolos sin afectar el contenido
del mensaje.
Recibir mensaje por JMS  Guardar en DB  Retransmitir
mensaje por HTTP
Transformación en contexto
Inteligencia de
negocios
ERP y CRM
XML
via ESB
Software
Integrador
(transformaciones)
Administración de
tesorería
CSV
via FTP
Logística
Back Office
Systems
Recursos
humanos
Longitud
fija
via MQ
Cadena de
suministros
Tag=Value
DB Table
Run Time (Weblogic, JVM, OSB,
SaaS, Cloud)
Base de
datos
Infraestructura de servidores
EDI
IDoc SAP
HIPAA
SPEI ISO 20022
CIP
Transformación en contexto
Inteligencia de
negocios
ERP y CRM
XML
via ESB
Format Plug-ins
Universal
FIX
ISO20022
SEPA
SWIFT
Code Generator
Composer
Administración de
tesorería
CSV
via FTP
Logística
Back Office
Systems
Recursos
humanos
Longitud
fija
via MQ
Cadena de
suministros
Tag=Value
DB Table
Run Time (Weblogic, JVM, OSB,
SaaS, Cloud)
Base de
datos
Infraestructura de servidores
EDI
IDoc SAP
HIPAA
SPEI ISO 20022
CIP
Patrones comunes de
transformación
www.volantetech.com
Enriquecimiento
Enriquecedor
Mensaje enriquecido
Mensaje básico
Recurso
Normalización
Normalizador
Fomatos diferentes
de mensajes
Fomatos diferentes
de mensajes
Ruteador
Traductores
Modelo canónico
Traductores
Traductores
A
C
B
D
Modelo canónico de datos
Swift MX a Swift
www.volantetech.com
Swift MX a Swift
Mensaje Swift MX
 Formato basado en XML.
 Pain.001 - representa pagos entre
instituciones bancarias.
 Puede incluir más de un pago a la
vez.
Swift MX a Swift
Mensaje Swift
 Formato de texto plano.
 Secciones agrupadas entre llaves.
 Campos empiezan con una
etiqueta entre dos puntos y están
delimitados por CRLF.
 MT101 - representa pagos entre
instituciones bancarias.
 Un solo pago por mensaje.
Swift MX a Swift
Ejemplo de niveles de transformación
 Estructura de datos: un mensaje pain.001 puede generar más de
un MT101. (cardinalidad)
 Tipo de dato: formato de las fechas.
 Representación: de un formato XML UTF-8 a un formato de texto
ascii.
Swift MX a Swift
FIX a CSV
www.volantetech.com
FIX a CSV
Mensaje FIX
 Mensajes transmitidos a través de sockets.
 Formato llave – valor.
 Campos delimitados por caracter SOH (start of heading).
 Mensaje Market Data Snapshot incluye información de mercado.
 Puede incluir información de múltiples entradas.
FIX a CSV
Mensaje CSV
 Mensaje delimitado por comas.
 Primera entrada representa el precio de la entrada.
 Segunda entrada representa la moneda de la entrada.
 Tercera entrada representa la cantidad.
FIX a CSV
Ejemplo de niveles de transformación
 Estructura de datos: para cada entrada en el mensaje
FIX se crea una nueva línea en el mensaje CSV.
 Representación: de un formato FIX llave-valor a un
formato de texto CSV.
FIX a CSV
¿Preguntas?
www.volantetech.com
Información de contacto
Arturo Moreno.
[email protected]
http://www.volantetech.com