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

Re: Null values and WSDL2RPG and HTTPAPI?



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
-----------------------------------------------------------------------