Oct
25

Cumulative Update 2 for BizTalk Server 2010 unconfigures DTA Purge and Archive Job

In case you’ve happened to make a custom configuration on BizTalk Job DTA Purge and Archive (BizTalkDTADb), you have to do an additional step after installing CU2 for BizTalk 2010:  CONFIGURE IT again!!

It is no joke,  nowhere in the documentation of this update it mentions anything about this job. It recently happened to us when a team co-worker of mine installed the update on one of our customers, she took under consideration everything as documented. She even restarted all the BizTalk machines on the Production Environment, but, after a couple of days of BizTalk running after she installed the update, PLOP!  BizTalk was down!  The MessageBox Database was so huge, and nothing, absolutely nothing was processing…  The DTA Purge and Archive was stopped! and Disabled!

Well, after noticing that we just thought about the latest change made on the BizTalk Environment, we couldn’t believe that the update could cause the Job to be disabled and let it completely unconfigured, as it comes out of the box on a fresh BizTalk install, so we proceeded with the whole process installation on one of our Devolpment BizTalk 2010 environments, we reproduce the same configuration that our Customer had and installed the CU2 to see if the update cause the job to unconfigure.  The result was positive,  the CU2 for BizTalk 2010 does unconfigures DTA Purge and Archive BizTalk Job!

Thanks to Alexa, who tested it and prove it all the way!  Smile

Feb
28

ESB Toolkit 2.1 Bug with ESB.ItineraryServices.Generic.Response.WCF service

There is a bug in ESB Toolkit 2.1 when navigating generic ESB.ItineraryService.Generic.Reponse.WCF service, you get the following error:

Microsoft.Practices.ESB.ServiceModel.Helpers.Exceptions+SoapHeaderExtensionException: Error 855000: Could not find schema file for SOAP header ‘ItineraryDescription’ at path C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Generic.Response.WCF\App_Data\ItineraryDescription.xsd

image

To make it work, you have to get the ItineraryDescription.xsd file from a Non-generic service, in my case I got it from the path in C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Response.WCF\App_Data\

Just copy the file ItineraryDescription.xsd from there and Paste it to C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Generic.Response.WCF\App_Data\

Then do a Recycle of the pool under which the service is running, in my case the pool is CoreEsbWcfAppPool.  After that ,do a browse again of the ESB.ItineraryService.Generic.Reponse.WCF service and it should be working already.

Jan
04

The BizTalk Adapter for Oracle Database – Making Polling work

After troubleshooting my previous issues with the connection to the Oracle Database using the Oracle Database Adapter (see my previous post)  I was able now to focus on making the polling to the oracle database work.

I implemented a sample BizTalk solution where I have an orchestration which only has the receive and the send ports.

The Receive is supposed to do the polling by means of a SELECT Statement to a table in my Oracle DB, and the Send Port sends the received message to a FILE Send Port.  That’s it.

image

First I had to import the schemas in the Consume Service Adapter Wizard, on my first try I did it wrong, I imported the schemas without specifying a pollingId, and without specifying the SELECT statement.  What I did was just to get the Select from the Table:

WrongPollingImportingSchemas

This actually imported the schemas.  After setting the MessageType to the imported schema, and deploying my BizTalk Solution I configured my receive and send ports.  The Receive Location was configured with the SELECT sentence in the PollingStatement, and I set the PollingInterval to 60 seconds. Also, this receive location was configured with WCF-Custom Transport Type and OracleDbBinding for the Binding Type. The Receive Pipeline was set to XML Receive.

For the send port, I just made a simple FILE Send Port and configured it with Send Pipeline XML Transmit.

After binding the orchestration to the recently created receive and send ports, and starting the application, the thing never worked.  I was complicating my life more than I had to…

When the application was started, and the polling began, there was an error happening. In the Event Viewer I started to see the following:

There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ Source: “XML disassembler” Receive Port: “Rcv_OraclePolling” URI: “oracledb://dddddd” Reason: Finding the document specification by message type “http://Microsoft.LobServices.OracleDB/2007/03/POLLINGSTMT#POLLINGSTMT” failed. Verify the schema deployed properly.

Well, this wasn’t the schema I was expecting.  I went through some reading and found that the way I had imported the schemas was very wrong.

The right way to do it is as follows.

In the Consume Service Adapter Wizard specify the SELECT query and a Polling Id to identify the query (this will help a lot if you are going to have more than one polling receive location in your BizTalk solution):

