Problems accelerating Siebel v8 server with Linux Access Gateway

  • 7008714
  • 07-Jun-2011
  • 26-Apr-2012


Novell Access Manager 3.1 Linux Access Gateway
Novell Access Manager 3.1 SUpport Pack 3 applied
Siebel version 8 running on Secure web server (SSL enabled)
Siebel version 8 running on non default TCP port 13000


Access Manager setup and working fine ie. all users can access protected resources on the Linux Access Gateway (LAG) after having authenticated at the Identity (IDP) server. A new application was rolled out requiring the same behaviour - Siebel 8 back end web server running on an SSL enabled web server over TCP port 13000. As soon as users started accessing the application, the main Siebel page would include a number of broken links, as well as reporting Javascript errors.

The Web server hostname and TCP port were different to the published DNS hostname of the proxy service and it's listening TCP port. There were no possibilities to change the web server TCP port to match the TCP 443 port the secure proxy service was listening on.


Make sure that the Web server hostname matches the published DNS name of the proxy service.

Additional Information

The default rewriter configuration was modified so that the search and replace strings rewrote the references to web_server_hostname:13000 coming back from the Siebel server. After doing this, we confirmed (using Microsoft STRACE output for example) that all strings were rewritten correctly. However, selecting any field within the Siebel application eg. customers, would return a broken link. LAN traces or STRACE logs would indicate that we continued to generate TCP requests to the web server IP address directly on TCP 13000.

Siebel uses Javascript in such a way that the URL references are not specific eg. instead of referencing, it would be referenced as URL=protocol + host + port + object where protocol is https; host is; port is 13000 and object is /callcenter_enu/start.swe. The LAG rewriter is not capable of detecting and completely rewriting these objects sent back from the back end.

Since the LAN traces showed requests going to the web server host despite all HTML data appearing to be rewritten, we changed the hostname of the web server to match that of the proxy service, which fixed the issue.