Evolving the Universe

 < Day Day Up > 



For designers used to a waterfall development approach, welcome to the realities of business intelligence: it’s all iterative. The universe is never finished. Your first universe is version 1, which will evolve as you elicit user input, the business environment changes, the applications evolve, the source systems/data marts change, and the technology changes. Figure 15-4 illustrates how a universe evolves over time.

click to expand
Figure 15-4: Universe development follows an iterative process.

You normally update the universe as the first users see it. Ideally, pilot users will preview the universe as you are developing it to ensure it will fulfill the intended business goals and requirements. This can be in a formal joint application development (JAD) session or with one user looking over the designer’s shoulder. It is not a pilot! Until you have done a thorough quality assurance review, users do not access the universe. As a result of the quality assurance review, you may make more changes, perhaps to correct errors, tweak performance, or make classes and objects more meaningful. Following quality assurance, the universe goes to a pilot phase. The goal of the pilot is to identify  errors or opportunities for improvement you could not uncover yourself; the goal of the preview is to tell you if the universe development looks as users expect.

Finally, users begin accessing the universe in a controlled way via a pilot. This is your first glimpse of payback for all your development efforts. If your company is new to ad hoc reporting, be sure to choose your pilot users wisely; casual users accustomed to fixed-screen DSS systems will be overwhelmed unless you provide them with parameterized reports. The pilot is typically a limited number of power users who understand the data and are fairly computer literate. For ad hoc access, they may be accountants or business analysts used to writing their own SQL or 4GL reports. The pilot uncovers more objects that you may need to build, modify, or remove hiccups in the supervisor/universe integration, and so on. Modify the universe following the pilot period and before you move to full-scale implementation.

As you make major changes to the universe, it’s helpful to document these in the Comments (File | Parameters | Summary). Also, I recommend you keep a separate backup copy of the universe.unv file. In the event of a disk crash or other hardware failure, you will be able to restore the entire repository and the universes if you regularly back up the repository database. However, as you revise individual universes, there is no way to recover a particular version from the repository; keeping a copy of the universe.unv file allows you to do this.

Benchmark Reports

During the pilot, it is important that either the designer or the power users develop standard reports that can be used to benchmark universe performance. Clearly, the universe is only one component that affects performance. However, if BusinessObjects is the tool that accesses the data, it is all the users will see and, therefore, will get blamed entirely for performance issues. Users rarely say, “the data mart is slow,” but frequently say “BusinessObjects is slow today.”

Some companies do a formal stress test during the pilot phase. Although BusinessObjects does not provide integrated benchmarking tools, tools are available from third-party companies. For example, some companies use Compuware’s QALoad to simulate user load on the system. One federal agency used it to simulate RDBMS and WebIntelligence (WebI) utilization for, initially, 25 concurrent users. As they neared 125 concurrent users, they experienced transaction failures; the RDBMS did not respond to WebI within specified time limits. Following the test, the agency went from one WebI server to a cluster manager with three nodes. This kind of controlled testing is much easier to manage than uncovering performance issues during actual implementation.

Figure 15-5 provides a conceptual overview of the phases of a user query, starting with the initial login and finishing with the presentation of a formatted report. In a full-client implementation, all the software and BOMain.key can reside either on the individual user PCs or on a workgroup application server. WebI can be deployed in either two-tier mode, in which all the software resides on the midtier and users access it via a browser, or in three-tier mode (ZABO), in which the software gets installed on the user PC via a plug-in. With three-tier mode, the WebI midtier still provides the connectivity to the source databases, whereas in full-client or two-tier mode, all the database drivers must also reside on the client PC. Figure 15-5 shows only one WebI server—although clearly, one could have a cluster manager and multiple nodes. With three-tier mode, the additional bottleneck becomes the initial software installation and subsequent software updates. Table 15-4 explains the potential bottlenecks during each of these phases in full-client and thin-client modes.

click to expand
Figure 15-5: Process overview of a BusinessObjects query

Table 15-4: Potential Bottlenecks that Affect BusinessObjects Response Time

