Services

Services are used to enable workflow automation in your solution. Services can be thought of as apps without a user interface.

A service can be used to:

• Receive data from an external service, for example sensor data, or new orders.

• Send data to an external service, for example to update inventory or generate invoices.

• Process data on a set schedule, for example to generate reports or send notifications.

As with apps, services have data sources and actions to process data and perform logical operations. In order to trigger these actions, services are exposed via an interface known as endpoints.

Important

For services to run in a given environment, the Enable API Services checkbox must be selected in the Environment configuration.

Endpoints

Endpoints are the external interface of a service. They parse the request, trigger an action, and facilitate which data is returned.

An endpoint can be called from an external application or by a schedule configured to run at specific times. Service endpoints can also be called from apps and other services in your solution.

An endpoint has a URL and one or more HTTP methods which together make it unique in your solution. The URL and appropriate method are used by external services to call the endpoint.

Service Endpoints

Data

Data sources are configured in the same way as for apps. Both database-connected and runtime-only data sources are supported. They can be referenced in actions, as well as used to map request and response data in an endpoint.

One key difference to be aware of compared to apps is around performance. Each time one of the service's endpoints is called, all database-connected data sources are filtered and re-evaluated. If you need to use database-connected data sources in your service, you should limit the number of endpoints and instead spread the functionality across multiple services. We recommend using runtime-only data sources to read data from the database in order to limit the performance impact of this pattern.

Service variables, the equivalent of app variables, can also be created. The built-in variables expose the active environment and hostname.

Data

Actions

Actions for services work in the same way as actions for apps and are primarily used to process data and send web requests. One key difference is that actions in services are run on the server, while actions in apps are almost always run in the browser. There are some action nodes that are exclusive to services, such as Update secret and others that are not available, for example Navigate.

In a service an action is triggered by specifying it as the Process Action in an endpoint. This primary action can also trigger other actions using the Run Other Action action node.

Actions

Testing and debugging

You may inspect execution logs and test Services with the DevTools for Services. Also, all Service Endpoints are automatically documented in a Swagger inteface, as documented in the API explorer article. You may also find this guide on Testing and Debugging helpful.