OE 12 PASOE Debugging

Posted by Darren Parr on 02-Aug-2019 17:55

Hi

I'm trying to debug a call into the DOH. Its failing to call something. I'd like more info so I can get some more information. All Ive managed to do so far is set debug-alert and call-stack to get some data. I know theres a way of getting the DOH to dump out some verbose text of whats going off.

I cant see how to to do this and would appreciate a pointer.

Thanks

Darren

2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr [OE.W.DO.DOH.STYLEmanService ERROR] Exception raised for GET oslld:17600/.../StyleMaster01 Entity=OSL.Service.Instances.StyleMaster01_3052; Operation=OpenEdge.Web.DataObject.MappedOperation_2857: GET /StyleMaster01: ;target: Class name:OSL.Service.Instances.StyleMaster01, type-of:OSL.Service.Instances.StyleMaster01, fn:ReadStyleMaster01, args(2): [abl-name:pcFilter data-type:CHARACTER io-mode:Input
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr has-schema:no arg-type:Ccs.Common.Support.ILongcharHolder is-array:no is-primitive:yes num-elem-in:1 num-elem-out:?],[abl-name:dsStyleMaster01 data-type:DATASET-handle io-mode:Output has-schema:yes arg-type:Ccs.Common.Support.IHandleHolder is-array:no is-primitive:yes num-elem-in:? num-elem-out:1], num-schemas:0, num-hdr:0, name:, num-cookies:0
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Log stack:
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleException OpenEdge.Web.DataObject.DataObjectHandler
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.DataObject.DataObjectHandler
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.DataObject.DataObjectHandler
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.InternalWebRouter
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Error(s) raised:
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Put/Get functions not allowed on uninitialised memory. (2914) (2914)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Error attempting to push run time parameters onto the stack. (984) (984)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Error stack:
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Write OpenEdge.Web.DataObject.Writer.StringValueWriter at line 63 (OpenEdge/Web/DataObject/Writer/StringValueWriter.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Write OpenEdge.Web.DataObject.Writer.StringValueWriter at line 86 (OpenEdge/Web/DataObject/Writer/StringValueWriter.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr GetInputValue OpenEdge.Web.DataObject.OperationHandler at line 1119 (OpenEdge/Web/DataObject/OperationHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr BuildArguments OpenEdge.Web.DataObject.OperationHandler at line 1307 (OpenEdge/Web/DataObject/OperationHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr Execute OpenEdge.Web.DataObject.ClassOperationHandler at line 1217 (OpenEdge/Web/DataObject/ClassOperationHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr PerformOperation OpenEdge.Web.DataObject.DataObjectHandler at line 618 (OpenEdge/Web/DataObject/DataObjectHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.DataObject.DataObjectHandler at line 451 (OpenEdge/Web/DataObject/DataObjectHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.DataObject.DataObjectHandler at line 354 (OpenEdge/Web/DataObject/DataObjectHandler.r)
2019-08-02T18:50:10.697+0100 034794 034815 1 AS-7 ROOT:w:00000010 LogMgrWrtr HandleRequest OpenEdge.Web.InternalWebRouter at line 113 (OpenEdge/Web/InternalWebRouter.r)

OpenEdge Development - Forum
Posted by Peter Judge on 05-Aug-2019 15:14

That's saying that we want to take the HTTP message body as pass it as the "filter" parameter. Typically, for READ operations, that msgElem would be
{
 "type": "QUERY",
  "name": "filter"
}
 
If this is generated form the ABL, then there's a bug in the generation code.
 
I assume that there's no messag body being sent on the GET request?
 
You could patch the GEN file with the above, but it'll be overwritten every time a new GEN file is generated. A better approach would be to add just that operation: service, uri, method to a <service>.map file that's in the same directory. That will override what's in the GEN.
 
 
 
 

All Replies

Posted by Peter Judge on 02-Aug-2019 19:12

What kind of verbose text are you after?
 
 

Posted by Darren Parr on 02-Aug-2019 22:45

I'd like to find out why its going wrong? The .gen file is  freshly generated from the BE and in the propath. The BE is using a static dataset. I "think" the DOH is building a structured dynamic dataset and calling the read method and they arent agreeing on the dataset. I don't know this as I cant see what its doing,

Any suggestions on what i should do?

-Darren

Posted by Darren Parr on 05-Aug-2019 13:01

I've been through the dataset field by field. They match to the field and index level. The same include file for the dataset has been used to build the .gen file and so Id expect this.

As it never gets into the read method, I'm assuming the run-time parameters error is the same one we get when passing a dataset as a parameter when the datasets differ.

Is the DOH buggy at the moment? If so do I need to write my own handlers?

Regards

Darren

Posted by Peter Judge on 05-Aug-2019 14:34

It's no buggier than usual :)

The run-time error is coming from code that's trying to convert the message body (as an input param) into a string. I'm guessing that that's empty and that's causing the error. There's no checking for an empty body so that's a bug. This is the stuff from That's the OperationHandler line 1119 and on.

Can you post the snippet from the gen file for this GET operation? If it's a JSDO READ then I wouldn't expect the input dataset .

Posted by Peter Judge on 05-Aug-2019 14:34

It's no buggier than usual :)

The run-time error is coming from code that's trying to convert the message body (as an input param) into a string. I'm guessing that that's empty and that's causing the error. There's no checking for an empty body so that's a bug. This is the stuff from That's the OperationHandler line 1119 and on.

Can you post the snippet from the gen file for this GET operation? If it's a JSDO READ then I wouldn't expect the input dataset .

Posted by Darren Parr on 05-Aug-2019 14:47

Thanks. That bad eh?

OK. Here's the snippet from the .gen.

"GET": {

               "contentType": "application\/json",

               "options": {"writeBI": true},

               "entity": {

                   "name": "OSL.Service.Instances.StyleMaster01",

                   "function": "ReadStyleMaster01",

                   "arg": [

                       {

                           "ablName": "pcFilter",

                           "ablType": "CHARACTER",

                           "ioMode": "INPUT",

                           "msgElem": {

                               "type": "BODY",

                               "name": null

                           }

                       },

                       {

                           "ablName": "dsStyleMaster01",

                           "ablType": "DATASET",

                           "ioMode": "OUTPUT",

                           "msgElem": {

                               "type": "BODY",

                               "name": null

                           }

                       }

                   ]

               }

           },

Posted by Peter Judge on 05-Aug-2019 15:14

That's saying that we want to take the HTTP message body as pass it as the "filter" parameter. Typically, for READ operations, that msgElem would be
{
 "type": "QUERY",
  "name": "filter"
}
 
If this is generated form the ABL, then there's a bug in the generation code.
 
I assume that there's no messag body being sent on the GET request?
 
You could patch the GEN file with the above, but it'll be overwritten every time a new GEN file is generated. A better approach would be to add just that operation: service, uri, method to a <service>.map file that's in the same directory. That will override what's in the GEN.
 
 
 
 

Posted by Darren Parr on 05-Aug-2019 15:51

The entire thing came from PDS via new BE and selecting crud and submit.

Here are my annotations. I added the JFP lines at the bottom.

   @openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="true").

   @progress.service.resourceMapping(type="REST", operation="read", URI="?filter=~{filter~}", alias="", mediaType="application/json").

   @openapi.openedge.method.property (name="mappingType", value="JFP").

   @openapi.openedge.method.property (name="capabilities", value="ablFilter,top,skip,id,orderBy").

Posted by Peter Judge on 05-Aug-2019 16:02

It looks like there are 2 bugs here
  1. The GEN file being wrongly generated. It should write it as I described earlier.
  2. The runtime failure: basically when we pass an empty memptr value into the StringValueWriter it barfs (the ValueWriters are used to convert values between various ABL types).
 
You should contact TS so that you can be associated with the bugs.
 
 
 

Posted by Darren Parr on 05-Aug-2019 16:47

OK. Ill raise them.

Thanks

Darren

This thread is closed