PIPEFORCE URI
- PIPEFORCE
Since Version 6.0
What is a PIPEFORCE URI?
Whenever you need to load data from some internal or external location inside an automation pipeline or a command, a form, list or report, 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.comftp://smith:12345@ftp.hostfile:/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:
$uri:<name>:<path><params>Whereas:
<name>must be replaced by the type name of the URI to be used such asdrive,property,pipelineor 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¶m2=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:
URI | Description |
|---|---|
| Loads a file from the |
| Loads a property from the property store and returns the |
| 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 |
| Returns the information object of the given user with given username. |
|
|
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/fileAs 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')}Resolving a PIPEFORCE URI
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:
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:
PIPEFORCE URI Types
$uri:drive
This custom URI points to a file on the data room service drive.
Example:
$uri:pipeline
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
DEPRECATED SINCE 10
Note that this approach is deprecated since version 10 as pipelines are no longer allowed to be called adhoc by default for security reasons.
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.
$uri:property and $uri:property-value
This custom URI points to a property in the property store.
Example:
or
Will return the property including metadata and value like this example:
In case
is used instead. The value part of the property is returned instead, without any metadata:
$uri:user
This uri is handy to load a user object given by a username or uuid.
or
For example:
or
This will return the user-info data similar to this:
The same is true when using the uuid of the user:
or
As an alternative you can also use these approaches if required: