1. Implementation Guide
  2. Implementation
  3. Application Deploy

Application Deploy

This section describes the process for deploying an application in an RPASCE Cloud Service environment.

Object Storage Upload Location

Oracle RGBU cloud services include an Object Storage site for incoming and outgoing file transfers. See "Uploading and Downloading Files" for details on the Object Storage interface.

For the purposes of building the application, four paths within the Object Storage site are used:

config

For uploading the application configuration into the cloud environment, create a .zip archive containing the contents of the config directory (without the top level config folder). This archive file must be named as <config_name>config.zip. This archive file must be placed in the planning/incoming/config path on the Object Storage service. It may be updated as often as necessary in support of application build or patch activities.

Example

The ascs_config.zip may contain the following contents:

  • ascs folder - this is the folder with configuration for an application called ASCS (required).

  • ascsDashboardSettings.json - custom settings for the ASCS dashboard (optional).

  • ascsHelpConfig.json - custom settings for ASCS Online Help (optional).

batch_control

The set of batch process control files, as detailed in the previous section, must be uploaded as planning/incoming/batch_control.zip (or alternatively as individual files in the planning/incoming/batch_control path) within the Object Storage service. These files are loaded into the application's data store during deployment, and can be updated later as part of the Patch Application task or by running the Manage Batch Control task.

Bootstrap Environment

A newly provisioned RPASCE cloud environment is set up with a bootstrap configuration that allows the implementer to log into the RPASCE Client and access the Online Administration Tool (OAT) interface before an application has been deployed. The bootstrap OAT configuration allows only tasks required to deploy your application. Once the application has been deployed, both the application-specific tasks and activities as well as the deploy activities will be available. This allows the application to be re-deployed from scratch multiple times, should this be required during the implementation phase. (Note that this would trigger a complete loss of any data, so would only be applicable in early phases of implementation testing.)

OAT Parameters

A few parameters must be specified when initiating an Application Deploy process through OAT. The implementer must supply these values:

Config Name

The name under which the configuration has been saved. For those familiar with the RPASCE application construction process, this is the name that is internally passed as the -cn parameter to rpasInstall. A drop-down list offers choices based on the available application config archive files in the incoming FTP area.

Partition Dim

The dimension on which the application will be partitioned. The application is constructed with one sub-application for each position in the given dimension. This must be a level of separation that fits with the intended workflow for individual users so that, when possible, most users' daily tasks relate to only one sub-application. This lessens contention when many users are active in the system.

Batch Group

Once a application has been built successfully, a named group of batch operations may be specified (typically including measure data loads and mace calculations). This operation sequence must be one batch_type entry in the Batch Exec control file, batch_exec_list.txt (described in "Batch Exec Service").

Overwrite

In the case where the application has already been built once, and the implementer must rebuild the application from scratch, which might occur because a non-patchable change has been made to the configuration, this option must be selected. If it is left in the default unselected state, then the application build process will halt and report an error, rather than overwrite the existing application.

Application Build

The application build process automatically carries out the following steps:

  1. Basic validation of the given config name and partition dimension.

  2. Ensure that a configuration with the given config name has been uploaded.

  3. If the overwrite flag is false, ensure that there is no existing application. It reports an error if the application exists.

  4. If the overwrite flag is true, remove the existing application.

  5. Build the application using the config name and the partition dimension as specified in the OAT parameter screen.

  6. Copy any users and user groups from the bootstrap application environment into the application environment.

  7. Copy the uploaded batch control text files into the application from the SFTP location.

  8. Run post-application-build batch group.

  9. Add the application details into the provisioned RPASCE Client configuration.

Once the Bootstrap Application task has completed, you only need to log out of the RPASCE Client and then log back in again to see the tasks and menus associated with your newly built application. (It is no longer required to restart the RPASCE Client, and this option has been removed from the OAT menus.)