Skip Headers
Oracle® Business Intelligence Applications Administrator's Guide
11g Release 1 (11.1.1.8.0)

E49134-01
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A Enabling Fusion Flex Fields for BI and Using ApplCore Grants for Data Security

This appendix describes how to enable Fusion Flex Fields for use with Oracle Business Intelligence and how to use the BI Extender to Propagate Flex Object Changes to the Oracle BI metadata repository and the Oracle Business Analytics Warehouse. It also explains how to implement ADF data security in the Oracle BI Server. To implement ADF data security, you must have an application with secured View Objects and user setup.

This appendix includes the following sections:

A.1 Setting the Extender for BI Applications Administration Tool Option

The Oracle BI Administration Tool is a Windows application that you can use to create and edit repositories. To use BI Extender for Oracle BI Applications, you must go to the Administration Tool's Options dialog and set the Extender for BI Apps option. For more information, see Section A.3, "Using the BI Extender to Propagate Flex Object Changes,".

This section describes how to open the BI Administration Tool and set the Extender for BI Apps option.

This section contains the following topics:

A.1.1 Opening the Administration Tool

To open the Administration Tool:

To open the Administration Tool, choose Start > Programs > Oracle Business Intelligence > BI Administration.

Note:

Do not open the Administration Tool by double-clicking a repository file. The resulting Administration Tool window is not initialized to your Oracle instance, and errors will result.

You can also launch the Administration Tool from the command line, as follows:

  1. In Windows Explorer, go to the location appropriate for your install type:

    • Client installations:

      ORACLE_HOME/bifoundation/server/bin
      
    • All other installations:

      ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup
      
  2. Double-click bi-init.cmd (or bi-init.bat for client installations) to display a command prompt that is initialized to your Oracle instance.

  3. At the command prompt, type admintool and press Enter.

A.1.2 Setting the Extender for BI Apps Option

You can use the Options dialog to set the Extender for BI Apps preferences for the Administration Tool. You must set this option to use BI Extender for Oracle BI Applications.

To set the Extender for BI Apps option:

  1. In the Administration Tool, select Tools, then select Options to display the Options dialog.

  2. On the General tab, locate the Extender for BI Apps option and enable it.

  3. Click OK.

A.2 Importing Metadata from Fusion Application ADF Data Sources

This section describes how to use the Import Metadata Wizard to import metadata from the Oracle Fusion Applications ADF data sources.

See Chapter 6 Working With ADF Data Source in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information about using ADF data sources with Oracle Business Intelligence.

This section contains the following topics:

A.2.1 Opening the Import Metadata Wizard

To open the Import Metadata Wizard:

  • In the Administration Tool, select File, then select Import Metadata. The Import Metadata Wizard appears.

    Note:

    If you have already defined an existing ADF data source and connection pool, you can right-click the connection pool in the Physical layer and select Import Metadata. The Import Metadata Wizard appears with the information on the Select Data Source screen pre-filled.

A.2.2 Performing an Initial Import

This section describes the options you need to set when using the Administration Tool's Import Metadata Wizard to perform an initial import from Oracle Fusion Applications ADF data sources.

For more information about setting all other options in the Import Metadata Wizard, click the help button on the wizard.

  • In the Metadata Wizard's Select Data Source screen, in the User Name and Password fields, you must connect as the FUSION_APPS_BI_APPID user.

  • If you are importing flexfields from Oracle Fusion Applications sources, then in the Metadata Wizard's Select Metadata Objects screen, you must always import both the name_ and name_c attributes for each segment. The name_ attribute contains the value. The name_c attribute contains the code of the value set that the value comes from. Both attributes are mapped to the corresponding dimension view object. You typically use the name_ attribute in reports.

    For DFF segments, you can also optionally import:

    • DESC_name_ attribute: contains a description of the value

    • TRAN_name_ attribute: contains translated values, when available

  • In the Map to Logical Model screen, click Finish to close the wizard, or click Next to continue to the Publish to Warehouse screen. See Section A.3.3, "Publishing Changes to the Data Warehouse and Propagating Changes to the Repository" for more information.

Note that the Hide object if field is predefined for Presentation layer objects imported from an ADF view object that includes the "hide" display property. When this display property is set and the ADF data source is imported into the repository, the ADF_IS_HIDDEN property is added to the physical column's properties. When a presentation column is based on a physical column with the ADF_IS_HIDDEN property, the presentation column's Hide object if field is set to 1, which indicates that it is hidden.

