Versions Compared

Version Old Version 78 New Version 79
Changes made by

Former user

Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleWhat is _Scope_?

In the context of the Pentaho BI Platform, scope describes the lifetime of parameters in the platform's runtime environment. Parameters can be scoped at one of four different lifetimes:

  • request: The lifetime of a parameter in request scope is the duration of the current request/response. A parameter in request scope is only available to the thread executing the current request/response.
  • session: The lifetime of a parameter in session scope is a user's session. A session starts when a user logs in, and ends when the user logs out, or the session times out. A parameter in session scope is available to all request/response threads associated with a user's session.
  • global: The lifetime of a parameter in global scope begins when the application server initiates the application, and ends when the application server terminates the application. Parameters in global scope are availabe to threads in any user's session.
  • runtime: Parameters in runtime scope have an infinite lifetime. Their existence transcends the application server's lifetime. This has certain metaphysical consequences and therefore should be used with appropriate caution. Parameters in runtime scope are available to threads in any user's session.

...

Next, in the action sequence editor, add an input called name to the Process Inputs tree control. Configure it to be of type string, and define its scope to be session.

When the user logs into the BI Platform, the platform places a parameter called name into the session scope. name is the user name that was used to log into the platform. We can get access to this parameter by defining it as an input to our action sequence.
The DEPARTMENT_MANAGERS table of the SampleData database has the columns MANAGER_NAME, REGION, and EMAIL. MANAGER_NAME is the full name of the manager. We need a mechanism for mapping the user's login name to their fullname. We can then use a SQL query in an action sequence to discover the user's region.
We'll do this by adding a JavaScript action to our action sequence. Using the Process Actions tree control in the action sequence editor, click on the Add control (blue + sign with a triangle next to it), and select Generate Data From -> JavaScript. In the JavaScript editor, add this JavaScript code:

Code Block
fullName = "";
fullNameArray = new Object();
fullNameArray["joe"] = "Joe Pentaho";
fullNameArray["suzy"] = "Suzy Pentaho";
fullNameArray["pat"] = "Pat Pentaho";
fullNameArray["tiffany"] = "Tiffany Pentaho";
fullName = fullNameArray[name];

...

We still need to identify name from the Process Inputs tree control as an input to our JavaScript action. Click on the Add control in the Script Inputs editor, and select name.
We also need to identify the fullName variable from our JavaScript code as an output from our JavaScript action. To do this, click in the Script Outputs editor, type in fullName, and identify its type as string.

Now that we have the fullname as an output parameter, we can use that parameter in the next action to discover the region that the manager is responsible for.
In the Process Actions tree control, click on the Add control and select Generate Data From -> Relational. Make sure the JNDI radio button is selected. Identify the name of the Database Connection as SampleData. Add the following query to the Query editor:

Code Block
sql
sql
select REGION from DEPARTMENT_MANAGERS where MANAGER_NAME = \{PREPARE:fullName\}

...

Info
titleWhat does "Keep Connections Open" mean?

If Keep Connections Open is not checked, when a Relational action runs a database query, it immediately stores the results of the query into a light-weight java object, and closes the connection to the database. This light-weight java object can be stored as a parameter in request, session or global scope. This makes the object available to other actions in this action sequence, and to other action sequences executing at another time.
Often however, the size of a result is very large, making it expensive to copy the contents into a light-weight java object. It is also expensive to have both objects temporarily in memory at the same time. In this case, it makes sense to have "Keep Connections Open" checked.
This will cause the result-set's connection to the database to be kept open. The result-set will be available to other actions in this action sequence. And a copy will NOT be made to a light-weight java object.
In all cases, the connection to the database is closed at the conclusion of the action sequence. This suggests that a result set that was created with "Keep Connections Open" checked should never be placed in session or global scope, since the result set's connection will be closed at conclusion of the current action sequence, making it unusable.


We now have the name of the region that the manager is responsible for, but it is still in the result set. We don't want to keep the relatively "heavy" result set to in our session. We only need the string from the result set with the region name. We can use another JavaScript action to get the region string out of our result set, and then store the region string into our session.
In the Process Actions tree control, click on the Add control and select Generate Data From -> JavaScript.  
Since we need access to the result set from the previous action, in the Scripts Input, click on the Add control and select RS_MANAGERS_REGION. 
Next, add the following code in the JavaScript editor:

Code Block
strRegion = RS_MANAGERS_REGION.getValueAt(0,0);

...