Our web services dev and support teams have put together a FAQ that lays out our current and future support for various Web Services technologies including SOAP, WSE 2, WSE 3, and WCF (indigo). Let us know if there are additional questions you think should be added.
-Kris
So, I figured it was finally time I broke down and started to really figure out what BAM was all about, partly inspired by Richard Seroter’s posting on the subject (everyone should read his blog by the way…. fantastic stuff!!). So, I picked a sample project I’ve been playing around with for some other POC stuff, followed along with the handy little “walk-throughs” in the help file, and wouldn’t you know Excel puked on what appears to be a very important step – exporting the BAM Observation Model (all the KPI’s, etc). While trying to export the excel file to XML using the BAM Export XML menu, I received a “Invalid procedure call or argument” error. After a quick google I ran across some information about a possible security patch to Excel that might cause this error. I don’t recall installing a security patch, but who knows.
Anyway, the good news is that you can use the XSL file without exporting to XML. I believe the XML file would contain some additional information, like the server where the BAMPrimaryImport database is running, etc., but you can also provide this information when you deploy the observation model with the BAM Management utility (bm.exe). You can use the following syntax at the command line to accomplish this (replacing MyWorkbook.xls with your actual excel file name) –
bm deploy-all -DefinitionFile:MyWorkbook.xls
Using this syntax will default to the local server for SQL Server, and the BAMPrimaryImport database. You can optionally supply parameters to specify a different server or database. To view help on deploying with bm, type the following command –
bm help -Command:deploy-all
Ok, I’m off to go BAMing now.
Cheers,
Todd
I was getting a 9009 error from “gacutil /iF $(TargetPath)”, if found some info on the web (http://www.mcse.ms/archive103-2006-1-2052602.html) that point me to using “$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /iF “$(TargetPath)” it now works.
I recently put together a VPC of the BizTalk 2006 RTM on Windows Server 2003. I followed the installation guide and I had no problems during the installation or configuration.
A few days later, during an impromptu sales demo I was asked to show how you would set up an orchestration to call a web service. I didn’t have a local web service so I fired up VS 2005 to create one – only to discover that I couldn’t find the Web Services project template. Why? Because it is only installed when you install the ‘Web Developer’ component of VS 2005; you are told to clear all checkboxes but C# in the installation guide (although to be fair, in the context verbiage above this instruction it does say you need to install C# at a minimum.)
So, if you need to develop web services and your installing BizTalk by following the single-machine Windows Server 2003 installation guide, make sure you check the ‘Web Developer’ component during the VS 2005 installation.
Also, try not to demo things that you haven’t run through previously J
[Note that the same instructions appear in the Windows XP installation guide.]
I was getting a 9009 error from “gacutil /iF $(TargetPath)”, if found some info on the web (http://www.mcse.ms/archive103-2006-1-2052602.html)that point me to using
“$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe” /iF “$(TargetPath)”
it now works.
I’m working on several projects and I have to switch between BizTalk 2004 and BizTalk 2006. Since they aren’t supported in a ‘side-by-side’ manner I’ve kept BizTalk 2004 on my base machine and run BizTalk 2006 in Virtual PC.
Sometimes I need to have a lot of applications running on my machine so I don’t always have enough memory to have BizTalk 2004 running and also run the BizTalk 2006 VPC image so I’ve create two batch scripts to start and stop BizTalk 2004 related services on my base machine:
Start:
net start MSSQLServer
net start SQLSERVERAGENT
net start MSSQLServerOLAPService
net start MSDTC
net start RuleEngineUpdateService
net start ENTSSO
net start BTSSvc{YourGuidGoesHere}
IISRESET /START
pause
Stop:
net stop BTSSvc{YourGuidGoesHere }
IISRESET /STOP
net stop ENTSSO
net stop RuleEngineUpdateService
net stop MSDTC
net stop SQLSERVERAGENT
net stop MSSQLServer
net stop MSSQLServerOLAPService
pause
Notes:
· Copy and paste the scripts into a text editor and save them with a .bat extension.
· Replace the ‘YourGuidGoesHere’ with your host instances Guid. The Guid will be part of the host instance’s ‘Service name’ which you can find using the Services MMC.
· If you try to use these with BizTalk 2006, the host instance service names have changed format. The new format is BTSSvc$YourHostName.
· If you have additional host instances you’ll need to add them to your version of the scripts.
· Use these at your own risk and make sure these scripts are appropriate for your machine and situation before attempting to use them.
· Do not use these scripts on non-development environments (MSBTS_HostInstance should be used in non-DEV environment to start and stop host instances via scripts.)
· To use the .bat files you created Double-click them or execute them CMD.exe.
I’ve come across a situation a couple of times in the past where I could not see certain (custom) properties in a Receive shapes’s filter list. In my cases, this appeared to happen when:
An obvious solution is to make sure that your property schema and the schema whose node you have promoted are in the same assembly. In my case I didn’t want to do this because I inherited a solution that has been used for quite a while and I didn’t want to create extra work for myself by having to restructure the artifacts.
Instead, I modified the underlying .odx file manually to add the Receive shape’s filter. Here’s how you do it:
We have received a lot of questions about the deployment enhancements in BizTalk Server 2006. Accordingly, I’ve decided to blog about it to help clear some things up but also to call attention to specific features which should be especially helpful to those working often with BizTalk.
In BizTalk Server 2006, application deployment has not changed dramatically under the covers, but many tools enhancements have been undertaken to ensure this process is much more intuitive and less error-prone. These will be discussed each in turn within this article.
Application Concept
The first major enhancement in this area is the introduction of the application concept. This is really just a logical container for application artifacts, allowing you to bucket related components. However, this concept permeates well throughout the product. The effect is a streamlining of many of your everyday tasks. By being able to deploy, manage, start/stop, and troubleshoot all at the application level, there becomes less confusion and less risk of errors for users.
For example, a developer can specify an application to deploy to by editing the “Application Name” property of a Visual Studio project. By doing so, their artifacts will be deployed to the said application. This creates a common vocabulary between the developer and the IT Pro when they speak of “an application”.
For the IT Pro, they can use the Administrative MMC Console to configure and start an entire application. Performing these tasks at the application level ensures that no stone is left unturned. Once running, the application concept allows the IT Pro to manage and troubleshoot selectively at the application level. In other words, they can ignore errors coming from a less important application while carefully debugging a more critical application.
This concept also assists greatly with the tasks related to Developer deployment as well as IT Pro deployment and staging, segueing into our next sections.
Developer Deployment
Developers typically deploy to their own local BizTalk server to sanity test the solution still in progress. The developer deployment and re-deployment process been streamlined considerably since BizTalk Server 2004.
Firstoff, the aforementioned application concept allows different projects to deploy into logical application containers, bucketing like artifacts. This allows users to easily enter the Administrative MMC Console after deploying from with VS and create ports and bindings for this application.
Once deployed, the developer typically tests, makes changes, and redeploys. In BizTalk Server 2004 this required a lot of manually intervention on the part of the developer to stop and tear down the dependent components in the correct order, redeploy all of the artifacts, restart host instances, and re-create/start all of the dependent artifacts (e.g. ports, orchestration enlistments, etc.). With BizTalk Server 2006, the developer experience is much more streamlined and less susceptible to user error. After making changes to the project already deployed (say fixing an orchestration or editing a map) and with the Redeploy = True and Restart Host Instances = True properties for the project set, developers can simply Right-click Deploy the project or solution and voila! This removes many formerly manual (and yes, painful) steps.
But application deployment does not just start and stop with the developer. The next section explains more about the feature advances which will help the IT Pro.
Deployment and Staging
Deployment is the logistical distribution of application artifacts to ensure all necessary components are available to the systems that require them. Staging, more specifically, refers to the moving of application artifacts from environment to environment, say from development to a test environment, or from staging to production.
Generally, deployment has been improved with the introduction of the application concept. Since an application typically contains all of the necessary components that its parts depend on, this logical container can be leveraged to help roll-out artifacts to other machines added to the group or for staging (when transporting an application to another environment).
Naturally, the application container contains BizTalk assemblies which are deployed to it by the Visual Studio environment, as explained earlier. Further, users can manually add BizTalk assemblies to the application, or move BizTalk assemblies from other applications. Likewise, they can also add non-BizTalk assemblies to the application. The application may also contain receive ports, receive locations, send ports, property tracking settings, and role links, to name a few. Implicitly, the application also contains all of the bindings that are represented by their current settings. And other BizTalk artifacts can also be added to applications, such as BRE (rules) policies.
But in an effort to create a more comprehensive application container, we also provide the ability for users to add additional (typically non-BizTalk) artifacts to the application under the Resources node. Scripts are also a welcome type of resource which can be chosen to run during different application deployment operations.
Now that an application contains all of the necessary artifacts, the actual deployment process comes in. BizTalk Server 2006 employs the help of MSIs to actually perform deployment and staging. The following section covers this process.
Working with MSIs
Microsoft Installer (MSI) technology is used to assist with application deployment tasks. Why use an MSI? MSIs are a standard way for applications to be installed onto Microsoft Operating Systems. They create registration entries in the Add/Remove Programs, accelerate deployment by automating deployment of artifacts and their dependencies in the correct order, and also have many additional capabilities which will be described below.
With BizTalk Server 2006, users have the option of exporting an application to an MSI file, which serializes all of the application artifacts into this package. Thereafter, several operations can be done with this MSI, explained below.
Depending on what type of roll-out you are doing, you may have to do one or both of the above operations.
Scenario A would be adding an additional server to the BizTalk group. You may want to use MSIs to help with this. Exporting the application as an MSI and installing it on the new machine would probably be sufficient to prepare this machine for runtime, at least with respect to the application.
However, Scenario B might be setting up a brand new environment with the solution, in which case the application and its contents must not only be installed on all runtime machines in the new group, but also registered with the Management Database for the group so that the application is created, the bindings are applied, the BizTalk assemblies are deployed, et cetera. This would necessitate running the MSI installation (double-clicking the package) on all n servers, but also importing the MSI once for the group.
Using Scripts with MSIs
Scripts can be helpful when customization to the machine (installation operation) or to the group (import operation) becomes necessary.
The documentation article entitled, “Using Pre- and Post-processing Scripts to Customize Application Deployment” in our core documentation, explains how scripts can be added as resources and how (and when) they are called by the MSI.
The long story short is that you can add scripts to run as pre-processing or post-processing scripts. However, you will have to include logic in your scripts to check environment variables to determine which context the script is executing in (an import, installation, or uninstallation) and process accordingly.
Advanced Staging
There are some additional features in BizTalk Server 2006 which can better facilitate staging. Obviously, exporting applications as MSIs can help greatly with this. But even beyond this, we have added some new capabilities which make transporting solutions from environment to environment even easier.
For example, every application contains a Resources node which is a general catch-all for additional application components. One of the Resource types is called “BiztalkBinding”. This allows users to add additional bindings files to an MSI. For each bindings file that is added, the user must specify the environment name (text field) which the bindings should be applied to. Then on import, the user will be asked to choose the environment name to which they are presently importing. If these are matching, then the bindings file is applied to the target group. Users can also choose to specify no environment name which will cause the bindings file to be applied to all environments unconditionally.
As explained earlier, the application implicitly has a bindings set by default, since ports and locations exist and the transport properties are already configured. These settings will be serialized into an XML file, included in the MSI file, and tagged as belonging to the “Default” environment. This environment can be chosen by the user or circumvented by selecting another.
Often times transports, URIs, or endpoints can change from environment to environment, and this feature allows an IT Pro, or developer, to create one package which contains all of the transport properties for all environments which it require testing in. One monolithic package can then be distributed around to service them all.
More Information
Yes, there are even more new deployment features in BizTalk Server 2006. For more information, please consult the core BizTalk documentation included with the product and updated online at MSDN.
Regards,
Doug Girard
Note: This posting is provided “AS IS” with no warranties, and confers no rights.
I’ve been writing some Pipeline Components for BizTalk 2006, and I ran into a bit
of a problem while testing one of them. The problem is a fairly common, but obscure
issue that appears with most non-trivial pipeline components: Stream Handling.
Charles Young has a pretty good article here about
the problems that appear when pipeline components don’t handle message stream correctly.
In particular, Charles talks about a bug in BizTalk 2004 which caused inbound maps
to fail when a pipeline component returned a seekable stream, and thus recommends
pipeline component developers always make sure they return a non-seekable stream to
avoid the issue.
My case, however, was a little bit different. It seems that Charles recommendation
only holds true for pipeline components that run in or after the disassemble
stage in a receive pipeline. I was, instead, writing a decoding component, and, in
my test, the receive interchange kept failing with the following message in the machine’s
Application Event Log: “Stream does not support seeking”. Indeed I was returning a
non-seekable stream from my pipeline component, but I haven’t figure out exactly why
this is an issue.
As far as I can see, this is related to the presence of the Xml Disassembler component
in the disassemble stage of the receive pipeline I was using to test my component.
Though BizTalk unfortunately doesn’t give you any details about the error (not even
a stack trace), it’s pretty hard to diagnose exactly what the problem is with non-seekable
streams here, but I think it has something to use with the use of the MarkableForwardOnlyEventingReadStream
used by the Xml Disassembler, which is constructed during message probing (IProbeMessage.Probe()).
I did some spelunking around doing some tracing and using Reflector, and it does indeed
seem that this special stream class that the disassembler creates called my Stream’s
CanSeek method (which properly returned false), but I could not see code where explicitly
an error message was returned or processing was halted based on this value, and instead
some alternative work was done, which I found rather confusing.
These kind of issues can be quite a bit of stressful because the semantics expected
by BizTalk (or rather, but the standard components included in BizTalk) are not documented
anywhere, making the process of writing a good and efficient pipeline component a
trial-and-error process, which is wildly frustrating and a very innefficient process
itself.
I think this is pretty nasty requirements for decoding component writers, as, in general,
they are usually built to decode a stream start to finish without moving around the
stream (most encryption/decryption components are easy, natural and efficient to write
this way). Additionally, it makes it imposible to simply have a decoding component
that returns a System.Security.Cryptography.CryptoStream stream to BizTalk, because
it is always non-seekable.
Solving the Issue
The easiest way to work around this problem would be to have the decoding component
decode the entire message into a seekable in-memory stream, but this is highly inneficient,
and it is sure to cause performance and scalability problems with either large interchanges
or a lot of concurrent messages flowing through the system.
What’s more frustraring about this is that it seems that the BizTalk Developers were
aware of this problem and solved it. After quite a bit of looking around, I discovered
that the MIME/SMIME component included in BizTalk is apparently aware of the problem
with non-seekable streams! It verifies if the data stream coming off the adapter is
seekable, and, if not, wraps it around a custom stream that allows read-only, seekable
access to it in what looks like a more efficient way than just loading it entirely
into memory. It basically does something like this:
if ( !stream.CanSeek
)
{
part.Data = stream = new ReadOnlySeekableStream(stream);
}
The ReadOnlySeekableStream class is implemented in Microsoft.BizTalk.Streaming.dll,
and is a public class. Unfortunately, it is undocumented, and the assembly is only
installed to the GAC, making it, at the very least, cumbersome and risky to reuse
on your own.
If anyone has any explanations of why seekable streams appear to be required on this
case, I’d sure would like to hear about it!
>
With Readify’s continuing growth we have now attained Microsoft Gold Partner Status, thanks to lots of paperwork by Kim.