A.3 Using the BI Extender to Propagate Flex Object Changes

You can configure and enable the BI Extender functionality to propagate changes made on Flex objects to the BI repository and optionally to the data warehouse.

This section contains the following topics:

A.3.1 About Propagating Changes to Flex Objects to the Data Warehouse

You can use the Administration Tool to propagate data warehouse changes in your ADF applications through the following system components:

  • Oracle Data Integrator (ODI)

  • The Physical and Business Model and Mapping layers of the Oracle BI Repository.

In this scenario, the BI Extender is the driver that coordinates the information exchange between the ADF objects and the other targets.

The BI Extender feature supports changes made to flexfields in ADF data sources. Flexfields are columns within tables that can be reused based on a user-specified context. There are two types of flexfields:

  • Key (KFF). These objects are modeled as dimension view objects. KFF segments are imported as new dimensions joined to an existing fact table.

  • Descriptive (DFF) These objects are modeled as view object attributes. DFF segments are imported as new attributes (on both facts and dimensions) on existing tables.

The BI Extender uses the JavaHost service to propagate flexfield changes. Because of this, JavaHost must be running for this feature to work, and the NQSConfig.INI file on the Administration Tool computer must be configured for the correct JavaHost location.

The rest of this section contains the following topics:

A.3.1.1 Overview of BI Extender Use with Oracle BI Applications

Figure A-1 Flexfield Change Propagation with BI Extender and Oracle Data Integrator

This graphic is described in surrounding text.

In Figure A-1, numbers indicate the steps in the flexfield change propagation process. These numbers represent the following steps:

  1. The Import Metadata Wizard sends XML containing the flexfield object changes to the BI Extender.

  2. XSL transform files are applied to the base XML.

  3. The BI Extender calls ODI.

  4. The BI Extender writes to the ODI Repository.

  5. ODI propagates the flexfield changes to the data warehouse.

  6. The BI Extender propagates the changes to the database object for the data warehouse in the Physical layer of the Oracle BI repository.

  7. The BI Extender maps the changes to the logical model.

A.3.1.2 Use Cases for Propagating Flexfield Changes

The BI Extender supports a variety of use cases for propagating changes made to flexfields. The primary use cases include:

  • New attribute added on a dimension (Dimension DFF - DescriptiveFlexExtensionStandard)

  • New attribute added on a fact (Fact DFF - DescriptiveFlexExtensionStandard)

  • New Dimension added, joined to an existing Fact (Dimension KFF - KeyFlexCreationStandard for dimension, KeyFlexExtensionStandard for the fact foreign key)

  • New Dimension added, joined to an existing Dimension (Dimension on Dimension KFF - KeyFlexCreationStandard on the new dimension, KeyFlexExtensionStandard for the foreign key)

In addition to these standard use cases, some more complex, advanced use cases are supported. The following sections describe these advanced use cases.

ETL Only View Object A view object that exists only to extend the ETL mappings, and that will not be used for queries. Imported view objects of this type are marked as disabled in the Business Model and Mapping layer. View objects of this type are marked as ETL Only in the Map to Logical Model screen of the Import Metadata Wizard.

Query Only View Object A view object that is only to be used for queries. View objects of this type are not passed to the BI Extender. View objects of this type are marked as Query Only in the Map to Logical Model screen of the Import Metadata Wizard.

View Objects that Map to Existing Dimensions This occurs when the imported view object is mapped to an existing logical dimension table that already maps to the data warehouse. In this case, the BI Extender uses the existing columns to perform the extensions. A different transformation template (from the specified XSL transform file, discussed in Section A.3.5, "Setting Up XSL Transform Files to Customize XML Output to the Oracle BI Extender") is applied for this use case, as shown in Table A-1.

Table A-1 Normal and Mapped to Existing Transformation Template Names

Normal Template "Mapped to Existing" Template

KeyFlexCreationStandard

KeyFlexCreationExtract

DescriptiveFlexCreationStandard

DescriptiveFlexCreationExtract

KeyFlexHierarchyCreationStandard

KeyFlexHierarchyCreationExtract

DescriptiveFlexExtensionStandard

DescriptiveFlexExtensionExtract

KeyFlexExtensionStandard

KeyFlexExtensionExtract


