Any Java OpenClient Changes in OE 12?

Posted by dbeavon on 15-Mar-2019 13:54

Does anyone have a list of enhancements to the Java openclient in 12? Is the openclient significantly different in the new version of OE? I looked in the "whats new" articles and couldn't find anything.

I'm curious about things like client-side APSV-sessions for session-free connections. In the past the client-side session pool would be invalidated after the HTTP APSV session(s) had reached the timeout that was specified on the server. And the client application wouldn't be able to recover auto-magically on its own (it would throw generic communication exceptions). The rumor is that Progress was going to handle this within management of the pool itself, or in the very least throw a more helpful exception.

Another rumor I'd heard is that the openclient would start allowing errors to be thrown from ABL and serialized/deserialized over to the openclient. In the past the only mechanism was to use the RETURN ERROR statement, which supports a single character string.

Another thing I'm looking for (on the .net side of things) is an APSV openclient that is able to be used on .Net core in addition to the .Net framework.

If anyone has specific news about the openclient in 12 would be appreciated (either java or .net).

Posted by Evan Bleicher on 15-Mar-2019 14:17

Information about this change can be found in the 12.0 documentation set.  The 'New in OpenEdge 12.0' page (docs.progress.com/.../ABL.html) notes this change and information about the new objects Laura references can be found on the 'Error and stop object enhancements for a Java open client'  page (docs.progress.com/.../Error-and-stop-object-enhancements-for-a-Java-open-client.html).

All Replies

Posted by Laura Stern on 15-Mar-2019 14:07

The rumors are true regarding throwing errors back to the Java Open Client.  You will still get the same error types you got before, though now there are a few new ones related to STOP conditions.  And now the real error message(s) and error number(s) will be sent back from any error object that is thrown out from the ABL.  So you no longer need to use RETURN ERROR.  Though if you throw a customized error object, custom properties will not be serialized back to the client.

I am not aware of any other Open Client changes.  If there are any, I don’t know about them.

Posted by Evan Bleicher on 15-Mar-2019 14:17

Information about this change can be found in the 12.0 documentation set.  The 'New in OpenEdge 12.0' page (docs.progress.com/.../ABL.html) notes this change and information about the new objects Laura references can be found on the 'Error and stop object enhancements for a Java open client'  page (docs.progress.com/.../Error-and-stop-object-enhancements-for-a-Java-open-client.html).

Posted by dbeavon on 15-Mar-2019 15:00

Thanks for the links Laura and Evan.  I did see the references to the Java openclient changes.  But I didn't see anything about any .Net openclient changes.  

One day I still hope to be able to use the APSV openclient from ".Net Core".  I suppose for now we could investigate switching over to SOAP or REST ... but it would be a substantial effort.  From what I had seen (using Telerik decompiler) the effort to allow the .Net openclient to run on .Net Core is extremely minimal (ie. just remove some references to OLE DB exceptions).  Maybe Progress should put the .Net openclient on github so we can do this ourselves?

Whats new in OE 12 (lots of good stuff:)

docs.progress.com/.../New-in-OpenEdge-Release-12.0.html

I was interested to see the OEM/OEE is being moved out of admin server framework.  It confirms that, while possible, there are probably not many folks who want to use PASOE without an admin console.  We've always been told that you could install it independently of adminserver for production deployments.  But it seemed very impractical considering that you lose the GUI console and, without it, most Windows administrators would feel like they are operating in the dark.  GUI's are fairly popular nowadays. ;)

Posted by gus bjorklund on 16-Mar-2019 15:06

> On Mar 15, 2019, at 11:01 AM, dbeavon wrote:

>

> without it, most Windows administrators would feel like they are operating in the dark. GUI's are fairly popular nowadays

true enough. but such interfaces are also quite tedious and inefficient for performing repetitive tasks or tasks that require a lot of data entry. for example setting up new tenants and users for a multi-tenant database or for adding more than one new user to an existing database, setting up a new database structure in preparation for a data load, and many other tasks.

scripting is absolutely essential for almost all database administration tasks.

This thread is closed