Ejemplos de EMB Switch/Integrator EIP |
En esta página, veremos algunos ejemplos de uso básicos de EMB Switch / Integrator. Con el propósito de entender qué es lo que EMB Switch / Integrator puede hacer por usted, evitando entrar en demasiados detalles, en cada ejemplo solo se muestran rutas básicas. Obviamente cada uno de ellos puede formar parte de su sistema final EMB Switch o EMB Integrator pueden configurarse fácilmente para realizar diferentes tipos de integración para su negocio. A continuación algunos ejemplos simplificados: Ejemplo 1: Ruta para Consulta de Pago de CuentasEste ejemplo muestra como EMB Switch permite construir fácilmente un sistema de "Consulta de Pago de Cuentas" que retorna un "cupón de pago electrónico" para un cliente específico de un servicio específico para uno o más periodos. Aquí se usan elementos EIP de tipo Message y ContentBasedRouter: Message: el mensaje de requerimiento de una consulta de pago de cuenta, tipicamente contiene la siguiente información: Número de cliente, identificador de la empresa de servicios (Compañia de Agua, por ejemplo), y el período. Content Based Router: Usando este ruteador, el requerimiento de consulta será ruteado de acuerdo a su contenido. En este ejemplo el requerimiento será ruteado a diferentes empresas de servicios. Usando estos patrones EIP (Message y ContentBasedRouter), EMB Switch le permite construir un sistema de "Consulta de Pago de Cuentas" muy facilmente: En este ejemplo, EMB Switch puede ser usado para rutear consultas generadas por un terminal de auto-servicio en una sucursal bancaria, para generar cupones de pago, con el cual el cliente puede pagar su cuenta en cualquier cajero de ese banco. Con la ayuda de Content Based Router, el sistema puede rutear la consulta de pago a una empresa de servicios especifica.
Ejemplo 2: Ruta para la Notificación de Pago de CuentasEste ejemplo, como continuación del ejemplo anterior, muestra cómo EMB Switch le permite construir un sistema para "Notificación de Pago de Cuentas", el cual encola requerimiento de notificación de pago de cuentas, y contesta una confirmación cuando la notificación es encolada, para luego realizar la notificación a la compañía correspondiente y contestar una respuesta de "Notificación entregada" al llamador. Aquí se usan los elementos EIP Message, ContentBasedRouter y Guaranteed Delivery: Message: Cuando un Pago de cuenta de servicio es recibida por el cajero del banco, el sistema del banco enviará una notificación de "Pago de Cuenta Recibida" a la empresa proveedora del servicio. Usando EMB Switch, se puede construir fácilmente un sistema de envío de notificaciones, con mucha flexibilidad y alta performance. En este ejemplo, la notificación será encolada en una cola de "Guaranteed Delivery" y un mensaje de confirmación de recepción de la notificación será entregado como respuesta al llamador. Luego, tan pronto la notificación sea efectivamente enviada a la empresa de servicio correspondiente, se envía un mensaje de "Notificación entregada" al llamador. Guaranteed Delivery: Usando mensajería de "Guaranteed Delivery", se garantiza que el mensaje (requerimiento) será entregado a su destino (empresa de servicio). Así, tan pronto el mensaje es encolado se recibe una respuesta de recepción, permitiendo al llamador continuar con su siguiente tarea. Content Based Router: Así como en el ejemplo anterior, cuando una notificación es decolada desde la cola Guaranteed Delivery, será ruteada a la empresa de servicio correspondiente para su procesamiento. Cuando la notificación es procesada, se genera una respuesta "Notificación entregada" y es enviada al llamador. Con los patrones EIP Message, Guaranteed Delivery y ContentBasedRouter, EMB Switch le permite construir un sistema de "Notificación de Pago de Cuentas" muy facilmente: En este ejemplo, EMB Switch puede ser usado para rutear notificaciones de pago de cuentas generadas por el sistema de información del banco, tan pronto como el cliente realice un pago con el cupón generado en el ejemplo anterior. Como puede ver en el diagrama, a diferencia de un switch común "Stop and Wait", EMB Switch puede ser configurado con 2 tipos de mensajes de respuesta: Respuesta de Notificación Recibida y Respuesta de Notificación Entregada, Esta característica permite reducir los tiempos de espera para el cliente.
Ejemplo 3: Ruta para la Mejor CotizaciónEste ejemplo muestra cómo EMB Switch le permite construir un sistema para "Cotizaciones" que entrega cotizaciones de distintos proveedores. Aquí se usan dos elementos EIP: Message: Mensaje de cotización que será enviado a distintos proveedores para cotizar precios de un bien específico, como el precio de un modelo específico de auto, luego los resultados serán comparados y el mejor de todos será entregado al llamador. Aggregator: con aggregator, los resultados individuales pueden ser combinados y procesados como un todo. En este ejemplo, las distintas cotizaciones entregadas por los distintos proveedores serán comparadas y se entregará la mejor. Con estos dos patrones EIP, EMB Switch le permite construir un sistema de "Mejor Cotización" muy facilmente:
Ejemplo 4: Ejemplo de Retiro de Efectivo desde Cajeros Automáticos con Detección De FraudesEste ejemplo "casi real" muestra que EMB Switch permite fácilmente construir una "Operación de Retiro de Efectivo desde un Cajero Automático (ATM)" que registre la operación en un log de auditoría, alimente una Business Intelligent Database para fraudes, si es necesario maneje intercambio entre zonas de seguridad, rutee el requerimiento a los bancos ("On Us" o "Not On Us"), realice nuevamente el intercambio entre zonas de seguridad en el mensaje de respuesta y envíe la respuesta a la base de datos de auditoría y también alimente la base de datos Business Intelligent (BI). Aquí se utilizan varios elementos EIP: Message: Hay varios mensajes utilizados en este ejemplo, el primero, y más importante, es el "Requerimiento de Retiro de Efectivo", el cual típicamente es un ISO 8583, que contiene la identificación del cliente, número de cuenta, identificador del banco, PIN (password). monto del retiro, etc. Para proteger el PIN y otros datos sensibles, tipicamente se utiliza encriptación 3DES, tambien se utiliza MAC para la validación de consistencia del mensaje. Content Based Router (CBR): En este ejemplo se utilizan dos CBRs. Uno se utiliza para determinar si la transacción requere realizar "intercambio entre zonas de seguridad", que implica que la encriptación y el MAC serán cambiados a otra zona de seguridad por el HSM con el criptograma correspondiente y luego, para la respuesta, otro CBR es usado para reversar el cambio de zona de seguridad. Guaranteed Delivery: Usando mensajería Guaranteed Delivery, permite que tanto los mensajes de requerimiento y respuesta sean enviados a las bases de datos de auditoría y BI para detección de fraude. Message Filter: Con la aplicación del filtro de mensajes, aquellos requerimientos considerados sospechosos pueden ser rechazados. Para tomar la decisión correcta, el requerimiento debe ser validado con el sistema de Detección de Fraude (FDS). Request-Reply: En este ejemplo, este elemento es usado para hacer llamadas al FDS, como también al HSM para el cambio de la zona de seguridad. Message Translator: En este ejemplo, este elemento es utilizado para hacer el cambio de la zona de seguridad. Durable Subscriber: En este ejemplo, tanto Durable Subscriber, como Guaranteed Deliver son usados para alimentar las bases de datos de auditoría y detección de fraudes. Con estos patrones EIP, EMB Switch le permite construir un sistema de "Retiro de efectivo desde Cajeros Automáticos con detección de fraudes" muy facilmente:
Opcionalmente, un sistema de Detección de Fraudes (FDS) puede ser utilizado para determinar si el requerimiento es sospechoso, usando el patrón EIP "Request/Reply", el requerimiento será ruteado hacia FDS y validado para determinar si es sospechoso o no. Si la operación es considerada sospechosa, será rechazada y un mensaje respuesta de rechazo será entregada.Como se mencionó anteriormente, esta respuesta tambien alimentará las bases de datos ADB y FDDB. Si FDS no detecta problemas con la operación, el "Content Based Router" ruteará el requerimiento por distintos caminos, si el cliente pertenece al mismo banco del ATM, significa que el requerimiento corresponde a una transacción "On Us", en este caso el requerimiento será enviado directamente al banco "On Us". Si el cliente no pertenece al mismo banco que el ATM, el requerimiento es considerado como una operación "Not On Us", entonces la encriptación del requerimiento debe ser transformado desde nuestra zona de seguridad, a la del destinatario, usando HSM para realizar la operación. Cada banco o red destino tendrá una clave específica, llamada "Criptograma" asociada al HSM para cada operación específica. En este caso, el CBR será usado para determinar cual criptograma usar para llamar al HSM (por ejemplo HP Atalla). Cuando el cambio de zona de seguridad este completo, el requerimiento transformado será ruteado al banco o red correspondiente. Para el llamado a HSM, se utiliza el patrón EIP "Request/Reply". Cuando la red o banco de destino envia una respuesta, y si el cliente no pertenece al banco del ATM, se aplica una reversa del cambio de zona de seguridad, desde la zona de seguridad del destino a nuestra zona de seguridad. Este proceso es el inverso del proceso anterior. Antes que la respuesta sea enviada al ATM, será copiada a la misma cola "Guaranteed Delivery" para alimentar las bases de datos ADB y FDDB. Con esto el proceso está completo.
Preguntas, comentarios, sugerencias? Nos encantaría conocer su opinión! |