Pipeline Tools in the SDK

The BizTalk Server SDK ships with the following command-line tools you can use to troubleshoot your pipeline components:

· DSDump.exe.Enables you to dump the document schema structure. This tool can be helpful when you get parsing engine errors such as $Root$0$3$2 and you need to decode them. Numbers after $ mean 0-based index or records as they appear in the document schema.

· FFAsm.exe. Runs the flat file assembler component, directly invoking it by emulating a send pipeline.

· FFDasm.exe. Runs the flat file disassembler component, directly invoking it by emulating a receive pipeline.

· Pipeline.exe. Runs a send or receive pipeline; accepts one or more input documents and their parts, XSD schemas, and related information; and produces an output document after the pipeline runs. Pipeline.exe does not access BizTalk Server databases, so pipelines containing BizTalk Framework assembler and disassembler components that access BizTalk Server 2006 databases during execution may not be supported.

· XMLAsm.exe. Runs the XML assembler component, directly invoking it by emulating a send pipeline.

· XMLDasm.exe. Runs the XML disassembler component, directly invoking it by emulating a receive pipeline.

These can be found in the \SDK\Utilities\PipelineTools directory of BizTalk Server.

Source: Microsoft

You receive a "Could not connect EDI Subsystem (StartDatabase returned -2) to Database" error message, and the BizTalk Base EDI service does not start

Problem

When you try to start the BizTalk Base EDI service, you receive an error message that is similar to "Could not connect EDI Subsystem (StartDatabase returned -2) to Database" in the Application log and the Base EDI service does not start.

Cause

This problem occurs if the following conditions are true:

· The BizTalk Base EDI database is on a remote computer that is running Microsoft SQL Server 2000 or Microsoft SQL Server 2005.

· The SQL Server client tools are not installed on the computer that is running the Base EDI service.

Resolution

To resolve this problem, install the SQL Server client tools on the computer that is running the BizTalk Base EDI service. After you install the SQL Server client tools, you can successfully start the BizTalk Base EDI service.

Note

SQL Server client tools can be found on the SQL Server installation CD.

Source: Microsoft

You receive an error in the event log similar to "index was outside the bounds of the array" when validating or sending an EDI document

Problem

When you try to validate an EDI document or when you try to send an EDI document in Microsoft BizTalk Server 2006, an Error event that resembles the following may be logged in the event log:

Event Type: ErrorEvent Source: EDI TransmitterEvent Category: BizTalk Server 2006Event ID: 27Description:Transfer of message(s) to EDI Subsystem failed. Index was outside the bounds of the array.

Cause

This issue occurs if one of the following conditions is true:

· The BizTalk Base EDI service and the BizTalk Server Host service do not use the same logon credentials.

· The logon account for the BizTalk Base EDI service and for the BizTalk Server Host service does not have the permissions that are required to access the BizTalkEDIDb database and the Configuration database.

· The user who configured the EDI adapter is not a member of the EDI Subsystem Users group and of the BizTalk Server Administrators group.

Resolution

The user account that is configured as the logon account for the BizTalk Server Host service must be a member of the EDI Subsystem Users group. If the user account that is configured as the logon account for the BizTalk Server Host service is not a member of the EDI Subsystem Users group, the EDI transmitter cannot connect to the EDI subsystem because of insufficient permissions. Therefore, the Error event in the event log states that there is a transmission failure.

To resolve, try one of the following methods:

· Verify the service logon credentials. Verify that the BizTalk Base EDI service and the BizTalk Server Host service use the same logon credentials.

· Verify the database permissions. Verify that the user account that is configured as the logon account for the BizTalk Base EDI service and for the BizTalk Server Host service has the permissions that are required to access the BizTalkEDIDb database and the Configuration database.

· Verify the group membership. Verify that the user who configured the EDI adapter is a member of the EDI Subsystem Users group and of the BizTalk Server Administrators group.

Source: Microsoft

Solving BizTalk "error X2044"

Strange compilation error in BizTalk 2004 when importing a web service.

When you see an error message like:

