Roger Larson Wed Aug 22

Web Development in Ignition SCADA

There are two independent web development type modules in Ignition that allow one to host a custom API or web page on a web server directly from Ignition – the WebDev module by Inductive Automation and the Web Services module by Sepasoft. Both of these modules allow external systems (ERP, SAP, DBs, etc.) to interact with Ignition, which can be used as a central hub for bidirectional data processing for these systems. The two main classes of web services are REST (Representational State Transfer) and SOAP (Simple Object Access Protocol). REST is available through both modules and can utilize JSON and XML data formats, while SOAP is available only through the Web Services module and only utilizes XML data formats.

IGNITION WEBDEV MODULE

For REST, there are several HTTP methods available for communication between web servers. The most commonly used are the GET (retrieve information from a server) and POST (send data to the server) methods. There are other methods available such as PUT (putting or updating a resource on the server) and DELETE (deleting the request resource), but the aforementioned two are the primary means of communication. Ignition can GET/POST/PUT/DELETE data to an external server on its own via scripting without the need for these modules, but in order to receive any calls from the external servers, these modules are absolutely essential. These methods are created in Ignition via Python scripts that exist within the modules, so some knowledge of programming will be needed to implement these REST API methods.

Ignition’s vanilla scripting library contains a scripting package (system.net) that contains useful functions for outgoing communication from Ignition to an external server. The four functions relevant to this are

  • system.net.httpGet
  • system.net.httpPost
  • system.net.httpPut
  • system.net.httpDelete

Generally, data will be sent as a JSON (JavaScript Object Notation) object or via XML (eXtensible Markup Language). A JSON object is useful in that it is easy to generate, parse, read, and write. Typically, it is represented as a collection of name/value pairs that could look like the following:

{

"Data": {

"Tag Name": "tag1",

"Tag Path": "tagPath1",

 

"History": {

[

"Tag Value": "237",

"Timestamp": "04-23-2018T22:00:00Z"

],

[

"Tag Value": "376",

"Timestamp": "04-23-2018T23:00:00Z"

]

}

}

}

 

WebDev1

Figure 1: WebDev - Basic Structure 

 

A JSON string object can be generated from a Python dictionary via encoding, or the reverse operation via decoding back to a dictionary. The system.util scripting package in Ignition contains functionality to do this with the following functions:

  • system.util.jsonEncode
  • system.util.jsonDecode

The URL endpoints are slightly different for each module, and are the primary means of communication from an external source using POST and GET commands. The URL endpoint for the WebDev module resource is:

 

http://host:port/main/system/webdev/project_name/path_to_resource/resource_name/path

 

Or, as an example for a system on the localhost (same computer and IP address),

 

http://localhost:8088/main/system/webdev/webanalytics/api

 

An example GET request with no parameters looks like the same request:

 

http://localhost:8088/main/system/webdev/webanalytics/api

 

And could have server response in the form of a JSON object:

 

{“data”: “{value1”: 123, “value2”: “456”, “value3”: [“Hello”, “World”]}}

 

WebDev2

Figure 2: WebDev - Reading Parameter Inputs

 

Another example server GET request call with parameters could look like this:

 

http://localhost:8088/main/system/webdev/webanalytics/api?param1=22&param2=81

 

With server response (simply repeating the input parameters, see Figure 2):

 

{"data":{"param1":"22","param2":"81"}}

 

POSTs to this server can send a JSON object in a server request and receive data in a similar fashion to GET commands if needed.

The Ignition web server will receive the request, process it, and deliver a response to the external server trying to communicate. What goes in that server response depends on what is programmed for that particular API method, be it HTML, XML, JSON, or simply text. Figure 1 and Figure 2 are sample python programs demonstrating how this works for the WebDev module.

 

SEPASOFT Web Services Module

The SepaSoft Web Services module is divided into two parts: Consumers and Providers. Consumers are REST/SOAP configurations that consume data from external servers, similar to how Ignition’s basic functionality allows GETs/POSTs to external servers. Providers are the REST/SOAP endpoints, similar to the ones present in the WebDev module, that allow external servers to communicate to Ignition and obtain data. The REST API URL endpoints for the Web Services module is

http://host:port/main/system/ws/rest/path_to_resource/resource_name/path 

 

WebDev3

Figure 3: Web Services – Structure

 

A few examples of this:

 

http://localhost:8088/main/system/ws/rest/api/tags/browse

http://localhost:8088/main/system/ws/rest/folder1/restEndpoint

http://localhost:8088/main/system/ws/rest/folder1/restEndpoint?param1=22&param2=81

 

Where api is the name of the REST endpoint and tags/browse is a callable path within that API GET request. The server response can simply be data in the desired format, usually JSON. POSTs to Ignition on this API would use the same path but would send a JSON request object. This module works in a very similar manner to WebDev module for all REST endpoints, with the exception of added REST configurations, and the ability to use the SOAP protocol instead.

The Web Services module Consumers/Providers structure is given in Figure 3, and a REST Endpoint API script is given in Figure 4.

 

WebDev4

Figure 4: Web Services – REST Endpoint GET method program

 

This type of bidirectional communication in Ignition via web APIs allows for easy accessibility of data into and out of Ignition. Tag history can be sent out via a request to an external server that can digest the data and follow up with various analytical tools or aggregation modes for exploration or dashboarding. This can be useful for administrative functions or process monitoring outside of Ignition.

Click here for more Ignition application use cases and programming tips.

 

COMMENTS

SUBSCRIBE TO OUR BLOG

Sign up to get the latest from Vertech delivered right to your inbox.