Gostaria de propor um exercício. A ideia é cada um indicar uma solução abstracta e "opinar" sobre prós e contras da mesma.

Imaginem o seguinte cenário:

1. Precisam de importar alguns dados externos para a vossa base de dados, efectuando algumas validações de negócio;
2. Os dados provêm actualmente de 3 entidades externas, com formatos diferentes, e não há previsão de mais entidades poderem gerar dados nos próximos 2/3 anos;
3. Apesar de os dados serem homogéneos entre as entidades, os formatos originados por essas entidades são distintas, sendo um em CSV, outro em DBF e outro em XML com um schema pré-definido e acordado;
4. Os dados são submetidos uma vez por més e têm um volume actual inferior a 1MByte;
5. Os dados terão que obrigatóriamente ser submetidos recorrendo a uma extranet ao qual cada entidade tem acesso, e será obrigatóriamente um processo de submissão manual;
6. A entidade que aceita os dados possui uma plataforma de integração (home made), que serve de broker para todos os serviços de negócio. Essa plataforma terá que ser, obrigatóriamente, envolvida como ponto de submissão dos dados pela aplicação web denominada extranet, mas poderá depois delegar o processamento a outra solução;
7. Todos os dados terão que ser validados com regras de negócio antes de serem definitivamente importados, apesar de a mesma validação poder ser efectuada de forma assíncrona; (há que garantir que dados incoerentes não são importados. apenas isso...)
8. O destino final dos dados serão bases de dados como DB2, ORACLE ou Sql Server;

Outros requisitos:

1. A plataforma de eleição é Win(X) + .NET;
2. Qq solução deve reutilizar licenças já existentes :)

Qual a macro solução que propunham para o cenário ?

Alguns pensamentos perdidos enquanto penso no problema:

• Importação custom made, recorrendo a WCF com msmqbinding, e estratégias de importação diferentes por ficheiro (strategy design pattern)
• Importação custom made, mas desenhada com WWF + WCF;
• Biztalk ? Não existe por enquanto BTS nesta entidade...  Mas pode vir a ser necessário...
• Sql Server 2005 Integration Services  (existe SQL Server 2005). Lógica de negócio nas integrações executadas no motor de base de dados ? Ahh... e o destino dos dados é 99% não Microsoft;
• Não importar nada e deixar como está. Obrigar o utilizador a introduzir os dados manualmente :)

Comentários, críticas, sugestões, alternativas, etc, são aceites desde que construtivas. Se acharem que o espaço do fórum não é suficiente para submeter uma solução, podem sempre submeter o link para o vosso blog pessoal.

Obrigado!

Disclaimer: O caso apresentado é baseado em pura ficção e não traduz de forma indirecta ou directa qq semelhança com a realidade, nem representa a opinião do meu empregador.

Algumas questões.

Os dados são independentes uns dos outros?

• A nível de entidade. Preciso dos dados das várias entidades, para importar ou posso importar entidade a entidade?
• Dentro da mesma entidade. Qual é o atomo a integrar? Uma linha? ou existem dependências entre linhas?

 Qual é o peso (computacional) de integrar cada linha?

Cada bloco de dados (ficheiro) de uma dada entidade, tem que entrar como um todo? ou serão apenas rejeitados linhas (ou N linhas, caso existem dependências) os erros?

Qual é a complexidade de integração de cada atomo de dados? (complexidade de processo/algoritmica)

Estamos a falar de um processo de integração transacional ou transacional com sagas (esquema de compensação)?

Acho q por ora não me lembro de mais nada. :-)

tspascoal:

• A nível de entidade. Preciso dos dados das várias entidades, para importar ou posso importar entidade a entidade?

R: podes importar entidade a entidade. Os dados não estão de forma nenhuma relaccionados.

tspascoal:

• Dentro da mesma entidade. Qual é o atomo a integrar? Uma linha? ou existem dependências entre linhas?

