Deepomatic Platform
Search…
v2.0.1
Deepomatic Drive
Deepomatic Engage
Security
Add a native API on top of a workflow
For augmented technician use cases, you probably need to create an API on top of your workflow to be able to integrate this API into a Field Service Management tool. Deepomatic platform offers an off-the-shelf component that automatically add an API to your visual automation application. See below for the specifications of the API.
To build solutions to complex problems, you need to tightly connect your workflow and business logic with this API, which is ultimately the interface with which the technician's application interacts.
Defining API checkpoints through a workflow
KEY TERMS
An intervention is a set of elementary tasks that must be performed by a field technician. These tasks are related to one or more photos that are requested from the technicians. End-users can also specify other parameters (a category, a number, etc.)
A question in this context refers to a specific checkpoint that can be validated via the Deepomatic application. There may be several checkpoints to be validated on a single photo, or conversely there may be several photos needed to validate a single checkpoint. The most basic checkpoint is the presence of a certain type of photo requested from the field technician, but much more complex checkpoints can be implemented in your Deepomatic application.
An answer in this context corresponds to the current state of a given control point for your intervention. It is built from the aggregation of the results of the workflow executions.
A checkpoint is then defined here by a question and its current state is given by the corresponding answer.
You define the checkpoints in your application with the outcome steps in your
workflow.yaml file. When calling the API, you get the answers for the questions that generate an output in your workflow. See the integration of the API for the exact data format.
Adding memory in the intervention process
The traditional way of conducting field interventions is that once a control point has been validated, it can no longer be invalidated. To implement this logic, but also to build solutions to more complex problems that require different photos to validate a control point, it is necessary to introduce the notion of memory and of state of an intervention. The state of an intervention is indeed very often determined both by the result of a workflow execution, but also by the past state of the intervention.
To access the current values of the state of your intervention, you must define entries according to the following nomenclature: <outcome_name>_previous. At each workflow execution, this entry's value is the current answer/outcome for the corresponding intervention.
Workflow with memory
1
workflow:
2
entries:
3
- name: image_input
4
type: Image
5
- name: checkpoint_previous
6
type: Text
7
outcomes:
8
- name: checkpoint
9
output_of: my_step_that_checks
10
concept:
11
name: status of the thing that needs to be checked
12
type: Text
Copied!
With the above workflow, you are able to use the value of the checkpoint in the execution of the workflow.
Last modified 1mo ago