Web Services are a lightweight and configurable means of communication for MES to share and consume data from other systems over the web. ERP, Advanced Planning, Warehouse Management, QMS, and other systems can bidirectionally communicate with MES systems using this modern web technology. Common protocols used by Web Services include SOAP and REST. Web Services are a key aspect of data transmission for modern connected software systems.
Use Cases for Manufacturing with MES
There are many reasons to implement communications with outside Web Services. Perhaps you want to convert currencies, calculate travel times for shipments, gather weather information, or communicate results to your ERP. For all of these, Web Service APIs exist, and you can query them to send or retrieve data that is key to your operations.
Similarly, there are many potential use cases for providing APIs from your manufacturing operation for clients to consume. For example, you could create an API that communicates production results, such that executive-level clients can actively query for progress against production orders, rather than waiting for a report. Or perhaps you want to create a web interface for your SCADA installation, allowing operators or managers to begin or end operations, or record other important data.
The key to understanding the adoption and implementation of Web Services for MES is an understanding of the technologies available for use. One such technology is Simple Object Access Protocol (SOAP). For many years, SOAP has been the most commonly used standard for communications between servers in the manufacturing realm. SOAP communications depend on an XML document called a Web Services Definition Language file (WSDL), provided by the Web Service provider, that dictates what information is available at the SOAP endpoint, and which inputs are required from clients that wish to consume the service. This WSDL file must be parsed by the client, so that they submit the correct inputs to the Web Service, and are prepared for the response.
The distinct advantage of SOAP is the predictability created by the WSDL document – the client knows what is required of them, and what information will be returned to them. However, this stability necessarily brings with it inflexibility – each and every element of the interaction must be carefully described in the WSDL XML document, and any deviation from that may cause errors. In addition, SOAP Web Services typically require the use of complex tools to interact with them.
More common these days are Representational State Transfer (REST) Web Services. With REST, there is not typically a machine-readable document that precisely delineates the inputs and outputs of the Web Services. Rather, it is up to the provider to deliver human-readable documentation to any and all potential clients of a given Web Service. Examples of well-documented REST Web Services are all over the web, from Amazon’s AWS APIs, to Google Maps and the DarkSky Weather API. For each of these Web Services, potential clients will find useful and exhaustively detailed documentation portals that include examples of how to successfully query these APIs. It is up to these clients to understand these Web Services and interact with them as prescribed.
One reason that REST Web Services are becoming more widely adopted is because they are relatively simpler to interact with. They typically only communicate over HTTP, there is no requirement for maintaining a machine-readable intermediary document like a WSDL, and the learning curve for interacting with them is relatively lower. It is remarkably easy in most major coding languages to query REST APIs, and you can even see the responses for most REST APIs right in your web browser.
Here’s an example of a real Web Service. This particular example is a REST API that returns a fictional list of users:
Imagine also, that the response to this is as follows:
The component parts of that call are as follows:
- Base URL
- This is the base portion of the web address, and is the location at which the web service is found.
- URL Resource Path
- A given API may have any number of endpoints to interface with, and in our example, we are using a resource that returns a list of users.
- URL Query Strings
- The available fields are “page” and “per_page.” “page” indicates which page of users we wish to review, and “per_page” sets how many users we wish to see per page.
- These query strings, as well as the Base URL and Resource Path should have been communicated to us in documentation written by the provider.
- The response here comes in the form of JSON, which is one of the most common formats used with REST Web Services. However, responses can be returned in any number of formats, including XML. It is up to the provider to tell the clients which formats to expect.
- Here we see some metadata about what sort of data is being served to us, and the actual list of users, which includes their names and an avatar for that user.