C:\Project\Web References\ExtRef\MyOrch.odx(445,23): error X2044: symbol '@@@@' is already defined; the first definition is in assembly @@@.dll : It may be possible to disambiguate by using fully qualified names.

The way to fix this error is to do the following:

• Open the orchestration in Notepad (In my case MyOrch.odx)
• Do a find (Ctrl+F) for “#endif // __DESIGNER_DATA”
• Delete all the code below that line
• Save your file in Notepad
• Say yes when Visual Studio asks if you want to update your file
• Recompile

Note: The code will not be regenerated until you edit an expression shape, etc. Add a “//” or something and you will then see the code re-appear when you open it in Notepad again.

Source: BIA - The BizTalk Intelligence Agency

Clients of published Web services may not receive server script time-out errors

If Web clients that use .NET Framework 2.0 are calling a Web service generated with the BizTalk Server 2006 Web Services Publishing Wizard, it is possible that the client cannot receive server script time-out errors because the client request time-out occurs first by default. To resolve this problem you can do one of the following:

· Increase the client request time-out to a value greater than the server script time-out by increasing the value for the HttpWebRequest.Timeout property on the client.

· Reduce the server script time-out to a value less than the client request time-out by reducing the value for the HttpServerUtility.ScriptTimeout property on the server.

Source: Microsoft

A Web service returns an HTTP 404 (File Not Found) error

Problem

Attempts to call a Web service return an HTTP 404 (File Not Found) error.

Cause

This error can occur if ASP.NET is not installed and/or enabled on the IIS server that hosts the Web service.

Resolution

Ensure that ASP.NET is installed and enabled. Install the .NET Framework if it is not installed and/or run the aspnet_regiis.exe program located in the %WinDir%\Microsoft.NET\Framework\vXXX.XXX\ folder of the IIS server.

Source: Microsoft

A "System.IO.FileNotFoundException" error occurs when a Web service is called

Problem

When you call a Web service in a Microsoft ASP.NET Web application, you may receive the following error:

System.IO.FileNotFoundException

Cause

This error can occur if either of the following conditions is true:

· The worker process does not have permissions to read to the process Temp directory, and the worker process does not have permissions to write to the process Temp directory.

· There are compilation errors in the code that XmlSerializer generated.

Resolution

Worker Process Account Permissions on the Temp Directory

To resolve this problem, the ASP.NET worker process account (the ASPNET account or the NETWORK SERVICE account if your application is deployed on Internet Information Services [IIS] 6.0) must have read access and write access on the Temp directory.

Note If you use impersonation, the impersonated user must have full access on the Temp directory.

To assign required permissions to the worker process account on the Temp directory, follow these steps:

1.	In Microsoft Windows Explorer, locate the %windir%\temp directory.
2.	Right-click %windir%\temp, and then click Properties.
3.	In the Properties window, click the Security tab.
4.	Click Add, type ServerName\ASPNET, and then click OK. Note Replace ServerName with the name of the Web server. Replace ASPNET with NETWORK SERVICE if you deployed your application on IIS 6.0.
5.	Under Allow, click to select the Full Control check box, and then click OK.

Find Compiler Errors in the Code That XmlSerializer Generated

To find errors that are generated by the compiler, you must add a switch to the Web.config file to keep compiler-generated files. To do this, follow these steps:

1.	Open the Web.config file in a text editor, such as Notepad.
2.	Add an XmlSerialization.Compilation switch to the system.diagnostics section of the code, as follows: <configuration> <system.diagnostics> <switches> <add name="XmlSerialization.Compilation" value="4"> </add> </switches> </system.diagnostics></configuration>
3.	Run the client application. The client application calls the Web service.
4.	Verify that the %windir%\temp directory has the _tmpname.00.cs file and the _tmpname.out file. The _tmpname.00.cs file is the generated source. The _tmpname.out file should have the compiler errors. Note Enable the read permissions and enable the write permissions to the worker process account (ASPNET or NETWORK SERVICE) to write %tmpname% files in the Temp directory. Source: Microsoft

Source Control Best Practices II

