SAP Business Objects Best Practicesv2

SAP Business Objects

Best Practices

Confidential - Deloitte Proprietary Page 1

Table of Contents1. Executive Summary............................................................................................................3

1.1 Purpose..........................................................................................................................31.2 Scope.............................................................................................................................31.3 Audience........................................................................................................................3

2. Universe Designer/IDT.........................................................................................................42.1 Connection.....................................................................................................................42.2 Class..............................................................................................................................42.3 Objects...........................................................................................................................42.4 Predefined Conditions....................................................................................................52.5 Tables............................................................................................................................52.6 Joins and Context...........................................................................................................52.7 Import/Export.................................................................................................................5

3. Webi Reporting Standard Guidelines...................................................................................63.1 General Information.......................................................................................................63.2 Data Providers...............................................................................................................63.3 Report Variables.............................................................................................................73.4 Report Structure............................................................................................................73.5 Report Format................................................................................................................73.6 Report CELL Format.......................................................................................................73.7 Validation Procedures....................................................................................................8

3. Migration Guidelines...........................................................................................................6

4. Security and Access Control................................................................................................6


1. Executive Summary

1.1 Purpose: The purpose of this document is to make the practitioners aware of the standards and best practices that can be followed while working with SAP Business Objects tools.Standards and best practices play an important role in maintaining consistent quality across all deliverables for an engagement.Abiding by these standards is required for development work to be transported to the quality assurance and production environments. Failing to adhere to it might result in the loss of development work during an upgrade.

1.2 Scope: The scope of this document entails all tools offered within SAP Business Objects BOXI 3.1 and 4.0. This includes Web Intelligences/InfoView, Universe Designer and Desktop Intelligence (minimal standards).The actual ‘how to’ develop logic/reports, and so on, will not be covered in detail in this document.

1.3 Audience:This document can be put to use by all the practitioners working on SAP Business Objects projects within Deloitte US/USI WellPoint engagement. In general, there are many generic guidelines and standards mentioned which can be used for generic assignments on SAP Business Objects.It is highly recommended that the technical and reporting team familiarize themselves with the content of this document. The target audience largely includes:

Report Developers Web Intelligence End Users Business Intelligence Contractors Business Objects Super Users Business Analysts


2. Universe Designer/IDT

2.1 Connection

When using a repository, always define a SECURED Connection to the Database. Use the Universe Property panel to define the Universe Use and Version (last update). Define the Connection Name that helps for Easy Database Identification. Parameters - SQL Tab - Multiple SQL statements for each measure to be unchecked. Parameters - SQL Tab - Multiple SQL statements for each context to be checked. Parameters - SQL Tab - Cartesian Products - Prevent is checked. Set “ANSI92 = Yes” in the parameters tab. This makes the universe compatible with any

database server and simplifies the migration between various databases if required in future.

2.2 Class Define Universe Classes / Subclasses as per the business logic & Naming Convention. Involve the business users in defining the class’s hierarchy and business names for the

classes and objects. AVOID Auto Class generation in the Designer. Give description for the use of each Class/Subclass. Avoid deep level of subclasses as it reduces the navigability and usability.

2.3 Objects Object to be used in calculation HAS to be Measure Objects. Object to be used in Analysis HAS to be Dimension Objects. Give description for the use of each Object. Include an (E.g.) In the description for Objects used in LOV. Do not set LOV Option for each Dimension. Use it only for required Objects, esp. those

to be used in Report Prompts. Keep "Automatic Refresh before Use" option clicked for LOV Objects:

o Keep “Export with Universe” option clicked for LOV objects used in the parameters.


If LOV is editable by the user, provide a significant name to List Name under object properties.

All measure objects should include aggregation functions for projection. Otherwise the generated SQL would not have the GROUP BY clause and a query could bring potentially thousands if not millions detailed records into a report.

Avoid having duplicate Object names (in different classes). Format for objects of type Numeric, Currency & Date should be defined. It is recommended to build the conditions on dates at universe level rather than at the

query panel.

2.4 Predefined Conditions Give description for the use of each pre-defined condition. If Condition is resulting in a prompt, make sure associated Dimension Object has LOV. Time dimension related predefined conditions such as Current year, Current month,

Previous year, Last (x) weeks, etc. can be defined to make it easy for scheduling daily/weekly/period based reports.

2.5 Tables Alias Tables should be named with proper functional use. Arrange the tables in the Structure as per Business/Functional logic. This helps other

Universe users in understanding. It is always best to bring the tables without joins and build them manually. It helps the

