× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Kurt,

In these two examples, are the endPoint, message (or gp_Msg), user agent, and content-type parameters all identical?

Also, bear in mind that the http_post_xml() routine will parse the XML that is sent back, so what will be passed to you will have the elements de-escaped.  Whereas, http_url_post() will simply save the document as-is to disk.  Could that be why you're noticing the difference?    It's strange because you're not comparing apples-to-apples, here..  you're comparing one case where the XML is already parsed to one where it is not...

-SK


On 9/4/2018 3:06 PM, Kurt Anderson wrote:
Hi Scott,

Unfortunately I no longer have the code as it was before I rerouted to the IFS. It was during initial testing that we saw the results that were passed back to the program directly (vs to an IFS file) had all of the brackets ok. It was at that time that I thought there was a problem with how the vendor returned the data, so I set out to simply fix the results instead of addressing the issue (we simply didn't have the time). We also didn't anticipate that this would become as big of an issue as it has become (the time to fix the file for our largest client totals 30+ minutes, which has me also worrying that the underlying API call that is replacing the brackets is also eating up significant time).

This is how it was calling the API (as it was based on another process we have in place and this is the call that makes):
resultCode = http_post_xml( endPoint:
%addr( message ) + 2:
%len( message ):
*NULL: // Start Element Procedure
%paddr( ProcessUpdateResult ):
%addr( gds_webSvcData ) + 2:
HTTP_TIMEOUT:
HTTP_USERAGENT:
CONTENT_TYPE );

And the way I'm calling it that outputs to an IFS file:
resultCode = http_url_post( endPoint:
gp_Msg:
gMsgLengthCur:
gIfsFilePath:
API_CALL_TIMEOUT:
USER_AGENT:
CONTENT_TYPE );

Thanks,

Kurt Anderson
System Development Manager, Service Delivery Platform


-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> On Behalf Of Scott Klement
Sent: Tuesday, September 4, 2018 3:31 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxx>
Subject: Re: HTTPAPI: Output to File changing brackets

Kurt,

I never said 'string' was a reserved XML element?!?!  I only said that it's name was 'string' (because that's what you showed in your
document)  another provider could potentially use any name. The point is that the data inside that element is another XML document.  Which is not an unusual thing.

You say that it only happens when saving to the IFS...  can you post the code both ways?  Once where you're not saving it and getting the document the way you want, and once where you are saving it the IFS and the data is wrong?

Thanks!

-SK


On 9/4/2018 2:09 PM, Kurt Anderson wrote:
Scott:
" It is an XML document with an element named 'string' that has another XML document passed inside of it."
That was my initial response as well. But, there is no such thing (from my google searching) as a reserved XML element (other than xml), meaning <string> is not a special element that would imply that everything coming before </string> would be a value and not more xml elements.
As I noted before, the escaping is only happening when the file is saved to the IFS, and not when processed directly.
And please don't take any offense. I'm not *blaming* anyone here, but something is causing this to happen and I was hoping to find a way to prevent it from happening, wherever that may be occurring.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.