Skip to main content

Introduction

A variety of services are running on the device, each having its own specific area of responsibility. Most services are built around the same structure and using the same concepts which are described below.

note

Services can be setup and configured from the AutoPi Cloud. When logged in go to: Device > Services

Settings#

At startup, a service is initialized with the given settings. They vary between different services but usually contains connection strings, timeout threshold etc.

Workers#

Within a service multiple worker threads can run. Each worker is setup to process one or more workflows sequentially for a limited period of time or indefinitely.

Available options for a worker instance:

FieldTypeDescriptionDefault Value
nameTextSystem name to identify the given worker.-
delayDecimalInitial delay in seconds before starting the worker. No delay if left empty.-
intervalDecimalPause in seconds between each run. Enter 0 if no pause.1
loopIntegerHow many runs should the worker do? Enter -1 if infinite.-1
suppress_exceptionsBooleanSuppress errors/exceptions so that they do not kill the worker thread?True
kill_upon_successBooleanKill the worker thread after the first successful run? Successful means that no errors/exceptions occurred.False
transactionalBooleanEnsure that consecutive workflows are processed in an uninterrupted sequence and not potentially mixed with others from other workers?False

Workflows#

A worker can process one or more workflows in a sequence. A worflow consists of a number of steps. The primary step of a workflow is called handler and is always required. Then more steps may occur both before and/or after, and are not normally required. At present, there are two built-in workflows. Below is an overview of the steps in the first workflow called simple:

handlerโ†’triggerโ†’filterโ†’returner

And secondly the extended workflow:

validatorโ†’handlerโ†’converterโ†’triggerโ†’filterโ†’enricherโ†’returner

Each step in a workflow has a defined area of responsibility:

StepDescriptionExample
validatorValidates the request and decide whether or not to proceed to the handler.-
handlerProduces a result typically by interacting with an external device or system.See
converterConverts the result returned from the handler into a more usable format.See
triggerDecides whether to trigger an event based on the result.See
filterFilters out result if insignificant.See
enricherEnriches result with additional information. Could for example be calculations.See
returnerReturns the final result to an external system or service.See

Reactors#

Coming soon...

Hooks#

Coming soon...