When switching to the Webspeed webhandler Data object, we noticed that datasets are now written as Base64 in the response of an Invoke operation (Normal read operations are not affected). When using the same business entity in a REST RPC Data object service the dataset is written as normal JSON.
Below an example of the respsonse body:
Anyone knows if this is by design or that this concerns a bug?
Openedge 11.6, Service pack 3
The issue that you mentioned seems to be bug report PSC00352502.
This issue has been fixed in 11.7.
I would suggest to contact Technical Support should you need a hotfix for 11.6.3.
Are you using the JSDO on the client?
A possible workaround could be to add code to the handling of invoke operations in the JSDO to call decode the parameter on certain conditions.
I hope this helps.
Thank you and regards.
There's another workaround you can add on the server. The DataObjectHandler (DOH) has callbacks that let you manipulate the response before it's sent back to the caller.
In this you can base64-decode the dataset data.
I'm attaching (I hope) 2 programs.
1) DOHEventHandler.cls . This contains the callback and some sample code that turns the base64-encoded string into a real dataset. It has no error handling and dumps a before and after file - you should probably clean this stuff up if you want to use it in any serious form.
2) session_start.p : this starts the event handler in the sessions You should use this code for your session startups (configured in openedge.properties)
or if you already have a startup proc, simply call
in your code.
When switching to the Webspeed webhandler Data object, we noticed that datasets are now written as Base64 in the response. When using the same business entity in a REST RPC Data object service the dataset is written as normal JSON.
You received this notification because you subscribed to the forum. To stop receiving updates from only this thread,
post as spam/abuse.
Architect of the SmartComponent Library and WinKit
The Openedge version is 11.6, Service pack 3
I should be able to decode the Base64 string in the method handling the response, but that would be an unwanted workaround.
I was not able to find anything about that bug report number, but good to know it is fixed, and i will reference that when contacting support for a Hotfix.
We are indeed using the JSDO on the client. decoding the property should be doable as a temporary workaround.
Fred van Leeuwen
Thanks for the information and examples Peter,
Good to know about these callbacks.