Packaging uses all output from the build phase to create consumable artifacts that can be tested and deployed to the customer. These artifacts include r-code, procedure libraries, configuration files, service definitions, online help, and other options.

Package overview

The output artifacts, code, and services generated from the build phase are combined to form a component. Components are the smallest logical units you can use to define the parts of your ABL business application. Components are be packaged together to build your business application.

As applications are packaged for deployment, you often combine components with configuration and settings. Each package should be independently developed, built, and versioned. Packages should not be tied to your OpenEdge version because changes made in OpenEdge versions could disrupt your packages. It is best for your packages to contain data and code that is independent of your OpenEdge version. Packages should be public and visible so they can be accessed easily within a CI/CD pipeline.

The following development artifacts are commonly packaged together to build OpenEdge application deployment artifacts:
  • ABL code and data
  • Static resources such as images and web pages
  • Configuration files
  • Scripts and procedures
  • Environment
  • Metadata

Application configurations

The simplest, runnable Progress Application Server for OpenEdge configuration contains one instance, one application, one WebApp, and one or more services. This basic configuration is what you get by default when creating an instance with tcman create. However, an instance can support many applications, depending on the available CPU and memory. When using one application per instance, you have advantages in scalability, flexibility, and simplicity. When using many applications per instance, you can have a family of applications that performs different functions within your instance. Having multiple applications per instance is also useful for developer environments because it allows you to do smaller deployments and share resources between applications. In addition to having multiple applications within a single instance, you could have multiple WebApps within a single application. This configuration allows you to use multiple services with each other in a more structured way. WebApps can contain many ABL services.

The best application configuration can be determined through load testing and identifying the right balance of applications, WebApps, and services. Another consideration for multi-tenant hosted systems is being sensitive to Service Level Agreements that can differ depending on the size of your operation. You might have smaller customers sharing an instance and provide large customers their own instances. Load balancing is another consideration when defining your instances and applications.