Phase

Description

Potential Bottlenecks

1

Repository Login

  • For full client, LAN performance to access BOMain.key and software if not installed on local disk.

  • For full client, WAN performance for client PC to access Repository RDBMS; for thin client, WAN performance for WebI server to access repository RDBMS.

  • RDBMS load if a significant number of users simultaneously access repository, security domain.

  • Security domain if the security settings are complex and use timestamps, resources enabled and disabled

  • For WebI, load on WebI Cluster Manager.

2

Universe Import

  • Size of universe and kernel universe if linked; the universe.unv files get imported to the client PC or WebI midtier.

  • Number of exported custom lists of values, as the object.lov files get imported for each user.

  • Size of exported custom lists of values that contain data, as this increases the size of each object.lov file.

  • Size of universe domain.

  • WAN performance to transport universe definitions.

  • For WebI and application servers: only the first user accessing the modified universe is affected.

3

Launch Query: Analyzing and Executing

  • Number of users concurrently logging into RDBMS.

  • If using row-level security within data warehouse, complexity of security model and number of views to implement.

  • If accessing source ERP, current load on system to update transactions.

  • Ability of RDBMS to execute SQL efficiently, using indexes whenever possible; subqueries can be slow.

  • For WebI: number of concurrent users, in particular those who open full-client documents.

4

Launch Query: Fetching

  • WAN performance to deliver results from RDBMS back to user PC or WebI midtier, particularly for queries that contain a large numberof rows (in other words, 100,000 or more).

5

Present Results: Computing

  • Memory on user PC to convert text results to micro cube, display charts, formatted tables, link multiple SELECT statements.

  • For WebI: complexity of reports, conversion to HTML.

Debugging performance is a complex task. In a full-client environment, individual PCs and LAN performance are hard to control. In a WebI environment, utilization of different cluster nodes, a user mix of thin and full clients, and file conversions to different formats significantly add to the complexity. As the designer, the key thing within your control is the query execution time. While the RDBMS may largely affect this, the SQL generated is often the culprit of poor query performance.

Some BI tools do not allow users to see the exact SQL that gets submitted to the RDBMS; BusinessObjects does. There are a few exceptions, such as queries that contain prompts, but for the most part, you can copy the SQL from the BusinessObjects Query Panel and rerun it in another tool. The DBA can submit the same SQL directly to the RDBMS to isolate whether response time problems are RDBMS-related or not. This is reflected in step 3 in Figure 15-5 and Table 15-4. If the query executes within a similar time in the RDBMS as in the full client or WebI, then RDBMS load or query execution is most likely the source of the response time problem. DBAs or other support personnel can analyze the SQL against an explain plan to understand if the RDBMS executed the query efficiently with indexes or performed full-table scans.

To access the SQL from within the BusinessObjects full client, select Data | Edit Data Provider and click SQL to launch the SQL viewer.

From within the SQL viewer, click Save to save the SQL to a separate text file.

click to expand

From within WebI, select Edit from the menu bar and then click SQL. The SQL viewer within WebI does not have a save to disk option. However, you can still highlight the SQL statement and use CTRL-C to copy and paste it to Notepad or another SQL or text editor.

click to expand

BusinessObjects also tracks how long it takes to run the query and build the micro cube. In the full client, the elapsed time unfortunately does not distinguish between phases 3 (executing) and 4 (fetching), even though it does display this information on the status bar. To view the query execution time, open the Data Manager via the pull-down menus Data | View Data or select the Data Manager button from the toolbar. Select the Definition tab. The Duration column displays how long it took to execute the query, transport the raw data across the network, and build the reports. In the next example, the last query refresh finished in 16 seconds and contained 591 rows. The refresh at 4:20:58 P.M. finished in one second but contained 50,000 rows.

click to expand



 < Day Day Up > 



Business Objects(c) The Complete Reference
Cisco Field Manual: Catalyst Switch Configuration
ISBN: 72262656
EAN: 2147483647
Year: 2005
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net