Chapter 25 BusinessObjects Enterprise Architecture

In this chapter

Introduction 596

BusinessObjects Enterprise Architecture Overview 596

The Client Tier 597

The Application Tier 599

The Server Tier: Introduction to the BusinessObjects Enterprise Framework 600

The Server Tier: Overview of the BusinessObjects Enterprise Services 603

The Data Tier 623

The BusinessObjects Enterprise Architecture in Action 625

Taking Advantage of the BusinessObjects Enterprise Distributed Architecture 629

Extending BusinessObjects Enterprise 631

Introduction

This chapter introduces the BusinessObjects Enterprise Framework and the components that make up its architecture. It describes how each of the services or daemons that are part of the BusinessObjects Enterprise Framework operate and what role they have in an information infrastructure. The chapter also discusses the benefits of having a distributed architecture: vertical scalability, horizontal scalability, innate load balancing, failover, high availability, and tune-ability—the capability to tailor the system to a particular environment and type of load.

This chapter uses a progressive approach: considering the highest level first, and then approaching each part of that whole in more detail.

BusinessObjects Enterprise Architecture Overview

At the highest level, BusinessObjects Enterprise has four main tiers: the client tier, application tier, BusinessObjects Enterprise Server tier, and database tier (see Figure 25.1):

Figure 25.1 The client, application, server, and data tiers compose an enterprise business intelligence infrastructure.

• The client tier consists of Web-based and installed applications. You can alternatively categorize these applications into end-user applications such as the Web-based InfoView, which enables end users to access data, management applications such as the Web-based Central Management Console, and content creation applications such as Crystal Reports or OLAP Intelligence. In the majority of cases, the client tier for a BusinessObjects Enterprise user is a Web browser.
• The application tier consists of application processing—typically on an application server, using the BusinessObjects Enterprise Software Development Kit (BOE SDK). The BOE SDK provides a programmatic interface to the BusinessObjects Enterprise server tier. These server-based programs are processed on an application server, such as BEA WebLogic, IBM’s WebSphere, a Servlet container like Apache Tomcat or Microsoft .Net server. This application tier could provide an application centered on BusinessObjects Enterprise functionality, like InfoView, or an application that uses BusinessObjects Enterprise functionality as part of a greater application (for example, an online banking application that provides full-service banking for customers, and provides detailed statements via BusinessObjects Enterprise).
• The server tier consists of services (in Windows) or daemons (in Unix) registered with the BusinessObjects Enterprise Framework. (They are generically referred to as either services or daemons as these terms are interchangeable.) Although this chapter uses the term “service” or “daemon” for technical accuracy, you might see references to these services as “servers” as well, for instance the Central Management Server. The server tier is usually subdivided into the intelligence and processing tiers.
• The data tier is comprised of two parts. First is all data sources from which an organization can pull data. This data can be in a database, an application, a programmatic data source, XML, a Web service, or a variety of other sources. The second part is that which is offered as part of the BusinessObjects Enterprise solution, specifically, Meta Data services via Business Views and Universes and data connectivity via ODBC and native drivers.

With a high-level understanding of the role of the client, application, server, and database tiers, you now consider each one in depth.

The Client Tier

The client tier is the “face” that you associate with BusinessObjects Enterprise. A particular end user might think of the ePortfolio application page that shows up in her Web browser as BusinessObjects Enterprise. However, BusinessObjects Enterprise has many faces, each distinct and useful. By adopting a flexible approach toward potential client applications, BusinessObjects Enterprise offers a system architect diverse means of sharing information with diverse audiences: an executive receives a text message on his cellular phone with the latest profitability statistics; a shipping clerk receives an order on the workgroup printer; a supplier company receives an XML file with detailed order specifications. These are but a few faces of BusinessObjects Enterprise.

To begin categorizing the client tier, define three groups of audiences that will use client applications: the end user, content creator, and administrator. Although these groups are not mutually exclusive (a particular person can have all three roles), this distinction helps to explore important dimensions of each.

End-User Clients

The most common end-user client for BusinessObjects Enterprise is a Web browser. Many of the client applications that are included with BusinessObjects Enterprise, such as InfoView, use a Web browser as their client. Additionally, most custom application development targets the Web browser.

With the proliferation, adoption, and maturation of the Internet as a communications medium, additional client tools offer diverse venues for end-user experiences. Internet-connected phones and mobile devices already grace the belts and briefcases of the more tech-savvy.

With each client targeted for an end-user community, specific considerations take the fore. For instance, most Internet-connected phones have small screens—they can only display a few lines of text at a time. Because BusinessObjects Enterprise is so widely experienced within the Web browser, several browser-related considerations merit your attention. Web browsers such as Internet Explorer and Netscape or Mozilla are page-oriented: They display one page at a time. Users expect these pages quickly and become frustrated at what they consider long waiting times for pages to display. The benchmark hovers at between 5 to 10 seconds for the patience of a typical Web user.

The Web experience also is by and large a simple one. You see a blue-underlined word, and know that you can click on it to go somewhere. Originally, Web browsers were simple text display programs. The capability of today’s browsers to render complex graphics and reflect exact positioning represents a tremendous maturation of the technology, but you must remember that a Web browser was not initially designed for this, and even today limitations, most notably around printing, reflect these origins. For content such as Crystal Reports, where pixel-level formatting is vital, and for content such as OLAP Intelligence reports, where interactivity is vital, BusinessObjects Enterprise provides special facility for overcoming the limitations of the Web browser.

The BusinessObjects Enterprise report viewers were presented in Chapters 23, “Introduction to BusinessObjects Enterprise,” and 24, “Using InfoView.” For each type of object managed in BusinessObjects Enterprise, there are specific viewers made available. These viewers appear in the browser and include buttons for exporting, printing, navigating, searching, and so on. These viewers provide pixel-level positioning, tremendous interactivity, and graphical capability. Crystal Enterprise 9 implemented a new viewing architecture which has been expanded on over the subsequent two releases. The viewer object in the SDK renders reports and provides a simple interface for the Web developer to embed a Crystal Report or OLAP Intelligence document. The developer sets the properties of the viewer to determine the capabilities an end user has. For instance, the report export capability might be inappropriate for a certain end-user population, and so can be turned off by setting the HasExportButton property to 0.

The Web browser receives only DHTML and images, with the exception of the optional print control. Should a user choose to print a report, either an ActiveX print control or an Adobe Acrobat file is used to print while maintaining pixel-level formatting and fidelity.

In earlier versions of BusinessObjects Enterprise, reports were rendered via a URL request to the viewrpt.cwr page, which was processed by the Web Component Service provided by BusinessObjects Enterprise. The new control enables a developer to embed a viewer control wherever they want in a Web page, to be platform independent, and to fully secure and control the report viewing experience.

BusinessObjects Enterprise supports the following browsers:

• IE 6
• Netscape 6.2
• Netscape 7.0
• Safari 1.2 on OSx (not including Japanese)

Content Creation Applications

Applications, such as Crystal Reports or OLAP Intelligence, install on the report developer’s machine and create and publish content to the BusinessObjects Enterprise Framework. These were introduced and covered extensively in Parts I through IV.

Administrative Client Applications

Applications such as the Central Management Console (CMC) allow administrative users to manage the BusinessObjects Enterprise system. Administrators might also use the Central Configuration Manager (CCM) for server-level management. The CMC is a Web-based application, but the CCM is an installed application. Coverage of these administration tools is provided in Chapter 27, “Administering and Configuring BusinessObjects Enterprise.”

The Application Tier

Various applications dynamically create end-user pages, most typically in HTML. These applications are processed on an application server. In the past few years, the Enterprise application server market has consolidated dramatically, with two main camps now extant: the Microsoft .Net technologies and the Java technologies.

BusinessObjects Enterprise provides a Software Development Kit in three formats for each of the three most popular development environments: COM, Java, and .Net. These allow an organization maximum flexibility in integrating BusinessObjects Enterprise into its applications.

The COM SDK includes a set of COM objects that interact with BusinessObjects Enterprise via the BusinessObjects Enterprise Framework.