Hierarchy View Object A special type of view object that is treated differently by the BI Extender. You can specify a Hierarchy view object in the updatehierarchy.xsl file, where you specify the HIERARCHY_NAME and DATASOURCE_NUM_ID (required attributes for Hierarchy view objects). This tells the Administration Tool which view objects are Hierarchy view objects. In the Map to Logical Model screen of the Import Metadata Wizard, the Hierarchy check box appears as selected for each Hierarchy view object.

Striping (W_GL_SEGMENT_D) Some view objects come with predefined filters. These filter definitions are automatically propagated to the appropriate logical table source content filter.

The BI Extender configures the logical table source filters for GL accounts by putting appropriate segment labels in the filters. There is a right-click option for GL-SegmentX dimension tables to pull in the synchronized custom AM properties into the logical table source filter.

A.3.2 Performing Preconfiguration Tasks for the BI Extender

To enable the BI Extender feature with ODI, you must configure a connection to ODI and the data warehouse in the biextension.properties file. You also need to provide configuration information in the loaders.xml file for JavaHost.

The following sections describe the steps needed for this configuration:

A.3.2.1 Configuring the biextension.properties File

This section explains how to configure the biextension.properties file.

To configure connections in biextension.properties:

  1. Open the biextension.properties file for editing. You can find this file at:

    MW_HOME/Oracle_BI1/bifoundation/javahost/lib/obisintegration/biextender
    
  2. Set the parameters in biextension.properties as needed for your deployment.

    The odi.* parameters define the connection to ODI.

    The following table describes the parameters in biextension.properties:

    Parameter Description

    odi.connection.sdk.masterdriver

    The Oracle JDBC Driver

    Set this to oracle.jdbc.driver.OracleDriver (exact value, do not change).

    odi.connection.sdk.masterurl

    The JDBC url for the ODI repository database (for example, jdbc:oracle:thin:@localhost:1521:orcl).

    odi.connection.sdk.workrepositoryname

    The ODI work repository name.


    Note that for Oracle Database, the driver parameters can use either a service name or SID. For example:

    • jdbc:oracle:thin:@host:port/service name

    • jdbc:oracle:thin:@host:port:SID

  3. Save and close the file.

A.3.2.2 Configuring the JavaHost loaders.xml File

This section explains how to configure the JavaHost loaders.xml file.

To configure the IntegrationServiceCall loader in loaders.xml:

  1. Open the JavaHost loaders.xml file for editing. You can find this file at:

    ORACLE_HOME\bifoundation\javahost\config
    
  2. Find the Loader section for IntegrationServiceCall. Then, edit the section to include the location of oracle.odi-sdk.jse_11.1.1.jar, as shown in the following example. Typically ODI client files are installed into C:\oracle\product\11.1.1\Oracle_ODI_1.

    <Loader>
     <Name>IntegrationServiceCall</Name>
     <Class>oracle.bi.integration.javahost.ServiceCallLoader</Class>
     <ConfigNodePath>ServiceCall</ConfigNodePath>
     <ClassPath>
      {%ORACLE_BIJH_ROOTDIR%}/lib/obisintegration/javahostservice.jar;
      {%ORACLE_BIJH_ROOTDIR%}/lib/obisintegration/aw/11g/ojdbc5.jar;
      C:\oracle\product\11.1.1\Oracle_ODI_1\setup\manual\oracledi-sdk\oracle.odi-sdk-jse_11.1.1.jar
     </ClassPath>
    </Loader>
    

    Important: Be sure to replace the path name in the highlighted line with the appropriate path names for your deployment.

  3. If the JavaHost is running on a Linux system, you must also download log4j-1.2.16.jar from http://www.apache.org and specify the classpath to this jar file in loaders.xml.

  4. Save and close the file.

A.3.2.3 Updating NQSConfig.INI

If you are using a client installation of the Administration Tool, such as when you are running the JavaHost on a Linux system, you must also update the NQSConfig.INI file on the Administration Tool computer to point to the location of a running JavaHost. To do this, follow these steps:

  1. Close the Administration Tool, if it is open.

  2. On the same computer as the Administration Tool, open the local NQSConfig.INI file in a text editor. You can find this file at:

    ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
    
  3. Locate the JAVAHOST_HOSTNAME_OR_IP_ADDRESSES parameter, near the bottom of the file. Update this parameter to point to a running JavaHost, using a fully-qualified host name or IP address and port number. For example:

    JAVAHOST_HOSTNAME_OR_IP_ADDRESSES = "myhost.example.com:9810"
    

    Note that in a full (non-client) Oracle Business Intelligence installation, you cannot manually edit this setting because it is managed by Oracle Enterprise Manager Fusion Middleware Control.

  4. Save and close the file.

