[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-----------------------------------------------------------------------