· Use unique strong name keys when appropriate. If the business solution being developed is composed of two or more distinct parts, then consider whether multiple key files should be used. Multiple keys in this scenario allow the parts to be treated as independent entities in the future, for example with differing upgrade paths.

· Keep test messages in their own folder under the project. Choose a folder name to hold messages ("Msgs" or "SampleMessages") and use it consistently across all BizTalk projects. You should keep generated and example messages distinct by naming convention or by placing them in a separate folder. Track version numbers in the file name and through your version control system.

· Check in code only when it has passed functional tests. The developer should be confident that the code will build successfully without breaking any related code. Schemas should be checked in only when they have been tested against a wide variety of messages, BizTalk projects containing business processes should be checked in only after testing with expected (and unexpected) messages with all ports configured, and Web service projects should be checked in only after testing using a test harness or by the initiating system.

· Use the version control system to track non-BizTalk projects related to your solution. Use the version control system to track custom tools, deployment utilities, scripts, documentation, and other artifacts relevant to your BizTalk project. For example, if your project uses a Visual Basic® .NET Windows® application to manage accounts in a related system, you should consider tracking the executable and configuration files.

· Choose a versioning number approach and stick with it. There are two approaches to setting version numbers for BizTalk solution assemblies: choose a fixed assembly version and increment only the file version, or increment both assembly and file version for a build. The approach you choose will impact how you maintain and deploy your project.

Source: Microsoft

Source Control Best Practices

· Use a consistent folder structure for solutions and projects. Team development is made easier when a consistent folder structure is used on all member computers. This practice can also reduce the amount of time it takes to identify build issues across computers and decrease project ramp-up time for new team members.

· Keep source control and file system structures identical. This keeps team member directories synchronized with the source system and with other developers and helps to ensure they are following team project organization guidelines.

· Define and use a common root folder. Organize projects under a common root folder in the source control system. Developers should create the same root directory on their own computers.

· Create a master solution that will hold all projects. The master solution can be used as the main build solution and is a recommended practice for medium to large BizTalk projects. All related BizTalk projects should be stored under the master solution.

· Divide the project folder structure according to business process. Shared processes should be sequestered to their own folder. This will make it easy for developers to navigate to the different business processes in the solution and make enhancements without modifying unrelated processes.

· Group related pipelines into separate projects. During development of pipeline components, it is a common requirement to modify and retest a pipeline independent of the rest of the solution. For this reason it is often helpful to keep pipeline solutions as a separate BizTalk project, resulting in a separate pipeline assembly that can be removed and redeployed without the need to rebind the rest of the solution.

Source: Microsoft

"you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port"

Problem

When you compile your BizTalk project, you receive the error "you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port".

Cause

This error can occur if your orchestration has no activating Receive shapes (Activate = true) or has no activating Receive shapes and is not called directly by another orchestration.

Resolution

If your orchestration is not called by another orchestration, you must configure one of the Receive shapes to be an activated receive.

Source: Microsoft

Custom Coding Best Practices

The following best practices may help you develop more maintainable, reliable, and extensible code for your BizTalk application:

· Provide purposeful, relevant comments. Use whatever commenting features your language offers to write purposeful comments that are relevant to the code. Always concisely document algorithms, general method flow, and all conditional and loop statements.

· Create and maintain key design and other development artifacts. Create documentation relevant to the solution and keep it current by updating it as the requirements, code, environment, or other application facts change. You should document key designs more fully in your design document than in code comments.

· Use Trace or Debug to follow program flow. Using Trace switches, you can control trace behavior through the configuration file. Both Trace and Debug allow you to send output to interested listeners that you or another tool implements.

· Avoid using Microsoft.BizTalk.ExplorerOM in 64-bit processes. The Microsoft.BizTalk.ExplorerOM DLL is only supported in 32-bit processes.

Source: Microsoft

Deployment Best Practices II

Avoid large (over 100 MB) MSI files. Large (over 100 MB) MSI files may not be deployed within the transaction time-out of the COM+ components used by BizTalk Server during application deployment, causing the deployment to fail. You should deploy smaller MSI files or modify the default transaction time-out for the deployment COM+ objects.

