Random Thoughts

Views on life

Posts Tagged ‘BOE Administration’

How to configure IIS Tomcat connector (ISAPI connector) for BusinessObjects

Posted by Hemanta Banerjee on October 28, 2010


One of the frequent questions I run into on the BOBJ board is around setting up IIS and tomcat connector for BusinessObjects. I believe most of these posts are from customers using BusinessObjects Edge which does not support IIS as the web server. In order for this to work I used the Jakarta connector (AJP13) from Apache which allows IIS to forward specific requests to Tomcat. This is especially useful if you want to enable Windows Integrated Authentication for your IIS server and setup SSO with trusted authentication. This setup would enable the user to logon to InfoView without having to enter any user id or password.

Setting up ISAPI connector with IIS

The AJP13 Jakarta connector (version 1.2.14) can be found on Apache Software’s site at: http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.14/. Download the isapi_redirect-1.2.14.exe.

image

This is a windows installer and after installation it would have setup a couple of things. By default the software is installed in “C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector”.

image

Installing and Configuring the Jakarta Connector on IIS

Step1: Configure the ISAPI connector configuration files. There are 2 main files to edit

workers.properties.minimal – This file provides configuration properties needed to connect to Tomcat. Find the “worker.ajp13w.host” and change the value from localhost to <machine_name>

image

uriworkermap.properties: This file contains all the mappings that will use by the ISAPI connector. There are some defaults. In the next step we will add the BusinessObjects related URL’s here.

image

I needed to add the following to this file as shown above

/businessobjects/*=wlb
/jsfadmin/*=wlb
/dswsbobje/*=wlb
/styles/*=wlb
/AnalysisHelp/*=wlb
/AnalyticalReporting/*=wlb
/AdminTools/*=wlb
/AnalyticalReporting/*=wlb
/bomm/*=wlb
/BusinessProcessBI/*=wlb
/CmcApp/*=wlb
/CmcAppActions/*=wlb
/CrystalReports/*=wlb
/DataServices/*=wlb
/doc/*=wlb
/dswsbobje/*=wlb
/ExtendedAnalytics/*=wlb
/fim/*=wlb
/Flexstore/*=wlb
/InfoViewApp/*=wlb
/InfoViewAppActions/*=wlb
/InfoViewPCM/*=wlb
/MetadataManagement/*=wlb
/OpenDocument/*=wlb
/PerformanceManagement/*=wlb
/PlatformServices/*=wlb
/PMC_Help/*=wlb
/polestar/*=wlb
/PolestarAppActions/*=wlb
/polestar_help/*=wlb
/polestar_tutorial/*=wlb
/STS/*=wlb
/VoyagerClient/*=wlb
/webservice/*=wlb
/Xcelsius/*=wlb

 

Step 2: Setup the virtual directory in IIS: The installer also defines the ISAPI redirector as a virtual directory in IIS as shown below. Check that execute permissions for this virtual directory is set to “Scripts and Executables”.

image

You also have to define the web service extension if using IIS. Right click on “Web Service Extensions” and define a new Web Service Extension called “Jakarta mod_jk” and required file as isapi_redirect.dll which can be found in the bin folder of Jakarta ISAPI redirector.

image

Now restart IIS using IISRESET.exe on the command line.

Installing and Configuring the Jakarta Connector on Tomcat

Now that you have the IIS ISAPI filter installed and configured on the IIS side, you have to configure Tomcat to accept connections from IIS. To do this, we will configure Tomcat’s AJP13 listener.

  1. On the Tomcat system (INSTALLDIR\Tomcat55) find the server.xml located in Tomcat’s \conf directory.
  2. Edit the server.xml. Search for the port=”8009” and uncomment and change the connector entry to look as follows

    <Connector enableLookups="false" port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false"/>

Save and restart Tomcat. If you do a netstat-an command on the command line you should see the tomcat connector listening on port 8009.

image

You can now test the connector by navigating to one of the tomcat samples such as the infoview URL on the webserver. For example: /InfoViewApp/">http://<iiswebserver>/InfoViewApp/.

Advertisements

Posted in Administration, IIS, ISAPI | Tagged: , , , , , , | 2 Comments »

How to deploy BusinessObjects in a distributed environment (BOE Federation)

Posted by Hemanta Banerjee on October 21, 2010


Yesterday while talking to one of my shipping customers I realized that a traditional centralized BOE deployment would not work for them. They have multiple offices (Belgium, Luxemburg, Shanghai, Singapore). While the offices are all connected the bandwidth is an issue for them and they would like their users to use the WAN as little as possible.

While having separate deployments for each office is always an option, it also means that each BOE server would need to be managed separately – update reports in 4 places, manage security in 4 places etc.. you get the picture.

This is where Federation comes in. It is a great feature of BOE that allows BI administrators to create a process for copying BI content from one system to another while keeping the systems synchronized. The objectives of Federation are to:

  • Simplify the administration of multiple deployments.
  • Enable the distribution of content and/or security principals across geographically separated repositories
  • Avoid heavy use of Wide Area Network (WAN).

Essentially it is a great way to still manage the deployment in 1 place and replicate the content so that it can be accessed locally by the users. Federation enables administrators to distribute content and implement a consistent rights policy across this organization.One origin site can replicate an object to multiple destinations through multiple jobs. The only restriction is that you cannot replicate replicated content.

image

There are 2 main design patterns that can be used for such a deployment

(1) Centralized Design, distributed usage – In this business scenario, report creators and designers create reports, universes at the Origin Site. The Destination Sites then pull the content from the Origin Site and then reports are run at Destination Sites. Scheduling is performed at remote sites, instances stay at remote sites where the local databases reside. Localized instances can also be sent back to the Origin Site.

(2) Central Schedule, Distributed Access – In this case, all BI content is managed from a single origin site. This is where the data is and where the scheduling occurs. All pending job are sent to the origin site to run. The instances from the completed jobs are then sent back to the branch sites to be viewed.

Steps to create replication jobs.

Step 1: Create a Replication List on the Origin Site – A replication list is a list of objects to be replicated by a replication job. It only has pointers to the objects (reports, users, and universes) that have been selected for replication.

image image

 

Select the objects to be replicated. If you want to replicate the entire repository then just select “Replicate All repository objects” and click save.

Step 2: Create a Remote Connection on the destination site – Remote Connection objects contain the necessary information to connect to the remote BOE Server. this is The remote connection is create in the destination site. The remote BOE deployment is always considered the origin site and the BOE deployment where you create the remote connection object is always considered the destination site.

image

Step 3: Create a replication job on the destination site – A replication job is used to replicate content between two BOE Servers. A replication job must have the associated remote connection, the replication list.

image

Step 4: Schedule the Replication Job to run on the destination site

Couple of points to note:

1. Local data source connections have to be defined on the remote site. If the BOE server cannot find the definition of the local connections it will try to run the report against the origin site.

2. Do not try to use this for moving reports from developments to production. There is a separate LCM utility to do that. Details on that will come in a separate post.

3. Make sure that proper conflict resolution is set up to handle scenarios where reports can be modified both on the origin and destination site. Ideally the origin server should take precedence and will overwrite the changes at the destination.

More details on this can be found on the SDN website http://wiki.sdn.sap.com/wiki/display/BOBJ/Federation+in+BOE+XI+3.1

 

Posted in Administration, BusinessObjects, Federation | Tagged: , , | 1 Comment »

 
%d bloggers like this: