RE: Saving INBOUND JSON (sent from the Web App) to the IFS

["Nadir Amra" <amra@xxxxxxxxxx>]

IBM does not say it is handy.  We plan on working on support to log 
incoming requests/responses.  But not sure when.  There is an RFE[1].

But logging is different than attempting to hand the request to the web 
service implementation code. 

[1] 
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=115871


"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 07/28/2019 
04:36:58 PM:

> From: B Stone <bvstone@xxxxxxxxx>
> To: Midrange Systems Technical Discussion 
<midrange-l@xxxxxxxxxxxxxxxxxx>
> Date: 07/28/2019 04:37 PM
> Subject: [EXTERNAL] Re: Saving INBOUND JSON (sent from the Web App) to 
the IFS
> Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>
>
> I do.  I don't see how you wouldn't.  I've done many projects with JSON 
and
> it's ALWAYS come in handy.
>
> I can't believe IBM doesn't think it would be (I assume for IWS).
>
>
> On Sun, Jul 28, 2019 at 1:11 PM Roberto De Pedrini 
<roberto.faq400@xxxxxxxxx>
> wrote:
>
> > I'm with Bradley, if you save original inbound JSON to your web 
service you
> > could use it to re-run a call to it or as a log.
> > I asked IBM lab to have the inbound JSON as metadata in some kind of
> > environment variables when I deploy my post-rest web services with IWS 
but
> > they didn't consider it so important.
> > Does anybody need to see inbound json in RPG/Cobol for web service 
logging?
> > Roberto De Pedrini
> > Faq400 - Italy
> >
> >
> > Il giorno mer 24 lug 2019 alle ore 01:03 B Stone <bvstone@xxxxxxxxx> 
ha
> > scritto:
> >
> > > It comes in VERY hand for debugging and logging what data actually 
came
> > > in.  I've used in at many clients and shared the new procedure with 
the
> > > OP.
> > >
> > > I didn't want to change anything in your code, and wanted to make is 
so
> > if
> > > I install a newer version all I do is take mine and leave it at the
> > > bottom.
> > >
> > > So that's why I made it separate with the optional stream file parm 
so if
> > > debug for the application is on, I supply the file name.  If not, I 
don't
> > > and it isn't created.  If you add the option I'd use that instead of
> > mine.
> > >  Overwriting would be my choice.  I always use unique IDs in 
production
> > for
> > > debugging/trace file names so overwriting isn't an issue.  That's 
just
> > me,
> > > though.
> > >
> > > I think in all it was an addition of maybe 6 lines of code.
> > >
> > > I remember asking the OPs same question a few years ago and people
> > > questioned why I would want that.  If you can't see the data coming 
in,
> > how
> > > do you know if it was correct.  Right?  Or what if it's required to
> > > log/store the data (as it is for a couple of my clients)?
> > >
> > > It's a simple update that adds a lot of functionality.
> > >
> > > Bradley V. Stone
> > > www.bvstools.com
> > > Need to interface with Braintree with your IBM i? Contact me
> > > <https://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.bvstools.com_contact.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=usb7JaJJtnMB9p4eb3pmGa8DSjbI5lbdnKnFv235svM&s=H_O2nnuQ6zFi_ZpapM6K3VZ4g_zu_dhv5hHNTx9yA6Y&e=
> > for more information!
> > > On Tue, Jul 23, 2019 at 5:17 PM Scott Klement <
> > midrange-l@xxxxxxxxxxxxxxxx
> > > >
> > > wrote:
> > >
> > > > Bradley,
> > > >
> > > > I assume this would only be desirable if reading input from stdin?
> > > > After all, in other cases, you already have the JSON data in your
> > > program.
> > > > It'd be easy enough to add this into YAJL, though I'd add it as an
> > > > optional parameter rather than create a new subprocedure.
> > > >
> > > > What should happen if the file already exists?  Replace it or 
append to
> > > > it?   The former would be better if you plan to process it later 
as a
> > > > json document, but the latter would be better if this is just 
intended
> > > > as a "log" (informational) type file and you don't plan to ever 
use it
> > > > directly.
> > > >
> > > > -SK
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://urldefense.proofpoint.com/v2/url?
u=https-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=usb7JaJJtnMB9p4eb3pmGa8DSjbI5lbdnKnFv235svM&s=sJ3bDYfv_XLessRtHajoPEGp-7Nk27fDLPKjJer6xtU&e=
> or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://urldefense.proofpoint.com/v2/url?
> u=https-3A__archive.midrange.com_midrange-2Dl&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=usb7JaJJtnMB9p4eb3pmGa8DSjbI5lbdnKnFv235svM&s=JCJ_rFTMP_Gs4xdiFLNXPrjeeMkuW6n2CgpdJ7ejBQY&e=
> .
>
> Please contact support@xxxxxxxxxxxx for any subscription related 
questions.
> Help support midrange.com by shopping at amazon.com with our affiliate 
link: 
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__amazon.midrange.com&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=usb7JaJJtnMB9p4eb3pmGa8DSjbI5lbdnKnFv235svM&s=PTgYpeKRbNT_TNPGfkhc7qngU_5NI0g1GS9EiY5F-
> cs&e=