Using Velocity

Velocity is a template engine used internally by DATPROF Runtime to parse and execute code. As an Apache project, you can learn more about it at Apache Velocity.

DATPROF Runtime projects generated by DATPROF Privacy and DATPROF Subset use Velocity templates, which are parsed using the Velocity syntax. These templates are then processed, and any plain SQL output is executed immediately.

In addition to internal templates, all SQL and OS scripts are also parsed using Velocity before execution. Scripts that do not contain any Velocity elements remain unchanged.

When working with Velocity templates, you can refer to various properties using the following syntax: ${identifier.property}

For DATPROF Runtime, all runtime parameters can be accessed using the dpf.parameters identifier. For example: ${dpf.parameters.DPF_RUN_DATE}

This enables dynamic content generation in your templates and scripts.

As of Privacy 3.9.0 and Subset 3.4, you can choose whether a script is parsed using Velocity or not. This flexibility applies to different components depending on the DATPROF product:

In DATPROF Subset, this includes the parsing of additional OS scripts, SQL scripts, as well as the startfilter and any additional filters.
In DATPROF Privacy, this applies to additional OS scripts, SQL scripts, as well as expressions and conditions.
In DATPROF Integrate, this affects the parsing of OS calls, SQL actions, and the coding in any other action.

To prevent specific parts of your code from being parsed by Velocity, refer to the Velocity Comments section for instructions on marking content as Unparsed Content. This allows you to control which sections of your scripts should bypass the Velocity parsing process.

Velocity properties can be highly effective for generating dynamic content in your reports. For example, you can log specific information to a file that will be available as a downloadable artifact in the Run History:

CODE

echo Run started on ${dpf.parameters.DPF_RUN_DATE} > ${dpf.parameters.DPF_ARTIFACTS_DIR}\MyLogfile-${dpf.parameters.DPF_RUN_ID}.log

This example uses Velocity properties to log the run date and run ID into a log file, which can then be accessed as an artifact.

DATPROF Parameters

In your scripts you can refer to the internally used DATPROF parameters by using this Velocity property syntax. They are all strings.

General available properties

Parameters	Value
${dpf.parameters.DPF_APPLICATION_NAME}	The name of the application.
${dpf.parameters.DPF_APPLICATION_VERSION}	The version of the application.
${dpf.parameters.DPF_ENVIRONMENT_NAME}	The name of the environment the application is running in.
${dpf.parameters.DPF_PROJECT_NAME}	The name of the project the application is installed in.
${dpf.parameters.DPF_RUN_DATE}	The date the current run of the application is started in the format YYYY-MM-DDT:HH:mm:ss:SSSZ Example: 2018-08-02T07:06:03.840Z
${dpf.parameters.DPF_RUN_ID}	The ID of the run.
${dpf.parameters.DPF_RUN_SCENARIO}	The selected scenario for the current run of the application.
${dpf.parameters.DPF_ARTIFACTS_DIR}	The location of a run the Run History screen will look in to list the the artifacts. Files in the Artifacts folder will show up as downloadable files in the history log view of DATPROF Runtime.
${dpf.parameters.DPF_SCRATCH_DIR}	The Temp dir location for this run.

In DATPROF Integrate defined parameters become Velocity properties

You can refer to your own defined DATPROF Integrate parameters by using the dpf.parameters identifier.

Example: ${dpf.parameters.DATA_INPUT_DIR}

DATPROF Runtime Velocity methods

There are 4 Velocity methods available you can use in your scripts/code. They enable you to run OS specific code in your application,

Method	Return	Explanation
$dpf.os.getenv("<ENVIRONMENT_PARAMETER_NAME>") example: $dpf.os.getenv("PATH")	String	Returns the value of the requested Parameter. Empty if not found. Enclose Parameter in "Double Quotes".
$dpf.os.isWindows()	Boolean	Returns 1 if on Windows, else 0.
$dpf.os.isUnix()	Boolean	Returns 1 if on Unix/Linux, else 0.
$dpf.os.isMac()	Boolean	Returns 1 if on Macintosh, else 0.

Velocity comments

In Velocity, single-line comments are identified by ##. However, this can conflict with the naming of Microsoft SQL Server Global Temporary Tables, as they are also referenced by ##. For example, the following SQL statement would cause issues in DATPROF Runtime:

create table ##test (X int, Y int) ;

To prevent this from being interpreted as a comment, you need to explicitly tell Velocity not to parse this content.

Velocity provides a way to specify a block of code as Unparsed Content. To do this, enclose the block of code with #[[ and ]]#.

Example:

Original SQL statement:

create table ##test (X int, Y int) ;

To prevent Velocity from parsing it as a comment, use Unparsed Content like this:

#[[ create table ##test (X int, Y int) ; ]]#

This ensures that the content is executed as-is without being parsed by Velocity, preventing any interference with SQL Server's global temporary table syntax or other instances where ## is used.

Example to check on three empty fields.

Original SQL statement:

select a.* from customers a where concat( a.x , '#' , a.y , '#' , a.z , '#' ) <> '###'

Use Unparsed content:#[[ select a.* from customers a where concat( a.x , '#' , a.y , '#' , a.z , '#' ) <> '###' ]]#

Or avoid using them:

select a.* from customers a where concat( a.x , '~' , a.y , '~' , a.z , '~' ) <> '~~~'