· Document your deployment process. Even the most complex deployment scenario can be simplified with documentation. You should document the deployment environment, steps for deploying the solution, and custom configuration settings for hardware and software.

· Configure a binding file for each environment and computer. You can control settings by environment or server by packaging additional binding files in your solution's exported MSI file.

· Customize your MSI file with pre- and post-processing scripts.

· Ensure that only BizTalk administrators have access to the assemblies, binding files, and policy files. These files may contain sensitive business data such as connectivity and configuration information. If you deploy applications through a network share, configure the discretionary access control list (DACL) on the network share so that only BizTalk administrators can view its contents.

· Verify the security settings on virtual directories before exporting an MSI file. Be aware that the security settings on the virtual directory are those in effect when the MSI file is generated. If you are deploying an application with a virtual directory and the virtual directory already exists in the destination environment, the security settings on the existing virtual directory will be in effect.

Source: Microsoft

Deployment Best Practices

You can minimize deployment problems by following these best practices:

· Group related artifacts together in a single application. This simplifies management and provides a logical grouping of similar functionality, making troubleshooting easier.

· Deploy shared artifacts in a separate application. Only one artifact having the same locally unique identifier (consisting of the artifact name and possibly other attributes) can exist in a BizTalk group. By storing shared artifacts like schemas in their own application, you have finer control over dependencies.

· Deploy a shared Web site in a separate application. If you are deploying a Web site that will be shared by more than one solution, deploy it as a separate application. If it were shared and part of another application, its virtual directory would be removed when that application was removed. The Web site would stop working and any applications relying on it would stop working.

· Never deploy an assembly to a production computer from Visual Studio. During deployment, Visual Studio may undeploy, unbind, stop, and unenlist artifacts contained in project assemblies, causing unexpected and undesired consequences in a production environment. Never install Visual Studio on the production computer and never refer to a production database from a computer running Visual Studio.

Source: Microsoft

You can’t remove all data related with Cross-Referencing from the BizTalk Server database

Problem

When you delete all of the information related through cross-referencing from the BizTalk Server database, you receive an error.

Cause

The xref_IDXREF and xref_ValueXRef tables must have at least one empty row.

Solution

Insert one blank row into the xref_IDXREF and xref_ValueXRef tables using the following SQL script:

use BizTalkMgmtDb; set IDENTITY_INSERT xref_IDXRef ON insert xref_IDXRef (idXRefID, idXRef) values (1, '') set IDENTITY_INSERT xref_IDXRef OFF set IDENTITY_INSERT xref_ValueXRef ON insert xref_ValueXRef (valueXRefID, valueXRefName) values (1, '') set IDENTITY_INSERT xref_ValueXRef OFF

Source: Microsoft

You receive error 'Namespace:Element1 cannot be a member of substitution group with head element Namespace:Element2' when compiling your solution

Problem

You receive the error 'Namespace:Element1 cannot be a member of substitution group with head element Namespace:Element2' when compiling your BizTalk Server 2006 solution.

Cause

This issue occurs if the schema contains the substitutionGroup element. This primarily affects EAN, UCC, and EDI schemas.

Resolution

Modify the schema so that the schema does not contain the substitutionGroup element. If required, implement similar functionality directly in the XSLT by using a custom functoid or custom script.

Source: Microsoft

Why doesn't my atomic transaction retry?

An atomic transaction will retry in either of the following circumstances:

· When a RetryTransactionException is deliberately thrown by user code.

· When a PersistenceException is raised when the atomic transaction attempts to commit.

Note

Any other exception raised in an atomic scope will not cause it to retry even if you have the Retry property set to True. If you are not sure why the atomic scope is not retrying, double-check both the exception type and any custom code to ensure a retry-friendly exception was thrown.

A PersistenceException could happen if, for example, your atomic transaction was part of a distributed DTC transaction and some other participant in that transaction aborted the transaction. Likewise if there were database connectivity problems at the time when the transaction was trying to commit, a PersistenceException would be raised.

