BizTalk UTF-8 codepage

I guess it's only me but after working a lot with BizTalk and WMQ, it was so clear to me that UTF-8 codepage is 1208. so today when working with the SAP adapter against Hebrew records we set value of the BizTalk Code Page as 1208 . the correct value is actually 65001.

I also find this about the SAP Adapter: http://msdn2.microsoft.com/en-us/library/aa562108.aspx

With Service Pack 1 installed, you must specify the appropriate encoding on any new and existing SAP receive port while receiving the IDoc. For example, if you need to receive Japanese characters, you may want to consider setting BizTalk Code Page as 65001, which is UTF-8 encoding.

Finally, look inside the UTF8Encoding class:

 

So for all of you out there:

• For IBM products (like WebSphere MQ) UTF-8 codepage is 1208.
• For widows based products UTF-8 codepage is 65001.

thanks to Amir Cohen for that.

Dynamic Send Port - Host instance limitation

In a previous post, I wrote about the importance of choosing the right Host instances for a peacefully working 'real-world' BizTalk solution. Although this is right for all BizTalk artifacts, unfortunately there's one exception: Dynamic Send Ports.

The analogy behind Dynamic ports is a wish to provide BizTalk the flexibility of 'SOA' - a way to create an atomic service that has no intension with the End-Point protocol/technology. the Dynamic ports are the way BizTalk server is combining it's Orchestration engine with the Adapter framework layer. in runtime - the orchestration will inform the adapter engine with the information about the destination Protocol and URI and the adapter engine will ship the message to that location using the right Adapter instance.

This magic become possible thanks to the Microsoft.XLANG.BaseTypes.Address class who derived from PortPropertyBase class under Microsoft.XLANG.BaseTypes.dll.

When passing those's parameters to the port, the Adapter engine is checking the value of Address to be associated with the adapter prefixes table. for example the following will cause the FILE adapter to handle the sending process:

 

The ability to "late-bind" the Adapter instance to associate with the Send process actually forces us to disallow any Host Instance configuration at design-time - the adapter can be In-Process Host like the FILE or WCF Adapter and equally can be Isolated Host like SOAP Adapter.

The BizTalk team choose to handle the Host-Instance resolving is to use the default Host Instance configured for the Adapter. because of this most unacceptable design, use can find your process running under BizTalkApplicationHost and BizTalkApplicationIsolatedHost instances. so eventually, this means we can't use Dynamic Ports in most of our BizTalk Solutions!.

After all this, I've been surprised to find that in the newly published ESB Guidance (v1.0), the Agent who responsible of routing (Delivery agent) was implemented using a Dynamic Send Port.

Just imagine what will happen if ALL of the specific Adapter of the entire ESB are running on the same Host Instance. So, I really can't understand this design, more then that - I encourage you NOT to use the default Delivery Agent in a real ESB environment.

Let's just hope that the team will fix this behavior and there will be a way of choosing the correct Host Instance within Dynamic Send port - then we'll can enjoy the benefits of 'SOA' with BizTalk solutions.