Skip to Content
Author's profile photo Shankar Narayanan SGS

6 Signs that your SAP BusinessObjects is not sized and what you should be doing about it

Every BOBJ Server is not the same and there is not one universal recipe when it comes to sizing it. As unique as each deployment is, the Sizing should also be done specifically for the usage of it. But the signs/indicators are same for all the deployments which help in identifying if your BOBJ is sized and utilized like how it is supposed to be.

Based on my experience consulting with numerous clients, I have put together some of the common signs/indicators and the components affecting it. We will also look at the reason behind the same.

1. Login time

Does your BOBJ server take users a very long time to log in to the launchpad? The possible reason for this is the Tomcat Server and the Application Database for the CMS. Sizing the Tomcat server is an important process which makes sure that the BOBJ Web applications run smoothly. The Database should have adequate memory and should be sized according to the vendor recommendation.

2. Nonresponsive Launchpad

Launchpad might go unresponsive or throw an error when more numbers of users access it when the BO system does not have memory to serve the request. The CMS and the applications should be capacity planned, based on the number of active and concurrent users. The resources of the system should be constantly monitored so that there is no over-utilization.

3. Slower Search

Does it take a very long time for the search results to appear? Are your users getting blank results when searching for the report? The possible reason might be that the Adaptive Processing server for the Search is not split and sized. This APS runs as a process and is responsible for Search within the BO Server. The Input and Output File repository should also be on a storage which has very low latency and high throughput.

4. Application response time

The application response time is one of the major indicators that the system is not sized. The application can respond slow when the necessary processing servers are not sized and split. The connection servers should also have enough memory to bring in the Dataset for the report. The Data source system can also slow down the time the reports get the data. Developer tools and tracing are good options for finding out the issue.

5. Scheduled Reports takes long to complete

If the reports that are scheduled take very long time to complete, then the Adaptive Job Server is not properly sized. The Job Server must be split and grouped for the schedule to run based on the load. The resources should also be monitored during the schedule run to make sure that the system is utilized properly.

6. Promotion of reports takes longer time

If the promotion of reports between systems takes a long time or fails unresponsive, then it is a clear indicator that the Promotion management Services are not sized. The issue could be at either of the systems involved in the promotion.

Sizing of SAP Business Objects is an important part of configuring the system and should be monitored and repeated at regular intervals depending on the usage to get maximum utilization of the system.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Venkateswara Y Guptha
      Venkateswara Y Guptha

      Simple yet informative, useful information.

      Author's profile photo Moritz Hoedel
      Moritz Hoedel

      Regarding 5.:
      It's not recommended to split the AJS.

      See for details:
      1950573 - Is it Necessary to Split the Adaptive Job Server in BI4.x ?
      1868751 - Sporadic and Random scheduling failures

      Best Regards


      Author's profile photo Shankar Narayanan SGS
      Shankar Narayanan SGS
      Blog Post Author

      Hi Moritz

      You may not need to Split the AJS, but it is necessary to Stop the unused Services and group the scheduling based on Node if you have more than one nodes dedicated for large processing of different BI Applications.

      The operation collectively does what Splitting does but in a different way for AJS. So in general terms it is similar to AJS Splitting.