11 Defining Business Areas for Visualizations

This section contains information on the following topics:

About Visualizations

The Oracle Life Sciences Data Hub (Oracle LSH) is integrated with visualization tools, to allow nontechnical users to quickly create onscreen graphical and tabular displays and interactive dashboards of Oracle LSH data. Any Oracle LSH data can be made available for this purpose—freshly loaded source data or merged and transformed data.

You make data available to the visualization tool by defining one or more Business Areas in Oracle LSH. You define Table Descriptors in a Business Area and map them to Table instances. The visualization tool can read data contained in the Table instances to which the Table Descriptors are mapped. An Oracle LSH Business Area corresponds to an Oracle Business Intelligence Enterprise Edition (OBIEE) Repository and a particular visualization can see data through a single Business Area. Your company may support other visualization tools and an Oracle LSH Business Area of that type may correspond to an element in those visualization tools.

You can also define Joins between the Table Descriptors and Hierarchies (drill-down structures) of Columns in the same Table Descriptor or in joined Table Descriptors. Joins and Hierarchies help determine how visualizations can compare and organize data; see Defining Joins and Defining Business Area Hierarchies.

When you launch a Visualization tool from a Business Area or from the Visualizations subtab of the Reports tab, you can choose to see non-current and blinded data, if you have the appropriate privileges, through the Launch Settings screen. If you open OBIEE directly (not from within Oracle LSH) you can view only current and not blinded data regardless of your privileges.

Reports on Business Area Definitions and Instances: From the Actions drop-down list, you can generate reports that provide information on a Business Area definition or instance; see System Reports for information.

Creating a Business Area

When you create a Business Area in a Work Area, you are actually creating an instance of a Business Area definition.

Figure 11-1 Process of Creating a Business Area Definition and Instance

Description of Figure 11-1 follows
Description of "Figure 11-1 Process of Creating a Business Area Definition and Instance"

To create a new Business Area instance:

  1. In a Work Area, select Business Area from the Add drop-down list.
  2. Click Go.

    The system displays the Create Business Area screen.

  3. Choose one of the following options:
    • Create a new Business Area definition and instance. Choose this option if no Business Area definition exists that can meet your needs, either as it is or with some modification.

    • Create an instance from an existing Business Area definition. Choose this option if a Business Area definition already exists that meets your needs.

      If you can adapt an existing Business Area definition to make it fit your needs, first copy it into the current Application Area, then choose this option and select the copied definition. See Finding an Appropriate Definition and Reusing Existing Definitions for further information.

  4. Depending on your choice, follow one of the following sets of instructions:

Creating a New Business Area Definition and Instance

When you select Create a new Business Area definition and instance in the Create Business Area screen, additional fields appear.

  1. Enter values in the following fields:
  2. In the Classification section, select the following for both the definition and the instance:
  3. Click Apply to save your work and continue defining the Business Area.

    The system opens the Properties screen for the new Business Area instance.

  4. Define the Business Area details. For information and instructions see:

    Note:

    A Generic Visualization Business Area does not contain Joins, Hierarchies, Source Code, or Parameters.

  5. Click Check In. The system checks in Version 1 of both the Business Area definition and instance.
  6. Install the Business Area instance (see Using, Installing, and Cloning Work Areas). On creation of the Generic Visualization Business Area, its status is 'Not Installable'.

    Note:

    When installing a GVA Business Area instance, a database schema is created. The schema name is an attribute of the Generic Visualization Business Area instance and its default value is the Business Area instance name. The schema name must be unique within the Oracle LSH installation. If the name is not unique, Namings' uniqueness rule appends _n to the schema name; where n is the next non-unique integer. If a schema name is not unique, the installation fails.

  7. Validate both the definition and the instance according to your company's policies.

Creating an Instance of an Existing Business Area Definition

If you use an existing Business Area as a definition source, its Table Descriptors, Joins and Hierarchies (if any) are already defined. See Creating an Instance of an Existing Definition for instructions.

After you have created the Business Area instance, you must map the Table Descriptors to Table instances; see Mapping Table Descriptors to Table Instances for instructions.

Using the Business Area Properties Screen

If you are working in a Work Area, you see the properties of both the Business Area instance and the Business Area definition it references. If you are working directly on the definition in an Application Area or Domain, you see only the properties of the definition.

See Modifying Business Areas for information on modifying Business Areas.

See also Figure 11-1.

This section contains the following topics:

Instance Properties

You can see the following instance properties:

  • Name: You can click Update and modify the name. See Naming Objects for further information.

  • Description: You can click Update and modify the description. See Creating and Using Object Descriptions for further information.

  • Definition: This field specifies the Business Area definition to which this Business Area instance points.

    You can upgrade to a new version of the same definition. See Upgrading to a Different Definition Version from an Instance.

  • Validation Status: This field displays the current validation status of the Business Area instance. If you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. See Validating Objects and Outputs for further information.

  • Status: This field displays the installable status of the Business Area: Installable or Non Installable. See Installation Requirements for Each Object Type.

  • Version: This field displays the current version number of the Business Area instance.

  • Version Label: This field displays the version label, if any, for the current Business Area instance version.

  • Schema Name: (Generic Visualization Business Areas) The unique name of the schema created for the Business Area.

  • Default Blinding Access Type: (Generic Visualization Business Areas) The data displayed by default in visualizations based on this Business Area.

  • Default Snapshot Label: (Generic Visualization Business Areas) The data currency displayed by default in visualizations based on this Business Area.

    For further information on object versions, see Understanding Object Versions and Checkin/Checkout.

