iT Synergy Blogs

Growing Innovation - Soluciones a problemas reales

Copyright © 2025 · iT Synergy·

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

By Leave a Comment

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

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

By 1 Comment

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

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.

The BizTalk Adapter for Oracle Database – Making Polling work
The BizTalk Adapter for Oracle Database – Making Polling work avatar

By Leave a Comment

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.

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:

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):

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

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!

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