The CALLASPPGM is emulating a HTTP environment, so you can benefit from the IceBreak functionality in a plain 5250 or batch environment. You can use session variables, ILOBS , SQL-Oneliners, XML, JSON etc. In this way you can easy implement webservice calls in an "old" 5250 app – you don't need the IceBreak core to execute the program from the web-stack.
The REQTYPE is where the payload to the POST'ed data is coming from:
If *VAR you can pass the variable with i.e. XML and IceBreak will automatically parse the XML stream and you can use the XML variables right away
If *STMF the payload is loaded from the IFS
And if *NONE it assumes that all parameters is from the querystring, and you don't do a POST but rather a GET operation
Btw. the CALLASPPGM needs to be incapsulated in a CLP or CLLE program. However, you can do the same with CALLICPGM except for returning the HTTP response in the CL variable. As a matter of fact, you should rather use CALLICEPGM if you don't require the "return value as CL var" - feature, for performance reasons.
Re: CALLASPPGM
Hi Syd;
The CALLASPPGM is emulating a HTTP environment, so you can benefit from the IceBreak functionality in a plain 5250 or batch environment. You can use session variables, ILOBS , SQL-Oneliners, XML, JSON etc. In this way you can easy implement webservice calls in an "old" 5250 app – you don't need the IceBreak core to execute the program from the web-stack.
The REQTYPE is where the payload to the POST'ed data is coming from:
Btw. the CALLASPPGM needs to be incapsulated in a CLP or CLLE program. However, you can do the same with CALLICPGM except for returning the HTTP response in the CL variable. As a matter of fact, you should rather use CALLICEPGM if you don't require the "return value as CL var" - feature, for performance reasons.
Best regards,
Niels Liisberg