by community-syndication | Sep 28, 2004 | BizTalk Community Blogs via Syndication
Since Virtual Server has been released, I got asked the question several times so I figured I’d put the answer here where everybody can find it. Knowledge Base Article 842301 says something like:
Current released versions of BizTalk (2000, 2002 ,2004) in any flavor (Enterprise, Developer …) are “best effort support” on virtual machines (Virtual PC and Virtual Server). Any case opened with Microsoft Support will be supported on a best effort basis and you may be asked to reproduce the problem on physical hardware during the course of troubleshooting the issue.
Not supported does not mean that it will not run: it may very well run fine or you may run into subtle issues. Not long ago a Microsoft Technology Specialist attempted to run BizTalk on a three weeks development project. According to him, this is not worth wasting the effort again. They ran into issues and none of them reproduced on real hardware. I am sure we can find individuals who have been running BizTalk on Virtual PC / Virtual Server without any problem so far. It probably depends on what you are doing.
If you feel lucky and want to try it out by yourself, this thread (chosen among many others) discusses some tips that might help you. While running a BizTalk server on a virtual machine for development purposes might be fine, I would definitely advise against running a production server under a virtual machine.
by community-syndication | Sep 28, 2004 | BizTalk Community Blogs via Syndication
Knowledge Base Article 838454 describes the new Microsoft.BizTalk.MessageBoxOM.MessageArchive object that was added to Microsoft.BizTalk.MessageBoxOM.dll. Currently, the package is only available through Microsoft Support.
There are a few things that this KB Article does not describe: remember that the Microsoft.BizTalk.MessageBoxOM.dll file is in the GAC. Currently, Visual Studio.NET 2003 does not allow you to add references to components in the GAC. To get past this, you can choose one alternative between these two solutions:
1 – Extract the dll from the GAC to a place where you can add reference to it (perhaps C:\<yourprojectdirectory>)
In a DOS prompt, run the following command:
copy %systemroot%\assembly\GAC\Microsoft.BizTalk.MessageBoxOM\3.0.1.0__31bf3856ad364e35\Microsoft.BizTalk.MessageBoxOM.dll <destination_path>
Where <destination_path> has been replaced by the path to your BizTalk project’s directory (for instance C:\MyProject)
2 – Manually edit the Visual Studio Project file (.csproj, .btsproj, .etc)
To add a reference to this assembly you must edit the project file (.csproj, .btproj, .etc) in a text editor. The following code snippet shows the code that must be added to the reference element of the project file to reference the assembly:
<Reference
Name = “Microsoft.BizTalk.MessageBoxOM”
AssemblyName = “Microsoft.BizTalk.MessageBoxOM”
HintPath = “<SystemRoot>\assembly\GAC\Microsoft.BizTalk.MessageBoxOM\3.0.1.0__31bf3856ad364e35\Microsoft.BizTalk.MessageBoxOM.dll”
/>
by community-syndication | Sep 25, 2004 | BizTalk Community Blogs via Syndication
I’m over in Redmond currently for a couple of weeks working with the Biztalk Design Wins team doing some performance tuning on a solution for one of my customers, I’ve also been having a lot of fun catching up with my colleagues and friends from the product group, and hearing about some of the great work they are doing for future versions. During this work we have gotton some interesting data that I thought was worth sharing.
As you will have seen from one of my previous post’s, marking a port as Delivery Notification = Transmitted provides a great mechansm to allow an orchestrations to know whether a message was actually transmitted successfully as opposed to simply being successfully published to the message box. There is of course a performance cost for using delivery notifications this goes without saying. The reasons for the performance hit being two fold, firstly, the load on the engine and the message box will be increased since for every transmittion an ACK or NACK will be created, published and routed to the orchestration instance that transmitted the message. Secondly, the execution of the orchestation instance is serialized whilst the message is being transmited, of course, some of the cost of this serialized processing will be recovered by the additional concurrency from other orchestration instances running whilst a particular insance is dehydrated waiting for an ACK/NACK.
In general the cost of using delivery notifications is of course dependant on the design of the orchestrations and ports, but as a rought rule of thumb, the performance cost is around 50%, though for one scenario we did see that using delivery notification gave approaximately 30% the performance of the same solution not using them.
by community-syndication | Sep 25, 2004 | BizTalk Community Blogs via Syndication
Kevin Lam has recently started a blog, be sure to check it out, Kevin works in the Biztalk Design Wins team and I’m sure he’ll share some of the great experience he has gained designing and building enterprise solutions on Biztalk.
by community-syndication | Sep 24, 2004 | BizTalk Community Blogs via Syndication
You might have received this error message if you followed these steps:
- Install BizTalk 2004 on a clean machine with Visual Studio .NET 2003,
- Start Visual Studio and Create a new C# project (Windows Application for instance),
- Save the solution/Project,
- Right click on the project name in the solution explorer and select “Add-> New Item …”,
- Click “Data Set” and press “OK”,
You see the following error message (the path under the white box is the path to the XSD that has been created when you inserted the DataSet):
When you install BizTalk, there is a component called “BizTalk developer tools”. This component contains all the logic to integrate with Visual Studio .NET 2003: pipeline designer, BizTalk Explorer and among many other things, a schema editor.
The error you are seeing is because the BizTalk Editor is trying to edit a DataSet schema and got confused. To workaround this, you have to ensure that DataSet schemas are opened with the Visual Studio Schema Editor and not the BizTalk Schema Editor. Here are two different workarounds:
- Bypass the BizTalk Schema Editor when editing the schema (works around the problem once)
- Reset the default editor to the Visual Studio Schema Editor instead of the BizTalk Schema editor (puts the Visual Studio Schema Editor back as the default XSD editor)
Bypass the BizTalk Schema Editor when editing the DataSet:
- Open the solution in VS.NET 2003
- Insert the DataSet as explained above (steps 4 and 5). You see the error, but you also see that the DataSet item was created and added to the solution explorer
- Click “OK” to close the error box
- In the solution explorer, locate the schema and right click on it
- Select “Open With …”
- In the dialog box, select “XML Schema editor” and click “Open”
Set the Visual Studio Schema Editor back to default editor:
- Follow the steps 1 to 5 above
- In the “Select XML Schema Editor” dialog box, select “XML Schema Editor” and click “Set as default”.
- Press OK to open the DataSet
Ravi, I hope this page helped you in case you missed my answer in another group.
by community-syndication | Sep 24, 2004 | BizTalk Community Blogs via Syndication
Waaw… Finally got my new paper published. Like I already promised a while ago, I was working on a sample and paper, showing how custom pipelinecomponents can be created. Even better: the paper and sample code will show you how to create a *streaming* pipelinecomponent that is able to put data into the msgcontext based upon an XPath expression.
“How’s that possible? XPath only works on a DOM Christof – you never can make this streaming!” Yes I can, because of Dare Obasanjo, who recently published a paper and sample code on so called “streaming xpath”, which makes up a subset of XPath that can be handled in a streaming, forward-only, way.
For all those funky things: visit the Belgium MSDN site here!
All feedback is welcome, please enjoy this!
by stephen-w-thomas | Sep 24, 2004 | Downloads
This sample shows how to use Delivery Notification on a Send Port to catch and react to adapter send errors inside an Orchestration.
Key Take Home Points:
– Delivery Notification is not available on Early Bound Ports.
– Must import System.Web.Services to cast the SOAP exception
– Set Send Port retries to 0
– Must use a Synchronized scope
– Does not work with Send Port Groups
Get more information from the original blog post on this topic: https://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/08/02/biztalk-delivery-notification-and-nack-sample.aspx
by stephen-w-thomas | Sep 23, 2004 | Stephen's BizTalk and Integration Blog
I have talked in the past about NACKs. These are great little messages that allow you to receive the status of your sent messages inside your Orchestration. For more information on NACKs, please see my earlier post and sample.
The problem I want to point out here occurs if you want to map on the Send Port and have Delivery Notification set to Transmitted inside the Orchestration. I have found that everything works great as long as your map is successful. ACKs and NACKs are returned as expected.
If the map on the Sent Port fails is when you have a problem. In this case, no ACK or NACK is sent back to the Orchestration since the message never reached the pipeline. The Orchestration will remain running and eventually dehydrate still waiting hopelessly for the ACK or NACK to return. In addition, the message that was sent gets set to Active and the status is set to Delivered, not consumed. I have not been able to get the sent message to do anything other then Terminate and even that took some effort.
I have updated my NACK sample to include a map that fails in case you want to test it out for yourself. The updated download is available here. Just add the map to your Send Port. If you want to create your own map, just add a scripting functoid that throws an exception.
Take Away: Be mindful of mapping in the Send Ports if Delivery Notification will be transmitted back to the Orchestration.
by community-syndication | Sep 23, 2004 | BizTalk Community Blogs via Syndication
Yet another frequently asked question. When using the BizTalk 2004 Administration Console, isolated hosts always report “Status unavailable” (see below).
BizTalk Server 2004 offers two kind of hosts: In-Process Hosts and Isolated Hosts. In-Process Hosts run in the same process as BizTalk and can be used to run orchestrations, run any send adapter and run the MSMQ or FILE receive adapters. Isolated Hosts can only run HTTP/HTTPS/SOAP receive adapters. From a pragmatic point of view, an Isolated Host is essentially an ISAPI extension running under the control of IIS. In BizTalk 2004, this ISAPI is called
BTSHTTPReceive.dll. The documentation page “
About Hosts” explains:
Isolated hosts primarily host adapters that must run outside of the normal BizTalk Server runtime process. For example, you use isolated hosts to host adapters for external processes such as ISAPI extensions and ASP.NET.
[…]
The status of an isolated host is always Status Unavailable. BizTalk Server does not access the status information for external processes.
So it is absolutely normal for an isolated host to report “Status unavailable”. It should not happen for an in-process host.
by community-syndication | Sep 22, 2004 | BizTalk Community Blogs via Syndication
Today, we continue our deep dive into the undocumented and unsupported bowels of the BizTalk artifacts compiler and examine how pipelines get compiled to .NET assemblies. Pipelines allow to adjust the format of inbound messages to something that is suitable for processing. There are two kind of pipelines: Send Pipelines or Receive Pipelines. The following picture shows a composite picture with a receive pipeline (left) and a send pipeline (right) being edited in Visual Studio.
It is time to dive a little deeper into the generated class. Compiling any Send or Receive Pipeline and loading it into the excellent Lutz Roeder’s .NET Reflector shows the following:
We already know that when a BizTalk project is compiled, Pipelines are compiled to a public sealed class type into a .NET assembly. The class inherits from Microsoft.XLANGs.BaseTypes.PipelineBase (contained in Microsoft.XLANGs.BaseTypes.dll, available in <BTS Installation Directory>). This class is not supported as explained by this page (look at the bottom of the page). To compile a Pipeline, BizTalk generates and compiles a class close to the following C# class:
namespace <projectName> {
public sealed class <nameOfPipelineFile> : Microsoft.XLANGs.BaseTypes.PipelineBase {
public <nameOfPipelineFile>() { }
public override Guid VersionDependantGuid { get { return new Guid(“<someGuid>“); } }
public override string XmlContent { get { return “<contentOfBTPFile>“; } }
// ——————————–
// Private const properties not shown go here
// ——————————–
}
}
To simplify, I have omitted the private constant members of the class. All the bold underlined words surrounded by angle brackets are placeholders that have to be replaced by an actual string adequate for the pipeline being compiled. Let look at the properties a little more closely:
- VersionDependentGuid: Guid of the Pipeline, dependent of the version of the Pipeline.
- XmlContent: The actual Pipeline definition, as an XML string. This is the content of the .btp file that was produced by the pipeline editor.
The base class Microsoft.XLANGs.BaseTypes.PipelineBase is abstract and contains only the properties outlined above. Alert readers have probably already noticed that the property “XmlContent” appears also on Maps as shown in my previous post. This is not a coincidence. It is used by the BizTalk assembly viewer and other tools to get a representation of the artifact in XML.
Remember that this post contains mostly undocumented, unsupported information. This content is provided “AS IS” and for entertainment purpose only. Further versions of BizTalk may change the ways things get compiled and relying on low level details like the ones outlined before will cause your application to break.