There can be several root causes for PersistenceException, depending on the situation, but what you generally observe is that all the XLANGs actions in your atomic scope seem to go through correctly, but then instead of committing, the scope fails. If that happens for an atomic scope that has Retry=True, then the atomic scope will retry up to 21 times. The delay between each retry is two seconds by default (but you can modify that value). After 21 retries, if the transaction is still unable to commit, the whole orchestration instance gets suspended. Then you can manually resume it and it will start over, with a fresh counter, from the beginning of the offending atomic scope.

Note

The atomic scope will retry up to 21 times. You cannot override this value from your code. For example, you cannot configure the atomic scope to retry only three times.

If you are using RetryTransactionException you can override the two-second default delay between consecutive retries by setting a different value for the DelayFor property. For more information, see RetryTransactionException.DelayFor Property.

Note

All variables will be reset when RetryTransactionException is thrown in an atomic scope.

Source: Microsoft

Interactive Debugging of an Orchestration in HAT

To perform interactive debugging of an orchestration in HAT, you must deploy and execute at least one instance of the orchestration you want to debug. To do so, you will have to perform the following steps:

1. Deploy and execute the orchestration you want to debug at least once. This will generate an instance of the orchestration that you can attach to in HAT. Without this step, HAT will not know about your orchestration and will not have a way to display it.

2. View the orchestration in the Orchestration Debugger by executing one of the canned queries or by running a custom query. This exposes the orchestration so that you can set class-level breakpoints.

3. Set a class-level breakpoint on the orchestration shapes you are interested in debugging. Future instances of the orchestration will break at the shapes specified.

4. Generate one or more new orchestration instances by submitting appropriate messages. You should use messages that exercise the appropriate shapes in the orchestration. For example, if you have a decision shape, make sure your sample message will trigger the branch you are interested in.

5. Attach to the orchestration instance by using Debug | Attach.

6. Review variable names and values including message part contents.

7. Resume the orchestration. If no more breakpoints are encountered, the debugger will detach from the instance.

8. Remove class-level breakpoints.

Source: Microsoft

You receive 'Type messagename cannot be found in namespace servicename' error using the WSE adapter

Problem

In some scenarios, the BizTalk Adapter for WSE Schema Generation Wizard may not generate an XML Schema definition language (XSD) schema or an orchestration as expected.

Cause

The wizard has a problem in the way it generates schemas and orchestrations.

Resolution

Obtain the Microsoft BizTalk Adapter for Web Services Enhancements (WSE) 2.0 Service Pack 2006 update. In addition to the problem stated above, it addresses the following issues:

· The BizTalk Adapter for WSE 2.0 now supports long schema names. Before you install this service pack, the BizTalk Adapter for WSE 2.0 uses the target namespace for the schema as the file name. Therefore, some Web services may not be usable because of long file names. After you install this service pack, the BizTalk Adapter for WSE 2.0 creates shorter file names that are unique.

· The BizTalk Adapter for WSE 2.0 now imports schemas correctly. This includes schemas that include the schemaLocation attribute.

· The BizTalk Adapter for WSE 2.0 now propagates information correctly if the response pipeline fails in solicit-response operations.

· The BizTalk Adapter for WSE 2.0 now returns an exception error message correctly when a pipeline failure occurs or when an unhandled pipeline exception occurs.

· The BizTalk Adapter for WSE 2.0 now follows the policy when a message is signed.

Source: Microsoft

I am receiving errors when consuming a Web service; how can I avoid them?

There are many details to consider when consuming a Web service, including the following:

· Avoid using two underscore characters in a parameter name.

· Use of the any element or the anyAttribute attribute is not supported in Web methods.

· Avoid using XLANG/s keywords as a Web service name or Web method name.

· Avoid using Web method parameter types that are not supported by XLANG/s.

· Do not use element names that are C# keywords or will be invalid as a C# identifier in your schemas.

· Avoid Web Services Description Language (WSDL) files with multiple service or port type definitions.