In prior versions of the product, the typical use and installation used the COM SDK as the primary conduit into the system. This architecture included a Web Connector on each of the web server machines and a Web Component Server (WCS) within the framework. The WCS provided application services for server side processing of Crystal Server Pages (CSP). CSP is a technology analogous to the Microsoft Active Server Pages (ASP) technology, with the key distinction that the processing occurs within the Enterprise framework in the CSP scenario. In the XI release, the default installation options include both a Java and .NET version of the packaged interfaces. The Web Component Server is removed from the framework. Support for CSP pages is provided through the Web Component Adapter running on the application server.

The BusinessObjects Java SDK includes a set of Java classes that communicate with the BusinessObjects Enterprise Framework. In a Java application server environment, no Web Connector (WC) or Web Component Service (WCS) is required. Instead the Java SDK is processed on the Web application server, which communicates via the Java SDK directly with the BusinessObjects Enterprise Framework. In addition, the BusinessObjects Enterprise Web Component Adapter (WCA) installs on the Web application server and provides the capabilities that you expect from the WCS: CSP processing and specific application support.

Microsoft produces the .Net Framework. Applications written within the .Net Framework are supported by BusinessObjects Enterprise via the .Net BOE SDK. This SDK includes primary interop assemblies and visual development controls for visual application development in Microsoft Visual Studio .Net. In a .Net application, there is no WCS, WCA, or WC required, as the native .Net assemblies are loaded into the .Net framework and communicate with BusinessObjects Enterprise via the COM SDK.

The current state of support for the SDK is both a reflection of the marketplace and a reflection of the historical progression of BusinessObjects Enterprise in response to the maturation of the Web server market. Because the previous versions of BusinessObjects Enterprise were introduced before the Web application market had matured, the product included its own application server: the WCS. Now that the Web server and Web application server markets have consolidated and matured, the WCS has been replaced by the capabilities of those application servers. Generally, all custom applications should be developed using the technology that is most appropriate: the Java or .Net SDKs. Although COM technology is supported in BusinessObjects Enterprise XI, with Microsoft’s migration to .Net from COM, it is recommended that development take place in .Net over COM where possible.

The Server Tier: Introduction to the BusinessObjects Enterprise Framework

The BusinessObjects Enterprise Framework, the backbone of BusinessObjects Enterprise, provides a distributed mechanism that manages the interaction and communication of the BusinessObjects Enterprise services that make up the server tier, as well as communication between this server tier and the BOE SDK. Each BusinessObjects Enterprise service uses the framework to describe the capabilities it offers and to discover other services that are registered with the framework. The framework treats each of the registered services as equals, which enables one service to use the capability of another BusinessObjects Enterprise server directly, thus enhancing scalability.

The Framework’s foundation is a communication bus that handles dialogue between the various services and facilitates automatic load-balancing and fault tolerance. This communication bus registers each service, categorizes the type of service, and maintains a tally of the status of each service. For scalability reasons, much of this service interaction is distributed and decentralized. This is one of the reasons BusinessObjects Enterprise leads the industry in scalability.

The BusinessObjects Enterprise Framework uses programmatic components, known as plug-ins, to represent each object type within BusinessObjects Enterprise. Plug-ins contain the appropriate properties and methods needed to handle a particular object within BusinessObjects Enterprise, and determine how BusinessObjects Enterprise should treat it. For instance, a service might require information about a Crystal Report, and will use the properties of the Crystal Report plug-in to retrieve the information. The Crystal Report plug-in properties include things like the report title, the database login information for that report, and the report thumbnail image. In contrast, a user plug-in might have the username, the type of login, and the group membership as its properties.

Although plug-ins become much more important as you start to explore application development using the BusinessObjects Enterprise SDK, they are a great way to start to explore the capabilities of BusinessObjects Enterprise. Figure 25.2 shows how a plug-in is used. They help you to categorize the types of objects you find in BusinessObjects Enterprise, and understand what you can do with each of them.

Figure 25.2 A plug-in is the way BusinessObjects Enterprise exposes the services of a server on the framework.

The object types that are part of the BusinessObjects Enterprise Framework are classified in the following groups:

• Administration
• Authentication
• Content
• Distribution

Administration Plug-ins

Administration plug-ins provide a way to manage the BusinessObjects Enterprise servers. Each plug-in exposes the control and configuration properties of a server within the BusinessObjects Enterprise system so that you can configure the behavior of each BusinessObjects Enterprise server. These plug-ins also provide activity metrics for each server.

Authentication Plug-ins

Authentication plug-ins provide a mechanism for BusinessObjects Enterprise to interact with external security systems and treat these systems as native authentication sources. The authentication plug-ins provided with BusinessObjects Enterprise are

• BusinessObjects Enterprise
• Windows NT
• LDAP
• Windows Active Directory

These authentication types are discussed in more detail in “The Server Tier: Overview of the BusinessObjects Enterprise Services,” p. 603.

Content Plug-ins

Content plug-ins describe the types of objects that end users (report viewers) would typically interact with, such as, but not limited to, a Crystal Report. The content types that are provided as part of BusinessObjects Enterprise are

• Folder
• User folder
• Shortcuts
• Crystal Reports
• OLAP Intelligence
• Microsoft Word
• Microsoft Excel
• Microsoft PowerPoint
• Rich Text Format
• Adobe Acrobat
• Text
• Users
• User groups
• Servers
• Server groups
• Events
• Connections
• Licenses
• Calendars
• Object packages
• Program objects
• Web Intelligence documents
• Universes
• Universe Connections

Distribution Plug-ins

A distribution plug-in allows anyone who is scheduling an object such as a Crystal Report to be able to send that report outside the BusinessObjects Enterprise environment. This facility enables the application to schedule reports to destinations such as e-mail. Distribution plug-ins that are provided with BusinessObjects Enterprise are

• Disk location
• FTP server
• E-mail (SMTP)

These plug-ins play a fundamental role in the BusinessObjects Enterprise Framework by encapsulating and exposing the knowledge of the object type that they represent. The remainder of this chapter discusses how these plug-ins are used by the BusinessObjects Enterprise servers within the BusinessObjects Enterprise Framework.

The Server Tier: Overview of the BusinessObjects Enterprise Services

Now that it’s clear that the functionality of individual BusinessObjects Enterprise servers is exposed through plug-ins, it’s important to understand exactly what that functionality is. The BusinessObjects Enterprise servers are designed to register themselves with the BusinessObjects Enterprise Framework and provide one or more services that can be consumed by other servers or by the plug-ins described in the last section. The services offered by each of the servers is dependent on the type of task that the server is expected to perform.

The following list shows the servers that are delivered with BusinessObjects Enterprise. These servers can be thought of as core servers:

• Central Management Server
• Cache Server
• Page Server
• Report Application Server
• Report Job Server
• Program Job Server
• Destination Job Server
• List of Values Job Server
• Event Server
• File Repository Server
• Web Intelligence Job Server
• Web Intelligence Report Server
• Web Component Adapter

These servers can be seen in the architecture diagram in Figure 25.3.

Figure 25.3 The core server architecture for BusinessObjects Enterprise.

With these servers in place, BusinessObjects Enterprise manages reporting and business intelligence content (such as Crystal Reports, OLAP Intelligence reports, Web Intelligence documents, Excel, Word, PDF, and PowerPoint documents) and offers rich customization services allowing organizations to deeply embed and integrate BusinessObjects Enterprise into their already established applications or Web services.

It’s important to note that multiple instances of the same server operating in the BusinessObjects Enterprise Framework at the same time are fully supported. This provides a scalable, reliable, and fault-tolerant system.

Central Management Server

The Central Management Server (CMS) provides a number of the core services that the BusinessObjects Enterprise Framework uses. These services include allowing other servers to register with the framework, allowing users to be authenticated with the system, and providing a storage mechanism for maintaining the metadata about each object. The services provided by the CMS fit into four main categories:

• Controlling access to content
• Managing objects and scheduling
• Managing servers
• Managing system auditing

The CMS provides for the following:

• System security
• Object metadata storage
• Object management
• Object scheduling
• Event handling
• Name-server capabilities
• Server clustering
• License management
• Auditing