These steps are only required for client installations of the Administration Tool.

A.3.2.4 Optionally Changing the Location of the BI Extender Files

Optionally, you can change the location of the BI Extender files. To do this, move the files from the default location to a new location, then create an operating system environment variable called ORACLE_BI_ETL_EXTENDER and set its value to the value of the new path. The default path for the BI Extender files is:

ORACLE_HOME/bifoundation/javahost/lib/obisintegration/biextender

A.3.3 Publishing Changes to the Data Warehouse and Propagating Changes to the Repository

This section explains how to use the BI Extender to propagate the flex object changes to ODI, as well as to the Physical layer and logical model objects. You must complete the preconfiguration steps in Section A.3.2, "Performing Preconfiguration Tasks for the BI Extender" before performing the steps in this section.

This section contains the following topics:

A.3.3.1 Running the BI Extender to Update ODI and the RPD

This section explains how to run the BI Extender to update ODI and the Oracle BI repository for flex object changes. This section assumes that you have already added a new attribute in your ADF application.

To run the BI Extender to update ODI and the RPD:

  1. Ensure that the JavaHost process is running.

  2. Open your repository in the Administration Tool.

  3. In the Physical layer, right-click the connection pool for your ADF OLTP source and select Import Metadata.

  4. Complete the steps in the Select Metadata Objects and Map to Logical Model screens. For more information, click the help buttons on these screens.

  5. On the Publish to Warehouse screen, perform the following steps:

    ODI Implementations

    1. For ODI implementations, select the warehouse database, and select ODI.

    2. For User Name and Password, enter the ODI Repository user name and password.

    3. For the Schema Owner Name and Password, enter the database user name and password where the ODI Master Repository resides.

    4. Click Test Connection.

  6. Click Finish.

See Section A.3.1, "About Propagating Changes to Flex Objects to the Data Warehouse" for a description of what happens when you click Finish in the Publish to Warehouse screen.

A.3.4 Automatically Publishing and Mapping Flex Object Changes Using the biserverextender Utility

You can use the -E option with the biserverextender utility to automatically publish and map flex object to the repository for Fusion Applications ADF data sources. This topic explains the -E option, only, which is specific to using the biserverextender utility with Oracle Fusion Applications ADF data sources. See "Automatically Mapping Flex Object Changes Using biserverextender Utility" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for complete information about the biextender utility, syntax options, and setting up the required XML parameter file.

Using the biserverextender utility does not require the Administration Tool, and is therefore especially useful when you want to publish changes and map flex object changes on Linux and UNIX systems where the Administration Tool is not available.

Syntax 

biserverextender -P repository_password -R base_repository_name -I input_XML_file -O output_repository_name -J oracle_enterprise_scheduler_id -E run_ETL_extension_process

Example 

biserverextender -R scratch/my_repos.rpd -I /scratch/ADFSource.xml -O /scratch/my_repos_modelled.rpd -J 300 -E
Give password: password

Sample ODI XML Parameter File 

<BIExtenderParameters updateAMPropertiesForTest="true">
           <ConnectionDetails>
    <ConnectionPool>
     <ConnectionPoolName> "oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal"."Connection Pool"
     </ConnectionPoolName>
    </ConnectionPool>
   </ConnectionDetails>
   <ETLExtensionDetails dataWarehouse="Oracle DataWarehouse" sendExtension="true"  generateXML="true">
    <ODI>
     <Username>username1</Username>
     <Password> D7EDED84BC624A917F5B462A4DCA05CDCE256EEEEEDC97D5AC4D07C3A079829F
     </Password>
      <MasterUserName>username2</MasterUserName>
      <MasterPassword> D7EDED84BC624A917F5B462A4DCA05CDCE256EEEEEDC97D5AC4D07C3A079829F 
      </MasterPassword>
    </ODI>
   </ETLExtensionDetails>
</BIExtenderParameters>

Where:

dataWarehouse is the name of the data warehouse to where the changes will be propogated.

sendExtension specifies whether to log the connection and XML in the Admintool log file. The default values is false.

generateXML specifies whether to generate the XML output file. The default value is false.

ODI specifies the ODI connection details of the user and the master user.

Note that in this example, Password and MasterPassword are encrypted values. When submitting the job through Oracle Enterprise Scheduler Service, the scheduler provides the encryption.

