Arrays in BizTalk Orchestration - Part I

I really don’t know why but I often hear from BizTalk developers that XLANG/s does not support arrays. The truth is that arrays in BizTalk orchestration are not an issue at all. XLANG/s does fully support arrays. More than that, XLANG/s fully supports indexing within arrays.

Here's some links:

"BizTalk Server can consume one dimensional and jagged arrays exposed by Web services that are not BizTalk Web services" (Support for consuming arrays exposed by Web services) http://msdn2.microsoft.com/en-us/library/aa561724.aspx

"XLANG/s supports single-dimensional arrays, but does not support array literals" http://technet.microsoft.com/en-us/library/aa560334.aspx

How to Consume Web Service Arrays: http://msdn2.microsoft.com/en-us/library/aa559325.aspx

I suppose the reason to this mistaken is because of the following downfalls:

1. You can’t declare typed array (like string[]) variable in the Orchestration editor.
2. You can’t initialize typed array using 'new' keyword (arr = new string[4] is not valid)
3. XLANG/s considers Array as primitive and not as an object. This means you can’t use useful methods and properties like Length (arr.Length is not recognized)

On the other hand, BizTalk 2006 was designed with Xml web services in mind – this means that every serializable object is accessible from inside BizTalk orchestration. If you need to consume a web service that returns array, BizTalk will serialize the web message part into the appropriate CLR object and not just into general System.Array object.

A Great new integration blog

Alex Linder is one of the integration consultants in our company and a very good friend.
He is one of the fewest people I know with a lot knowledge and experience of many integration technologies.
In the past last years he is examining products like Microsoft BizTalk Server, WebSphere Message-Broker and WebSphere MQ to the very edge.

Now he sharing his investigations and tips in his great new blog: http://linderalex.blogspot.com/

It's a great place for all you integration experts so stay tunes – I'm sure I would!

Congratulations Alex.

Publishing BizTalk Orchestration as WCF service

Some issue I encountered when publishing BizTalk Orchestration as WCF service.

After the wizard finished, I tried to browse to the svc file and got the following error:

Type 'System.ServiceModel.Activation.HttpHandler' cannot be instantiated under a partially trusted security policy (AllowPartiallyTrustedCallersAttribute is not present on the target assembly).

It seems that WCF can't initiate itself with less then full trust policy. To solve this edit the service web.config under <system.web> section with the following entry:

<trust level="Full">

By this you'll grand the service full trust security policy.

Another error is: Receive location for address ".svc" not found. (The BizTalk receive location may be disabled.)

