XML Tip - SOAP Body content that is encoded
There is a common “gotcha!” associated with web services when working from the Microsoft .NET environment that causes the consumption of .NET web services to be more cumbersome than necessary. We are specifically talking about how .NET web services are frequently built in a fashion that requires the entire
<soap:Body> tag contents to be URL encoded. This means that the following XML:
<tag1>somevalue</tag1> would instead need to be encoded as such:
<tag1>somevalue</tag1> As you can see there was simply a translation done to take the less than and greater than signs and convert them to
< and
> respectively. We can determine the cause of why this needs to happen by looking at the WSDL created from Microsoft's Visual Studio IDE.
Figure 1 contains a portion of a WSDL that defines an interface to a county vehicle title inquiry web service. The
TitleInquirySoapIn WSDL message points to a XML Schema Definition (XSD) element named
tns:TitleInquiry which is defined in the
<wsdl:types> area. Here is where the heart of the problem exists. The
TitleInquiry element declaration has a child element named
xmlstring. The important thing to note is there isn’t any more child elements defined within.
At this point the SOAP XML document would look like the following in Figure 2. Note that there really isn't any content defined within element
<xmlstring>. This is because instead of further defining the XML with the WSDL's schema, the creators of this web service simply define it in a Microsoft Word document (a very bad practice). Instead, all of the XML elements should have been declared in the WSDL's XSD area. Because of this, the SOAP spec declares that everything within
<xmlstring> needs to be URL encoded.
Figure 3 shows what the raw request needs to look like in order for the Microsoft .NET web service to receive it properly. If the XML within
<xmlstring> is not escaped you can expect to get back messages from Microsoft's IIS like “400 Bad Request”. This error obviously doesn't give us much to go on, but as stated it can have something to do with how the WSDL was written and inherently how the XML is composed and encoded.
We have talked about the request and how the .NET web service requires the
<soap:Body> to be URL encoded. Now it should also be mentioned that the response
<soap:Body> will also be encoded. Composing the XML with < and > is fairly easy and your normal RPG-XML Suite template approach can work for that. Parsing takes on a little more complication.
Before the response XML from the .NET web service can be parsed it must first be decoded to change the < and > to < and > respectively. This will allow the parser to recognize these as actual XML elements instead of plain text. Fortunately, RPG-XML Suite provides the RXS_soapDecode API to easily translate to the correct format. Pass RXS_soapDecode the RPG variable or IFS file containing the XML and it will quickly go through and do the necessary translations. Once the translation is done you can appropriately continue with the normal approach to parsing using RPG-XML Suite by setting up your event handlers and calling RXS_parse.