SAP has streamlined the BusinessObjects software footprint by reducing the number of servers and increasing what each server can do in the form of services. The Adaptive Processing Server is a perfect example of this approach. It contains many services, ranging from Web Intelligence charting, to publishing, promotion management, and monitoring. The Adaptive Processing Server could do so much, in fact, that it had to be split into multiple servers that specialized in like sets of services. Early installations of SAP BusinessObjects BI 4.0 that did not take this into account failed. In its BusinessObjects BI 4.1 release, SAP included a wizard that performed this split for you based on the size of the final installation.

The Adaptive Job Server has been streamlined just as the Adaptive Processing Server has, with each job server managing the scheduling duties for Web Intelligence (also known as WEBI or WebI) and Crystal Reports as well as destination and replication processing. This totals more than 16 possible services managed by one job server. Each server spawns multiple child processes, each of which is capable of handling one type of service. One job server is capable of managing five of those child processes by default. That number can be increased as needed.

That’s where the similarities end, however. SAP has not recommended splitting the job server in practice, although why this is the case has not been publicly disclosed. There have been a few SAP Notes on the subject (SAP KB 1868751 – Sporadic and Random Scheduling Failures and SAP KB 1950573 – Is it Necessary to Split the Adaptive Job Server in BI 4.x? [log-on required]) and even a mention in the SAP BusinessObjects BI Sizing Guide that recommends keeping the job server together except under special circumstances. What is not discussed is what companies give up by not doing so. This article should help fill in these gaps.

Understanding the Job Server – A Short History

It might help to review what has been asked of this server historically to better understand the need to re-examine the do-not-split stance. Earlier versions of BusinessObjects (XIR2 and prior) came with many different job servers—one each for Desktop Intelligence (also known as DeskI), Web Intelligence, and Crystal Reports, as well as a list of values and destination processing.

Each job server was invoked directly by the Central Management Server (CMS) based on the task at hand. For example, the CMS would select an available Crystal Reports job server to process a scheduled Crystal Report. Each job server would start child processes to handle the real processing. The only exception was made for Web Intelligence scheduled processing, where the child process delegated the processing of that particular document to an available Web Intelligence processing server. Regardless of the type of document processed, the parent job server would send the status back to the CMS as the schedule was processed, including final success or failure.

As BusinessObjects evolved to the next version, v3.1, several services that focused on replication and Web Intelligence scheduling were melded as one server—the Adaptive Job Server. At that point, Desktop Intelligence and Crystal Reports schedule processing were still handled by their own servers.

Note that no matter which version of BusinessObjects is being discussed (XIR2 through 4.1) the basic role of the job server has remained the same:

• It waits to be contacted by the CMS to process a scheduled request.
• It spawns a child process that handles the processing of that request (except Web Intelligence).
• In the case of Web Intelligence schedules, the job server spawns a child that invokes the Web Intelligence processing server to refresh the report and create the scheduled instance.
  • It monitors each child and reports back the status of all schedules being processed to the CMS.

The Pros and Cons of Splitting

The evolution of the job server has resulted in fewer servers performing more functions through the use of services. This would appear to simplify the process from an administrator’s perspective (fewer servers) and to be less prone to error from SAP’s perspective (one server to perform all actions rather than disparate servers for each type of processing). Since these both seem like positive outcomes, one has to wonder what the negatives might be.

The answer to that question is clear when considering the Adaptive Processing Server. That server is capable of processing many types of actions through its use of services. Depending on the BusinessObjects environment being configured, though, related sets of services should be isolated and given their own servers. The cost of doing so is resource-related: More servers require more memory and CPU on their respective machines.

Splitting Pros

The same arguments could be made for splitting the Adaptive Job Server. The advantages for splitting this server include control, separation, recovery, and redundancy. Each of these points is important enough to consider on its own merits.

Control

With one overall Adaptive Job Server, a BI administrator can no longer control processing that was easy to do in the past. For example, controlling publication processing in previous versions was simple—simply pause or stop the Publication Job Server. If you try and do the same step in BusinessObjects 4.1—attempting to stop one job server for publications—it stops all processing, not just the one job. This includes any ad-hoc schedules not related to publications. The situation gets worse when one realizes that control over schedules by content type is also gone. With one Adaptive Processing Server, defined control over just Web Intelligence schedules evaporates.

Separation

Splitting the Adaptive Processing Server gives administrators the chance to move wildly different forms of processing to their own servers. Certain activities are more stable than others—one has to look no further than promotion management to understand the benefits. Promotion management has been historically challenged from the outset, requiring more resources in terms of memory and CPU to perform its activities. Isolating these services to their own server allows the allocation of memory based on the type of activity being performed.

The Adaptive Job Server should be treated no differently. It is a Java-based process just like the Adaptive Processing Server, and as such, can be allocated more memory based on the type of processing being performed. Job server-related tasks are handled by children where each child gets its own memory allocated. Usually this is enough for most tasks, but not all. Consider replication, where content from one environment is synchronized to a second BI environment via scheduling. If many objects are replicated in the first pass, this requires more memory. This memory can be better allocated if there was a job server dedicated to replication.

Recovery

In theory, one server processing more documents and types of requests should be superior to many servers that process smaller numbers. In reality, though, an administrator must consider the real-world impact of crashing solitary servers. Even today, one report can crash a Web Intelligence processing server. If that server is set up to handle 100 requests, guess what happens to the other 99? When a single server crashes, all related processes (whether thread or process-based) die with it. It’s hard enough to control this situation when considering one type of processing such as Web Intelligence scheduling. Just try and imagine what would happen if all other scheduled tasks are dependent on the same server for survival.