Definition Properties

  • Checked Out Status: This field displays the status of the definition: either Checked Out or Checked In. You must check out the definition to modify Table Descriptors, Joins, and Business Area Hierarchies. However, you can change Table Descriptor mappings without checking out the definition. See Understanding Object Versions and Checkin/Checkout for further information.

  • Latest Version: If set to Yes, this Business Area instance is pointing to the latest version of the Business Area definition. If set to No, this Business Area instance is pointing to an older version of the Business Area definition.

  • Checked Out By: This field displays the username of the person who has the Business Area definition checked out. See Understanding Object Versions and Checkin/Checkout for further information.

  • Version Label: This field displays the version label, if any, for this definition version.

  • Business Area/Adapter Type: This field displays the name of the Business Area adapter.

  • Validation Status: This field displays the current validation status of the Business Area definition. If you are working directly in the definition in an Application Area or Domain and you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. If you are working in an instance of the Business Area in a Work Area, and you want to change the validation status of the definition, you must go to the definition. See Validating Objects and Outputs for further information.

  • Status: This field displays the installable status of the Business Area: Installable or Non Installable. See Installation Requirements for Each Object Type.

    Note:

    When a Generic Visualization Business Area Definition is created, its status is 'Not Installable'.

Business Area Attributes

This section of the Business Area screen displays attributes for the type of Business Area you have created. See Setting Business Area Attributes and Parameters for more information.

Buttons

From a Business Area instance in a Work Area, you can use the following buttons:

  • Install: Click Install to install the Business Area instance, including mapped Table instances in the same Work Area; see Installing Business Area Instances. For a list of reasons a Business Area instance may not be installable, see Installation Requirements for Each Object Type.

  • Launch Visualization: Click Launch Visualization to go to the Launch Visualization screen; see Launching Visualizations. You can see the Launch Visualization button only after you have installed the Business Area. See Installing Business Area Instances.

  • Update: Click Update to modify the Business Area instance properties. See Modifying Business Area Instance Properties.

  • Check In/Out and Uncheck: Click these buttons to check out, check in, or uncheck the Business Area definition. Different buttons are displayed in the Business Area Definition Properties section depending on the Checked Out Status and whether or not you are the person who has the definition checked out. If someone else has checked out the definition, you cannot check it in or uncheck it. The username of the person who has checked it out is displayed. See Understanding Object Versions and Checkin/Checkout.

Defining Table Descriptors

You make data available to visualizations by mapping the Table instances that contain the data to Table Descriptors in a Business Area. Any one visualization can access data through one and only one Business Area. The more Table Descriptors you include in a Business Area, the more data is accessible to a single visualization.

However, system performance during visualization creation improves by having fewer Table Descriptors in the Business Area. Therefore, you may want to define more Business Areas with many different combinations of Table Descriptors.

Business Areas have source Table Descriptors only. They can read data but they cannot write data to Tables instances.

If you do not want data from a particular Table instance Column available to visualizations, remove the Column from the Table Descriptor that is mapped to that Table instance.

You can map Business Area Table Descriptors to Table instances in any Work Area.

If the Table instances to which you want to map a Business Area's Table Descriptors already exist, the simplest way to add and map Table Descriptors to the Business Area is to use the Table Descriptors from Existing Table Instances job from the Actions drop-down list. See Creating Table Descriptors from Table Instances and Simultaneously Mapping Them for further information.

Note:

Set the SAS Library Name of the source Table Descriptor to $REPINIT if you want to enable queries from the OBIEE repository's Repository Init Block to access Table instances mapped to this Table Descriptor. These queries fetch data from the Oracle LSH Table instances at user-defined refresh intervals to initialize Repository Variables.

If you do not set the SAS Library Name to $REPINIT, OBIEE cannot access the mapped Table instances and the automatic, periodic OBIEE repository queries will fail.

For additional information about Table Descriptors see the following sections:

Defining Joins

You can define a Join between two Table Descriptors to allow a visualization to query and display data from two Table instances as if they were one unified table.

Note:

Joins are not supported in Generic Visualization Business Areas.

You must define Table Descriptors before you can define Joins between them. You can create Joins between two and only two Table Descriptors.

You can define a Join between Table Descriptor A and Table Descriptor B, another Join between Table Descriptors B and C, and another between Table Descriptors C and D, for example. Furthermore, in this same example you can create a join between Table Descriptors D and A.

However, if you create a Join between Table Descriptor A and Table Descriptor B, you cannot create a Join between the same Table Descriptors with their positions reversed (Table Descriptor B and Table Descriptor A).

Joined Columns: For each Join, you must specify at least one pair of equivalent Columns, one Column from each Table Descriptor, that are equivalent in terms of their data content; for example, Table A's Patient Column and Table B's Pat Column, both of which contain the patient ID. The joined Columns must be of the same data type.

