Published on Friday, 24th August 2007 .
In a production system, it’s likely that you’ll have multiple hosts (and therefore multiple instances of the btsntsvc.exe process) running on a particular server. If one of the btsntsvc processes is performing particularily badly – e.g. hogging all of your CPU – how do you identify the host?
Fire-up Task Manager and identify the PID of the offending process (if you don’t have the PID column, add it by clicking View -> Select Columns). Armed with that information, use the
tasklist command to view which Windows Service (i.e. Host) relates to the PID, as follows:
tasklist /svc /fi “imagename eq btsntsvc64.exe
The tasklist command will list the processes matching the query string, their PID and service name (something similar to the screenshot below). With your PID from the Task Manager, making the correlation between process and Host is straightforward.
Note that in the tasklist example above, I’m specifically searching for 64-bit processes – if you’re working on a 32-bit system (or you’re search for 32-bit processes on a 64-bit system), your search string will just be ‘btsntsvc.exe’. My Thanks to
Francois Malgreve who originally helped me with this problem.
Published on Thursday, 23rd August 2007 .
My colleague Mike Stephenson has just posted details of the next UK BizTalk User Group meeting to be held at the Edenbrook offices in London on the 12th September 2007.
I’ve missed the previous UK meetings so I’m looking forward to meeting the UK community, it’s also great that my employer is hosting the event!
I received the following e-mail from Joe, regarding a bug I found in BizTalk 2004 when developing maps with XSLT:
Hi! I was reading the post on ureader.com regarding a problem of not having XSLT changes show up when deploying a BT04 project when I saw your response (#2 of your listed solutions) about creating ‘a link from the root note of the source map to the root note of the destination map and delete the link to refresh the map.’ I was wondering if I could get a little clarification on exactly how you created the link. Any thoughts would be greatly appreciated! Thanks! -Joe
The bug Joe is talking about here relates to changes to an XSLT file (with the BizTalk map using that file in the ‘Custom XSL Path’), which do not appear when you re-deploy a project.
As an example, say you have developed a solution using custom XSLT files for your BizTalk map. You test the map in VS and everything works ok, so you go ahead and deploy the project and again, everything works as expected in the runtime environment (say the map is on a Receive Port). However, you notice that the output from the map needs a minor amendment, so you go back into your XSLT, correct the problem and test the map again from within VS – everything works fine. You re-deploy the project and test in the runtime environment and bam, the map hasn’t changed – the changes that were made to the XSLT didn’t get picked up. Huh?
I originally noticed this bug in BizTalk 2004, but have just tested against 2006 (not R2) and can confirm that it is also present in this version. I believe that the bug (?) is due to the fact that the artifact that is compiled (i.e. the map) hasn’t changed, so Visual Studio doesn’t know that the project needs to be re-compiled (the output windows tells me that ‘the project is up-to date’, even though I know I’ve changed the XSLT and it therefore isn’t).
As a work around, I suggest that you open the BizTalk map (not the XSLT) and trick VS into thinking that the map has changed – i.e. create a single link from the source to the destination document (it doesn’t matter which element) and then delete the link. VS will pickup the change and force the project (and your XSLT changes) to be re-compiled.
Happy XSLT-ing!
Published on Tuesday, 24th April 2007 .
I’ve just read this thread over on the BizTalk newsgroups relating to a failing BizTalk 2004 custom receive pipeline following a side-by-side installation of the .Net 2.0 Framework.
I was always under the impression that BizTalk 2004 would ‘just work’ with a side-by-side install of .Net 2.0… obviously not. A fellow poster, Saravana, points us to Microsoft KB Article 841405 – it would appear that BizTalk 2004 versions prior to SP2 cannot run with .Net 2.0 installed alongside. So if you want to run both versions of the framework, upgrade to BTS04 SP2.
Given that this is news to me, I thought I would post to the community (thanks to Saravana for the pointer)!
Published on Thursday, 8th March 2007 .
This is really a post to remind myself not to be quite so stupid in future….
I’ve been developing a custom pipeline disassembling component over the last few days to take a single purchase order from a customer and split into multiple orders based on (potentially) multiple delivery addresses. The component worked well through the Pipeline.exe tool but on testing using messaging (Send Port subscribing to messages from a Receive Port configured with the new component) I kept receiving:
The "FILE" adapter is suspending a message coming from Source URL:"D:\BizTalk Messages\Inbound\Sales Orders\BAA Sales Orders\Order Splitter Test Input\*.xml". Details:"Could not find a matching subscription for the message. ".
In my wisdom, I’d managed to forget that BizTalk is based on a pub/sub model – if I don’t copy the input message properties onto the resultant output messages and promote the message type, the Send Port might struggle to subscribe…..
So, note to self – copy context properties:
// Iterate through inbound message context properties and add to the new outbound message
for (int i = 0; i < pInMsg.Context.CountProperties; i++)
{
string Name, Namespace;
object PropertyValue = pInMsg.Context.ReadAt(i, out Name, out Namespace);
// If the property has been promoted, respect the settings
if (pInMsg.Context.IsPromoted(Name, Namespace))
outMsg.Context.Promote(Name, Namespace, PropertyValue);
else
outMsg.Context.Write(Name, Namespace, PropertyValue);
}
and promote the message type:
// Promote the MessageType property to ensure subscription by orchestrations
string systemPropertiesNamespace = "http://schemas.microsoft.com/BizTalk/2003/system-properties";
string messageType = "http://www.covast.com/schemas/EDI/Accelerator2004#EDIFACT_ORDERS_D_98A_DEFAULT_UN";
outMsg.Context.Promote("MessageType", systemPropertiesNamespace, messageType);
Doh!