Since Version 6.0


Whenever you need to load data from some internal or external location, you can use a URI to point to such a location. You do so already by using such URIs in your web browser, for example. Common URI types you might be familiar with, are:

  • https://www.google.com

  • ftp://smith:12345@ftp.host

  • file:/data/path/contract.docx

Besides such commonly known URI types, PIPEFORCE also supports custom URI types to simplify access to common resources used internally in PIPEFORCE. Such a custom URI is called a PIPEFORCE URI.

Custom PIPEFORCE URIs typically start with an additional prefix $uri: followed by the concrete uri scheme (type).

They typically have a format like this:



  • <name> must be replaced by the type name of the URI to be used such as drive, property, pipeline or similar for example (see below). It is the implementation type of the URI.

  • <path> must be replaced by the path or value which will be passed as input value to the URI implementation.

  • <params> is optional an can contain parameters in the format ?param1=value1&param2=value2.

In most locations where a URI is accepted as an argument, for example in commands or utils, you can apply such a PIPEFORCE URI.

Here are some examples of common PIPEFORCE URIs:






Loads a file from the drive data room.


Loads a property value from the property store and also all property metadata such as uuid and created time for example.


Loads only the value of a property from the property store.


Executes the persisted pipeline at given location and returns the final body content as result.


Executes the persisted pipeline at given location, passes the given parameters firstName and lastName to it and returns the final body content as result. The parameters can be accessed via the vars scope inside the pipeline.


Returns the information object of the given user with given username.


  • Returns the information object of the given user with given uuid.

Here is an example to apply a custom URI on a command:

pipeline: - mails.send: to: recipient@mail.tld subject: "Hello!" message: "Hello World!" attachments: $uri:property:global/app/myapp/resources/file

As you can see in this example, the attachments argument contains a PIPEFORCE URI pointing to a property in the property store. This property will be loaded and added as an attachment.

And in this example, a PIPEFORCE URI is used inside a PEL util instead:

pipeline: - body.set: value: ${@resolve.uri('$uri:drive:/someFolder/document.json')}


You have multiple options to resolve a PIPEFORCE URI: Resolving an URI means, loading the content this URI is pointing to.

By command

In case you use a PIPEFORCE URI as parameter to a supporting command, this URI will automatically resolved to its content data by this command, as you could see by the previous example:

By resolve command

In order to explicitly resolve a PIPEFORCE URI, there is a special command resolve for this, which can resolve any URI and returns the content of it.

You can use it in a pipeline like this:

This example will return you the full property (metadata + value) of the given property path. For example like this:

In order to return only the value of a property, you can use the $uri:property-value scheme instead:

This will return only the value part of the property as JSON:

And if you would like return only the title text of the JSON property value, you can use the # symbol which let you query the content of the returned JSON value by applying a PEL on it. For example:

This would return:

In case you use the # symbol as request parameter, you need to decode it before sending. Otherwise the server would strip it off. Alternatively, you can send the URI in a POST request, form-data encoded in the body. In this case, no encoding is required.

Here is an example how to use this command with curl on the terminal with URI encoded parameter (the symbol # is encoded to %23):

By the @resolve.uri util

Another possibility inside a pipeline is to use the @resolve.uri function:



This custom URI points to a file on the data room service drive.



This URI can be used to execute a persisted pipeline, and return the final body output of this pipeline as a result.

Let's assume you have a pipeline like this stored at global/app/myapp/pipeline/hello:

To execute this pipeline and to output this hello world example, you could execute a URI like this:

In this example the URI parameter name is used inside the pipeline as variable name.

This will create a log-entry like this:

Adhoc Pipeline URI

You can use the $uri:pipeline scheme also in order to execute an adhoc pipeline. This is a combination of commands to be executed in serial, one after another from left to right. The format is like this:

This approach is handy in case you would like to call one or more commands in serial without persisting a pipeline for this.

The path part of the URI is empty and only the query string is given, starting with ? whereas the name of a query param is the name of the command. The optional query param value contains the parameters to the command whereas name and value is separated by a colon : and multiple params are separated by by a semicolon ; . For example:

In case a command parameter is a default command parameter, it can be used without any parameter name prefix in the URI. So the example from above can be simplified to this:

Since uri of command uri.get and query of command data.filter.jmespath are default parameters, these parameter names can be skipped. But this must be then the only parameter given to the command. If you need more than one parameter per command, the pipeline must be written including the parameter names.


This custom URI points to a property in the property store.


Will return the property including metadata and value like this example:


This custom URI points to the value of a property in the property store:


Will return the value of the property as JSON:

Value Filter (JSON)

In case the value of a property is of type application/json, you can apply an expression filter on the value in order to return just a subset from the JSON:

This filter only works in case the value of the property is of the type: application/json!

Let's assume we have a property in the property store like this:

We can use a value filter in the property URI in order to directly return the name of the person, like this:

Which will return a value like this:

It's possible to use the full power of the PEL to filter, for example:

Which will return a value like this:

The value filter will be applied on the fully loaded property value attribute: It will be converted to JSON and then the expression will be applied, then the resulting value is returned.


This uri is handy to load a user object given by a username or uuid.


For example:

This will return the user-info data similar to this:

The same is true when using the uuid of the user: