Invalid white space character (0x7) in text to output

, ,
1

Hello,

What can I do to prevent this fault in the response payload from a Natural RPC Server-processed web service call based on bad data in ADABAS?

Invalid white space character (0x7) in text to output

I found this when the SOA team was complaining that under certain conditions they receive:

Unable to invoke endpoint URI “http://wsstack-dev.tcc.etn.com:8081/wsstack/services/Vista_C360_Query_Order?wsdl” successfully due to: java.lang.RuntimeException: oracle.j2ee.ws.saaj.soap.InvalidSoapMessageException: Illegal processing instruction target (“xml”); xml (case insensitive) is reserved by the specs. at [row,col {unknown-source}]: [1,59399]

I tested in the XML tester in Designer to find out the error behind the error.

The service call works when the payload sent include these input parameters:

<_MESSAGE-ID>1234567 <_ERP-NAME>VSTA01 <_INPUT-DATA> <_PRODUCT-ID/> <_VCN/> <_CUST-PO-NUM/> <_GO-NUM>KIMS0114* <_GO-DATE-FROM/> <_GO-DATE-TO/> <_GO-DATE/> <_INVOICE-NUM/> <_JOB-NAME/> <_SERIAL-NUM/> <_SHIP-RLS-NUM/>

…but not with these…

<_MESSAGE-ID>1234567 <_ERP-NAME>VSTA01 <_INPUT-DATA> <_PRODUCT-ID/> <_VCN/> <_CUST-PO-NUM/> <_GO-NUM>KIMS* <_GO-DATE-FROM/> <_GO-DATE-TO/> <_GO-DATE/> <_INVOICE-NUM/> <_JOB-NAME/> <_SERIAL-NUM/> <_SHIP-RLS-NUM/>

The inclusion of more hits based on the wild-carded search is finding the bad data in records returned.

Thanks in advance!

-Brian

2

In doing some trial and error, I ran across two records in ADABAS where this issue occurs. Here is an example of one:

General-order-num…* KIMS00035_
Cust-po-num… DEFFER ??Ä?1____________________

The data stored in CUST-PO-NUM cannot successfully be returned.

Is there anything I can do in EntireX to allow it to pass that back, or are the only options:

  1. data cleanup
  2. Natural module does an EXAMINE… REPLACE for every field for every possible bad character before passing the data back?

Thanks,

Brian

3

Hello Brian,
First, let me say that a bad data should be cleaned, as the ground rule - so cleaning this bad values is the prefereed way.

Saying this, I understand this is not always possiable or convinient to do- so I would suggest that you take a look at the
EntireX Broker Attribute parameter “Conversion”, sub-parameter “option”, where you can define how to handle where there is a character that can not be convereted.

Here is a link:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite9-12/EntireX/9-12_EntireX/adminGeneral/attributes.htm#attributes_service_OPTION-conversion
Hope that helps

Sagi

4

Hi Sagi,

Thanks for the useful documentation link. It would appear that should advise me correctly.

However, I already have this defined in the relevant broker attribute file:

DEFAULTS = SERVICE
CONV-NONACT = 5M
DEFERRED = YES
SERVER-NONACT = 10M
CONVERSION = (SAGTRPC, OPTION = SUBSTITUTE)

CLASS = RPC, SERVER = POLLARTSHIP, SERVICE=CALLNAT
CLASS = RPC, SERVER = UNIFYARGLFEED, SERVICE=CALLNAT
CLASS = RPC, SERVER = UNIFYIMD, SERVICE=CALLNAT
CLASS = RPC, SERVER = SRV1, SERVICE = CALLNAT

The final one listed there is the Natural RPC Server’s service registered into the EntireX Broker, and I am using the recommended CONVERSION and OPTION settings that should replace any bad characters with one that the WSStack or any consumers won’t choke to death on. Why would this kind of error occur with this setting?

Thanks,

Brian

5

EntireX architecture has a layering: From TCP to ACI/RPC and on top XML/SOAP. The EntireX Broker is aware of ACI/RPC messages but does not know XML/SOAP is used above. This is known by the WS-STACK and XML RPC Server / Listener. Broker CONVERSION and its OPTION value relates to ACI/RPC messages and invalid codepage characters. Although you do not have posted the codepages in use for the ACI/RPC layer, U+0007 is valid as x07 in most ASCII codepages and as x2F valid in EBCDIC. The error occurs because XML/SOAP is more restrictive.
Layering.png

6

Hi Bernhard,

I can understand what you’re saying and why the CONVERSION = (SAGTRPC, OPTION = SUBSTITUTE) is perhaps not sufficient for SOAP/XML but is for other types of integration that simply requires satisfying the ACI/RPC level. Thanks also for providing the illustration.

However, it would seem to me SOAP/XML integration would be perhaps of utmost importance with a product whose role is to provide a way to integrate “legacy” applications including Natural/ADABAS with today’s enterprise suites, which predominantly integrate with other applications using SOAP/XML (e.g., web services, APIs, etc.). Is there a broker configuration that will not just substitute enough to pass the ACI/RPC conversion but will also substitute characters that are bound to fail SOAP/XML? Or is there another way to catch and convert such characters before it passes through the Tomcat layer (WSStack)? I am thinking not on the latter as the data streams over TCP/IP directly from the Broker to Tomcat on its way back to the client.

I don’t know if this problem will be as prevalent as I am finding in our development environment when we deploy this particular service in production. We know development environment data can be a bit more corrupt, but the possibility of having web service calls initiated by customer use our our applications fail due to bad data in ADABAS worries me as that won’t be acceptable. Database cleanup would be an overwhelming task as well with the historical volume of data present.

It would seem there should be an option (CONVERSION = (SAGTRPC, OPTION = SUBSOAP?) that would perform the substitution on the additional values that, when EntireX is used for SOAP-based integration, would take care of those as well. That is, if CONVERSION = (SAGTRPC, OPTION = SUBSTITUTE) cannot be changed to do that, too. As you said, EntireX Broker does not know beyond ACI/RPC how you are integrating. It should not assume you aren’t using SOAP-based integration, as that would be a terrible assumption to make in today’s enterprise.