After you generate an InterSystems IRIS web client class, you do not usually edit the class. Instead you write code that creates an instance of the web client and that provides provide client-side error handling. This section documents the notable exceptions where you do modify the generated client class.
Adjusting the Generated Classes for Extremely Long Strings
In rare cases, you might need to edit the generated client class to accommodate extremely long strings or binary values — values whose lengths exceed the string length limit.
When the SOAP Wizard reads a WSDL, it assumes that any string-type input or output can be represented in InterSystems IRIS as %StringOpens in a new tab, which is not always true. In rare cases, a string might exceed the string length limit. Similarly, the wizard assumes that any input or output with XML type base64Binary can be represented in InterSystems IRIS as %xsd.base64BinaryOpens in a new tab), which is not always true, due to the same string length limitation. In neither case does the WSDL contain any information to indicate that this input or output could exceed the string length limit.
When your web client encounters a string or a binary value that is too long, it throws one of the following errors:
-
A <MAXSTRING> error
-
A datatype validation error:
ERROR #6232: Datatype validation failed for tag your_method_name ...
(This error, of course, can also be caused by a datatype mismatch.)
The problem, however, is easy to correct: adjust the method signature in your generated web client class (specifically the class that inherits from %SOAP.WebClientOpens in a new tab) to use an appropriate stream class:
For example, consider a web service (MyGiantStringService) that has one method (WriteIt), which takes no arguments and returns a very long string. If you use the SOAP Wizard to generate the web client class, the web client class originally looks something like this:
Class GetGiantString.MyServiceSoap Extends %SOAP.WebClient
{
Method WriteIt() As %String
[Final,SoapBindingStyle=document,SoapBodyUse=literal,WebMethod]
{
Quit ..WebMethod("WriteIt").Invoke($this,"https://tempuri.org/MyApp.MyGiantStringService.WriteIt")
}
}
In this case, there is only one adjustment to make. Change the return type of WriteIt as follows:
Method WriteIt() As %GlobalCharacterStream
[Final,SoapBindingStyle=document,SoapBodyUse=literal,WebMethod]
{
Quit ..WebMethod("WriteIt").Invoke($this,"https://tempuri.org/MyApp.MyGiantStringService.WriteIt")
}
When you compile this class, the system automatically regenerates the associated classes as needed.
You may also need to adjust property types within any generated type classes. For example, suppose the web service uses an element called <Container>, which includes an element <ContainerPart> of type string. When you generate the InterSystems IRIS web client classes, the system creates a Container class with a ContainerPart property of type %StringOpens in a new tab. If the web service sends a string longer than the string length limit in the <ContainerPart> element, your web client throws an error. To avoid this error, change the type of the ContainerPart property to %GlobalCharacterStreamOpens in a new tab.
Other Adjustments
If the WSDL does not specify the location of the web service, the SOAP Wizard does not specify the LOCATION parameter of the web client. This is a rare scenario. In this scenario, edit the web client class to include the LOCATION parameter. For example:
Parameter LOCATION = "https://devsys/csp/mysamples/GSOP.AddComplexWS.cls";
Or specify the Location property of your web client instance as shown later in this topic.
You might need to adjust other parameters of the web client class to make other changes. See Fine-Tuning a Web Client in InterSystems IRIS for details.
