Dynamics in OE 12.0 - Forum - OpenEdge Development - Progress Community
 Forum

Dynamics in OE 12.0

This question is not answered

Hi,

I'm wondering if there's anyone out there working with Progress Dynamics and planning to go to OE 12.0.
We'll be facing some serious challenges if we ever decide to upgrade to OE 12:
- We'll have to find some way of migrating classic AppServer to PASOE seeing classic AppServer will be deprecated. Note that Dynamics is tightly integrated with the classic AppServer.
- This means we'll need to custom coding in the Dynamics framework to get this working again
- Even though the availability guide for 12.0 lists a 32-bit version Progress Developer Studio, this is incorrect and only a 64-bit version will be provided (Confirmed to us by Progress). This means we'll need to go back to classic 32-bit AppBuilder as Dynamics is dependent on 32-bit OCX elements (For me, this feels like going back to the stone-age as we've just started to use OOABL).

(On top of that we'll also need to move from HP-UX to linux as HP-UX will be deprecated.)

Please share any thoughs.

Regards,

Steven

All Replies
  • 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.

  • Some of the Dynamics managers have been changed to add checks for the SESSION:CLIENT-TYPE. The bootstrap mechanism (afxmlcfgp.p) considers the  MS agent an Appserver (not a webspeed-server).
     
    The rest of the places that the Dynamics code checks the SESSION:CLIENT-TYPE largely use is to determine whether we’re running on a server (below) , and this will continue to work just fine
    IF NOT (SESSION:REMOTE OR SESSION:CLIENT-TYPE = "WEBSPEED":U)
     
     
    One thing to note is that if you want to use PASOE for the Dynamics AppServer and the Dynamics WebSpeed replacement, you’ll have to do some (more) work
    1. Set up 2 ABL applications in the instance. This is because Dynamics specifies the type of session via the -icfparam switch (read-only in the session), and the agent command-line (parameters) is done per ABL application.
    2. If there’s code that checks for CLIENT-TYPE = WEBSPEED only, it’ll have to change to CLIENT-TYPE= MULTI-SESSION-AGENT AND SESSION:CURRENT-REQUEST-INFO:ADAPTER-TYPE EQ Progress.ApplicationServer.AdapterTypes:WEB
     
     
    The work to use a client-principal for authentication has not been done so you’d have to change that yourself.
     
    Hth,
    --peter
     
     
  • 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.