Passed the Microsoft BizTalk Exam

As of yesterday I can call myself a Microsoft Certified Technology Specialist (MCTS): Microsoft BizTalk Server 2010.

I passed the exam 70-595: Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2010. I did this making only a single mistake, not bad at all :).

All I did as preparation was reading the book (MCTS): Microsoft BizTalk Server 2010 (70-595) Certification Guide once. This together with the practical knowledge I had gathered on the job made sure I passed the exam easily.

So all credits go to the authors of the book (Johan Hedberg, Kent Weare , Morten la Cour). They definitely achieved their goal. Also the sample questions (and their answers) were very helpful in the preparation.

Identify Performance Bottlenecks in BizTalk

I found a series of blogs on how to identify Performance bottlenecks in BizTalk Environments.
Also look at this article on finding and eliminating bottlenecks

Here's an short overview of all the steps, including a link to the more detailed explanation:

Step 1: Monitoring BizTalk Host Instances via Windows Performance Counters

 The first place to measure the BizTalk performance can be done using Performance Counters. These counters let you monitor all components like the message box, orchestrations, adapters, etc… .

Step 2: Analyzing BizTalk Adapters

A deeper look at the adapter performances, again using some performance counters.

Step 3: Analyze Pipelines

It is important to understand the impact of Pipeplines that are used. Because each of the pipelines have a significant impact on the overall BizTalk performance as they perform actions on every single message that gets through BizTalk
One way to analyze what is really going on in pipelines is using an Application Performance Management Solution with Transactional Tracing capabilities, like dynaTrace for example.

Step 4: Analyzing Orchestration

Orchestration can get quite complex sometimes, but how to analyze the performance of these orchestrations?

The actual logic behind the Orchestration Definition is compiled into an assembly, loaded into BizTalk, and gets executed when messages are processed by that Orchestration Definition. A more detailed overview of the execution of such an orchestration can be generated with PurePath for example.

Another way to analyze the orchestration performance can again be done using performance counters.  BizTalk provides a set of counters for the Orchestration Engine as well as for the MessageBox.

Step 5: Analyzing external service calls (SendPorts)

Often BizTalk Orchestration makes a call to an external web service. PurePath can also give you an idea of the time consumed for this external web service call.

FINAL NOTE

As a final note I would like to point out to use the MessageBox Viewer Tool. The tool gives an overview of what might be wrong in your installation.
This tool runs a set of tests and queries against the MessageBox database an creates a nice report. The result can be viewed using the tool or it can generate an HTML report.

Best practices on Biztalk Tracking

I announced in a previus post that I joined the blogging team on biztalkadminsblogging.com.
However it took untill today before my first blog post was created.

I gave it a long thought what my first blog post should cover. the result is a post on some best practices for the usage of tracking in BizTalk... hope you like it!

The actual post can be found here http://www.biztalkadminsblogging.com/index.php/item/83-best-practices-for-tracking

New blog site: Windows Azure Road trip

There is a brand new developers' blog site on Windows Azure, called windows azure roadtrip. three specialist developers, each in thier own programming language, will be posting some blogs regularly.

Maarten Balliauw (a .NET developer) kicked it off with the very first blog post 'Winsows Azure when you code .NET: what & Why'.
The other blog writers are Michelangelo van Dam (a PHP developer) and François Hertay (a Java developer).

Keep a close eye on this webiste, more useful blog posts to come.

Resource: https://www.azure-roadtrip.be/

joined BizTalkAdminsBlogging.com

My personal blog only exists for a year and a half now, but already has quite some visitors. Yesterday I was even asked to join another Biztalk blogging team on Biztalk administrator related topics. I already knew the blog and was a frequent visitor of the website. Of course I was glad to join the Biztalk blog team.

So, as of  today I joined several other biztalk experts on the BizTalk admin blog BizTalkAdminsBlogging.com.
This blog is dedicated to provide BizTalk admins with useful information, tips, example scripts and everything else that is interesting for a BizTalk admin.

I will still publish posts to this blog, but I will also write an occasional blog post for the BizTalkAdminsBlogging.com website... My first post on the site still has to be written, and any suggestions are always welcome :).

My profile on BizTalkAdminsblogging.com: http://www.biztalkadminsblogging.com/index.php/component/k2/itemlist/user/59-mitchvanhelden

Guideline to Solve Performance issues of Biztalk

Typically a performance problem can be narrowed down to one of the following components of a BizTalk Server environment:

·         A receive adapter or the system from which the adapter is receiving documents. For example, if documents are being received by the HTTP adapter at a suboptimal rate then the problem may be with the HTTP receive adapter or with the client that is posting to the HTTP adapter.

·         An orchestration service instance.

·         Performance of the SQL Server that hosts the BizTalk Server databases.

·         A send adapter or the system that the adapter is sending documents to. For example, if documents are being sent by the SQL adapter at a suboptimal rate then the problem may be with the SQL send adapter or with the computer running SQL Server that the SQL adapter is updating.

