In this article we will describe the process for creating a simple workflow from scratch.
...
If you have never set up a workflow before we encourage you to follow the steps in this guide for practice, to create a simple workflow with the Test app. Since the Test application just uses dummy data there is no risk involved.
To do so:
Add the Test application to your account, as shown previously in step 1.
The Test app does not require any API credentials to be entered - simply add it to your account.Then proceed to create a new workflow from scratch, and copy the steps shown in this article.
...
These are the steps we will go though:
Select the app(s) to use in the workflow
Add the blocks that we need
Configure the blocks for our purpose
Configure the mapping
Select the app(s) to use in the workflow
Choose the apps you want to connect in the list on the left.
In our case we will just be using one app, the Test app, both for getting and posting data.
...
After clicking the button (“Use single” in our case, otherwise labeled “Connect”) you will be presented with the workflow editor.
In the next steps, we will:
...
Add the blocks that we need
...
Configure the blocks for our purpose
...
Adding blocks
Next we will add the blocks that will make up the workflow logic. A As explained previously, a block is a re-usable, modular piece of code that executes one or more tasks.
On the left, you will see a list of available blocks for the applications you have selected, as well as several generic blocks, including Mapper, Code and Join. (These will be are described in more detail in separate articles, here.)
To start building the workflow, simply drag and drop the blocks you want onto the canvas.
In this exampleFor our demo workflow, we will need the following three blocks:
...
For our demo workflow, we will need:
A block to fetch employees from Talent Managerdata (from the Test API).
A block to update employees in Quinyx.A mapper block to map data and fields between the two applicationstwo data formats
A block to update employees (in the Test API).
...
Configure the blocks
Now that the blocks have been added, we need to configure them to our needs.
If you click each of the blocks on the canvas, you will see each has the available block settings (under the “Working Area” tab) that allow for each block, which lets you to customize how the block works, with some fields being functions. Some of these settings are marked as required information, with a red *.Next we will look at setting up the mapping, using the mapper block.
...
Configure the following settings:
For the GetEmployees block, set “Amount to obtain” to 10, to limit the block to fetch data for 10 employees
For the Mapper block, set the source to be the GetEmployees block, and the target to the Post Employees block
For the Post Employees block, set the Datasource to be the Mapper block
Now is a good time to save the changes you have made. Click the save icon to save your workflow.
Next we will look at setting up the mapping, using the mapper block.
The Mapper block
Data coming out of one application will need to be reformatted before it is transferred to the destination application. That is where the Mapper block can be used.
The Mapper block lets you transform data and map fields between a source and a destination application.
| Info |
|---|
Please note that the Mapper block is currently a work in progress, so you can expect the Mapper block to gain more features and improve going forward. |
Select the Mapper block, and click the “Map model” button.
When we click on Map Model, the Mapper block will ask the source and target blocks to give examples of the kind of data they use. The mapper block will use this information to dynamically construct a mapping screen.
...
(You will see a green checkmark appear next to the GetEmployees block as data is pulled, before the mapping screen appears.)
...
The mapping screen can be thought of as a spreadsheet with two columns – one for the source application, and one for the target application. By simply clicking on the connecting corresponding fields, you are building a map for how data should be transformed. And like in a spreadsheet, you also have the possibility to use functions, to concatenate fields, put things to upper case, date manipulation, etc.
Expand the area on the left, and the Target column on the right, as shown in the screenshot.
You can now drag and drop fields from the area on the left into the Source column, to specify how fields will be mapped to the Target column.
But you may notice you are not able to map the zip code field directly, because of a type difference:
...
The zip code field has a string type in the source model, but a number type in the target model:
...
To fix this we must change the type for this field, by clicking the little pencil icon.
...
You are now able to also map the Source zip field to the Target zip field.
Save the mappings, and then save the workflow.
...
So, to summarize, this workflow is going to get (dummy) employee data out of the HR app, we are going to map it based on the mappings we created, and then we are going to load it into QuinyxTest API, remap it (into an identical data format), and then upload the employee data back to the Test API.
Let’s run it!