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

"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

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 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

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