Use the following guidelines to help identify the components of the BizTalk Server environment that are performing poorly:

·         Capture any warnings or errors generated in the BizTalk Server or SQL Server Event Viewer.

·         Follow the steps in "Identifying Performance Bottlenecks" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154238 to help identify performance bottlenecks.

Once the poorly performing component has been identified, follow the appropriate guidelines to help resolve the issue:
Guidelines for resolving performance problems related to send and receive adapters

·         For information about troubleshooting problems with BizTalk Server adapters, see "Troubleshooting BizTalk Server Adapters" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154240. This section contains general troubleshooting information including information about how to set up logging for certain adapters, and information that can be used diagnose network problems, problems with MSDTC, problems with the registry, problems with the file system, and problems with IIS.

·         For information about troubleshooting problems with MSDTC, certificates, Enterprise Single Sign-On, and SQL Server, see the appropriate section of "Troubleshooting BizTalk Server Dependencies" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154242.

Guidelines for resolving performance problems related to orchestrations

·         For information about modifying the appropriate sections of the BTSNTSvc.exe.config file, see "Orchestration Engine Configuration" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154244.

Guidelines for resolving performance problems related to SQL Server

·         SQL Server Profiler can be used to capture Transact-SQL statements that are sent to SQL Server and the SQL Server result sets from these statements. Since BizTalk Server is tightly integrated with SQL Server, the analysis of a SQL Server Profile trace can be a useful tool for analyzing problems that may occur in BizTalk Server when reading from and writing to SQL Server databases. For information about how to use SQL Server Profiler, see "Using SQL Server Profiler" in SQL Server Books Online at http://go.microsoft.com/fwlink/?linkid=104423.

·         SQL Server Management Studio can be used to execute SQL statements directly against SQL Server databases. This functionality may be useful for querying the BizTalk Server databases or for updating the BizTalk Server databases in certain scenarios. For more information about using SQL Server Management Studio to execute SQL statements, see "Writing, Analyzing, and Editing Scripts with SQL Server Management Studio" in SQL Server Books Online at http://go.microsoft.com/fwlink/?linkid=104425.

·         For more information about resolving performance problem related to the BizTalk Server databases, see "Troubleshooting SQL Server" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154250.

SAP calling RFC hosted in BizTalk

 I've configured a SAP receive port in BizTalk. However when trying to enable the receive location I got some errors in the error log saying ' 'saprfc.ini' failed: 'No such file or directory' '.  Here is the full error message:

The Messaging Engine failed to add a receive location "RECEIVE MIXED ERIKS SAP" with URL "sap://CLIENT=900;LANG=EN;@a/SAPSERVER/00?GWSERV=sapgw00&ListenerDest=TRADCOMSAPDEST&ListenerGwServ=sapgw00&ListenerGwHost=194.178.122.5&ListenerProgramId=TRADCOMSAPPROG&RfcSdkTrace=False&AbapDebug=False" to the adapter "WCF-SAP". Reason: "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_SYSTEM_FAILURE. SapErrorMessage=Open file 'saprfc.ini' failed: 'No such file or directory'.  AdapterErrorMessage=Error accepting incoming connection. RfcAccept returned RFC_HANDLE_NULL..

Apparently this file is used in the RFC library of SAP:
“The RFC library will read the saprfc.ini file to find out the connection type and all RFC-specific parameters needed to connect to an SAP system, or to register an RFC server program at an SAP gateway and wait for RFC calls from any SAP system.”

How to solve this issue?

First of all you'll need to create a System Variable called RFC_INI. To manage the Environment Variables you'll need to open the system properties and select 'Environment Variables...', as shown below.

Then create the new system variable RFC_INI with a filepath as value, for example C:\SAPINI\saprfc.ini.

 

Next we need to add the contents to our saprfc.ini file.  The values that I needed to provide include: 

Field	Value	description
DEST	TRADCOMSAPDEST	In this case, this is the name of the RFC Destination that our BASIS team created for us from SM59.  More details here.
TYPE	R	Type R is for RFC server programs or for a client program working with another external program as RFC server program which is already registered at an SAP gateway.
GWHOST	SAP_HOST_NAME	In my case, this is the name of the physical server that his hosting the SAP Gateway.
GWSERVER	SAP_GATEWAY_NAME	The name of the SAP Gateway.  A standard naming convention is: SAPGW## where ## is the system number for the SAP instance that you are working on.
PROGID	TRADCOMSAPPROG	This is the name of the Program ID that has also been provided by BASIS.

When you compare the data between the Receive Location and the saprfc.ini file, you'll see a certain symmetry between the two.  However, the values in the ini file take precedence.<br />

 
You'll need a restart of the BizTalk host instance, the one defined on the SAP adapter, for the changes to take effect.
This should be all to resolve the issue.

Source: Kent Weare's BizTalk Blog: SAP calling RFC hosted in BizTalk