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

Re: [Ftpapi] Optional XML Labels



1+

That is how things have to be. I am looking forward to 7.3.

Thank you very much for the links to your presentations. Nice and useful.

We already use the "ON-EXIT" feature, because I noticed the posting of Barbara Morris at RPG400-L, when she introduced ON-EXIT. It is a "must have".

Thomas.


-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott Klement
Gesendet: Mittwoch, 8. März 2017 22:25
An: FTPAPI/HTTPAPI mailing list
Betreff: Re: [Ftpapi] Optional XML Labels

Thomas,

You don't have to define the null indicator field.   Please don't think 
that my example is the only way to do things!  You can do this, for example:

*dcl-s myfield char(123) nullind;**

**%nullind(myfield) = *on;**
**if %nullind(myfield) = *on;**
**   // do something**
**endif;*

Actually, that might be nicer than having the separate null indicator 
for a standalone field ;)   You can also do stuff like specify a data 
structure as the null indicator for another data structure.  Where the null data structure has indicators for each corresponding field in the other data structure.  Please read more about it in the RPG Reference.

Also, you can read the slides from a presentation I sometimes give about what's new in RPG here:
http://www.scottklement.com/presentations/#WHATSNEW

I use the chart in that presentation quite frequently to remember which releases the different features were available in.  Due to the fact that many of them were PTFed to previous releases, it can be hard to remember them all, so I find that the chart is handy.

The presentation is missing the "ON-EXIT" feature that was very recently added to RPG because I haven't added it yet.  If you are interested in ON-EXIT, you can read about it here:
http://ibm.biz/RPG_ON_EXIT_Section

I hope that these newer features are useful for you in WSDL2RPG (I had to say this so that this e-mail was on-topic for the mailing list, haha.)

-SK