Redundancy

Offering more than one server of the same type reduces the number of catastrophic moments. An argument could be made for allowing one Adaptive Job Server per machine as a way of offering redundancy. Though that may technically meet the requirement for more job services, it is often not enough. Redundancy should be influenced by the type of activity performed. A company whose content base is mostly Web Intelligence should allow more Web Intelligence-based job servers. Those job servers should be sized such that any one single server crash does not cause a massive schedule failure. This is usually done by limiting the number of reports that can be processed at any one time.

Splitting Cons

Arguments against splitting the Adaptive Job Server include increased inter-server communication, decreased stability, and higher resource requirements. As with the advantages that splitting offers, let’s give the possible downsides equal time.

Increased Communication

With more servers comes the need to communicate even more. Earlier versions of BusinessObjects faced this dilemma as a set of Central Management Servers coordinated the activities of all servers that were part of the environment. A Desk Intelligence job server would never be called upon, though, when processing a Crystal Reports document. In the same way, a BusinessObjects 4.1 Central Management Server would not communicate with a job server whose services it did not need at that time. Each Central Management Server is able to contact the correct set of servers based on services that are available via each server. The amount of communication is still higher than one job server, but no more so than with the last BusinessObjects version (v3.1).

Decreased Stability

This particular point was made early on by SAP Notes such as the ones previously discussed. In those articles, the increase in the number of split-job servers was blamed for the growing number of report crashes and an increase in the general instability of the BusinessObjects BI 4.x environments. Early adopters of BusinessObjects BI 4.0 technology can attest to the fact that system crashes were caused by many other factors, job server splitting being the least of these. From personal experience with large BusinessObjects BI 4.1 environments, splitting job servers has not resulted in system instability or system crashes that were referenced in SAP KB 1868751 and 1868753.

Higher Resource Requirements

This point is absolutely true. More servers require more memory and more CPU to process their requests. The increase is due more to the number of parent processes vs. children, since the same number of children will be required to process each individual request.

Making the Split

Based on these pros and cons, it’s only natural that most companies would want to at least test to see if there are any benefits of a split Adaptive Job Server environment for them. The following instructions show how to split the default BusinessObjects BI 4.1 job server. Perform the following steps during a scheduled downtime for your environment to avoid schedule failures that depend on the original configuration.

1. Open the Central Management Console.
2. Navigate to Home > Servers.
3. Find the original Adaptive Job Server. Stop and disable it.
4. Add a new server by selecting Manage > New > New Server from the menu.
5. Choose the correct service category based on the type of job server desired. For example, select Web Intelligence Services to create a Web Intelligence job server
6. Select the scheduling service based on that category. Following the same example as in step 6, choose Web Intelligence Scheduling Service.
7. Give the job server a name (for example, WebiJobSever1).
8. Select the Create button to create the new server. Note that the final server automatically uses the Destination Configuration Service and Tracelog Service without selecting them using the previous steps.

Walking Through a Split Server Example

What follows are suggestions for splitting the job server by type of activity. Arguments can be made for other combinations, though the reader should realize the disadvantages of grouping too many tasks together as previously discussed. This example is from an actual customer who has used this technique successfully. It represents one possible scenario and should not be taken as the only splitting method.

Keep the original Adaptive Job Server but stop and disable it for safekeeping. Use the CoreJobServer to host all other services that weren’t specifically split out. Other job servers like Crystal and Web Intelligence could be duplicated based on the number of overall documents processed to increase bandwidth. Alternatively, the maximum number of documents processed for each server could be increased.

The following is a list of typical job servers that can be created, and their associated services. They are to be used as examples of what can be created using the instructions above. Each is focused on a particular task (for example, the job server WebiJobServer is for handling Web Intelligence schedules). These are representative and not meant as an all-inclusive list of possible job servers that can be created.

PromotionJobServer

• Destination Configuration Service
• Promotion Management Scheduling Service
• Tracelog Service

CrystalReportJobServer

• Crystal Reports 2013 Scheduling Service
• Crystal Reports Scheduling Service
• Destination Configuration Service
• Tracelog Service

PublicationJobServer

• Publication Scheduling Service
• Destination Configuration Service
• Tracelog Service

WebiJobServer

• Web Intelligence Scheduling Service
• Destination Configuration Service
• Tracelog Service

CoreJobServer

• Authentication Update Scheduling Service
• Destination Delivery Scheduling Service
• Platform Search Scheduling Service
• Probe Scheduling Service
• Program Scheduling Service
• Replication Service
• Security Query Scheduling Service
• Users and Groups Scheduling Service
• Visual Difference Scheduling Service
• Destination Configuration Service
• Tracelog Service

In this article, my goal is to present missing information about a subject that was sorely lacking. As each BusinessObjects server evolves, it is only natural that they will be required to do more. Streamlining the architecture to fewer servers, though, does not mean that every company should deploy the software based on generic defaults. This was an early problem with BusinessObjects BI 4.0 and the Adaptive Processing Server—one that was rectified in a later version of the product. The same argument was made for the Adaptive Job Server, hopefully with the same effect.

Alan Mayer

Alan Mayer is president at Solid Ground Technologies, Inc. He has built customer-focused, BusinessObjects-based solutions for the last 20 years. His original company, Integra Solutions, was one of the first BusinessObjects partners that joined the program in 1995. His company provided the first authorized set of training manuals that were later purchased by the software vendor for nationwide distribution. Solutions from his firm have been adopted by a wide variety of industries, from healthcare to banking, manufacturing, and retail.

You may contact the author at alan.mayer@solidgrounded.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.