Web Services and SCADA

Web services can be another method for connectivity to SCADA and MES systems. They can retrieve tomorrow's weather, the price of stocks or commodities, the time of sunrise and sunset, and a slew of other publicly-available resources. They can also interact with many different ERP and middleware systems.

We have been looking for the best way to implement web services in Ignition for a long time, but the problem has been complicated by three factors:

1. There are many web service standards; in fact, too many.
2. Data formats are wildly variable and can include many nested structures.
3. Responses can dynamically return a varied number of data elements every time.

As regards Ignition, the question has always been how to deal with these factors in an elegant way. How should we map nested and dynamically-changing data into Ignition's resources such as SQLTags, HistoricalSQLTags or other database resources? The problem gets hairy pretty fast.

We recently solved this problem by including the Python SUDS web service client library in version 7.4.2 of Ignition (currently available in beta). In just two lines of Python code you can be up and talking to practically any SOAP server that serves WSDL files. Okay, maybe that's a bit too much information – let's clarify a few things about web services. 

Web Services Demystified
Web services are nothing more than web pages for machines. There are web servers (like the one serving this blog) and web clients (analogous with your web browser) but in the place of you (the one who is controlling your web browser) there is a program which is controlling the web client.

The content of web pages is HTML (which is text) whereas in web services this is replaced with XML (eXtensible Markup Language) which is also text. HTML is intended primarily to manage how content is displayed in your web browser, whereas XML is geared for labeling and structuring the data to be exchanged.

SOAP (Simple Object Access Protocol) sounds scary but is nothing more than some text and XML which essentially makes a contract between the web client and web server concerning how they're going to talk to each other.

WSDL (Web Services Description Language) is nothing more than an initial web page (again in XML) that the server sends (when requested) which answers the questions "How should I talk to you?" and "What should I expect back in response?"

The SUDS Library
The SUDS library can query the server for a WSDL file and parse it to tell you in plan English how to talk to it in order to execute its methods (the name SUDS is clearly a play on the acronym SOAP). Once you know what methods are available you can use SUDS to invoke those methods which can (generally) be used to retrieve and send information to the server. For example, you could retrieve a work order from an ERP system, mark the work order with current production status, and then send it back to the ERP system.

The really good thing about the SUDS library is that it works. Other libraries we tried were complicated or were picky when they tried to parse information from the server (so they "blew-up", so to speak).

The thing to realize is that XML can be (and has been) structured into many arbitrary forms. Therefore, many different standards have been created to try and reign in the chaos I.e. WSI-BP (Web Services Interoperability – Basic Profile). Another variable is that even when standards are followed, there sometimes are unintentional deviations. I think both of these reasons are why we saw so many web service client libraries fall short – except for SUDS. SUDS appears to be highly forgiving.

Looking at the example at the top right of this post you can see SUDS in action. Using Ignition's "Interactive Script Tester" we first import the SUDS client. Next, we instantiate a client against a URL and request the "calculator" WSDL file. Then we print the client instance and it tells us that it is a calculator web service and says it has four methods add, divide, multiply, and subtract each of which take two arguments which should be of type float. So now we use this information for our next print command "print client.service.divide(33.33, 11.11)" and the output results are "3.0000002".

There you have it. Four lines of code. The beauty of the library is that it's Python which solves the above issues two and three. Obviously, data on the server end can take any shape, but with the use of Ignition's system scripting functions you can now map the data into any shape and into any resource with only a few lines of Python code. Easy as pie.

It's an extensive library that can do a lot of things but you really don't need to know much more than I've shown you to do magic. Documentation and more examples for the SUDS library are here and the PyDocs are here.