The transport proxy method DeleteMessage() failed for adapter XYZ (Bug in Codeplex Adapter Wizard)

February 25, 2009 / Comments Off on The transport proxy method DeleteMessage() failed for adapter XYZ (Bug in Codeplex Adapter Wizard)

Ok, I have seen this error a couple of times on the internet. They all have to do with the same issue. And in my current project i stumbled upon this problem. I found a solution and thought it would be nice to share this with the community

  • You have created an adapter with the AdapterWizard on codeplex.
  • You stress test the newly developed adapter and you get some pretty strange eventLog messages.

Some sample Eventlog messages you could encounter:

Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5796
Date:  2/10/2009
Time:  2:48:45 PM
User:  N/A
Description:
The transport proxy method DeleteMessage() failed for adapter AAA: Reason: “Messaging engine has no record of delivering the message to the adapter. This could happen if DeleteMessage() is called multiple times for the same message by the adapter or if it is called for a message which was never delivered to the adapter by the messaging engine”. Contact the adapter vendor
.

Or you could get

Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5673
Date:  2/10/2009
Time:  2:48:44 PM
User:  N/A
Description:
The Messaging Engine received an error from transport adapter “AAA” when notifying the adapter with the BatchComplete event. Reason “Object reference not set to an instance of an object.”.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Or

Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5675
Date:  2/10/2009
Time:  2:48:44 PM
User:  N/A
Description:
The Messaging Engine encountered an error while deleting one or more messages.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

And even :

Event Type: Error
Event Source: BizTalk DW Reporting
Event Category: None
Event ID: 1000
Date:  2/10/2009
Time:  2:48:45 PM
User:  N/A
Description:
Faulting application btsntsvc.exe, version 3.6.1404.0, stamp 4674b0a4, faulting module btsmsgcore.dll, version 3.6.1404.0, stamp 4674b091, debug? 0, fault address 0x0008fb84.

They all have to do with the same issue.

I compared the code generated by the Adapter Wizard with the code from the HTTP.NET adapter that comes with the samples…..
I found one BIG difference. Here is the code as it is generated by the adapter wizard….

        private IBaseMessage BuildResponseMessage(Stream response,IBaseMessageContext context)
        {
            IBaseMessage btsResponse = null;

            // Get the response stream, create a new message attaching
            // the response stream…
            using (Stream s = response)
            {
                // NOTE:
                // Copy the network stream into a virtual stream stream. If we were
                // to use a forward only stream (as in the response stream) we would
                // not be able to suspend the response data on failure. The virtual
                // stream will overflow to disc when it reaches a given threshold
                VirtualStream vs = new VirtualStream();
                int bytesRead = 0;
                byte[] buff = new byte[8 * 1024];
                while ((bytesRead = s.Read(buff, 0, buff.Length)) > 0)
                    vs.Write(buff, 0, bytesRead);

               response.Seek(0, SeekOrigin.Begin);
               response.Close();

                // Seek the stream back to the start…
                vs.Position = 0;

                // Build BTS message from the stream
                IBaseMessageFactory mf = transportProxy.GetMessageFactory();
                btsResponse = mf.CreateMessage();
                IBaseMessagePart body = mf.CreateMessagePart();
                body.Data = vs;
                btsResponse.AddPart(“Body”, body, true);
                btsResponse.Context = context;
            }

            return btsResponse;
        }

