Module and Parameter Naming

The WebService functions use name matching on the WSDL Web Services Description Language. An XML-based language that provides a model for describing Web services <operation> tags to discover SOAP SOAP (originally Simple Object Access Protocol) is a protocol for exchanging XML-based messages over computer networks modules. Modules to be called must therefore be named such that they match the names of the <operation ...> tags described in the WSDL document. Incoming SOAP messages will use this same name to indicate the module to call, while outgoing messages will use the name of the module with the string "Response" appended to indicate their source.

Example:

    <wsdl:message name="GetTagValueInput">
        <wsdl:part name="request" type="tns:GetTagValueIn" />
    </wsdl:message>

    <wsdl:message name="GetTagValueOutput">
        <wsdl:part name="response" type="tns:GetTagValueOut" />
    </wsdl:message>
    <wsdl:portType name="TagQueryServicesPort">
        <wsdl:operation name="GetTagValue" 
                        parameterOrder="request response">
           <wsdl:input message="tns:GetTagValueInput"/>
           <wsdl:output message="tns:GetTagValueOutput"/>
        </wsdl:operation>
    </wsdl:portType>

The VTScada module referenced here, GetTagValue, must be created and given parameters as follows:

<
GetTagValue
(
  request;
  response;
)
...
>

Parameters exposed by the called modules must cover both input from the incoming SOAP message and output to the outgoing SOAP response. The names of these parameters must match the <part> tag names associated with both the <input> tags and <output> tags as defined in the <operation> section of the WSDL for the called module.

This system enables parameters to be properly integrated into messages. Each output parameter will be given a pointer to a blank instance of the type required by the method. The method should fill out these structures, extending array portions as necessary. Similarly, each input parameter will be passed a pointer to the incoming data type that the parameter represents. The pointers themselves must not be changed as this would break the linkage to the WebService system calling the module and prevent proper passage of output data.

The return value of a called module must not be of type OBJECT and should be INVALID. Steady-state called modules must not contain a return statement at all, as this will cause VTScada to attempt to execute them as subroutines (i.e. procedurally). Any values that are returned will be discarded by the system.

After a web service is set up, a variable called "WSDrvr" will be added to the connected module

Developers should not include a variable with the name "WSDrvr" themselves. The WebService initialization function will reject any modules containing such a variable.

This variable records several pieces of context data relevant to the new web service as well as a group of support functions for common web service processing tasks.