System Security

The security service breaks security down into three main elements:

• Authentication
• Authorization
• Aggregation

Authentication

BusinessObjects Enterprise provides mechanisms to allow for third-party authentication services to be used as the basis of user and group/role definition. The CMS interacts with these third-party authentication mechanisms by using the following authentication plug-ins, described earlier in the chapter:

• BusinessObjects Enterprise security plug-in
• Windows NT security plug-in
• LDAP security plug-in
• Windows Active Directory plug-in
• Application authentication such as PeopleSoft or SAP

The Enterprise security plug-in enables organizations to define users and groups directly within BusinessObjects Enterprise and restrict use of an external source for those users. This is useful if an organization has chosen not to use an external security source or has not yet defined one. All authentication information is stored in BusinessObjects Enterprise and does not rely on an outside source to determine whether a user is valid.

The NT and Active Directory security plug-ins enable a customer to map any number of users and groups into BusinessObjects Enterprise. Although these two are separate plug-ins, they function in similar manner and so are discussed here together.

An administrator is required to go into the Central Management Console (see Chapter 27) or use an application written using the SDK and define the default NT or Active Directory (AD) domain as well as any user groups that might need to be mapped into BusinessObjects Enterprise. After this initial mapping is complete, BusinessObjects Enterprise will dynamically query for users within that group and establish those users as BusinessObjects Enterprise users. When a user logs on for the first time, the security service using the NT or AD security plug-in asks the NT or AD security database if this is a valid NT or AD user and whether the user belongs in any of the mapped groups. If the user is indeed a valid user, he will be granted access to BusinessObjects Enterprise. If at any time in the future that user is removed from that NT group, he will not be granted access to BusinessObjects Enterprise (and, hence, reports within the system) because the security service would be told that this user is no longer a valid NT user. There’s no requirement for the administrator to manually inform BusinessObjects Enterprise that the user is no longer a valid NT user.

The LDAP security plug-in operates in a similar manner to the NT security plug-in; however, instead of talking to the operating system for a list of valid users or groups, this security plug-in communicates with a directory server using the LDAP protocol. BusinessObjects Enterprise does not require the LDAP schema in the directory server to be modified in any way for use with BusinessObjects Enterprise. This security plug-in provides default mappings for several directory servers, including

• iPlanet Directory Server versions 5.1 and 5.2
• Lotus Domino versions 5.0.12 and 6.0.2
• IBM Secureway 5.1
• Novell Directory Services eDirectory 8.7
• Custom

When the BusinessObjects Enterprise solutions kits for PeopleSoft and SAP are installed, they provide additional authentication plug-ins for each system, respectively.

Users and groups are queried by leveraging attributes within the LDAP schema, such as InetOrgPerson, which is an attribute used by iPlanet Directory Server. If the directory server that is to be used with BusinessObjects Enterprise is not in the preceding list, it’s also possible to create a custom mapping of LDAP attributes. The attributes that are used to define a group or user must be mapped to the LDAP security plug-in for these attributes to be used when querying for a user or a group.

Application-specific authentication plug-ins enable BusinessObjects Enterprise to validate a user’s credentials against an ERP system such as SAP or PeopleSoft. Installing a BusinessObjects Enterprise Solution Kit installs the respective plug-in, which then appears next to the default authentication tabs in the Central Management Console. Each of these application-specific plug-ins requires configuration to enable BusinessObjects Enterprise to interact with the application, and require information on group mapping.

Authorization

After configuring BusinessObjects Enterprise with external users and groups, it’s necessary to determine which objects within the system an end user has the authority to view. This central mechanism of controlled access to certain reports is a key component of the system. Setting up authorization rules or access control is straightforward after users and reports have been added to the system. Chapter 27 reviews how to apply access control on objects in the system.

Aggregation

BusinessObjects Enterprise can aggregate or group users in two ways, as Chapter 27 reviews in some detail. A group can be created directly in BusinessObjects Enterprise or it can be mapped from one of the external authentication sources. The grouping within BusinessObjects Enterprise is quite powerful because native and mapped groups can be used at the same time. If this method of user aggregation is implemented, a native group would contain a mapped group. The use of mapped groups simplifies administration: As users are added or removed from groups in the external systems, this will be automatically reflected in BusinessObjects Enterprise. It’s also possible to create a hierarchy of groups to better organize the end users of the system.

Object Metadata Storage

Among other tasks, the CMS stores a repository of information about each object in the BusinessObjects Enterprise system. After this information is stored, it becomes available to other objects or servers within the system. This persistent data describes an object (such as a Crystal Report) and makes it possible to dynamically query the system and discover the properties of that object. This repository expanded in version 10 of Crystal Enterprise to include storage of objects used to design Crystal Reports as well as Business Views Objects (see Chapter 18, “Using a Semantic Layer—Business Views and Universes”).

This information is stored in a repository to enable scaling; to do otherwise would require dependence on the information being stored in memory on a physical server—not scalable. The CMS stores this information by writing it to a relational database. As the product matured through version 10 and now, XI, database querying capabilities were more fully leveraged than in previous versions, resulting in even faster request processing and enhanced scalability. However this changed functionality also requires that more attention be paid to database optimization.

The CMS service is able to access these databases by using ODBC or by a direct, also known as native, interface to the database. Because the CMS also provides auditing capability, the database compatibility is the same for the auditing database (you will consider the auditing capability later in this chapter). Although the BusinessObjects Enterprise system database and the audit database can be on the same or separate database servers, the actual databases are separate.

The following list shows databases supported by the CMS and how they are accessed by BusinessObjects Enterprise XI when the CMS is operating on Windows NT:

• Direct IBM DB2 8.1 and 8.2.
• Direct Oracle 9.2 and 10.1
• Direct Sybase System 12.5
• ODBC-MSDE
• ODBC-MS SQL Server 2000
• ODBC-MS SQL Server 7

The databases that the CMS can access on Unix are a subset of what is available on Windows. If the CMS is operating on Unix, it’s able to use the following databases:

• IBM DB2 8.1
• IBM UDB DB2 8.2
• Oracle 9.2
• Oracle 10.1
• Sybase ASE 12.5

All database connections for the CMS repository are done by a direct interface.

The default Windows-platform database that the CMS will use if one is not provided is the MSDE, a simple implementation of Microsoft’s SQL Server. Because performance of the CMS database can dramatically affect system performance, MSDE is used to provide an organization a useful out-of-the-box experience. The repository is set up and configured without the need for interaction with a database administrator. If BusinessObjects Enterprise is initially configured to use the default repository database and the need arises to move the repository to a different database server, BusinessObjects Enterprise provides tools (the Central Configuration Manager) to easily migrate the data from one server to another.

Nameserver Capabilities

The CMS allows all other BusinessObjects Enterprise servers to register with the BusinessObjects Enterprise Framework. After each service has registered through the CMS, it is able to discover the other servers active within the framework and use any services it needs from those servers.

New BusinessObjects Enterprise services can be added to the system from either the Central Management Console or the Central Configuration Manager. The addition of these new services provides additional scalability and higher availability.

Object Management

One of the key benefits of BusinessObjects Enterprise is how it manages objects. After an object (such as a Crystal Report) is published to BusinessObjects Enterprise, the properties of that object are read and added to the repository. The object is then represented by metadata in the repository, which makes it possible for other services to interact with the object, and the object is formally considered a “managed object” by the system.

Managed objects facilitate simplified administration of an Enterprise Business Intelligence system and represent a principal benefit of BusinessObjects Enterprise. After an object is managed by the system, all of that object’s properties become managed from a single access point. For instance, if a server needs access to an object, it asks the CMS for an ID to the object. Additionally, if you want to maintain a certain number of reports in the system, or only keep objects more recent than a certain date, this can be automated within the system. If you want to schedule a report, or organize similar reports into folders, or control access rights, or link reports, or change database properties of multiple reports—all of this and other similar actions are possible when you manage the objects within BusinessObjects Enterprise.

