Annoying Tomcat Error: “secLDAP security plugin not available”
Deploying Tomcat with Business Objects is so easy and convenient that I almost always do it on at least one server in every Business Objects Enterprise XI cluster that I build. It is a quick way to get in to CMC, an awesome backdoor, and an excellent debugging tool when you main Java Application Server is not behaving properly.
Tomcat, and all Java web apps built by “wdeploy” has one big problem. For some reason they can give you the following error and really confound the best of us:
An error has occurred: The secLDAP security plugin is not available. Please contact your system administrator for details.
The good news is that this error is usually caused by one outrageous default setting in the web.xml file of the BO XI 3.X InfoViewApp web application (or desktoplaunch for BO XI R2). The setting that continues to amaze me is this one:
siteminder.enabled true
Perhaps someone can enlighten us all and explain the reasoning for deploying all desktoplaunch and InfoViewApp web application with the setting in /WEB-INF/web.xml set to “TRUE” for “siteminder.enabled”. I don’t have anything against SiteMinder, I use it, but I have to wonder why this is a default setting. Perhaps SiteMinder paid for this “feature” as an alternative method of advertising.
The punchline is that with the systems on which I use SiteMinder I actually have to disable SiteMinder here to get it to function as I need it. In some cases this setting may not cause you any trouble, but if you get the dreaded “The secLDAP security plugin is not available” in the future, I hope you will remember this article and check your application’s web.xml file for any enabled trouble makers.
Oh, I almost forgot to state the solution. Set this value to “FALSE”, save, and redeploy the application (or just restart Tomcat).
BO XI Distributed Environment: The Standalone Java Application Server
When you are building a small sandbox it is great to put everything all in one place and create a Business Objects solution that is a one-stop shop (a.k.a. putting all of your eggs in one basket). This works for lots of small-to-medium sized BO systems, but sometimes you want to do a little more. Sometimes you want some fault-tolerance, high-availability, and/or fault-tolerance. In any of these cases you might decide to build something really cool: a distributed Business Objects Enterprise XI 3.X Environment.
In this article, I would like to talk about putting your Java Web Application Server on a separate dedicated machine. You could chose Apache Tomcat, or your could get a little more crazy and go with Oracle’s WebLogic. Either way, the principles are the same.
Does BO Support Mixed Mode?
Perhaps your BO CMS, job, and reporting servers are all running on Windows machines. Perhaps you are thinking that you would like to run your Java applications on a Linux server. No problem. Business Objects has documented that it is acceptable to mix different Operating Systems in your BO environment as long as all servers running a particular component are of the same Operating System. What does this mean? It means that you would be running in a unsupported mode if you ran one CMS in your cluster on Windows and another CMS in the cluster on Linux. But if you put all of your web applications on Linux you should have no problems getting support and you should not expect any unusual issues. In fact, in my opinion, if your web application servers are not clustered, you could get away with running Apache on one Windows server and WebLogic on a Linux server, since they do not communicate with each other.
How Do I Create a Dedicated BO Web Application Server?
The hardest part is setting up your Java Web Application Server. I won’t help you here, but there is plenty of help out there in the great Internet to guide you in configuring Tomcat or even setting up WebLogic. Once this is setup all that you have to do is copy the WAR files over to the server (or you can even upload them from your client machine using the WebLogic Administration Console). Yes, this is all you have to do for Business Objects XI 3.0 and later.
Don’t I Need to Install BO on the Server?
No, do not believe the documentation. You do not need to install BO on the server as long as you can generate the WAR files from some other server. It is true! The documentation would have you believe that regardless you need to copy over at least the “deployment” folder and a “java” folder, but this is not true. These are ONLY needed if you are needing to run “wdeploy” on the Java Web Application Server. In my case, I can always use a CMS machine to generate my WebLogic and Tomcat WAR files so why would I want to put BO software on another server? If I put some of the BO binaries on my Java Web Application Server then I have to worry about maintaining/patching the software on that server as well. I don’t know about you, but I don’t need more work and more things to forget to do.
Where Do I Get the WAR Files From?
As I said, go look at the CMS machine. Follow the documentation* to help you find the “wdeploy” application (it is a command-line driven application, probably found here > wdeploy weblogic10 predeployall“. You do not need to configure any “config.*” files for your Java Application Server as these are ignored when running with the option “predeployall”. After you run the command successfully, take about 4 to 7 minutes, then you will be told where your WAR files will be located, for example:
What About XI R2, Do I Need to Put BO on the Web App Server?
All java deployments/application except for the “webcompadapter” are standalone applications that require nothing more than a supported JVM to be installed on the Java Web Application Server. The only application that uses the “webcompadapter” is CMC, so if you are intending to provide CMC access through some other method (such as a small unadvertised Tomcat instance installed on a CMS server) then you do not need to install any Business Objects binaries or libraries on the Java Web Application Server. The issue here is that the XIR2 still has some JNI calls in CMC, it was not fully converted from COM to Java and so the “Web Component Adapter” is required by the CMC and it requires that certain binaries of Business Objects Enterprise XI R2 be installed on the server.
————-
* Recommended published BO documentation is the “BusinessObjects Enterprise XI 3.1 SP2 Web Application Deployment Guide” or if not running Service Pack 2 then use the “Web Application Deployment Guide” for your OS (hint: Unix applies to both Unix and Linux). Of course, the file names will look more like the following: xi3-1_deployconfig_unix_en.pdf or plugin-xi31_sp2_webappd_unix_en.pdf (for example)
Note: I have not played enough with IIS and .NET to know much about deploying the different application there. I am sure the process is quite different, so I would not try to use this article as a guideline for any .NET BO web applications.
To Split Mode or Not to Split Mode, That is the Question?
Wishlist Item: A Distributed Business Objects Enterprise Environment
We all want our BOE environment to perform to the best of its ability. We want to be certain that no particular component of our environment’s architecture is a weak point or bottleneck. As a result, given the time and the hardware, most of us would love to deploy a distributed, well-balanced Business Objects Enterprise environment. In many cases this would include putting each tier or group of services on their own machine/node: the Intelligence Tier (CMS, FRS, etc.), the Processing Tier (Report/Processing, Job, etc.), Web Application Tier (where InfoView and CMC are deployed), and Web Tier (HTTP/HTTPS services). Aside for using multiple servers for each tier, if you read the documentation closely, you could be tempted to take your distribution to the next level.
What is “Split Mode”, “Split-Web”, “Split Deployment”?
The SAP Business Objects “Web Application Deployment Guide” explains that “you can deploy all web application resources on a single web application server (standalone mode), or to separate dynamic and static content for deployment to de-paired web and web application servers (split mode).” The dynamic content, the part requiring actual processing would be deployed to the dedicated Web Application Server and the static content (images and client side scripts, I believe) would be deployed to a dedicated Web Server. The reason behind creating a split mode web deployment would be to better distribute the load of Web Application Server, giving the otherwise under utilized Web Server a little more responsibility.
The following is a list of WDEPLOY supported split mode server combinations:
• Tomcat 5.5 (web app) with Apache 2.x (web)
• WebSphere 6.1 (web app) with IBM IHS (web)
• WebLogic (web app) with Apache 2.x
• Sun Java Application Server 8.1 and secondary web server
Ideals and Reality, Same or Different
My mother used to play a game with us (when we were children) that we called “same or different”. It quickly became and inside joke, a way of indirectly making a comment on something, for example, I would ask my mother something like “Business Objects, a simple/stable/scalable out-of-the-box experience; same or different”. Now I didn’t say that all of them were witty gems.
The truth of the matter is that even if you are successful at deploying Split Mode you won’t find that it makes your life, or that of your servers any easier. It is extremely difficult to get Split Mode working. The guides would have you believe that it is a simple matter of using different parameters with the WDEPLOY application. This may be true for creating the packages to deploy, but actually deploying them and getting them to function is quite a different task.
Benefits Outweighed by Costs
If you are able to get split web working then you have joined the ranks of a very select few and you have also probably burned through at least 3 or 4 of your SAP Business Objects Support Customer Message allocations. So what did all of that work get you? Not much, in fact, even if you are monitoring the servers closely you may not see any change in the actual load on the Web Application Server, even with a large user base. Not to mention, each time you install a FixPack or Service Pack you will have to recreate the magic all over again and ask yourself, was it really worth it?
These are not just my personal experiences and observations. Seasoned Business Objects consultants have expressed similar discontent with this feature. My limited Internet research (forums, mostly) also confirms my findings. I would love for anyone to share their own experience with split deployments in the comments.