And the code from the HTTP.NET adapter from the BizTalk SDK looks like this :

        private IBaseMessage BuildResponseMessage(WebResponse webResponse)
        {
            IBaseMessage btsResponse = null;

            // Get the response stream, create a new message attaching
            // the response stream…
            using (Stream s = webResponse.GetResponseStream())
            {
                // NOTE:
                // Copy the network stream into a virtual stream stream. If we were
                // to use a forward only stream (as in the response stream) we would
                // not be able to suspend the response data on failure. The virtual
                // stream will overflow to disc when it reaches a given threshold
                VirtualStream vs = new VirtualStream();
                int bytesRead = 0;
                byte[] buff = new byte[8 * 1024];
                while ((bytesRead = s.Read(buff, 0, buff.Length)) > 0)
                    vs.Write(buff, 0, bytesRead);

                webResponse.Close();

                // Seek the stream back to the start…
                vs.Position = 0;

                // Build BTS message from the stream
                IBaseMessageFactory mf = transportProxy.GetMessageFactory();
                btsResponse = mf.CreateMessage();
                IBaseMessagePart body = mf.CreateMessagePart();
                body.Data = vs;
                btsResponse.AddPart(“Body”, body, true);
            }

            return btsResponse;
        }

After I removed the context copy part of the code things started to look much better. No host restarts anymore and no more strange exceptions. It’s logical that copying the entire context from one request message to a response message can cause these problems.

So if you created an adapter yourself with the adapter wizard, check your code to see if the offending line of code is still there. If so, do a stress test on it and see the eventlog messages pop up !.

 

 

Cannot add (custom) pipeline component to the toolbox (You have selected an invalid pipeline component assembly. Please check security settings for the assembly if you are loading it from an UNC path)

February 17, 2009 / Comments Off on Cannot add (custom) pipeline component to the toolbox (You have selected an invalid pipeline component assembly. Please check security settings for the assembly if you are loading it from an UNC path)

If you created a pipeline component with the Pipeline componet wizard it will probably run just fine.

But then comes that moment in time that yoy want to create a new pipeline component that looks just like an already created pipeline, so you decide to copy the code and change some things.
Then you compile the component and you try to add it to the Vizual studio toolbox. And then you get the following message :

You have selected an invalid pipeline component assembly. Please check security settings for the assembly if you are loading it from an UNC path.

Well, you can check whatever you want but it probably won’t help.

Possible causes are :

1. Your Pipeline uses some DLL that’s not in the GAC or pipeline components folder.

2. There is something wrong with the namespaces….. That’s what I am going to cover now.

A pipeline component has the following piece of code…

 private System.Resources.ResourceManager resourceManager = new System.Resources.ResourceManager(“BizTalk.BestPractice.PipelineComponents.AuditingComponent”, Assembly.GetExecutingAssembly());

For descriptions and stuff, the pipeline uses a resource file. The piece of code above tells the pipeline component where the resource file is located.
If the namespace and component name are not exactly the same as the namespace and component name mentioned in the piece of code above you will get that message.

I saw several questions about this in google but none had this solution, so I figured this blog entry would maybe come in handy for someone with the same problem.

 

 

BizTalk HotRod number 5 is now online !

February 12, 2009 / Comments Off on BizTalk HotRod number 5 is now online !

Topics covered :

  • Application Servers: BizTalk vs. Dublin
  • Unit Testing in BizTalk Server 2009
  • Monitoring a WCF Service Using BAM: A Walkthrough
  • Operations Management for BizTalk
  • Governing the SOA Runtime with AmberPoint
  • BizTalk monitoring and exception handling from any desktop
  • Add Governance to BizTalk with SOA Software

So lots of interesting stuff again !. Go to the site of BizTalk HotRod and download your copy >>here<<

Now that BizTalk Utillities is out of business It’s time ………………

February 10, 2009 / Comments Off on Now that BizTalk Utillities is out of business It’s time ………………

BizTalk Utillities used to have a very nice suite of solid adapters. For some reason, Pieter van de Merwe has stopped his business.

We tried for months to get into contact with him to no avail. We called all the possible phone numbers we could find and finally we got somebody on the line.
It was not Pieter himself but someone else working there in the same office. This person mentioned that he believed that BizTalk Utillites were no longer available as a product.
This answer in combination with our results (as to getting into contect with BizTalk Utillities) makes me believe the person on the phone was correct.

If that’s true !

IT’S TIME FOR MICROSOFT  TO WRITE A DESCENT ODBC/ADO ADAPTER FOR BIZTALK !!!

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta