Let’s look at the basic principles of working with data in filters and scenario steps.
These are the main points:
Now, let’s move on!
Each and every filter or scenario step works with on object from a particular data structure. For example, the security conditions in an API configuration deal with the ‘App users’ structure, and the scenario step processes the target structure element within it.
We’ll find two types of input here:
First—a simple ‘select object’ field, like this.
and second—a text input space where we can write an expression using object fields.
Let’s have a look at how it works using our old friend, the book-related example.
Here—is an area for the expression.
and there—is a sample object, a book, along with a few properties:
And we’ll see the result here.
OK, let’s type something in. Then… we can check!
Let’s add an object field to the expression. Here we use the template mechanism, inserting the system name of the field surrounded by double curly braces.
There’s also a technique for checking a boolean property value. Here it is: this string is shown if the field ‘is classic’ equals ‘true’, or this one — if it equals ‘false’.
We can also include the properties of a linked object. Choose the link-field – dot – and then a field system name. In our example, we can insert, for example, the author’s first name. Don’t forget that we can use as many linking levels as we want.
Working with arrays, dates and JSON is a bit more complicated and we’ll explain the techniques for dealing with them in future tutorials. Also, feel free to explore the platform documentation where you’ll find lots of detailed descriptions and examples.
In addition to standard JS-features there are also a few unique Directual functions we can use. You’ll find more about them in the documentation and of course in future tutorials on the platform SDK, or software development kit.
There is a system data structure called ‘App global constants’ that contains records, which can be requested from any scenario in the app. These are global variables (actually, we can’t change them from within a scenario, so these variables - once in a scenario - really become constants).
Developers usually use them to storing an app’s general parameters, like URLs, emails, or passwords. To request a global variable we use the ‘Template system, and insert ‘GlobalVar’ - dot – then the variable ID.
A scenario may include a few local context variables. We can create a list of these variables in a ‘start’ step configuration. We also set up the variable type and default values .
The way we request context variables is similar to the process used for global ones, by typing ‘ContextVar’-prefix - into a template.
We usually use context variables when run a scenario by ‘link scenario step’. This step configuration includes the list of variables from the selected scenario. We can think of all of these variables as parameters.
The essential feature of a context is that it has a unique value for every scenario that’s run.
There are two particularly useful features in the templating Directual interface.
First. A button to add the templated value. Here we can choose the object’s field, global and context variables, or choose the linked object properties.
Second. A tool to check the expression. It works just as you’ve seen it in this video-tutorial. Here we have to indicate the ID of the object to be processed and (if there are any) all the context variable values.
Have questions? Visit our community forum.