O átomo é o cabecalho + detalhe. As unicas dependencias que existem são sobre cada cabecalho, não poder ser importada nenhuma linha sem que todas as linhas sejam importadas.

tspascoal:

 Qual é o peso (computacional) de integrar cada linha?

Cada linha de cabecalho tem < 10 campos, cujo tamanho total não excede os 100bytes. Cada linha de detalhe é constituida por dois campos, data e texto livre (blob). GERALMENTE, cada texto livre não excede os 10KB.

O peso é olhar para a linha (cabecalho) e verificar as seguintes operacoes:

- verificar se a entidade de negócio para o qual os dados correspondem, existe.
- verificar se alguns dados de lookup, constantes no cabecalho existem nos sistema destino. Ex: tipo de processo (imaginemos que um cabecalho é um processo)
- importar a linha. Esta importação corresponde, geralmente, a inserir o cabecalho numa tabela, e os detalhes noutra.

tspascoal:

Cada bloco de dados (ficheiro) de uma dada entidade, tem que entrar como um todo? ou serão apenas rejeitados linhas (ou N linhas, caso existem dependências) os erros?

respondido acima. a atomicidade é vista a cada linha de cabecalho. Imaginemos dentro da estrutura XML, algo do género:

<Cabecalho>
  <Campo1>a</Campo1>
  <Campo2>a</Campo2>
  <Campo3>a</Campo3>
  <Detalhes>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
  </Detalhes>
</Cabecalho>
<Cabecalho>
  <Campo1>b</Campo1>
  <Campo2>b</Campo2>
  <Campo3>b</Campo3>
  <Detalhes>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
    <Detalhe>
      <Data>
      </Data>
      <TextoLivre></TextoLivre>
    </Detalhe>
  </Detalhes>
</Cabecalho>

A atomicidade é por elemento cabecalho.

tspascoal:

Qual é a complexidade de integração de cada atomo de dados? (complexidade de processo/algoritmica)

respondido acima..

tspascoal:

Estamos a falar de um processo de integração transacional ou transacional com sagas (esquema de compensação)?

Boa questão. É simples: Ou importa, ou não importa. Se não importa, avisa um utilizador de manutenção. A origem dos dados não precisa de compensar nada. No destino, não esquecer que a importação de cabecalho é transaccional.

mais algumas questões:

• os serviços expostos pelo broker (6) já efectuam as validações de negócio pretendidas ou as validações que falas em (7) teriam que ser executados pelo importador?
• estás a apenas a pensar em cenários de consolidação master-slave (actualização de dados de entidades já existentes) ou de "sincronização" (actualização de entidades já existentes e criação d enovas entidades)?
• é a plataforma existente (6) que sabe o destino dos dados (8) ?

---

- Paulo

Paulo Sousa:

• os serviços expostos pelo broker (6) já efectuam as validações de negócio pretendidas ou as validações que falas em (7) teriam que ser executados pelo importador?

o broker apenas é encarregue de inspeccionar a mensagem e executar serviços horizontais a toda a plataforma: autenticacao, autorizacao, logging, auditing, etc. Normalmente, não executa negócio...

Paulo Sousa:

• estás a apenas a pensar em cenários de consolidação master-slave (actualização de dados de entidades já existentes) ou de "sincronização" (actualização de entidades já existentes e criação d enovas entidades)?

Sincronização. Mas um dado bastante relevante é que os dados nunca são alterados depois de importados. A ideia é importar todos os dados. Uma espécie de offline...

Paulo Sousa:

• é a plataforma existente (6) que sabe o destino dos dados (8) ?

Neste momento não. A plataforma só deve ser envolvida porque é o ponto central de publicação de serviços, e as funcionalidades horizontais (auth/authz/etc) são fornecidos por ela.

um abraço

Boas Hugo,

