Name/Value Pairs(NVP) and RPGLE

[thebkline]

I have an RPGLE program that uses Scott Klement's HTTP_API to send a SOAP request to a Web Service. No groaning about SOAP, it's what the vendor supports and I have no choice. Anyway, I'm not real sure how to parse the NVP. For example, when I look at the HTTP log produced on the iSeries using WRKLNK, I see the element that contains the NVP and it looks like this:

<c:nvpReply>reasonCode=102 decision=REJECT requestToken=alsdkjfIFHDlAGJADGlkdsgGAHdGLh requestID=9999999999999999</c:nvpReply>

Those are Linefeeds in between, FYI.

Can anyone point me to a routine for parsing the NVP? I am not opposed to building my own but didn't know if someone already had an open source type version. Any help would be greatly appreciated.

[Whitecat27]

Greetings!

At first glance, if that is the only kind of line you are interested in (tagged "<c:nvpReply>... </c:nvpReply>") within your SOAP message, and if I were doing such a thing... I would play around with XML-INTO or XML-SAX to extract the information into a Data Structure Array. The required DS seems fairly simple at this point.

(Of course, when I say array in this context, I'm guessing you will get multiples of these from the vendor after a request that returns multiple answers)

The DS would be fairly simple, and with a single call to XML-INTO which is pointed at your received SOAP answer, would be a "one line of code" type of solution to get you all the replies returned. After that, it is a simple matter to set up a Do Loop and process these kinds of answers.

It also comes to mind that maybe some parts of the CGIDEV or even the HTTPAPI stuff could also work with this. It just depends on what you're comfortable with using in your work environment, and what you are the most familiar with.

It's always interesting to ask a group of programmers how they would do this, that, or the other thing. Out of 1,000 programmers asked, you're likely going to get 2,000 equally valid answers.


Best Regards,

Fred Williams

[TedHolt]

I use the DivideString routine in this article to divide name-value pairs, but I renamed it to Split.

http://www.itjungle.com/fhg/fhg031914-story02.html

[Scott Klement]

This is a very unusual requirement. In about 16 years of working with web services, this is the first time I've seen a web service return an XML document containing name/value pairs. I doubt there is any standard tool for parsing this -- but it should be very easy to do with the %SCAN BIF, just scan for the equal sign, and %SUBST before/after the position found.

[thebkline]

Thanks for the suggestions everyone. I will do some experimenting. FYI, the vendor I'm working with is a fairly well known, I think, payment gateway/processor. I will say it's not PayPal and it's not Braintree. This vendor does support sending and receiving a response in XML(without the NVP that is) which I would prefer, but I had to give up because I kept getting an XML Parsing Error in their reply and so far they've not been able to tell me why. So, I'm using NVP until I can get to the right person. I digress. Anyway, thanks again for the suggestions. Oh and you've probably heard this a lot but thank you, Scott Klement, for HTTP_API. At my current employer, we have a couple things that use it with one more soon to be added.

[thebkline]

Greetings!

It's always interesting to ask a group of programmers how they would do this, that, or the other thing. Out of 1,000 programmers asked, you're likely going to get 2,000 equally valid answers.


Best Regards,

Fred Williams

That's why I came here. I got three different answers which gives me three things to try. I am fairly new to Web Services so I'm still learning what's available in the 'ol RPG toolbox. Actually, your comment about a DS Array got me started before I saw the other two responses. Plus, I'd never used a DS Array so I got to learn how to declare and search one. Now I have two other things to try to see if one, or a combination of all three, makes my life easier.

[Barbara Morris]

I think XML-INTO or XML-SAX would only help a little bit. The reasonCode, decision etc aren't XML attributes of the c:nvpReply tag. They're just the value of the tag. So XML-INTO or XML-SAX would only help you to get the string "reasonCode=102 decision=REJECT requestToken=alsdkjfIFHDlAGJADGlkdsgGAHdGLh requestID=9999999999999999". Still, that would be useful, even if it doesn't solve the main problem.

dcl-s string varchar(1000);
dcl-s xmlstring varchar(1000) inz('<c:nvpReply>reasonCode=102 decision=REJECT</c:nvpReply>');
xml-into string %xml(xmlstring : 'path=c:nvpReply');
dsply string;
// displays "reasonCode=102 decision=REJECT"
return;

[Whitecat27]

Greetings all,

I guess I don't understand why those do not seem to be attributes of "nvpReply" in Barbara's answer... after all, when looking at the article here: http://www.ibmsystemsmag.com/ibmi/de...NTO-Revisited/

I see no difference between the "nvpReply" tag and the "Name" tag in the example given in the article (other than the "Name" tag having a value in the article). The Data Structure for the OP's question could simply be something like;

D nvpReply         DS             Template
D   reasonCode           3A
D   decision            10A
D   requestID           30A
D   requestToken        16A

With the inclusion of "allow=missing", etc., XML-INTO should fill out the "nvpReply" Data Structure quite nicely.... given the original question about that one line of XML shown... Naturally, I've been way wrong too many times not to consider my approach could be an invalid opinion in this single case.


Best Regards,

Fred Williams

[Barbara Morris]

I guess I don't understand why those do not seem to be attributes of "nvpReply" in Barbara's answer... after all, when looking at the article here: http://www.ibmsystemsmag.com/ibmi/de...NTO-Revisited/

I see no difference between the "nvpReply" tag and the "Name" tag in the example given in the article (other than the "Name" tag having a value in the article).

Fred, the difference is that the XML in the article has quotes around the attribute values. Without the quotes, it's not well-formed XML. http://www.w3schools.com/xml/xml_attributes.asp (Sorry, I meant to include that information in my first response.)

Example from the article:

[FONT=courier][SIZE=10px]<Name category="Retail" ID="J020">Jones and Co.</Name>[/SIZE][/FONT]

Update: My bad. I forgot about the nature of the XML in the original post. As Scott points out in a later post, what looks like XML attributes is just part of the valeu of the "c:nvpReply" tag. Nothing to do with well-formed XML, since those name=value pairs are just text in the context of the XML document.

[Whitecat27]

Barbara,

Now I get it. I'd forgotten about the "w3scbools.com" way of thinking and I used a different XML validation webpage (which pronounced the OP example as well-formed). I sort of figured that maybe there was something I was forgetting.

Thanks for the reminder and the clarification, Barbara. XML-INTO is highly sensitive to the XML being well-formed... a fact that gave me sleepless nights when I first started playing around with XML-INTO.

However, with the XML-INTO results you described in an earlier post, I would still do this little task with XML-INTO and work with those results. I guess like everything else programming, it all comes down to personal preference.


Best Regards,

Fred Williams

[Scott Klement]

All XML documents should be well-formed. No XML reader should ever read a document that's not well-formed, that would go against the philosophy of XML! This was one of the big complaints about HTML was that different browsers all interpreted it differently (especially in the old days) some required closing tags, some did not, some tags didn't ever get closed, some did. When closing tags were missing, they'd all react differently, etc. A big part of XML's philosophy was to make it really clear and consistent. All tags must be closed, no matter what they are. No reader should process a document that isn't well-formed, it should always give an error, etc.

What does that have to do with the examples here, though? As far as I can tell, whether the document is well formed (or not) has nothing to do with the discussion. The discussion is about what to do with a string containing name/value pairs.

Fred, I think you are confusing XML attributes with a string containing name/value pairs. <mytag>var1=value var2=value2</mytag> is different from <mytag var1="value" var2="value2"></mytag> . In the first case, the name/values are just a character string, they're not part of the XML document. The second case, they are not just name/values in a string, they are XML attributes. Two different things.