Universes and Deployment


In order for a universe to be utilized by others, it needs to be published as a resource in the CMS. The Designer module will export the universe, meaning it will export the .unv file from the desktop to the CMS, where it is stored in a folder for distribution. From here, other Designers can download the universe or import it to their desktop. Likewise, the Business Objects Enterprise infrastructure can access it for use with the Web Intelligence and Crystal Reports reporting engines. The universe is automatically downloaded to the Business Objects Enterprise infrastructure when the first user requests usage of the universe. It is cached on the Web Intelligence server to avoid having to retrieve it from the InfoStore for every successive user request.

Semantic Layer Overrides

After the universe is an InfoObject in the InfoStore, data security overrides can be applied to the semantic layer. The idea behind these overrides is to supply a semantic layer that provides access to the database in general, but can also restrict the access based on user or group profiles. Because the universe is designed for ad-hoc usage, the user should be prevented from asking any questions he should not be able to ask. And because a user's questions cannot be known prior to asking them, the security restrictions need to be applied to the semantic layer for that user. The semantic layer applies these security overrides when appropriate during SQL generation.

The most common semantic layer override is row restriction. This is accomplished by forcing WHERE clause usage within the universe. For example, say Joe belongs to the Eastern sales region, and Joe should only be able to see data from his region. Because you cannot predict what queries Joe will ask ahead of time, you want to ensure that any SQL he generates will have a restriction added, limiting him to Eastern region data only. In SQL this might appear as WHERE Org.Region = 'East'. With this clause applied, whenever Joe creates an ad-hoc query, he will be limited to only Eastern region data. If you wanted to limit a group of Eastern region users to the same data, you could apply the WHERE clause restriction to a group and place all users within the group, where they would inherit the override.

Other semantic layer overrides are

  • Object hiding Restricts users from seeing certain objects (column-level security).

  • Table swapping Substitutes one table in the database for one defined within the universe. An example of this would be if a DBA created a restricted view of a fact table (maybe limiting it to only Eastern region data). The DBA wants a certain user, Joe, to use this particular database view in place of the normal fact table as defined in the universe.

  • Connection swapping Substitutes a different connection string to a different database. This assumes that there are two databases with the exact same table structures as represented in the universe. The different databases exist to segregate data in some waysay, one database contains Eastern region data only.

Note that the same example is used here to illustrate a point. With the exception of object hiding, the other three restrictions perform the same functionlimiting the user to a certain set of data. However, DBAs often employ different techniques to achieve this result. Business Objects can handle it one way by applying WHERE clause restrictions. If the DBA decides to use database views to limit the data, table swapping is used to assign the views. If the DBA puts the data in a separate physical database, connection swapping is used. There are additional methods for limiting users to certain records, such as a security lookup table. Security lookup tables, along with other methods, are also accomplished by employing semantic layer overrides. The four mentioned previously are the most common and have been built into the universe for about a decade.

Restriction Sets

Semantic layer overrides are applied via the Designer and are called restriction sets. A restriction set contains one or more semantic layer overrides bundled into a single administrative entity. For example, suppose that you want to restrict certain objects in a universe, swap a table for a view, add a WHERE clause restriction, and limit the number of rows returned to 50,000. This can all be defined within a single restriction set. The restriction set is then applied to particular users or groups defined via the CMS. In this case, all overrides apply to the users or groups to which they are assigned.

To recap the overrides available for inclusion in a restriction set, see Table 18.2.

Table 18.2. Overrides for Restriction Sets

Override

Definition

Connection

Changing from the default connection to an alternative one. A prerequisite here is that both databases contain the tables/views defined in the universe. The assumption is that the data has been segregated in some fashion.

Query controls

There are three controls: number of rows allowed to return, limit of execution time, and limit of long text objects. These do not eliminate the SQL from running; rather, they are designed to protect the report engine from overloading due to bad queries (not to protect the RDBMS from receiving bad SQL).

SQL generation options

There are five options: allow use of union, minus intersect; multiple SQL statements for each context; multiple SQL statements for each measure; allow selection of multiple contexts; prevent/warn Cartesian products. This control is meant to restrict the generation of poor SQL. It is intended, along with the model design, to protect the database from poor query requests.

Object access

This hides selected objects from the user/group. By default, users can see all objects in a universe unless some restriction is explicitly placed on the objects.

Row access

This limits queries by applying WHERE clauses to the SQL for a particular user/group. This is the most commonly used semantic layer override.

Alternative table access

This replaces a table defined within the universe with a substitute for all queries run by the user/group that use objects calling for this table.


Restriction sets are created by selecting Tools, Edit Security Restrictions and choosing the New button.