If you run the biserverextender utility manually by entering the details in the input XML file, then you can use the QSecUDMLGen utility to generate the encrypted password. When you run the QSecUDMLGen utility with the -P option, you will be prompted to supply a password. When you enter the password, the utility generates the encrypted string for the password.You then add this string (encrypted password) to the input XML file.

A.3.5 Setting Up XSL Transform Files to Customize XML Output to the Oracle BI Extender

The biextension.properties file specifies the XSL files to be used to transform and customize the default XML generated by the Administration Tool and sent to the BI Extender. By default, the following XSL files are applied:

  • biextension.xsl: Contains default transformations for the Extender. Contains templates for both normal and "mapped to existing" cases.

  • updatehierarchy.xsl: Specifies rules for how Hierarchy view objects should be handled.

  • LastUpdateDate.xsl: Identifies which input columns need to be filtered for Change Data Capture.

All XSL files are located in the same directory as biextension.properties.

In rare cases, you might need to make additional customizations the default XML that is generated by the Administration Tool and sent to the BI Extender. To do this, you can create other XSL files to be applied in addition to the three default XSL files. Note the following:

  • Additional XSL files need to conform to the XML schema defined in the biextension.xsd file, located in the same directory as the biextension.properties file.

  • It is a best practice to define changes in an additional XSL file rather than updating one of the default files.

  • The replaceName.xsl file provides examples on how to do XSL transforms for name changes.

To specify additional XSL files:

  1. Open the biextension.properties file for editing. You can find this file at:

    ORACLE_HOME/bifoundation/javahost/lib/obisintegration/biextender
    
  2. Add additional XSL files to the xsl_transforms line, as follows:

    xsl_transforms = updatehierarchy.xsl,LastUpdateDate.xsl,biextension.xsl,
    replaceNames.xsl
    
  3. Save and close the file.

A.3.5.1 Sample XML Output

Sample base XML output generated by the Administration Tool might look like the following:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Document>
  <extension mode="KeyFlexCreationStandard" type="Dimension">
    <table name="W_COST_CENTER_D">
      <columns>
        <column datatype="Varchar2(50)" name="COST_CENTER_NAME" type="Attribute">
          <source column="COST_CENTER_NAME" table="SnowflakesalesApp.
          ADF_COST_CENTER_VO"/>
        </column>
        <column datatype="Varchar2(10)" name="COST_CENTER_LOCATION" 
        type="Attribute">
          <source column="COST_CENTER_LOCATION" table="SnowflakesalesApp.
          ADF_COST_CENTER_VO"/>
        </column>
        <column datatype="Varchar2(5)" name="COST_CENTER_ID" type="Key">
          <source column="COST_CENTER_ID" table="SnowflakesalesApp.
          ADF_COST_CENTER_VO"/>
        </column>
      </columns>
    </table>
  </extension>
</Document>

A.4 Setting Up and Using ApplCore Grants for ADF Data Security

Note:

This section applies to Fusion Applications source systems only.

This section explains how to implement ADF data security in the Oracle BI Server. To implement ADF data security, you must have an application with secured View Objects and user setup.

Perform the steps in the following sections:

A.4.1 Setting Up Oracle Business Intelligence to Use ApplSession

When you set up Oracle Business Intelligence to use ApplSession, the following occurs:

  • Pillar-specific AOL sessions are created for data queries. A new AOL session is created for every pillar within a BI session when a data query is fired against the pillar. This AOL session is reused for all subsequent data queries against the same pillar. There are, at most, as many AOL sessions as there are ADF pillars (databases) defined in the Oracle BI repository.

    For the examples used in this section, there are three or less AOL sessions ("AOL_SESSION_ID_HCM", "AOL_SESSION_ID_CRM", "AOL_SESSION_ID_FSCM") created within a BI Session for data queries.

  • AOL context variable values are propagated to the newly-created pillar-specific AOL sessions. Presentation Services propagates the AOL context variables when it logs in to the Oracle BI Server.

  • The SQL Bypass query reattaches to the previously created AOL session for that ADF Database.

This section contains the following topics:

A.4.1.1 Setting Up Database Objects and Connection Pools for ApplSession Integration

To set up the Oracle BI repository to enable ApplSession integration, you must first configure the appropriate database object and connection pools in the Physical layer.