setPollingId

SetPollingStatement

After setting this you are set to go.  Click OK and then try to Connect:

SelectingPOLLINGSTMT

You can notice several things here.  First you have a PollingId in the URI string, second in the Contract Type you have to select Service (Inbound Operations), and third, when you click the Root (/) under the Category selection, you will find in the available categories and operations windows the POLLINGSTMT,  WOW!! Yep, this is what BizTalk was expecting from the query polled.

After this you have the right schema, and also you have the Binding for the Receive Location generated (so you don’t have to worry about creating it from scratch).

Then I just change the Message Type to the correct Schema POLLINGSTMT and change the Requests types for the Receive and Send Ports. Then deployed, imported the binding file to create the receive location and that’s it!  It worked!

image

I would finally get my output file as desired.

For some people there must be much easier just to get the Oracle Database Adapter Sample available from http://msdn.microsoft.com/en-us/biztalk/gg491395, well, I actually got the sample and opened in my Visual Studio, the thing was that I never understood that the POLLINGSTMT schema was supposed to be created from the schema generation in the Consume Adapter Service Wizard.  So after spending some time with the errors and reading a bit, a finally got to the understand and get my solution to work.  Hope it helps!

Some good links for understanding Polling:

http://msdn.microsoft.com/en-us/library/cc185291(BTS.10).aspx

http://msdn.microsoft.com/en-us/library/cc185181(BTS.10).aspx

http://msdn.microsoft.com/en-us/library/dd788457(BTS.10).aspx

http://msdn.microsoft.com/en-us/library/dd788193(v=BTS.10).aspx

http://msdn.microsoft.com/en-us/library/dd788064(BTS.10).aspx

Jan
04

Issues when working with the BizTalk Adapter for Oracle Database

Recently I’ve been working on a new project where we have to integrate Oracle within some workflows we are implementing using BizTalk Server 2010.

I have encountered several issues, so I preferred to document the solution as I got them solved.  Hope it helps!

What I needed to do was to have a Polling Receive Location Listening from an Oracle Database. So I had to first test the connection from Visual Studio 2010 and import the schemas, then I had to create the receive location, with Transport Type WCF-Custom and Binding Type OracleDbBinding.  Within the Visual Studio Solution I made a simple orchestration where I have a Receive Port (From Oracle DB) and a Send Port (FILE) so I could see the file that was being generating from the Receive Location.

So, this is how I got it working:

My Environment Configuration

I have my development environment configured as follows:

  • Windows Server 2008 R2
  • Visual Studio 2010
  • BizTalk Server 2010
  • WCF LOB Adapter SDK x64
  • BizTalk Adapter Pack for both x32 and x64 bit machines
  • Oracle 11g Client 11.0.7.0 for both x32 and x64 (One home for each).

Issue 1: Error “Connecting to the LOB System has failed”

When trying to connect to the oracle database while importing the schemas from the Consume Adapter Service Console you get this error:

ErrorConexionOracleVS

In my case was because I had installed only the 64 bit version of the Oracle 11g Client. So I had to install the 32 bit version also.

After installing the 32 bit version, I tested it again and now it worked like a charm.

OracleConnectionConsumeServiceAdapter

Issue 2: Unable to load OraMTS Error when configuring a Polling Receive Location

After I deployed my sample biztalk solution for the polling exercise, I had to create the Receive Location that was supposed to do the polling on the Oracle Database. The Polling Statement was set to a simple SELECT * FROM Sentence. The receive location was configured having the WCF-Custom Transport Type with the OracleDbBinding Binding Type.  The polling interval was set to 60 seconds.  After the receive location was configured, an error kept on showing in the Event Viewer saying that it was Unable to load OraMTS.

For this to be fixed it is necessary to install the Oracle Services for Microsoft Transaction Server.  Since I had both 32 and 64 oracle client versions installed, I installed the Oracle Services for MTS for both:

image

Make sure you restart your machine after this installation, otherwise the error will keep on happening.

Mar
24

Cambio en la extension de Proyectos BizTalk de .btproj a .btproj.csproj

 

Si está utilizando el WCF LOB Adapter SDK SP2, es posible que al tratar de importar schemas  en un proyecto existente de BizTalk (.btproj) por la opcion “Add Generated Items –> Consume Adapter Service” le pase que el proyecto cambie de nombre a .btproj.csproj, y si revisa en la carpeta fisica en donde se encuentra el archivo del proyecto, probablemente verá dos proyectos uno btproj y uno csproj.  Esto es un bug con el SP2 del WCF LOB Adapter SDK.  Para solucionarlo Microsoft ya liberó un hotfix que lo puede solicitar en la siguiente pagina:

 

