Oracle E-Business Suite
- Karl Henselin
- Perepa Sai Sri Mukhi
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
Checklist | Description |
|---|---|
Tomcat | Recommended install option contains Tomcat (no separate install required) |
SCM provider | Git provider : GitHub, Gitlab, BitBucket, Azure Devops, Oracle etc. Other supported source control management:
|
SCM repository URL | The URL of the source control management repository. |
SCM account user name | The username to login to the repository. |
SCM account password | The password to login to the repository. |
Review existing SCM directory structure | Recommended source control structure Source Control Folder Structure . |
EBS Custom TOP name | Name of the custom top you will deploy to. |
EBS Environment File (e.g. EBSapps.env) | The Fully qualified path to the environment file. This is the environment file outside of fs1/fs2 filesystem. |
Apps Password | The password for apps user. |
User id which runs EBS (e.g. applmgr) | FlexDeploy will connect to target server using this user. |
Password for user id | Password to connect to the target server. |
JDK home for primary app-tier host | Recommend JDK 1.8 installed outside of fs1/fs2. |
If EBS 12.2.x, do you deploy customizations using ADOP? | If using EBS 12.2.x, check whether you have any ADOP patching phases. |
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.
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.
General Configuration
Scroll through this guide to fill in the blueprint properties whereas the Build and Deploy options are auto-selected.
Project Info
Property Name | Value for this tutorial | Description |
|---|---|---|
Module Short Name | XXHR | This property defines the short name of the custom top for this project (eg. XXAR, XXHR). |
EBS Install Name | EBS | This value will provide environment independent name for EBS install (eg. ERP, EBSHR ). The default is EBS. |
Module Description | EBS Project creation using blueprint | Brief description of the custom module. |
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
Field | Required | Description |
|---|---|---|
Name | Yes | A descriptive name for this SCM instance. |
Code | Yes | A technical code for the instance, without any spaces. The codes are available as variables to shell and Groovy scripts, and therefore needs to comply with their limitations. |
Source Control Type | Yes | Type of Source Control Management System. We will use Git for this tutorial. Supported Source Control Management Systems are:
|
Description | No |
|
SCM Properties | Yes | The remaining properties are specific to the selected SCM. For Git:
|
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
Property Name | Values for this Tutorial | Description |
|---|---|---|
EBS Source Script | locate this value from your EBS server. | Source Script with full path. |
EBS Database User | apps | DB User to connect with privileges. |
EBS Database Password | locate this value from your EBS server. | Password to connect for |
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 Integrations is achieved by selecting Integrations from the menu. There are eleven types of integrations in FlexDeploy, but we will focus on Source Control in this tutorial.
Topology
Navigate to the Topology from the Menu. The Page with the Target Groups, Environments and Endpoints sections will be displayed. Choose a Target Group on the left. You will see a list of Environments on the right with colored circles representing each Target.
Click on EBS 12.1.3 Target Group and click on the Development Environment
Color coding represents:
RED - The Endpoint is not configured
YELLOW - some of the required properties are not set,
GREEN - all required properties are set and the Endpoint is configured
Targets Properties
Clicking the environment row for DEV allows modifying the Endpoint and 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.
Note that all the three of the files in the package were deployed successfully. If we modify/commit/push one file in GitHub, rebuild and deploy it to Dev, we will see that that one file gets deployed. The others will have a status of SKIPPED. This is because FlexDeploy maintains a hash on all files which it has deployed to determined whether it needs to be deployed or not. This change detection makes the process more efficient and helps maintain accurate auditing information related to when objects really changed.
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.
Related content
- style