[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing tags in the web service XML creation



Scott - Thanks for your reply. Your inputs have helped me a lot to
understand the pros and cons of the different ways of doing the web
service calls. 

I have dropped the plan of using Thomas's WSDL2RPG as his tool will take
some time to complete the <extension> in conjunction with <sequence> in
order to make the correct web service call. Hence we are for now
manually preparing the XML file and using IBM MQ Client to post the
message. We are then writing the XML parsing using the XML SAX.

Wish me good luck.

Regards
Kalyan
------------------------------------------------------------------------
--

Message: 3
Date: Thu, 27 Aug 2009 17:48:17 -0500
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
Subject: Re: Missing tags in the web service XML creation
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <4A970D31.4030002@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

hello Kalyan,

> - If it is worth a question can you please tell me how different is
> EXPAT compared to IBM supplied XML-SAX parser? I just started reading
> documentation on IBM for XML parsing.

The general concept of XML-SAX and Expat are about the same.  The 
overall paradigm is the same.

With regards to how they read the XML data.  XML-SAX is simpler, but 
Expat is more flexible.  With Expat, you have to write your own routine 
to read the data -- which means you have to do more work.  That gives 
you added flexibilty (for example, you can get the data from a network 
instead of a disk file) but you need to know/understand the programming 
to do so.  XML-SAX reads the file for you, which means you don't have to

do it -- but is only capable of reading a variable or stream file.  It 
can't read from a pointer or network socket.

With regards to how the handlers work...   XML-SAX calls only one 
handler routine, and passes an integer that identifies which event has 
occurred. The parameter list is therefore the same for every event 
(which it has to be, since there's only one routine to call)

By contrast, Expat requires a separate event handler for each event, and

has parameter lists taylored for that event.

Those are the main differences -- and about as much as I can explain 
without turning it into a very long complicated e-mail message.


> - I am trying to understand your sample programs in LIBHTTP and find
> which is going to be the version I should use as there seems to be
> different methods of XML parsing in there.

Hmmm... not sure that I follow that?  Maybe I'm interpreting the word 
"method" differently than you mean it, but...   there's only one method 
of parsing included with HTTPAPI, and that's Expat.

You can, of course, get the document itself and parse it with a 
different parser that's not included with HTTPAPI.


> - Also I do not know if I can use SOAPUI since our company has already
> developed a generic RPG application to generate a XML file to POST to
> the web service. Would that cause any issues in using your EXPAT
utility
> to parse the response file?

Weren't you planning to use Thomas Raddatz's WSDL2RPG?? I'm confused. 
SoapUI would calculate the SOAP message, just as Thomas's tool would do 
it.  The only difference is that SoapUI won't generate RPG code for you,

you'll have to generate it yourself.

If your company is already generatign the SOAP message, then you'd want 
to use HTTPAPI directly, and not go through SoapUI *or* WSDL2RPG.

Unless you mean that your company's data is actually an XML payload of a

SOAP message, as opposed to the SOAP message itself.  If that's the 
case, then you should be able to use it with either approach.

> - Lastly, your example in HTTPXMLR4 seems to contain both HTTP POST as
> well as EXPAT parsing. Is that correct?

HTTPXMLR4 is *not* an example.  It's one of the modules of HTTPAPI.  The

examples are named EXAMPLE1, EXAMPLE2, EXAMPLE3, and so forth.

HTTPXMLR4 is part of the code of the HTTPAPIR4 service program, and is 
definitely not something I'd start learning from, as it's rather 
advanced coding.


------------------------------

Message: 4
Date: Fri, 28 Aug 2009 08:46:55 +0200
From: thomas.raddatz@xxxxxx
Subject: Antwort: Re: Missing tags in the web service XML creation
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Message-ID:
	
<OFD8BCA23F.DA3A829B-ONC1257620.00223E99-C1257620.00254762@xxxxxx>
Content-Type: text/plain; charset=US-ASCII


Kalyan,

> - I am trying to understand your sample programs in LIBHTTP and find
> which is going to be the version I should use as there seems to be
> different methods of XML parsing in there.

Usually you will use http_post_xml() to send your SOAP request to the
server and automatically invoke the eXpat parser on the response
received
from the server. I assume that this approach is common sense for calling
a
web service. http_post_xml() is the very same procedure as
http_url_post_xml(). It is mapped to http_url_post_xml() in member
HTTPAPI_H. I do not know why both procedure names exist.

Some times, but I cannot explain why, you will use http_url_get() or
http_url_post() to send a request to the server but put the response
into
an IFS stream file. Then you can decide whether to start a parser for
the
data in the stream file or not. Procedure http_parse_xml_stmf() is used
for
that purpose. It takes the name of an existing stream file and the
address
of the callback procedure to use. Then it starts the eXpat parser and
the
parser will call the callback procedure for each element it reads from
the
stream file.

> - Lastly, your example in HTTPXMLR4 seems to contain both HTTP POST as
> well as EXPAT parsing. Is that correct?

As Scott already mentioned, HTTPXMLR4 is part of the HTTP API service
program. It is not an example program. The following sample programs
demonstrate how to use http_url_post_xml()/http_post_xml():

   EXAMPLE16 - UPS package tracking
   EXAMPLE18 - Currency converter
   EXAMPLE19 - Language translation
   EXAMPLE20 - Currency converter (long SOAP action)

Thomas.


ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 28.08.2009 00:18:13:

> Von:
>
> KTirumamidi@xxxxxxxxxxxxxxx
>
> An:
>
> ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>
> Datum:
>
> 28.08.2009 00:22
>
> Betreff:
>
> Re: Missing tags in the web service XML creation
>
> Gesendet von:
>
> ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>
> Scott - Upon reading the articles I am leaning towards your idea.
>
> - If it is worth a question can you please tell me how different is
> EXPAT compared to IBM supplied XML-SAX parser? I just started reading
> documentation on IBM for XML parsing.
>
> - I am trying to understand your sample programs in LIBHTTP and find
> which is going to be the version I should use as there seems to be
> different methods of XML parsing in there.
>
> - Also I do not know if I can use SOAPUI since our company has already
> developed a generic RPG application to generate a XML file to POST to
> the web service. Would that cause any issues in using your EXPAT
utility
> to parse the response file?
>
> - Lastly, your example in HTTPXMLR4 seems to contain both HTTP POST as
> well as EXPAT parsing. Is that correct?
>
> Thanks advance,
>
> Regards
> Kalyan
>
>
>
> Message: 1
> Date: Thu, 27 Aug 2009 12:46:34 -0500
> From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
> Subject: Re: Missing tags in the web service XML creation
> To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID: <4A96C67A.4010103@xxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello,
>
> > Here is what is happening. The tags between <q0:paymentRequest> and
> > </q0:paymentRequest> are not being generated.
>
> I just want to point out that you can use HTTPAPI with SoapUI. To get
> this service working.  It's a little more effort than using WSDL2RPG,
> but if you have a looming deadline, this might get you going quicker
> than waiting for Thomas to update WSDL2RPG.
>
> Surely doing that is 100 times simpler than switching to another
> technology like MQ!
>
>
> -----------------------------------------
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or
> entity to which it is addressed. If the reader of this e-mail is
> not the intended recipient or his or her authorized agent, the
> reader is hereby notified that any dissemination, distribution or
> copying of this e-mail is prohibited. If you have received this
> e-mail in error, please notify the sender by replying to this
> message and delete this e-mail immediately.
>
-----------------------------------------------------------------------
> 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.


------------------------------

Message: 5
Date: Fri, 28 Aug 2009 11:41:54 -0500
From: Mohamed Musthafa Safarulla <mohamedmusthafa.safarulla@xxxxxxxxx>
Subject: Re: No SOAP input for WS!
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID:
	<ffab07660908280941x3d11bfe8k98aeb9872f9db789@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Sorry. The code i posted i was trying all combination to see if it
works.
Actually the program had serviceXML elements wraps everything. Sorry for
the
confusion.

Thanks,
Musthafa

On Thu, Aug 27, 2009 at 4:07 PM, Scott Klement
<klemscot@xxxxxxxxxxxx>wrote:

>
>   Hello,
>    > WS works fine when we call it from the WS testing utility but the
WS
>   > expert removed the header and methode name element from the SOAP
to
>   > make it work in that utility. Just used the basic XML data input
>   > element to test it. WSDL is attached.
>    The XML document from your debug log and RPG code is not the same
as
>   the one in this WSDL.  The WSDL wants it to look like this:
>   <SOAP:Envelope
>   xmlns:SOAP=[1]"http://schemas.xmlsoap.org/soap/envelope/";
>                  xmlns:tns=[2]"http://tempuri.org/";>
>      <SOAP:Header/>
>      <SOAP:Body>
>         <tns:CalculateTransitDates>
>            <tns:serviceXML> your-value here </tns:serviceXML>
>          </tns:CalculateTransitDates>
>      </SOAP:Body>
>   </SOAP:Envelope>
>    Your code doesn't have <tns:serviceXML> -- instead it has
>   tns:ServiceDS and tns:ServiceParam.  These aren't defined anywhere
in
>   the WSDL.  One wonders where you got the SOAP that you are passing
to
>   the web service?  Because it sure doesn't look like the SOAP that
the
>   WSDL expects.
>
> References
>
>   1. http://schemas.xmlsoap.org/soap/envelope/
>   2. http://tempuri.org/
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
>



-- 
Thanks,
Musthafa
-------------- next part --------------

   Sorry. The code i posted i was trying all combination to see if it
   works. Actually the program had serviceXML elements wraps everything.
   Sorry for the confusion.
   Thanks,
   Musthafa

   On Thu, Aug 27, 2009 at 4:07 PM, Scott Klement
   <[1]klemscot@xxxxxxxxxxxx> wrote:

       Hello,

     > WS works fine when we call it from the WS testing utility but the
   WS
     > expert removed the header and methode name element from the SOAP
   to
     > make it work in that utility. Just used the basic XML data input
     > element to test it. WSDL is attached.

       The XML document from your debug log and RPG code is not the same
     as
       the one in this WSDL.  The WSDL wants it to look like this:
       <SOAP:Envelope
       xmlns:SOAP=[1]"[2]http://schemas.xmlsoap.org/soap/envelope/";
                      xmlns:tns=[2]"[3]http://tempuri.org/";>
          <SOAP:Header/>
          <SOAP:Body>
             <tns:CalculateTransitDates>
                <tns:serviceXML> your-value here </tns:serviceXML>

           </tns:CalculateTransitDates>
        </SOAP:Body>
     </SOAP:Envelope>

       Your code doesn't have <tns:serviceXML> -- instead it has
       tns:ServiceDS and tns:ServiceParam.  These aren't defined
     anywhere in
       the WSDL.  One wonders where you got the SOAP that you are
     passing to
       the web service?  Because it sure doesn't look like the SOAP that
     the
       WSDL expects.
     References
       1. [4]http://schemas.xmlsoap.org/soap/envelope/
       2. [5]http://tempuri.org/

 
----------------------------------------------------------------------
   -
   This is the FTPAPI mailing list.  To unsubscribe, please go to:
   [6]http://www.scottklement.com/mailman/listinfo/ftpapi
 
----------------------------------------------------------------------
   -

   --
   Thanks,
   Musthafa

References

   1. mailto:klemscot@xxxxxxxxxxxx
   2. http://schemas.xmlsoap.org/soap/envelope/
   3. http://tempuri.org/
   4. http://schemas.xmlsoap.org/soap/envelope/
   5. http://tempuri.org/
   6. http://www.scottklement.com/mailman/listinfo/ftpapi

------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list digest.  To unsubscribe, go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------


End of Ftpapi Digest, Vol 38, Issue 27
**************************************
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------