designer to understand the intricacies of the model. Avoid using Derived tables in the universe. They reduce the flexibility of generating ad-

hoc reports. If used, try to use them independently without joining to other tables. Joining a derived table to other tables will affect the performance of the overall query.

Always name a derived table appropriately with context to its functionality and use.

2.6 Joins & Context AVOID keeping hanging (not joined) tables in the structure. If at least 1 context is defined in the universe, then AVOID having joins that are not part

of any context. Give proper functional naming to the context for easy identification. AVOID having 1:1 joins.

2.7 Import/Export


Make sure of the path for Import, which usually is always in the Business Objects' Universe folder.

LOCK the universe if Administrator/Designer does not want any user to Import/Export. DO "Integrity Check" before Exporting the Universe.

3. Webi Reporting Standard Guidelines:

3.1 General Information Give meaningful names for the report tabs. For complex reports, keep overview report tabs explaining the report. Use the Report properties to give more information about the report. Data within each column can be centered, left justified, or right justified accordingly.

This should be determined based on the data displayed within each column. For example, name & address fields should be left justified, policy number & group numbers should be centered, and policy counts or annual premium should be right justified.

Section headers should be left justified. Report subtotals should be right justified. Report totals should be right justified; the background color should be set to

White/light gray. Report background color should remain the default white. When saving reports, the saved name should match the report title & include a

detailed report description. Page Footer – should contain the date the report was last refreshed, report user’s e-

number (if required), and page numbers. Uncheck the – associated LOVs for date objects in Universe to avoid pre-population of

date values in the prompts.

3.2 Data providers Each Data provider should be given a name that reflects the usage of the data it is going

to fetch. Avoid unchecking the option “Retrieve Duplicate Records” in the query options. This will

include the DISTINCT keyword in the query which may degrade the performance. Select Objects in such a fashion that the resulting SQL gives a hierarchical order of

Tables. This helps to achieve SQL Optimization. Avoid bringing lot of data into the report which will unnecessarily slow down the report

performance.


Avoid using report level filters. Instead use Universe level filters which can increase the re-usability of the filters.

If an optional filter is defined, the name of the filter should include “(Optional)” at the end. E.g. Diagnosis (Optional).

3.3 Report Variables Follow the naming convention of "var_" as prefix to each report level variable. This helps

to identify Report Variables different from Universe Objects. Have a brief description of the variable usage in the variable comments. Each variable that carries a calculation involving division should have IF <Denominator>

<> 0 THEN <Object>. This avoids display of #DIV/0 errors in the report. Avoid having deep nested calculations which will slow down the performance of the

report.

3.4 Report Structure Make use of Report Templates when having most of the report with similar structures.

This makes the work to move faster and consistent across.

3.5 Report Formats For all the printable reports, the page layout should be set in a printable manner.

(Landscape/Portrait, Fit in 1 page wide or/and 1 page tall are different options). All the reports should have page numbers in the footer. All the reports should have Last Refreshed Timestamp in the header or footer. All the above can be standardized by using templates. Wrap report titles and column headers as needed. Add summations to the reports as needed (i.e., Sum, Count, Average, etc.). Whenever possible, use graphs to represent data and enhance your reports.

3.6 Report CELL Formats All Numeric should be given Number format as per the language Eg. For German #.##00

for English #,##00. Number cells should have a Right Alignment while Text cells should have Left Alignment. Cell showing Percentage should carry the % text (either Column Header or in each cell). Indenting should ALWAYS be done using the Indenting Tool and NOT by using " ".


3.7 Validation Procedures Any Business Objects Web Intelligence reports that need to reside in the Public Folders

must be peer reviewed and approved by members of the Business Intelligence Team. Make sure all reports reflect a meaningful business name; the report name should

provide reference to the data being presented in the report. For review purposes, Business Objects Web Intelligence Reports will need to be sent to

one of the BI Team Administrator’s Business Objects Inbox to review the reports. Reports will be reviewed for formatting accuracy as well as spelling accuracy. Changes or corrections to any reports will be documented and communicated back to

the report developer(s) for modification. Ensure all reports and/or graphs run properly within the development application.


5. Business Objects Migration Guidelines:

a. If you import a reports without import dependent universes, and thoseUniverses do not already exist on the destination environment, the reportswill lose the relationship with the universes and will not run properly onthe destination environment.

b. If you import a report that has rights set on it for users and groups, andyou want to import the object rights on the report, you must either importthose users and groups or ensure that the users and groups already existon the destination environment.

