Add a native API on top of a workflow

Search…
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.
Field Services 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. 
Assembling workflows
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
workflow:
    entries:
        - name: image_input
          type: Image
        - name: checkpoint_previous
          type: Text
    outcomes:
        - name: checkpoint
          output_of: my_step_that_checks
          concept:
            name: status of the thing that needs to be checked
            type: Text
With the above workflow, you are able to use the value of the checkpoint in the execution of the workflow. 
Custom step
Manage cameras as input for your workflow
Last modified 1mo ago
Copy link
Outline
Defining API checkpoints through a workflow
Adding memory in the intervention process