Managing Oracle Fusion Applications project requires a clear understanding of the various facets of its lifecycle. Whether you are starting a new project or joining one in progress, this article will help you quickly find your bearings and navigate further with ease.
This article summarizes lifecycle topics related to key phases of Oracle Fusion Applications implementation and maintenance, highlighting existing options, tools and documentation. The purpose is to provide a clear and concise overview along with pointers that guide you to detailed next steps. Topics such as upgrade that need more in-depth review are slated for upcoming articles.
- The focus here is limited to on-premise work. For customers using the Oracle SaaS Cloud, while the overall concepts still hold, the options and tools are different. I will cover the SaaS Cloud scenario in the near future.
- This article is on the Fusion Applications as a whole and is not to be confused with the Oracle Workforce Lifecycle Manager which is a specific product in the Fusion Applications HCM Family.
- The links in this article reference mostly Fusion Applications Release 7 documents and a new Release 8 has just come out. If you are using Release 8 please use the equivalent documentation from Release 8.
The software lifecycle is a well laid out phenomenon tying goals, process flows and resources. A typical representation of the lifecyle stages mapping project requirements to workflow holds for Oracle Fusion Applications as well. The major phases are : planning, implementation, administration (routine) and maintenance (scheduled / ad-hoc).
Fusion Application projects involve many different technology stacks all the way from hardware and networking, to database, web technologies and security. So to ensure successful and efficient results, it is important to include the different technology teams within the enterprise from the start through the full lifecycle. Given the spread of the workforce globally in the enterprise in today’s world, it is vital for project managers to not only consider the technical work and resources, but also ensure synchronization across various teams to handle the different tasks for smooth project workflow.
Fusion Applications come in different implementation options and the applicability of lifecycle steps and tools varies accordingly – the figure below shows the options.
Notes for Oracle Cloud and OVM Template environments
While the basic Lifecycle concept, flow and phases hold the same across all implementation options of Fusion Applications, the exposure and applicability of some steps and tools vary. For example, customers using Fusion Applications in the Oracle SaaS Cloud are free of any concerns associated with installs, tuning, backup and patching / upgrade. They can instead focus their work on functional implementation. While the steps in this article still hold from a software project view, they are not exposed to the customers and their IT teams. This article will focus only on on-premise bare-metal deployments where customers tackle these issues themselves.
FA Lifecycle Phases, Steps and Tools
Phase 1 : Project Planning
While Fusion Applications by their nature start with well defined organizational goals, their implementations can carry a broad scope and involve most of the IT teams over the project timeline.
The following table summarizes the key steps and pointers to the detailed tasks that project managers need on a daily basis to plan the work as well as help the various teams understand the plans.
|1.1||Overview of Fusion Applications Concepts||The best way to get started with Fusion Applications is the Concepts Guide. It has all the basic functional and technical information as well as pointers to other locations for more details.|
|1.2||Business and functional Requirements Planning||A glossary type of introduction and quick planning summary are in the Setup Guide , Getting Started white paper and Common Implementation Guide and more in OTN (example from OOW).|
|1.3||Project Phases and Steps||The pathway to get started on project implementation is in the Roadmap Guide here.|
Phase 2 : Implementation
The Implementation phase involves the core work to get Fusion Applications running. The basic focus is to get an initial instance working in order to get a preview of the process and tasks involved, and the ability to try and evaluate the product features. This phase runs across the gamut of most IT organizations and so active and proper control of the tasks and resources are essential for efficiency and success. An overview of the documentation list that comes in handy is here.
The table below shows a summary of all the key aspects in the implementation phase with pointers to more detailed information.
- Most of the steps within the implementation phase have pre-requisites and are strictly sequential unless otherwise noted.
- Always when filesystem backup is taken, ensure to shutdown midtier process.
|2.1||Pre-Requirements||Infrastructure Requirements||Requirements for a bare-metal FA Installation are here.For organizations that need a robust full-fledged environments, the Enterprise deployment guides provide a more detailed architecture and install guide.It is vital to ensure that Fusion Applications compatibility certifications are met by all parts of the stack. This information spanning from OS and Database to client browsers is available in Oracle Support website under the “Certification” tab.For organizations that need multiple FA environments (production, test etc), the ability to clone (make a copy of) an environment is important. There are specific infrastructure requirements that are needed for this, especially with host naming conventions. The Cloning Guide lists best practices to be used for FA installs and should be followed to ensure smooth cloning work later.Fusion Applications is architected to allow application level scalability and thus can run across multiple nodes to make the most out of available hardware. In such cases, to ensure all the nodes use the same software and configuration, a key requirement is to install FA in a shared storage used by all nodes. This is is detailed in the install guide.Another aspect to plan before an install is the backup process. Backups are needed after major install steps – after RCU, after IdM, after FA etc. These backups need to cover all the databases and IdM and Fusion Applications midtiers. It is best to plan for flash backup (DB and Filesystem) if possible to cut down the time for backup as well as any recovery if needed.|
|Software Download||Fusion Applications software for on-premise customers is available at the Oracle E-Delivery site. The Fusion Applications DVD set is self-contained and sufficient to install the complete Fusion Application stack including Database, Identity Management and Webtiers.For organizations that prefer to install database separately, they can do but need to ensure they comply with Fusion Apps certifications.All additional patches are available at the Oracle support website website.|
|2.2||Installation (the steps here are sequential)||OS||Supported platform list for bare-metal install is here and more details are in the certification list.|
|Database||Independent databases are used for Fusion Applications and its Identity Management stack. Each database can be a single instance or multi-node RAC. The databases can share common hardware and oracle home but it is best to keep them separate as a best practice.
Fusion Applications must reside in a single database. For organizations that need more robust architectures, Identity Management or BI can be split into separate databases as allowed by each product.In addition, some projects may integrate external activities to Fusion Applications (eg. data warehouse, custom apps) and those must use reside in databases separate from Fusion Applications or IdM.Fusion Applications provisioning tool can perform database install also. However, for organizations that prefer to install database separately, they can do so but need to ensure they comply with Fusion Apps certifications.All databases should be installed before IdM or Fusion Applications can be provisioned.
|RCU||Repository Creation Utility (RCU) is a tool used across many Oracle products to create the necessary DB schemas and objects needed by those products to install and run.In the case of Fusion applications, the two main stacks involved are the Identity Management (IdM) and the Fusion Middleware (FMW). Each of these need mandatory database objects. These objects are created in the database using the RCU. The Fusion Applications RCU also creates and populates preseeded database objects needed for Fusion Applications products that run on top of the Fusion Middleware (FMW) stack.The RCU needs to be run separately for IdM and FA pointing to their respective databases and the details are in the install guide as well as EDGs RCU is available only in Linux and Windows platforms.A backup of the databases is a must after the RCU step.|
|IDM||Currently Fusion Applications uses a devoted Identity Management (IdM) stack and an IdM install is a pre-requisite for Fusion Applications provisioning. Please ensure to install the IdM stack using the IdM software and documentation that comes with the Fusion Applications.Since Fusion Apps Rel 7 the IdM install has moved to an automated provisioning model similar to Fusion Applications. Note that the IdM stack has its own webtier separate from Fusion Applications webtier and has options for DMZ hosting as well. IdM provisioning for Fusion Applications is documented here.It is important to also follow any special instructions in the Fusion Applications Release Notes specific to your release as all post-release updates and patches are listed there. The release notes are updated frequently and so it is important to get the latest version before you do any work.A full backup is a must at the end of the IdM install step.|
|Fusion Applications||As mentioned before, the configuration of database and IdM are pre-requisites to provision Fusion Applications.The next step is to install the tool that in turn will provision the Fusion Applications environment. In the case of multi-node use, this tools should be installed in a shared storage visible to all nodes.Using the provisioning tool, a response file is created with desired parameters for the FA system topology. Then the provisioning tool will be run to use this response file and install Fusion Applications with the desired topology. The provisioning process is automated with little user input and includes basic system validation.All the steps for the install tasks are detailed in the FA install guide.There are a few post-install steps and mandatory patching to be done as given in the Release Notes. A full system backup is a must at the end of this step.|
|2.3||Other Deployment Options||Enterprise Deployment||For customers who need full-fledged installs, following the Enterprise Deployment Guide documentation provides complete steps that include scaling out the servers for high availability and configuring the webtiers in the DMZ network.|
|OVM Template||This article is for bare-metal deployments of FA including installing FA in a guest VM.There is another VM deployment option for FA named “FA OVM Template Deployment” where Fusion Applications is deployed using pre-built Oracle VM templates. This article and the above install steps do not hold for deployments that use OVM FA Templates (whose discussion will follow in a different post). For now, one can use the OVM install doc to proceed further if they are doing an FA OVM template deployment.|
|2.4||Post-Installation Setup / Config||Common Setup||Some of the initial setup tasks are common across the Fusion Applications product offerings and are given the Post-Install Guide and the Common Implementation Guide.|
|Product-offerings setup||Product-specific setup involves detailed implementation steps for each product and is the bulk of the implementation phase to enable functional features. These are detailed in product-specific documentations here.|
|2.5||Customization / Integration||Overview||Once the Fusion Applications environment is installed and configured, customers may need to customize or extend the functionality. The Developer Documentation is a good starting point for these.|
|Customization||Customization and extension information is located here.|
|BI||BI configuration / Reporting to get additional information from FA data is documented here and here.|
|Other||The Oracle Enterprise Repository for Fusion Applications is a good resource to get integration related content.|
|2.5||Configure Security||Security||The FA Secuity Guide and the APM Admin guide are useful to understand FA security and manage user access and roles.|
Phase 3 : Administration
The Administration phase is a collection of routine tasks performed to keep the system running well. The key tasks are listed in the table below. Additional tasks that do not come under normal daily work are listed in the next section under maintenance.
|3.1||Basics||Once the system is installed and implemented the immediate next steps are basic administration task such as system start/sop, managing jobs, and changing system user passwords. These are covered in the Fusion Applications Administration Guide.|
|3.2||Monitoring||With the system in running state a constant task is to monitor the system and watch for any issues in performance or ad-hoc errors. Fusion Applications comes with Enterprise Manager (EM) to perform this.The EM is usable in two ways :The first is the often used Fusion Application Control interface that runs out of the AdminServers in each Fusion Applications weblogic domains.The second is the less known fact that the Fusion Applications comes with EM Applications Management pack and Fusion stack is geared for monitoring using the EM Cloud Control at the datacenter level.These are documented in the Monitoring section of the FA Admin Guide. They also provide useful features such as in-depth investigation of stack issues and performance.|
|3.2||Backup / Recovery||Backup is another important and routine Administration task and is covered in the FA Admintrator’s Guide here.A couple of key issues to note :First, when backup is done it is critical to keep in mind that the system consists of three key components – the databases, IdM stack and the FA stack – and all of them need to be backed up in synchronization to allow for proper recovery when in need.Second, filesystem backups should be done only the midtier processes are shutdown.It is best to make full use of the flash backup technologies (DB and disk) given large sizes involved.It is also critical to actually test the recovery process periodically to validate it.|
|3.3||Tuning and Troubleshooting||Fusion Applications comes with a basic Tuning Guide and the Admin Guide monitoring chapter has addition info – use these and the EM controls to complement the traditional tools for FMW and Database tuning.|
|3.4||Scaling||Over time, usage patterns can pose a need for additional capacity or increase in availability. These are handled by resizing and scaling out the FA system, and if necessary, the hardware. The Administration Guide High Availability and Scaling chapter has details to get started on this.If the EDG was followed to provision the system, please note that the scale-out feature was already enabled in the system and you just have to follow the same EDG scale-out steps to add more nodes.Scaling out can also be done using the EM Cloud control.|
Phase 4 : Maintenance
We now come to one of the popular phases in FA lifecycle – popular because the tasks provide the critical features and patches needed for functional usage. Fusion Applications is now in Release 8 and some customers have actively followed the upgrade process for the feature set benefits. The FA upgrade process has undergone changes with releases and is now more automated and simpler than before, and patch bundles follow regular release cycles too.
While patching is done on a per-product basis, upgrades are more comprehensive and involve the entire FA stack.
Cloning / P2T are the methods to replicate an environment. Cloning copies an environment fully in an empty target hardware and changes the end-user URLs and passwords so it is independent of the source system. P2T is more concise and copies just the data and configuration from one FA system to another.
|4.1||Patching||Patching of Fusion Applications implies patching of any component in the whole stack – all the way from database to midtier, security and functional modules.Different tools are patch different layers of the stack and it is important to understand them. The FA Patching Guide details them.Some patches come in bundles that may cover multiple products. The patch bundle that targets the FMW stack is called the P4FA (Patches for FA) bundle. The patch bundles that target the Fusion Applications deployed over FMW stack are called the “High watermark” patch bundles and go by product families such as HCM Patch Bundle 11 etc.The individual patches as well as the patch bundles are available from Oracle Support.|
|4.2||Upgrading||Over the past couple of years since the first release of Oracle Fusion Applications, there have been periodic releases that update the entire stack with patches and new features as expected. While some steps in earlier upgrades were manual, they are almost fully automated now and should cut down on the time needed to upgrade.The upgrade process allows for phased upgrade and groups tasks by pre-downtime and downtime categories to allow customers perform these more efficiently within weekends.The FA Upgrade Documentation has complete details on the process.(Given the constant customer needs in this area, the next article in the lifecycle series will be devoted to upgrade.)|
|4.3||Cloning / P2T||One FA system installed, implemented, and running may not suffice for enterprise customers – they may need multiple environments with similar configurations and data to do development work, Training, User Acceptance Testing (UAT) or performance / patch testing etc.The FA cloning process comes to the rescue and is a key aspect of the FA lifecycle. Cloning as the word means is the ability to make copies of a FA instance for parallel use – such as creating a copy of the production instance and using it for User Acceptance Testing to ensure patches work right in the test system before being applied to a production system.Fusion Applications is a multi-tier system and so making a simple copy of files into a new hardware is not sufficient as changes in parameters like hostname or database information need to be handled right. So the product comes with a couple of tools that enables this.The two basic methods and associated tools in Fusion Applications are named “Cloning” and “P2T” (Production to Test).Cloning provides a way to duplicate an entire Fusion Applications environment including the databases and filesystems of FMW / FA and IdM stacks into a different hardware (which has OS but not FA). There are some rules on how this can be accomplished.P2T is a simpler process that moves just the data and configuration information from one FA environment to another. P2T has a key requirement that the source and target FA environments should have similar stack versions.Thus P2T has a target that is another FA instance, while Cloning copies FA onto an empty target with just the OS.Both methods need details on the source environment to be able to recreate it in the target.Complete details on Cloning and P2T are documented in the FA Cloning and Content Movement Guide.|
Some steps in the lifecycle process are much more than a mere task – especially, cloning and upgrading. These can be mini-projects themselves and involving multiple teams across the enterprise technology stack. There will be more in-depth coverage of these topics in future articles.
The above information on Fusion Application lifecycle stages should serve as a good starting point and help one to quickly and clearly understand the basics and get a footing on their Fusion Applications projects. The references and links provided can be used to get more detailed information.
All site content is the property of Oracle Corp. Redistribution not allowed without written permission