Access MTConnect data from a web application

About five years ago I wrote 5 ways to access MTConnect data from a web application. This article outlined methods for accessing the MTConnect agent’s data from a client-side web application.

Ignore it. Much has changed in web development since then, and some of the methods mentioned in the old article range from bad to obsolete. If you want to write an MTConnect web application, here are your best options:

Run on the Same Server

The easiest way to circumvent the same-origin policy is to comply with it. If you are running the MTConnect Institute’s stock C++ agent, this is simple to do. Serving static files (such as HTML and JS files) is now a configuration option. According to the documentation:

Using a Files Configuration section, indvidual files or directories can be into the request file space from the agent. To do this, we use the Files top level configuration declaration as follows:


Files {
schemas {
Path = ../schemas
Location = /schemas/
}
styles {
Path = ../styles
Location = /styles/
}
}


Each set of files must be declared using a named file description, like schema or styles and the local Path and the Location the files will be mapped to in the HTTP server namespace. For example:

http://example.com:5000/schemas/MTConnectStreams_1.3.xsd will map to ../schemas/MTConnectStreams_1.3.xsd

All files will be mapped and the directory names do not need to be the same. These files can be either served directly or can be used to extend the schema or add XSLT stylesheets for formatting the XML in browsers.

This allows you to specify a “public” directory for your web application, which will be served by the MTConnect agent. If your web application is largely static content, for example, using only HTML or client-side Javascript, this option may be sufficient.

May the CORS Be With You

If your web application includes server-side processing, serving static files from the MTConnect agent won’t help. This will be the case if your app is coded in PHP, Ruby on Rails, ASP.NET, or other server-side technologies. In that case, your option is to use CORS to enable your client-side scripts to access cross-origin data from the MTConnect agent.

The advice from my earlier article still applies:
1. Download the C++ agent source code from GitHub.
2. Open agent/agent.cpp.
3. Locate the Agent::on_request method.
4. Find the line that reads: outgoing.headers[“Content-Type”] = “text/xml”;
5. Add a line right below it: outgoing.headers[“Access-Control-Allow-Origin”] = “*”;
6. Save and build.

When you run the modified agent, it will answer all requests with an Access-Control-Allow-Origin: * header, which should allow your client-side web application to access the data served by the agent.

Proxy Everything, or Do Everything Server-Side

If all else fails, this problem can be solved by serving the data and your web application through a proxy. Worst-case, the relevant portion of your app could be migrated server-side, though this runs against current trends, and will prevent your app from running offline.

Conclusion

For a lightweight browser application coded in Javascript, the MTConnect Agent alone may provide sufficient capabilities with its ability to serve static files.

For anything more complex, the MTConnect Agent can easily be modified to allow cross-origin requests. If you are unable to modify or recompile the agent, you can set up a proxy server to pass both the MTConnect Agent data and your web application.

With a minimal amount of work, there’s nothing to prevent client-side web applications from accessing MTConnect agent data.