XML-RPC Web Services in WinCC OA An Application: online PARA JCOP FWWG Meeting 15-12-2015 Lorenzo Masetti

Let’s start from the result: Para Online

Live Demo

Another Example: Log Access

Service Architecture

http server also serves the required HTML and javascript Two-layers setup Client (Javascript) Request (XML-RPC) Response (JSON-RPC) Server (WinCC OA) http server WinCC OA http server also serves the required HTML and javascript Service

Four-layers setup using Oracle WebCenter Client (Javascript) Request (XML-RPC) Response (JSON-RPC) J2EE Web Server ( JAVA ) DPAccess Portlet Public Network CMS Network DpAccess EJB Request (XML-RPC) Response (XML-RPC) Server (WinCC OA) http server Service

Services in WinCC OA

General Services in WinCC OA Using CMSfwClass (OO-framework for WinCC OA) we implemented a general framework for exposing and consuming services Request and response through data points Interface of the service defined in a CMSfwClass interface

Exposing the service to the Web To expose the service as a Web Service: we use the httpServer provided with WinCC OA. To handle the request we instantiate a ServiceClient Forwards the request to data point Forwards the response via http

Communication Format The format can be changed by implementing an interface Currently we have implemented: XML-RPC Mixed format (request in XML-RPC, response in JSON-RPC) Request  decoded to methodName, list of parameters (dyn_mixed) Response  decoded to anytype (depending on the return type of the method) Client Encode request Decode response Note: decodeResponse not implemented here: can only be used on the server side Decode request Encode response Server

Service Router A specialized class implements a service router Used to dispatch commands to different services depending on the prefix in the command, e.g. dpAccess.dpGet  dispatched to DpAccess service logAccess.getLog  dispatched to LogAccess service All XML-RPC services implement a “system” interface that allows the client to discover which procedures are available

Generic Client in Javascript

Generic XML+JSON-RPC client in Javascript Mixed communication format: XML for the request, JSON for the response. JSON is easier to handle in Javascript Using the reflection features, we can create a JS object having the same functions defined in the service Passing the URL of the Web Service and the prefix we get an object The implementation of the functions forwards the request to the server and gets the response via AJAX The functions are asynchronous (the result is returned in a callback function passed as last parameter)

Interface to access WinCC OA functions

Service interface to access DPs This is the interface used to get read-only access to the datapoints Can access remote data points Some convenient functions to group requests (e.g. dpGetStruct) Some fw functions are also exposed getDeviceChildren  fwDevice_getChildren getPeriphAddress  fwPeriphAddress_get

The Javascript client to access DPs Using the generic XML-RPC JS Client, a library (SCADA.js) exposes the methods of the DPAccess interface in javascript SCADA.js xmlrpc.js On top of SCADA.JS, a library para.js is used to create the online version of the para module para.js SCADA.js

Java EJB Implementation It is convenient to have an EJB with the same interface of the XML-RPC service The implementation of the EJB is straightforward using an XML-RPC Proxy (this feature is implemented for example in redstone.xmlrpc library)

Custom Panels The para library allows defining custom “panels” for certain data point types / data point name patterns “Panels” are rendered using EJS (Embedded JavaScript)

Serialization of Asynchronous calls SCADA.js library exposes asynchronous functions It is much easier to write code with synchronous calls Solution: WCCOA object offering the same functions but synchronous The first time the function is called it adds the request to the queue and returns a default value At the end of the execution (of the panel/function) the requests are sent to the service (multicall) The code is executed again and the functions will return the correct value from the response If there are dependencies, the code will be called again until the queue is empty

Example: WCCOA.dpGet returns “” the first time WCCOA.wait returns true if all the prior requests were resolved All the requests that are not dependent are grouped automatically returnVal calls again the function until done and calls the callback at the end