安全相关Session Variable

About Using Initialization Blocks with VariablesAn initialization block contains the SQL statement that will be executed to initialize or refresh the variables associated with that block.


The SQL statement must reference physical tables that can be accessed using the connection pool specified in the Connection Pool field in the Initialization Block dialog.


If you want the query for an initialization block to have database-specific SQL, you can select a database type for that query. If a SQL initialization string for that database type has been defined when the initialization block is instantiated, this string is used. Otherwise, a default initialization SQL string is used.




Caution:


By default, when you open the Initialization Block dialog for editing in online mode, the initialization block object is automatically checked out. While the initialization block is checked out, the Oracle BI Server may continue to refresh the value of dynamic variables refreshed by this initialization block, depending on the refresh intervals that are set. When you check in the initialization block, the value of the dynamic variables is reset to the values shown in the Default initializer. If you do not want this to occur, use the Undo Check Out option. 




This section contains the following topics:


Initializing Dynamic Repository Variables


Initializing Session Variables


About Row-Wise Initialization


Initializing Dynamic Repository Variables
The values of dynamic repository variables are set by queries defined in the Default initialization string field of the Initialization Block dialog. You also set up a schedule that the Oracle BI Server will follow to execute the query and periodically refresh the value of the variable. If you stop and restart the Oracle BI Server, the server automatically executes the SQL statements in repository variable initialization blocks, reinitializing the repository variables.


The Oracle BI Server logs all SQL queries issued to retrieve repository variable information in nqquery.log when the logging level for the administrator account (set upon installation) is set to 2 or higher. You should set the logging level to 2 for the administrator to provide the most useful level of information. You can find the nqquery.log file in:


BIDOMAIN\servers\obisn\logs
For more information about user-level logging, see "Managing the Query Log" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.


Initializing Session Variables
As with dynamic repository variables, session variables obtain their values from initialization blocks. Unlike dynamic repository variables, session variables are not updated at scheduled time intervals. Instead, the Oracle BI Server creates new instances of those variables whenever a user begins a new session. The values remain unchanged for the duration of the session.


Execution of session variable initialization blocks during session logon can be deferred until their associated session variables are actually accessed within the session. See "Creating Initialization Blocks" for more information.


The Oracle BI Server logs all SQL queries issued to retrieve session variable information if the logging level is set to 2 or higher in the Identity Manager User object, or the LOGLEVEL system session variable is set to 2 or higher in the Variable Manager.


The default location for the nqquery.log file is:


BIDOMAIN\servers\obisn\logs
For more information about user-level logging, see "Managing the Query Log" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.


About Row-Wise Initialization
You can use the row-wise initialization option to create session variables dynamically and set their values when a session begins. The names and values of the session variables reside in an external database that you access through a connection pool. The variables receive their values from the initialization string that you type in the Initialization Block dialog.


For example, suppose you want to create session variables using values contained in a table named RW_SESSION_VARS. The table contains three columns:


USERID, containing values that represent the unique identifiers of the users


NAME, containing values that represent session variable names


VALUE, containing values that represent session variable values


Table 19-2 shows the table in this example.


Table 19-2 Sample Session Variables Database Table


USERID NAME VALUE 
JOHN
 LEVEL
 4
 
JOHN
 STATUS
 FULL-TIME
 
JANE
 LEVEL
 8
 
JANE
 STATUS
 FULL-TIME
 
JANE
 GRADE
 AAA
 




To use row-wise initialization, create an initialization block and select the Row-wise initialization option (refer to "Creating Initialization Blocks"). For this example, you would provide the following SQL statement for the initialization string:


SELECT NAME, VALUE
FROM RW_SESSION_VARS
WHERE USERID='VALUEOF(NQ_SESSION.USERID)'
Note that NQ_SESSION.USERID has already been initialized using another initialization block.


The following session variables would be created:


When John connects to the Oracle BI Server, his session contains two session variables from row-wise initialization: LEVEL, containing the value 4, and STATUS, containing the value FULL_TIME.


When Jane connects to the Oracle BI Server, her session contains three session variables from row-wise initialization: LEVEL, containing the value 8; STATUS, containing the value FULL-TIME; and GRADE, containing the value AAA.


Initializing a Variable with a List of Values
You can use the row-wise initialization option to initialize a variable with a list of values. You can then use the SQL IN operator to test for values in a specified list.


For example, using the table values in the previous example, you would type the following SQL statement for the initialization string:


SELECT 'LIST_OF_USERS', USERID
FROM RW_SESSION_VARS

WHERE NAME='STATUS' AND VALUE='FULL-TIME'

This SQL statement populates the variable LIST_OF_USERS with a list, separated by colons, of the values JOHN and JANE (for example, JOHN:JANE). You can then use this variable in a filter, as shown in the following WHERE clause:


WHERE TABLE.USER_NAME = valueof(NQ_SESSION.LIST_OF_USERS)
The variable LIST_OF_USERS contains a list of values, that is, one or more values. This logical WHERE clause expands into a physical IN clause, as shown in the following statement:


WHERE TABLE.USER_NAME IN ('JOHN', 'JANE')

Note that the above information and example pertain to Logical SQL. 

If you are using Physical SQL to initialize a variable with a list of values, then you must use the VALUELISTOF function. For example, to get the customers assigned to the user names in the variable LIST_OF_USERS, use the following statement:

Select 'LIST_OF_CUSTOMERS', Customer_Name from RW_CUSTOMERS where RW.CUSTOMERS.USER_NAME in ( VALUELISTOF(NQ_SESSION.LIST_OF_USERS))
To filter by only specific values in the list, then use ValueNameof as show in the below example. Note that the first value is 0, not 1.

Select 'LIST_OF_CUSTOMERS', Customer_Name from RW_CUSTOMERS where RW.CUSTOMERS.USER_NAME in '(ValueNameOf(0,NQ_SESSION.LIST_OF_USERS))

When Execution of Session Variable Initialization Blocks Cannot Be DeferredExecution of session variable initialization blocks cannot be deferred

in some circumstances. When the execution of session variable initialization blocks cannot be deferred, a message is displayed that explains why.


See "Assigning a Name and Schedule to Initialization Blocks" for more information.


The following list summarizes the scenarios in which execution of session variable initialization blocks cannot be deferred:


The Row-wise initialization option is selected in the Session Variable Initialization Block Variable Target dialog and the variables have not been declared explicitly with default values.


Example message: "The execution of init block 'A_blk' cannot be deferred as it is using row-wise initialization."


The Required for authentication option is selected in the Session Variable Initialization Block dialog.


Example message: "The execution of init block 'A_blk' cannot be deferred as it is required for authentication."


The Data Source Type is not Database.


Example message: "The execution of init block 'A_blk' cannot be deferred as it does not have a connection pool."


The initialization block is used by session variables named PROXY or USER.


Example message: "The execution of init block 'A_blk' cannot be deferred as it is used by session variable 'PROXY'."


The initialization block is used by session variables where the Security Sensitive option is selected in the Session Variable dialog.


Example message: "The execution of init block 'A_blk' cannot be deferred as it is used by session variable 'A' which is security sensitive."


The initialization block is a predecessor to another initialization block which does not have the Allow deferred execution option selected.


Example message: "One of the successors for init block 'A_blk' does not have "Allow deferred execution" flag set. Init block 'B_blk' does not have "Allowed deferred execution" flag set.