SAP BusinessObjects Enterprise XI3 Deployment Patterns

When deploying an SAP BusinessObjects Enterprise system there are a lot of choices for where you can deploy all the services that make up the system. It is then necessary to make sure that you choose the right deployment in order to meet your requirements, for example, is it easily maintained, is it resilient, is it secure, will it support my user base and can it be easily expanded to accomodate additional users.

This article looks at different deployment patterns for an SAP BusinessObjects Enterprise XI3 system and reviews their advantages and limitations of each. It is the intention then that this can help you make an informed decision about the deployment configuration of your system.

The article focuses on the core SAP BusinessObjects Enterprise servers and does not include Data Services or Performance Management.

Overview of Patterns

The patterns below describe four different deployment configurations where the technologies involved in an SAP BusinessObjects Enterprise (BOE) system are deployment across different numbers of physical servers.

Our scenario is a deployment where the users are accessing the system and using InfoView to work with either Crystal Reports, Web Intelligence documents or Voyager applications. The source data for these reporting and analysis tools is held in either a data warehouse or in SAP BW or in some other database or OLAP system. The patterns below include a data warehouse server and an SAP BW server however it is not the intention of the pattern to suggest that both of these are mandatory but it is expected that one or other would be deployed.

Pattern I – Basic SAP BusinessObjects Enterprise Deployment

Pattern Overview

This is the most basic deployment where essentially we have all the required server components for a BOE installation on one physical server. These components are,

• all BOE server components: CMS, WebI Report Server, Crystal Report Server etc
• a Web Application Server (IIS, Tomcat etc) that hosts the user and admin web applications
• A file system to host the BOE repository where documents are held
• A database server (SQL Server, Oracle, MySql etc) that hosts the CMS Repository, Audit database and LifeCycle Manager database

This server can be running any of the supported operating systems – Windows, Unix or Linux. The following diagram is of a basic BOE deployment.

Desktop client applications, e.g. universe designer, Web Intelligence full client and administration applications such as the Import Wizard will require communication with this server. The ports that BOE uses for communication will need be open on this network. Web based applications will also access the web application server installed on this server and similarly the HTTP port will also need to be opened on this network.

Both the database server that BOE is reporting against and the SAP BW server are hosted on a separate physical servers.

In the above diagram we are displaying two network branches (thick blue lines) however this is just to highlight the communication between the different components and a typical installation would normally be on a single LAN. To keep the diagram simple we are displaying all the BOE services as a single component rather than displaying them all individually.

Note, some desktop applications, for example universe designer, will require direct access to the data warehouse and SAP BW servers.

Sizing

Many factors influence the required sizing for a BOE system and primarily these are the number of users, how the system is being used (accessing Web Intelligence documents, Crystal Reports or Voyager applications) and how often they access the system. However we can consider a minimum size for this deployment pattern.

We can assume that both the web application server and repository database server are in constant use so we should then dedicate a single CPU to each of those. For BOE it is a bit more difficult but 2 CPUs should handle a small deployment. So our physical server should be as a minumum a 4 CPU server.

On a 32bit server it is recommended to allocate 2GB per CPU. The rule of thumb here is that a 32bit process can only access a maximum 2GB or RAM. Obviously a single CPU can execute more than one process and so this isn’t an absolute calculation.  For 64bit server we don’t have this 2GB limit per process so you can install more RAM if required.

Advantages

The obvious advantage is that this deployment is the easiest to install and configure. In addition it is also straightforward to maintain and to backup. Performance is good as we do not have any network latency between the main server components as they are all on the same physical server.

Limitations

One disadvantage is that there is no resilience in the system. If one of the components fails or indeed the whole server then there is no backup server to take over. Automatic failover is not always mandatory in a system as it is not always necessary to have the system available 24 hours a day, 7 days a week. An  alternative is to have a well defined disaster recovery strategy.

Another limitation is that although perfromance isn’t affected by network latency performance still isn’t optimised. We have a single physical server managing several different services – the web application server, BOE services, a database service – and the OS will spread the load across the available CPUs however it will do this fairly arbitrary and you may find that some key processes will get queued while waiting on another less important process to complete. Here you can then have contention between say the web server, database server and all the BOE services you have running.

A further disadvantage is with licensing. There are several different licensing options available from SAP BusinessObjects one of which is CPU license where you license the software by the number of CPUs on the server that BOE is installed on. For example if you have a 4 CPU server then you pay 4 times a single CPU license.

