Informes en SOA (Business Intelligence & Service Oriented Architecture)

Tengo SOA con un servicio para empleados y un servicio de viajes. El servicio de viaje creará una entrada de travelID para el employeeId en la base de datos [Travel]. El empleado utilizará un sitio web “TravelUI” (que llama al Servicio de viajes para almacenar detalles en DB) para solicitar un viaje. Existe un sitio web “ManagerUI” que será utilizado por el gerente para aprobar la solicitud de viaje. El sitio web “ManagerUI” utiliza el servicio Travel y el Employee Service para obtener más detalles. Cuando el administrador aprueba el viaje, el registro de viaje (en la base de datos [Viajes] se aprueba mediante el uso de las operaciones en el servicio de viajes).

Nota: Los detalles del empleado se almacenan en la base de datos [Empleado] y el servicio del empleado usa esta información.

Ahora, necesitamos generar un informe con TravelID, Fecha de solicitud de viaje, EmployeeID, EmployeeName, EmployeePhone. Los primeros tres datos provienen de la base de datos [Travel] y los remaing pertenecen a la base de datos [Employee]. El informe se generará utilizando SSRS.

Aquí el problema NO es si es posible generar un informe peinando dos bases de datos; pero se convirtió en un problema complicado debido a la introducción de SOA.

  1. ¿Cómo podemos resolver el problema?

  2. ¿Cuáles son los errores en mi diseño que hicieron el problema complejo?

  3. ¿Tiene alguna sugerencia para algún buen artículo sobre el manejo de tal problema?

Nota: SOA se planifica usando WCF aquí.

EDITAR : Aunque el título menciona Business Intelligence, estoy buscando una respuesta que no incluya datamart / datawarehouse principalmente. La respuesta de Datawarehouse también es bienvenida, pero el objective principal es sin datawarehouse.

LEYENDO:

  1. Inteligencia empresarial orientada a servicios http://msdn.microsoft.com/en-us/library/bb245659.aspx

  2. Una architecture orientada a servicios para Business Intelligence http://www.hpl.hp.com/personal/Claudio_Bartolini/download/soca07.pdf

  3. Arquitectura orientada a servicios e inteligencia empresarial http://www.servicetechmag.com/I53/0811-2

  4. Microsoft en Enterprise Service Bus (ESB) http://msdn.microsoft.com/en-us/library/aa475433(v=bts.10).aspx

  5. https://stackoverflow.com/questions/41353/net-esbs-out-there

El problema de lo que puedo ver es que SSRS viola el patrón de centralización del contrato . En su lugar, su informe debe generarse a partir de los servicios que ha creado o extendiendo esos servicios. De lo contrario, se crea un acoplamiento estricto basado en la tecnología entre su informe y sus bases de datos, lo que dificultará la modificación, migración o reimplementación de sus sistemas de viaje y empleados cuando sea necesario. Cuantos más informes agregue de esta manera, más difícil será cambiar su implementación de Viaje y Empleado.

Si aún no lo hizo, crearía operaciones de informes en el servicio de viajes; por ejemplo, si está utilizando servicios basados ​​en SOAP, agregue una operación GetTravelRequests , que acepta algún tipo de parámetros de consultas y paginación, que simplemente devuelve el TravelID, Solicitud de viaje Fecha, EmployeeID de los registros coincidentes. A continuación, cree un GetEmployeeTravelRequests , que compone GetTravelRequests con una operación GetEmployeeDetails servicio del empleado.

Esto será más lento que un informe basado en SSRS, pero usted es libre de cambiar la implementación subyacente de los servicios de Viaje y Empleados, siempre y cuando no cambie el contrato de servicio.

He asumido que está utilizando SOAP, que es en lo que se basa la respuesta anterior, sin embargo, si los servicios RESTful son una opción, entonces recomendaría lo siguiente. En lugar de exponer TravelID ‘s numéricos y EmployeeID s, en su lugar usa URI . Por ejemplo, el servicio de viajes creará un recurso de viaje para el URI del empleado en la base de datos de Travel . A continuación, cree un feed basado en Atom de solicitudes de viaje. Puede detenerse allí y donde el usuario del informe necesita los detalles del empleado, pueden seguir el enlace URI del empleado. De lo contrario, puede usar los URI de los empleados para crear un feed compuesto de Atom que incluya los detalles del empleado para cada solicitud de viaje.

La principal ventaja de este último enfoque es la carga de base de datos reducida mediante el uso de caché HTTP; HTTP GET es la operación más optimizada en el mundo. Su informe es ahora un informe en vivo, en lugar de tan actual como la última vez que se generó, que puede ser una vez al día o una vez al mes y si estructura su alimentación correctamente, las páginas que no son cabezales nunca cambian y se pueden almacenar en caché por un año o más Si supone que los detalles de los empleados cambian con poca frecuencia, puede establecer el máximo de edad en 1 día, en cuyo caso una consulta para detalles de un empleado en particular solo afectará a la base de datos una vez al día.

Finalmente, otro buen beneficio es que resulta trivialmente fácil agregar un recurso de recolección TravelRequests recurso Employee , que contiene una lista paginada basada en Atom de todas las solicitudes de viaje para ese empleado.