By having objects managed, a Web application developer can use BusinessObjects Enterprise to manage and provide access to all objects. Rather than requiring knowledge of object filenames or network share locations, or even which objects or reports are available at all, developers can simply query BusinessObjects Enterprise for the desired objects—perhaps those kept in a certain folder or of a certain type. Each time a user accesses the Web application, the content might be different, depending on the actual reports (objects) published by or scheduled into BusinessObjects Enterprise. Web developers are not required to make changes such as adding and maintaining reports. This can be done by a report developer or system administrator through delegated administration and provides a logical separation of tasks.

Managed objects can be categorized into folders, which themselves are managed objects. This categorization adds to the manageability of BusinessObjects Enterprise because content can be easily organized into something that is meaningful to end users. In addition to residing in a folder, BusinessObjects Enterprise XI introduced the concept of categories. Objects can be associated with one or more categories to further organize a collection of related objects that span multiple folders.

BusinessObjects Enterprise XI adds several new types of objects to the system, such as program objects and third-party objects such as Microsoft Word objects (please see “The Server Tier: Introduction to the BusinessObjects Enterprise Framework” earlier in this chapter for a complete list). The system database also includes a report component repository that simplifies access to corporate objects such as logos, images, disclaimers, and so on, and a rich semantic layer called Business Views.

If are not familiar with the database changes which occurred in Crystal Enterprise 10 and you were to look at the database directly, you would see that these additional capabilities have altered the database tables from previous versions of BusinessObjects Enterprise, and you now see four tables in the system database instead of the previous two. The two additional tables represent the report component repository. No additional tables were added between Crystal Enterprise 10 and BusinessObjects Enterprise XI.

For performance and security reasons, the vast majority of the information about objects is stored in a binary format in the database, making it unreadable to direct database access. Instead, the CMS provides access to database objects via the BOE SDK via a SQL-like query language. This system ensures authenticated and authorized access only; the application provides access to objects based on their authenticated identity only.

Object Scheduling

The scheduling service of the CMS makes it possible for objects such as Crystal Reports to be processed at a particular time or on a recurring basis. This service determines when a report object gets processed using the Report Job Server, or a program object gets processed using the Program Job Server. When a scheduled event occurs, the two main servers that interact with the object are the relevant Job Server and the Event Server. Additionally, an object package combines objects such as reports or programs for simplified scheduling.

When scheduling a job, the scheduling service gathers information from various objects before running. It needs information from the report object regarding how to connect to the database, the desired format to output the report to, where it might be delivered (such as an e-mail address), and which server is going to process it (if there are multiple Job Servers). An object can be scheduled to run at a particular date or time, on a recurring basis, or perhaps according to a custom calendar. This information is then stored in the system as a scheduled instance of the object. This is known as a ProcessingInfo object.

The ProcessingInfo object contains all the properties set on the report object when it was scheduled. It knows when the job will run as well as all the data-connection information and all the formatting and distribution settings.

A scheduled object can be made to be dependent on an event occurring within or outside the BusinessObjects Enterprise system before it will run. By using events with schedules, it’s possible to provide meaningful control around when a schedule should actually run. If an object is due to run every day but the databases that it queries are updated sporadically, an event can be used to initiate the running of the scheduled job and eliminate unnecessary scheduled jobs or reports.

A notification capability is built in to provide the capability to send e-mail upon a scheduled job completion, either in the case of success or failure. Common use cases include an administrator receiving notification of a report processing failure, or an end-user group being notified of the latest quarterly results.

In some instances, batch scheduling can take place via a custom program. In these cases, report instances might be distributed to many users. The scheduling service makes this possible by allowing a job to be scheduled on behalf of another user. This is useful when an organization wants to configure its system to only show instances of objects to a user if she “owns” that instance. This is exposed in the BOE SDK in the ScheduleOnBehalfOf property of the SchedulingInfo object.

Event Handling

Events make it possible for users to ensure that scheduled jobs are processing only when external systems, like a database, are ready to be accessed. All events interface with the CMS Event service.

BusinessObjects Enterprise supports three types of events. The first event type is a scheduled event. The scheduled event allows an organization to create dependency chains when scheduling reports. This enables the user to determine the schedule of a report based on a preceding report successfully completing or failing. Users can easily configure scheduled event conditions such that if report 1 is successful, run report 2. If report 1 is not successful, run program object 3. This can continue so that a process flow is established.

The next event type is a custom event. The custom event is sometimes also called a generic event in the predecessor to BusinessObjects Enterprise, known as Seagate Info. This event requires application developer interaction to trigger the event by using the Trigger() method via the BusinessObjects Enterprise SDK. This event type gives an organization a great deal of flexibility. Having an event that can be triggered by code makes it possible to have an external system determine when the event is triggered and the scheduled jobs that are dependent on it will run. A good example of this would be a database update trigger user event for BusinessObjects Enterprise.

The third type is a file-based event. These events are managed by the Event Server and are discussed later in the chapter.

Server Clustering

As a BusinessObjects Enterprise system grows and access to information that it contains becomes increasingly mission critical, it’s important that the system be fault tolerant, ensuring that end users are always able to access their information.

The CMS can be clustered to provide load balancing and fault tolerance for the services that it provides. When two or more CMSs are clustered, they perform as an active-active collection of servers. By being active-active, they are sharing the workload and this translates into increased scalability and performance.

Auditing

The auditing capability introduced in Crystal Enterprise 10, simplifies gathering statistics on system performance and enables administrators to profile the usage of reports or system resources. Because the auditing database is separate from the CMS/system database, you must create the “blank” database and any necessary ODBC DSN first. From within the Central Configuration Manager (CCM) you then stop the CMS, click on the Specify Auditing Source icon (the fourth icon from the right in the toolbar), specify the database or DSN you want to use, and then restart the CMS, whereupon the CMS creates the auditing database structure and connection. On Unix platforms you take the same approach, except that you stop and start the CMS with the ccm.sh script and use the cmsdbsetup.sh script with the selectaudit option to specify the audit database, including the connection port (which is 6400 by default).

After the CMS starts and connects to the audit database, you can specify which items you want to audit. The administrator enables auditing of each of the following items by entering the Central Management Console (CMC), navigating to the Servers, choosing the particular server you want to affect, and then checking the appropriate boxes in the Auditing tab. Table 25.1 shows each server’s auditing features. Note that the table does not include the Page Server; the Page Server’s auditing occurs through the Cache Server, which takes reports from the Page Server and passes them to the appropriate viewer. Note also that although the Job Servers are treated as one, they must be specified on each server. Additionally, you must specify auditing on each instance of a server if multiple instances exist.

Table 25.1 Detailed Auditing Capabilities by Server

Note that the CMS periodically broadcasts a request to all system services requesting audit information to be returned for writing to the database. The default is every five minutes. Your BusinessObjects Enterprise documentation describes several command-line flags to specify this and other audit-specific CMS parameters. You must specify the same command lines on all CMSs if clustered.

Web Component Server

The Web Component Server (WCS) which existed in previous versions of the product has been removed from the framework. However, it warrants a brief mention here. The WCS in Crystal Enterprise served as an application server to provide seamless integration of Enterprise content into any Web application. This integration was be hosted on a variety of Web servers and provided a robust scripting interface known as Crystal Server Pages that enables the creation of rich server-side Web applications.

At the time the product was introduced to the market many organizations already had licensed and installed Web servers, but did not possess an application server. Crystal Decisions found it necessary to provide this application server so that applications could be written against the SDK on any operating system platform. With the maturation and consolidation of the Web server market many of the functions that the WCS provided are now supplanted by the combination Web and application servers common in the marketplace, rendering the WCS application-serving capabilities unnecessary for most organizations.

However, the WCS did provide some capabilities in addition to CSP processing, and these functions, if desired in an installation, are now provided by the Web Component Adapter. In summary, the WCS capabilities include the following:

• Processing of CSP
• Report parameter prompting at report view time
• Report database logon requests at report view time
• Central Management Console server processing
• Rendering of OLAP Intelligence reports

To provide these capabilities, should they be required by the use case, BusinessObjects Enterprise includes the Web Component Adapter (WCA) that provides all the above, except the processing of CSP pages.

