- This topic has 10 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
Here’s the situation:
We have several send ports in our application. Some of them go to webservices we cannot alter (e.g. using the CRM adapter or some calls to the WCF-SQL adapter). Sometimes we need to fetch the response messages, so we use a static solicit-response send port.
The problem is that we’re also receiving a lot of response messages we do not need… Now what is the best way to handle those? The way we do it now, is create an extra send port that fetches all those messages and sends them to a temporary file location. But we don’t like that solution and we hope there is a better solution?
Thanks!
-
Hi,
The question you and your colleagues should be asking yourselves is what do you really want to do with the response messages that are not needed? Do you want to throw them away? Keep and archive them on the file system or a database?
-
Thanks for the reply!
In fact, we don’t want to do anything with those messages… If it were possible, we would not catch them. But when we don’t have a send port that processes those messages, we end up with errors in the event log.
Is there a way to “ignore” those messages?
If not, what is the best way to get easily, rapidely, nicely, … rid of those messages?
-
Hi ChristopheT,
Personally, I would keep the current setup that you have. There is no way for BizTalk to simply “ignore” those unwanted response messages.
Another alternative would be for you to build a custom pipeline component (that will discard the unwanted messages) and use it in the Receive pipeline of any Send port where you are making calls to services and expecting (wanted and unwanted) response messages. This is a better way to handle your situation but it’s not the easiest way to implement, in my opinion.
Daniel.
-
Hi Daniel,
Thanks for the reply!
One more question… If we try and build that custom pipeline, how can we discard the messages we don’t want in that pipeline? Would we need to check the message type for example, and if it’s one of those we don’t want, we just don’t process it any further?
Thanks,
Christophe-
Hi Christophe,
You can interrogate the context of the message (which gets passed to your custom pipeline’s component Execute method), or, if that does not work, you can parse its body part for a pattern that indicates that it is an unwanted message, and if that is found, then return null from the method.
For a sample code of general pipeline component, check the following blog. Please note that for your purpose, you don’t need to rebuild the contents of your message, assign to a memory stream and assign it back to the message body part, as detailed in the example shown by the blog.
Good luck and let me know how you make out on this.
Daniel.
-
Hi,
Maybe you would like to use null adapter? We use it for throwing a dummy message in one of processes (to promote some value in orchestration), and in couple of others – to collect unwanted response messages.
This adapter is free, simple to install, works with both 32 and 64 bit systems. We use it on Windows server 2008/2003, BizTalk 2009 (it also works with BTS 2010)
http://winterdom.com/2005/03/biztalk2004nullsendadaptersample
For installing it – I put the DLL to gac, and run reg file (pay attention that path in reg file is pointing to dll in your file system.)
-
Thanks for the replies!
The solution with the custom pipeline doesn’t seem to work though… If you return null, you get an error in the eventlog saying Object reference not set to an instance of an object”… So I think this means it’s not possible to return null from that method?
The solution with the null adapter seems to work exactly as we wish for! There does seem to be a little issue in getting this adapter to work on a 64-bit environment, though… Isn’t there a good installation-file for that adapter? Or a complete (as in “also for 64-bit”) installation-guide for it?
Thanks!
Christophe-
Hi Christophe,
If you want to give the custom pipeline another shot, I found this statement somewhere on the internet:
“Say that you want to write a custom pipeline component that writes some data into a database and
don’t want to include further BizTalk processing. Once the database write is successful you do not
need the message anymore. You do not want the engine to write any data into the message box,
basically one message gets into the pipe and none goes out.
What you need to do to support this scenario is to return null from the IComponent.Execute,
IDisassemblerComponent.GetNext or IAssemblerComponent.Assemble methods“See if you can make this work, otherwise go with Yonathan’s example.
Daniel.
-
Hi,
If you intend to use the null adapter, it should be registered with “32 bit” reg (read this article http://www.biztalkgurus.com/blogs/biztalksyn/archive/2008/04/23/registering-null-adapter-on-64-bit-machines.aspx )
I downloaded solution for null adapter from winterdome site, and compiled the adapter. There’s no installer, but you can write one 😉
For me, it’s just ll wich needs to be in GAC and registered with *.reg file. Very simple, very useful.
-
Thanks again! 🙂
About the custom pipeline component:
That’s what I did, indeed 😉 But I keep on getting that error… It’s strange though, because I find the same information when I google a bit for the problem. It seems there must be something else wrong with my piece of code? When I step through the code (debug it), it gives no errors. But when I check the eventlog afterwards, I get the “object reference not set to an instance of an object” errors…Here’s the piece of code I’m using:
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
string messageTypeIncomingMessage = “”;
object oMessageType = inmsg.Context.Read(“MessageType”, “http://schemas.microsoft.com/BizTalk/2003/system-properties“);
if (oMessageType != null)
{
messageTypeIncomingMessage = (string)oMessageType;
messageTypeIncomingMessage =
messageTypeIncomingMessage.Substring(messageTypeIncomingMessage.IndexOf(‘#’) + 1);
}// Make sure the properties aren’t null and the messageType was found
if (!String.IsNullOrEmpty(messageTypes)
&& !String.IsNullOrEmpty(messageTypeIncomingMessage))
{
String[] messageTypesArray = messageTypes.Split(new char[] { ‘;’ }, StringSplitOptions.RemoveEmptyEntries);// Loop all elements to check if the message needs to be ignored
for (int i = 0; i < messageTypesArray.Length; i++)
{
string messageTypeFromArray = messageTypesArray[i];
if (messageTypeIncomingMessage == messageTypeFromArray)
{
// messageType was found -> message needs to be ignored
return null;
}
}
}return inmsg;
}About the null adapter:
Thanks a lot for the information about the 64-bit systems! This adapter works like a charm and does exactly what we need it to do! Great! 🙂
-
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.