http://support.microsoft.com/kb/979096

 

Despues de aplicar el hotfix que recibió por correo, no olvide cerrar el visual studio y volverlo a abrir para que los cambios del hotfix tengan efecto. 

Mar
09

Deshabilitar la Encripción de Itinerarios en ESB 2.0

 

Por default, el diseñador de itinerarios del ESB Toolkit 2.0 tiene habilitada una encripción por certificados, lo que ocasiona un error cuando se intenta validar o exportar el itinerario, y no se ha seleccionado un certificado.  El error que se ve es de este tipo:

 

Error    1    A X509 Certificate is required in the model property ‘EncryptionCertificate’ to encrypt any sensitive property in the designer.   

 

Para deshabilitar la opción de utilizar el certificado, y poder validar y exportar los itinerarios sin que aparezca este error, se debe hacer lo siguiente:

1. En el directorio de instalación del ESB ir a la siguiente ruta: C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Tools\Itinerary Designer

2. Abrir el archivo ruleset.config

3. Ubicar la sección <property name="EncryptionCertificate">

4. Colocar en comentario la primera regla. Se debería ver algo así:

<property name="EncryptionCertificate">
            <!–<validator type="Microsoft.Practices.Modeling.Validation.X509CertificateContainerValidator, Microsoft.Practices.Modeling.Validation"
                          messageTemplate="A X509 Certificate is required in the model property ‘{0}’ to encrypt any sensitive property in the designer."
                      name="EncryptingCertificate validator"/> –>
            <!– Warning message when not enforcing encryption –>
            <validator type="Microsoft.Practices.Modeling.Validation.X509CertificateContainerValidator, Microsoft.Practices.Modeling.Validation"
                          messageTemplate="Some data may not be secured because no X509 Certificate was specified in the model property ‘{0}’."
              tag="Warning"        
                      name="EncryptingCertificate (warning) validator"/>
          </property>

 

5. Guardar los cambios.

6. Probar nuevamente y el error ya no debe aparecer.

Nota: Si el error pesiste, puede ser necesario cerrar y volver a abrir el Visual Studio.

Feb
25

BizTalk 2009 Hotfix para arreglar los problemas que se presentan con Visual Studio 2008

Cuando se desarrolla con Visual Studio 2008, proyectos de BizTalk 2009 que referencian otros proyectos de BizTalk que estan en visual studio en una máquina que tiene BizTalk Server 2009 instalado se presenta un error de referencias al compilar o hacer deploy que se arregla con el hotfix que se encuentra en el siguiente link:

 

http://support.microsoft.com/kb/977428/en-us

 

El hotfix se debe solicitar y llega por correo electrónico.

Feb
16

El Script de Instalación del Portal de Administración de ESB (Management Portal) falla en Sistemas de 64 Bits.

 

Si el error que le aparece cuando se ejecutan los scripts (.ps1) de instalación de los ejemplos de ESB y el Portal de Administración es como el siguiente:

 

The term ‘C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com’

is not recognized as the name of a cmdlet, function, script file, or operable p

rogram. Check the spelling of the name, or if a path was included, verify that

the path is correct and try again.

At C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Source\Sa

mples\Management Portal\Install\Scripts\Management_Install.ps1:19 char:3

+     & <<<< $env:VS\devenv.com “$solutionPath\Samples\Management Portal\ESB.Al

ertService\ESB.AlertService.sln” /clean $buildType

    + CategoryInfo          : ObjectNotFound: (C:\Program File…\IDE\devenv.c

   om:String) [], CommandNotFoundException

    + FullyQualifiedErrorId : CommandNotFoundException

 

Es porque usted los esta ejecutando en un Windows de 64 Bits desde la consola de comandos default de 64 bits. Para correr los scripts sin problema, se debe ejecutar la consola de comandos que se encuentra en la ruta C:\Windows\SysWOW64\cmd.exe

 

Con esta consola, se deben ubicar las rutas de instalación de los scripts y ejecutar los .cmd.  El error ya no debería aparecer porque esta consola automáticamente reconoce la ruta C:\Program Files (x86)\  como la default de instalación del Visual Studio.

Nov
04

Welcome to iT Synergy Blog

Welcome!!