Try OpenEdge Now
skip to main content
Application Migration and Development Guide
Migrating AppServer and WebSpeed Applications : ABL application code migration : ABL application structure
 

ABL application structure

With the classic OpenEdge AppServer, the definition of an ABL application is a very abstract notion with no physical attributes other than an installed OpenEdge AppServer product, an AppServer instance that is declared and configured, some .p and/or .r files, and, optionally, one or more adapters. Progress did not advise or recommend where or how an ABL application was packaged, where its files were installed or written, how to prepare it to be scaled, or how to organize it for extensibility.
PAS for OpenEdge is like a classic OpenEdge AppServer with respect to requiring an installation of a PAS for OpenEdge product, declaring and configuring an instance, and supplying some .p and/or .r files. That is where the similarities end. A PAS for OpenEdge instance and the ABL application it hosts have a defined structure with specific locations for different components.
The structure of a PAS for OpenEdge instance (which is identified by an alias name and its OS file system path) includes the following directories:
*bin — A directory that contains OpenEdge and customer-written utilities and libraries that are tailored to that specific instance. For example, OpenEdge utilities are tailored to use the local instance's file space but load and use core (in other words, home) shared libraries and utilities.
*common/lib — A directory that contains java libraries and files that are shared across all of the instance's Web applications (Note: the core server also has a common/lib directory that holds java libraries and files shared by all Web applications across all instances).
*conf — A directory that contains the instance's Tomcat, OpenEdge, and customer-written configuration files that control only the applications deployed into the instance
*logs — A directory that contains the log files for the server instance, including all of the server, Web application, OpenEdge, and ABL application log files.
*work — A directory that contains Web application (in other words, ABL application) generated persistent working files. Note that these files should not be deleted by an administrator as part of cleaning up before doing an application restart.
*temp — A directory that contains Web application (in other words, ABL application) generated temporary files. These files can be deleted by an administrator as part of cleaning up before restarting the server instance.
*webapps | webapps-ref — A directory, or a reference to a directory, that contains the instance's Tomcat, OpenEdge, and customer ABL Web applications
*openedge — A directory that contains .p and/or .r files and supporting files only for ABL applications. Other Progress and/or third party Web applications cannot write or read from this directory.
As an example of a Web application, notice that OpenEdge ABL Web application (oeabl.war) is structured as follows:
*/apsv — A URI path reserved for OpenEdge client connections (can be disabled)
*/soap — A URI path reserved for OpenEdge soap client connections (can be disabled)
*/rest — A URI path reserved for OpenEdge REST clients (can be disabled)
*static — A directory that contains static files, including images, style sheets, and HTML pages.
*META-INF — A required directory containing meta data and context.xml definitions specific to the Web application. OpenEdge uses a tailored context.xml file for the Web application, and can be tailored by the deployment site to meet security requirements
*WEB-INF — A required directory holding the Web application's configuration file (web.xml), Spring Security configuration files, and other application private files
*adapters — OpenEdge directory tree holding REST and SOAP deployment files
*lib — Required directory that holds any Java libraries specific to the Web application
*classes — Required directory that holds any Java classes or data files specific to the Web application
*openedge — Directory provided by OpenEdge where an ABL developer can distribute their ABL application's files that apply specifically to the Web application
As you can see, there are specific places where OpenEdge recommends an ABL application developers to locate their files. While an ABL application can physically locate their files anywhere in the OS's file system, locating them inside of the PAS for OpenEdge Web application instances promotes scaling, extensibility, and deployment. To promote scalability, extensibility, and deployment a PAS for OpenEdge ABL Web application should contain the following components:
*An ABL application (identified by name) that may be deployed into an existing PAS for OpenEdge instance.
*Common .r and/or .p files used across multiple web applications located in an instance's openedge/* directories. The directory structure should be capable of being configured read-only for a secure installation.
*One or more Web applications like oeabl.war that may be deployed to an existing PAS for OpenEdge instance. They are used to host APSV, SOAP, and REST transport access to ABL business logic.
For each Web application, include:
*(Optional) The .r and/or .p files specific to the application. They should be located in a Web application's WEB-INF/openedge directories. The directory structure should be capable of being configured read-only in a secure installation
*Static pages used by the Web application. They should be located from the root URI (/) , but not from one of the reserved OpenEdge URIs.
*Configuration files for the Web application, including the application specific web.xml files and oeablSecurity*.xml files.
*A default REST configuration properties file. (REST properties are not contained in the conf/openedge.properties file.)
*Zero or more REST .paar files that may be incrementally deployed into an existing OE ABL Web application.
*Zero or more SOAP .wsm files that may be incrementally deployed into an existing OE ABL Web application.
*A fragment of the openedge.properties file that contains the defaults for the application and its attending web applications, transports, session manager, and multi-session agents. The fragment is appended to the conf/openedge.properties file at installation time by a user-written tailoring script.
*An optional user-written installation tailoring script that customizes Web applications and openedge.properties files.
*An optional user-written startup environment script ( myapp_setenv.{sh|bat} that sets OS process environment variables used by the ABL application code.