· Web method parameters must be Xml Serializable.

· Avoid references to consumed Web services that contain multi-rooted schemas.

· Avoid referencing Web services with Web methods expecting generic-based parameters such as nullable parameters.

· The WSDL import element is not supported.

Source: Microsoft

Using the ThrowDetailedError switch

If an error occurs, the Web client receives a generic SoapException.

To debug your published Web service, you can add a switch to the web.config file to control the level of the exception details returned from the published Web service. The switch is ThrowDetailedError, and when it is set to True the server proxy returns inner exception information to the Web client, enabling you to debug the published Web service.

The following XML code shows the ThrowDetailedError switch that appears in the web.config file under the appSettings node:

<appsettings>
<add key="ThrowDetailedError" value="False">
<appsettings>

Warning

The inner exception may contain sensitive information. After debugging, you should set the ThrowDetailedError switch to False.

Source: Microsoft

Review the XSLT generated for the map

It is often useful to inspect the XSLT generated by the map compiler. Some of the benefits of inspecting XSLT include:

· If you are using looping or custom functoids, you will better understand how the looping is performed and how the custom functoid is invoked.

· If you have a complicated map, reviewing the XSLT will enable you to see how the map is translated into a transform and may give you insight about how to better structure, replace, or streamline one or more parts.

· If you are using custom scripts or other artifacts, reviewing the XSLT will enable you to see how the scripts, artifacts, and other parts of the map interact.

Fortunately, viewing the XSLT for a map is an easy process.

To view the XSLT generated by the map compiler

1. From a Visual Studio BizTalk project, click the Solution Explorer tab, right-click a map, and then click Validate Map. 2. Scroll the Output window to find the URL for the XSL file. Press CTRL and click the URL to view the file.

If you decide to customize your map by hand, you can modify the version produced by the map compiler. Changes will not be reflected by the Mapper and will be lost the next time you build your solution.

Source: Microsoft

How do I create multipart mappings?

If you have multiple maps that are used together, you will need to combine them in an orchestration by using the Transform shape to test them together. BizTalk Mapper can test only one map at a time.

Source: Microsoft

Debugging Stored Procedures (SQL Adapter)

Programming errors in stored procedures can often be more easily identified by stepping through the code one statement at a time. This gives you the opportunity to not only verify stored procedure arguments and variables, but also check data in tables, error values, and other variables that are affected by the stored procedure.

To debug a SQL Server stored procedure using Visual Studio

1. Open a BizTalk project using Visual Studio 2005. 2. On the Visual Studio View menu, click Server Explorer. 3. In the Server Explorer pane, right-click Data Connections and then click Add Connection. 4. On the Choose Data Source screen, click Microsoft SQL Server and then click Continue. 5. On the Add Connection screen, choose a server name from the drop-down list or type a server name, and choose a logon method. If you choose Use SQL Server Authentication, supply a User name and Password. Choose a database to connect to, and then click OK. 6. In the Server Explorer pane, expand the database and then expand Stored Procedures to expose the stored procedures. 7. Right-click one of the stored procedures and then click Step Into Stored Procedure. 8. On the Run Stored Procedure screen, enter values for each of your stored procedure arguments. 9. Step through the stored procedure using F10, breakpoints, and the other tools available in Visual Studio 2005.

Source: Microsoft

You receive a "use of unconstructed message" error when building your project

Problem

When you compile your BizTalk project, you receive the error "use of unconstructed message ''".

Cause

This error occurs when an unconstructed message is used in a Send shape.

Resolution

To resolve this issue, add a Construct Message shape to the orchestration. Include the Construct Message shape before the Send shape that is bound to the Web service.

Source: Microsoft

You receive a "Message has not been initialized in construct statement" error when building your project

Problem

When you compile your BizTalk application, you get the error "Message has not been initialized in construct statement".

Cause

When you construct a message, you specify all the message variables. Then you make assignments to the message or its parts. If part of a specific message assignment is included in a separate Construct Message shape, you may receive the initialization error message.

Resolution

To resolve this behavior, make sure that you include all parts of a specific message assignment in the same Construct Message shape.