To set up database objects and connection pools for ApplSession integration:

  1. Open your repository in the Administration Tool.

  2. Create database objects and connection pools in the physical layer for each pillar, as follows:

    • Create a database object and connection pool for SQL bypass during data queries (for example, Pillar1_bypass).

    • Use the Import Metadata Wizard to create a database object and connection pool that correspond to the application EAR file deployed in WLS (for example, Pillar1_http). This database object contains the physical table and column mappings to view objects and attributes. Be sure to specify the SQL bypass database you want to use during metadata import.

    Figure A-2 shows the pillar-specific database objects.

    Figure A-2 Pillar-Specific Database Objects

    This graphic is described in surrounding text.
  3. Open the connection pool for each SQL bypass database and click the Connection Scripts tab. To ensure that SQL bypass queries are issued within the pillar-specific AOL session (for example, "AOL_SESSION_ID_Pillar1_http,") you must provide the appropriate pre-query and post-query scripts, as follows:

    1. Expand Execute before query and click New.

    2. Enter a pre-query script similar to the following:

      BEGIN
        fnd_session_mgmt.attach_session('VALUEOF(NQ_SESSION.AOL_SESSION_ID_Pillar1_http)');
      END;
      
    3. Click OK.

    4. Expand Execute after query and click New.

    5. Enter the following post-query script:

      BEGIN
        fnd_session_mgmt.detach_session;
      END;
      
    6. Click OK.

    7. Click OK in the Connection Pool dialog.

    Figure A-3 shows the Connection Scripts tab of the Connection Pool dialog.

    Figure A-3 Pre-query and Post-query Scripts for the SQL Bypass Connection Pool

    This graphic is described in surrounding text.

A.4.1.2 Setting Up Initialization Blocks for ApplSession Integration

Initialization blocks are used to initialize BI session variables. They contain SQL/XML queries that are set up to return columns of values which are then mapped to BI session variables. Initialization blocks typically execute during BI session creation.

In the Initialization Block dialog, you can choose to defer the execution of an initialization block by selecting Allowed deferred execution. A deferred initialization block runs when its target variable is used for the first time within a BI session.

To set up initialization blocks for ApplSession integration:

  1. In the Administration Tool, select Manage, then select Variables.

  2. Select Action > New > Session > Initialization Block.

  3. Provide a name for the initialization block (for example, create_AOL_SESSION_ID_Pillar1). This initialization block creates a new AOL session when a data query is issued against the data source (for example, Pillar1_http).

  4. Click Edit Data Source.

  5. Select Default initialization string, and provide an XML initialization string similar to the following:

    <?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
    <ADFQuery mode="create_applsession">
      <ContextAttribute>
        <Name><![CDATA[ADDTL_CUSTOM_LEVEL]]></Name>
        <Value><![CDATA[VALUEOF(NQ_SESSION.AOL_ADDTL_CUSTOM_LEVEL)]]></Value>
      </ContextAttribute>
      <ContextAttribute>
        <Name><![CDATA[CLIENT_ENCODING]]></Name>
        <Value><![CDATA[VALUEOF(NQ_SESSION.AOL_CLIENT_ENCODING)]]></Value>
      </ContextAttribute>
      <ContextAttribute>
        <Name><![CDATA[CURRENCY]]></Name>
        <Value><![CDATA[VALUEOF(NQ_SESSION.AOL_CURRENCY)]]></Value>
      </ContextAttribute>
    </ADFQuery>
    

    This initialization string causes the OBIEE broker servlet to create a Java AOL session.

    The <ContextAttribute> elements represent the name-value pairs of context variables that will be propagated to the newly created AOL session. If no <ContextAttribute> elements are specified in the XML initialization string, default values of the user are used to create the AOL session.

    The values provided in the <Value> elements are mapped to the session variables initialized by Presentation Services.

    The following list shows a full mapping between AOL context attributes and session variables initialized by Presentation Services:

    ACCESSIBILITY_MODE - AOL_ACCESSIBILITY_MODE
    ACTION - AOL_ACTION
    ADDTL_CUSTOM_LEVEL - AOL_ADDTL_CUSTOM_LEVEL
    ANIMATION_ENABLED - AOL_ANIMATION_ENABLED
    APPLICATION_LANGUAGE - AOL_APPLICATION_LANGUAGE
    CLIENT_ENCODING - AOL_CLIENT_ENCODING
    COLOR_CONTRAST - AOL_COLOR_CONTRAST
    CURRENCY - AOL_CURRENCY
    DATE_FORMAT - AOL_DATE_FORMAT
    DECIMAL_SEPARATOR - AOL_DECIMAL_SEPARATOR
    EMBEDDED_HELP_ENABLED - AOL_EMBEDDED_HELP_ENABLED
    FONT_SIZE - AOL_FONT_SIZE
    GROUPING_SEPARATOR - AOL_GROUPING_SEPARATOR
    HISTORY_OVERRIDE_USER_NAME - AOL_HISTORY_OVERRIDE_USER_NAME
    INDUSTRY - AOL_INDUSTRY
    INDUSTRY_IN_TERRITORY - AOL_INDUSTRY_IN_TERRITORY
    LANGUAGE - AOL_LANGUAGE
    MODULE - AOL_MODULE
    NLS_SORT - AOL_NLS_SORT
    NUMBER_FORMAT - AOL_NUMBER_FORMAT
    PRODUCT - AOL_PRODUCT
    PRODUCT_FAMILY - AOL_PRODUCT_FAMILY
    TERRITORY - AOL_TERRITORY
    TIME_FORMAT - AOL_TIME_FORMAT
    TIMEZONE - AOL_TIMEZONE
    TRACE_LEVEL - AOL_TRACE_LEVEL
    

    Application-specific, nonstandard variables that do not appear in the preceding list can be propagated in the same manner.

  6. Click Browse next to Connection Pool and select the connection pool for the data source (for example, Pillar1_http_cp), then click Select.

  7. Click OK in the Session Variable Initialization Block Data Source dialog.

  8. Click Edit Data Target, then click New.

  9. Create a variable to be initialized by this initialization block. The name must be in the following format:

    AOL_SESSION_ID_physical_layer_database_object_for_pillar

    For example:

    AOL_SESSION_ID_Pillar1_http

  10. Click OK in the Session Variable Initialization Variable Target dialog.

  11. Select Allowed deferred execution. Selecting this option means that this initialization block only executes when a data query is issued against Pillar1.

  12. Click OK in the Session Variable Initialization Block dialog.

  13. Repeat the steps in this procedure for each pillar, if you have more than one.

