REST methods returning LONGCHAR results in error

Posted by Neil Treeby on 19-Aug-2019 19:39

Using 11.7.5, PDSOE, local "classic" restbroker1 AppServer, built-in Tomcat, built-in restmgr1 OE Web Server on the default port.  The only thing not "local" is the db restbroker1 connects to, though I'm sure that's not relevant here.

Maybe I'm doing something wrong, or there's some documentation explaining this behavior.  I've not come across anything about this on the KB or elsewhere in the community.

If I map a method like this to a URI:

/* ping.cls */

CLASS ping:

    METHOD PUBLIC CHARACTER doPing():

        DEFINE VARIABLE vcRetVal AS CHARACTER NO-UNDO.

        ASSIGN vcRetVal = "okay".

        RETURN vcRetVal.

    END METHOD.

END CLASS.

... I get the expected response:

{"response":{"_retVal":"okay"}}

However if all I do is change the return type of the 'doPing()' method from CHARACTER to LONGCHAR (with a corresponding change of the data type of the vcRetVal variable), I get an error:

com.progress.open4gl.Open4GLException: Invalid data type specified for return type. (12473)

I can't even find a log file where this error is occurring - it's not in either of the restbroker1 log files (broker or server). I assume that's because it's coming from some adapter log file.

Any insights? I'd prefer to use LONGCHAR where possible. CHARACTER is fine for test / R&D purposes but I can't rule out real live code returning much larger data sets (and, as I discovered, I can't directly map a Progress.Json.ObjectModel.JsonObject data type as a return value - have to do a Write() to a CHARACTER or LONGCHAR).

All Replies

Posted by Peter Judge on 20-Aug-2019 01:20

To answer directly, I don't know whether LONGCHAR types are supported, although the doc at docs.progress.com/.../Mapping-REST-resource-verb-parameters.html is vague enough to indicate that they might be. It's worth a call to TS to get either the behaviour (or the doc) fixed.
 
I do know that only primitive types and temp-tables/dataset are supported for the rest transport.
 
I *think* that that error is coming from the rest adapter (the tomcat webapp) rahter than the AppServer.
 
Is there any reason you don't want to use PASOE and the web transport?
 
 

Posted by Neil Treeby on 20-Aug-2019 12:38

I'm not using PASOE because we don't have PASOE licenses right now (apart from the "local" PASOE that comes with PDSOE).  Due to issues with a 3rd-party application that aren't scheduled to be resolved until mid-2020 at the earliest (the application is being completely re-engineered as an in-house replacement, but that's not an overnight job), we're stuck with "classic" AppServer for the time being.

The error is clearly coming from the Java Open Client libraries so I think you are correct it's coming from Tomcat, somewhere.

This issue appears to be restricted to the return values from methods.

The following are both okay:

/* ping.p */

DEFINE OUTPUT PARAMETER pcReturn AS LONGCHAR NO-UNDO.

ASSIGN pcReturn = "okay".

/* ping-lib.p */

PROCEDURE ping:

   DEFINE OUTPUT PARAMETER pcReturn AS LONGCHAR NO-UNDO.

   ASSIGN pcReturn = "okay".

END PROCEDURE.

This thread is closed