We have now created the topology, workflows to manage the build and deployment, and a connection to our GitHub repository. Next we will create a Project to tie it all together.

At the completion of this section, you will:

understand the concept and use of projects in FlexDeploy
understand the relationship between projects, workflows, and topology
gain further understanding of the Partial Deployment methodology
understand the relationship between source control and projects
learn how to configure projects for Oracle EBS
learn how to populate Oracle EBS metadata about your customization files within projects
have a basic understanding of options available to source customizations directly from an EBS instance

A Project represents a collection of resources which can be built and deployed, with its history (what, who, where, when) tracked over its lifetime. A project itself remains relatively static, even though its associated source changes over-time, and maybe even very frequently. A project represent a web application, a set of configuration files, a service, etc.

Tip

In the case of Oracle E-Business suite, the project represents a set (or sub-set) of customizations within a single custom top. There may be one large project for the entire top, or you may choose to break it down by EBS module (or set of modules), or by CEMLI/RICEW (if you are using the Oracle AIM methodology). Dependencies between individual customization files can be managed within a project, but not across projects. So that is one consideration when determining how granular to define your projects. You can define which projects must be deployed and in what order.

For the tutorial, we will define a single project to manage an entire custom top.

Partial Deployment

With traditional applications such as web applications or integrations, they are typically built and deployed as a single unit. For example, a WAR, JAR, or EAR file. With an ERP or other large enterprise software packages it is quite a different model. These are very large systems consisting of hundreds or thousands of customizations which are applied to the base product. And often times the development teams are very large and there are many moving parts at any point in time. Its not feasible to tackle deployment of these large software packages in the same way we do traditional applications.

FlexDeploy provides another approach called Partial Deployment. Its called Partial Deployment because it provides building a "partial" subset of the project and assembling the source into what is called a package. For example, you may have one project for the entire custom top, but create packages for several sets of changes you are developing for a release. Developers can build and deploy the packages independently, or group them together in into a release for a shared delivery milestone.

To enable this capability, FlexDeploy generates metadata about all of the customizations for your project (called project files), and builds a "catalog". The developers then build packages using items from this catalog. We will see this in action as we work through the next two sections of the tutorial.

Applications & Folders

Open the Project Explorer by selecting Projects from the main menu. In the left-hand pane you will see the hierarchy of folders, applications, and projects. By default there is a root folder called FlexDeploy.

Folders and applications are used to organize and group your projects so that they are easy to locate. There is additional configuration, such as security and approvals, but those configurations are out of scope for this tutorial.

Folders may contain folders or applications
Applications may contain projects

Here we will create a folder and an application to hold our project.

To create the project, right-click on the FlexDeploy root folder and select Create Folder. In the Create Folder form, enter a folder name of EBS.

Click OK to create the new folder.

To create the application, right-click on the EBS folder we just created and select Create Application. In the Create Application form, enter an application name of Global.

Click OK to create the new application.

Creating the Project

A project represents a unit of work which can be built and deployed. There is another type of project called a utility project, but that is outside the scope of the tutorial.

To create the project, right-click on the Global application we just created and select Create Project. Enter the following information for the required fields:

Field	Description
Project Name	A descriptive name for the project
Partial Deployment	Indicates that this project will be using Partial Deployment
Project Type	The technology type for this project

Click OK to create the new project. The project is opened for you in the center pane. Click on the Configuration tab. Enter the following values for the required values:

Field	Description
General Project Configuration
SCM Type	The Source Control Management System type where the project's source is located
Build Workflow
Build Workflow	The workflow which will be used to build this project
Build Instance	The topology instance which the build workflow will execute on
Deploy Workflow
Deploy Workflow	The workflow which will be used to deploy this project
Deploy Instance(s)	The topology instance(s) which the deploy workflow will execute on. If more than one is selected, the user will select specific ones in the deployment request.
SCM Configuration	These properties are dependent on the selected SCM Type. Properties listed below are for Git.
Git Instance	The Git instance (repository) from topology which hosts the source for this project
Branch Name Script	A groovy script which resolves to the branch name to execute the build on. This is typically the stream selected during build.
Sparse Checkout Folders Script	A groovy script which resolves to the path (relative to the repository root) containing the root of the source files within the selected Git instance.
Streams
Stream Name	The name of the Git branch. If you will be building from multiple branches, you will add a new stream for each. The stream is selected during the build request, and will available as StreamName variable to the groovy scripts in the SCM Configuration.

