Welcome Guest! Log in
Due to some maintenance operations, stambia.org will be switched to read-only mode during the 13th November. It will be possible to read and download, but impossible to post on the forums or create new accounts. For any question please contact the support team.


Metadata Variables may be used to store persistent values and re-use them. They are a powerful way to define and use global variables in several processes.

In this example, we define a "START_DATE" variable, which we can read and write among different processes.

The principle is that:

  • the variable value is stored in a database table
  • any process can read / update the variable value

Setting up the Metadata

Database schema

We choose to store the variables in the Runtime's log database schema. In our example it is the default H2 Database.

Of course you can choose any database schema of your choice.

The Runtime will simply create a table named "IND_SESSION_VARIABLE_VAR" into this schema (we will see the table content later in this article).

279 01

  • Driver: org.h2.Driver
  • Url: jdbc:h2:tcp://localhost:42100/sessions/internalDb/sessionLogs
  • User: sa

This Database metadata only needs the server and schema nodes (no table needed).

Variable Set

Now, we create a Variable Metadata file and we add a Connection node to it (Right click on the Set / New / Connection). 

We named it "RuntimeLogSchema".

And then we drag and drop the LOGS schema into this RuntimeLogSchema Connection node.

Finally we create the variable with these properties:

  • Name: START_DATE
  • Saving Connection: Set.RuntimeLogSchema
  • Type: String
  • Default Operation: SetToSavedValue

 279 02

Using the metadata in processes

Init Start Date process: one shot initialization

For future use, we need to initalize the variable so that it is registered into the database.

So we simply drag and drop the variable into a new process, and configure the action like this:

  • VAR_OPERATION: SetValue
  • VAR_VALUE: 2001-01-01

After execution, we can see the Variable in the Session's variables (at the bottom):

279 03

 

And we can also see the variable in the IND_SESSION_VARIABLE_VAR table:

279 04

 

A few words about this table's columns:

  • VAR_NAME is full technical name of the variable.
  • VAR_TYPE is the variable type
  • VAR_NO_LINE: when the value is a long string, it may be written over several rows (depending on the database's varchar max size). Usually there is only one line.
  • VAR_VALUE: the value
  • VAR_CONF: the configuration which applies. Note that a variable may be stored with one value per configuration in the same table.
  • VAR_DATE: when the variable was last saved
  • VAR_SESS_ID: the session that did the last save

LoadCustomerOrders process: reading the variable

Now, we can develop processes which rely on this persistent variable.

This process only reads the variable value and uses it. It does not modify the variable value.

The "START_DATE" action was created simply by drag'n'droping the Variable in the process. The default operation applies (SetToSavedValue, as we chose in the metadata definition).

"Load data" is a subprocess where we use the variable, for example see the parameter "ReportTitle" using %{START_DATE}%, and see its value at the bottom right of the screenshot:

 279 05

 

 PublishInvoices process: updating the variable

This process first loads the variable value, and uses it (somewhere in the subprocess).

And finally, the "START_DATE Update" step is changing the variable value. Here is how this step is set:

  • VAR_OPERATION: SetValue
  • VAR_VALUE: %x{md:formatDate("yyyy-MM-dd")}x%    (this is a tip to produce the current date with the specified date format)

 

279 06

 

As you can see at the bottom left, after execution of the final step, the variable value has changed.

And we can see this also in the table:

279 07

 

 

You have no rights to post comments

Articles

Suggest a new Article!