Figure A-4 shows an example pillar-specific session variable initialization block.

Figure A-4 Session Variable Initialization Block Dialog for Pillar-Specific Initialization Block

This graphic is described in surrounding text.

A.4.1.3 About the Client Login Process in an ApplSession Integrated Environment

The following steps provide an example of the client login process when you have integrated Oracle Business Intelligence with ApplSession:

  1. A client logs in to the Oracle BI Server with the BI session variables that represent AOL context.

  2. The BI Session is established.

  3. The client issues a Logical SQL statement that navigates to the database object (for example, Pillar1_http).

  4. The initialization block runs and initializes the session variable (for example, create_AOL_SESSION_ID_Pillar1 initializes AOL_SESSION_ID_Pillar1_http).

  5. The session variable (for example, AOL_SESSION_ID_Pillar1_http) is attached within the OBIEE broker servlet before querying Composite view object SQL from the database object (for example, Pillar1_http).

  6. The Oracle BI Server replans the query with Composite view object SQL.

  7. The session variable (for example, AOL_SESSION_ID_Pillar1_http) is attached using the pre-query script in the connection pool before querying data directly from the SQL bypass database object (for example, Pillar1_bypass).

A.4.2 Setting Up Authentication for ApplSession Integration

Oracle Business Intelligence provides a custom identity assertion provider that must be installed in Oracle WebLogic Server. This custom asserter is used to extract a token from the HTTP request from Oracle Business Intelligence. The super user name and password provided in the repository connection pool object, as well as the session user name provided in the BI user session, are extracted from the token.

Authentication is performed in the custom asserter using the super user name and password. After the super user's credentials are authenticated, the custom asserter performs identity assertion using the session's user name. One-way SSL is required to secure the communication channel between Oracle Business Intelligence and Oracle WebLogic Server.

Note that the custom identity assertion provider only allows a user with the user name FUSION_APPS_BI_APPID to perform identity assertion. In other words, the user specified in the connection pool (the ADF HTTP connection pool, not the SQL bypass connection pool) must be FUSION_APPS_BI_APPID.

This section describes the configuration tasks you need to perform in the application before deploying to Oracle WebLogic Server for Oracle Business Intelligence consumption.

Ensure that you have correctly set up the ADF data sources before you perform the steps in the following sections.

This section contains the following topics:

A.4.2.1 Setting Up Security Constraints and Security-Related Servlet Filters in web.xml