In the basic pattern we’ve described here some of the CPU resource on the server will be utilised by the web application server and database server and so the BOE services won’t be able to maximise all available CPUs. However the licensing requires that we pay for all CPUs even though we know that the BOE services won’t be able to utilise all available CPUs.

Note, SAP frequently update and modify their licensing so please check with them for latest licensing information.

Pattern II – A Distributed SAP BusinessObjects Enterprise Deployment

Pattern Overview

Here we start to distribute the components to separate servers in order to improve performance and optimise licensing. This pattern is sometimes described as a 3 tier deployment where we have the components deployed as follows.

First Tier – Web Application Server. A Web Application Server that hosts the InfoView and the CMC web applications or a custom web application.

Second Tier – BOE Application server. BOE services are deployed onto a separate physical server and this server will also hosts the file system that for the BOE file repository – essentially where all the Web Intelligence documents, Crystal Reports, universes and any other file based objects are held.

BOE Repository Database server. Here we have moved the BOE repository and audit databases onto thier own dedicated server. It is not recommended to have the BOE repository database on the same server as the data warehouse or the database system that you are reporting against. The reason for this is that you can bring down the BOE repository database for some mainentance task such as backup or upgrading without having to bring down the data warehouse.

Third Tier – Database Tier. This tier comprises of the physical servers that host the SAP BW or data warehouse systems.

Sizing

We follow the same logic as with the basic deployment pattern above however since we have a distributed system we now have the following minimum CPU requirements for each of the servers:

• Web Server: 1 CPU,
• BOE Server: 2 CPUs and
• BOE Database Server: 1 CPU.

Advantages

Here we have more efficient use of processing with servers dedicated to particular purposes. This allows for the network security to be more tightly controlled e.g. the web server only needs to open ports used by the web application server. Backup and maintenance can also be optimised per server. And finally we are also optimising our licensing as we only need to buy licenses for the BOE Server.

Limitations

Obviously it is a more complicated installation and we need to spend more time with installing and configuring the system.  We now also have network latency between the physical servers however this should be minimised by installing the physicall servers on the same LAN. And as with pattern I we still don’t have any failover.

Pattern III – Optimised SAP BusinessObjects Enterprise Deployment

Pattern Overview

In this deployment we split out the BOE processes onto separate servers to optimise processing for a given deployment. We have the web application server and BOE repository database server deployed onto seperate servers as before in pattern II. The group of servers on which we have installed the BOE server processes is known as the cluster. The following are details of the BOE cluster

BOE CMS Server.  Hosts the core BOE services which are the Central Management Server (CMS), input and output File Repository Server (FRS), Event Server, Publishing server, Program Scheduling Server, Replication server, Search server and the Web Services server. The repository file system is also held on this server.

Web Intelligence Server. Hosts the Web Intelligence Processing server and Web Intelligence Scheduling and Publishing (job) server.

Crystal Reports Server. Hosts the Crystal Reports services: Crystal Reports Cache Service, Crystal Reports Processing Service, Crystal Reports Scheduling Service, Crystal Reports Viewing and Modification Services and the List of Values Scheduling service.

Voyager Server. Hosts the Voyager server processes the multi-dimensional analysis server.

Refer to the “Architecture” section of the SAP BOE Administration Guide.

Note, if your deployment does not need one of data processing servers (Web Intelligence server, Crystal Reports server or Voyager server) then these can be omitted.

Sizing

Sizing is as before for web server and CMS database server but for each BOE server we have,

• BOE CMS Server: 1 CPU
• Web Intelligence Server: 1 CPU
• Crystal Reports Server: 1 CPU
• Voyage Server: 1 CPU

To increase capacity you can add more CPU and RAM to the individual servers. For example if you have a large number of users accessing Crystal Reports and not so many access Web Intelligence then you can scale up the Crystal Reports server.

Advantages

This pattern has the same advantages as pattern II but we now can optimise processing based how BOE is being used. If there is a requirement for more Crystal Report processing than Web Intelligence we can add more CPU to the Crystal Report Server. This allows the more flexibility if the system is required to be scaled up as more BI applications are added to the deployment.

A second advantage is in resilience, for example, if a we have a runaway Web Intelligence process that is utilising 100% CPU then this failure is not going to impact on the CMS or Crystal Reports server and those users will not be impacted. In addition we can then restart the failed server without having to restart the whole system.

Limitations

Again this pattern is obviously more complex to install and configure than patterns I and II. We also have network latency between servers but again we minimise this by installing on same LAN.  We are deploying across more servers and so it will be more expensive for CPU licensing however we aren’t over spending as we are with pattern I.

