Archive for March, 2008

Siebel Adapter for BizTalk Server 2006

March 19, 2008 2 comments

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:

Orchestration with Many Siebel Adapter Calls

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:

Add/Remove Columns

After adding the processing server you should see something like:

Processing Server Shown

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.

Categories: BizTalk Server

Ordered Delivery Trick in BizTalk Server 2006

March 19, 2008 2 comments

The other day at work I needed to change the URL and proxy class of a send port that was using ordered delivery, but that was already suspended with lots of messages queued up in the instance.  So, I did what most of us would have tried, I changed the URL and proxy class, and then I resumed the send port.  Did this work?  No.  The send port kept trying to send the messages to the old URL, using the old proxy class.

So I started trying to see if there was anyway to resolve this without losing messages.  I did what most administrators would have done next: I bounced the host instance.  Did that work?  No.

Then I got creative.  I decided to change the host instance of the send port to another available host instance.  I made the change and pressed ok, but got an error indicating that I couldn’t change the host instance since ordered delivery was on.  So I put things back the way they were and tried once more to resume the instance.  At this point, you’re probably thinking this didn’t make any difference (as I did).  But guess what?  It made all the difference.   Suddenly messages began flowing with the new URL and proxy class!  I couldn’t believe it.  I guess the attempted change of the host instance triggers something in BizTalk, causing it to read in the URL and proxy class again…

I presume this problem exists if you are only trying to change the URL as well (and not the proxy), but I didn’t take the time to verify this.  Hope this information helps someone out there!

Categories: BizTalk Server