Camera Connector
Field users are redirected to the Deepomatic camera.
Last updated
Field users are redirected to the Deepomatic camera.
Last updated
The Camera Connector has been designed to redirect users at the camera level in the Deepomatic application. With this connector, user flow follows the following steps:
Users open a work order (or equivalent) page in their field application and start filling out the form (or equivalent).
When clicking on the button to take a photo, they are redirected to the Deepomatic camera.
Users can then take the photo, view the analysis results and report any issue within the Deepomatic interface.
Once they are done, they finally return to their original field application to continue their journey.
The three sections below describe the technical steps and options to create this experience.
In order to send users to the Deepomatic camera, a work order and a work item must have been created in our systems. A work item is the equivalent of a photo expected on a specific work order, there can be multiple work items per work order.
Work orders and work items are created on the fly via the URL redirection. Let's take an example where 2 photos A and B are expected to be taken in a work order :
Redirection on photo A : as it is the first redirection, the work order and the work item (associated to photo A) have to be created.
Redirection on photo B : the work order is already created, therefore you only need to create the work item associated to photo B.
Redirection again on photo A : the work order and work item are already created, therefore you only need to pass the work item associated to photo A. It can prove useful if you need your field users to retake another photo on a specific work item.
Redirection to the analysis view for photo A : the work order and work item are already created. The work item has already been analyzed, but the field users need to see the analysis results.
With this system, there are therefore four scenarios :
Create work order and work item
Create work item within an existing work order
Redirect to an existing work item
Redirect to the analysis view
All four scenarios are described below.
Users start their work and have to take their first photo. The work order is therefore not created yet. The following URL can be used to create both the work order and the work item on which the redirection will be made:
The task_group_name query param is mandatory. It indicates the type of work item to be created and therefore the photo that is expected to be analysed.
The list of the different task_group_name will be provided by the Deepomatic team at the start of the integration. This list can evolve over time: for example, a new type of photo could be added over time.
In addition to the task_group_name, optional query parameters are also available:
work_order_name (string) - name of the work order. If not specified, a value will be set by default.
wo_metadata (base64) - metadata of the work order. Metadata let you store custom data on a per work order basis.
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
state (base64) - parameter that allows you to pass data through the different steps of the flow.
The following parameters will be returned in the callback:
work_order_id (uuid) - id of the work order.
work_item_id (uuid) - id of the work item.
input_id (uuid) - id of the input (photo) analyzed. If several photos are analyzed in the same work item, the input id will be the one of the last photo uploaded.
status (string) - status of the analysis carried out. If multiple analysis are carried out on the same work item, the status will be the one of the last analysis. Four values can be returned :
canceled_picture - users return to their field application before taking the photo.
analysis_ko - at least one task was not validated by Deepomatic.
analysis_ok - all the tasks were validated by Deepomatic.
conformity_error - a conformity error was detected. Comma separated string of conformity messages that happened on the photo, can only happen if the users canceled the picture while retaking the photo, or clicked on the button "Go back". The messages are formatted with the severity level, then the error code then the message, separated by two colon characters (::).
work_item_score (integer, between 0 and 100) - validation score of the work item based on the analysis of the tasks.
state - parameter that allows you to pass data through the different steps of the flow.
The work_order_id, work_item_id and input_id should be stored as they will be necessary for other redirections.
There is some limitation on the amount of information that can be passed through the URL. For maximum compatibility between browsers, keeping the length under 2048 characters is recommended.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
Users have done a first redirection, the work order therefore already exists. If another photo is expected, a new redirection can be made by creating another work item within the same work order using the following URL:
For this redirection, the work_order_id and task_group_name query parameters are both mandatory. The work_order_id is returned in the callback URL after the first redirection (where the work order was created).
In addition to the work_order_id and task_group_name, optional query parameters are also available:
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
state - parameter that allows you to pass data through the different steps of the flow.
The task_group_name is basically a type of work item. For a unique task_group_name, there can therefore be different work items created. For example, users have to take 3 photos of the same type of equipment: in that case, you can do 3 different redirections with the same task_group_name that will create each time a different work item.
The following parameters will be returned in the callback:
work_order_id (uuid) - id of the work order.
work_item_id (uuid) - id of the work item.
input_id (uuid) - id of the input (photo) analyzed. If several photos are analyzed in the same work item, the input id will be the one of the last photo uploaded.
status (string) - status of the analysis carried out. If multiple analysis are carried out on the same work item, the status will be the one of the last analysis. Four values can be returned :
canceled_picture - users return to their field application before taking the photo.
analysis_ko - at least one mandatory task was not validated by Deepomatic.
analysis_ok - all the mandatory tasks were validated by Deepomatic.
conformity_error - a conformity error was detected. Comma separated string of conformity messages that happened on the photo, can only happen if the users canceled the picture while retaking the photo, or clicked on the button "Go back". The messages are formatted with the severity level, then the error code then the message, separated by two colon characters (::).
work_item_score (integer, between 0 and 100) - validation score of the work item based on the analysis of the tasks.
state - parameter that allows you to pass data through the different steps of the flow.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
Users could still need to access an existing work item within a work order: for example, to retake a photo in case of a BEFORE_ANALYSIS redirection. To allow this behaviour, the following URL should be used:
Optional query parameters are also available:
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
state - parameter that allows you to pass data through the different steps of the flow.
The following parameters will be returned in the callback:
work_order_id (uuid) - id of the work order.
work_item_id (uuid) - id of the work item.
input_id (uuid) - id of the input (photo) analyzed. If several photos are analyzed in the same work item, the input id will be the one of the last photo uploaded.
status (string) - status of the analysis carried out. If multiple analysis are carried out on the same work item, the status will be the one of the last analysis. Four values can be returned :
canceled_picture - users return to their field application before taking the photo.
analysis_ko - at least one mandatory task was not validated by Deepomatic.
analysis_ok - all the mandatory tasks were validated by Deepomatic.
conformity_error - a conformity error was detected. Comma separated string of conformity messages that happened on the photo, can only happen if the users canceled the picture while retaking the photo, or clicked on the button "Go back". The messages are formatted with the severity level, then the error code then the message, separated by two colon characters (::).
work_item_score (integer, between 0 and 100) - validation score of the work item based on the analysis of the tasks.
state - parameter that allows you to pass data through the different steps of the flow.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
After a photo is taken and users have returned in their field application, it is possible to redirect them to the analysis page of a specific work item in Deepomatic. To do so, the following URL should be used :
Optional query parameters are also available:
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
state - parameter that allows you to pass data through the different steps of the flow.
The input_id is returned in the callback when an analysis has been carried out. The state is always returned if it has been specified.
In case an analysis is corrected by field users, the additional parameters will be returned in the callback:
status (string) - status of the analysis carried out. If multiple analysis are carried out on the same work item, the status will be the one of the last analysis. Four values can be returned :
canceled_picture - users return to their field application before taking the photo.
analysis_ko - at least one mandatory task was not validated by Deepomatic.
analysis_ok - all the mandatory tasks were validated by Deepomatic.
conformity_error - a conformity error was detected. Comma separated string of conformity messages that happened on the photo, can only happen if the users canceled the picture while retaking the photo, or clicked on the button "Go back". The messages are formatted with the severity level, then the error code then the message, separated by two colon characters (::).
work_item_score (integer, between 0 and 100) - validation score of the work item based on the analysis of the tasks.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
It is possible to set when the users will be redirected to their field application. There are two options:
After analysis (recommended) : users take the photo, view the analysis results and then can go back to their field application.
Before analysis : users are directly redirected to their field application after taking the photo, and therefore do not see the analysis results in Deepomatic.
All data generated by Deepomatic is not directly returned through the callback URLs. In order to retrieve the images and the complete analyses of a specific work order, you will need to use the endpoint to get a work order described here.