Note:

For Business Areas of type OBIEE, joins work only if Table instances have a Primary Key constraint.

Also, OBIEE Business Areas support only one-to-many relationships; for example, if you want to create a join between an employee table and a department table, you must add the department table to the Join first, because a department can have multiple employees in it, but an employee can belong to only one department.

If you specify more than one pair of equivalent Columns, the system sees rows in the two Table instances as being the same only if they have the same value in both Columns. For example, if you create a Column Join between Table A's Investigator Column and Table B's Inv Column, both of which contained an investigator ID, as well as the Patient/Pat join, the visualization query would see rows as being the same in the two Table instances only if they shared the same investigator ID as well as the same Patient ID.

Note:

Although some visualization tools allow the use of other operators to join columns, Oracle LSH always applies the "equal to" (=) operator.

Inner and Outer Joins: By default, an Oracle LSH Join is an inner join. That is, only rows where the joined Columns share the same value are evaluated for the query. Rows that exist in either Table instance that do not have an equivalent row in the other Table instance are not included in the visualization.

You have the option to create an outer join. In an outer join, the visualization query evaluates all the rows in the Table instance you define as Table A plus all the rows in Table B where each joined Column has the same value as a row in Table A.

Defining a Join at the Table Level

To define an Oracle LSH Join:

  1. From the Joins subtab on the Properties screen of the Business Area, click Add. The system displays the Join for Business Area screen.
  2. Enter a name for the Join.
  3. Enter a description for the Join (optional).
  4. Click the Search icon to the right of the Table A field.
  5. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  6. Click the Quick Select icon to select the Table Descriptor you want.

    Note:

    In an outer join, the system evaluates all the rows of the Table instance you map to the Table Descriptor you define as Table A.

  7. If you want to define an outer join, select Yes in the Table A Outer Join field.
  8. Click the Search icon to the right of the Table B field.
  9. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  10. Click the Quick Select icon to select the Table Descriptor you want.
  11. Click Apply. See Defining a Join at the Column Level.

Defining a Join at the Column Level

To define which two Columns are joined, do the following:

  1. Define the Table Descriptors in the Join; see Defining a Join at the Table Level.
  2. In the Join properties screen, click Update. The system displays an Add Join Column button.
  3. Click Add Join Column. The system displays a drop-down list under each Table Descriptor included in the Join.
  4. For the Table Descriptor on the left, select the Column you want to define as part of the Column Join from the drop-down list.
  5. For the Table Descriptor on the right, select the Column you want to define as part of the Column Join from the drop-down list.

    Note:

    The two Columns must have the same data type.

  6. Click Apply. The system saves your work.

    Click Return to go back to the main Business Area screen.

Defining Business Area Hierarchies

Many visualization tools allow drilling down into more and more detailed data or up into more and more general data. To allow this functionality for visualizations of Oracle LSH data, you must define Business Area Hierarchies.

Note:

Hierarchies are not supported in Generic Visualization Business Areas.

Business Area Hierarchies define hierarchical relations among Table Columns to organize data in a meaningful way, from general to specific, so that data values at the lower levels aggregate into the data values at higher levels.

For example, you could define a Hierarchy for the Columns Study, Patient, Visit, Test, in that order, from the most general to the most specific. The system uses the Hierarchy and the data values for each row to interpret the data values in the Columns hierarchically: all tests belong to a visit; all visits are associated with a patient, and all patients are part of a study.

If Table Descriptors are defined as joined, you can create a Business Area Hierarchy that includes Columns from both Table Descriptors. For example, you could create a Business Area Hierarchy for the Columns Investigator Name, Patient, and Gender where the Investigator Name is in the Sites Table and the Patient and Gender Columns are in the Demography Table.

When you define a Business Area Hierarchy, you assign each Column an order number. The Column with order number one is the top, or most general, level of the Business Area Hierarchy, and each subsequently numbered Column is the next lower Hierarchy level. Sequential Columns must be contained either in the same Table Descriptor or in joined Table Descriptors.

Grouping Columns

You can include two or more Columns in the same Business Area Hierarchy level by using the Group With Previous flag. For example, you could define the following Business Area Hierarchy:

The example above shows a three-level hierarchy. Investigator ID and Investigator Name are both in the top level, which makes sense because they are alternate values for the same type of information. Patient is the middle level and Gender is the bottom level. In a visualization, users can drill down from the investigator by either name or ID, or view them both, to all patients for whom a particular investigator is responsible, to an investigator's male patients or the same investigator's female patients.