BusinessObjects Enterprise XI no longer uses the WCS. This server has been deprecated, although the functionality of the service continues to be available via the .NET or Java SDK or via a Web Component Adapter as an intermediary to on of the BOE SDK.

A typical Unix installation, for example, uses a client application such as InfoView written in Java Server Pages (JSP), rather than in Crystal Server Pages (CSP). Therefore, it does not require the WCS to process CSP pages. Instead, it uses a Java application server to process the JSP against the Java version of the BusinessObjects Enterprise SDK. In such a scenario, should you require the functions listed above, a WCA installed on the application server will provide that application server functionality.

Using the .Net BOE SDK in a Microsoft .NET environment, application-processing functions are carried out by Microsoft Internet Information Services (IIS) Web server and the .Net Framework application serving capability, as well as the BusinessObjects Enterprise Primary Interop Assemblies.

Although CSP is not specifically deprecated in BusinessObjects Enterprise XI, it has indicated in the help files that CSP is to be fully deprecated in a future release. CSP in BusinessObjects Enterprise XI is supported via the WCA for backward compatibility.

Crystal Web Request(CWR)

A type of request that is not mentioned in the above paragraphs is a Crystal Web Request, or CWR. A CWR is a server-side request that is executed by the WCA working in tandem with the services BusinessObjects Enterprise to provide access to managed objects contained within the BusinessObjects Enterprise repository.

In the prior version of the product, support for URL-based requests to directly view an object such as a report was deprecated because the report viewing model changed to a Crystal Report viewing control within the Application tier. Certain legacy applications might still use .cwr requests, but this method is not recommended for new installations to ensure forward-compatibility.

Web Component Adapter

In the default configurations in either a Java or ASP.NET environment, the Web Component Adapter serves the purpose of providing the following functionality.

• Processes CSP pages
• Services Central Management Console requests
• Handles viewrpt.cwr requests (legacy support)

The Web Component Adapter supports the following Java application servers:

• BEA WebLogic 7.0(SP5), 8.1(SP2)
• IBM WebSphere 5.0 (Fix-pack 2)
• IBM WebSphere 5.1 (Fix-pack 4)
• Tomcat 5.0.27

Job Servers (Report and Program)

The Job Servers process scheduled jobs. Job Servers are informed about the content that they process by loading a Job Server plug-in. This plug-in, like all other BusinessObjects Enterprise plug-ins, describes what capabilities it exposes to the service using it. In BusinessObjects Enterprise XI, there are four different Job Server plug-ins: one for Crystal Reports, one for Programs, another is for Web Intelligence documents and the fourth is for List of Values job server. When the system administrator adds a new Job Server to the BusinessObjects Enterprise system, he must choose which type of plug-in, and thus which type of Job Server it will be.

Report Job Server

The Report Job Server allows scheduled objects to access the necessary data source required, provides row-level data security services, and distributes the content to a location chosen by the user.

Essentially, the Job Server provides three main services to BusinessObjects Enterprise:

• Database access
• Distribution of objects
• E-mail

Database Access

When a scheduled job is about to be processed by the Job Server, it gathers the appropriate information from the ProcessingInfo object mentioned earlier. This information includes database connection information and any filters or parameters required that determine what the final query is. After it has this, it opens the object and queries the database for the appropriate information. The data is retrieved, compressed, and stored back into the system as a report instance.

Distribution of Objects

It’s the Job Server’s responsibility to distribute the object to the destination set by the user scheduling the job. To do this, the distribution service interacts with the distribution plug-ins mentioned earlier and receives the information appropriate to each plug-in type. For example, if a user scheduled a job to be delivered by e-mail, the distribution service would get the To:, Cc:, subject, and body properties as well as the SMTP server that is configured for use with BusinessObjects Enterprise. Chapter 26, “Planning Considerations when Deploying BusinessObjects Enterprise,” shows how to configure the distribution service.

This service enables a user to send a report outside the BusinessObjects Enterprise environment and deliver it to one of four destinations using the distribution plug-ins mentioned earlier.

Inbox As a Destination

New in BusinessObjects Enterprise XI is the ability to send objects to an user’s Inbox within the BusinessObjects Enterprise system. When a job is scheduled and it is to be sent to a user’s Inbox, the Job Server uses the appropriate methods to direct a copy or shortcut to the appropriate destination.

E-mail as a Destination

Crystal Enterprise supports SMTP as its e-mail distribution protocol. Virtually all Internet mail servers support SMTP, so it’s easy for an organization to integrate BusinessObjects Enterprise into its mail system, regardless of platform. By supporting standards such as SMTP, organizations are not restricted in the e-mail server types that can be used with BusinessObjects Enterprise.

FTP Server as a Destination

Organizations send objects directly to an FTP server location so that it’s available for other users or applications. This is useful for getting information that can be used offline by customers, partners, or suppliers. A report can also be scheduled to update information at an FTP location on a regular basis to drive another application or business process. For example, a report could be designed to provide a product pricing list, including dynamic calculations of discounts that vary by customer, and then deliver it automatically to an FTP folder on a customer’s Web server. Another example might be a scheduled Crystal Report output to an XML document sent via FTP to an external server for a business partner’s application to pick up.

Unmanaged Disk as a Destination

The unmanaged disk distribution service is used in the same fashion as the FTP server except that this service distributes the scheduled report to a disk location that is available on an organization’s internal network. Building on the preceding example, an organization could have BusinessObjects Enterprise distribute a general pricing list to a location on disk and have this information populated on a purchase form or as a way of populating values into a Web service.

Printer as a Destination

Distributing reports to a printer available on the network is as simple as deciding which printer is to be used when the report is processed. Printing reports often is necessary when the information on the report needs to be shared with people who don’t have access to a computer during analysis of that information. Situations such as team or board meetings often require that each member have a printed copy of the information to be covered.

Interacting with External Systems

Sometimes, it’s necessary for a job to be intercepted before being run. Typically, organizations choose to do this so that information from an external entitlement database can be queried, and they can determine what data the user is allowed to view and modify the filter to reflect their restrictions. Prior to the introduction of Business Views, this primary technique for handling this requirement was achieved using a component called a processing extension. The processing extension is loaded by the Report Job Server during a schedule or by the Page Server or Report Application Server if being viewed. This extension allows for row-level security. Row-level security makes it possible for organizations to have content, such as a Crystal Report, shared by many users but the actual data that they see is targeted to them. It’s also important to note that defining row-level security does not affect the content template but rather filters the view that the user sees based on the data that user has the right to see. There is no need to go into Crystal Reports and modify the report to affect which pages a user can see.

Processing extensions are just that, an extension of BusinessObjects Enterprise. Some examples of processing extensions are available for BusinessObjects Enterprise with the product.

Program Job Server

Much in the same way that the Report Job Server processes Crystal Reports, the Program Job Server processes programs. These programs consist of three types:

• Executable
• Java
• Script

These objects are published to the BusinessObjects Enterprise Framework, scheduled to be run by the Program Job Server, and executed. The goals of the programs differ as organizations can write programs according to their needs. Although processing a report results in a report instance, processing a program results in only a record that the program was run. The results of the program will depend on the program itself. Some programs might do maintenance on the BusinessObjects Enterprise system and some programs might have functions totally unrelated to BusinessObjects Enterprise—a powerful new capability to integrate BusinessObjects Enterprise functionality into an organization’s workflow.

Destination Job Server

The Destination Job Server introduced with the XI version of BusinessObjects Enterprise is a slightly different type of Job Server. In contrast to the Report Job Server that can both process and send an object, the Destination Job Server does not process or execute the object. Instead, the Destination Job Server uses objects already in the system, such as a report instance, and delivers that object to a destination. The default, enabled destination on a Destination Job Server is BusinessObjects Enterprise Inbox. Additional destinations such as SMTP, FTP, or file can also be enabled.

List of Values Job Server

Also new with BusinessObjects Enterprise XI is the List of Values Job Server that handles the processing of lists which are exposed as parameter pick-lists. The List of Values Job Server is very similar in nature to the Report Job Server, but the purpose of the service is distinctly used for generating and displaying Lists of Values.

Web Intelligence Job Server