No creo que tu diseño sea incorrecto. Su architecture parece estar perdiendo un almacén de datos o un almacén o algún tipo de forma de respaldar la inteligencia empresarial además del procesamiento de transacciones.

BI en SOA es un tema complejo y es imposible dar consejos sin conocer algunos detalles sobre su architecture. Pero aquí hay algunos artículos para que comiences:

¿Has considerado ESB para tu SOA? Podría hacer que la integración de un data mart sea más fácil en su SOA. Vea este artículo: http://www.b-eye-network.com/view/3018

Uno de los usuarios potenciales de un ESB es un servicio de integración de datos. De hecho, varios proveedores han modificado sus herramientas de integración de datos y ETL (extraer, transformar y cargar) para que sean controladas por eventos, de modo que puedan consumir mensajes de eventos desde un ESB. Estos eventos pueden llevar información sobre los cambios en los datos de origen, que pueden ser utilizados por el servicio de integración de datos para actualizar incrementalmente un almacén de datos operacionales (ODS) o depósito de datos. Este enfoque es particularmente útil para aplicaciones operacionales de BI que requieren datos intradiarios.

Este es un buen ejemplo del tipo de confusión que puede surgir cuando no tiene claro cuáles son sus prioridades de diseño. Y en particular, para mi gusto, hay demasiada preocupación con los problemas técnicos y no con los requisitos del usuario.

Comenzaría trabajando con las partes interesadas para crear un buen conjunto de historias de usuarios suficientes para identificar el scope del proyecto y para enumerar las capacidades que se utilizarán para una prueba de aceptación en la primera fase. Sus posibilidades para un proyecto exitoso, y para reducir la probabilidad de rediseñarlo más adelante, es acordar una descripción de un entregable completo que sea inmediatamente útil y brinde un valor obvio una vez que se complete la primera fase.

Debe estar compuesto completamente desde el punto de vista del usuario, sin siquiera usar las palabras “base de datos”, “SOA”, “servicio web”, “API”, etc.

Lo que usted construirá será un tipo de acuerdo contractual entre usted y el cliente por un servicio de valor para ellos; y una vez que se acuerde, no debe cambiar, excepto para boost su valor para el cliente en sus términos. Por lo tanto, la mejor opción es intentar diferir la consideración de los problemas de “cómo” hasta que tenga el “qué” firmemente establecido.

Entonces tendrá la libertad de considerar varias opciones técnicas que podrían usarse para generar el mismo resultado. A menudo hay un diseño de fase uno que solo proporciona lo suficiente para hacerlo funcionar; y desea conservar la flexibilidad para aprender y ajustar el back-end de la forma que considere adecuada, siempre y cuando el contrato conceptual / diseño lógico no se modifique.

Según mi experiencia, todos estarán más contentos si presta su primera atención a la posibilidad de reactjsr ante las expectativas del usuario (que se completará a medida que todos aprenden del proceso) en lugar de optimizar previamente la tecnología. Microsoft le ofrece muchas formas de combinar, combinar y evolucionar un diseño empresarial. Si te gusta Agile, recuerda comenzar con el menor desarrollo que funcione y luego iterar como loco.

No hay forma de que pueda ver en el diseño que el servicio de viajes no necesitará acceso al servicio del empleado de alguna forma o forma. Si se operan en aislamiento virtual, entonces tendrá un problema de administración de datos maestros esperando a morder.

Recientemente diseñé la architecture para un sistema de T & E con los datos de recursos humanos dentro de la infraestructura corporativa y la interfaz de T & E alojada como SaaS.

En ese escenario, el sistema de T & E requirió un nivel básico de datos de recursos humanos principalmente para garantizar que el empleado fuera validado. También se requirió que permitiera que el sistema procesara correctamente las reservas de viajes sin requerir que el empleado volviera a ingresar los datos clave.

Esto se logró al entregar los datos del empleado base al sistema de viajes, primero como una carga masiva y luego a través de actualizaciones a medida que los datos de los empleados cambiaban. Esto requiere un diseño cuidadoso ya que está transportando algunos datos PII, pero un protocolo de transporte seguro y un buen cifrado entre el origen y el destino mitigan eso.

Informes sobre las reservas de viajes y actividades están entonces completamente dentro del sistema de Viajes. Deben mantenerse en un estado de semi-almacén para garantizar que los cambios en los registros del empleado base no contaminen los registros históricos de viaje. Estas son ‘transacciones’ y deben almacenarse como tales.

Con eso en mente, aunque su diseño no es exactamente incorrecto, no es exactamente correcto. Rápidamente llegará a los problemas que necesita para revisar su diseño y resolverlo. Mi recomendación general sería seguir el consejo de @le dorfier y volver al principio. Diseñe para cumplir con todos los requisitos del usuario, asegúrese de que sean requisitos reales, no solo ‘deseos’ (es decir, agradables de tener). El diseño natural incluirá los requisitos no solo para la interfaz externa alojada externamente sino también para la generación de informes necesarios para satisfacer el backend.

Prácticamente todo lo que diseñamos hoy tiene que hacerse teniendo en cuenta la interoperabilidad, construimos software modular utilizando componentes y patrones que ofrecen un acoplamiento flexible. Esa flexibilidad nos ahorra un esfuerzo incalculable más adelante y, aunque lleva más tiempo diseñarlo, vale la pena el esfuerzo.