Relatórios em SOA (Business Intelligence & Service Oriented Architecture)

Eu tenho SOA com um serviço de empregado e um serviço de viagens. O serviço de viagens criará uma input de ID de viagem para o employeeId no database [Viagem]. O funcionário usará um website “TravelUI” (que chama o Travel Service para armazenar detalhes no database) para solicitar uma viagem. Existe um site “ManagerUI” que será usado pelo gerente para aprovar a solicitação de viagem. O site “ManagerUI” usa o serviço de viagem, bem como o serviço do empregado para obter os detalhes. Quando o gerente aprova a viagem, o registro de viagem (no database [Viagem] é aprovado usando as operações no serviço Viagem.

Nota: Os detalhes do funcionário são armazenados no database [Employee] e o serviço Employee usa esses dados.

Agora, precisamos gerar um relatório com o TravelID, Data de Solicitação de Viagem, EmployeeID, EmployeeName, EmployeePhone. As três primeiras informações são do database [Viagem] e o restante é do database [Empregado]. O relatório deve ser gerado usando o SSRS.

Aqui o problema não é sobre se é possível gerar um relatório combinando dois bancos de dados; mas se tornou um problema complicado devido à introdução de SOA.

  1. Como podemos resolver o problema?

  2. Quais são os erros no meu design que tornaram o problema complexo?

  3. Você tem alguma sugestão para algum artigo bom sobre como lidar com esse problema?

Nota: SOA é planejado usando o WCF aqui.

EDIT : Embora o título menciona sobre Business Intelligence, estou procurando uma resposta que não envolve datamart / datawarehouse principalmente. A resposta do datawarehouse também é bem-vinda – mas o objective principal é sem datawarehouse.

LEITURA:

  1. Inteligência de negócios orientada a serviços http://msdn.microsoft.com/pt-br/library/bb245659.aspx

  2. Uma arquitetura orientada a serviços para Business Intelligence http://www.hpl.hp.com/personal/Claudio_Bartolini/download/soca07.pdf

  3. Arquitetura Orientada a Serviços e Business Intelligence http://www.servicetechmag.com/I53/0811-2

  4. Microsoft no 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-here

O problema do que eu vejo é que o SSRS viola o Padrão de Centralização do Contrato . Em vez disso, seu relatório deve ser gerado a partir dos serviços criados por você ou pela extensão desses serviços. Caso contrário, você cria um acoplamento baseado em tecnologia entre seu relatório e seus bancos de dados, o que tornará mais difícil modificar, migrar ou reimplementar seus sistemas de viagem e de funcionários quando a necessidade se aproximar. Quanto mais relatórios você adicionar dessa forma, mais difícil será transformar a implementação de viagens e funcionários.

Se você ainda não o fez, eu criaria operações de relatório no serviço de viagem, por exemplo, se você estiver usando serviços baseados em SOAP, adicione uma operação GetTravelRequests , que aceita algum tipo de consulta e parâmetros de paginação, que apenas retorna o TravelID. Data, EmployeeID dos registros correspondentes. Em seguida, crie um GetEmployeeTravelRequests , que compõe GetTravelRequests com uma operação GetEmployeeDetails do serviço Employee.

Isso será mais lento do que um relatório baseado no SSRS, mas você está livre para alterar a implementação subjacente dos serviços de Viagem e Funcionário, desde que não altere o contrato de serviço.

Eu presumi que você está usando o SOAP, que é a resposta acima, mas se os serviços RESTful são uma opção, recomendo o seguinte. Em vez de expor um TravelID e EmployeeID numéricos, use URIs . Por exemplo, o serviço de viagens criará um recurso de viagem para o URI do funcionário no database de Travel . Em seguida, crie um feed baseado em Atom de solicitações de viagem. Você pode parar por aí e, onde o usuário do relatório precisar dos detalhes do funcionário, ele poderá seguir o link do URI do funcionário. Caso contrário, você pode usar os URIs dos funcionários para criar um feed Atom composto que inclua os detalhes do funcionário para cada solicitação de viagem.

A principal vantagem desta última abordagem é a carga reduzida do DB através do uso do HTTP Caching; O HTTP GET é a operação mais otimizada do mundo. Seu relatório agora é um relatório ao vivo, em vez de apenas atual, quando pode ser gerado uma vez por dia ou uma vez por mês e se você estruturar seu feed corretamente, as páginas sem header nunca serão alteradas e poderão ser armazenadas em cache por um ano ou mais. Se você assumir que os detalhes dos funcionários mudam com pouca frequência, poderá definir a duração máxima para 1 dia. Nesse caso, uma consulta dos detalhes de um determinado funcionário só atingirá o database uma vez por dia.

Finalmente, outro benefício interessante é que se torna trivialmente fácil adicionar um TravelRequests coleção TravelRequests ao recurso Employee , que contém uma lista paginada baseada em Atom de todas as solicitações de viagem para esse funcionário.

Eu não acho que seu design esteja errado. Sua arquitetura parece estar perdendo um data mart ou warehouse ou algum tipo de meio de suporte a business intelligence além do processamento de transactions.

BI em SOA é um tópico complexo e é impossível dar conselhos sem conhecer alguns detalhes sobre sua arquitetura. Mas aqui estão alguns artigos para você começar:

Você considerou o ESB para o seu SOA? Isso poderia facilitar a integração de um data mart na sua SOA. Veja este artigo: http://www.b-eye-network.com/view/3018

Um dos possíveis usuários de um ESB é um serviço de integração de dados. Na verdade, vários fornecedores modificaram suas ferramentas de integração de dados e de ETL (extrair, transformar e carregar) para serem orientadas a events, de modo que possam consumir mensagens de events de um ESB. Esses events podem transportar informações sobre alterações nos dados de origem, que podem ser usados ​​pelo serviço de integração de dados para atualizar incrementalmente um armazenamento de dados operacionais (ODS) ou um data warehouse. Essa abordagem é particularmente útil para aplicativos operacionais de BI que exigem dados entre dias.

Esse é um bom exemplo do tipo de confusão que pode resultar quando você não está claro sobre suas prioridades de design. E, em particular, para meu gosto, há muita preocupação com os problemas técnicos e não com os requisitos do usuário.

Gostaria de começar trabalhando com as partes interessadas para criar um bom conjunto de histórias de usuários suficientes para identificar o escopo do projeto e listar os resources que serão usados ​​para um teste de aceitação da primeira fase. Suas chances de um projeto bem-sucedido e de reduzir a probabilidade de redesenhar mais tarde, é concordar com uma descrição de uma entrega completa que seja imediatamente útil e forneça um valor óbvio quando a primeira fase estiver completa.

Ele deve ser composto inteiramente do ponto de vista do usuário, sem usar as palavras “database”, “SOA”, “web service”, “API”, etc.

O que você estará construindo será um tipo de contrato entre você e o cliente para um serviço de valor para eles; e uma vez acordado, não deve mudar, exceto para aumentar seu valor para o cliente em seus termos. Portanto, sua melhor aposta é tentar adiar a consideração das questões do “como” até que você tenha o “o que” firmemente estabelecido.

Então você terá a liberdade de considerar várias opções técnicas que podem ser usadas para fornecer o mesmo resultado. Muitas vezes há um projeto de fase um que fornece o suficiente para que funcione; e você quer preservar a flexibilidade de aprender e ajustar o back-end da maneira que achar melhor, desde que o contrato conceitual / design lógico permaneça inalterado.

Na minha experiência, todos ficarão mais felizes se você colocar sua primeira atenção em reagir às expectativas do usuário (que serão preenchidas à medida que todo mundo aprende com o processo) em vez de pré-otimizar a tecnologia. A Microsoft oferece várias maneiras de misturar e combinar e desenvolver um design corporativo. Se você estiver no Agile, lembre-se de começar com o mínimo de desenvolvimento que funciona e, em seguida, iterar como um louco.

Não há como eu ver pelo design que o serviço de viagem não precisará de access ao serviço do funcionário de alguma forma ou forma. Se eles forem operados em isolamento virtual, você terá um problema de gerenciamento de dados mestres apenas esperando para ser mordido.

Recentemente, projetei a arquitetura de um sistema de T & E com os dados de RH dentro da infraestrutura corporativa e o front-end de T & E hospedado como SaaS.

Nesse cenário, o sistema de T & E exigia um nível básico de dados de RH principalmente para garantir que o empregado fosse validado. Também era necessário permitir que o sistema processasse corretamente as reservas de viagem sem exigir que o funcionário reinscrevesse os dados-chave.

Isso foi alcançado com a entrega dos dados básicos do funcionário ao sistema de viagens, primeiro como um carregamento em massa e, depois, por meio de atualizações conforme os dados dos funcionários foram alterados. Isso requer um projeto cuidadoso, já que você está transportando alguns dados de PII, mas um protocolo de transporte seguro e uma boa criptografia entre a origem e o destino mitigam isso.

Relatórios sobre as reservas de viagens e atividades são, então, inteiramente dentro do sistema Travel. Eles precisam ser mantidos em um estado de semi-warehouse para garantir que as alterações nos registros do funcionário base não poluam os registros históricos de viagem. Estas são ‘transactions’ e precisam ser armazenadas como tal.

Com isso em mente, enquanto seu design não está exatamente errado, não é exatamente correto. Você está indo rapidamente para os problemas que você precisa rever seu design para resolver. Minha recomendação geral seria seguir o conselho de @le dorfier e voltar ao começo. Projetar para atender a todos os requisitos do usuário, certifique-se de que eles são requisitos reais e não apenas ‘desejos’ (ou seja, bom ter). O design natural includeá os requisitos não apenas do front end hospedado externamente, mas também do relatório necessário para satisfazer o back-end.

Praticamente tudo o que projetamos hoje deve ser feito com a interoperabilidade em mente, construímos software modular usando componentes e padrões que fornecem acoplamento flexível. Essa flexibilidade nos poupa um esforço incalculável mais tarde e, embora leve mais tempo para projetar, vale a pena o esforço.