REST - update parameter mapping?

Hi,

Remapping the verb to the procedure clears out all the existing mappings. It is the expected behavior of Rest expose editor.

To use an ABL class and procedure files in a REST service, you require the REST interface annotations to be defined in the ABL procedure or class file, and then generate a .pidl file. The .pidl file is required for the ABL class and procedure file to communicate with the REST process.

When you associate a REST resource verb with a REST interface annotated ABL procedure (.p) or class (.cls) file in the Associate Operation with Verb dialog, the REST invocation (.pidl) file of the selected ABL class or procedure file is automatically created.

If you check, ‘Generate REST invocation files’, it automatically generate REST .pidl files whenever a build occurs for the project. The generated REST invocation (.pidl) files are located under the .services node in your REST project. The generated .pidl file has the same name as that of the ABL procedure or class file name. If the location is specified in the File Destinations properties page, .pidl files generated are stored in the location specified.

For the error/warning you mentioned, there might be some problem with the procedure file(s) you used in mappings. Please share the procedure file(s) with us to find out what is causing the issue.

Thanks,

Rama.

Hi Rama,

If remapping clears out the existing mapping as expected - what is the expected procedure to update a mapping?

I have been able to deploy the war and execute the rest services fine - it wasn't until I looked for a more efficient way to update the mapping that I enabled the 'generate REST invocation files'. What is creating the pidl files if it is not the build?

The errors in the log confuse me somewhat:

[23-09-2014 12:39:49] /rest/AppServer/debtor.p (C:\workspace\oe11.4\7.11\rest\AppServer\debtor.r)

>debtor (Cannot access .r code for dataset: C:\Progress\wrk\oe11.4\debtor.r)

>debtor (cannot access .r code for dataset pi_dscontext)

>debtor (No field information will be generated in C:/workspace/oe11.4/7.11/rest/.services/AppServer\debtor.pidl)

The file is being compiled to my project directory c:\workspace\oe11.4\7.11\rest - but the cannot access messages are attempting to grab the r-code from the progress working directory (c:\progress\wrk\oe11.4) - is this correct?

Thanks,

Stefan

Hi Stefan,

Please see my comments inline.

If remapping clears out the existing mapping as expected - what is the expected procedure to update a mapping?

[Rama]: You need to recreate the mappings from the scratch. This is how it is designed.

Whenever you associate a ABL procedure/class file with a verb, corresponding '.pidl' file will be generated. This '.pdl' file contains the information about  the mappings and the details of Input/output/Input-output parameters. You can update mappings by dragging and dropping the mappings between the parameters in Input and out put tabs.

If the ABL procedure/class is updated with some other parameters, whenever you de associate and re associate the file with same verb, the '.pidl' will get regenerated freshly. This won't preserve the old mappings data. So all the mappings will disappear.

I have been able to deploy the war and execute the rest services fine - it wasn't until I looked for a more efficient way to update the mapping that I enabled the 'generate REST invocation files'. What is creating the pidl files if it is not the build?

[Rama]: Even though if you do not build the project, reassociation of verbs with procedure/class files creates the .pidl files each time.

The errors in the log confuse me somewhat:

[Rama]: We are not sure about these errors. Please share the project with us.

Thanks,

Rama.

Hi Rama,

Thanks for the explanation, clearing the mapping when updating is a bit drastic and user unfriendly, but I can live with it.

I have pinpointed what is triggering the incoherent error message:

@openapi.openedge.export FILE(type="REST", executionMode="single-run", useReturnValue="false", writeDataSetBeforeImage="false").

DEFINE TEMP-TABLE tt NO-UNDO RCODE-INFORMATION
   FIELD adm_nr   AS INTEGER
   FIELD debtor   AS INT64
   FIELD name     AS CHARACTER
   INDEX ttix IS PRIMARY UNIQUE adm_nr debtor
   .

DEFINE TEMP-TABLE ott LIKE tt.

&IF TRUE &THEN
   DEFINE DATASET debtors FOR ott.  /* fails with ott, succeeds with tt - simply adding preprocessing influences this... */
&ENDIF

@openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="false").
PROCEDURE findDebtor:
   DEFINE INPUT         PARAMETER i_iadm_nr     AS INTEGER     NO-UNDO.
   DEFINE INPUT         PARAMETER i_i64debtor   AS INT64       NO-UNDO.
   DEFINE       OUTPUT  PARAMETER DATASET FOR debtors.

END PROCEDURE.

If I add code that is not code it also works - this disturbs me deeply:

@openapi.openedge.export FILE(type="REST", executionMode="single-run", useReturnValue="false", writeDataSetBeforeImage="false").

DEFINE TEMP-TABLE tt NO-UNDO RCODE-INFORMATION
   FIELD adm_nr   AS INTEGER
   FIELD debtor   AS INT64
   FIELD name     AS CHARACTER
   INDEX ttix IS PRIMARY UNIQUE adm_nr debtor
   .

DEFINE TEMP-TABLE ott LIKE tt.

&IF TRUE &THEN
   DEFINE DATASET debtors FOR ott.  
&ENDIF
&IF FALSE &THEN
   DEFINE DATASET debtors FOR tt.  /* adding this non code change the behavior!!! */
&ENDIF

@openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="false").
PROCEDURE findDebtor:
   DEFINE INPUT         PARAMETER i_iadm_nr     AS INTEGER     NO-UNDO.
   DEFINE INPUT         PARAMETER i_i64debtor   AS INT64       NO-UNDO.
   DEFINE       OUTPUT  PARAMETER DATASET FOR debtors.

END PROCEDURE.