How to remove temp-table name from REST service response

How to remove the object representing a temp-table of a ProDataSet from the JSON response generated by an OpenEdge REST service, leaving only the JSON array representing the temp-table records.

How to return a ProDataSet consisting of one temp-table in a REST response without including a level for the temp-table name

In an example based on the Sports2000 sample database, the output from the service is required to look like the following:
 

However, the default response generated by the REST adapter looks like:
 

OpenEdge REST services are designed to be consumable by any REST client. Some client applications may have specific requirements for the response format that they are expecting. The required format may not be the same as the default format used by the REST adapter to represent ProDataSets and temp-tables as JSON when they are serialized as procedure or method parameters.

In the example used in this article:

• A Business Entity class BeCustomer is generated in Progress Developer Studio for OpenEdge and mapped to a REST service in the REST Resource URI Editor.
• The Business Entity class is generated for a ProDataSet named dsCustomer. dsCustomer contains one temp-table, ttCustomer, which is filled from the Sports2000 Customer table.
• BeCustomer is generated with the default CRUD methods and exposed as a Data Object service.
• The default Read method is named ReadBeCustomer and returns the dsCustomer dataset as an output parameter

Instead of associating the ReadBeCustomer method generated for the Business Entity by PDS to the GET verb and mapping the output dataset parameter to the response, add a wrapper method to the BeCustomer class that defines an OUTPUT parameter as LONGCHAR. Code the method to do the following:

• Invoke the default ReadBeCustomer method
• Use the Progress.Json classes to:
  • Read the records returned in the ttCustomer temp-table into a Progress.Json.JsonArray object
  • Serialize the JsonArray object to a LONGCHAR variable. This variable will contain only the JSON array representing the temp-table records; the array will not be contained in an outer JSON object representing the temp-table itself.
• Store any other output that will be needed in the final response in separate CHARACTER or LONGCHAR variables.
• Concatenate the LONGCHAR containing the temp-table records with the other output in the desired format. Assign this result to the LONGCHAR OUTPUT parameter.

In the sample project, the wrapper method looks like this:

/*------------------------------------------------------------------------------
            Purpose:  Get one or more records, based on a filter string                                                                     
            Notes: Wrapper for ReadBiContact. Modifies JSON payload to remove name
                from temp-table array and adds additional output.                                                                        
    ------------------------------------------------------------------------------*/
    @openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="false").
    @progress.service.resourceMapping(type="REST", operation="read", URI="?filter=~{filter~}", alias="", mediaType="application/json"). 
    METHOD PUBLIC VOID ReadBeCustomerWrapper(
        INPUT filter AS CHARACTER, 
        OUTPUT lcOutput AS LONGCHAR):

        DEFINE VARIABLE httCustomer          AS HANDLE    NO-UNDO.            
        DEFINE VARIABLE oCustomerArray       AS JsonArray NO-UNDO.
        DEFINE VARIABLE lcttCustomer         AS LONGCHAR  NO-UNDO.
        DEFINE VARIABLE cOtherResponseValues AS CHARACTER NO-UNDO.
        
        /* Invoke the standard Read method of this BusinessEntity */
        ReadBeCustomer(INPUT filter, OUTPUT DATASET dsCustomer).
        
        /* Get the handle to the temp-table of the dataset returned by the Read method */
        httCustomer = DATASET dsCustomer:GET-BUFFER-HANDLE('ttCustomer'):TABLE-HANDLE.
        
        /* Create a new JSON array object and fill it with objects representing the temp-table records */
        oCustomerArray = NEW JsonArray().
        oCustomerArray:Read(httCustomer).
        
        /* Serialize the JSON array object to a LONGCHAR */
        oCustomerArray:Write(INPUT-OUTPUT lcttCustomer).
        
        /* If there are any values other than the temp-table records that must be returned in the same
            REST response, add them to the LONGCHAR output parameter in the desired format and order.
            This example includes two simple string values in addition to the temp-table array. They
            will be placed before the temp-table array in the response.
            */
        cOtherResponseValues = '"region":"all","tier":"all"'.
        
        /* Concatenate all parts of the response in a single LONGCHAR output parameter. Escape braces
            (curly brackets) with a tilde. Map this parameter to the response body
            (*not* a body parameter) in the REST Resource URI Editor. */
        lcOutput = '~{' + cOtherResponseValues + ',"data":' + lcttCustomer + '~}'.
        
        RETURN.
              
    END METHOD.

In the REST Resource URI Editor, associate the GET verb with the wrapper method. Map the output parameter to the response body (not to a body parameter):



Mapping all output directly to the response body avoids extra layers added by the REST adapter to distinguish separate parameters in the JSON payload. This is why the wrapper method concatenates all output into a single LONGCHAR parameter containing all output in the desired JSON format. Only one interface parameter can be mapped directly to the response body; multiple interface parameters must be mapped as separate body parameters.

A complete example project is attached. The project was developed in OpenEdge 11.6 using the sample Progress Application Server oepas1 to expose the REST service. Both the project and oepas1 must be connected to a Sports2000 sample database. To adapt this example in other OpenEdge versions, or to a classic AppServer and OE Web Server, create a new project in the desired OpenEdge configuration and copy the dsCustomer.i and BeCustomer.cls files into the AppServer directory of the project.

OpenEdge REST services are available beginning with OpenEdge 11.2.

Progress Application Server for OpenEdge is available beginning with OpenEdge 11.5. Early versions were called Pacific Application Server for OpenEdge.

References to Other Documentation:

OpenEdge Development: ABL Reference

Progress Developer Studio for OpenEdge Online Help, Chapter 5, "Introducing OpenEdge REST"

Progress Articles:

 How to generate JSON data without a root node in ABL?
 REST mapping in PDSOE and its effects on the JSON payloads for Dataset-Handle