In this demonstration we will use /GetProduct_v1 Post endpoint. We will try to implement it as close to the specification as we can. Let's start by creating the Linked Process from the API view.

At the beginning we have only the bare minimum of the Process itself. The Trigger is watching the Post endpoint which we specified in the API specification. Let's take a closer look of those Elements Frends added automatically.

The Trigger Element is named as is the endpoint with the API's base URL included. As you can see the Trigger type is locked and cannot be changed after API has been selected. This is the same behavior as is when creating a regular Process. You can view the API specification by pressing the Open API specification button. This way you can reassure that the correct one is used.

The URL, Allowed protocols and Authorization has been set as is in the API specification. However you can change the Allowed protocols to accept HTTPS or both HTTP and HTTPS.

If you have a need for the API Trigger to accept requests from certain page you can enable the cross-origin resource sharing (CORS) by setting the parameter "Allow requests from these origins (CORS)" on. You can then set the origins in the input field below. Multiple origins can be set by separating them with colon(,) or semicolon(;). You can also allow requests from all origins by using asterisk(*) character.

When scrolling down in the Trigger's parameter editor you can set the API Trigger to be private which will disable the accessibility on API Gateway.

The Return Element has been configured to be a HTTP Response type automatically. As you can see the Http status code has been set to 200 as is in the API specification. Because there was no response content set in the API specification the Http content parameter has been left empty in the Return Element.

API Trigger has multiple variables which can be referenced with the #trigger.data reference. These variables holds crucial information of request body, headers, path and query parameters, client IP address etc.

Frends API enables you to specify which headers are required when making the request to that Frends API such as Authorization, Content-Type ect. These can be specified in the API specifications. To specify headers in the API you need to add headers in the parameters object and using the in property as "header". Required property specifies whether the API Trigger will need the parameter to allow the connection.

You can also list optional header parameters here by stating required: false or leaving the required property out all together. The API Trigger will allow connection even if these are not present in the request. However you can handle these headers inside the Process.

When using this endpoint as a Trigger in Process, you can reference the header with #trigger.data.header.test reference. This allows you to extract the value put in that header in the incoming request. This feature is crucial especially with query and path parameters.

In the API specification both path and query parameters are specified by adding them to the request parameter list. Path parameters need to have in: path and query parameters in: query property. When using path parameters you also need to specify the endpoint to include path parameter like shown in the picture below. Note that path parameters need to always be required: true. The Swagger editor will give error if that property is not set. Query parameters can be both required and optional.

You can extract the query and path parameters from the request by referencing either #trigger.data.path or #trigger.data.query and adding the parameter name to the reference.

For this Process to become a functioning one, we need to connect the Elements together using the Global Connect Tool and we need to add the functionalities to the Process. Usually the first thing is to parse the HTTP Body from the Trigger into something we can more easily use inside the Process. This can be done by parsing the body into a JToken:
​

JToken.Parse(#trigger.data.body)

This can be done using a Expression Element.

Remember to assign a variable for us to use in following steps.

When the HTTP Body is parsed into a JToken, we can use dot notation on the properties inside the JToken. We can for example add a statement Element which validates that the input is valid or with the help of Decision Elements to determine what needs to be done to the contents.

However when dealing with GET HTTP methods the request body should not have any semantic value. Therefore in this case we need to extract the query parameter from the incoming URL. This can be done by referencing #trigger.data.query.. In this example we will extract "prod_code" named parameter so the correct reference is #trigger.data.query.prod_code. We could put the reference directly to the next Task but in this case we want a manual Trigger as well so the Trigger query parameter needs to be set to a variable.

Here we can determine whether to use the actual path query parameter or the manual Trigger parameter.

Next in this demo we can add SQL Task to the Process which will query the wanted data from the database to be processed in the Linked Process. You can choose the Task Element from the Toolbar in the left side of the Process Editor or use the Quick tool which is visible when the previous Element is selected.

Let's add the Task Element into the Process and select the MicrosoftSQL.ExecuteQuery Task. This will, in this example, fetch the data which we will then map into JSON format and send either back to the requester or some other system with the API Linked Process depending on the business need.

In the Task we can use the #var.code variable we created from the Trigger's query parameter.

After the SQL query we can check if any data was returned from the database. This can be done by adding a Decision Element after the SQL Task and check if the Data property has any values. The MicrosoftSQL Task returns Data property which is a JArray type. If the Task doesn't find any rows from the database it will return empty JArray []. This will enables us either to check the Count of the JArray: #result[Get data from DB].Data.Count > 0. If no rows were found we can use one of the failed responses. Otherwise we can continue to the data mapping.

The data mapping means that we are trying to modify the structure of the JSON to better suit for the receiving end system. This means we need to create a JSON string with correct property names and values. The most simple way to do it is to use a Task Frends.JSON.Transform.

First we need to get a single JToken from the JArray and in order for us to do so we need to add a loop to the Process. Let's use Foreach Element for that.

You can name the Variable which we are iterating in the Foreach as you see fit and we can set the Data property returned from the MicrosoftSQL Task directly to the Expression. This is enabled because the JArray which is returned from the Task is Enumerable object which we can iterate through.

We can then add the Transform Task inside the Foreach Element and configure it as we see fit.

Here we are giving the Task the variable value of the iterated product which is a JToken. The Task handles the mapping for us and we can set the property names easily for the new JSON. However when we are iterating through a large data set we need some other variable where we store the mapped values. For this we need to add a new variable before the Foreach Element. Let's just create new variable named products and set it's expression to new JArray().

Inside the loop we need to add the mapped JToken to that variable products. The JSON.Transform Task returns the mapped dat as a JSON string and in JToken form. We can simply add an Expression Element and set the expression inside it to #var.products.Add(#result[JSON Transform].JToken). This enables us to use the whole mapped data in later state of the Process.

Finally we can either return the mapped data back to the requester or send it to a receiving system. In this demo we will just return the data with the HTTP Response typed Return Element. In order for us to pass string value to the Return Element we need to call ToString() method on the JArray we created. This can be done inside the Return Element

The final Process will look like this run with the Manual Trigger:

The next article is Example on How to test and debug a Linked Process.