Customizing start nodes
Start node is a special node of services that triggers the service execution and provides input parameters. The start node configuration can change based on the type of service you are creating.
Endpoint service start node
Endpoint services are triggered when a request is sent to the associated RESTful API endpoint. Endpoint start node receives all request parameters (body, headers, query string parameters, endpoint path identifiers) and additional system-generated data (e.g., session object if endpoint requires a session token and device information). It provides this data to the connected node input link points through is output link point. The following is the list of data that can be injected into an endpoint start node.
.png)
Name | Description | Example |
---|---|---|
ids | Endpoint path id parameters | If endpoint path is defined as /supplier/{supplierId} then this parameter keeps the value of supplierId |
query | Endpoint path query string parameters | If endpoint path is defined as /supplier/{supplierId}?type=steel&country=US then this parameter keeps the value oftype andcountry |
headers | Request header parameters | If the RESTful API request has additional headers, then header data is provided through this request parameter |
appParams | System generated parameter | If the app has a param named MIN_ORDER_QUANTITY then this parameter keeps the value of this parameter |
client | System generated parameter | Provides device type (e.g., mobile, desktop) and device IP information |
session | System generated parameter | If the session is marked as required for the endpoint, then this parameter provides the session data (e.g., session date, user id, token) |
files | Named file uploads | If the request has file uploads named logoSmall and logoBlack then this parameter keeps the data of the uploaded files |
filesList | List (array) of file upload | The same uploaded file information is provided as an array, without names, e.g., [logoSmall, logoBlack] |
dbTransactions | List of database transactions | If the endpoint service will be using database transactions, then this parameter keeps the created database transactions |
body | Request body data | If the endpoint has body data, then this parameter provides input data. Request body can be a single or an array of objects, or it can be a list of name-value pairs |
The endpoint service start node has the following configuration parameters, aligned with a RESTFul API request.
- Request body - You can select to specify whether the service will have any request body input, have just an object or list of objects from a single mode, have multiple name-model pairs, or have a custom transient model object.
- Single model - If you select a single model as a request body, you can either pass a single object or an array of specified model objects as input to your endpoint service. The count parameter specifies whether you pass a single object or an array (multiple)
- Multiple different models - If you select multiple different models, you provide a list of model object(s) that will be passed to your endpoint service as name-model pairs. In the example below, assuming that we have two models, one for products and the other for suppliers, we can pass a product and an array of suppliers as request body input parameter to our service using name-model pairs. "item" used as the name for a single "product" model object and "providers" used as the name for multiple (array) "supplier" model objects.

- Custom transient model - If you select the custom transient model option then you can define the model of the input object. This option is quite handy if you would like to define a specific model for the input of the endpoint and you do not need to define it in the "Models" view.
- Database transactions - If you plan to have a database transaction in your service, you define all transactions in the start node and access them from database nodes that support transactions.
Messaging service start node
The configuration parameters of a messaging service start node are as follows:
- Message body - A messaging service processes the input message sent through the message queue. The message body is similar in structure to an endpoint service request body with multiple different models (please see above). You provide the list of model object(s) that will be passed to your messaging service as name-model pairs. In the message body, you can also pass looked up object reference field values.
- Database transactions - If you plan to have a database transaction in your service, you define all transactions in the start node and access them from database nodes that support transactions.
Task service start node
The configuration parameter of a task service start node is as follows:
- Database transactions - If you plan to have a database transaction in your service, you define all transactions in the start node and access them from database nodes that support transactions.