c. If you are importing a report that relies on a server group or an event thatalready exists on the destination, do not overwrite the server group orevent. On the "Select objects to import" screen, do not select the servergroup or event.

d. If you're importing server groups or events, the Import Wizard does notallow you to import specific objects. You must import all events or servergroups, or none of them. If you've modified an event or server group onthe source environment, and only want to import that one object, deletethe object from the destination environment, and then ensure that youclear the Overwrite object contents on the "Incremental import" screen.This ensures that the modified server group or event is the only one thatis imported.


1. Select the Source Environment

The first step in using the Import Wizard to migrate content is to specify an existing source environment and to enter logon credentials with administrator rights

Source systems can include content from the following types of environments:

BusinessObjects Enterprise 5.x BusinessObjects Enterprise 6.x BusinessObjects Enterprise XI BusinessObjects Enterprise XI R2 BusinessObjects Enterprise XI 3.1 Crystal Enterprise 9 Crystal Enterprise 10 Business Intelligence Archive File (BIAR) File Text File

In addition you can use the following authentication modes to log on to the source system:

Enterprise Lightweight Directory Access Protocol SAP Windows Active Directory Windows NT

2. Select the Destination Environment

The second step in using the Import Wizard to migrate content is to specify an existing destination environment and to enter logon credentials with administrator rights

The destination environment selection is similar to the source environment selection as you can select the same types of environments and authentication methods. The main difference is the destination environment selection includes the target of the migration rather than the source of the migration.

3. Select the Types of Objects to Migrate

The third step in using the Import Wizard to migrate content is to specify the types of objects to be migrated from the source environment to the destination environment

Types of objects that can be selected to be migrated include:


Users and user groups (including all sub-options). When you select Import users and user groups, five additional selections are automatically selected as well. You have the option of unselecting the following sub-options:

- Inbox documents

- Personal categories

- Favorite folders

- Application rights

- Root folder rights

Corporate categories. Corporate categories provide an alternate way to classify public documents in addition to public folders. They enable users to locate information more easily regardless of where the information is stored within the BusinessObjects system. Subsequently corporate categories and public folders allow for public documents to be organized according to multiple types of criteria and can add additional level of security on the document.

Folders and objects (including all sub-options). You have the option of unselecting these sub-options:

- Discussions associated with selected reports

- Application folders and options

Events Server groups Repository objects Calendars Universes Profiles Encyclopedia objects, which are reference guides for documents (reports and

queries). Encyclopedias include a panel that explains the purpose of a document, what questions it helps answer, how it is best used, and a glossary of synonyms and definitions used in the document.

Custom access levels Remote connections and replication jobs

4. Select an Import Scenario

The fourth step in using the Import Wizard to migrate content is to specify the scenario for importing content into the destination environment. The scenario specifies how to determine whether an object already exists in the destination system and what to do with the object if it already exists.

There are two ways to determine if an object already exists in a destination system, plus three sub-options for each main option if the object does already exist within the destination.


The first method to use the object’s unique identifier. BusinessObjects uses the cluster unique identifier (CUID) as the key to identify universes or reports within the same cluster or environment (development, testing, and production). The CUID is a 24-bit key that the system automatically generates when the universe or report is first exported to the BusinessObjects repository. It is only used by the system and is not viewable to an administrator or user. The CUID may be in a different deployment environment (e.g., development, staging, or production).

Update the destination object. In the case of name conflict, rename the source object.

Update the destination object. In case of name conflict, do not import the source object.

Do not import the source object.

The second method is to use the object’s name and path:

Keep the destination object and import a renamed copy of the source object Update or overwrite the destination object with the source objects Do not import the source object

Best practice: The option Use the object’s name and path and the sub-option Update the destination object is the most commonly used import scenario. That is because it is the only option that allows for destination objects to be overwritten by corresponding source objects and it allows the object to keep the same name.

Best practice: Matching objects by name and path is only supported for the following object types:

Folders and objects under public folders and private folders Corporate categories Universes Universe connections Dashboards Profiles Schedules

All other object types use the matching by the unique identifier scenario.

Best practice: Matching objects by name and path is not an option when importing content from a BIAR file. When importing from a BIAR file, objects are imported using the unique identifier scenario.

5. Select Incremental Import Options

The fifth step in using the Import Wizard to migrate content is to determine incremental import options that specify the types of objects whose source contents will overwrite the corresponding destination contents if the destination object already exists (Figure 5). Options for overwriting destination content with source content include:


