The WebService functions use name matching on the WSDL <operation> tags in order to discover SOAP 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.
e.g.
<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 VTS module referenced here, GetTagValue, would have a structure similar to the following:
<
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 allows 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 VTS to attempt to execute them as subroutines (i.e. procedurally). Any values that are returned will simply be discarded by the system.
Once 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.