The Web Intelligence Job Server also introduced with the XI release is much like the Destination Job Server in that it does not execute requests itself. Instead, the Web Intelligence Job Server receives the scheduled request from the CMS and then passes the request to the Web Intelligence Report Server, which runs the report.

Page Server

The Page Server is responsible for delivering three key functions to the framework. The primary function is to generate pages for viewing reports. This capability is relevant for performance and the scalability of viewing reports because it only ever sends a single page of a report to the viewers. It does this by using a function known as Page on Demand. Other functions performed by the Page Server are refreshing a report’s data using a feature known as on-demand viewing as well as the capability to export a report to another format for end-user download.

Page on Demand

The Page on Demand function of the Page Server receives a request to view a certain page of a report and then generates just enough information to have the report viewers display that page. As described previously, it’s much more efficient in a multi-user or low bandwidth environment to have pages of a report rather than the entire report sent to the viewer. This feature not only ensures a positive user experience by getting them the view of the report they’re after quickly, it also is important to administrators.

Page on Demand minimizes demand on network bandwidth. Each page of the report generated by the Page Server is approximately 2KB in size. A report is usually much larger than this, especially if it’s many thousands of pages containing thousands, if not millions, of rows of data. It should now be apparent why Page on Demand is a useful feature. This service goes one step further by ensuring a positive user experience through a technology known as report streaming.

Report streaming builds on Page on Demand by determining which objects in the page might take longer to calculate than others and then delivering them to the viewer slightly behind objects that can be generated quickly. For example, the report might contain summaries or charts that require additional calculations to be performed before rendering for the end user who is viewing the report. Report streaming will ensure that the rest of the information, such as the details making up the chart or summaries, is sent to the user right away. The remaining portions of a report are sent as soon as they are calculated on the server. Report streaming is similar to the placeholder technologies that browsers use when loading images.

On-Demand Viewing

The Page Server allows a user to refresh the view of the report dynamically instead of scheduling the report. To take advantage of this service, users first must be granted the proper access level for the object that needs to be updated.

If a user has this access level, he has the capability to force the report to connect to the database upon his request. When the user refreshes the report, he will be prompted to enter any relevant information the report requires, such as database connection information or parameter values. Before enabling on-demand viewing for all users, the use of the system and size of reports must be taken into consideration. If many users are querying the database at the same time, are they asking for similar information? If so, the report could be run once and then shared among many users. What amount of data is expected to be returned or how long is the report expected to run? Often, a report might be too complex to enable all users in an organization to run it themselves. Based on the amount of time spent in the database, on the network, and in the report engine, a report can take several seconds, or even minutes, to complete. If this situation occurs, it makes sense to schedule any complex reports that spend a lot of time processing and allow that report to be shared among the users.

Exporting to Other Formats

The Page Server makes it possible for users to request to have the report presented to them in a format other than Crystal Reports. These formats are Crystal Reports, Microsoft Word, Microsoft Excel with formatting, Microsoft Excel data only, Adobe Acrobat, Rich Text Format, Editable Rich Text, text, or Comma Separated Value (CSV) format. The user can request these formats typically by selecting the Export button in the report viewers.

Row-Level Security

In the same manner as the Job Server, the Page Server is able to restrict information presented to users based on a row restriction set by a processing extension. The main difference here is the Page Server is providing this capability at view time rather than at schedule time. Each method has its benefits. If a report has a row restriction applied to it during scheduling, the amount of data being returned to the report is filtered during the query. This means that the report instance only contains data that is relevant to the user who scheduled it. Another method is to apply the row restriction at view time.

If restrictions are applied at view time, the report instance contains the data necessary for the report, regardless of who is viewing it. When a user requests the report, the Page Server communicates with the processing extension to determine the row restriction to be applied for the user viewing the report. The data is then dynamically filtered so that the user is seeing only the data that he is able to see.

Cache Server

The Cache Server is an integral component to the overall scalability of BusinessObjects Enterprise. It establishes a cache of report pages generated by the Page Server, which are called encapsulated page format (EPF) files, and promotes the sharing of this information. This is an important facet of the BusinessObjects Enterprise Framework because, instead of having the report page regenerated for each user who requests it, the Cache Server determines whether the page can be shared among users. If it can, it will return the cached page. The Cache Server receives these requests from the report viewer and when the request is received, it checks to see whether the page requested is available in cache. If it is, the page is returned to the report viewer to complete the request. If it is not, the request is sent to the Page Server to have it generated.

In the case that the Report Application Server serves the view request, caching occurs inside the Report Application Server itself, and the Cache Server does not interact with it. The Report Application Server would service view requests requiring interaction; for instance, when using the Interactive Viewer, the Report Application Service renders reports, as it has the additional capabilities that the Interactive Viewer requires.

Cache Management

The Cache Server is responsible for maintaining a cache of report pages generated by the Page Server on disk. When a request for a page is received, the Cache Server checks to see whether the page is available in its cache and whether it can be shared. If it is a sharable page, the server returns the page to the user. If the page cannot be shared, the request is sent to the Page Server to generate a new page.

Constraints

Sometimes, pages are not sharable. The Cache Server determines that a report page is not sharable if it meets one of these conditions:

• Row-level security is being enforced—If row-level security is being used, the page of information is valid only for the user who requested it; therefore, the Cache Server is unable to pass this page onto another user.
• The query within the report has changed—The query for the report can change if a user chooses to view a report and change the filter already previously defined or change a parameter value. When this occurs, the cached page is invalidated and must be regenerated.

Event Server

The Event Server provides a way for BusinessObjects Enterprise to monitor and use events that are occurring outside of its environment. It enables an organization to trigger the running of BusinessObjects Enterprise scheduled jobs dependent on external events.

The Event Server monitors the operating system for the existence or modification of a file. Using a file to trigger an event is a useful way of determining when an event is triggered because the generation of a file is a simple thing to achieve. For example, an organization might perform a nightly data warehouse update, and have the same program that does the database load create a file after finishing the load. Upon file creation or update, the event server then reports to the CMS that the required trigger is present, allowing the scheduled job to be processed.

File Repository Servers

The File Repository Server provides the BusinessObjects Enterprise Framework with two core services. The first is the capability to provide a centralized content storage facility, and the second is the capability to abstract the location of these objects from other services within the framework.

Centralized Storage of Content

BusinessObjects Enterprise provides two File Repository Servers (FRS). An input FRS is used to store any content that has been published to BusinessObjects Enterprise by the Publishing Wizard or from the content creation tools. When content is published to BusinessObjects Enterprise, the object is copied from the client to a location in the FRS. This location is set by the installation of BusinessObjects Enterprise but can be controlled by the administrator through modification of the FRS root directory. The objects are placed into unique folders on the server and are given unique names to ensure that there will not be any conflicts with other objects.

An output FRS is used to store the content generated by a scheduled job. The output server operates in the same manner as the input server by generating a unique name and location for each object.

Abstraction of Content Location

Now that the content is centrally stored and managed, the FRS abstracts the actual location of the objects from the other framework services. By using Uniform Resource Identifiers, or URIs, the framework sees a virtual “location” for the content. This makes it easy for services to request an object from the FRS without the need to ensure that it has access to the actual physical disk location. From a deployment and administration perspective, the job is much easier if objects are referred by URI. There is no need for complex network configurations, such as setting each service to run as a user account so they can access network shares.

However, this means that the system administrator must ensure that the account privileges of the FRS daemon or service include access to the disk location(s). This concept, of appropriate privileges for services, echoes throughout the entire system. The various services or daemons all interact with the operating system in different ways, and each requires the appropriate rights to function.

Report Application Server

The Report Application Server is a powerful add-on server to the BusinessObjects Enterprise Framework. It enables organizations to take their Web reporting a step or two further than the simple viewing of report content over the Web. The Report Application Server provides three new components for the framework: an alternative processing component for the report, a full object model for creating and modifying a Crystal Report, and a dedicated server for handling the creation and modification requests.

Crystal Report Modification and Creation Concepts