You can also resolve this behavior by creating your message in a Construct shape before using an instance of it in an Expression shape. For example, the following code will cause an error if placed in an Expression shape:

XMLDOM = new System.Xml.XmlDocument(); POAckMsg = XMLDOM;

To fix, create the instance of XMLDOM in a Construct shape, and then do the assignment in a downstream Expression shape.

Source: Microsoft

An "AssemblyName context property was not valid" error occurs when submitting a document to a Web service via an orchestration

Problem

Submitting a document to a Web service via an orchestration results in an "AssemblyName context property not valid" error.

Cause

The BizTalk application was originally designed using a "messaging" approach without an intervening orchestration. This type of solution uses a send port filter to link the receive port and the send port so that the document is passed through to the send port upon receipt. Later, the solution was modified to include an orchestration that was bound to the send port.

Resolution

Remove the filter on the send port. If you apply a filter to a send port that is bound to an orchestration, messages will often bypass the orchestration and cause the context property error.

Source: Microsoft

Ugly XmlSerializer bug that generates invalid XML for required+fixed attributes

One common way of signaling the version of a configuration file that the processor of that file understands, is having an attribute (i.e. SchemaVersion) with the attributes use="required"fixed="[required version]". This way, all config files need to include such an attribute. When you evolve the schema, you can allow say "2.0" and most probably have XSLTs that automatically upgrades older versions, based on the version number you receive.

But this will not work with the XmlSerializer, not in Everett, neither in Whidbey so far.

The XSD 2 classes conversion process transforms an attribute that is both required and has a fixed value into the following class member (will be just a public field in v1.x):

[System.ComponentModel.DefaultValueAttribute("1.0")]
public string SchemaVersion {
get {
return this.schemaVersionField;
}
set {
this.schemaVersionField = value;
}
}

The class constructor will initialize the field value to the fixed value specified in the XSD (and the serialization attribute).

When the XmlSerializer finds such a property, it generates the following code:

if (((global::System.String)o.@SchemaVersion) != @"1.0") {
WriteAttribute(@"SchemaVersion", @"", ((global::System.String)o.@SchemaVersion));
}

This means that it will only serialize the attribute to the XML output if it was given a value other than the required one. This rule doesn't make sense. This means it will generate XML that doesn't validate against the schema it was created from.

