Oracle E-Business Suite

FlexDeploy provides broad and flexible support for managing the build and deployment of customizations across Oracle E-Business suite implementations.

To name a few, FlexDeploy has support for:

• EBS 11.5.10, 12.1.x, and 12.2.x (with or without online patching)

• One or many custom EBS Tops

• Source your customizations from either an SCM repository or a development EBS instance. 

  • See FlexDeploy Plugins for a list of supported Source Control Management (SCM) systems.

  • See EBS Object Types Reference for details on supported types.

• Automated change detection on deployment

• Continuous Integration

• Flexible Build options

• Integration with FlexDeploy Pipeline & Release features

While this tutorial will not cover all features or design patterns for managing EBS customizations, it’s aim is to provide an end example for a common use case.  Where applicable, we will call out different options, why you would consider them, and the potential benefits to your overall process.

Objective

You have a global instance of Oracle E-Business Suite with customizations in a custom top called XXHR.  The goal of this tutorial is to configure FlexDeploy to manage the lifecycle of building and deploying the customizations across the environments in your organization.  In this tutorial, we will source the customizations from a GitHub repository, and deploy them to a Development Environment.

Once the configuration is complete we will walk through the build and deployment life-cycle for managing your EBS software delivery.

Checklist

Create EBS Project using Blueprint

The assumption is that you have FlexDeploy installed and ready for use. When logged into the FlexDeploy, you will see the Home page. Click on the + icon on the top and click “Create Project” to create a new project.

Open

The screen displays the list of blueprints supported by the FlexDeploy. Select the blueprint from the list or you can search for the blueprint in the search filter present in the top. In our case, we will select the EBS Customizations.

Open

General Configuration

Scroll through this guide to fill in the blueprint properties whereas the Build and Deploy options are auto-selected.

Project Info

Source Control

Click on source repository dropdown. If you have already created a connection to your source code repository, select it from the list. Enter the sparse checkout folder, if any.

Otherwise add one by clicking on “Create new Source Repository”. Enter the sparse checkout folders script, if any.

Inputs Info

We selected the SCM type as GIT. The properties related to the GIT source control management will be displayed on the screen.

Click on Create New Credential to create a new credential password for GIT password. Enter the credential Name which is unique name to identify the password. In the secret text, enter the password and click on Save.

After saving the credential, click on Save again on the SCM instance. Do a Test Connection. The green color ticket mark will show that the connection is successful.

Enter the sparse checkout folder value, if any. Sparse checkout folder is a Folder in your repository where your EBS Customization files are located. If files are in root folder of repository, then leave this value empty.

Gather Build and Deployment information

Enter values for any workflow properties which are required for the build and deploy.  In the image below, no properties are required for this build. Select the target endpoint that the build and deploy should execute on.

Target Properties

Select Topology from the menu and then select Topology Overview from the left menu.  You will see a table that has Instances as the rows and Environments as the columns with colored circles representing the Environment Instance.  Color coding represents:

• RED - no required properties are set and/or the Endpoint is not configured

• YELLOW - some of the required properties are set and/or the Endpoint is not configured

• GREEN - all required properties are set and the Endpoint is configured

Selecting the GREEN circle for DEV will display the configurable properties/Endpoint and allows for the configuration of the properties.

The Project Name will be auto updated as XXHR since it takes the value given in the Module short name i.e. Custom top Name.

Select the Parent Folder from the list and click on “Create”. We will be able to see the project created under the given Parent Folder path.

We can see the Folder hierarchy on the top of the project.

Summary

General Configuration

Build and deploy workflows

Project Properties

There are many properties for EBS, but only one is required - EBS Module Application Short Name.  This property defines the short name of the custom top for this project. The value for EBS Module Application short name i.e. XXHR will be auto populated from the blueprint itself. You can filter out the properties by using the search filter properties in the top.

Source Control

Branch Name

Change the branch name similar to the git repositories branch name. Click on Save.

SCM Instance

Viewing the current list of https://flexagon.atlassian.net/wiki/spaces/FD60/pages/9856627772 is achieved by selecting Topology from the menu, then the Integrations tab from the left-hand pane.  There are eleven types of integrations in FlexDeploy, but we will focus on Source Control in this tutorial.

Target Properties

Populate the files

Click on File Catalog under Package screen.

Click on “Discover”. This will populate the customization files which are stored in our GitHub repository into our FlexDeploy project.  FlexDeploy will interrogate the files, determine the type, and generate metadata about them. 

It displays the count of list of the files discovered from that repository.

Click on “Show new Files” to see the list of files on the file catalog screen.

To create new files, click on create button. The create file screen will expect the file path and object type. Enter the value and fields related to the object type selected will be displayed.

Click on Evaluate if any modifications are done. Click on Save button to save the file.

To inactivate the file, click on Active switch box.

We can see the file created on the top of the screen.

Create a package

On the package screen, click on create button to create a new package.

Enter the package name and select the package type. We select the “User Managed” in our use case.

Open the package by clicking on the package name.

Click on Add Files to add the files that are populated from the SCM repository. We can also create new files at the package level.

Click on the file name directly to add the file in the package. Else, use the filter file option to search for the specific file and select that to add into the package. Click on save.

We can see the files added in the package under the package file screen.

Building Package (EBS)

Click on Execution tab to submit the build request for that package. Click on Build.

The Build Request Form is displayed. Click on the “Submit” button for the build to execute.

Here you can make note of build execution details for version 1.0.1 of our CHG0054692 package.  To view more detail, click on the generated Execution Id.

On the Steps tab we see the execution details of our build workflow. 

Notice the Initialize: Extract Project Files (Revisions) step.  This is an implicit step that is injected into the build workflow when using partial deployment.  This step extracts the source code for the package files from the configured SCM.  These files are then available for the EBS Build step to assemble them into an artifact, which is versioned (1.0.1) in the artifact repository.

After the build completes we can see the artifact on the Artifacts tab, and see details of the files within it on the Files tab.

Another mechanism for building a package is to select Build from the Execution tab. Select the package name of CHG0054692.

Click on Submit to submit the build request.

Since the build is successful, we see the pop up saying No change detected in source control. Click on Force Build or check the force build check box to re-build the execution.

Click Submit to build the package.  You can again monitor the build execution by the clicking on the execution Id of project version 1.0.2.

Rebuilding an Existing Package

Now suppose you need to make a modification to one of the files in your package in GitHub.  After pushing the change to the master branch, we need to initiate a new build.  To rebuild an existing package, click on the single gear icon next to the user name, you want to rebuild.  Here we will rebuild project version 1.0.2 of the CHG0054692 package.

Click the wrench icon as shown below will again launch the build request form with package name pre-filled and the same project files added. 

Also note that the request form selects the SCM revisions of the previous build.  To pick up the latest revisions, we will navigate to the File Revisions tab on the Build Request Form and select the revision which we want to make use of.

Click Submit to build the package. You can again monitor the build execution by the clicking on the execution Id of project version 1.0.3.

Deploying Packages

In the previous module, we performed three builds of one package.  In this module, we will perform deployments of that package into the Dev Environment.

To submit the deploy request for a package, first click on the Execution tab of the XXHR Project. Click on the icon as shown in the image below will launch the deploy request form for that project version 1.0.3.

Select the environment Dev. Click on Submit to submit the deployment for the package CHG0054692.

We can see all the three files that we selected got successfully deployed to the Dev Environment.

Congratulations, you have completed the FlexDeploy E-Business Suite tutorial!  You have learned just how easy it is to configure FlexDeploy to build and deploy all of your EBS customizations across your environments.