em termos puramente tecnológicos, para o tipo de cenários que descreves, e com o meu background, optaria pelo Sql 2005 Integration Services ou pelo BizTalk 2006. Uma vez que tens os diversos formatos, assincronicidade, e as necessidades de validação, optaria de imediato por este último. Validações complexas poderiam ser feitas pelo Rules Engine do BizTalk, por exemplo.

Em termos de transporte, se isso for um issue, recorreria se possível a um dos adapters já existentes no produto. Definiria schemas para cada um dos formatos, e utilizaria um pipeline para fazer debatching de registos individuais. Este pipeline poderia ser usado ou na componente de messaging, ou invocado de uma orquestração, que poderia ter as chamadas às regras (as regras tb podem ser chamadas no Pipeline, mas supondo que pudessem ser mtas validações, seria melhor na orquestração).

O BizTalk tb poderia ser usado, possivelmente com os adaptadores nativos, para fazer a escrita nos sistemas destino que referes.

Aquilo que poderia de alguma forma limitar (a meu ver) a utilização de um produto destes seria eventualmente um elevado volume de dados, mas 1Mb são "peanuts".

Em termos das alternativas tecnológicas que descreves, se houver disponibilidade para a utilização de um produto como o BizTalk 2006, parecer-me-ia de longe a solução mais vantajosa e com menos desenvolvimento, e que encaixa perfeitamente nos cenários típicos em que este tipo de produtos é mais proveitoso.

Pelo que é descrito, não usaria o biztalk.

Segundo depreendo isto é puro GIGO, as validações de negócio são simples (famous last words), não necessitam de orquestrações, se acrescentarmos o facto de que não usam biztalk, a introdução do biztalk era mais uma peça a adicionar ao que já tem (com todos os problemas que isso tem, licenciamento, máquinas, tempo de startup, know how, integração no sistema de monitorização, treino das equipas de suporte operacional,etc,etc).

Portanto, se não tem biztalk e (isto é que é definiria na minha opinião a decisão), não tem previsto passar a usar bts no futuro para outras situações em que seria um fit perfeito, então não se justifica passar a utilizá-lo só por isso.

Uso de workflow. Presumo que aqui a questão se prenda, passar a utilizar o WWF como orquestrador dentro do broker, se for essa a pergunta. Então aqui já não tenho tanta certeza.

Se o objectivo do broker, for (também para além do que já oferece) passar a ter algumas orquestrações de negócio lá dentro, então o WF seria uma boa solução, e uma processo com uma complexidade de fluxo tão pequena poderia servir como um bom teste/aprendizagem de integração no WF dentro do broker (se os custos de aprendizagem/startup forem aceitáveis). Claro que aqui se põe a questão, será que o broker + WF a certa altura não é um biztalk? :-D

Tendo em conta que em termos de negócio um processo simples (again famous last words), com validações de negócio simples sendo a sua maioria a nível de validação de dados, diria q o SSIS (pelo pouco que já tive oportunidade de ver) seria um bom fit para o problema.

O facto de haverem dados não Sql Server, não tem problema. o SSIS não são só DTS com esteróides, é já uma ferramenta de ETL. (ou pelo menos um desiderato :-))

Tiago,

tens razão relativamente ao que dizes, efectivamente existem condições à utilização de BizTalk, e a infraestrutura, licenciamento, e know-how necessários podem ser fortes condicionantes. O que me agrada nesta solução, no entanto, bem como numa baseado em algo tipo SSIS, é a possibilidade de fazer as integrações com um mínimo de desenvolvimento.

Nesta óptica, uma solução usando WF não me pareceria acertada para processos importantes. Não só obriga a bater algum código (p.ex. no DAL), como não inclui qualquer aplicação de gestão/monitoria, que teria também de ser desenvolvida. Especialmente se se tratam de processos importantes do ponto de vista de negócio. O facto de o WWF dispôr de um motor de regras, apesar de com características algo distintas do do BizTalk, é no entanto um ponto a favor.