Use-case description

In various situations it might be necessary or beneficial to interact with other systems from within a work instruction or checklist. This requires a trigger from within the platform, which starts the corresponding process and propagates the information.

Operations1 offers two mechanisms to achieve this:

• The "Request Information" interaction, which allows the executing user to initiate the process. For details and configuration see: External request interaction
• Webhooks, which trigger at certain events, like entering a value, update a task or complete a report. For details and configuration see: Webhooks

Specific use-cases for such an integration could be:

• Starting an automated process (for example with an automatic screwdriver) and return the result
• Retrieving values from an external device or database (for example machine parameter)
• Executing calculations based on already entered data
• Sending information about required material to a Pick-by-Light software
• Requesting machine information in real-time

Depending on the circumstances this could mean different stages of complexity.
The following pages introduce some options to start with such an integration.

Overview

This use-case runs through 3 main steps:

Receive data from Operations1: cloudbased

If you can provide an entrypoint, which is accessible through the internet, you can directly trigger an integration from the Operations1 platform through webhooks or an external request. The architecture looks like this:

Important information

The cloudbased mechanisms:

• require that your endpoint is accessible by Operations1 from Azure independen how you implement it.
• can be used for system events through webhooks.
• can be triggered by a user through external request

Implementation

You can receive the data for example in a Microsoft PowerAutomate flow, as desrcibed here: How to Create a Power Automate Flow for Operations1 Events

Receive data from Operations1: local infrastructure

In case you need to stay within your local infrastructur you can trigger the integration directly from the device:

Important information

The local request:

• can access endpoints within your local infrastructure, if you cannot provide an public endpoint.
• can only be triggered through an external request interaction by the user.

Implementation

You can find an example implementation in python with flask in our recipe section as starting point:

Document configuration

To start with the recipe above you can configure a document like this:

• Create a new document.
• Insert an "Request information" interaction into the document and add the endpoint.
• Insert a second interaction and add an interaction tag named "target_interaction".

Execution

When starting the flask webservice and executing this as report you should see a result like this and the targetinteraction is set with the value from the "get_data" function:

Caveats

Payload

The payload of the local request differs from the cloudbased one. Make sure to have the correct schema: Local Request Payload

CORS

When triggering requests from a local device in a browser, one of the most common issues developers face is Cross-Origin Resource Sharing (CORS). CORS is a security mechanism enforced by web browsers to prevent unauthorized or malicious cross-origin requests.

When making requests from a local device in a browser, CORS (Cross-Origin Resource Sharing) can block them unless the server allows cross-origin communication. Here's what to consider:

Server Configuration:

• Set CORS headers:

Access-Control-Allow-Origin (specific origin or *)
Access-Control-Allow-Methods (e.g., GET, POST)
Access-Control-Allow-Headers (e.g., Content-Type)
Access-Control-Allow-Credentials (if cookies/credentials are needed)

• Development Solutions:

Use proxies or middleware (e.g., http-proxy-middleware for Node.js).
Set up a reverse proxy (e.g., Nginx).
Use browser extensions (for local testing only).

• Best Practices

Avoid * for Access-Control-Allow-Origin in production.
Configure environment-specific server settings.
Always secure sensitive requests.

You can find further details for example here: MDN: CORS