integrating your business

Yesterday Peter Borremans and Sam Vanhoutte were guest speakers at the BizTalk User Group Sweden in Stockholm.
We presented an overview of Microsoft Host Integration Server, a product that allows you to integrate with resources on IBM Mainframes and Midrange systems. The presentation went smoothly and all the demo's worked :)
It was a great pleasure to present this product to the many interested people who attended the presentation.

The slide deck of our presentation can be found here. (change the file extention to 'pptx' after downloading)
When the presentation is available online, we will post a link on this blog.

 Peter Borremans

Host Integration Server is by default configured to use 'smart multihoming'. When using smart multihoming, the Host Integration Server (HIS) will send all his available IP addresses to the clients. The SNA client will use the address from the list with addresses received from the server that is closest to its own subnet or IP address.

In some scenarios smart multihoming can cause some problems. What if one of the IP addresses received from the HIS server is not reachable (e.g. an IP address that is used to link to a separate network)? In that case the client will try to connect to one of the other address received from the HIS server. This only happens after a delay (default 45 seconds). After the delay the client will connect to the IP address that connects successfully.

This delay when connecting to the server is not a desired behavior.

How do we fix this?

On the client we can disable smart multihoming. To do this, make sure that this registery key 'ReadjustMultihomedAddresses' is set to 'NO'. If the key does not exist, create it. The location of this registry key should be: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Snabase\Parameters\SnaTcp'.

If smart multihoming is disabled on our client, the new behavior is as follows: the client will try to connect to a server IP address in the order as the client received them from the server. Again, this causes problems... What if the IP address that is not reachable appears first in the list? We will again see a long delay when connecting to the server. Luckely we can fix this!

Host integration server uses the network bindings to determine in what order to present its IP addresses to the client. You can find the network binding  on the 'Network Connections' sceen, 'Advanced' menu option, 'Advanced Settings...', then 'Adapters and Bindings' tab. On that tab page, every network connection is listed and we are able to change the order in which they appear. Adapt the order to your needs (reachable IP's first!!!). Host Integration Server will use the order specified here to send it's IP list to the client.

Now that both steps are done (disable smart multihoming AND change the network bindings on the server), the client will no longer experience a delay when connecting to the HIS server.

Peter Borremans 

On 16th March, CODit is speaking at the BizTalk User Group in Stockholm (Sweden).

CODit is presenting an introduction to Host Integration Server, the secret gem of Microsoft :)

You can subscribe here: http://swebug20100316-widget.eventbrite.com/

Content of the presentation:

Session: Introduction to Microsoft Host Integration Server
Speakers: Peter Borremans & Sam Vanhoutte

Over the years, a lot of companies invested in IBM mainframe (zSeries) or midrange (iSeries) systems. The mainframe architecture is not compatible with nowadays standards and architectures. Rewriting applications is not always feasible and desired. These applications are often very large systems with high reliability and performance. If possible
people's skills must be reused. This leads to the need of integrating with existing host systems. Microsoft created Host Integration Server (HIS) to integrate with host systems.
This session will cover all important components of HIS and how Mainframe functionality is exposed to newer technologies:

Network integration

As mentioned earlier, IBM host systems (most of the time mainframe systems) use a proprietary network architecture.
HIS network integration will allow other systems to connect to those networks and expose functionality higher up in the stack (MQ, Applications, Data).

Data integration

HIS data integration will allow Microsoft systems to access data stored in DB2 databases or in VSAM files.
This is either done with by using .NET data providers (DB2 or VSAM) or by using BTS adapters (DB2 or VSAM)

Application integration

HIS application integration will allow Microsoft systems to interface with IBM host applications as CICS transactions (Transaction Integrator) or IMS.
Application integration is without any doubt one of the most powerful features of HIS.

Messaging integration

By using HIS, Microsoft BizTalk server can communicate with MQSeries on any other platform. HIS provides a WebSphere MQSeries client-based adapter. This adapter does not require a MQSeries installation on a Windows Server box. The WebSphere MQSeries client-based adapter allows direct access to MQSeries on host systems.

Welcome to the first of many posts around BizTalk Server 2009 R2, the latest version of BizTalk Server that is scheduled for release later this year. 
As many times before, CODit is again part of the TAP (Technology Adoption Program).  In this serie, I will create a post for each new feature in this version.
This post will probably the less interesting one: installation and configuration :)

The 2009 R2 version can be installed on the latest available platform: Windows Server 2008 R2, SQL Server 2008 R2 and .Net 4.0.  Therefore, I decided to take the latest available releases for all these products and install them on my Virtual PC.
Windows Server 2008 R2.
First issue: the Windows Server 2008 R2 version will only be available in a x64 build.  While this makes perfectly sense (who configures a 32bit server nowadays?), it raised an issue for me.
I am using Virtual PC as the virtualization software on my development laptop.  But VPC does not support hosting x64 operating systems.  Microsoft makes this only available through Hyper-V.  But since I am testing on my laptop, I don't want to install Hyper-V, which would make me lose my 'stand-by'/'sleep' features.
Therefore, the only options left were VMWare or Sun VirtualBox.  I decided to take the last one. 
After the installation of Windows, it became clear that a lot of the Windows 7 UI features made it in the Windows 2008 R2 release, which is cool.