So if you create an instance of the class (or deserialize from a valid XML file), assign the required property to the required value (which isn't necessary because it will already have the initialized value), that property it will never get serialized, no matter what.

This effectively means that you not roundtrip: valid XML -> Object Model -> valid XML. The third step will always be invalid, as the attribute is not emited.

Repro:

1. Create an XSD file with an element that has an attribute required and with a fixed value.
2. Call XSD.EXE /c with it to generate the class.
3. Create an XML that is valid according to the schema.
4. Create a console app that uses the XmlSerializer to deserialize the XML into the classes, using XSD validating reader
5. Use the serializer to serialize the in-memory representation of the XML into a stream again
6. Try to deserialize again with this new stream, using an XSD validating reader.

Solution to the problem may be to have a new XML Serialization attribute which signals the attribute has a fixed value (so it should always be emited, unlike the DefaultValue one).

The bug has been fixed in .NET 2.0, and now you should be able to have a fixed value serialized properly.

Source: Kzu weblog

You receive an error message when you try to apply a tracking profile to an x64-based computer in the Tracking Profile Editor

Problem

When you apply a tracking profile to a BizTalk server running on an x64-based computer you receive the error "Failed to apply the tracking profile" along with one or more of the following exception details:

· System.Runtime.InteropServices.COMException: The transaction has already been implicitly or explicitly committed or aborted

· Communication with the underlying transaction manager has failed. (System Transactions)

· Unhandled Exception: System.InvalidOperationException: The Promote method returned an invalid value for the distributed transaction.

Cause

This issue can occur if one or more of the following conditions are true:

· The Microsoft Distributed Transaction Coordinator (MSDTC) service cannot be initialized. This occurs if a lightweight remote procedure call (LRPC) association contains an incorrect Service Principal Name (SPN) in its authentication information structure because of the Winspool.drv file.

· The Tracking Profile Editor tries to use RPC to connect to the MSDTC transaction coordinator. When this occurs, the interface may perform additional security checks.

Resolution

When the Tracking Profile Editor tries to connect to the MSDTC on the local computer, the interface that is used may perform additional security checks. Depending on the operating system version and service packs that are installed on the computer, RPC may perform these additional security checks when the interface does not have a registered security callback.

There are two potential resolutions:

· Use the Group Policy Object Editor to disable the RestrictRemoteClients setting that the RPC configuration enforces.

· Use the Registry Editor to disable the RestrictRemoteClients setting that the RPC configuration enforces.

Source: Microsoft

Replaying an Orchestration Instance in HAT

When you replay an orchestration, you are given the opportunity to watch the activity of an orchestration on a shape-by-shape basis. By replaying an orchestration in HAT you can pinpoint where a problem may have originated. For example, by looking at a message flow through a decision shape you can determine if the decision logic is working properly. You can also easily determine where a message was suspended due to an exception or error.

To replay an orchestration instance in the debugger

1. To start the HAT tool, click Start, point to Programs, point to Microsoft BizTalk Server 2006, and then click Health and Activity Tracking. 2. On the HAT tool menu, click Queries, and then choose Most recent 100 service instances or one of the other query choices as appropriate to your situation. 3. In the search results, right-click an orchestration service instance and then click Orchestration Debugger. This brings up the Orchestration Debugger as shown below: 4. Individual actions are listed on each row. Click a row to see the corresponding shape. The shape will be green for start actions and blue for completion actions. 5. Clicking the final initialization action will highlight the path a message took through the orchestration. This can be useful when an orchestration has one or more decision shapes. 6. To switch to the Message Flow views, click Debug | Switch to Message Flow. On the Message Flow screen, click the Orchestration Debugger link at the top of the flow to return to the Orchestration Debugger view.

When viewing an orchestration in the Orchestration Debugger, you will see its state at the last commit point. If you want to see the actual state of the orchestration, you must attach to it by first suspending the instance and then resuming debug mode. You can then attach to the instance and see its current state.

Source: Microsoft

You receive error event ID 324 when parsing dates

Problem

When you use the Database Value Extractor functoid in a map to extract a date field, your document may fail validation against the outbound document definition. BizTalk Server may log a validation error similar to the following in the event log:

Event Source: BizTalk Server

Event Category: Document Processing

Event ID: 324

Description:

An error occurred in BizTalk Server.

Details:

------------------------------

The XML document has failed validation for the following reason: Error parsing '10/12/1995' as date datatype.

Suspended Queue ID: "{A1127909-CA36-4359-B672-7CBA8B60BDAF}"

Cause

The date format (as it is returned from the data source) is not in ISO 8601 format, which is the format required by XML.

Resolution

To resolve this issue, do one of the following:

· Edit your outbound document definition to use a string datatype instead of a date datatype.

· Create a custom Microsoft Visual Basic Script functoid that will convert the output of the Database Value Extractor functoid into the ISO 8601 format.

Source: Microsoft

You receive errors with event ID 5724 or 5719 when using the Base EDI adapter

Problem

When you use the adapter, you receive an error that is similar to one of the following messages when using party resolution together with an EDI receive location:

· The Messaging Engine is dropping the message due to authentication failure. The message came from Receive Location URL "EDI://1234567:ZZ:1234567".

· There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "Microsoft.BizTalk.Pipeline.Components" Receive Location: "EDI://1234567:ZZ:1234567" Reason: There was an authentication failure. "The party corresponding to the inbound message cannot be identified".

Cause

The issue occurs because the BizTalk Server Base EDI adapter does not support party resolution.

Resolution

Create a custom pipeline or orchestration component to scan the InboundTransportLocation context property value and the ExplorerOM object model to enumerate through a list of parties to find a party that has an EDI qualifier value that matches.

Source: Microsoft