Initialization block is a way that OBIEE provided to access the source or other systems to establish the run time environment. It establish the user context. The language context is also established via init block.
Init Block and Data Security
The feature was not designed just for data security but the feature is heavily used in supporting data security.
We use it to get the object instances that a user has the access and cache the list in variable.
Init Block and Variable
The name of the feature is confusing. An initialization block cannot exist without variables. They are just SQLs that are used to populate the variables.
When the init blocks are executed?
Before 10g, the init blocks created for populating the session variables were executed right after a user login.
It was working great when you have a handful init blocks. However, when you start creating a lot of the init blocks, it becomes problematic.
A prepackaged solution should allow people to pick and choose what they want to use during the deployment time. However, if the tool does not have the intelligence to let people to pick and choose, putting a lot of unused OOTB features becomes a monster.
OBIEE later introduced a feature of deferring the init blocks. The idea is that init block SQL could be costly and could actually delay the user access. First, it should not always be synchronous call and second, it should be time-out and protect the server process.
It is what available now in OBIEE:
You can defer the init blocks and make it not being executed during user login. Instead, BI server will parse the SQL and know when it needs the variable. In its first use, BI server will run the init block. In the subsequent usage, it will check if the session variable is already initiated before executing it.
How about the dependency?
In the past, you can define the init block dependency. It builds the order of execution of the init block during the session establishment. Since the deferral feature is introduced, you no longer need to declare the dependency.
You can use one session variable in the init block for another session variable. What happen is that BI server will build the execute order right at the time when it needs it. The session variable may be referred in a SQL and the init block will be put into the list, it will then parse it and find another session variable, and add to the queue before the one already there. It will find the one that has no dependency via parsing the SQL, and start executing it.
What are the recommendation?
You should avoid mixing the old way and the relatively new way in defining init blocks.
In BI Apps, we just simply defer almost all of them. I think that this can be a good practice.
You should always let BI server to get the order via SQL parsing. This way, you won’t get abnormal results.