To define a Business Area Hierarchy:

  1. From the Business Area Hierarchies subtab on the Properties screen of the Business Area, click Add. The system displays the Create Business Area Hierarchies screen.
  2. Enter a name for the Business Area Hierarchy (required).
  3. Enter a description for the Business Area Hierarchy (optional).
  4. Click Apply. The system displays the Properties screen of the new hierarchy.
  5. Click Update. The system adds the Add Another Row button.
  6. Click Add Another Row.
  7. Click the Search icon in the Table column. The system opens a Search and Select screen.
  8. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  9. Click the Quick Select icon to select the Table Descriptor that is mapped to the Table instance you want to include in the Hierarchy.
  10. Click the Search icon in the Column Name column. The system opens a Search and Select screen.
  11. Click Go to see a list of all the Columns in the Table Descriptor. Alternatively, enter the exact name of the Column you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Columns.

  12. Click the Quick Select icon to select the Column you want to include in the Hierarchy.
  13. Repeat Steps 6-12.

    This time the system displays only the Table Descriptor you selected in Step 9 and any other Table Descriptors that are part of a Join that includes the Table Descriptor you selected.

    In addition, beginning with the second row, you can choose to group the Column with the previous one at the same level of the Hierarchy; see Grouping Columns.

  14. When you have added all the rows you want in the Hierarchy, click Apply. the system saves your changes.

    Click Return to go back to the Business Area Properties screen.

Example 11-1 Business Area Hierarchy Column Grouping

Order number Column Group With Previous?

1

Investigator ID

2

Investigator Name

Yes

3

Patient

4

Gender

Understanding Business Area Source Code

In the context of an Oracle LSH Business Area, the Source Code object is used to store files required for integration with an external visualization tool. This is different from the way Source Code is used in Oracle LSH Programs where the Oracle LSH Source Code object contains actual program source code.

For information on OBIEE Business Area Source Code see About OBIEE Business Areas.

Note:

Source Code is not supported in Generic Visualization Business Areas.

Setting Business Area Attributes and Parameters

Some types of Business Areas, including third-party types not covered by this documentation, may have attributes and Parameters. When you create a Business Area of those types, attributes or Parameters required for the visualization tool may appear on the Business Area Properties page.

OBIEE Business Areas have one attribute; see Defining Oracle Business Intelligence Business Areas.

Defining Oracle Business Intelligence Business Areas

For information on using the OBIEE Administration Tool and Presentation Services to create visualizations—Answers and Dashboards—see the Oracle Business Intelligence documentation, including online help.

This section contains the following:

About OBIEE Business Areas

When you install an OBIEE Business Area for the first time the system generates an Oracle BI repository (.rpd) file—which is required for creating and displaying Subject Areas, Answers, and Dashboards in Oracle BI Presentation Services—and copies it to the BI Server. This generating .rpd allows the creation of visualizations of LSH data through OBIEE Answers without the use of the OBIEE Administration tool. Oracle LSH stores the .rpd file in the OBIEE Business Area Source Code definition.

The system deploys the .rpd files from all the OBIEE Business Areas that share the same OBIEE Service Location Name onto that Oracle BI Server and merges them into a single .rpd file as each Business Area is installed.

If you are using OBIEE 11g, each time you install an OBIEE Business Area you must open Oracle Enterprise Manager, manually deploy the merged, or master, .rpd file and restart the BI Service for the Business Area to become available to users; see Manually Deploying the Master RPD File. If you are using OBIEE 10g, this process is automatic each time you install the Business Area.

Customizing the RPD File Using OBIEE Administration Tool: Oracle LSH takes advantage of only a small number of the features that OBIEE has to offer. If you are experienced with OBIEE you may wish to make changes to the Business Area's default .rpd file using the OBIEE Administration Tool and upload the resultant .rpd to replace the system-generated .rpd in the Business Area in Oracle LSH.

In order to ensure that subsequent installations of the Business Area do not overwrite those customizations, the system tracks the origin of the .rpd file. When Oracle LSH creates an .rpd file during installation, it populates the File Reference Name with the value SYSTEM. When a user uploads a customized .rpd file the system populates the File Reference Name with the value USER.

Each time you install the Business Area, the system checks if the current .rpd file was generated by the system or manually uploaded to the Business Area. If the file was generated by Oracle LSH and not manually uploaded and the Table Descriptor, Join, or Hierarchy definitions have changed, then the system generates a new .rpd file and stores this as a new version of that Source Code.

If the current .rpd file was uploaded, the system does not override it with a new file even if you have made changes in Oracle LSH. You must make corresponding changes—adding, deleting, or modifying tables, joins, and hierarchies—in the Administration Tool and reupload the file.

Defining an OBIEE Business Area

