Oracle Application Express (APEX) is a popular application development tool and is also used to develop custom extensions for Oracle E-Business Suite. FlexDeploy is a DevOps platform for Continuous Integration, Continuous Delivery, and Release Automation which supports Oracle APEX out of box. FlexDeploy strives to eliminate scripting requirements and provide in-depth support for many open source and commercial tools, database, middleware, and applications running on premises and/or in the cloud.
This FlexDeploy Loves APEX Blog Series will help you understand what makes FlexDeploy a perfect choice to implement DevOps and Continuous Delivery with Oracle APEX. Here is a summary of FlexDeploy Loves APEX Blog Series:
- FlexDeploy Loves APEX – Source application from SCM (Git, SVN, etc.)
- FlexDeploy Loves APEX : Source application from Development Environment
- FlexDeploy Loves APEX : Continuous Integration for APEX
- FlexDeploy Loves APEX : Deploy Individual Application Pages
In this FlexDeploy Loves APEX article, we will discuss using FlexDeploy to export APEX application from development environment and promote automatically to other environments like Test, QA, Production etc. Most of this setup will be shared for deployment of all APEX applications. We will use this particular application.
Let’s talk about FlexDeploy setup for automating export and import of APEX applications. FlexDeploy configurations explained below is one time activity, which may seem a bit complex at first glance, but the configurations are easy to follow, reusable and do not require scripting.
Create BuildAPEX workflow of Build type using Export operation from Oracle Application Expression plugin. Save and Activate this workflow. When executed, this workflow will export the APEX application as a SQL file and store the SQL file in FlexDeploy artifact repository.
Create DeployAPEX workflow of Deploy type using Deploy operation of Oracle Application Express plugin. Save and Activate this workflow. This workflow will deploy APEX application to target environment. Artifacts captured during build execution are used by deploy execution.
Now we need to define the APEX topology, i.e. environment details. First we will create an Instance called APEX and associate it with various Environments and Workflows (BuildAPEX, DeployAPEX). Here is what the Instance will look like for APEX. An Instance is a logical representation of some technology that is installed in one or more environments.
This means that we have an APEX server setup in DEV, QA and PROD. Now let’s define more details for each environment, i.e. Property values and Endpoint. For each circle below we need to provide configuration details. The colored circle will change to indicate whether it is configured fully, partially or not at all configured.
For example, let’s review details for QA environment for APEX. Let’s click on the circle icon in APEX row and QA column. First decide on Endpoint, so that you can provide property value details accordingly.
Endpoint should be preferably database node where APEX is installed. You can also use any Endpoint where SQL Plus is installed and is configured for connectivity to the APEX databases. You also need to make sure the APEX Export utilities are installed for export operation. See FlexDeploy – Oracle Application Express Plugin Guide more details.
- APEX Oracle SID – SID of database where application will be deployed. This is used during execution of SQL Plus.
- APEXExport Path – Directory path to the APEXExport class. For example – /u01/app/oracle/apex/utilities
- Oracle Database Home – Oracle Database Home. For example – /u01/app/oracle/product/11.2.0/dbhome_1
- Oracle Database User and Password – Credentials to connect to database.
- Oracle Database URL – JDBC URL for connecting to database. This is used during export operation.
- Target JDBC Driver Path – Path to jdbc driver jar file. This is used during export operation.
Now that we have the Topology configured, we can create a FlexDeploy project for each APEX application that we want to to automate. Topology configurations and Workflows will be reused by all APEX applications that we want to automate.
Note that we have used None as SCM Type an application is sourced from the Development environment. Workflows and Instances created previously are configured here as well. Every FlexDeploy project has a Stream, in this case it is called main.
Now let’s configure properties at the project level which is what differentiates one application from other.
- APEX Application ID – ID of application as seen on Application Builder. Keep id and name same in all environments.
- APEX Application Name – Name of application as seen on Application Builder.
- APEX Workspace Name – Workspace where application will be deployed. Use uppercase name.
- Database Schema – Parsing (owner) schema for application. Can be left empty if same as Workspace name.
Let’s start build manually as shown below.
Now let’s deploy the version that was just built from Development environment to QA environment as shown below. You can define approval and schedule requirements for deployments as well as put security restrictions on who can perform deployment to specific environments.
You can also use dashboards and reports to see how the applications have been deployed. Additionally, you can use test automation to run automated tests against a deployed application. Use test results to decide if the application is ready to be promoted to next environment or not. All these are options available for any type of project in FlexDeploy.
You just saw how you can configure an APEX project in FlexDeploy, and automatically promote an APEX application from Development to various environments. You can now just copy this FlexDeploy project and adjust various properties to match another APEX application.
In next post, I will show you how to export an APEX application from development environment and commit to SCM.