This one means that the target Receive Location in BizTalk administration is not existing (you didn't check the option in the wizard) or it's not enabled.

BizTalk Context Property Class Generator - BTSPscGen.exe

When working with BizTalk Pipeline components, it’s a common requirement to work with context property values.

The context property key is actually XML element defined in the Property Schema, and is a combination of the name and namespace of the XML element.

To read a context property value, you use the Read method on the context object of IBaseMessage:

object Read(string strName, string strNamespace);

Now, because its so easy to make mistakes with the name and namespace (just like all other string value in your code) its very advisable to save those values as constants. Something like that:

const string EPMRRCORRELATIONTOKEN_NAME = "EpmRRCorrelationToken";

const string EPMRRCORRELATIONTOKEN_NAMESPACE = "http://schemas.microsoft.com/BizTalk/2003/system-properties";

public IBaseMessage Execute(IPipelineContext context, IBaseMessage inMsg)

{

object epmObj = inMsg.Context.Read(EPMRRCORRELATIONTOKEN_NAME, EPMRRCORRELATIONTOKEN_NAMESPACE)

if (epm != null)

{

//Do Something here

}

return outMsg;

}

More elegant way is to use the classes in Microsoft.BizTalk.GlobalPropertySchemas.dll

public IBaseMessage Execute(IPipelineContext context, IBaseMessage inMsg)

{

BTS.EpmRRCorrelationToken epm = new BTS.EpmRRCorrelationToken();

object epmObj = inMsg.Context.Read(epm.Name.Name, epm.Name.Namespace);

if (epm != null)

{

//Do Something here

}

}

You can see the benefits of the second approach with Reflector:

• The class has Type property that is the CLR object type of the context property value.
  
• System.Xml.XmlQualifiedName object (that have some useful method itself) include the name and namespace values.

To me it's seemes that the above is the most appropriate way, so, if you want to create your own GlobalPropertySchemas.dll follow thoes steps:

1. Create a new BizTalk project
2. Create a folder with the appropriate Name (ex. ESB)
3. Add a new property schema (ex. ESBProperties)
4. Add the context-properties (ex. ServiceName).
5. complie

the results are generated classes for each context-property (ex. ESB.ServiceName)

For educational proposes, I once wrote a utility that takes a user defined BizTalk schema property and generates this class for every element so you could see what happens behind scene. also, you can extend this tool and create more "smart" classes for your own GlobalPropertySchemas.dll

So, go ahead and start using your own GlobalPropertySchemas.dll in the very same way that BizTalk artifacts are using property schema elements from inside code.

BTSPscGen.exe source-code can be download form: http://pinhask.googlepages.com/BTSProperySchemaClassGen_Source.rar

Enjoy!.

BizTalk Host instance and Windows NT Services limit issue

When developing SOA/ESB solutions, you should NOT use the same Host instance for more then one service. the reason is because all messages will be writen into the same table (queue), so if one service is consumed intensively, the other services will experience latency.

To avoid this, it's a known best-practice with BizTalk solutions, to create at least 3 Hosts instances per service:

• Orchestrations Host
• Receive Ports Handler
• Send Handler

An important and little known issue is the limit number of host instances that can be defined on a single machine.

Every host instance in BizTalk is implemented as a Window NT Service with the prefix 'BizTalk Service BizTalk Group : 'HostName'.

Now, services can run under one of two Accounts:

• User Account
• LocalSystem

Windows can host unlimited number of services running under LocalSystem, but By Default, has a limit number of services running under User Account (from my experience with Windows 2003 Server it's between 23 to 25, based on the service memory usage).

If you reach this limit, the host instance won't start and you'll get the following error massage:

1053 The service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.

The only solution is to decrease the memory for each desktop on the computer.

In the following I'll show you how to set this key in the system registery:

Run regedit.exe and browse to:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Find the key 'SharedSection=1024,3072,512'

The third value (512) is the desktop heap for each desktop that is associated with a "noninteractive" window station. this value can be decreased down to 128.

More information can be found on http://support.microsoft.com/kb/184802/en-us (cause 2).

Very important:

Please DON’T do this on production environment before a VERY CARFUL test – this key can affected and harm the system very badly. So please check if it suitable for your system before running and applying it.

The ESB Guidance – hello ‘SOA’ world

Introduction to BizTalk solutions architectures.

Almost all IT professionals are familiar with the benefits Service Oriented Architecture (‘SOA’) approach is offering, therefore the term ‘ESB’ is not a buzz word any more.

As a BizTalk developer the architecture you often use is known as ‘Hub-And-Spoke’. This means we’re using BizTalk as a middleware application (known as a ‘Broker’) between of all other applications. When app A needs to interact with app B, it will submit the request to the broker application. The broker then will make the preparations needed to redirect the request to app B (one example is transformation) and then route the message into app B and vice versa.

Enterprise Service Bus ('ESB') extend of the traditional EAI and MOM broker with some capabilities like:

• Web Service standards
• Integration with rang of protocols and technologies.
• metadata registry

As a rule of thumb, ESB is the gate into the ‘SOA’ world.

It means you don’t develop ‘Application’ anymore; from now on it is about ‘Services’.

If you’re new with ‘SOA’ you can learn about it here.
Also, you can find an overview of BizTalk Server based 'ESB' here.

Now, because of BizTalk ‘Hub-And-Spoke’ nature, developing ESB solution based on BizTalk Server require massive development of infrastructures, The ESB guidance is Microsoft way of achieving it in the fastest way by integrating and relaying on common Microsoft technologies.

Microsoft ESB Guidance is here

Microsoft finally released the toolkit for developing ESB solutions based on BizTalk Server.
if you're a BizTalk developer and 'ESB' is your second name [the first one is probably 'SOA' :-) ] this set of powerful tools was designed exactly for you. It can make your life match more happier and save you a lot of coding time.

you can find the ESB Guidance on the MSDN Here

In the next few posts I'll give you a deep dive into this new exciting tools and framework.