Oracle recommends developing an OBIEE Business Area in the following order:

  1. Create the Business Area; see Creating a Business Area. Special information for OBIEE Business Areas:

    • Name. The Business Area name is displayed in OBIEE Answers as the Subject Area. The name must be unique among Business Areas using the same service location. If it is not unique, when you install the Business Area you receive an error message with the location of the previously installed Business Area with the same name.

      Note:

      Do not change the name of a previously installed Business Area. This will cause problems with the .rpd file.

    • OBIEE Service Location Name. Select the value for the computer with the Presentation Server you want this Business Area to use, if more than one is available in your company.

  2. Add Table Descriptors and map them to the Table instances that contain the data you want to make available in OBIEE; see Defining Table Descriptors.

    Note:

    To enable the OBIEE repository to query the source Table instances that the Oracle LSH OBIEE Business Area uses, set the SAS Library Name of the mapped Table Descriptor to $REPINIT. See Defining Table Descriptors.

  3. If you want to add joins and hierarchies in Oracle LSH, do so now; see Defining Joins and Defining Business Area Hierarchies. See About OBIEE Business Areas.

    Note:

    Do not explicitly create a Source Code definition. The Source Code is automatically created when you install the Business Area. Its name is determined by the value of the Details attribute in the Deploy service defined for the service location you selected.

  4. Install the Business Area to create the initial .rpd file. Install it again if you make changes in Oracle LSH before working in the OBIEE Administration Tool. The system generates a new .rpd file with your changes.

    Note:

    Customization in the OBIEE Administration Tool is optional.

  5. Click Launch IDE to open the OBIEE Administration Tool. When prompted for a repository password, enter blank and continue. Work on the .rpd file in this tool, using the OBIEE user documentation.

    If you make structural changes in the OBIEE Administration Tool—changes to tables, joins, or hierarchies—you must make the same changes in Oracle LSH so that the .rpd file is always synchronized with the Business Area definition. Otherwise you will not be able to use the new structures in OBIEE. For example, if you add a column to a table in OBIEE but do not add the column in the Business Area Table Descriptor and map it to a column in its Table instance, you will not be able to see the data in the column in OBIEE.

  6. When you are finished making changes, upload the .rpd file to the Business Area:

    1. In the Source Code tab, click the link to the Source Code definition.

    2. Click Browse.... The .rpd file is generally stored on the C drive, in the CdrWork folder. The full path of the repository file looks like this:

      Drive:\CdrWork\LSH_database_username\OBIEE_BA_Domain_name\OBIEE_BA_Application_Area_name\OBIEE_BA_Work_Area_name\OBIEE_BA_name\OBIEE_BA_version_number\

      Note:

      Oracle LSH supports uploading zipped .rpd files. However, you must give the .zip file exactly the same name as the .rpd file; for example, test.zip must contain test.rpd.

    3. Click Apply.

  7. Install the Business Area. If you are using OBIEE 10g, the system creates a new version of the Source Code definition that contains the newly uploaded file and deploys the file to the repository folder path defined on the Oracle BI Server, merging it into the master .rpd file.

    Note:

    If an .rpd file does not appear in the Source Code tab after installation, check the Jobs subtab. If the Execution Status is Pending Logon or Obtain Service, there is a problem with the Distributed Processing (DP) Server on the BI Server computer.

  8. If you are using OBIEE 11g, manually deploy the master .rpd file to the BI Server and restart the BI Service; see Manually Deploying the Master RPD File.

Manually Deploying the Master RPD File

Manually deploy the new version of the master .rpd file on your OBIEE 11g BI Server using the Oracle Enterprise Manager. This step is required every time you install a Business Area.

  1. Open the Oracle Enterprise Manager using the URL specific to your environment.

    Note:

    If the URL does not work, you may need to restart the WebLogic Server; see Starting the WebLogic Server.

  2. In the left-hand panel, navigate to Farm_bifoundation_domain, then Business Intelligence, then coreapplication. Then click the Deployment tab, and then the Repository subtab.
  3. Click Lock and Edit Configuration near the top. A confirmation message appears.
  4. Under Upload BI Server Repository, click the Browse button for the Repository File field and select the master .rpd file.

    Note:

    The location of the master .rpd file is determined by the edited obieedeploy.cmd file; ask your administrator for it.

  5. Enter the repository password and confirm password. The password must be same as the administrator password stored in LSH under Remote Location Connections. This is very important for the integration. Click Apply.
  6. Click Activate Changes at the top of the screen. A confirmation message appears.
  7. Click Restart and confirm.
  8. Ensure that Restart All completed successfully. This indicates the successful deployment of the .rpd on the BI Server and a successful restart of the BI Server services. The Business Area .rpd is now ready to be used through the OBIEE Presentation Service (BI Answers).

Starting the WebLogic Server

If the URL for Oracle Enterprise Manager is not working, the WebLogic Server may be down. To start it:

  1. On the BI Server computer, right-click Command Prompt under the Start menu and select Run as Administrator.
  2. Change directory to the Domain folder under the OBIEE installation folder; for example, E:\oracle\fmw\user_projects\domains\bifoundation_domain.
  3. Run the command startWeblogic.cmd under this folder. The system prompts you for the WebLogic Server username and password.
  4. Check that the command window displays the message "Server started in RUNNING mode."

Visualizing Business Area Data using OBIEE Answers

You can access OBIEE data visualizations in two ways:

  • In Oracle LSH, go to the Visualizations subtab of the Reports tab; locate the Business Area under its classification hierarchy; click the View icon in the Actions column for the Business Area; and click Launch Visualization.

    The system launches the Oracle Business Intelligence Presentation Services interface. Navigate to the Subject Area with the same name as the Business Area and follow instructions in the OBIEE user documentation to create Answers and Dashboards.

  • Outside Oracle LSH, go to the URL of the computer corresponding to the Service Location Name. The system launches the Oracle Business Intelligence Presentation Services interface. Navigate to the Subject Area with the same name as the Business Area and follow instructions in the OBIEE user documentation to create Answers and Dashboards.

OBIEE Security

OBIEE security is handled through Oracle LSH.

End User Security

Security access to OBIEE visualizations is determined by users' security privileges on the Business Area on which the visualization is based. The automatically generated RPDUpdates.txt file contains the information required to initiate user authentication. This file is passed to the BI Server during Business Area installation and RPD file merge and deployment operation.