Click Save to apply your changes.

Project Properties

We have created a project and completed the base configuration, including:

Binding the project to our build and deploy workflows
Binding the project to our Global instance for both build and deploy
Associating the project with our GitHub repository
Established a single stream for our GitHub master branch

Next we will configure the project-scoped properties for EBS. To configure the properties, click on the Properties tab. 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. Enter a value of XXHR, and click Save to apply the changes.

Tip

There are dozens of properties which are used to adjust the behavior of the project. Many of these properties are used to help FlexDeploy categorize the customization files you have stored in your source control repository into the correct types, or override the location of where they get deployed.

See Source Control Folder Structure for the recommended SCM directory structure.

See Oracle EBS Plugin Guide for a listing and description of all EBS related properties.

Project Files

The next step is to 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. The metadata includes the location on the server where it will be deployed, a generated command used to deploy it, and other attributes specific to the type. Click on the Project Files tab to see a list of customization files for this project. Since it's a brand new project, there are not any files yet.

Click the Populate from GIT button, and select master as the Stream. Click Populate.

In our GitHub repository, within the master branch, FlexDeploy found 35 files. The files have been automatically categorized into the appropriate types. You can filter by type by selecting it from the drop-down. The types for which the project files have been categorized into are displayed as bold.

The metadata varies from type to type, but in all cases it is used to ultimately derive the deploy command. The deploy command is what gets executed against the source file to perform the deployment. You can review the metadata for each of the files in this project, but here are few examples of the generated deploy commands.

Form	DB Objects	AOL
export FORMS_PATH=$FORMS_PATH:$AU_TOP/forms/US/:$XXHR_TOP/forms/US/:$AU_TOP/resource/:; frmcmp_batch $AU_TOP/forms/US/AKDAPREG.fmb $FDEBS_DB_USER/$FDEBS_DB_PASSWORD output_file=$XXHR_TOP/forms/US/AKDAPREG.fmx compile_all=special	cp "$SOURCE_FILE" "$XXHR_TOP/patch/115/sql/"; sqlplus "$FDEBS_DB_USER"/$FDEBS_DB_PASSWORD <<EOF set define off @$XXHR_TOP/patch/115/sql/XXHR_PER_SOCIETIES.sql . SHOW ERRORS exit sql.sqlcode EOF	cp $SOURCE_FILE $XXHR_TOP/patch/115/import/US/; FNDLOAD $FDEBS_DB_USER/$FDEBS_DB_PASSWORD 0 Y UPLOAD @FND:patch/115/import/afcpprog.lct $XXHR_TOP/patch/115/import/US/XXHR_First_CP.ldt - UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE ;

Metadata Tips

Each type has metadata fields which are used to calculate the deploy command. With the necessary privileges, you can adjust the metadata and re-evaluate the commands. However, the preferred approach is to adjust the project properties such that the commands are generated correctly and no manually intervention is required in the majority of cases. For a deeper understanding of the metadata for each object type, and the role the project properties play in its generation, see EBS Object Types Reference.

For some object types, such as AOLs, you will notice the Build Command. This is used when you are sourcing the objects from an EBS Development environment rather than an SCM. In this case, the object will be downloaded from the EBS instance during the build using the build command. In such cases, you can build the metadata for these objects using FlexDeploy's metadata generator.

Notice the project files have a red + icon in the State column. This indicates that the file is newly populated and the metadata has not yet been saved in FlexDeploy. After review, click the Save button to persist the metadata.

After saving, the State icon is changed to a green check mark.

We have now populated and saved the project files for this project from our GitHub repository. These project files now become a "catalog" of objects from which we can assemble into build packages. We will explore this in the next section.

Tip

The project files are only the metadata about our source files. The actual revision of the file is obtained during build. Therefore, there is no reason to populate as new revisions are committed for files which are already populated. You will only need to populate when new files are added to the repository, so that they become available in the catalog.

Completed 8 of 11 Sections	Continue to Building Packages	Back to Git Integration