Figure 18.5 shows the Edit Restriction Set dialog. The six tabs correspond with the six overrides listed in the preceding table. The Objects tab is highlighted in the figure, showing that the Discount object from the Measures class is restricted and will be hidden from all to whom this restriction set is applied. The restriction set can combine restrictions from all six override types.

Figure 18.5. Designer with Edit Restriction Set dialog open.


After the overrides have been set and the OK button is selected, the restriction set shows up in the list of available restrictions. Clicking OK saves the restriction set.

Applying Restriction Sets

To apply the restriction set to a particular user or group, select Tools, Apply Security Restrictions and choose the Select Users/Groups button. This shows the available users/groups as defined via the Central Management Console (CMC). The window allows for searches through the InfoStore to aid in managing the list in large deployments.

After the user or group is selected, the user or group is available to apply to a restriction set. This is achieved by clicking on the user or group to highlight it. After it's highlighted, you click on the restriction set drop-down menu, select the restriction set you want to apply, and click on the Apply button.

Multiple Restriction Sets

Because multiple groups can house the same users, it is possible for a user to have more than one restriction set applied to her. If a user belongs to more than one group, the order of restriction sets can be prioritized. Sometimes contrary to expectation, the restriction set with the highest priority number is the dominant one. For example, suppose that there are two groups, Sales Management and Sales Field, and both have restrictions limiting row return, with Sales Management limited to 50,000 rows and Sales Field to 20,000 rows. If Sales Management is priority 1 and Sales Field is priority 2, for those users who are in both groups, the priority 2 would apply. (you might think priority 1 would win, but it's the highest number of all restrictions possible). If a user has individual overrides applied through one restriction set and is also a member of a group, the overrides are cumulative. For example, if Joe is limited to the Eastern region only via a WHERE clause restriction and he is in the Sales Field group, he will also be limited to 20,000 rows.

Some restrictions have to be managed by priority because they cannot cumulate, such as connection information (the user must clearly have one and only one connection defined). The other two restrictions that have priority applied are table swapping and query and SQL controls. The other restriction types can accumulate (object access and row access).

Caution

It is possible to define a restriction for a user that conflicts with the group. For example, say you define a restriction set for Joe for Org.Region = `East`;. You then put Joe in a group called Central, which has a restriction set containing the restriction Org.region = `Central`. In this case, Joe will apply both of these WHERE clauses to the SQL generated. Because there is no row that can be both in the East region and Central region at the same time, Joe will get no results returned. It is best practice to apply overrides at the lowest level possible and to use the Preview Security Restrictions command in the Designer to show the cumulative effect of restrictions on individual users.


Universe Changes

Sometimes after a universe is deployed and users begin using it, you might find that an object definition is incorrect and needs to be rectified. Or perhaps you discover the necessity for an aggregate table, create one, and make your universe aggregate aware. Or you find out the DBA made a change to one of your underlying tables and accidentally renamed some of your column names. You corrected the universe, and want all of your users to start using the new version.

However, you have many users who have developed reports (either Web Intelligence or Crystal) off of the universe currently in use. You know the SQL statements they are using are either not optimal or incorrect. How do you get all the existing reports updated with the new semantic definitions?

This capability is built in to the Business Objects Enterprise framework. When a new universe is placed in the InfoStore to replace the existing one, the report engines will detect that a newer version of the semantic layer exists, and will fetch it from the InfoStore. It will then be used to dynamically regenerate the SQL statements at execution time. The reports pick up the new object definitions and new SQL, if applicable. It will be done automatically the next time the report is run. So, if a user pulls a report out of his Favorites and executes it, the SQL will automatically regenerate with the new universe object definitions. If a user had a report scheduled for refresh every week, the report would generate new SQL at the next scheduled refresh. This holds true for both Crystal and Web Intelligence reports.

In version 10 of Crystal Reports, with the Business Objects Crystal Integration Pack, the universe could be used to generate SQL for Crystal Reports, but it would not dynamically update as the universe changed. However, in Business Objects XI, Crystal Reports will regenerate SQL when the universe changes. This is an important change to note.

The reason the SQL should regenerate is simplesecurity. Users often move from department to department or are promoted to a new job which might have less restrictive data access. After the appropriate semantic layer overrides have been made, all reports used by that user will pick up the new restrictions automatically. It's just part of a Business Intelligence system.

Any instances the user might have run historically will have results based on the old semantic layer overrides. After the SQL is executed, the data retrieved, and the document stored as a report instance, the data is static. Changes to the semantic layer will not rerun historical instances. You can see why this would be impossible given the fact that the underlying data is changing constantly. Therefore, semantic layer changes will modify any SQL generated from the point in time that the new universe is in the CMSuntil the next semantic layer change, of course.




Crystal Reports XI(c) Official Guide
Crystal Reports XI Official Guide
ISBN: 0672329174
EAN: 2147483647
Year: N/A
Pages: 365

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