Resolvendo Erro de Send Pipeline XMLTransmit

Considere o erro abaixo:

“There was a failure executing the send pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLTransmit, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML assembler" Send Port: "SAP_SendPort" Reason: This Assembler cannot retrieve a document specification using this type: "http://schemas.microsoft.com/BizTalk/2003#QIRF_GET_INSP_POINT2_Request".

Esse erro é gerado ao enviar mensagens do tipo “http://schemas.microsoft.com/BizTalk/2003#QIRF_GET_INSP_POINT2_Request” para a Send Port usando o Pipeline XMLTransmit, sendo que provavelmente existem dois schemas publicados com o mesmo Root e Target Namespace.

Para resolver, é preciso mudar um dos schemas, ou usar o Pipeline PassThruTransmit.

 

Até mais!

Leia mais »»

Resolvendo Erro Acessando Campo Promovido

Considere o seguinte erro:

“A failure occurred while evaluating the distinguished field MESSAGE_ID against the message part data. The message part data does not contain at least one of the nodes specified by the XPath expression (listed below) that corresponds to the distinguished field. The cause for this error may be that the message part data has not been initialized or that the message part data does not conform to the message part schema. Ensure that the message part data is initialized correctly.”

Isso quer dizer que o campo MESSAGE_ID, que está sendo acessado, não existe na mensagem.

Provavelmente, ao mapear a mensagem, o MESSAGE_ID foi mapeado sem valor, ficando nulo, e ao tentar acessar o campo, apresenta o erro.

Para resolver, no mapeamento, o campo MESSAGE_ID deve conter um valor qualquer, para que ele passe a existir na mensagem, podendo ser acessado.

Bom, é isso. Até a próxima!

Leia mais »»

Chamar dinamicamente uma orchestration com shape “Call Orchestration”

Usar o shape de “Call Orchestration” nos obriga a adicionar a referencia do projeto que inclui a Orchestration que vai ser chamada. Mas isso tem um grande inconveniente: se 100 projetos usarem essa Orchestration, quando houver alguma atualização, vou precisar excluir as 100 Orchs do Console para conseguir fazer o Update.

Então quais seriam as opções disponíveis chamar a orchestration dinamicamente?

1. Publicar a orchestration como Web Service. Problemas: Envolve o IIS, que em caso de grande demanda poderá ficar fora.
2. Usar direct port. Apesar de cair um pouco a performance, seria uma boa opção se a orchestration não retornasse nenhuma mensagem, exigindo uma porta de request-response.
3. No caso de request-response usar a direct port com self-correlation. Problemas: volta ao problema original de criar uma dependência entre os projetos, pois devemos usar a mesma porta nas duas orchestration.

Pesquisando na internet encontrei em um blog a solução perfeita: uma forma de passar o Assembly da Orchestration de forma dinâmica para o shape “Call Orchestration”.

No blog, ele sugere criar uma Dll que imita uma orchestration, ou seja, fazer uma orchestration customizada sem a parte gráfica. Nessa “orchestration”, recebe dois parâmetros, o Assembly da orchestration e um ArrayList com os parâmetros que deverão ser passados.

Muito inteligente a solução e realmente funciona. No blog o autor coloca um link para baixar o exemplo, com a Dll, orchestrations e exemplo de como utilizar o shape Expression para chamar a orchestration (precisa adicionar referência).

Segue o endereço do blog.

http://www.jonfancey.com/default.aspx?key=2007-03-07T09:08:12Z

Eu também disponibilizei um exemplo, baseado no que ele fez. Segue o link.

http://dynamicinvocation.codeplex.com/

Até a próxima! Espero que tenham gostado. :)

Leia mais »»

Projetos somem do Biztalk Administration Console ao aplicar o deploy em outro projeto

Imagine três projetos numa mesma Solution, sendo que um deles (projeto Common) é compartilhado pelos projetos A e B, e ao aplicar o deploy em um deles, o outro projeto some do Biztalk Administration, ficando somente o projeto Common e aquele em que foi aplicado o deploy.

Isso acontece porque a solution esta configurada para republicar os projetos. Então cada vez que é aplicado o deploy, é feito o Redeploy também no projeto Common, excluindo os Resources do Biztalk Administration Console.

Para resolver precisamos alterar as propriedades, clicando em cima da solution com o botão direito, e em “Properties”. Ou Clique no botão “Configuration Manager” na opção “Configuration Properties”, que pode ser acessado clicando com o botão direito e em “Properties” de qualquer projeto.

Deverá abrir uma tela igual a essa:

Tenha a certeza de que a opção Deploy esteja desmarcada, caso contrário causará o problema mencionado.

Espero que esse post possa ser útil.

Leia mais »»

Resolvendo problema de caracteres especiais IDOC - SAP Adapter

No mundo de TI é mais do que comum nos deparamos com erros que parecem inexplicáveis, e receber IDOC do SAP com informações cortadas em alguns campos, desposicionando todo o Flat File,  é um desses casos.

Isso acontece porque quando geramos o schema do IDOC, o padrão é vir com o Code Page UTF-8, que não aceita caracteres especiais, simplesmente os ignora, cortando a informação.

Para entender melhor, vamos supor que o Biztalk deve receber um IDOC como abaixo:

Porem ele chega assim:

Para resolver devemos alterar o Code Page para Western-European.

OBS: Se o Receive Pipeline e o IDOC em questão estiverem em projetos separados, os dois projetos devem ser republicados (opção Deploy) com a nova alteração.

Leia mais »»