When you launch an OBIEE visualization from within Oracle LSH , you can see noncurrent and blinded Oracle LSH data if you have the required privileges.

If you access an OBIEE visualization outside of Oracle LSH, through the URL of the OBIEE Presentation Services, you cannot see blinded or noncurrent data regardless of your privileges.

Developer Security

Developers must have normal security access to modify the Business Area.

When you launch the OBIEE Administration Tool or an OBIEE visualization from within Oracle LSH , you can see noncurrent and blinded Oracle LSH data if you have the required privileges.

When you launch the OBIEE Administration Tool from Oracle LSH, the system create synonyms to the Business Area's Table Descriptors for your database account, and the OBIEE Administration Tool connects to the LSH database with your database account. The logon trigger authenticates against Oracle LSH user privileges.

Installing and Setting Up Oracle Business Intelligence Administration Tool

To use the Oracle Business Intelligence Administration Tool, you must do the following on your local PC:

  • Get the CD-ROM that contains the Oracle LSH files cdrconfig.xml and cdrclient.exe from your system administrator and insert it into your PC. InstallShield automatically runs setup.exe to load cdrconfig.xml and cdrclient.exe to a location you specify on your local computer.

  • Install Oracle BI Client Tools on your PC in the location specified by your system administrator. The location must match the directory path specified in cdrconfig.xml.

  • Ensure that cdrconfig.xml has the correct directory path for the Oracle BI Administration tool.

  • In the Oracle BI Administration Tool, set up connectivity with the Oracle LSH database. See Set Up Database Connectivity for information.

  • Add and set the following environment variables on the PC through advanced system properties:

    • ORACLE_HOME Enter the absolute path of the Oracle Home on your PC; for example:

      Drive:\Program Files\Oracle Business Intelligence Enterprise Edition Plus Client\oraclebi\orahome
      
    • ORACLE_INSTANCE Enter the absolute path to Oracle BI orainst1 on your PC; for example:

      Drive:\Program Files\Oracle Business Intelligence Enterprise Edition Plus Client\oraclebi\orainst
      
    • ORACLE_BI_APPLICATION You must enter the following value exactly:

      coreapplication
Set Up Database Connectivity

To access Oracle LSH data in the Administration Tool on your PC, you must set up connectivity between the Oracle LSH database and your PC. You can use a system ODBC DSN or the Oracle Call Interface (OCI10g):

  • Set Up Database Connectivity Using a System DSN

    1. Create a valid Oracle driver-based System Data Source Name (DSN) on your PC that points to the LSH database.

    2. Consult Microsoft Windows online help for instructions on creating the System DSN.

    3. Use the Test Connection button to test the connection.

  • Set Up Database Connectivity Using OCI 11g

    1. Create an entry in your PC's tnsnames.ora file with the name and connection details for the LSH database server.

    2. Create an entry in your PC's tnsnames.ora file with the name and connection details for the LSH database server.

    3. Test the connection by trying to connect to the Oracle LSH database using sqlplus as apps. For example:

      sqlplus apps/apps_password@lsh_database_name

Defining Generic Visualization Business Areas

Oracle LSH includes a Generic Visualization adapter to allow you to integrate the data visualization tool of your choice with Oracle LSH so that your end users can view Oracle LSH data through that tool. See the Oracle Life Sciences Data Hub Adapter Toolkit Guide for information on using the Generic Visualization adapter.

After setting up integration, you define and install one or more Business Area instances of type GENERIC_VISUALIZATION. Users can then access the data visualizations through the tool's URL. Users can then access data visualizations through the tool's URL.

Generic Visualization Business Area Instance Properties

Generic Visualization Business Area instances have the following properties:

  • Schema Name: Enter a unique name for the schema of up to 30 characters. The value is stored in uppercase. Do not use special characters or reserved words; see Naming Objects. Users will be able to use this account to log in to the integrated visualization tool.

    If a schema already exists in the Oracle LSH installation with the same name, the system automatically appends _n to the name, where n is 1 or the next higher integer if there is already a schema name your_name_1 or higher.

  • Default Currency: This setting controls the data viewed by users if they do not explicitly make another selection at login. The default value is Current. If all the source Table instances mapped to the Business Area have the same snapshot label applied and you want users to see that snapshot data by default, select the snapshot label.

  • Default Blinding Access Type: This setting controls the data available to users. Users' privileges also determine which data they can view. Your own privileges determine which values you can set. The possible settings include:

    • NA/Dummy All users, regardless of their privileges, can see data in Table instances whose Blinding flag is set to No and the dummy data in Table instances whose Blinding flag is set to Yes. If all Table instances mapped to Business Area Table Descriptors have their Blinding flag set to No, this is the only option available.

    • Real(Unblinded) If all Table instances whose Blinding flag is set to Yes have a Blinding status of Unblinded, you can set the Default Blinding Access Type to this value. In these Table instances, users with the necessary privileges can see the real, unblinded data, and users without these privileges see the dummy data. All users can see data in Table instances whose Blinding flag is set to No.

    Note:

    The adapter can allow users with Blind Break privileges on all Table instances whose Blinding flag is set to Yes and whose Blinding Status is set to Blinded to select the Real (Blind Break) option when they log in, regardless of the Default Blinding Access Type. All blind breaks are audited.

  • Table Descriptors: Generic Visualization Business Area Table Descriptors can be mapped to any Table instance type including 'View' Table instances.

    Note:

    You cannot define Joins, Hierarchies, Parameters, or Source Code for Generic Visualization Business Areas.

