Oracle Fusion Applications is the next generation enterprise application suite from Oracle Corporation. It is not a new version or a release of Oracle’s existing ERP products like E-Business Suite (EBS), PeopleSoft, JD Edwards, or Siebel. It’s an entirely new suite of applications built from the ground up using open standards encompassing a large number of Oracle components as well as many third-party open source products. Oracle started developing Oracle Fusion Applications in early 2005 and the first release was generally available in late 2011. The adoption of Oracle Fusion Applications is steadily increasing, especially with recent releases. The current release as of the writing of this book is 11.1.9 (Oracle Fusion Applications 11g, Release 9).
There is considerable documentation available on Oracle’s web site as well as a few blogs, but the purpose of this book is to provide a consolidated handbook for Oracle Fusion Applications enthusiasts using a simple step-by-step practical approach on the architecture, installation, and day-to-day administration. Since its architecture is fairly complex with a number of technology components involved, it is possible for someone new to Oracle Fusion Applications to feel overwhelmed during the course of learning. But rest assured that once you understand the basic foundation of Oracle Fusion Applications, you will feel confident about your role in implementing and managing Fusion Applications in your organization. The goal of this chapter is to make sure that you have a clear understanding of architectural components even though you may not be an expert in every aspect of the overall design of Fusion Applications.
Overview of Oracle Fusion Applications
It may be a natural question to ask why Oracle needed to build a completely new ERP applications suite from scratch when it already has proven ERP products like Oracle E-Business Suite, PeopleSoft, JD Edwards, Siebel, and so on. What has changed recently that created a need for an all-new set of enterprise applications products? The answer is simple; the technologies used in existing ERP products are becoming outdated and customers’ requirements are becoming more and more business- and processes-centric instead of being confined to vendor-specific technologies. With the growth of heterogeneous systems there was a need for building an enterprise applications suite that’s built on open standards and uses a service-oriented architecture to allow integration with a vast number of applications and systems.
With the acquisition of PeopleSoft and Siebel, Oracle had access to a large number of new customers. Oracle spent thousands of days working closely with customers and understanding what they needed from the next generation ERP system. Oracle Fusion Applications leverages the best functionalities and processes of E-Business Suite, PeopleSoft, JD Edwards, Siebel, and other Oracle products. The result is a 100% open standard-based applications suite that’s future ready.
What’s New in Oracle Fusion Applications?
Those who have already worked on other Applications suites, including the Oracle E-Business Suite, must have this common question. What’s new in Oracle Fusion Applications and why should I migrate? In this section, we will look at the strategic features of Oracle Fusion Applications that make it unique and the right choice for the future. Oracle Fusion Applications can be distinguished by the following major new changes that it brings to existing application suites.
Deployment Options
Most of the traditional applications suites have on-premise deployment option only, while a few non-Oracle ERP or CRM products have cloud-only options available. Oracle Fusion Applications provides various deployment options based on customers’ requirement and policies. Following are the deployment options available with Oracle Fusion Applications.
On-Premise: So far this was the standard deployment strategy for current generation Oracle applications suites, including E-Business Suite, Siebel, and so on. The major differentiator here is the complexity and heavy footprint of the Oracle Fusion Applications environment. Depending on the availability of hardware and resources, this strategy provides maximum control over infrastructure and security. The standard licensing terms apply in this option.
Private Cloud: Provides an intermediate solution between complete control and security of an on-premise setup and the flexibility of a public cloud. Organizations that are not yet prepared to move their transaction data outside their firewall but would like to leverage the benefits of the cloud can opt for private cloud setup, which can be managed by their own team or by a third party. Since the applications are specific to the organization, the customer needs to procure licenses instead of using a user-based subscription.
Public Cloud/SaaS: Oracle has introduced Fusion Applications in a cloud or SaaS (Software as a Service) model on a subscription basis. The complete application infrastructure is managed by the Oracle or SaaS provider and the customer has only its data on a shared infrastructure. This provides a faster go live option but with less control over the infrastructure.
Hybrid: Some organizations opt for a mix of these options for different application families and gradually plan to migrate to either deployment option depending on their confidence level with a particular deployment option.
Take a look at which factors influence the selection of a particular deployment strategy. Figure 1-1 provides the basic idea of the decision-making process. There may be other factors also, but these are primary ones.
Figure 1-1. Decision-making process for Oracle Fusion Applications deployment strategy
Standard-Based Architecture
Enterprises can no longer afford to be tied up with proprietary standards of application suites built more than a decade ago. Oracle Fusion Applications has been built using open standards and service-oriented architecture to make sure that it integrates seamlessly with existing business applications. It also facilitates the migration to Oracle Fusion Applications or coexistence along with existing application modules.
Oracle Fusion Applications has Oracle Fusion Middleware at its foundation. We will discuss the components of Oracle Fusion Middleware later in this chapter. The reason behind opting for open standards is not surprising. With an increasing number of applications products, organizations need a number of resources to manage proprietary methods. Having open standards such as Java, XML (Extensible Markup Language), BPEL (Business Process Execution Language), and service-oriented architectures makes it easy to find talent for UI, metadata, workflows, and web services development. This also reduces the integration cost and time to implement or extend the features.
Business Process Model
Oracle has reengineered the design of the application suite by focusing on the Business Process Model. Oracle has consolidated the best practices from E-Business Suite, Siebel, PeopleSoft, and JD Edwards applications and from customers’ processes into the design of Oracle Fusion Applications. The Business Process Model classifies each task into five levels. The last level in the hierarchy defines the actual function or task while the remaining four levels map to the Business Process or activity.
Level 0 (L0): Industry
Level 1 (L1): Business Process Area
Level 2 (L2): Business Process
Level 3 (L3): Activity
Level 4 (L4): Task
Oracle Fusion Applications Security Model
Oracle Fusion Applications comes with built-in security standards and features. There are several seeded roles and policies that cover most of the business needs. You can always modify or extend the security policies based on security requirements of the organization. Following are the key features of Oracle Fusion Applications Security Model.
Role Based Access Control (RBAC): Any access to Oracle Fusion Applications system resources is granted only through defined roles instead of direct access to individual users. The roles are grouped based on functional security, which gives the users access to specific functionality, and data security, which specifies access to specific dimensions of data within the same function.
Segregation of Duties (SoD): Oracle Fusion Applications applies segregation of duties policies across all roles and complies with the requirements of Sarbanes-Oxley Act (SOX) guidelines to limit the access to unauthorized use of application functions and data.
Functional and Data Security: By default, access to the application functions and data is disabled for all users. So unless the functional or data security roles are granted explicitly, users cannot access the data or system resources.
Functional security provides implicit access to data depending on the functions to which access is granted. It is mainly achieved through the following roles.
Duty Roles: Duty roles are the groups of tasks or functions that are duties of a particular job. Duty Roles are assigned to Job Roles or Abstract Roles instead of directly to users to make sure that minimum effort is needed to extend or change duties of a particular job within an organization.
Job Roles: Job Roles are collections of related Duty Roles. These roles are assigned to the users based on their job profiles and access to only those functions will be available to the grantee.
Abstract Roles: Abstract Roles are used to group users based on non-functional grouping, for example, employees, managers, approvers, and so on. Abstract Roles are also directly assigned to users, similar to Job Roles.
Data security provides explicit access to data. It is achieved through data roles, which provide access to specific subset of data within the given functional role.
Adoption Options
Oracle provides several adoption models for Oracle Fusion Applications.
Migrate to Oracle Fusion Applications: It may be much easier for new ERP adopters to move directly to Oracle Fusion Applications, as it may not involve migration risks. For organizations with existing applications suites, if all the current modules are covered in Oracle Fusion Applications suite, they can plan moving to the next generation applications, as the confidence around Oracle Fusion Applications is increasing steadily.
Coexistence with existing applications: Due to its service-oriented architecture, we can implement some Oracle Fusion Applications modules along with existing applications modules and expose the new functionalities through web services and business events. There are also many coexistence modules readily available as part of Oracle Fusion Applications in HCM, Financials, Supply Chain, and CRM product families. They can be used out-of-the-box without need for manually creating integrations.
Upgrade existing applications to the latest releases to prepare for future adoption: If the other two options are not viable at the moment, it is important that you upgrade existing E-Business Suites or other applications to their latest releases. Oracle is moving its E-Business Suite Applications toward Oracle Fusion Middleware foundation since release 12.2. In the future, the architecture would be very similar to Oracle Fusion Applications, which may also provide simpler migration in the future.
Oracle Fusion Applications Product Families
Oracle Fusion Applications includes more than 100 individual modules or products that are grouped into product offerings based on their functionalities and features. At the time of planning for licensing, you need to select the required product offerings that need to be licensed.
Oracle Fusion Applications 11g Release 9 includes the following product families.
Oracle Fusion Financials
Oracle Fusion Human Capital Management
Oracle Fusion Customer Relationship Management
Oracle Fusion Procurement
Oracle Fusion Project Portfolio Management
Oracle Fusion Supply Chain Management
Oracle Fusion Setup
Oracle Fusion Governance, Risk and Compliance
Note
Although Oracle Fusion Governance, Risk and Compliance is part of the Oracle Fusion Applications suite, it is not included in an Oracle Fusion Applications standard installation. You can download the “Oracle Governance, Risk and Compliance” product from Oracle’s software delivery cloud.
The Oracle Fusion Setup family is installed and configured by default regardless of which product family or product offering was selected. Oracle Fusion Setup contains the common functionalities of Oracle Fusion Applications, including the user dashboard, Help pages, and the Oracle Fusion Functional Setup Manager. We will discuss the Oracle Fusion Functional Setup Manager in detail in later chapters.
Figure 1-2 provides summary information on the available product offerings within each product family.
Figure 1-2. Oracle Fusion Applications product families and product offerings
Fusion Applications Architecture
Oracle Fusion Applications has a very complex architecture involving a large number of technology components hosted on each node. Because of this, it requires members from various teams to be involved in the implementation and management of an Oracle Fusion Applications environment. Figure 1-3 shows a high-level look at the major components involved in an Oracle Fusion Applications logical architecture. We will discuss these components in detail later in this chapter.
Figure 1-3. Architecture of Oracle Fusion Applications
Before going into the details of every component of the complete environment, let’s consider a high-level overview of an Oracle Fusion Applications instance. We will start with a macro-level diagram and then look at each high-level component along with the sub-components and technologies involved.
Overall Technical Architecture
We can describe an Oracle Fusion Applications instance in a very simple high-level diagram, as shown in Figure 1-4. This diagram shows three major tiers, namely Oracle Identity and Access Management node(s), Oracle Fusion Applications node(s), and Database node(s). Each of these tiers uses standard Oracle technologies and other open source components. We will discuss each component in detail later in this chapter. You can refer to Oracle’s licensing notes to see the list of third-party components used in Oracle Fusion Applications.
Figure 1-4. High-level view of an Oracle Fusion Applications instance
Since Oracle Fusion Applications is more complicated than the simplified architecture shown in Figure 1-4, we will discuss the architecture by going a level deeper step-by-step so that by the end of this chapter you will have a fairly clear idea of what an Oracle Fusion Applications instance looks like.
Understanding a Typical Oracle WebLogic Server Domain
Since Oracle Fusion Middleware forms the foundation of Oracle Fusion Applications architecture, it is very important to have someone in the implementation team with strong Fusion Middleware skills and strong WebLogic Server administration skills. For the purpose of provisioning an Oracle Fusion Applications instance, you need to first understand the architecture of an Oracle WebLogic Server domain.
Figure 1-5 shows the architecture of a typical Oracle WebLogic domain.
Figure 1-5. Components of a typical Oracle Fusion Applications WebLogic domain
Each WebLogic domain has one active administration server regardless of the number of hosts used in the Oracle WebLogic domain. There are several Oracle managed servers in an Oracle WebLogic Sever domain. The actual application functionality is generally deployed in the form of EAR (Enterprise ARchive) files to one of the managed servers. If more than one server hosts the same functionality then you can host multiple instances of the same managed servers in a WebLogic Server cluster. Each cluster hosts multiple instances of the same managed server to provide high availability and scalability for the required functionality.
The role of administration server is to configure and manage the WebLogic managed servers in the domain. The status of administration server does not impact the actual functionality of the managed server; however, it allows centralized control and management of all WebLogic Servers in the domain across multiple nodes. The Oracle WebLogic environment also includes a component called Node Manager, which monitors and controls the status of all WebLogic servers, including the administration server as well as WebLogic managed servers.
Oracle WebLogic server provides management interfaces in the form of Administration Console and Oracle Fusion Middleware Enterprise Control. In the case of Oracle Fusion Applications, each product family domain can be managed by the Oracle Enterprise Manager Fusion Applications Control (commonly referred as the Oracle Fusion Applications Control). You can also install and configure Oracle Enterprise Manager Cloud Control to manage every component in your Oracle Fusion Applications infrastructure. In fact, Cloud Control is the recommended interface to manage Fusion Applications instances. More details on these components will follow in later chapters, where we will discuss Oracle Fusion Applications administration.
Oracle Identity Management Infrastructure
Now coming back to the Oracle Fusion Applications architecture, let’s further drill down the components in each of the tiers shown earlier in Figure 1-4. Let’s take a look at Oracle Identity and Access Management infrastructure first. Oracle Fusion Applications requires Oracle Identity Management components to provide authentication and authorization as well as Single Sign-On (SSO) functionality. It uses the Oracle Internet Directory (OID) as identity and policy stores.
Let’s look at the major components that constitute the Oracle Identity Management infrastructure, as shown in Figure 1-6.
Figure 1-6. Components of the Oracle Identity Management tier
We can see the major components of Oracle Identity Management infrastructure in three different tiers adhering to Enterprise Deployment Architecture.
Oracle Identity Management Web Tier: Oracle Identity Management Web Tier includes the Oracle HTTP server, which provides a web listener to handle all web requests to Oracle Identity Management infrastructure. This tier also includes WebGate, which intercepts the HTTP requests and forwards the requests for protected URLs to Oracle Access Manager for authentication and authorization. Earlier versions of Oracle Fusion Applications (prior to 11.1.7) required manual installation of the Oracle HTTP server for Identity Management, but with Oracle Fusion Applications release 11.1.7 onward, it is automatically installed and configured as part of the Identity Management provisioning process. We will look at this process in detail in Chapter 3.
Oracle Identity and Access Management Application Tier: Components of Oracle Identity Management tier are hosted on one or more servers. Following are the components of Oracle Identity Management. We will discuss each of these components in the following sections.
Oracle Identity Manager (OIM)
Oracle Access Manager (OAM)
Oracle Directory Services Manager (ODSM)
Oracle Virtual Directory (OVD)
Oracle Internet Directory (OID)
Oracle SOA Suite (SOA)
Oracle Identity Federation (OIF) (optional)
The components OIM, OAM, ODSM, and so on, are installed and configured as part of the Oracle Identity Management (IDM) WebLogic domain. This tier also has Oracle Internet Directory and optionally Oracle Virtual Directory, which provide identity and policy stores for the Oracle Identity Management and Oracle Fusion Applications. We will look at these components in the next section, where we discuss all technical components involved in a complete Oracle Fusion Applications environment.
Oracle Identity Management Database Tier: Oracle Identity Management database schemas are stored in the IDM database. The database schemas are seeded using the Oracle Identity Management Repository Creation utility. This is covered in Chapter 4.
Oracle Fusion Applications Infrastructure
After having a look at the Oracle Identity Management infrastructure, you’ll now see how an instance of Oracle Fusion Applications looks once it’s installed and configured. Once again we consider a multi-tier enterprise deployment to understand which technical components are located on which tier.
Figure 1-7 shows some of the major components you will see in an installed Oracle Fusion Applications instance and you may need to focus on managing these services while administering an Oracle Fusion Applications instance.
Figure 1-7. Major components of Oracle Fusion Applications tier
In an enterprise deployment of Oracle Fusion Applications, we can divide the major components of Oracle Fusion Applications infrastructure in three different tiers, similar to those of the Oracle Identity Management infrastructure. We have already discussed the product families, product offerings, and individual Oracle Fusion Applications products in an earlier section. In this section, we will discuss the common technical components in each tier of Oracle Fusion Applications and how the modules are deployed in the product WebLogic domains.
Oracle Fusion Applications Web Tier: Similar to Oracle Identity Management, Oracle Fusion Applications Web Tier also includes an instance of Oracle HTTP Server and WebGate, which forward the HTTP requests for any protected resources to OAM. Since the first release of Oracle Fusion Applications provisioning framework includes the Oracle Fusion Applications Web Tier, it automatically is installed and configured during the Oracle Fusion Applications provisioning process. Depending on the topology selected, the Web Tier could be hosted internally or in DMZ. We will discuss multiple topology options in the next chapter.
Oracle Fusion Applications Tier: Oracle Fusion Applications Tier mainly consists of individual Oracle WebLogic domains for each product family. Each domain has a dedicated admin server and a set of Oracle WebLogic clusters. Each cluster hosts a WebLogic managed server where the Oracle Fusion Applications products are deployed. There are two types of managed servers hosted in Oracle Fusion Applications WebLogic domains, depending on the deployments.
Application Managed Servers: These managed servers host one or more Oracle Fusion Applications product modules. They provide the actual functionality of the Oracle Fusion Applications products.
Middleware Managed Servers: Each product domain contains one or more Fusion Middleware managed servers, for example SOA, Enterprise Scheduler, Secure Search, Oracle Data Integrator, and so on to provide essential middleware services to the product family.
Apart from Oracle WebLogic Server Domains, Oracle Fusion Applications Tier also contains an instance of Oracle Business Intelligence Suite. If we have selected any product offerings of Oracle Fusion Customer Relationship Management then Informatica Identity Resolution (IIR) components are also installed.
Oracle Fusion Applications Database Tier: Oracle Fusion Applications Transaction Database Schemas are stored in a dedicated database for Oracle Fusion Applications. The database could be single node or a RAC (Real Application Clusters) database, depending on selection of topology. The initial database tablespaces and schema are created using Fusion Applications Repository Creation utility before the provisioning process. We will cover this in Chapter 8.
Let’s now have a look at an example Oracle Fusion Applications family domain to understand how the multiple WebLogic clusters and managed servers are hosted in a domain. Figure 1-8 uses HCMDomain (Oracle Fusion Human Capital Management domain) as an example to show how the applications are deployed in a typical Oracle Fusion Applications WebLogic domain.
Figure 1-8. Oracle WebLogic domain for Oracle Fusion HCM product family
You may notice that each managed server has at least one primary application deployed in it, which will allow the managed server to serve that specific product functionality related requests. Many applications have their functionalities covered by more than one managed server, but for the purpose of clarity, the diagram in Figure 1-8 shows only the primary application deployed on each managed server.
As you can see in the diagram in Figure 1-8, there are a number of managed servers in HCMDomain in addition to the administration server. The managed servers are classified as Application Managed Servers and Middleware Managed Servers. The administration server is not shown in this diagram, but each product domain has an exclusive administration server as well. For each node of Oracle Fusion Applications, you can also see a Node Manager component. It is not shown in Figure 1-8 since it is common across multiple product domains.
Each managed server is part of a WebLogic cluster; for example HCMAnalyticsServer_1 is a member of HCMAnalyticsCluster on the respective node. By default, the installation wizard of Oracle Fusion Applications ensures that each product cluster has a single instance only but if you want to achieve high availability for Oracle Fusion Applications WebLogic domains, you can scale out by adding a new managed server in the same WebLogic product cluster.
The applications deployed in the product managed servers provide the actual functionality of Oracle Fusion Applications. As mentioned earlier, these applications are deployed in the form of EAR (Enterprise ARchive) files, which encapsulate all the required J2EE, XML, and web archive packages into a single file. The functionalities of a particular product could span across multiple deployed applications and a single deployment can include functionalities from multiple products.
Figure 1-9 shows only a portion of the products versus deployed applications mapping for Oracle Fusion HCM domain. As you can see, HcmCoreSetupApp includes functions of multiple products. Global Payroll functionalities span across in HcmPayrollApp and HcmCoreSetupApp.
Figure 1-9. Mapping of Oracle Fusion Applications products and deployed applications
Key Technology Stack Components
As mentioned earlier, an Oracle Fusion Applications instance contains a variety of Oracle and third-party products, all of which are based on open standards. In order to understand the key technical components involved in Oracle Fusion Applications, let’s go back and have a look at Figure 1-3. We have already discussed Oracle Fusion Applications product families in a previous section. These product families use Oracle Fusion Middleware infrastructure and framework components for Oracle Fusion Applications.
Oracle Fusion Middleware Components
We have discussed the Fusion Middleware infrastructure components used in Oracle Fusion Applications Product domains. Now let’s look at the common Oracle Fusion Middleware components that make up the Oracle Fusion Applications infrastructure.
Oracle Identity and Access Management
Oracle Fusion Applications uses Oracle Identity and Access Management components for user authentication and authorization policies. These components are prerequisites for Oracle Fusion Applications provisioning, so they must be installed and configured prior to installing Oracle Fusion Applications.
Oracle Internet Directory (OID): The identity and policy repository for the Oracle Fusion Applications environment. Although Oracle Fusion Applications supports other LDAP directories for identity store, this is the only supported directory for policy store. So OID must be installed as a prerequisite.
Oracle Virtual Directory (OVD): An optional component of Oracle Identity Management that can handle LDAP requests for multiple directory sources and provide a single view of directories. Although it is an optional component in standard Oracle Identity Management installation, the IDM provisioning wizard included from Oracle Fusion Applications 11g Release 7 (11.1.7) onward configures and enables OVD by default.
Oracle Identity Manager (OIM): Provides the self-service management interface to manage user accounts and roles. It periodically runs reconcile jobs to retrieve the latest changes from OID.
Oracle Access Manager (OAM): Responsible for managing Authentication and Authorization policies. It provides Single Sign-On functionality based on the seeded policies and created through self-service user interface.
Oracle Identity Federation (OIF): Another optional component that can provide Single Sign-On functionality in a multiple-directory environment. It is installed by the Oracle Identity Management provisioning process but remains disabled by default. It can be enabled and configured if required.
Oracle Directory Service Manager (ODSM): Provides a graphical interface to manage any OID or OVD instances. This eliminates the need to use command-line tools for various operations.
Oracle SOA Suite
Since Oracle Fusion Applications is built on service-oriented architecture, the Oracle SOA suite plays a crucial role and is at the heart of Oracle Fusion Applications. The SOA suite provides infrastructure components required for orchestrating, deploying, and managing services into SOA composite applications and business processes.
Oracle WebLogic Server
Oracle WebLogic Server is the application server used in Oracle Fusion Applications and Oracle Identity Management. It is based on Java Enterprise Edition, and it’s secure and scalable, based on enterprise requirements.
Oracle HTTP Server
Oracle HTTP Server is based on Apache HTTP server technology with more features. It provides the web listener to the deployed applications. It can host web pages locally as well as provide redirection to WebLogic server handlers based on user-defined rules.
WegGate
WebGate is a web server plugin that acts between the HTTP server and Oracle Access Manager. It intercepts user requests received by the HTTP server and checks with OAM for access validation.
Oracle Application Development Framework (ADF)
ADF is the next-generation framework based on Java Enterprise Edition and open source technologies. It allows rapid application development based on metadata, design patterns, and graphical tools to create service-oriented applications.
Oracle Business Intelligence
Oracle Business Intelligence is the default reporting and analytics solution integrated into Oracle Fusion Applications. It replaces earlier traditional methods of manually reporting by giving complete control of the analytics to users right in the application dashboard.
Oracle WebCenter
The Oracle WebCenter suite is the integrated suite of Oracle Fusion Middleware to create web sites, dynamic pages, and portals using service-oriented architecture. Even Oracle E-Business Suite R12.2 uses Oracle Fusion Middleware for applications deployment certified with WebCenter. Oracle WebCenter is staged to replace Oracle Portal so we can see the technological synergy between EBS and Oracle Fusion Applications.
Oracle Data Integrator (ODI)
Oracle Data Integrator facilitates high-performance data load, data extract, batch processing, and SOA data events for Oracle Fusion Applications product families.
Oracle Fusion Middleware Infrastructure Components
Each Oracle Fusion Applications product family uses the following core components to provide core UI functionality, scheduling services, and Enterprise search functionality.
Middleware Extensions for Applications (Applications Core)
These components mainly include the following extensions.
UI Shells: Provide the common user interface to all Oracle Fusion Applications products. Page templates include consistent common layouts that support tasks and user-based screen elements. We will discuss common user interfaces in Chapter 11.
Flexfields: Provide extensibility features by allowing you to create dynamic custom attributes on the UI.
Trees: Allow you to create a multi-level hierarchy to organize the content in tree-based menus. Business rules control the tree structure and application performance can be improved by using collapsible and expandable roll-up queries to display data faster due to row-based or column-based flattening.
Attachments: Provide a mechanism for adding a file, text, or URL to be added to UI pages.
Oracle Enterprise Scheduler
Those familiar with Oracle E-Business Suite can understand Oracle Enterprise Scheduler as a replacement of Concurrent Manager but with more features. The role of Oracle Enterprise Scheduler is to define, schedule, run, and monitor different type of jobs, business intelligence reports, and programs. Similar to Concurrent Manager in E-Business suite, it can run a program on demand or on a predefined schedule and control the complete lifecycle of a job. Having the Enterprise Scheduler Service (ESS) with every product family allows you to give dedicated control of related jobs to the same product family.
Oracle Enterprise Crawl and Search Framework
Oracle Enterprise Crawl and Search Framework (ECSF) is a metadata-driven component that provides foundation to Oracle Secure Enterprise Search (SES). It allows seamless search functionality in every Oracle Fusion Applications product with full transactional search.
Oracle Database
Oracle Database must be installed and configured before installing Oracle Identity Management or Oracle Fusion Applications. Oracle Fusion Applications does not support any other database. The databases for Identity Management and Fusion Applications contain database schemas for Oracle Identity Management and Oracle Fusion Applications, respectively. The initial database repository is created using the repository creation utility prior to installing Oracle Fusion Applications.
Fusion Applications Interaction with Identity Management
As we know now, Oracle Identity Management provides the infrastructure for Single Sign-On and manages the user identity and policy information for authentication and authorization. In this section, we will see how these components fit together in real-world scenarios.
Figure 1-10 provides a bird’s eye view of the interaction between Fusion Applications and Identity Management components. Please note that this is only a subset of the integration to give you an idea how the components talk to each other.
Figure 1-10. Interaction example betweeen Fusion Applications and Identity Management
Oracle Fusion Applications contacts Oracle Access Manager for any SSO requests that further access Oracle Internet Directory for user authentication. Similarly, the Fusion Applications user provisioning or self-service functions such as Forgot Password interact with Oracle Identity Manager, which uses the Oracle virtual directory to communicate with OID and to reconcile users/roles.
Figure 1-11 shows a typical flow of events when a page request is made from a user through an Oracle Fusion Applications interface. You can see that it involves multiple technology components in Oracle Identity Management and Fusion Applications hosts.
Figure 1-11. Typical flow of events during a user request for an Oracle Fusion Applications page
1. The user types a URL in the browser. Consider an example of a login page. The format of the homepage URL is as follows:
https://<Web_Server_or_Load_Balancer>:<port>/homePage
For example, https://fahost.paramlabs.com:10634/homePage .
2. The request is received by the Oracle Fusion Applications Web Tier and the WebGate checks with OAM as to whether the requested page is protected. If the page is not protected as per OAM policy, it redirects the request to the corresponding WebLogic domain based on the HTTP virtual host configuration of the WebLogic handler. The respective managed server prepares the page and serves it back to the user. If the requested page is a protected resource as per OAM policy, it proceeds to further processing as follows.
3. In this example, since homePage internally redirects to the adfAuthentication page, which is a protected resource, WebGate checks whether there is an existing session for the same user. If there is an existing session, it skips to Step 7. In this example, since the user is accessing the login page for first time, WebGate does not find an existing session, so it proceeds to further processing as follows.
4. In absence of an existing session, Oracle Fusion Applications node WebGate redirects the page to the Oracle Access Manager (OAM) login page. This page request is received by Oracle Identity Management node WebGate and it passes this login page to the IDM node HTTP server. The HTTP server checks the virtual host configuration and passes the request to the OAM server, which prepares the page. The page is now delivered to the user’s browser.
5. Users can now see the OAM login page in the browser. The users enter a username and password and submit the login page.
6. OAM receives the credentials passed by the user and validates the same. If the credentials are incorrect, it sends the page back to the user with a login error. Once the login is validated, OAM sends the access token along with an OAMAuthnCookie value in the URL to WebGate on the Fusion Applications web server.
7. At this point, the login is validated and a session has been established. The next step is to check if the user has the permissions to access the requested page. If the user is not authorized to access the requested protected page, it sends the page forbidden error page to the user. This can when a user tries to manually type a URL that he is not authorized to access in an existing or new session.
8. Once the user’s authorization to the requested page is validated, it checks the virtual host configuration of the Fusion Applications web server for the requested URL. Depending on the WebLogic handler rule for the specific URL or part of the URL, it passes the request to the appropriate WebLogic domain. The corresponding managed server for the WebLogic domain processes the request and prepares the page content.
9. Once the page is prepared, it is sent to the user’s browser.
This concludes the introduction of Oracle Fusion Applications. You are ready to move on to planning an Oracle Fusion Applications installation.
Summary
By now you should have a fair understanding of what an Oracle Fusion Applications environment looks like along with the architectural components involved. We know the synergy between Oracle Fusion Applications and existing applications suites and how Oracle Fusion Applications utilizes the best processes and practices from existing application suites using a service-oriented architecture.
The next chapter looks at how to plan for an optimal installation of Oracle Fusion Applications. We will look at various topology options and discuss how to choose the best option. We will also look at individual roles and responsibilities in the planning and implementation processes.