Typically when purchasing a server today it will come with a minimum of a dual core if not a quad core CPU. If your sizing exercises determines that the Web Intelligence server only needs 1 CPU you still need to pay for a quad core CPU license as this is what is on the server. Obviously this is not ideal but you can use virtualisation technology to optimise the available CPUs across different virutal servers.

As with the previous patterns we still don’t have any failover, this is addressed in the final pattern described below.

Licensing

A CPU license is required for any server that a BOE service is installed on (refer to SAP BusinessObjects for latest information). Here we need to a CPU license for each of the CMS, WebI, Crystal Reports and Voyager servers.

Pattern IV – Load Balanced / Failover SAP BusinessObjects Enterprise Server Deployment

Deployment Overview

For a load balanced failover deployment we duplicate servers so that in the event of one failing the duplicate server is there to take the load. It is also termed load balanced as the load from the users is spread across the available servers. However the primary focus of this pattern is failover. This deployment pattern is typically used for high availability, mission critical systems.

In the diagram below we have two ‘stacks’ where each stack comprises of all the servers required for a deployment: web application server and BOE services. The diagram illustrates that the BOE repository and File repository is shared between the two stacks however it is also possible to have these components duplicated for failover. This will depend on the type of database management system being used and also what technology is available for maintaining a synchronised file system.

Another benefit of this architecture is that you can perform maintenance tasks on one side of the stack while leaving the other still operational.

Web Server

In front of the web server is a load balancer which distributes requests between the two web application servers, if one server fails then all requests are sent solely to the other still operational server.

An alternative to using a load balancer is to use clustering of the web applications. Not all web application servers can be clustered and not all clustered web application servers are suported by BOE. See latest doc for more info.

BOE Servers

We duplicate the servers across the two stacks. It is important to ensure that the size of one stack is large enough to accomodate a ful load. For example if your sizing exercise determines that you need a 2 CPU Web Intelligence server then you have a 2 CPU server in each stack rather than having a single CPU Web Intelligence server in each stack.

The BOE Repository database can be a single database management system but for a high availability system it will also be held on a failover database system. Consult the documentation for your RDBMS system for further information on building a failover system.

We are also requird to share location of the BOE File Repository between the two stacks as opposed to utilising the file system on one of the CMS servers as we had in pattern III. Here we use a networked file system such as a NFS or a SAN system and again there are technologies available to provide failover to these systems. This will obviously depend on the operating system being used on the servers.

Sizing

The important aspect to sizing here is that one stack is required to accommodate the full load. This is so that when on stack fails or is brough down the system will not suffer from a dorp in performance when the remaining stack is taking the full load.

Advantages

The advantage on this deployment is for failover and as such it is only usually deployed on mission critical systems. A second advantage is that you can perform maintenance tasks on the system without requiring to take the full system off line.

Limitations

The primary limitation on this system is that it is the most expensive pattern to deploy. In effect we are doubling the required number of servers which in turn requires double the number of CPU licenses. In addition it is also the most complex to deploy and configure.

Summary

Above we looked at four different deployment patterns for an SAP BusinessObjects Enterprise system. We are by no means limited to only being able to deploy one of these  four and we create a deployment architecture that borrows features from both.

For example if we have a small user base but the system is required to have high availability then we could start with deployment pattern II and then use the high availability architecture from pattern IV by duplicating the BOE server.

The table below summarises the patterns, listing their advantages and limitations and the final column suggests some typical scenarios in which you would use the pattern.

Pattern	Advantages	Limitations	Deployment Scenario
Pattern I	Easy Install Maintenance No Network Latency	No resilience or failover Performance not optimised – CPUs shared over different processes Licensing not optimised Limited scalability	Small deployments, users base less than 100 Development or Testing environments Demonstration systems
Pattern II	Optimise Licensing Servers dedicated to tier Network can be secured through use of firewalls between servers Backup/restore optimised per server	More complex than pattern I Network latency between servers No resilience / failover Limited scaling options	Small to medium size deployments (100-500 users) Secure deployments that require firewalls Development / test environment for large  teams (20+ developers)
Pattern III	Scalable to accomodate more users BOE processes optimised over servers Network security Resilience where if a BOE server fails rest of system is unaffected	Again more complex No failover Network latency	Medium to large deployments (500+ users) High demand Scalable system
Pattern IV	Resilience / failover Scalable Network can be secured BOE servers are optimised	Complex Expensive Network latency	Enterprise deployments (1000+ users)