You must set up the CLIENT-CERT authentication method in web.xml to trigger the custom identity assertion provider during log-on. In addition, you need to set up the JPS servlet filter in web.xml for data security to work properly.

To set up the CLIENT-CERT authentication method and servlet filters in web.xml:

  1. In JDeveloper, expand the Web Project for OBIEEBroker and open web.xml.

  2. Go to the source view of the file.

  3. To set up the CLIENT-CERT authentication method, include the following elements under the <web-app> element:

    <security-constraint>
      <web-resource-collection>
        <web-resource-name>restricted</web-resource-name>
        <url-pattern>/obieebroker</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <role-name>EndUsers</role-name>
      </auth-constraint>
    </security-constraint>
    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
      <realm-name>myrealm</realm-name>
    </login-config>
    <security-role>
      <role-name>EndUsers</role-name>
    </security-role>
    

    Note that the value for <role-name> can be anything. This value will eventually be mapped to principals that exist in the security realm; see Section A.4.2.2, "Configuring Role-to-Principal Mapping in weblogic-application.xml" for more information.

  4. To set up the JPS servlet filter, include the following <filter> elements before the <filter> element for ServletADFFilter:

    <filter>
      <filter-name>JpsFilter</filter-name>
      <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
    </filter>
    

    Then, include the following <filter-mapping> elements before the <filter-mapping> element for ServletADFFilter:

    <filter-mapping>
      <filter-name>JpsFilter</filter-name>
      <servlet-name>OBIEEBroker</servlet-name>
      <dispatcher>FORWARD</dispatcher>
      <dispatcher>REQUEST</dispatcher>
      <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>
    

A.4.2.2 Configuring Role-to-Principal Mapping in weblogic-application.xml

You must map the value you provided for <role-name> in web.xml to principals that exist in the security realm. This mapping is defined in weblogic-application.xml.

To configure role-to-principal mapping in weblogic-application.xml:

  1. In JDeveloper, under Application Resources, open Descriptors > META-INF > weblogic-application.xml.

  2. Include the following <security> element under the <weblogic-application> element:

    <security>
      <realm-name>myrealm</realm-name>
      <security-role-assignment>
        <role-name>your_role_name</role-name>
        <principal-name>your_principal_name</principal-name>
      </security-role-assignment>
    </security>
    

    Note the following:

    • Replace your_role_name with the actual value you provided for <role-name> in web.xml.

    • Replace your_principal_name with the name of either a BI session end user (for example, joeUser), or an Oracle WebLogic Server group (for example, testUsers).

  3. Redeploy the application.

A.4.2.3 Configuring the Custom Identity Assertion Provider in Oracle WebLogic Server

This section explains how to configure the custom identity assertion provider.

To configure the custom identity assertion provider in Oracle WebLogic Server:

  1. Locate the custom identity assertion provider jar file, located in your Oracle Business Intelligence installation directory at:

    ORACLE_HOME/bifoundation/javahost/lib/obisintegration/adf/
    biadfidentityasserter.jar
    
  2. Copy the jar file to the following Oracle WebLogic Server location:

    MW_HOME/wlserver_10.3/server/lib/mbeantypes
    
  3. Restart the Oracle WebLogic Server.

  4. Open the WebLogic Server Administration Console. For example, if your Oracle WebLogic Server is running locally on port 7001, go to http://localhost:7001/console.

  5. Log in to the WebLogic Server Administration Console with the credentials you created when you set up your WebLogic domain.

  6. In the Change Center, click Lock & Edit.

  7. In the left pane, select Security Realms, and then click the security realm that you want to configure.

  8. Click the Providers tab, then click New.

  9. Enter a name (for example, BI-ADF IdentityAsserter) and select BIADFIdentityAsserter for Type.

  10. Click OK.

  11. In the Change Center, click Activate Changes.

  12. Restart the Oracle WebLogic Server.

A.4.2.4 Configuring One-Way SSL in Oracle WebLogic Server

One-way SSL is required to properly secure the communication between Oracle Business Intelligence and Oracle WebLogic Server.

To configure one-way SSL in Oracle WebLogic Server:

  1. From the WebLogic Server Administration Console home page, click Servers under the Environment heading.

  2. In the Servers table, the name of the server you want to manage. Then, on the General subtab of the Configuration tab, select SSL Listen Port Enabled.

  3. Use the Administration Tool to update the appropriate connection pool object in the Physical layer so that the URL uses https:// instead of http://. Also, update the port number to use the SSL port (7002 by default).