Changed layout of SOAP message / empty elements omitted

, ,
1

Hello,
We are upgrading our Natural RPC server environment and now we face a problem / feature (?) of changed layout of the returned SOAP messages.
Our situation: we are using XMLAdapter classes generated with Exx v6.1 some years ago. These classes were communicating with the RPC server via the old, also v6, entxrt.jar.
Because of the migrate of Natural to newer version and a problem we got in the RPC server (see also topic http://entirex.forums.softwareag.com/viewtopic.php?t=427) the entxrt.jar had to be replaced by the newest version, v721.50, entirex.jar.
The result is that the RPC communication is functioning Ok now, but the layout of returned SOAP message differs compared to the old situation.
Eg an array-field which is empty is now suppressed to one empty element.
As an example:
v611 – part of xml file of generated class

With the corresponding XMLAdapterclass we call the NAtRPC server.
The results are:

call with v611.8 entxrt.jar – part of returned SOAP message

			<SRT_DTE SOAP-ENC:arrayType="xsd:string[5]"
				xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
				<string></string>
				<string></string>
				<string></string>
				<string></string>
				<string></string>
			</SRT_DTE>

call with v721.50 entirex.jar – part of returned SOAP message

			<SRT_DTE SOAP-ENC:arrayType="xsd:string[5]"></SRT_DTE>

As you can see the are omitted in with the new jar.
Does anyone now whether this is a feature or a bug?
Or whether it can be parameterised to get the empty elements included in the SOAP message?

2

Hello Frank,

you should open the corresponding IDL and XML file in the 7.2 Workbench. In the mapping editor check the parameters for “Null Value Suppression”. The defaults might have changed over the years. The details should be handled in the support request which already exists for this issue.

It is also a good idea to move to XMM files because the old Adapter classes will not be supported in the future.

3

Via support we now got a correction. The error was in the generated XMLadapter class and the entirex runtime jar.
The new entirex.jar and exxworkbench.jar now have version v721.50v.
With the new workbench and a newly generated adapeterclass my problem was solved.