Assigning Security Privileges to Business Area Data

Unlike other Business Areas, which are installed in their Work Area's schema, Oracle LSH installs each Generic Visualization Business Area instance in its own schema outside the Work Area schema. There are simplified security requirements for data in this schema.

Users can log in to the integrated visualization tool using an Oracle LSH database account. The system checks if there is an Oracle LSH user account linked to the database account. If there is a linked user account, the system uses it to determine the user's privileges. If there is no linked user account, the system uses the database account itself to determine the user's privileges.

The database account can have one or two privileges assigned:

  • Read Data. This privilege allows the user to view data that was never blinded and dummy data in Table instances that are currently blinded. All database accounts that should have access to the Business Area instance data should have this privilege.

  • Read Unblind. This privilege allows the user to view data that has been permanently unblinded.

If a user should be able to view currently blinded data, he or she must have an Oracle LSH user account with all the required Blind Break privileges and a linked database account. An administrator must set up the user account and appropriate privileges.

If you have the Manage GVA BA Database Access operation on Business Area instances and belong to a user group assigned to a Business Area instance, you can grant or revoke Read Data and Read Unblind privileges database accounts for the Business Area instance. Oracle LSH audits all changes to these permissions.

To grant privileges to database accounts on Business Area instance data:

  1. In the Business Area instance Properties page, select Manage DB Privileges from the Actions drop-down list. Select Go.

    You see the the privileges Read Access and Read Unblind Access. You can expand either privilege to view the database accounts currently assigned to that privilege.

  2. To change assignments, select the plus (+) icon in the Manage column for either Read Access or Read Unblind Access. A screen opens displaying available accounts for assignment and those already selected for the privilege.
  3. Use the arrow icons to grant or revoke the selected privilege to one or more accounts:
    • To grant an account the privilege you selected, double-click or use the arrow icons to move the account from Available Users to Selected Users.

    • To revoke the privilege, double-click or use the arrow icons to move an account from Selected Users to Available Users.

  4. Click Apply.

Launching Visualizations

This section contains the following topics:

Creating a Visualization

To create a Visualization from a Business Area instance:

  1. Click Launch. Oracle LSH opens the Launch Visualization screen.

    Note:

    Launching the IDE is not supported for Generic Visualization Business Areas.

  2. The Launch Visualization screen displays details about the Business Area instance, and launch settings—data currency, and data blinding-related settings—for data that becomes available to OBIEE. To edit these settings, click Launch Settings. Oracle LSH opens the Launch Settings screen. See Setting Data Currency and Blinding Values.
  3. After making your selections in the Launch Settings screen, click Launch on the Launch Visualization screen. Oracle LSH opens the OBIEE Administration Tool.

    Note:

    When you launch the OBIEE Administration Tool, you have to log in with an Oracle LSH username and password.

Setting Data Currency and Blinding Values

You can determine the blinding status and currency of the data you see by clicking the Launch Settings button and selecting a value for Blind Break and Shared Snapshot Label.

This section contains the following topics:

Setting the Blind Break Value

This setting is relevant only when one or more source Table instances either currently or formerly contained blinded data. Special privileges are required to view real data that is either currently blinded or was formerly blinded. You must have these special privileges on all such Tables, in order to see real data in any of them.

Note:

You must have Read Data privileges in order to see any data at all.

The following choices are available depending both on the state of the data and on your security privileges:

  • Not Applicable. If none of the data has ever been blinded, the only option available is Not Applicable. No special privileges are required.

  • Dummy. This is the only option available to you if you do not have blinding-related privileges for blinded Tables. You can also see this option if you have blinding-related privileges. In that case, you can select this option to work with dummy (not real) data in Oracle Business Intelligence Enterprise Edition.

  • Real (Blind Break). If any of the data is currently blinded, and you have the required privileges, you can select this option to view real data in Oracle Business Intelligence Enterprise Edition according to your company's policies. The table(s) containing the blinded data remain blinded after you run the visualization.

  • Real (Unblinded). If a blinded Table instance has now been unblinded, you can see real data for the Table instance, provided you have the required privileges. If there are more than one such Table instances, you need the required privileges for all of them to be able to use this option.

Setting the Shared Snapshot Value

If all the relevant Table instances share one or more snapshot labels, those snapshot labels appear in this drop-down list and you can select one.

Note:

If a Table instance is defined as a pass-through view, visualizations always display current data in it, regardless of this setting.

In addition, you normally have the option to view the current data.

You can apply snapshot labels in the Work Area; see Adding, Removing, or Moving a Snapshot Label.

For more information on what snapshots are, see Data Snapshots.

Installing Business Area Instances

You can install a Business Area instance directly from its Properties screen, using the Install button, or in its Work Area (see Installing a Work Area and Its Objects).

