[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SOAP-ENV:Client: FormatException
Hi John,
I simply chopped the TransactionSerializer blocks that I didn't need from the stub source, and it works like a charm!
I basically wanted the resulting RPG-generated XML (which I can now view easily) to match what I've been running in SoapUI for each given request type (we only use three). If I need to add any of them back, it's easy enough to do (not too grueling after all).
Thanks so much for your help.
Ted
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Thomas Raddatz
Sent: Monday, March 07, 2016 10:44 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: SOAP-ENV:Client: FormatException
Ted,
Before I start to explain how to block elements from being sent, I need to explain some details of WSDL2RPG. I assume that you use the most recent version 1.16.4.
Version 1.16.0 started to use "Serializer" procedures to generate the request message. "Serializers" are procedures that generate the XML message for a given RPG data structure. So blocking a complete data structure from being sent is very easy. For example:
Let us assume your xml message looked like this:
<soapenv:Envelope>
<soapenv:Body>
<address>
<name>Donald Duck</name>
<street>Wet Foot Road 5</street>
<city>
<zip>1313</zip>
<name>Duckburg</name>
</city>
</address>
</soapenv:Body>
</soapenv:Envelope>
Then you should have two data structures in your program:
D tns1_address_t...
D DS template
D qualified
D name 128A
D street 128A
D city likeds(tns1_city_t)
D tns1_city_t...
D DS template
D qualified
D zip 128A
D name 128A
You should also have two matching serializer procedures:
tns1_addressSerializer()
tns1_citySerializer()
The stub starts the "Envelope" and "Body" elements and then calls tns1_addressSerializer(), which produces the xml data of elements "name" and "street" and afterwards calls tns1_citySerializer(), to produce the xml data for elements "zip" and "name".
So if you want to permanently block a complete data structure from being send, find the associated serializer procedure and disable it. The name of the serializer procedure is the concatenated value of:
a) the namespace prefix of the element
b) the name of the element type
c) the literal "Serializer"
Another option is to add a flag to the data structure in question like this, for example:
D tns1_city_t...
D DS template
D qualified
D isNil N
D zip 128A
D name 128A
The you can query city.isNil to determine whether or not to call tns1_citySerializer:
if (not city.isNil);
tns1_citySerializer(
i_hOutStream
: city
: 'city'
);
endif;
For all simple elements you need to find the place where it is added to the xml. I suggest to search for "<name" to find the place where the data of element "name" is generated. The source code should look like this:
'</zip>' +
'<name' +
'>' +
'';
// Add previous bytes of request message to output stream OutputStream_appendGlobalRequestBuffer(
i_hOutStream
: g_requestBuffer
);
Marshaller_toStringV6(
%addr(i_city.name)
: %addr(i_city.name: *DATA)
: %len(i_city.name)
: i_hOutStream);
g_requestBuffer =
'</zip>' +
Now you need to modify it like this in order to permanently disable "name":
'</zip>';
// Add previous bytes of request message to output stream OutputStream_appendGlobalRequestBuffer(
i_hOutStream
: g_requestBuffer
);
For sure I know that modifying the stub by hand is annoying. But what shall I do? If I added a "isNil" switch for each element, the number of elements would be doubled and other people would complain about setting all switches to *ON or *OFF depending on what they want to send. All that is a lot easier with Java where you can left unneeded elements null. But in RPG we have no NULL support and hence we need to use a separate indicator for coming close to it. And that raises the question what default value to use for it. Should it be *ON or *OFF? If we set it to *ON you can simply assign values to your elements without caring for the indicator. But you need to set it to *OFF for NULL values (one operation per element in both cases).
When we turn it around and set the initial value of the indicator to *OFF you need to set it to *ON and assign your actual value to the field (2 operations for per element). But you do not need to set it to *ON for all values that are NULL.
At the end the default value depends in the ratio of used/unused fields.
That is very frustrating and when it comes to that point, I sometimes wished I had never started WSDL2RPG.
I currently try to add the "isNull" indicator for complex types (= RPG data structure). That is some work but possible in a reasonable amount of time. For simple fields it is even more work and not that easy. I cannot predict when it will be finished.
Thomas.
-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Hammack, Ted
Gesendet: Sonntag, 6. März 2016 21:57
An: HTTPAPI and FTPAPI Projects
Betreff: RE: SOAP-ENV:Client: FormatException
Ok, thanks.
Just thought there was some sort of *NoPass-like option for this (still new to me).
Could you just show me some sample code of how I would block a given field from the request message? (and the section of the stub code where I plug this in?)
Thanks again.
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Thomas Raddatz
Sent: Saturday, March 05, 2016 11:59 AM
To: HTTPAPI and FTPAPI Projects
Subject: RE: SOAP-ENV:Client: FormatException
Why do you want to create separate stubs for each request type? It is not difficult to add a couple of IF statements to the generated stub to prevent blank or zero values from being added to the request message. All I said is, that it was easier, if RPG had full null support. Then I could generate the IF statements for optional elements. But I cannot do that today, because I cannot know, whether or not BLANK or ZERO shall be interpreted as NULL.
Thomas
Gesendet mit AquaMail für Android
http://www.aqua-mail.com
Am 4. März 2016 11:20:41 nachm. schrieb "Hammack, Ted" <thammack@xxxxxxxxxxx>:
> Yikes!
>
> Seems to me there should be some sort of "Ignore Null" parameter to
> pass in the OnlineRequest command.
>
> Looks like I'll need to set up separate stubs for each different type
> of request then?
>
> We can't abandon the RPG method this late into the development process
> (wish I knew about this limitation earlier).
>
> Anyway, thanks.
>
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Thomas
> Raddatz
> Sent: Friday, March 04, 2016 4:38 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: RE: SOAP-ENV:Client: FormatException
>
> There is no way to block any elements from being sent out of the box.
> The right way was to use NULL values. But that does not work for RPG
> due to the poor implementation of the compiler regarding null values.
>
> So all you can do is modifying the generated stub by hand for example
> to ignore elements that contain blanks or 0. And that is where the
> problems begins. For numeric fields it is not always right to assume
> that 0 must not be sent.
>
> Thomas.
>
> Gesendet mit AquaMail für Android
> http://www.aqua-mail.com
>
>
> Am 4. März 2016 9:42:58 nachm. schrieb "Hammack, Ted" <thammack@xxxxxxxxxxx>:
>
>> Thanks Thomas,
>>
>> It was revealed in the debug text that we're sending a bunch of tags
>> that we don't need (with null values). In SoapUI, I only have the
>> fields and tags listed that we need to send for a given request (this
>> is a huge WSDL, so about 95% of them are simply omitted). And it
>> works fine in SoapUI.
>>
>> Is there a way to block any fields/tags that we don't need from being sent?
>> (using RPG code?).
>>
>>
>>
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of - -
>> Sent: Friday, March 04, 2016 1:38 PM
>> To: HTTPAPI and FTPAPI Projects
>> Subject: Re: SOAP-ENV:Client: FormatException
>>
>> Ted,
>>
>> Please enable the HTTPAPI debug log like this:
>>
>> // Enable/disable http api debug log
>> // (Enable the http api debug log in case of problems with the
>> web service)
>> ZipCodeSoap_Port_setHttpDebug(
>> *ON: '/tmp/httpapi_debug.txt'); // Default path of http
>> api
>>
>> Thomas.
>>
>> "Hammack, Ted" <thammack@xxxxxxxxxxx> hat am 4. M?rz 2016 um 18:43
>> geschrieben:
>> Hi Scott / Thomas (or anyone who knows this),
>> We were finally able to resolve the SSL Handshake Exception, and are
>> moving on to the next error....
>> SOAP-ENV:Client: CompassFormatException
>> So far, the only information I've been able to view when running the
>> driver program in debug has been assigned to a text field from the
>> following procedures (currently we have a SoapError)...
>> CMPWSApiPort_HttpError_getCode()
>> CMPWSApiPort_HttpError_getText()
>> CMPWSApiPort_SoapError_getCode()
>> CMPWSApiPort_SoapError_getText()
>> CMPWSApiPort_XmlError_getCode()
>> CMPWSApiPort_XmlError_getText()
>> Is there any way that I can view the full XML that is sent over? I'd
>> like to compare it to the XML that I use in my SoapUI tests (which
>> work fine).
>> I only populate the fields in the OnlineTransRequest DS's that I
>> have assigned values for in SoapUI, but something else is wrong.
>> Let me know, thanks!
>> Ted
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
>> Klement
>> Sent: Thursday, March 03, 2016 8:49 PM
>> To: HTTPAPI and FTPAPI Projects
>> Cc: Mastrofrancesco, Tony; Lestik, Michael
>> Subject: Re: GSKit SSL Handshake Error
>> Ted,
>> Commercial support and consulting is from Profound Logic Software,
>> Inc.
>> You can contact sales@xxxxxxxxxxxxxxxxx.
>> This is also listed on the HTTPAPI home page, near the bottom.
>> http://www.scottklement.com/httpapi/
>> -SK
>> On 3/3/2016 11:21 AM, Hammack, Ted wrote:
>>
>> Hi Scott,
>> In your reply from 2/18, you mentioned HTTPAPI commercial
>> support/consulting as an option. It looks like we may need this.
>> Could we get some contact info? (so we're not cluttering up this
>> forum)
>> Would appreciate it, thanks.
>> Ted
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
>> Klement
>> Sent: Thursday, February 18, 2016 11:15 PM
>> To: HTTPAPI and FTPAPI Projects
>> Subject: Re: GSKit SSL Handshake Error
>> Hi Ted,
>> It's unclear why you would need a certificate assigned to your
>> application? Can you explain the requirements, here? The most
>> common scenario for a client-side application is to NOT use a
>> certificate. Normally, only server applications need certificates
>> (in
>> like 95% of the cases.) Unless you are referring to a CA
>> Certificate?
>> That's a different matter.
>> If what you're looking for is a CA Certificate, then i wonder why
>> you'd like to associate it with an application?
>> If you do need client-side certificates, I could tell you how to
>> configure them in HTTPAPI, but I cannot tell you how to do so in
>> WSDL2RPG, as that is not my project, and I am not familiar with it.
>> Thomas Raddatz is usually a frequent participant on this mailing
>> list.
>> Usually his responses (as well as others here) are very good and
>> frequent, but there are no guarantees because this is "community
>> support" on an "open source" project. HTTPAPI also offers commercial
>> support and consulting, but I do not know whether WSDL2RPG offers
>> the same.
>> -SK
>> On 2/12/2016 8:24 AM, Hammack, Ted wrote:
>>
>> >> We recently used a newer version of WSDL2RPG (developed by
>> Thomas>> Raddatz) to create stubs and service programs for a fairly
>> complex WSDL
>> >> (a WSDL that the IBM told us could not be processed by their IWS
>> client
>> >> tool due to the presence of "complex content extensions").
>> >>
>> >>
>> >>
>> >> We now have a driver program set up to consume the service.
>> Immediately
>> >> after executing the OnlineTransRequest, we get an
>> HttpError_getCode
>> >> return value of 30 and an HttpError_getText value that reads...
>> >>
>> >>
>> >>
>> >> "(GSKit) No certificate is available for SSL processing"
>> >>
>> >>
>> >>
>> >> Our LAN director says that he already installed the certificate
>> using
>> >> IBM's Digital Certificate Manager. Is there something else that
>> we need
>> >> to do that will allow us to link the program to the cert? (is
>> there a
>> >> built-in function that handles this in RPG?)
>> >>
>> >>
>> >>
>> >>
>>
>> --------------------------------------------------------------------
>> --
>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> --------------------------------------------------------------------
>> --
>> -
>> --------------------------------------------------------------------
>> --
>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> --------------------------------------------------------------------
>> --
>> -
>>
>> --------------------------------------------------------------------
>> ---
>> This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> --------------------------------------------------------------------
>> ---
>> +++++ This email and related attachments may contain confidential
>> information intended exclusively for the addressee. Unauthorized
>> use, disclosure or distribution of this material is prohibited. If
>> you received this message in error, please advise the sender and
>> delete all copies of it. Content is provided by the individual
>> sender and does not necessarily reflect the views of the Company.
>> Though sender believes this transmission to be virus-free, it is the
>> recipient's responsibility to ensure that it is.
>> --------------------------------------------------------------------
>> ---
>> This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> --------------------------------------------------------------------
>> ---
>> ---------------------------------------------------------------------
>> -
>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> ---------------------------------------------------------------------
>> -
>> -
>
>
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
>
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------