Calling external REST service from Natural Software AG

, ,
1

We have new requirement that we need to invoke an external REST endpoint from mainframe Natural program. Webmethod integration server is not available in our environment. We have many existing Natural online transactions which invoke wsdl endpoints using SOAP XML protocol. The problem with REST API is that it accepts only JSON string as input . I am not quite sure that REQUEST DOCUMENT to REST endpoint will work or not. I passed JSON statements , but it came back with several errors.I referred many blogs and articles , all are referring to web method integration server. We are using other SOA product which can convert SOAP to JSON and invoke REST API for us, but the overall effort would have been greatly reduced if mainframe could directly invoke REST end points without contacting any middle ware tool.

2

Can you please be a bit more specific about the “several errors” you receive ?

1 Like
3

I have passed JSON parameters via REQUEST DOCUMENT from Natural for Windows, so I am confident that it will work from the mainframe.

4

I can testify REST calls work well directly from Natural (and via Mainframe with XML=ON), with JSON and Query parms no problems, perhaps provide an example of what is happening and we can all take a look.

1 Like
5

Thanks every one for clarifying it .I have never done this before and some how got misunderstood that webmethod integrator is mandatory for rest invocation.The error code is 8304 .Error in transport layer.It is actually invoking https endpoint and not sure whether it has anything to do with certificates.I have raised that an issue and once that is resolved I need to try again.I will post the code snippet tomorrow

6

Hello Sreesh,
would you pls. be so kind as to send me an e-mail to juergen.lind (at) softwareag.com?
The way recommended by Adabas&Natural for REST-enablement is via EntireX.
I’d like to send oyu some info on that way.
Cheers,
Juergen

  • A&N Product Management -
7

It took some time to resolve the HTTPS issues . We have added the certificates and I am able to get the JSON response back. The next big challenge for me is to parse the big JSON response string . Is there any in-built parser available for JSON ?. We have PARSE XML , but I could not find anything with respect to it in SYSTXT or github. I wonder why we don’t have it yet .We have work around like invoking another service and get it parsed, but it would have been really nice if something is already available in natural itself. I am trying to write parser in natural, but it less likely that any one will accept as solution due to strict project deadline.

8

Scan your FNAT libraries for “PARSE” and you will see many references in libraries SYSEXINS, SYSEXV, and SYSXTK.

Here is the basic structure of a function retrieving a postal address.

REQUEST DOCUMENT
   FROM #URL
   WITH USER 'user' PASSWORD 'password'
        HEADER NAME 'Request-Method' VALUE 'GET'
 RETURN PAGE     #RESPONSE
        RESPONSE #RC
                                          /* <-- inspect #RC
PARSE XML #RESPONSE INTO PATH #PATH VALUE #VALUE
                                          /* <-- inspect return code/message
    DECIDE ON FIRST VALUE OF #PATH
      VALUE 'address/contact/$'
            ASSIGN #REPLY.#CONTACT = #VALUE
      VALUE 'address/line1/$'
            ASSIGN #REPLY.#ADDR1   = #VALUE
      VALUE 'address/line2/$'
            ASSIGN #REPLY.#ADDR2   = #VALUE
      VALUE 'address/line3/$'
            ASSIGN #REPLY.#ADDR3   = #VALUE
      VALUE 'address/city/$'
            ASSIGN #REPLY.#CITY    = #VALUE
      VALUE 'address/state/$'
            ASSIGN #REPLY.#STATE   = #VALUE
      VALUE 'address/zip5/$'
            ASSIGN #REPLY.#ZIP5    = #VALUE
      VALUE 'address/zip4/$'
            ASSIGN #REPLY.#ZIP4    = #VALUE
      NONE  VALUE
            IGNORE
    END-DECIDE
END-PARSE
IF  #REPLY.#ERROR
  THEN
    ASSIGN view.RETURN-CD   = #REPLY.#ERR-CD
    ASSIGN view.RETURN-MSG  = #REPLY.#ERR-MSG
  ELSE
    ASSIGN view.CONTACT    = #REPLY.#CONTACT
    ASSIGN view.ADDR-1     = #REPLY.#ADDR1
    ASSIGN view.ADDR-2     = #REPLY.#ADDR2
    ASSIGN view.ADDR-3     = #REPLY.#ADDR3
    ASSIGN view.ADDR-CITY  = #REPLY.#CITY
    ASSIGN view.ADDR-STATE = #REPLY.#STATE
    ASSIGN view.ADDR-ZIP5  = #REPLY.#ZIP5
    ASSIGN view.ADDR-ZIP4  = #REPLY.#ZIP4
END-IF
. . .
9

@Ralph_Zbrog - I think he’s looking for a JSON parser, which the PARSE XML statement is not. I’m not aware of support for JSON with the REQUEST DOCUMENT statement. You may want to enter a Brainstorm (change/enhancement) request, but it isn’t likely to help you with the current project, nor, due to the EntireX support for REST via wmIS, is it likely to be made available (my opinion only, not official Software AG statement).

Using EntireX with REST support is available to all EntireX customers now and is likely to be the quickest way for you to solve your problem.

10

This was for one of my clients who asked for JSON support. I was a bit surprised that it worked.

The biggest coding change was in the formatting of the request:

ASSIGN #TEMP.#CONTACT = view.CONTACT
ASSIGN #TEMP.#ADDR1   = view.ADDR-1
ASSIGN #TEMP.#ADDR2   = view.ADDR-2
ASSIGN #TEMP.#ADDR3   = view.ADDR-3
ASSIGN #TEMP.#CITY    = view.ADDR-CITY
ASSIGN #TEMP.#STATE   = view.ADDR-STATE
ASSIGN #TEMP.#ZIP     = view.ADDR-ZIP
EXAMINE #TEMP.#CONTACT FOR ' ' REPLACE '+'
EXAMINE #TEMP.#ADDR1   FOR ' ' REPLACE '+'
EXAMINE #TEMP.#ADDR2   FOR ' ' REPLACE '+'
EXAMINE #TEMP.#ADDR3   FOR ' ' REPLACE '+'
EXAMINE #TEMP.#CITY    FOR ' ' REPLACE '+'
EXAMINE #TEMP.#STATE   FOR ' ' REPLACE '+'
*
COMPRESS '?' -
         '&contact=' #TEMP.#CONTACT
         '&line1='   #TEMP.#ADDR1
         '&line2='   #TEMP.#ADDR2
         '&line3='   #TEMP.#ADDR3
         '&city='    #TEMP.#CITY
         '&state='   #TEMP.#STATE
         '&zip5='    #TEMP.#ZIP5
         '&zip4='    #TEMP.#ZIP4
    INTO #REQUEST LEAVING NO SPACE