Dynamics in OE 12.0

My first thought is that you should have been working on phasing out Dynamics for a few years already.

The signs that it's dead-end technology that you want to move away from started to appear way back in OpenEdge 10.0A, when it did not even get updated to support the new datatypes. Followed by not being updated to use client-principal-based authentication (available since 10.1A if memory serves), it officially being deprecated in 10.2B (+/- 1 release) etc.

It's becoming less and less sustainable as time goes by, and that trend is NOT going to reverse. (What will you do when the 32-bit OpenEdge for Windows gets the axe ?)

That little rant aside:

1. Code changes to support the PASOE may turn out to be minimal. AFAIK the ADM2 code Dynamics is based on did get a few fixes to be deployable on a PASOE. If I'm correct there, and assuming your application was designed to run in stateless mode (which Dynamics was primarily targetted at), you should be able to get quite far by opening up the APSV transport on the PASOE and changing your AppServer partition definitions to use the PASOE's AppServer URL. You will still miss out on all the new security features etc. that the PASOE provides though.

2. Regarding going back to classic AppBuilder - better check if that's actually still available in OpenEdge 12. Also, keep in mind this KB article knowledgebase.progress.com/.../Will-it-be-possible-to-run-an-OpenEdge-Dynamics-application-to-OpenEdge-12-0 , and make sure to carry over the Dynamics code from an older release. AFAIK the Dynamics-specific tooling is also part of that set of code.

Otherwise you'll be stuck developing on an older release and deploying on a newer one. With all the complications that introduces during building & testing.

> On Apr 10, 2019, at 5:45 AM, frank.meulblok wrote:

>

> assuming your application was designed to run in stateless mode

with PASOE, in general, “stateful" applications should work quite well and with most of the advantages that stateless provides but without the extra work. this is because a single agent process can handle multiple concurrent 4GL sessions.

in some cases, stateful applications will run much better than stateless ones. that is because there is no need for the agent side to load and unload session state between requests.

True, but I was focusing on the amount of ABL code changes you need to make to migrate.

And implementing stateful sessions on a PASOE does require more code changes (because in a PASOE environment, you'll need to change your connection logic so the *client* can request the session to be stateful). And for ADM2 / Dynamics-based applications that does mean customizing the bit of framework code that handles your appserver connections.

We are using Dynamics with PASOE on 11.7, and are planning on going to 12.0.

There are code changes you need to make within Dynamics and/or ADM2. For instance there are a few references to SESSION:CLIENT-TYPE checking for a value of "APPSERVER" and you need to add "MULTI-SESSION-AGENT" to that (see documentation.progress.com/.../index.html )

There were also some changes we made to the client side to improve support for reconnecting to the appserver. We changed our client deployment strategy with pasoe. Instead of setting up VPN's to connect to the traditional appserver, we use https without a VPN. However this seems to make the connection a bit less reliable, so we were exposing this reconnection bug more often. It looks like it was always intended to be able to recover from transient network errors, but there's a problem in afasconmgr.p connectServiceWithParams. You can change "if not valid-handle(hServer)" to "if not valid-handle(hServer) or not hServer:connected()" and it works much better!

I also changed dynamics to use SESSION:CURRENT-REQUEST-INFO:ClientContextId instead of SESSION:SERVER-CONNECTION-ID as the basis of the session id (e.g. in afsesmngrp.i, but there are a number of other files as well). This is so that the session is preserved upon reconnect. But you also need to modify connectServiceWithParams to not recreate the server handle (which causes openedge to generate a new default ClientContextId) and disconnectService to not delete the server handle. An alternative which would probably be better would be to generate your own session id on the client as a guid, store it persistently (global or static class for instance) and then manually set the ClientContextId after the server handle is created.

All in all it's possible to do, and at this point we're seeing improved connection stability and performance over the traditional appserver.

We are using Dynamics with PASOE on 11.7, and are planning on going to 12.0.

I'm wondering how you will continue to develop Dynamics in 12.0 when Progress doens't provide the tools anymore?

You'll be stuck developing on an older release and deploying on a newer one. With all the complications that introduces during building & testing.

Or if you're willing to invest the time and monmey required, the source code for the dev tools is freely available (here: https://community.progress.com/community_groups/openedge_general/w/openedgegeneral/3279.ade-openedge-11-7-4-development-tools-source-code ), so you could port them over yourself.

Or you could work out a plan to phase out Dynamics.