On 3/8/2017 3:13 PM, Thomas Raddatz wrote:
> Hi Scott,
>
> Thank you for having enlightened me. The NULLIND keyword is promising 
> and it makes me think about whether or not it makes sense that I try 
> to change WSDL2RPG right now or wait for 7.3.
>
> But I wonder why we have to define the null indicator field. From my 
> point of view (I am a lazy developer) that is something the compiler 
> should do under the cover as it already does (I assume) for external 
> data structures with null-capable fields.
>
> Why must it be so often so complicated?
>
> Regards,
>
> Thomas.
>
> Am 08.03.2017 um 21:34 schrieb Scott Klement:
>> Thomas,
>>
>> I think he's referring to your statement that RPG doesn't support 
>> declaring null-capable fields.  However, I think Jon is wrong about 
>> 7.2
>> -- this was a 7.3 feature!  But, RPG does support null-capable 
>> fields, you can read about it under "What's New in 7.3" in the RPG 
>> Reference, search the page for "NULLIND":
>>
>> https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzasd/rpgrel
>> v7r3.htm
>>
>>
>>
>> An example would be:
>>
>> *ctl-opt alwnull(*usrctl);**
>>
>> **dcl-s myfield_null ind;**
>> **dcl-s myfield char(50) NULLIND(myfield_null);**
>> **
>> myfield_null = *on;   // myfield is now null**
>> *
>> (could also use *%nullind(myfield) = ***on*)
>>
>> etc.
>>
>> So in 7.3, RPG does support any field being null-capable, so you 
>> could potentially add that support to WSDL2RPG, that it uses those 
>> null indicators when a SOAP message supports nillable fields to 
>> indicate that null to the RPG program.  And when generating the 
>> response, you could check the null indicators and generate the XML 
>> according to whether it is/isn't null.
>>
>> At least, I think that's what Jon was trying to say.  (He didn't 
>> provide much detail.)
>>
>> -SK
>>
>> On 3/8/2017 2:08 PM, Thomas Raddatz wrote:
>>> Jon,
>>>
>>> Sorry, but what do you think would not work earlier that V7.2? The 
>>> 4MB buffer? It is heap storage dynamically allocated by WSDL2RPG and 
>>> controlled by the following procedure call:
>>>
>>>      hSoapPart =
>>>         MessageContext_getSoapPart(hMsgCtx: 1024*1024*4); // 4 MB 
>>> cache
>>>
>>> Regards,
>>>
>>> Thomas.
>>>
>>> Am 08.03.2017 um 20:47 schrieb Jon Paris:
>>>> It would not work for anything earlier than V7.2 I think Thomas - 
>>>> but the current support for creating your own null capable fields 
>>>> in RPG might lead to a possible solution.
>>>>
>>>>
>>>> Jon Paris
>>>>
>>>> www.partner400.com
>>>> www.SystemiDeveloper.com
>>>>
>>>>> On Mar 8, 2017, at 2:31 PM, Thomas Raddatz 
>>>>> <thomas.raddatz@xxxxxxxxxxx> wrote:
>>>>>
>>>>> Christian,
>>>>>
>>>>> Sadly WSDL2RPG does not support NULL values, which equals a 
>>>>> dropped element. The actual problem is that RPG does not support 
>>>>> NULL values and it is not possible to define "special" values for 
>>>>> recognizing a NULL value. For strings *BLANKS may work, but for 
>>>>> example "0" or any other value does not work for numeric values. 
>>>>> So actually you need an indicator for each nillable field. I did 
>>>>> not yet enhanced WSDL2RPG to support NULL values, because that is 
>>>>> a hell lot of work.
>>>>>
>>>>> Therefore please change the generated stub by hand to meet your needs.
>>>>>
>>>>> Here are some hints:
>>>>>
>>>>> a) WSDL2RPG generates a "Serializer" procedure for each data 
>>>>> structure of the request message. So if you do not want to 
>>>>> generate a whole data structure, just return the serializer 
>>>>> procedure immediately on a condition of your choice.
>>>>>
>>>>> b) Inside the serializer procedure parts of the XML are assigned 
>>>>> to field "g_requestBuffer". Then the content of "g_requestBuffer" 
>>>>> is append to the request message buffer by calling 
>>>>> OutputStream_appendGlobalRequestBuffer(). Afterwards the value of 
>>>>> the XML element is "marshalled" by a type specific "Marshaller", e.g.
>>>>> Marshaller_toStringV6().
>>>>>
>>>>> c) Just for your information: The request message buffer is a 4MB 
>>>>> memory block (default value) to cache the request message. When 
>>>>> the message exceeds 4MB it is dumped to an IFS file.
>>>>>
>>>>> d) It is up to you to define the conditions when a field (XML 
>>>>> element) or data structure (XML complex type) is not added to the 
>>>>> request message.
>>>>>
>>>>> e) You can safely add indicator field to the *_t template 
>>>>> variables to indicate whether or not something shall be 
>>>>> serialized. Make sure to compile everything of the stub after having changed a *_t field.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Thomas.
>>>>>
>>>>> Am 08.03.2017 um 14:16 schrieb larsenvalverde@xxxxxxxxx:
>>>>>> Hello.
>>>>>>
>>>>>> I’m using WSDL2RPG  to generate the stubs to connect to a webservice.
>>>>>>
>>>>>> I have a problem.
>>>>>>
>>>>>> The XML that I have to send (generated by WSDL2RPG), have a lot 
>>>>>> of “optional labels”.  When I don’t use them, the result XML have 
>>>>>> a lot of sentences like this:
>>>>>>
>>>>>>
>>>>>> …
>>>>>>      </LABEL1>
>>>>>>      </LABEL2>
>>>>>> …
>>>>>>
>>>>>> (because I cannot send the information of the LABEL1, LABEL2, …).
>>>>>>
>>>>>> If I send this to the webservice, the server give me an error, 
>>>>>> because I’m not sending the information of that “optional” labels.
>>>>>>
>>>>>> The question is… have I had to manually change the stubs 
>>>>>> generated by WSDL2RPG, or there another way to manage them??
>>>>>>
>>>>>>
>>>>>> Christian.
>>>>>>
>>>>> --
>>>>> _______________________________________________
>>>>> Ftpapi mailing list
>>>>> Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>>>>> http://scottklement.com/mailman/listinfo/ftpapi

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://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.
-- 
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi