BizTalk, Development, Orchestrations

You do not (always) need a correlation set to promote properties in a message sent from an orchestration

It is common knowledge that you use a Correlation Set to correlate message by creating an instance subscription that subscribes to hopefully unique properties. The subscription is created by pointing out a number of properties that you want to use for the correlation. Then when a message is published to the MessageBox that matches that subscription it is delivered to the orchestration. What most experienced developers knows is that Correlation Sets also promote properties as they are initialized; as the first message is sent by the orchestration. There is no other way to manually select properties to be promoted in a message sent from an orchestration. However, do not think that manual promotion through the use of Correlation Sets is the only way that properties will get promoted when published by an orchestration. It is not.

If the property has a Property Schema Base of MessageDataPropertyBase as below, then you do not need a correlation set. You only need to send the message and promotion will be taken care of automatically.

image

Only if you want to promote a property that has a Property Schema base of context type (MessageContextPropertyBase or PartContextPropertyBase) do you need to manually provide a Correlation Set to make sure promotion happens.

image

By *ContextPropertyBase we mean that its origin cannot be found within the data of the message, but is expected to be promoted to the context by another component, such as the adapter, a pipeline component or something else – in this case an orchestration, do you need to manually take action to make sure it is promoted as you publish a message to the MessageBox from an orchestration. And in this case you need a Correlation Set.

Of course if you were to be actually doing correlation with the Correlation Set and not only using it to promote a property then you would still want to Initialize a Correlation Set containing all properties you want to use regardless if these have their origin in the message data or not.

BizTalk, Development, General

Cross Reference notes

This isn’t a really deep how-to technical post, it’s more in the way of “note to self”.

Sample Database Diagram (relations do not actually exist in BizTalkMgmtDb, I added them for visualization).

image 

Sample Cross-Reference Files.

image 

Firing the BTSXRefImport tool

image

Actual tables in BizTalkMgmtDb and sample data selected from xref tables in general and IDXRef in particular.

image

Actual usage of cross reference id functoids

image

Links for BizTalk Cross Reference

BizTalk Server 2009, BizTalk Server 2010, Deployment, Development

Visual Studio (BizTalk Server) 2010 development / BizTalk Server 2009 deployment mix

Can you use the updated development environment for BizTalk Server 2010 with Visual Studio 2010 while still deploying to BizTalk Server 2009?

Can you do it? On a file level, yes. On a project level, yes. On a solution level, doesn’t seem like it. On an assembly level, no.

I tried two scenarios.

  1. A simple messaging only scenario with a transformation on the receive port.
  2. An orchestration scenario picking up the file from the receive location, doing the mapping and delivering it to the send port.

I developed the solution on a BizTalk Server 2010 / Visual Studio 2010 combo and deployed it to BizTalk Server 2009.

So what worked and what didn’t?

Compile and deploy the .NET 4 assembly to BizTalk Server 2009

FAIL!

Why?

Even though I did Add a resource manually selecting the file to be a BizTalkAssembly BizTalk Server 2009 kept on reverting it back to File. Obviously it doesn’t recognize it, or recognizes that it’s an incorrect version of the framework.

image

Re-target the solution to .NET 3.5 or .NET 2.0

FAIL!

Why?

The following is taken from http://msdn.microsoft.com/en-us/library/ff629735(BTS.70).aspx

BizTalk Server 2010 supports building new applications only on .NET Framework version 4 . You can build both BizTalk applications as well as custom applications (such as custom functoids, custom pipeline components) using .NET Framework 4 . However, BizTalk Server 2010 continues to support the BizTalk Server 2006 R2 and BizTalk Server 2009 applications (BizTalk applications and custom applications) built on .NET Framework 3.5 SP2.

If you launch an existing BizTalk project in BizTalk Server 2010 , it automatically gets migrated, changing the .NET Framework version to 4.0. You cannot modify the .NET version number later in the Properties dialog box of the BizTalk project.

In essence it says that you cannot use the re-targeting functionality within Visual Studio 2010 for BizTalk Server 2010 projects. If you try, because the drop down is still there, you get the following dialog:
image

Using Files created by Visual Studio 2010, like .xsd, .btm or .odx

SUCCESS!

You can copy paste files from one project into another, without any issues I detected.

Open the project file created with Visual Studio 2010 and re-compile using Visual Studio 2008

SUCCESS! But with some issues…

You can open a BizTalk project created in Visual Studio 2010 in Visual Studio 2008 and just re-compile it. Without any issues I detected. However, it does not seem like Visual Studio 2008 wants to open the solution file, which may be an issue in some situations, like for example if you wan’t to create automated builds. The structure of the solution file begins like this:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "BizTalk Server Project1", 
"BizTalk Server Project1BizTalk Server Project1.btproj", "{DE7C19FB-A5BA-46A0-9382-ACFB3EB91409}"

This may very well be what causes Visual Studio to dismiss it.

Hope this helps someone thinking along these lines 🙂

Disclaimer: This is tested with BizTalk Server 2010 Beta. All artifacts used while performing these tests are trivial. It might very well be that in some more complex scenario this might not work.

.NET 3.5, BizTalk Server 2009, Development, SOA, WCF

Oh BizTalk, why dost thou mock me?

In any given integration project many different parties are involved. In some cases these parties have standard endpoints against which BizTalk operates and sometimes these endpoints are built as you go in the participating systems to meet a new demand. This is true for other types of projects as well – things get finished at different times – and you need to be able to work independent of each other during that time. What you often do determine very early in the project are the design of messages, schemas or APIs through which you exchange information. In many cases a BizTalk project can effectively use FILE send or receive ports that serve the same purpose as a One-Way send or receive port to say SAP would do at a later stage. But how about solicit-response send ports? What do you exchange these for?


In this post I’d like to introduce a way to handle solicit-response through the use of a catch all WCF Service. There any many ways in which to mock a service. The prime benefit with this approach is that you will be able to model your BizTalk solution the way you want it to be, without having to have access to the real service, and exchange the solicit-response port for it’s production or acceptance test counter parts at your convenience.


To achieve this we need something that let’s us send in any message, and based on some part of the message determine what message to send back, and the send it as a response.


WCF is a perfect candidate. It has functionality both to allow us to create methods that handles all incoming requests by specifying a wildcard (*) as the Action property, and accept any message and can send any message as a return. Using the Message base class it also allows us to easily create the response message, and populate the body of the message from the contents of a stream, such as a file (See the ‘Creating Messages from XmlReaders’ topic in the link).


So what I did was I created a WCF Service, and added a method to catch all messages:

[OperationContract(Action = “*“, ReplyAction=”*“)]
Message CatchAll(Message message);

In the implementation for this method I have include the following code:

FileStream stream = new FileStream(ResponseHelper.GetResponseFile(requestAction), FileMode.Open);
XmlDictionaryReader xdr = XmlDictionaryReader.CreateTextReader(stream, new XmlDictionaryReaderQuotas());
MessageVersion ver = OperationContext.Current.IncomingMessageVersion;
return Message.CreateMessage(ver, ResponseHelper.GetResponseAction(requestAction), xdr);

I have a small helper class that just helps me get data from the config, the config in turn looks like this:

<configSections>
  <section name=”requestResponseHandling
type=”ServiceHost.RequestResponseHandlingConfigSection, ServiceHost“/>
</configSections>
<requestResponseHandling>
  <actionList>
    <add requestAction=”http://tempuri.org/IService1/GetData2
responseAction=”http://tempuri.org/IService1/GetData2Response
responseLocation=”GetData2Response.xml” />
  </actionList>
</requestResponseHandling>

This enables me to add new responses to incoming requests without needing to rebuild the service to incorporate a new response. You could go crazy here with code and undertakings to reply based on some context or what not. In the case presented here I’m just making it simple and returning the same static message for all request that matches a certain requestAction.


Finally, put this in the host of your choice. In my case I’ve got IIS so I’m hosting it there. That will also cause changes to the web.config to automatically get loaded, so that’s happy times.


Using this from a client is super easy. Just point the address of the client endpoint towards this service instead. The only thing that might not be super simple (though still fairly simple) is that you need to know what the meat of the response will look like when serialized as a response (the body of the response message). That is you need to Generate a sample response message from your wsdl.


Now let’s look at how we can utilize this to mock services in BizTalk Server. Oh, but wait, that sounds like it would be a bit of work to do, but… no, that isn’t the case. In fact, once you have configured the WCF service the only thing you need to do is to point your Send port at this service instead of the system that would otherwise be there in it’s place. Loop closed.

Administration, BizTalk Server 2009, Development, Presentation, Usergroup, Webcast

April post-swebug-event resources, part 1

Slides for last wednesdays session with Brian Loesgen and Alan Smith – Development & Administration Best Practices are available through the BizTalk User Group Sweden site here. Check the lower right corner downloads.


UPDATE: Video available here and here.


We used a customized version of the floatzam application and took some pictures of people as they arrived and had tweets, rss and flickr pictures appear on screen live during the period leading up to event starting. All good fun. Not too many saw it though.


image


I will updates this post when the videos are uploaded to channel9.


Meanwhile, here are some pictures from wednesdays and thursdays events.


Flickr:
http://www.flickr.com/photos/37233849@N02/


Twitpic.
http://twitpic.com/3emkg
http://twitpic.com/3cp62
http://twitpic.com/3elog