Overwrite object contents Overwrite universe contents Overwrite connection contents Overwrite group and user membership Overwrite object rights

Best practice: When determining incremental options, the options Overwrite object contents and Overwrite universe contents are the ones that are most often chosen. They allow destination content to be overwritten without changing any security setting or environment database connection settings.

Best practice: The option Overwrite connection contents should rarely be chosen as it forces a change to the database connection that the corresponding universe is using and could change the source of data for the universe. Most of the time, it is wise to keep the current connection that the universe is already using in the destination environment.

Best practice: The options Overwrite group and user membership and Overwrite object rights should only be selected if security settings including group membership and object right settings were made in the source system and need to be propagated to the destination environment.

6. Select the Specific Objects to Migrate

The sixth step in using the Import Wizard to migrate content is to determine the specific objects to be migrated from source to destination. A unique screen type for selection of content appears corresponding to the choices selected in the Selection of Objects to Import step.

Select Users and Groups

If users and groups have been chosen to be imported then a User’s and groups selection screen appears

An administrator then checks the users and groups to be migrated from the source environment to the destination environment by clicking the check boxes next to the users and groups. The administrator has the option of viewing the groups hierarchically or alphabetically by checking or un-checking the Show groups hierarchically check box. Additionally the administrator has the option of automatically selecting groups that contain selected users by checking the Select groups that contains selected users check box.

Select Universes

If universes have been chosen to be imported then an Import options for universes and connections option screen appears.

When migrating universes, an administrator has to pick from one of three import options for universe objects:

Import all universes and all connection objects Import all universes and only connection objects used by these universes


Import universes and connections from the selected documents or select additional universes that are not used by any imported document

Best practice: The third option is the one that should be chosen almost all the time as it allows the administrator to manually pick the universes to be migrated. The universe choices appear on the next screen. The other two options should only be used if all universes need to be migrated at the same time.

Additionally, the administrator has the option to migrate universe overloads with the universe chosen in the previous option. Universe overloads are security and row restrictions included in a universe that generate SQL that are applied above and beyond the SQL generated by the universe itself. This option should be chosen when the source universe does include overloads. Those overloads need to be migrated and will overwrite the destination universe overloads.

7. Finalize the Migration

After an administrator has selected all the migration options for BusinessObjects content, the Ready to import screen.

At this point, an administrator should review the displayed list to verify that it contains the selected content from previous screens. If not, the administrator should click the Back button and navigate to the appropriate previous screen to make the corrections on that particular screen. When the content is verified, the administrator should click the Finish button to begin migration of the content to the destination environment. The Import progress screen then appears showing the progress of the import and a summary of the migration events. Once the migration is complete, the import summary screen appears, displaying the results of the migration

Best practice: Upon completion of the migration, an administrator should view and confirm the content in the detail log. This can be performed by clicking the View Detail Log button. The Detail Log provides a summary of the content that has been migrated and allows an administrator to verify the success of the migration. In addition, the Detail Log includes a listing of the migrated objects, their status, and any migration errors that may have occurred.

Best practice: The information that appears in the Detail Log screen also appears and is written to a log file. The log file starts with the name ImportWiz, and is typically located in the C:\Program Files\BusinessObjects\BusinessObjects Enterprise\12.0\Logging directory on the server or client machine that is running the import wizard. The log file contains a system-generated ID, a title that describes the imported information, and a description of the action taken by the Import Wizard.


4. Security and Access Control Guidelines:

Keep these considerations in mind for security and access control:

a. Use access levels wherever possible. These predefined sets of rightssimplify administration by grouping together rights associated with commonuser needs.

b. Set rights and access levels on top-level folders. Enabling inheritancewill allow these rights to be passed down through the system with minimaladministrative intervention.

c. Avoid breaking inheritance whenever possible. By doing so, you canreduce the amount of time it takes to secure the content that you haveadded to BusinessObjects Enterprise.

d. Set appropriate rights for users and groups at the folder level, then publishobjects to that folder. By default, users or groups who have rights to afolder will inherit the same rights for any object that you subsequentlypublish to that folder.

e. Organize users into user groups, assign access levels and rights to theentire group, and assign access levels and rights to specific memberswhen necessary.

f. Create individual administrator accounts for each administrator in thesystem and add them to the Administrators group to improve accountabilityfor system changes.

g. By default, the Everyone group is granted very limited rights to top-levelfolders in BusinessObjects Enterprise. After installation, it is recommendedthat you review the rights of Everyone group members and assign security accordingly.


Documents

SAP Business Objects Best Practicesv2