[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Need help adjusting a WSDL2RPG stub program (lenghty email)
- From: thomas.raddatz@xxxxxx
- Subject: RE: Need help adjusting a WSDL2RPG stub program (lenghty email)
- Date: Fri, 3 Aug 2012 10:42:45 +0200
Michael,
Key 'AVAILABILITY_STATUS' is a map entry of the inner map of two nested
maps returned by the web service. A map is represented by WSDL2RPG as
an array where each item is a data structure with a 'key' and a 'value'
field. The data structures generated by WSDL2RPG usually match the
structure of the XML message, expect for arrays (and maps). XML
elements having a 'maxOccurs' attribute greater than 1 are transformed
into a data structure with an index field and the actual array.
<complexType name="AnyMap">
<sequence>
<element name="item" minOccurs="0" maxOccurs="unbounded"
type="apachesoap:anyMapItem"/>
</sequence>
<complexType name="anyMapItem">
<sequence>
<element name="key" nillable="true" type="xsd:anyType"/>
<element name="value" nillable="true" type="xsd:anyType"/>
</sequence>
</complexType>
Is transformed into:
The map itself:
D apachesoap_AnyMap_t...
D DS template
D qualified
D item
likeds(apachesoap_RpgArrayOfItem1_t)
Since I need an additinal index field for handling the array items,
element <item> is transformed into:
D apachesoap_RpgArrayOfItem1_t...
D DS template
D qualified
D x 10I 0
D anyMapItem likeds(apachesoap_anyMapItem_t)
Now 'anyMapItem' is the same as element <apachesoap:anyMapItem>:
D apachesoap_anyMapItem_t...
D DS template
D qualified
D key 128A varying
D value 128A varying
Now let us get back to the actual question: Where is
'AVAILABILITY_STATUS'?
Usually the easiest way to find the data is to look at the debug log in
order to find the name of the element that contains the data. Once you
found the data you can create the name of the RPG field by
concatenating the names of the XML elements. In your case that is a bit
more difficult, because your web service is RPC encoded and uses
<multiRef> elements.
So what you get back is:
<soapenv:Envelope
xmlns:soapenv="[1]http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="[2]http://www.w3.org/2001/XMLSchema";
xmlns:xsi="[3]http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<ns1:getDeviceInterfacesResponse
soapenv:encodingStyle="[4]http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns1="urn:Provision">
<getDeviceInterfacesReturn href="#id0"/>
</ns1:getDeviceInterfacesResponse>
<multiRef id="id0"
soapenc:root="0"
soapenv:encodingStyle="[5]http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="ns2:Map"
xmlns:soapenc="[6]http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns2="[7]http://xml.apache.org/xml-soap";>
<item>
<key xsi:type="soapenc:string">0.0</key>
<value href="#id1"/>
</item>
</multiRef>
<multiRef id="id1"
soapenc:root="0"
soapenv:encodingStyle="[8]http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="ns3:Map"
xmlns:ns3="[9]http://xml.apache.org/xml-soap";
xmlns:soapenc="[10]http://schemas.xmlsoap.org/soap/encoding/";>
<item>
<key xsi:type="soapenc:string">AVAILABILITY_STATUS</key>
<value xsi:type="soapenc:string">Failed</value>
</item>
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
In order to get rid of the <multiRef> elements you need to move each
<multiRef> element to its proper position in the XML. For example
href="#id0" addresses <multiRef> element <multiRef id="id0" ... >. So
the final XML document looks like this:
<soapenv:Envelope
xmlns:soapenv="[11]http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="[12]http://www.w3.org/2001/XMLSchema";
xmlns:xsi="[13]http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<ns1:getDeviceInterfacesResponse
soapenv:encodingStyle="[14]http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns1="urn:Provision">
<getDeviceInterfacesReturn>
<item>
<key xsi:type="soapenc:string">0.0</key>
<value>
<item>
<key
xsi:type="soapenc:string">AVAILABILITY_STATUS</key>
<value xsi:type="soapenc:string">Failed</value>
</item>
</value>
</item>
</getDeviceInterfacesReturn>
</ns1:getDeviceInterfacesResponse>
</soapenv:Body>
</soapenv:Envelope>
Now the first guess for the name of the RPG field that contains
'AVAILABILITY_STATUS' might be:
getDeviceInterfacesResponse.getDeviceInterfacesReturn.item(x).value.ite
m(y).value
Unfortunately that is wrong, because we are working with two nested
arrays!
Hence the right name is:
getDeviceInterfacesRpc.getDeviceInterfacesReturn.item.mapItem(x).value.
item.anyMapItem(y).value
It is 'getDeviceInterfacesRpc' instead of 'getDeviceInterfacesResponse'
because the test program uses this name instead of
'getDeviceInterfacesResponse'.
Another good starting point to get the RPG field name is the "Parameter
Structure Visualizer" (thanks to John Fox). The visualizer is started
with '*' or '*STMF' at parameter PARMSTRUCT of command WSDL2RPG. You
may specify '*NONE' for the member name to not generated a module. Its
output looks like this:
Service Response Parameters
---------------------------
o_getDeviceInterfacesRpc(impl_getDeviceInterfacesRpc_t)
getDeviceInterfacesReturn(impl_getDeviceInterfacesReturnMvd_t)
item(apachesoap_RpgArrayOfItem_t)
x(10I 0, *ARRAY_INDEX)
mapItem(apachesoap_mapItem_t, *STATIC_ARRAY)
key(128A varying)
value(apachesoap_AnyMap_t)
item(apachesoap_RpgArrayOfItem1_t)
x(10I 0, *ARRAY_INDEX)
anyMapItem(apachesoap_anyMapItem_t, *STATIC_ARRAY)
key(128A varying)
value(128A varying)
With the output of the visualizer you can easily concatenate the field
name by adding a dot for each indention. Arrays are flagged with
'*STATIC_ARRAY' for standard RPG arrays or with '*DYNAMIC_ARRAY' for
dynamic arrays.
o_getDeviceInterfacesRpc.getDeviceInterfacesReturn.item.mapItem(x).valu
e.item.anyMapItem(y).value
Eventually adjust the first part of the name to what the test program
generated by removing the 'o_':
getDeviceInterfacesRpc.getDeviceInterfacesReturn.item.mapItem(x).value.
item.anyMapItem(y).value
Sorry for that pretty lengthy email. I hope it helps to better
understand the way WSDL2RPG works. Feel free to ask question for
anything that is not yet clear enough.
Thomas.
ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 02.08.2012 23:55:52:
> Von: mkoester@xxxxxxxxxxxxx
> An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx,
> Datum: 03.08.2012 00:02
> Betreff: RE: Need help adjusting a WSDL2RPG stub program
> Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>
> Hi Thomas. I made big progress, thanks to you and your assistance
> (and patience). I'm shutting down for the week now, and will be
> back at it on Monday. Still trying to find my way around the data
> structures that should be returned to the test caller, and I haven't
> got the hang of it yet.
>
> Using your revised wsdl, I was able to generate the new stubs. Got
> the base stub and method stubs compiled to modules and put into a
> *SRVPGM. Got a test caller generated from Provision4.wsdl as well.
> Created *module and *pgm. Ran that. No run-time errors, debug log
> was generated.
>
> My challenge now is trying to decipher how to find the data
> structure where the desired results are supposed to be stored.
> Specifically, I'm looking for the key='AVAILABILITY_STATUS' and its
> associated value = 'Failed', but I haven't been able to set up the
> right data structure in the test caller to show anything in that
> level. I'm quite lost in the nested ds arrangements, and I can't be
> certain that the data from that level is even available (mostly
> because I don't know how to look for it).
>
> I've attached pretty much the whole project. (The in0 and in1
> inputs are set in the test caller's D specs).
>
> More fun on Monday...
> Thanks again!
> -- Michael Koester
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [[15]mailto:ftpapi-
> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Thomas Raddatz
> Sent: Thursday, August 02, 2012 11:30 AM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Need help adjusting a WSDL2RPG stub program
>
> Michael,
>
> There is really no need for copying the changes between WS3* and
> WS4* into your generated stub module. I attached WS3* and WS4* just
> to demonstrate the changes between the generated code of
> Provision3.wsdl and Provision4.wsdl.
>
> If I was you I would take Provision4.wsdl and let your version of
> WSDL2RPG generate a new stub module. Of course you then have to add
> your changes related to copy book NMS_PROTOS, etc.
>
> The key are the changes I applied to Provision3.wsdl (= your
> Provision.wsdl) to get my Provision4.wsdl!
>
> Thomas.
--
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.
References
1. http://schemas.xmlsoap.org/soap/envelope/
2. http://www.w3.org/2001/XMLSchema
3. http://www.w3.org/2001/XMLSchema-instance
4. http://schemas.xmlsoap.org/soap/encoding/
5. http://schemas.xmlsoap.org/soap/encoding/
6. http://schemas.xmlsoap.org/soap/encoding/
7. http://xml.apache.org/xml-soap
8. http://schemas.xmlsoap.org/soap/encoding/
9. http://xml.apache.org/xml-soap
10. http://schemas.xmlsoap.org/soap/encoding/
11. http://schemas.xmlsoap.org/soap/envelope/
12. http://www.w3.org/2001/XMLSchema
13. http://www.w3.org/2001/XMLSchema-instance
14. http://schemas.xmlsoap.org/soap/encoding/
15. mailto:ftpapi-
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------