Siebel Adapter for BizTalk Server 2006

After working on a project that uses the Siebel Adapter heavily, I learned a lot. I found so little documentation on the adapter and best practices, that I’m hoping the post will help someone out there with a similar problem. I suppose some of the lessons learned might very well apply to the Oracle Adapter or another adapter.

So, what was my problem? Inconsistency. For starters, here’s a UML activity diagram to give you an idea of what my orchestration looked like:

And this goes on and on for something like 8 Siebel calls (I didn’t bother to draw this).

I had the basic functionality working. However, like I mentioned, I’d get inconsistent results. Sometimes I’d get decent performance; sometimes I’d get horrible performance; sometimes I’d get cryptic Siebel errors. This post will hopefully explain what I ended up finding after days of frustration.

Let’s start with the cryptic Siebel errors. Here’s what I saw a couple of times:

E-SBL0030: Call to failed; Siebel error msg- Business object handle could not be got from the name.The task 41080 has either been shutdown or timed-outFailed to get business object from business object name : Customer Complaint Case BO; Siebel error code- 106

This error was always accompanied by a similar error:

E-SBL0030: Call to LogOff failed; Siebel error msg- The task 41080 has either been shutdown or timed-out; Siebel error code- 106

Fortunately, our Siebel guru and fellow BizTalk Developer, Prashant Kulkarni, recognized the error enough to provide a simple solution: restart the Siebel Applications Server. I guess as a custom they typically bounce the Enterprise Server and Gateway Server as part of that.

Okay, the next problem I had was inconsistency:

After fixing the infinite loop that occurred in a fringe case (oops!), the main issue with consistency I faced were timeouts from what I believed to be Siebel. I assumed the Siebel server was under heavy load when I got these errors at first. It wasn’t until I started monitoring the throttling state constantly, that I found the real problem: BizTalk had started throttling my orchestration and the Siebel calls, so consequently messages would take too long before being sent out to/from Siebel. The result: timeouts. Finding this problem was a little tricky at first. Here’s why:

When inconsistency and poor performance were first detected, I moved the host instance to two servers, thinking that doubled resources would solve the problem. Well, this assumption was naive. The equation was a little more complicated than that.

Also, the BizTalk Admin Console by default doesn’t show you the processing server, so unless you’re careful, you might monitor the wrong machine and find nothing. Fortunately, in my case, I was used to this problem and I always add the “processing server” as soon as I start looking at performance issues. Here’s how if you’ve never done this before. From the Admin Console right click on the shown columns displayed from any query. You’ll then see:

After adding the processing server you should see something like:

Before I get started into the meat of this let me first say that if you have no idea on how to check throttling you might want to run a Google search on “BizTalk Performance Monitoring” or something like that. I used the graphical Windows tool called “Performance” in the Administrative Tools section for my work on this…

I first started monitoring the “Message Delivery Throttling State” on the first server and found nothing (throttle state of zero). Then, I took a look at server #2: nothing. At this point I probably sat frustrated for a few minutes and complained to myself. After the complaining was over, I looked for more throttling monitors. I found “Message Publishing Throttling State”. I didn’t think this was my problem, but I added the monitor to server #1: nothing. I then added it to server #2, and lo and behold: throttling in state 4 (throttling due to process memory usage)!

Once I found this, things immediately started looking brighter. I was able to adjust the throttling settings so that it wouldn’t throttle until I began using 1000 MB of memory for the host instance (I tried some other values first but found this to be about right). This immediately helped. After that, I found that monitoring memory usage and the throttling state was very helpful while I checked on performance. Professional BizTalk Server 2006 by Jefford, Smith and Fairweather has a good section on performance, which I referenced quite a bit too.

The irony of the whole thing is that the Siebel Adapter starts using more memory for its processing, and BizTalk starts throttling, which causes BizTalk (or me, rather) more problems than it started with. In conclusion I’d say that I think I found the Siebel Adapter’s worse enemy for my kind of situation: throttling. Why? Because of timeouts. Querying Siebel Business Objects can take a while – the last thing you want is to start timing out as a result. Performance went from 30+ mins for processing of my orchestration down to 60 seconds! Amazing. And, my orchestration started getting consistent results.