RobServer 8 and RoboAPI.asp

Question

Like many in my position, I am a Technical Author that also administers the document servers for the company. In my case, the Australian Federal Police. I have been using RoboHelp and RoboEngine/Server for many years, so I am quite familiar with the setup. I am also quite close to the development team, who worked with me in the beginning to set up all the applications for the RoboHelp/RoboServer Context Sensitive Help (CSH) technology.
RoboHelp Server 6 and 7 created many problems for me. The constant errors, the weekly server re-boots, the monthly flushing of databases, the daily Windows Service restarts; I'm sure there are others familiar with this as well.
Then along comes RoboHelp Server 8. After a frustrating length of time receiving no help whatsoever from Adobe, I am told that RoboServer 8 will fix everything.
So I put in a case and was given the budget to proceed with the upgrade. Two RoboHelp Server licenses, a Tech Comms suite and three RoboHelp Office 8 licenses. Thousands of dollars and countless hours later, I am no better off because none of our applications can call the CSH from RoboServer 8. None of the documentation for RoboHelp 8 or RoboHelp Server 8 says this up front. In fact, the RoboHelp 8 documentation maintains the use of the RoboAPI.asp for viewing WebHelp Pro output, but, like I said, it just doesn't work and won't work.
In the back of the RoboHelp Server 8 book is the procedure for connecting Tomcat and IIS. If anyone has bothered to look, it is pure gobbledegook. None of the URLs take you to the file downloads and you need a university degree to understand the process anyway.
I now have the Madcap Madpack, plus Madcap Server, which I shall be trialing, but, in the meantime, I have these urgent questions:
Can RoboHelp Server 8 be connected to IIS so that I can use my RoboHelp 6 and 7 API calls that are part of our applications?
Does anyone have a set of instructions that a failry intelligent person can follow to do this?
Currently, our main application uses a configuration file to specify the root server. It looks something like this:
http://<server>:666/ and is placed in the variable strRootPath
The call in the code is defined in the variable strHelpPath and is in this form:
RoboAPI.asp?context=<context ID>
This has worked well for many years and many versions of RoboHelp from RoboEnterprise to RoboEngine to RoboServer 4.
Someone out there has got to have an answer for this. I can't imagine what would happen if I had to go back to the development team and inform them that we have to change the code. For the Web Apps, it would not be so bad, but will still take months of coordination and testing before it can be released. Our main application, however, is another story, and will require the approval of a new On Line Help project. If we have to do that, it won't be RoboHelp!

Answer 1

After some badgering of a couple of the developers, I am almost at the verge of some small milestone. The string that calls the on line help is built using the content of a couple of variables. The main one is the servername. In the old RoboHelp 7 format, it is entered into the config file as http://<servername>:<port>/RoboAPI.asp?
I changed this to:
http//<servername>:<port>/test/server?
(I created a context in RobHelp Server 8 called "test").
The rest of the string is built from the content of a variable that pulls the context ID from a database table. The result is "context=<ID>", so it should work just fine, right?
Well, no, it doesn't.
A help viewer called browser.exe is used to view the help. When the above configuration is used, the help viewer opens with this single line of text:
The help page you are looking for can be found at here.
Clicking here takes you to the correct page, in the help viewer.
There MUST be some way of bypassing that crudely drafted message. There are other issues, but this ome MUST be resolved first.
Anyone?
Please?