SQL Server 2008 R2.
For installation of SQL Server, I installed the November CTP release.  Installation went smoothly.  New features like StreamInsight and Master Data Services are not available through the standard setup wizard.  They need to be installed through a seperate MSI on the DVD. 

Visual Studio 2010.
Installing the 2010 RC version of Visual Studio went fine, during the deep-dive sessions we had in Redmond, we already had a chance to play with it, so nothing shocking here...

BizTalk Server 2009 R2.
In the setup features, there are no new features available at first sight:

I closely followed the installation of BizTalk Server and there was only one thing that looked new to me: we finally have a download/progressbar for the prerequisites cab.  I know of too many customers who just stopped the installation of one of the previous versions of BizTalk, while it was downloading the cab-file.  Finally we have visibility on this:

The configuration of BizTalk hasn't changed at all.  No new features or sub-features are available in the Configuration Wizard.  So, next thing after install will be to find out where the new features like the settings dashboard and trading partner management will be...

Part 2: the new and enhanced BizTalk mapper.

In order to successfully setup communication with SAP. You have following configurations.
In terms of the SAP part you need to have following things on SAP side:

·         A SAP user with suitable access

·         A RFC connection (This will specify the ‘listening’ program running on BizTalk. (SAP transaction SM59)

·         A tRFC port which uses the RFC connection defined above. (SAP transaction WE21)

There is also some setup in terms of messages. Assignment of messages to receiving/sending partner…
But this would be down to the SAP team for doing this sort of implementation.

The most important thing from BizTalk point of view is the configuration of the Send and Receive ports.
There for you need to first generate the correct SAP schemas.  (See blog post: “Communication with SAP through WCF custom adapter – Generate SAP schemas”).

Note: When generating the SAP schemas, BizTalk will provide you with the correct bindings to setup the Send/Receive Ports.
On the other side, it’s better to cross-check that configuration to be sure that you have the correct setup.

Send Ports

Your URI should look like this:

sap://CLIENT=[SAPClientID];LANG=[LANG];@a/[ServerName]/[SystemID]?RfcSdkTrace=False&AbapDebug=False
ex: sap://CLIENT=235;LANG=EN;@a/10.80.32.3/00?RfcSdkTrace=False&AbapDebug=False

In the SOAP Action header you should specify the action, this action you can find in the configuration of your generated SAP schema. 

Double check the configuration of the URI and do not forget to add your credentials to avoid logon problems. 

Receive Ports

Your URI should look like this:

sap://CLIENT=[SAPClientID];LANG=[LANG];@a/[ServerName]/[SystemID]?ListenerGwHost=[ListenerGWHost]&ListenerGwServ=[ListenerGWService]&ListenerProgramId=[ListenerProgramID]
ex: sap://CLIENT=235;LANG=EN;@a/10.80.32.3/00?ListenerGwHost=10.80.32.3&ListenerGwServ=SAPGW00&ListenerProgramId=BIZTALK_CODIT

The SAP team has to provide you with the correct variables. Again, do not forget to add your credentials to avoid logon problems.
If you still have issues with enlisting your Receive Locations you should paste following entries in c:\windows\system32\drivers\etc\services.
 Services.txt (3.71 kb)

Enjoy !

Glenn Colpaert 

In order to send and receive messages from SAP you need to have the correct schemas generated from SAP.
To successfully generate those schemas you need following prerequisites installed.

·         BizTalk - SAP LOB Adapter SDK SP2

·         BizTalk – Adapter Pack 2.0

·         BizTalk – SAP client libraries 

Create a new project in Visual Studio. Click “Add Generated Items”. 

Select “Consume Adapter Service”.

Select the “sapBinding” and press “Configure”.
Configure the URI properties (application server host, the gateway host, the gateway service, the system number, the client, programid) and credentials provided.

When the configuration is finished press the “Connect button”.
In the following sceen you can Select Client (Outbound operations) or Server (Inbound Operations), then you can select the IDOC you want.
Be sure to select the correct version of the IDOC. Select the Send or Receive operation and click “OK” to generate the schema.

 Generating a schema will provide you with the correct schemas and a binding file that you can use to setup the receive or send port.
(See blog post: “Communication with SAP through WCF custom adapter – Send and Receive Ports”)

Enjoy !

Glenn Colpaert

Anyone who has ever worked with Business Rules and with the Business Rule Composer has had it's share of problems when you want to perform a small modification to their policy or vocabulary.

Normally, when in production or QA phase, you would copy/paste your old version to a new version of the policy/vocabulary and then modify what was needed. The tool does not allow you to change already published policies or vocabularies. This to make absolutely sure that the same version of the policy/vocabulary would not result in different results.

Now this is all fine unless you are actually developing everything from scratch.... 
Now, most of the time you would work with a vocabulary and would build this along the way. Publishing a new version every time you add a new entry to your vocabulary is a common thing, but at the end of your work you end up with several versions (sometimes up to 10/20). This makes it quite difficult to maintain.
What makes it worse is that your rules depend on specific versions of your vocabulary...

At the end of your business rules development you would most likely want just one version of your vocabulary and one version of your ruleset (most likely v1.0).
This means that you would need to update all your rules and all your vocabularies which is again a very time consuming process.

Now, we found a little trick that enables you to "un-publish" a vocabulary and even a ruleset while you are developing them. Off course this is something you would only do while actually developing it from scratch. It would definitely be a bad practice to execute this on production vocabularies and/ or policies!! 

Here's how you do it for vocabularies:

1. Publish your vocabulary and use it in your ruleset to test your rules.
2. When you need additional changes to your vocabulary, go to "SQL Server Management Studio" and open the contents of the DB table "re_vocabulary" in the DB "BizTalkRuleEngineDB".
3. Check your vocabulary name in the "strName" column (second column in the table), together with the "nMajor" and "nMinor" columns which together make up your version number of your vocabulary.
4. Once you found your particular vocabulary, set the "nStatus" column to 0 instead of 1 to "un-publish" your vocabulary.
5. Reload your Business Rule Composer view (Press F5).
   Be aware that you need to be able to save your rulesets/vocabularies without errors to be able to do so.
6. Perform the necessary changes to your vocabulary set...
7. Republish, but not using the Business Rule Composer, but via setting "nStatus" to 1 again.

Good luck!

Pieter Vandenheede

The following warning is often seen on servers running Microsoft Host Integration Server:

Log Name:      Application
Source:        SNA Base Service
Date:          date
Event ID:      561
Task Category: None
Level:         Warning
Keywords:      Classic
User:          user
Computer:      computer
Description:
Write to mailslot or socket failed, rc = 64

 EXPLANATION

 A Win32 WriteFile() or winsock sendto() call failed. The return code is shown.

 ACTION

 Provide network support personnel with the event log file(s) related to SNA, and the return code included in this message. For information about SNA log files, see the "Microsoft Host Integration Server Online Books.

 The warning is caused because Host Integration Server tries to communicate with all the servers in a subdomain (and the clients) via broadcasts messages. Host Integration Server does this over all protocols that are selected in the SNA Manager. Not all of these protocols are enabled on your network, if one of them is not enabled this warning will pop up.

To fix this warning unselect the protocol that causes the warning as shown in this screenshot.

Typically you enable TCP/IP and you disable Named Pipes. After adapting the configuration the warning disappears.

Peter Borremans

When adding a Web reference to a BizTalk project, the following message appears:

There is a problem with the WSDL but you don't get any extra information.

The cause was this part in the WSDL:

<port binding="tns:TestServicePortBinding" name="TestServicePort">
          <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>

Apparently a BizTalk project can't handle an invalid location (a Console project doesn't have any problem with this!).