When you install a Business Area instance using the Install button on its Properties screen:

  • The system checks in the Business Area instance and definition, and also the Table instances in the current Work Area to which the instance is mapped.

  • The system attempts to install the Business Area instance and its source Table instances in the current Work Area. The system displays a success or error message. If the installation fails, the error message displays the name of any objects that were not installable.

    Note:

    If the Business Area definition or any of its source Table instances in the current Work Area is not installable, the system cannot install the Business Area instance. See Installation Requirements for Each Object Type for the reasons these objects may not be installable.

  • In an OBIEE Business Area, the system may generate a repository file; see About OBIEE Business Areas.

Note:

To continue working on the Business Area, check it out.

Accessing the Log File

To see the log file for the installation, you must go to the Work Area Installation screen, as follows:

  1. Click the Applications tab. The main Application Development screen opens.

  2. Click the name of the Work Area you are working in. The Work Area screen opens.

  3. From the Actions drop-down list, select Installation History.

  4. Click Go. The system displays the Installation History screen with the log files in chronological order.

  5. Click the View Log link for the most recent installation attempt or for the date and time that you ran the install process. The system displays the log file.

For information on installation and on reading the log file, see Installing a Work Area and Its Objects.

Modifying Business Areas

If you have the necessary privileges, you can modify a Business Area either through an instance of it in a Work Area or directly in the definition in its Domain or Application Area. In most cases it makes sense to work through an instance in a Work Area for the following reasons:

  • In order to use or test changes to the definition you must create and install an instance of it.

  • If you work through an instance, the system automatically repoints the instance to the new version of the definition.

However, if you need to change properties of the definition, you must work directly in the definition in its Domain or Work Area.

Whether you work in an instance or directly in the definition, when you check in the new version of the definition you have the opportunity to upgrade instances of the original definition to the new version; see Upgrading Object Instances to a New Definition Version.

This section contains the following topics:

Modifying Business Area Instance Properties

On the Business Area instance's Properties screen, click Update to enter changes. Oracle LSH creates a new version of the instance you are working on and applies your changes to it when you click Apply. Click Cancel to discard your changes and the new version.

You can modify some properties through the Actions drop-down list; see Using the Actions Drop-Down List for further information.

Note:

You must reinstall the Business Area for the changes to take effect.

You can modify the following:

  • Name: See Naming Objects for further information.

  • Description: See Creating and Using Object Descriptions for further information.

  • Definition Source: This field applies to the instance only. It specifies the Business Area definition to which this Business Area instance points. It generally does not make sense to change the source definition for the following reasons:

    • Changing the definition may result in a new set of Table Descriptors, Joins, and Business Area Hierarchies.

    • Any new Table Descriptors are not mapped.

    • The Business Area's status changes to Non Installable.

    If you want to change to a new version of the same definition, use the Upgrade Instance option from the Actions drop-down list.

  • Default Blinding Access Type: (Generic Visualization Business Areas).

  • Default Currency: (Generic Visualization Business Areas).

Modifying Business Area Definition Properties

You can go to a Business Area definition's Properties screen in one of the following ways:

  • From the Business Area's Properties screen: Click the hyperlink of the Business Area definition that appears in the Definition field.

  • From the Domain or Application Area where you created the definition: Click Manage Definitions to view all the definitions in that Domain or Application Area. Click the definition name.

Once on the Business Area definition screen, click Update to enter changes. Oracle LSH creates a new version of the definition. You can change the following properties:

Modifying Table Descriptors

Table Descriptors belong to the Business Area definition, but Table Descriptor mappings belong to the Business Area instance. You must check out the definition to add, remove, or update Table Descriptors, but not to map, unmap, or remap Table Descriptors.

You can remove the existing Table Descriptors and add different ones. See Creating a Business Area for information about the function of Table Descriptors in a Business Area.

Oracle LSH enforces the following rules:

  • You cannot remove a Table Descriptor if any Join or Hierarchy references it.

  • You cannot change a Table Descriptor's source Table definition to a different Table definition if any Join or Hierarchy references the Table descriptor.

  • You cannot remove a Column from a Table Descriptor if any Join or Hierarchy references it.

You can change the Table Descriptor mappings, which are part of the Business Area instance, not the definition; see Mapping Table Descriptors to Table Instances.

Note:

Oracle LSH does not prevent all changes that might cause your Business Area to not function properly. For example, you are allowed to change the underlying Variable of a Column even if the Column is part of a Join. However, if you select a Variable that has a different data type, the Join may no longer work.

Modifying Joins

Joins belong to the Business Area definition.You must check out the definition to add, remove, and modify Joins. See Defining Joins for information about Joins.

Modifying Business Area Hierarchies

Business Area Hierarchies belong to the Business Area definition. You must check out the definition to add, delete, and modify Business Area Hierarchies. See Defining Business Area Hierarchies for information about Business Area Hierarchies.

To change the order of the hierarchy columns, click Reorder. See Reordering and Renumbering Objects.

Modifying Business Area Source Code

Business Area Source Code belongs to the Business Area definition. You must check out the definition to make any changes to the Source Code instance, for example, editing and uploading an OBIEE repository file for OBIEE Business Areas. See About OBIEE Business Areas for more information on OBIEE Business Area Source Code.