FlexDeploy - Oracle Transactional BI Plugin Guide

The Oracle Business Transactional Intelligence plugin provides operations to manage the build and deployment of WebCatalog objects across you cloud instances. 

Supported Versions

  • OTBI for Oracle Cloud Applications

Key Features

  • Source WebCatalog from SCM or Development environment.
  • Supports FlexDeploy Full as well as Partial Deployments for WebCatalog objects.
    • Partial deployment option allows users to select various catalog objects (via FlexDeploy package) for build and deployment. Change detection and reporting is maintained for each individual object.
    • Partial deployment option can make use of dynamic packages for an effective way to manage consistent deployments at the folder level.
  • When sourcing from OTBI development instance, files are populated with an extension mapping to its type.
  • Folders are automatically deployed first without children, followed by their components

Plugin Operations 

Partial Deployments

The Oracle Transactional BI plugin supports full as well as partial deployment projects. Partial deployment project can be created of "Oracle Transactional BI" type to manage object types defined in next section. 

  • Project can be either source data from Backend (Oracle Transactional BI server in development) or SCM (any supported SCM type). 
  • Select SCM Type as None, if you want to perform development environment to other environments migration. Keep in mind that artifacts are still captured at build time in FlexDeploy repository to allow for reproducible deployments.
  • Folder deployment in partial deployment mode, only deploys Folder without any of it's children objects. You can select individual children objects as necessary in package for deployment.
  • Objects in files list can not be sequenced for this project type. If necessary, user can control sequencing when building user managed packages.
  • See appendix for more details on how you can source files from SCM.
  • OTBI project packages are deployed using a "stop on failure" method.  In other words, if any file in the package fails the other will not be attempted.  The predominant reason is to avoid dozens of failures when the deployment of the parent folder fails.

Appendix