One of the main benefits of adding the Report Application Server to the BusinessObjects Enterprise Framework is that organizations can quickly and easily add Crystal Report creation and modification capabilities to their Web applications. The Report Application Server makes it possible to connect to a server-side data source, query for information, and then display that information, all within a zero-client Web viewer. By using any of the built-in clients that are delivered with the Report Application Server or using the object model to create a custom user interface, it’s possible to provide ad hoc Crystal Report creation and modification to the system end users—and essentially provide self-service reporting.

Web Report Design

The Report Application Server can take the data returned as part of the previously mentioned ad hoc report query issued by an application user and allow her to begin to format the report. The user is able to modify the query in many ways to format it into a quality report. Many people, after seeing these capabilities within a Web browser, remark that the experience is similar to a Web-based version of Crystal Reports. The Report Application server enables the making of database connections, selecting and joining tables, choosing fields, grouping and summing, creating formulas and charts, and formatting fields and sections.

Interactive Report Viewing

In addition to the capabilities of the BusinessObjects Enterprise report viewer connected to the Page Server, a benefit of connecting to the Report Application Server from a report viewer is that it provides an object model that enables the report to be manipulated on the server. You can modify the viewer to provide a flexible viewing experience.

The viewer supports an event model that provides you with the information selected by the user in the viewer. This makes it easy for organizations using the Report Application Server to make closed loop systems.

This means that when the event model is used, a report can become much more interactive and drive more business value. For example, a retail organization uses BusinessObjects Enterprise to present its product catalog to its users. The reports are very useful and allow users to browse the catalog or drill in for more details on items. If the user wants to order something, he needs to navigate to another form to enter his order and he has to keep looking back to the catalog report to remember the part number he wants to order.

Using the event model of the Report Application Server this organization can, without changing its catalog report, enable the user to click on the item he wants right within the view of the catalog. This event captures the data that the user clicked on and enables the Web developer to populate the order screen with this information with no user interaction. If the report also displayed inventory counts, the report could be updated as soon as the user finished his transaction.

Rich Object Model

The Report Application Server provides a powerful object model (covered in detail in Chapters 33, “BusinessObjects Enterprise—Customizing the Crystal Reports Viewers,” and 34, “Crystal Report Modification and Creation APIs”) that allows an organization to control any aspect of how a user performs an ad hoc query or formats it. In typical ad hoc tools the users are given the same tool and the organization deploying the tool has no say in how the user is able to perform her tasks.

The Data Tier

Every organization has data in a wide variety of sources: databases, applications, XML files, Excel spreadsheets, EJBs, and so on. BusinessObjects Enterprise provides unparalleled access to data in a wide variety of formats. Although data access was covered in Chapter 1, “Creating and Designing Basic Reports,” several architectural concepts around this topic merit our attention. First, BusinessObjects Enterprise XI includes Business Views, which provide a level of abstraction above data sources, greatly simplifying report writing and data security. Second, you will explore some of the most common sources of data.

Business Views

Rather than connect directly to data sources, an organization can use Business Views to simplify data access. Using the Business Views (BV) Semantic layer speeds report development because the report developer bypasses several typical steps of report development: connecting to the data source, choosing tables, joining tables, and adding calculations. Instead, by choosing the BV, the report developer sees a complete set of fields logically organized around business problems and areas.

During development of a BV, a database administrator or subject matter expert with database skills chose the appropriate data sources and tables or other constructs, joined them together, selected the necessary fields, created any formulas or functions, and applied security at row and column levels against BusinessObjects Enterprise User groups.

Architecturally, this can be seen as a separate layer between the processing services in the server tier and the data sources. BVs are not required to access data because direct connections to data sources remain. BVs are covered in greater detail in Chapter 18.

Universes—Semantic Layer

Another alternative to mapping complex data sources, is the use of Universes as a Semantic layer providing similar efficiencies to Business Views. A comprehensive coverage of Universes is out of scope in this book, however it is recognized that Universes are a powerful device for managing complex data models.

Data Source Types

Although available data sources were discussed in Chapter 1, a brief summary helps to understand some key architectural concepts when connecting to different types of data sources. The following few sections cover some of the most popular data sources in the enterprise computing environment.

Database Systems

Databases are the prototypical data source. There are several ways that the Server tier connects to databases. An ODBC connection uses an ODBC driver to communicate with the Database Management system (RDBMS), which returns the relevant data. Every machine hosting report processing services from the BusinessObjects Enterprise Framework, namely Page Servers, Report Job Servers, and Report Application Servers, must have the requisite ODBC Data Source Names (DSN) configured. ODBC connections require special support on Unix-based machines, often in the form of an ODBC driver that must be purchased in addition to the operating system.

Using a direct connection to a database most often requires a database client application installed on any machines. Most RDBMSs that support native connections ship with their respective database client applications, which then must be installed on machines hosting BusinessObjects Enterprise report processing services.

Application Data Sources

BusinessObjects Enterprise offers a variety of Solution Kits that include application-specific integrations to provide data access to those applications. For instance, the SAP Solution Kit facilitates access to SAP’s R/3 and Business Warehouse.

These Solution Kits represent a high level of integration, usually providing single-sign on so end users can use their application credentials to log on to BusinessObjects Enterprise. They are also notable in that data access does not proceed directly from the BusinessObjects Enterprise processing services or daemons to the application databases, but rather connects to the applications themselves, which subsequently manage queries and security and often data transformation to simplify data access. So application data sources present an additional level of abstraction from the underlying data source. These are covered in detail in Chapter 15, “Additional Data Sources in Crystal Reports.”

Programmatic Data Sources

A data source might not be accessible in the correct format, or might require some transformative or conditional logic. In these cases a software developer can write a program using the appropriate logic, and then expose the resulting data to BusinessObjects Enterprise. BusinessObjects Enterprise supports connectivity to these programmatic, or Active, data sources. Typical programs would expose a JavaBean, ADO (COM), or ADO.NET data provider, which would be consumed by BusinessObjects Enterprise.

For more information on this, see “Understanding the Additional Crystal Reports Data Sources,” p. 338.

The BusinessObjects Enterprise Architecture in Action

This section takes a look at how all the BusinessObjects Enterprise services come together and which of the services are used when a user requests objects. Each scenario is based on the following situation: Over a corporate intranet site, a user is browsing a Web page that connects him to a BusinessObjects Enterprise system. The user has provided proper login credentials and is logged into BusinessObjects Enterprise. He has been presented with a list of report objects that he has rights to access.

For this scenario to occur, a browser has connected to a Web Server with a request for BusinessObjects Enterprise. The request, assuming it does not require WCA processing, is passed from the Application server to BusinessObjects Enterprise Framework via the BOE SDK. For example, if the page is written in JSP, the Java application server passes a request to the BusinessObjects Enterprise Framework via the BOE SDK classes loaded on that application server. The continued interaction between the user and BusinessObjects Enterprise Framework occurs through the facility of the BOE SDK on the application server.

If you are using the CSP pages provided in a COM environment, the request is passed to the WCA for processing. The .csp is processed and in this scenario, the page asks the user for logon credentials and is returned to the user to complete. The credentials are submitted and passed to the WCA. The WCA now takes this information and relays it to the CMS via the BOE SDK. After the user is logged on to BusinessObjects Enterprise, the CMS is queried to present a list of folders and reports to the user. (The query is generated within the CSP page as well.) This scenario diagram can be seen in Figure 25.4.

Figure 25.4 The login process for a user validated by BusinessObjects Enterprise.

If you are connecting to the BusinessObjects Enterprise via the Web Component Adapter or directly through the SDK, the general process flow remains the same. For simplicity, the following examples will use the .Net and Java environments without pointing out when the Web Component Adapter is invoked.

Figure 25.5 The report-loading process in BusinessObjects Enterprise.

Figure 25.6 The report loading process for on-demand viewing.

Figure 25.7. The process for scheduling reports.

Requesting a Crystal Report

The user in the preceding scenario has two methods of viewing a report.

The first method is to view an instance of a previously scheduled job. If an instance is chosen, the report contains cached data from when the job was run. When the request to view the report is received, the Cache Server is interrogated to see if the first page of this report is available in cache. If the first page is available, the Cache Server returns the page to the Application Server so it can be delivered to the report viewer. The report viewer then displays the report for the user. If the page is not in the cache, the request is forwarded onto the Page Server to generate the page.

