IBM i Global

 View Only
Expand all | Collapse all

IWS API Manager / Orchestrator?

  • 1.  IWS API Manager / Orchestrator?

    Posted Wed November 23, 2022 01:51 AM
    Good afternoon All, 

    I as able to progress from my previous question: How to implement the RESTful API with a mixed set of *ENTRY parameter list | IBM i

    I updated the *ENTRY PLIST of our APIs so it will define the individual parameters rather than 1 big string. Now i am able to expose our RPGLE APIs as RESTful endpoints via IWS. Below is the PCML generated for reference: 

    <pcml version="6.0">
    <!-- RPG program: R_H15ARR -->
    <!-- created: 2022-11-07-18.18.06 -->
    <!-- source: JAWILIJ1/QRPGLESRC(R_H15ARR) -->
    <!-- 52908 -->
    <struct name="DSAIMR">
    <data name="R_GZWSID" type="char" length="4" usage="inherit" />
    <data name="R_GZDIM" type="zoned" length="2" precision="0" usage="inherit" />
    <data name="R_GZTIM" type="zoned" length="6" precision="0" usage="inherit" />
    <data name="R_GZSEQ" type="packed" length="7" precision="0" usage="inherit" />
    <data name="R_GZIMG" type="char" length="1" usage="inherit" />
    <data name="R_GZAB" type="char" length="4" usage="inherit" />
    <data name="R_GZAN" type="char" length="6" usage="inherit" />
    <data name="R_GZAS" type="char" length="3" usage="inherit" />
    <data name="R_GZBRNM" type="char" length="4" usage="inherit" />
    <data name="R_GZPBR" type="char" length="5" usage="inherit" />
    <data name="R_GZPSQ" type="packed" length="5" precision="0" usage="inherit" />
    <data name="R_GZVFR" type="zoned" length="7" precision="0" usage="inherit" />
    <data name="R_GZBRND" type="char" length="4" usage="inherit" />
    <data name="R_GZDRF" type="char" length="16" usage="inherit" />
    <data name="R_GZAMA" type="packed" length="15" precision="0" usage="inherit" />
    <data name="R_GZAPP" type="char" length="2" usage="inherit" />
    <data name="R_GZTCD" type="char" length="3" usage="inherit" />
    <data name="R_GZCCY" type="char" length="3" usage="inherit" />
    <data name="R_GZSRC" type="char" length="2" usage="inherit" />
    <data name="R_GZUC1" type="char" length="3" usage="inherit" />
    <data name="R_GZUC2" type="char" length="3" usage="inherit" />
    <data name="R_GZNPE" type="packed" length="5" precision="0" usage="inherit" />
    <data name="R_GZNR1" type="char" length="35" usage="inherit" />
    <data name="R_GZNR2" type="char" length="35" usage="inherit" />
    <data name="R_GZNR3" type="char" length="35" usage="inherit" />
    <data name="R_GZNR4" type="char" length="35" usage="inherit" />
    <data name="R_GZRFR" type="char" length="1" usage="inherit" />
    <data name="R_GZAUT" type="char" length="1" usage="inherit" />
    <data name="R_GZSSI" type="char" length="1" usage="inherit" />
    <data name="R_GZFRV" type="char" length="1" usage="inherit" />
    <data name="R_GZTTP" type="char" length="1" usage="inherit" />
    <data name="R_GZHSRL" type="char" length="16" usage="inherit" />
    <data name="R_GZHAMT" type="packed" length="15" precision="0" usage="inherit" />
    <data name="R_GZAUTC" type="char" length="12" usage="inherit" />
    <data name="R_GZCED" type="char" length="1" usage="inherit" />
    <data name="R_GZCHQ" type="char" length="1" usage="inherit" />
    <data name="R_GZDRFN" type="packed" length="16" precision="0" usage="inherit" />
    <data name="R_GZINW" type="char" length="1" usage="inherit" />
    <data name="R_GZRAU" type="char" length="1" usage="inherit" />
    <data name="R_GZEMN1" type="char" length="4" usage="inherit" />
    <data name="R_GZRAU1" type="char" length="1" usage="inherit" />
    <data name="R_GZEMN2" type="char" length="4" usage="inherit" />
    <data name="R_GZRAU2" type="char" length="1" usage="inherit" />
    <data name="R_GZEMN3" type="char" length="4" usage="inherit" />
    <data name="R_GZRAU3" type="char" length="1" usage="inherit" />
    <data name="R_GZEMN4" type="char" length="4" usage="inherit" />
    <data name="R_GZRAU4" type="char" length="1" usage="inherit" />
    <data name="R_GZMCH" type="char" length="1" usage="inherit" />
    <data name="R_GZTCCY" type="char" length="3" usage="inherit" />
    <data name="R_GZTAMA" type="packed" length="15" precision="0" usage="inherit" />
    <data name="R_GZTCED" type="char" length="1" usage="inherit" />
    <data name="R_GZHCCY" type="char" length="3" usage="inherit" />
    <data name="R_GZEAN" type="char" length="20" usage="inherit" />
    <data name="R_GZGDP" type="char" length="1" usage="inherit" />
    <data name="R_GZPSQ7" type="packed" length="7" precision="0" usage="inherit" />
    </struct>
    <program name="R_H15ARR" path="/QSYS.LIB/QTEMP.LIB/R_H15ARR.PGM">
    <data name="#ZWSID" type="char" length="4" usage="inputoutput" />
    <data name="#ZDIM" type="packed" length="2" precision="0" usage="inputoutput" />
    <data name="#ZTIM" type="packed" length="6" precision="0" usage="inputoutput" />
    <data name="#ZSEQ" type="packed" length="7" precision="0" usage="inputoutput" />
    <data name="GZJTT" type="char" length="1" usage="inputoutput" />
    <data name="@LIB" type="char" length="10" usage="inputoutput" />
    <data name="@VALD" type="char" length="1" usage="inputoutput" />
    <data name="@PGM" type="char" length="10" usage="inputoutput" />
    <data name="DSAIMR" type="struct" struct="DSAIMR" usage="inputoutput" />
    <data name="GZREC" type="char" length="1" usage="inputoutput" />
    <data name="GZMES7" type="char" length="37" usage="inputoutput" />
    <data name="AOW" type="char" length="37" count="20" usage="inputoutput" />
    <data name="@EM" type="char" length="37" count="20" usage="inputoutput" />
    <data name="@AEXT" type="char" length="1" usage="inputoutput" />
    <data name="@AREC" type="char" length="1" usage="inputoutput" />
    <data name="@EMH" type="char" length="37" count="20" usage="inputoutput" />
    <data name="@EA" type="packed" length="15" precision="0" count="20" usage="inputoutput" />
    <data name="@EB" type="char" length="4" count="20" usage="inputoutput" />
    <data name="@DR" type="char" length="1" count="20" usage="inputoutput" />
    </program>
    </pcml>

    I am now able to do a POST using the RESTFul endpoint generated from the above PCML. However as you can imagine, the request body contains every single parameter, many of which are actually optional (refer to DSAIMR struct above, so many fields included by default). Am thinking

    1. do i need some sort of API manager to "hide" some of the fields, default some of the fields so that the REST endpoint is more "end user friendly" with only the bare minimum required fields, or to orchestrate / combine the RESTful API endpoints into a composite or semantic type of API? Is this the proper architectural pattern for managing the RPGLE RESTful API endpoints from IWS?

    2. For your RESTful RPGLE API endpoints what do you use in your applications for managing the endpoints, and for things like security token based authentication?

    3. our clients deploy our software on prem, not cloud based, and 3rd party banking applications that might use these RPGLE RESTful endpoints are likely deployed on prem as well, things like Tellering systems, Party systems, Cash Management etc. So im thinking if the answer to 1 is yes, then for performance considerations, i will need the API manager to be deployed on premise as well rather than cloud based like Azure/Mulesoft/AWS etc. 

    Your inputs are much appreciated. Thanks!

    ------------------------------
    [Joel]
    ------------------------------


  • 2.  RE: IWS API Manager / Orchestrator?

    IBM Champion
    Posted Wed November 23, 2022 04:35 AM
    Edited by Satid Singkorapoom Wed November 23, 2022 05:02 AM
    Dear Joel

    This is not a direct answer to your question as I'm not a programmer.  I'll let others respond with direct answers.

    Since I just re-read your original question "1. the "modernization" or the screens for browser based access, we still use HATS with Webfacing - are there alternatives to this? ",  let me say that it should be a better approach for you to use a web deployment and/or RESTful API enablement tools that work with 5250-based applications to help with your attempt because the tools can help generate the resulting codes for you.  There are several such solutions for IBM i that I observe and one of which appearing frequently in my own observation is Rocket SW which has 2 products that may match your case (judging from your questions).  

    • Rocket Modern Experience web deployment tool for mainframe and IBM i, supporting COBOL and RPG. It has an old name of Rocket LegaSuite. This tool was originally from Seagull SW which has been around for a long time in IBM i world and was taken over by Rocket SW.
    • Rocket API which claims to "enables developers to create application APIs from host-based applications-without requiring modifications to the underlying source."    API here is REST API.

    You can search in Google and Youtube with "rocket legasuite" and "rocket api" to find more details and demo videos to see if it appeals to your case or not. Then you can also look into other such products.  This recent article lists 10 such solutions (including Rocket) : https://www.softwaretestinghelp.com/ibm-i-modernization-services/.  From my own experience, ARCAD and Rocket SW have their presence in ASEAN geography.  Others in the list may do as well outside of my awareness.

    Whichever one catches your interest, do not forget to ask them for a free trail period for you to play around with the tool.  I'm fairly confident most, if not all, of them provide free trial period.

    Just my 2 cents.

    ------------------------------
    Right action is better than knowledge; but in order to do what is right, we must know what is right.
    -- Charlemagne

    Satid Singkorapoom
    ------------------------------



  • 3.  RE: IWS API Manager / Orchestrator?

    Posted Thu November 24, 2022 01:32 AM
    Thanks Satid, will check these recommendations out.

    ------------------------------
    [Joel]
    ------------------------------



  • 4.  RE: IWS API Manager / Orchestrator?

    Posted Thu November 24, 2022 01:33 AM
    Thanks Wim, will check this out as well.

    ------------------------------
    [Joel]
    ------------------------------



  • 5.  RE: IWS API Manager / Orchestrator?

    Posted Wed November 23, 2022 05:03 AM

    Hello Joel,

     

    The way IWS generates a wrapper around an RPG program using PCML is a quick way to expose an RPG program over HTTP. Now you have a glimpse of its power, you want to consider going the OpenAPI route. OpenAPI is the worldwide standard for describing REST services (formerly known as Swagger). Then you can use tooling (like our OpenAPI Studio) to generate RPG Rest services, clients, and documentation from this specification.

     

    You do not want to communicate over a PLIST. Instead, you interface to your program using a JSON structure like all the professional APIs out there.

     

    Call your endpoints over Apache/NGinX with CGi. CGi goes directly from the client into your RPG program, giving you split-second response times without having to have a Java middleware doing coding and decoding for you.

     

    Constructing/Deconstructing JSON can be done with the fabulous NOXDB open-source library. The same author also provides a microservice architecture called ILEAstic (pronounced as ilastic).

     

    Remain Software has a very affordable solution that enables you to design your REST service and generate royalty-free RPG Free Rest Services that do the JSON parsing for you. It also provides JWT security token generation and session management. In addition, it includes a lovely API Designer that runs in RDi or as a standalone client. You can test the API Designer (without the RPG generator) by downloading it here:

     

    https://remainsoftware.com/designing-rest-api-oas-and-remain-api-studio

     

    Ping me if you want to test the generator or require a demo.   

     

     

    Best regards,

     

    Wim Jongman, CTO

    +31(0)622371297

     

     

    remainsoftware-logo

    Embrace Change. Remain In Control.

     

    www.remainsoftware.com

    See our video to learn more about Remain.

     

           linekdin    

     






  • 6.  RE: IWS API Manager / Orchestrator?

    Posted Fri November 25, 2022 01:58 PM
    I disagree  with this comment "You do not want to communicate over a PLIST. " .  Not sure why you even state this.

    ------------------------------
    Nadir K Amra
    ------------------------------



  • 7.  RE: IWS API Manager / Orchestrator?

    Posted Sun November 27, 2022 08:03 AM

    > Not sure why you even state this.

     

    I explain that in the sentence directly after:

     

    ..." Instead, you interface to your program using a JSON structure like all the professional APIs out there."

     

    Do you disagree with this?

     

    I'm advocating using the OpenAPI specification to describe the interface to REST services and using JSON to communicate the input and output. My RPG Free server programs extract all information directly from the HTTP request. Therefore I don't expose the internal structure of my programs to the network. The latter is critical to me, but there are more good reasons to favor JSON communication over using a PLIST. One is that it is easy to evolve your API using JSON but very hard when using a PLIST.

     

    Best regards,

     

    Wim Jongman, CTO

    +31(0)622371297

     

     

    remainsoftware-logo

    Embrace Change. Remain In Control.

     

    www.remainsoftware.com

    See our video to learn more about Remain.

     

           linekdin    

     

     

     

     






  • 8.  RE: IWS API Manager / Orchestrator?

    Posted Sun November 27, 2022 12:39 PM
    I  do  agree with this.  That is IWS server does, expose ILE programs and services programs to the world as REST APIs using JSON or XML.

    ------------------------------
    Nadir K Amra
    ------------------------------



  • 9.  RE: IWS API Manager / Orchestrator?

    IBM Champion
    Posted Mon November 28, 2022 03:14 AM
    I totally agree with you on that Wim - can i quote you on it? 

    I guess you prefer to use a framework rather that a server technology to build your API. The framework path like fastAPI for python or express for node.js or spring-boot for Java will also be my first choice. For that reason i stated the ILEastic project - The Serverless architecture for ILE .

    https://github.com/sitemule/ILEastic

    .. But you already know that ...



    ------------------------------
    Niels Liisberg
    ------------------------------



  • 10.  RE: IWS API Manager / Orchestrator?

    Posted Tue November 29, 2022 02:03 PM

    > I totally agree with you on that Wim - can i quote you on it? 

     

    Yes, it is open-source ;)

     

     

    Best regards,

     

    Wim Jongman, CTO

    +31(0)622371297

     

     

    remainsoftware-logo

    Embrace Change. Remain In Control.

     

    www.remainsoftware.com

    See our video to learn more about Remain.

     

           linekdin    

     






  • 11.  RE: IWS API Manager / Orchestrator?

    Posted Fri November 25, 2022 02:06 PM
    Hi,

    (1) If there are fields you do not want to expose, then create a program that has only the fields that are needed for the API. 

    (2)  Currently if you want to have a manager you can front-end the APIs with a manager like IBM API Connect[1].  The manager could also support token management.  Alternatively, you can inject in an IWS server Java code that you define that can interrogate and verify tokens generated by third-party libraries.   You do this via trust association interceptor[2].

    [1]  https://www.ibm.com/products/api-connect

    [2] https://www.ibm.com/support/pages/node/6396908

    ------------------------------
    Nadir K Amra
    ------------------------------