Dica Rápida: Schemas Oracle Database no TargetNamespace

Olá Pessoal.

O Adapter Oracle Database tem suas particularidades e esse artigo é mais uma dica para evitar problemas futuros.

O especialista em Biztalk fala muito em schemas, arquivo xsd e etc, mas para trabalhar com o Oracle precisamos entender que o banco de dados tem outra definição para schemas.

Oracle Schema

Schema no Oracle é uma coleção de objetos do banco de dados.

A figura abaixo, representa o schema no banco:

O schema por padrão tem o mesmo nome do usuário, porém em alguns casos pode ter nomes diferentes, e é onde reside o nosso problema.

O Problema

Pois bem, ao criarmos schemas no biztalk, arquivos xsd do Oracle, percebemos que o nome do usuário aparece no TargetNamespace do schema por padrão. Como a seguir:

TargetNamespace COM o Usuário no Namespace
http://Microsoft.LobServices.OracleDB/2007/03/USUARIO/PollingPackage/PACKAGE

Agora digamos que o usuário do ambiente de desenvolvimento seja diferente do usuário de produção. Já captaram o problema? Toda vez que enviasse para a produção teria que alterar todos os namespace para o usuário correto. Trabalhoso e nada prático.


A Solução
Para evitar que isso aconteça, poderiamos alterar a propriedade UseSchemaInNameSpace para False.



É preciso realizar esse procedimento quando criar o arquivo xsd no Visual Studio e na Send/Receive Port para que funcione. E então o TargetNamespace ficará assim:

TargetNamespace SEM o Usuário no Namespace
http://Microsoft.LobServices.OracleDB/2007/03/PollingPackage/PACKAGE

OBS: Apesar do schema não fazer mais parte do TargetNamespace, o Action que é configurado na porta ainda precisa tê-lo, pois é dessa forma que o Adaptador consegue executar a procedure:

Action precisa ter SEMPRE o usuario no TargetNamespace
http://Microsoft.LobServices.OracleDB/2007/03/USUARIO/PollingPackage/PACKAGE/PROCEDURE

O Segundo Problema

Esta seria uma ótima solução se não usarmos Composite Operation.

Composite Operation é uma técnica que permite executar uma procedure para vários registros em um único envio. Essa técnica era nativa nos antigos Adaptadores, mas com o WCF explico essa técnica aqui.

E porque alterar a propriedade UseSchemaInNameSpace para False, com Composite Operation é um problema? Porque o Action do Composite Operation é esse aqui:

Usando o adaptador WCF-Oracle:
http://Microsoft.LobServices.OracleDB/2007/03/CompositeOperation

Usando o adaptador WCF-SQL:
CompositeOperation

Isso quer dizer que o Adaptador vai olhar o próprio TargetNamespace do schema, do arquivo xsd para executar a procedure. Então voltamos ao problema inicial e precisamos colocar o nome do usuario novamente no TargetNamespace do schema.

TargetNamespace COM o Usuário no Namespace
http://Microsoft.LobServices.OracleDB/2007/03/USUARIO/PollingPackage/PACKAGE

A Solução - Melhores Práticas

Para esse caso, não achei uma solução satisfatória para o problema.

Mas, deixo documentado aqui uma sugestão como Best Practice de desenvolvimento.

Continuar com a propriedade UseSchemaInNameSpace setada para True, e ao invés de usar o Usuário no Namespace que é diferente nos ambiente de desenvolvimento e produção, usar um Schema em comum entre eles. Assim quando enviar para produção não irá precisará recompilar tudo novamente com o usuário correto.

Para escolher o schema ao invés do usuário, basta selecionar o schema correto no treeview do wizard, e depois o package desejado.

OBS: Para o package aparecer abaixo do schema no treeview, é necessário compilá-lo no Oracle com o schema correto.

Então o arquivo xsd vai ficar com o seguinte TargetNamespace:

TargetNamespace COM o SCHEMA do Oracle no Namespace
http://Microsoft.LobServices.OracleDB/2007/03/SCHEMA/PollingPackage/PACKAGE

Action com o SCHEMA no TargetNamespace
http://Microsoft.LobServices.OracleDB/2007/03/SCHEMA/PollingPackage/PACKAGE/PROCEDURE

Vimos neste artigo que é melhor usarmos o Schema do Oracle ao invés do usuário para criarmos arquivos xsd.

Espero que possa ajudar alguém.

Até a próxima.