[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Null values and WSDL2RPG and HTTPAPI?
Charles,
I greatly appreciate your feedback because you had some good ideas. To be
honest I do not tend to go with that special "setter" procedures because
people may want to pass the request or response message between their
procedures. Obviously that would be impossible with a stub internal data
structure.
But I like your "t_Int4_Nullable" idea. Today I generate the following code
for an array element like this:
<element name="anArray" type="xsd:string" maxoccurs="unbounded" />
D fooBaa...
D DS based(pDummy)
D anArray likeds(impl_RpgArrayOfAnArray_t)
*
D impl_RpgArrayOfAnArray_t...
D DS based(pDummy)
D qualified
D x 10I 0
D string like(xsd_string_of_string_t)
D dim(DIM_A1)
*
D xsd_string_of_string_t...
D S 128A varying
D based(pDummy)
For null-capable fields it could be the very same thing like this:
<element name="aNillable" type="xsd:string" nillable="true" />
D fooBaa...
D DS based(pDummy)
D aNullable likeds(impl_NillableOfANillable_t)
*
D impl_NillableOfANillable_t...
D DS based(pDummy)
D qualified
D value like(xsd_string_of_string_t)
D isNull N
*
D xsd_string_of_string_t...
D S 128A varying
D based(pDummy)
Instead of calling the marshaller like this:
'<s0:City>' +
Marshaller_toString(
i_impl_fooBaa.aNillable
) +
'</s0:City>' +
I could it do this way:
if (not i_impl_fooBaa.aNillable.isNull);
request = request +
'<s0:City>' +
Marshaller_toString(
i_impl_fooBaa.aNillable.value
) +
'</s0:City>';
endif;
> with the WSDL. Which could be then could be checked in the setter
> procedure in case the developer is trying to use a NULL value where
> it's not allowed...
Maybe I could do it so:
if (not i_impl_fooBaa.aNillable.isNull);
request = request +
'<s0:City>' +
Marshaller_toString(
i_impl_fooBaa.aNillable.value
) +
'</s0:City>';
else;
sendEscMsg('NULL not allowed');
endif;
At the moment there is no time to get into details because I am about to
release v1.13 which will include significant enhancements like:
a) better support of choice types
b) http redirection
c) batch installer
d) option to write the structure of the request and
response messages to a stream file
e) Base64 stream encoder procedure
(simplifies encoding a given stream file)
f) minor improvements and bug fixes
Regards,
Thomas.
Am 05.01.2011 14:31, schrieb Charles Wilt:
> Thomas,
>
> Yeah, I was afraid of that....especially once I looked at the
> marshaling procedures. :)
>
> Strings might not be too bad, given the use of varying strings,
> wouldn't a zero length string be sufficient to indicate a null value?
>
> The rest of the data types are another story of course!
>
> The best way I'm come up with is to use complex types instead of
> simple types....so for example...
>
> d t_Int4_Nullable ds qualified based(TEMPLATE)
> d value 20i 0
> d isNull n
>
> But that might be difficult to shoehorn into WSDL2RPG without braking
> backwards compatibility
>
> One possible solution...continue to generate the definitions that come
> in as part of the prototype
> D tns_addContact_t...
> D DS based(pDummy)
> D qualified
> D contact likeds(wns2_Contact_t)
> D intVal 10I 0
> D longVal 20I 0
> *
> *
> D tns_addContactResponse_t...
> D DS based(pDummy)
> D qualified
> D result 20I 0
> *
> *
> D wns2_Contact_t DS based(pDummy)
> D qualified
> D catalogMailings...
> D N
> D contactFirstName...
> D 128A varying
> D contactLastName...
> D 128A varying
> D decisionMaker N
> D email 128A varying
> D faxNumber 20I 0
>
> But add a second set of definitions using complex "nullable" types
> that are used only in the STUB module.
>
> Along with some extra "setter" procedures in the stub module that set
> nullable version....
>
> Existing code could continue to work like so
> D parameters DS likeds(tns_addContact_t)
> D inz
> /free
> parameters.contact.catalogMailings = *ON;
> parameters.contact.contactFirstName = 'string';
> parameters.contact.contactLastName = 'string';
> parameters.contact.decisionMaker = *ON;
> parameters.contact.email = 'string';
> parameters.contact.faxNumber = 0;
>
> // Now let's call the web service.
> addContactResponse =
> ContactMaintainerPort_addContact(
> parameters:
> errText);
> /end-free
>
> New code that needed NULL support could do something like so:
>
> /free
> ContactMaintainerPort_set_contact_catalogMailings(*ON);
> ContactMaintainerPort_set_contact_contactFirstName('string');
> ContactMaintainerPort_set_contact_contactLastName('string');
> ContactMaintainerPort_set_contact_decisionMaker(*ON);
> ContactMaintainerPort_set_contact_email('string');
> ContactMaintainerPort_set_contact_faxNumber(*OMIT); //
> NOTE: fax number will be NULL
>
> addContactResponse =
> ContactMaintainerPort_addContact(
> *OMIT: //means use the internal DS
> errText);
>
>
> I supposed that you could also simply expose a second DS with the
> complex nullable types....but it seems to me it might be nice to hide
> the implementation in the stub module.
>
> hiding the implementation would allow you to have a complex type that
> looked like so:
> d t_Int4_Nullable ds qualified based(TEMPLATE)
> d value 20i 0
> d isNull n
> d allowNull n
>
> The allow Null variable would be set by generated code in accordance
> with the WSDL. Which could be then could be checked in the setter
> procedure in case the developer is trying to use a NULL value where
> it's not allowed...
>
>
> Feel free to contact me offline...for my POC, I'll just handcode the
> XML and use HTTPAPI directly...but I'd be willing to try to help add
> null support to WSDL2RPG for my actual project.
>
> Charles
>
>
>
>
>
> On Tue, Jan 4, 2011 at 4:25 PM, Thomas Raddatz
> <thomas.raddatz@xxxxxxxxxxx> wrote:
>> Charles,
>>
>> I am sorry, but there is no NULL support in WSDL2RPG. That is something you
>> have to do by hand.
>>
>> The problem is that RPG lacks true NULL support. If I wanted to support
>> NULL values I would have to generate NULL indicator fields for each XML
>> element having nillable="true" because *BLANK or *ZERO values do not
>> necessarily indicate a NULL value. So far I avoided these additional fields
>> to keep things simple.
>>
>> However I am open to any suggestions of how to add NULL support in WSDL2RPG.
>>
>> Thomas.
>>
>> Am 04.01.2011 21:18, schrieb Charles Wilt:
>>> All,
>>>
>>> Finally got my chance to create call and web service from RPG...
>>>
>>> WSDL2RPG and HTTPAPI should make quick work of my POC...
>>>
>>> One question, in the test program generated by WSDL2RPG, how to I
>>> indicate that some values are null?
>>>
>>> The WSDL for the service in question has:
>>> <xsd:complexType name="Contact">
>>> <xsd:sequence>
>>> <xsd:element type="xsd:boolean" name="catalogMailings"
>>> minOccurs="1" maxOccurs="1"/>
>>> <xsd:element type="xsd:string" name="contactFirstName"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:string" name="contactLastName"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:boolean" name="decisionMaker"
>>> minOccurs="1" maxOccurs="1"/>
>>> <xsd:element type="xsd:string" name="email"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:long" name="faxNumber"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:string"
>>> name="generalInstructions" minOccurs="1" maxOccurs="1"
>>> nillable="true"/>
>>> <xsd:element type="xsd:long" name="id" minOccurs="1"
>>> maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:long" name="mobilePhoneNumber"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:boolean"
>>> name="opinionSurveyMailings" minOccurs="1" maxOccurs="1"/>
>>> <xsd:element type="xsd:boolean" name="otherMailings"
>>> minOccurs="1" maxOccurs="1"/>
>>> <xsd:element type="xsd:int" name="phoneExtension"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:long" name="phoneNumber"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> <xsd:element type="xsd:boolean" name="prcContact"
>>> minOccurs="1" maxOccurs="1"/>
>>> <xsd:element type="xsd:string" name="title"
>>> minOccurs="1" maxOccurs="1" nillable="true"/>
>>> </xsd:sequence>
>>>
>>> Thanks!
>>> Charles
>>> -----------------------------------------------------------------------
>>> 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
-----------------------------------------------------------------------