CODit

BizTalk 2009 R2 Serie (part 1) : Installation & Configuration

by sam 4. March 2010 08:42

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.

Tags: ,

BizTalk

Permalink | Comments (0)

Communication with SAP through WCF custom adapter – Send and Receive Ports

by gcolpaert 2. March 2010 15:40

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 

Tags: , ,

BizTalk | WCF

Permalink | Comments (0)

Communication with SAP through WCF custom adapter – Generate SAP schemas

by gcolpaert 2. March 2010 15:29

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

Tags: , , ,

BizTalk | WCF

Permalink | Comments (0)

Avoid republishing your vocabularies and policies with the Business Rules Engine

by Pieter Vandenheede 1. March 2010 11:19

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.
Although I know that this is not a best practice, it has really save me hours of work!

Be aware though, because there are some pitfalls:
  • If you add new items to your vocabulary, the above will work flawlessly. 
  • If you edit existing items in your vocabulary, you will need to update your rules where you used the vocabulary with the "updated" vocabulary.
    I haven't found yet why this is, but it can create some problems. They are easy to find though, since your friendly name will be replaced with an xPath function.

By the way: you can do the same for policies: take a look at the re_ruleset table in the same database (BizTalkRuleEngineDB)..

 

Good luck!

Pieter Vandenheede

Tags: ,

BizTalk | Business Rules

Permalink | Comments (0)