The problem was solved by putting the filepath of the WSDL in the location attribute.

To find this problem i removed part after part of the WSDL untill the import went fine. It's a good practice to identify different kinds of WSDL problems.

For one of our projects, we are receiving unicode messages through a receive pipeline containing only a BTF disassembler (BizTalk Framework). The disassembler has the standard properties and the AllowUnrecognizedMessage set to true.
When we are receiving a UTF16 unicode message (with no byte order mark in the stream!), the disassembler crashes with the known error : No disassemble stage components can recognize the data.
Sending a UTF8 message works.

The BizTalk Xml Disassembler normally tries to detect the message's encoding by executing these steps:

1. If a byte order mark is available in the data, the encoding is extracted from it.
2. If the IBaseMessagePart.Charset property is set, that setting will be used.
3. Xml Declaration will be used, when available
4. If none of the above are met, the default, UTF-8, is used.

The message we received had none of the first 3 conditions, so it was interpreted as UTF8. By setting the Charset property on the IBaseMessage in our custom pipeline component, we were able to pass it through the Xml Disassember.

The BtfDisassembler was raising another error, now. My conclusion (and Tomas Restrepo's too) was that the BtfDisassembler was not able to process Unicode messages.

The solution to this was using our CODit Charset decoder that creates a new stream, with the UTF8 encoding. This was working.

Thanks to Tomas Restrepo, who investigated a lot on this and wrote an entry on his blog : http://www.winterdom.com/weblog/2006/05/19/DecodingUTF16MessagesWithTheBizTalkFrameworkDisassembler.aspx