As Figure 25.5 shows, when the Page Server receives the request, it loads the report from the output File Repository Server. After the Page Server loads the report, it generates the page that has been requested and then passes it back to the Cache Server. The Cache Server sends the page onto the Application Server to be given to the report viewer.

The second method for viewing a report is to view the report itself, which is also known as on-demand viewing. If a user selects the report itself, she must first have the “view on demand” access level. When the report is requested it goes through the same process as shown in Figure 25.5; however, because the report does not have any cached data within the report like the instance has, the Cache Server passes the request directly onto the Page Server.

Figure 25.6 shows the extra steps required for on-demand viewing. The Page Server queries the input FRS for the report and loads it. After the report loads, the user will be asked to enter the database logon information and any parameters for the report to run. The Page Server then passes this information to the Crystal Reports engine through the report plug-in. The Crystal Reports engine connects to the database and queries for the necessary data. After the data has been returned to the report engine, the report is recalculated and page information is determined. The Page Server now generates the first page of this report and sends it to the Cache Server, which in turn passes it to the Application Server and then to the report viewers.

In both scenarios of viewing a Crystal Report, if a processing extension is being used with this report, the cache is then not sharable. The Cache Server will pass the request directly to the Page Server. The Page Server will load the report from the FRS. During the time that the report is being loaded, the processing extension is engaged to determine the proper row-level restrictions that need to be applied to the cached data within the report. The cached data is then filtered and the page is generated with information that is viewable by that user only.

Scheduling a Crystal Report

When a report is scheduled, BusinessObjects Enterprise requires the appropriate information so that the scheduling service knows what tasks are to be performed. Figure 25.7 depicts a typical scenario where an end user schedules a report with the appropriate criteria set. This information is passed to the Application Server, which in turn forwards the information to be stored in the CMS. The schedule is set to run at a particular point in the future. When the schedule time occurs, the CMS loads the information from the repository and submits the request to a Job Server. The Job Server asks the input FRS for the report and then loads it into the report Job Server plug-in.

With the report loaded, the Job Server applies any of the parameters set when the user scheduled the report earlier. These parameters might be filters that affect the overall data query. If a processing extension is in use, the report would be further manipulated. After the processing extension is finished with the report, the Job Server connects to the database and completes the processing of the report.

When the job has completed, the Job Server checks two remaining pieces of information the user would have set when scheduling the report; the format in which the report is to be delivered and where it will be delivered. At this stage, the Job Server would output the report into a supported BusinessObjects Enterprise format, including Crystal Reports, Microsoft Word, Excel, Adobe Acrobat, Rich Text Format, Editable Rich Text format, or text.

Next, the Job Server needs to distribute the report to the desired location. As previously mentioned, these locations can be a location on disk, an FTP server, or an e-mail address, or remain in the managed BusinessObjects Enterprise environment by distributing it to the output FRS as a general report instance object or inbox instance object. Regardless of where the user decides to distribute the object, a copy is always stored in the output File Repository Server so that it can be further shared between users.

Requesting a OLAP Intelligence Report

If an organization is using OLAP Intelligence, it’s important to note that report viewing is handled differently from a Crystal Report. Requesting an OLAP Intelligence report starts by the user clicking on a link to the report in a Web browser.

The request is delivered to the Application Server, and it asks the CMS for the object that was asked for. The object is returned to the Application Server and then is loaded by the OLAP Intelligence engine. The reports created in OLAP Intelligence are dynamic queries to a multidimensional cube of data—the OLAP Intelligence engine must connect to the cube referenced in the report.

After a connection to the cube is made, data is retrieved and populated into the .car file, which is an XML document. This XML document is transformed through a style sheet into DHTML and delivered as the first view of the report. This information is sent from the Application Server to the Web browser along with the OLAP Intelligence DHTML viewer. The viewer makes additional requests for data from the cube via the Application Server as it is needed to populate the view of the report.

Taking Advantage of the BusinessObjects Enterprise Distributed Architecture

This section of the chapter discusses how the BusinessObjects Enterprise Framework and all the services that it provides are most effectively deployed. As mentioned earlier, BusinessObjects Enterprise is designed as an n-tier distributed system for information delivery. This distributed nature gives an organization a great deal of flexibility in how it might want to deploy BusinessObjects Enterprise in its environments. How BusinessObjects Enterprise is deployed will depend on the way in which the system is expected to be used, how many users are expected to be active in the system at any given time, and how many objects are expected to be processed at any given time.

Scaling Up

The term scaling up implies that a software product is able to take full advantage of the physical hardware resources it has access to and ultimately increase its performance as the hardware increases. BusinessObjects Enterprise was designed from its inception to effectively scale up.

All the BusinessObjects Enterprise servers are multithreaded components that are able to scale to take advantage of available physical hardware resources. They have been designed to operate on multiprocessor machines efficiently.

When a system is under high load, even being multithreaded isn’t enough. If the load on the servers is high enough, I/O might start to become the limiting factor. BusinessObjects Enterprise deals with this by allowing an organization to configure multiple instances of a server on the same physical piece of hardware. This makes it possible for additional servers to share in the load and remove any I/O bottlenecks. A benefit in doing this is that automatic load balancing kicks in, making the system that much more efficient.

Scaling Out

Building on the scalability in BusinessObjects Enterprise for scaling up, the capability to distribute report processing loads to multiple physical machines is also available. This is beneficial in many ways.

As an example, an organization can scale its systems to very large levels by adding physical servers to the environment when needed. If an organization chooses to license BusinessObjects Enterprise using named or concurrent access licenses, additional hardware resources can be added to the environment as needed without purchasing additional BusinessObjects Enterprise user licenses. If processor licenses are initially purchased, new processor licenses must be purchased when the additional hardware is added. This is why it’s important to understand the expected usage of the system as well as project the future growth of the system so that the appropriate license model is chosen.

The second benefit is the capability to assign tasks to certain computers. For example, the Job Server, Page Server, and File Repository Server could be grouped together on the same physical computer. The Page Server and Job Server both connect to databases and both communicate with the File Repository Server. Locating them on the same computer makes sense in many situations.

The next benefit of scaling out with BusinessObjects Enterprise is fault tolerance. BusinessObjects Enterprise provides the capability not only to have multiple instances of the same service running on the same computer, but also allows for those servers to be spread across multiple machines. BusinessObjects Enterprise has automatic fail-over support in each of its servers to complement the automatic load-balancing capabilities. This means that if a server goes offline for any reason, other servers registered to the BusinessObjects Enterprise Framework will automatically pick up the workload without user interruption.

Scaling Across Platform Boundaries

Some deployments of BusinessObjects Enterprise might require a distributed system on different operating systems. BusinessObjects Enterprise makes it possible for an organization to deploy BusinessObjects Enterprise across any of its supported operating system platforms. This provides a way for organizations to decide what deployment scenario best fits their needs, given the hardware available to them. A key benefit to being able to do this is that organizations might want to seamlessly mix functionality available from different operating systems. For example, an organization might require that reports process on Unix but still want the users authenticated using Windows NT accounts.

There might be situations in which it’s necessary to have certain servers running on one operating system and the rest of the system running on another. For example, an organization might have the majority of BusinessObjects Enterprise operating on Unix, but want to seamlessly integrate the SQL Server Analysis cubes being used in the OLAP Intelligence reports created by the finance department. These reports can easily be added to the BusinessObjects Enterprise system running on Unix, as long as a WCS is running on Windows so that the OLAP Intelligence reports have access to SQL Server Analysis Services.

Extending BusinessObjects Enterprise

An important aspect of information delivery is how the information is presented to the user community. BusinessObjects Enterprise enables organizations to easily customize how information is presented to end users by providing a rich object model for Web application developers to tightly integrate BusinessObjects Enterprise into their Web applications. Developers can present content to end users, as well as provide Web-based administration applications to their organization, using the BusinessObjects Enterprise SDK. The upcoming sections detail the flexibility of the entire Business Objects suite of products and how they can be easily integrated into any environment.