Moving your classic AppServer applications to the Progress® Application Server for OpenEdge®

Moving your existing applications to the Progress
Application Server for OpenEdge is easy. It just takes a little planning and organization.
In this video we’ll • Introduce you to your new application
server • Review a sample application to move
• Then move the application Let’s start by learning a little more about
your new server. PAS for OpenEdge is a unified web server (animate an outline for the full
server) which no longer requires special adapters for each client type. (animate an outline
around the client types.) All client types send requests to your ABL server code using
one of four transports shown here. (animate pulse of the four transports inside the box.) The Session Manager (animate the session manager)
then distributes those client requests to the underlying Multi-Session Agents (animate
the Multi Session Agent) to ensure efficient use of your server resources. Built on Apache
Tomcat web server technology (animate the Apache logo) and enhanced by OpenEdge development
to manage the specific needs of your OpenEdge clients, you get the best of both worlds.
Apache updates ensure compliance with industry standards, like Spring security, while OpenEdge
development ensures we can handle all client types in a single server with no additional
products using easy to configure properties files.
We will use a very simple sample. An ABL client (animate) will connect to the new server (animate).
The server instance will already be connected to a database (animate) at startup. The server
code will then return a customer record to the client. So now that we know what we are going to move.
We will need to complete the following steps and tasks.
OpenEdge offers development and production licenses for PAS for OpenEdge. For staging
a production configuration, install the production license which implements stronger security
and limits external management of your server instances. This screen capture shows the product
installed for this video. The pasman create command creates an instance.
This instance acts as the staging area for deploying your existing applications before
you move to a live environment. In Unix, after running proenv to set our environment
variable, we begin in our work directory. Using the pasman command with the create action
we create an instance. The dash v is the verbose option to provide feedback as the instance
is created. Dash lowercase p is the TCP port that listens for HTTP message. Dash uppercase
P is the TCP port that listens for HTTPS message. Dash m is the usernaame and password combination
to replace the default tomcat:tomcat used by Apache Tomcat. You’ll want to pick something
unique for your system. Dash uppercase Z prod is used to create a production instance. This
locks down the server with production server security settings. The final option is the
instance_pathname. It is an absolute path to the directory where instance gets created.
If no path is specified, it is created in the current directory. The example uses myProdInstance.
As the command executes, the verbose option provides insight into the create process (pause
for messages) Create is copying files, tailoring files and using the production security model
which disables server status pages and the four transports shown earlier. Later we’ll
enable the APSV transport to allow ABL client access for the sample.
Notice that a new directory was created for the instance. Before going to the next step,
it is a good habit to test the instance with pasman test to check for things like port
conflicts. This is an example with no conflicts.
Now we are ready to convert an existing to the new format used
by the new server. This is a three step process. The first step is to convert the existing
properties to temporary merge file using this script. The paspropconv utility uses the following
options. • The path to existing classic AppServer file. • The fully qualified name of the broker
whose properties you are converting • The name of the new instance.
This generates a merge file of converted values for you to review and customize before merging
them into your file. Using more to skim through this file, you
can see the kind of information that it provides. There are a lot of comment about different
changes that are going to be made for this server. You’ll want to review this file
in its entirety but for this video we are going to look just at the settings of interest.
Confirm or update your PROPATH entries, adding any additional or shared code locations. In
this file the application code is in an appserver subdirectory.
If you used event procedures, like these. Confirm or update your PROPATH entries, adding
any additional or shared code locations. If your existing application used parameter
files to connect to a database or initialize other values, confirm that those files are
available to the new server. One last property of note is this one that
enables access to use the APSV transport for your ABL clients to connect.
Apply your changes, using pasman oeprop to merge the converted properties into the
file for your new server. Copy the ubrokerName_setenv[.sh|bat] file
to instancePath/bin. This script is run when the instance is started to set environment
variables. Earlier we used the PROPATH to locate the
server code. In your environment we recommend you consider the following locations for your
code. For application code, move compiled code to
instancePath/webapps/ROOT/WEB-INF/openedge For common code used by multiple applications,
move compiled code to instancePath/openedge Moving existing code to these recommended
locations promotes security, scalability, extensibility, and easier deployment.
Next we test the server access to the database server. We’ll start the database server,
if it isn’t already running and we’ll check the .pf file used by our instance to
make sure that we will connect the instance at startup.
In this step, restart the server to confirm that the startup procedures were available
and the .pf file connections are working. Enter the following command to start the server.
If the server were currently running it would stop and restart the server. Since this is
the first time we’ve started this server the startup takes a little longer. When it
completes make sure there are no errors. If you encounter errors here are a few troubleshooting
tips. These are very standard. Check the log files and recheck the changes for typos.
Now we are ready to connect our ABL client A classic AppServer connection looks like
this. Obviously, machinename would be replaced with your server name. For a PAS for OpenEdge client the connect
options look like this. Notice this format looks more like a URL because you are connecting
to a web server using the new APSV transport. When we run the code. The client connect to
the server and the server returns the requested customer.
If you are done testing your server and it is no longer needed, it is good practice to
stop the instance. This completes our look at Moving your classic
AppServer Applications to the Progress Application Server for OpenEdge. To learn more about this
topic, see the links provided in the video description.

1 thought on “Moving your classic AppServer applications to the Progress® Application Server for OpenEdge®

  1. Just looked at the technical demo's. And wow. That was impressive. I worked with Progress back in the days with version 6 until version 9. Latest job at Progress NL as a consultant. After that, I switched jobs and are now a systemadministrator at an integration company in the netherlands. Mostly working with Java engineers.

    I know this is, nowadays, an old vid, but it itches again. Always loved the 4GL, now ABL, for its speed.

Leave a Reply

Your email address will not be published. Required fields are marked *