Introduction to Oracle E-Business Suite

Oracle E-Business Suite, also known as Oracle Applications or Oracle EBS, is sophisticated software that works like a software system, which as a whole supplies the enterprise resource planning (ERP), customer relationship management (CRM), and supply chain planning application families. It is a software system that consists of global business applications with built-in integrity.

E-Business Suite is a product of Oracle Corporation and was created in late 1980s. The first name of the product was Oracle Financials. After Oracle Financials, the product name changed to Oracle Applications; the next release was called Oracle Application Release 1, introduced in August 1987. Following Oracle Application Release 1, Oracle released its first ERP application called Accounting System in 1988; this application was considered Release 2. After that, the release numbers increased linearly. Oracle continued to enhance the product over the years, and at the time of writing this article, the latest release version is 12.2.5.

Recent Oracle EBS software versions consist of three or four digits. Versions such as 11.5.10.2, 12.1.3, 12.2.3, 12.2.4, and 12.2.5 are all examples of the EBS software versions used by organizations today. The first digit is the release number, so versions starting with 11 imply Release 11, which is called 11i. Likewise, versions starting with 12 imply Release 12.

Although release numbers describe the general capabilities of the application, there are some exceptions. For example, version 11.5.10.2 is the latest version for the former release EBS 11i (referred to as Release 11), but it is much more enhanced than other 11i releases. The situation is the same for EBS 12.2. EBS 12.2 actually has a different technology and architectural design compared to earlier releases. It is really different, and in our perspective, this enhanced new-generation EBS 12.2 is not Release 12 anymore. The enhancements, changes in the technology components, new administration methods, utilities, and innovations in EBS 12.2 are so exciting that they’re the reason we’re writing this blog.

There are several applications in E-Business Suite’s application families. We will introduce these applications in the forthcoming sections.

EBS can be called a software systembecause it is software as a whole and includes its own database, application server, and software running on top of this stack. By using the cross-industry capabilities of EBS, organizations can make decisions in a better, faster, reliable, and more cost-efficient way. Some of the business applications are already in EBS, and some of the applications are separate but tightly integrated with it. We describe the applications in EBS in the following sections.

Note

Some of the EBS applications in the application families covered next are actually solutions, so they have no short product codes. They are considered as extensions to the other applications and are created by using the capabilities of other EBS applications. These solutions, as we call them, may contain more than one product across different EBS modules. They can be enabled by performing some of the setup with the dependent Oracle E-Business applications and some of the setup within the solutions themselves.

CRM Applications Family

The applications and solutions delivered within the CRM applications family provide strong customer relationship management features inside EBS.

• Oracle Channel Revenue Management: This supplies consistent, accurate information and advanced tools for managing revenues of both direct and in-direct channels. Oracle Channel Revenue Management contains the Accounts Receivable Deductions Settlement, Channel Rebates and Point-of-Sale Management, Partner Management, Price Protection, and Supplier Ship and Debit products.
• Oracle Marketing: This supplies a robust environment for managing marketing information and processes.
• Oracle Order Management: This supplies a platform for driving the order fulfillment process of any business.
• Oracle Service: This supplies customer service based on true information.

Service Management Family

The applications and solutions delivered within the service management family provide information-driven customer service features inside EBS.

• Advanced Inbound Telephony: This enables telephony integration to all major telephone systems. It is part of the product family named Oracle Interaction Center, which consists of the Advanced Inbound Telephony, Advanced Outbound Telephony, Email Center, and Scripting applications.
• Advanced Outbound Telephony: This supplies tools such as list management and predictive dialing for executing outbound calling campaigns.
• Advanced Scheduler: This supplies productive and cost-effective scheduling for field service reps.
• Depot Repair: This supplies the ability for automating the in-house repair processes.
• Email Center: This is an e-mail response management system for managing the high volume of incoming messages.
• Field Service: This supplies the ability for automating the dispatching processes in field services, which is required for servicing the service calls in remote locations.
• Interaction Center: This provides an interaction center for integrating the customer interaction channels.
• iSupport: This provides a secure, self-service web portal for enabling the self-service functionality to both customer and employees.
• Mobile Field Service: This makes the information accessible to the agents via both handheld and laptop devices. This application is part of the Oracle Service application.
• Scripting: This provides scripting and survey capabilities.
• Service Contracts: This provides contract management and a centralized repository for entitlement information.
• Spares Management: This provides logistics and planning for selecting and delivering the spare parts to field locations.
• Tele Service: This supplies the ability for automating the resolutions by using the integrated CRM applications. This application is part of the Oracle Service application.

Financial Management Family

The applications and solutions delivered within the financial management family are the financial applications for increasing the efficiency and reducing the costs of all the financial processes.

• Cash and Treasury Management: This provides management for treasury operations. This application includes the Cash Management (CE) and Treasury (XTR) applications.
• Asset Lifecycle Management: This provides an effective environment for managing the assets of the organization. This solution consists of Enterprise Asset Management, Self-Service Work Requests, Asset Tracking, and Property Manager.
• Credit-To-Cash: This provides customer data management, credit decision making, standard invoicing/billing and electronic bill presentment, revenue recognition, cash receipt, cash application, collections, audit and financials compliance, and reporting. Credit-To-Cash is a solution for managing credit, collections, and receivables for the Advanced Collections, Oracle Financial Analytics, iReceivables, Loans (LNS), Credit Management, Financials Centralized Solution Set, Payments (IBY), Receivables (AR), and Accounts Receivables Deductions Settlement applications.
• Financial Control and Reporting: This provides financial control for creating and managing the transactions and provides the ability for reporting the results. This solution works with the Oracle Financial Analytics, Oracle Hyperion Financial Management, Financials Accounting Hub, Governance, Risk and Compliance Management, and Oracle Financials (General Ledger and Financials Centralized Solution Set) applications.
• Financial Analytics: This provides business intelligence in the financial area. This application is an Oracle Business Intelligence (OBIEE) application that gets its data from EBS. So, it is used with EBS financial applications to bring the business intelligence into the EBS environments.
• Governance, Risk, and Compliance: This provides enterprise risk management, compliance, and controls enforcement. Governance, Risk, and Compliance (GRC) includes applications such as Advanced Controls for E-Business Suite, Application Access Controls Governor, Application Access Controls for E-Business Suite, Configuration Controls Governor, Configuration Controls for E-Business Suite, Transaction Controls Governor, and Preventive Controls Governor.
• Lease and Finance Management: This supplies the ability for automating lease and load portfolio.
• Procure-To-Pay: This supplies integration between purchasing and payables. This solution can be implemented with the following applications: Oracle Financial Analytics, Internet Expenses, iProcurement, iSupplier Portal, Landed Cost Management, Oracle Financials, Payables, Payments, Procurement Contracts, Projects, Purchasing, Services Procurement, Sourcing, and Supplier Network.
• Travel and Expense Management: This provides an automated and simplified travel and expense management solution. This solution can be implemented using the included applications: Oracle Financial Analytics, Internet Expenses, Oracle Financials, Payables, and Payments.

Human Capital Management Family

The human capital management family delivers business applications and solutions for constructing a global and sophisticated human resource environment to increase productivity, manage labor, increase the motivation of employees, analyze the workforce efficiency, and reduce the costs of service delivery. The processes of these applications also comply with local laws and regulations. The main application in this family is called Human Resources .

• Global Core Human Capital Management: This solution delivers a complete, worldwide HR management system, which includes these applications: Human Resources, Self-Service Human Resources, Advanced Benefits, Compensation Workbench, iRecruitment, Payroll, Performance Management, Time and Labor, and Succession Planning.
• Workforce Management: This provides a detailed workforce management solution that addresses such needs as labor forecasting, schedule management, capturing the labor data, tracking the workforce, and adhering to labor laws and pay rules. It is a solution for managing the workforce using the HRMS applications and other EBS solutions such as Time and Labor, Advanced Scheduler, Project Resource Management, and Mobile Field Service.
• Talent Management: This is a tal ent management solution that provides talent management requirements such as planning, recruiting, performance, learning, career development, succession planning, compensation, talent reviews, and measuring and reporting. It is a solution for delivering talent management using the HRMS applications.
• HR Analytics: This provides business intelligence for analyzing workforce staffing and productivity. This application is an OBIEE application that gets its data from EBS. So, it is used with EBS HR applications to bring the business intelligence into the EBS environments.

Project Portfolio Management Family

The applications and solutions in the project portfolio management family provide project and portfolio management features including forecasting, budgeting for the profitability, resource assignments, and so on. The main application in this family is called Projects.

• Project Analytics: This provides business intelligence for analyzing important project data such as forecasts, budgets, cost, revenue, billing, and profitability. This application is an OBIEE application that gets its data from EBS. So, it is used with EBS to bring business intelligence into the EBS environments.
• Project Billing: This provides the ability to measure the profitability of contract projects, as well as simplified client invoicing and improved cash flow. It is an option to be implemented under the Project Costing solution of the Projects application.
• Project Contracts: This provides the ability to deliver complex, project-driven commercial and government contracts.
• Project Collaboration: This provides a platform for project members to collaborate and communicate. It is a solution to be implemented within the Projects application.
• Project Costing: This provides an integrated cost management solution for all projects and activities. It is a solution to be implemented within the Projects application.
• Project Management: This is a consolidated project management solution for planning the work, assigning the resources, forecasting the competition, and communicating with stakeholders.
• Project Resource Management: This fulfils a management need for the capacity and deployment of people and assets for project work. It is a solution to be implemented within the Projects application.
• Project Portfolio Analysis: This supplies the ability to analyze, prioritize, and choose the right set of projects.

Advanced Procurement Family

The applications and solutions in the advanced procurement management family are there to support the whole process for procurements.

• iSupplier Portal: This is an Internet-based portal that provides all the supplier communication. It is an option to be implemented within the Purchasing application.
• iProcurement: This is a self-service solution for controlling employee spending.
• Oracle Procurement and Spend Analytics: This offers business intelligence for procurement. This application is an OBIEE application that gets its data from EBS and is used with EBS to bring business intelligence into the EBS environments.
• Oracle Spend Classification: This supplies accurate categorization of past spending data. It is a component of Oracle iProcurement.
• Oracle Supplier Network: This is a secure online service that provides automated electronic document exchange with suppliers.
• Oracle Supplier Hub: This provides critical supplier information for quickly onboarding, evaluating, and managing suppliers.
• Landed Cost Management: This enables the financial visibility into the extended supply chain costs.
• Procurement Contracts: This is a solution that is part of the advanced procurement family and provides the ability to create and enforce better purchasing contracts.
• Purchasing: This delivers a modern purchase order processing for professional buyers. Purchasing includes optional solutions to be implemented with it, such as Sourcing, Sourcing Optimization, iSupplier Portal, Procurement Contracts, Services Procurement, and Advanced Pricing.
• Services Procurement: This is an EBS solution that provides control for the services spending.
• Supplier Lifecycle Management: This is an EBS solution that supplies the ability to streamline registration, review the potential suppliers, evaluate the cross-functional performance, assure effective governance, and mitigate risk.
• Oracle Contract Lifecycle Management for Public Sector: This is a solution that provides a procure-to-pay system with automated and auditable processes.

Supply Chain Management Family

The applications and solutions in the supply chain management family provide integrated supply chain processes for delivering complete and information-driven value chains.

• Advanced Procurement: This provides supply management applications and solutions for managing goods and services and procure-to-pay processes spending.
• Value Chain Execution: This is a solution for logistics needs. Value Chain Execution includes Transportation Management, Landed Cost Management, Warehouse Management, Global Trade Management, Mobile Supply Chain, and Inventory Management. The products for the value chain execution family are also considered EBS products, even though there are value chain execution applications such as Oracle Transportation Management, which is integrated with the EBS products but resides outside of the EBS environment.
• Order Orchestration and Fulfillment: This provides support for planning, configuration, pricing, and orchestration and fulfillment processes.
• Asset Lifecycle Management: This provides effective asset management. This solution consists of Enterprise Asset Management, Self-Service Work Requests, Asset Tracking, and Property Manager.
• Manufacturing: This provides a complete manufacturing solution with capabilities such as configure-to-order, project manufacturing, outsourcing, and quality management capabilities.
• Product Value Chain Management: This provides the ability to innovate, develop, and commercialize compliant products.
• Value Chain Planning: This provides demand-driven planning. It includes applications such as Advanced Planning Command Center, Advanced Supply Chain Planning, Collaborative Planning, Demand Management, Demand Signal Repository, Global Order Promising, Inventory Optimization, and more.
• Business Intelligence and Analytics: Business Intelligence for Oracle Supply Chain and Order Management: This application is an OBIEE application that gets its data from EBS.

As you can see, within Oracle EBS there are many application families and quite a few applications to support today’s business needs. This big and integrated application environment is modular in deployment, so it saves time and increases the efficiency for organizations.

Because the modules and supplementary system are tightly integrated, the solutions provided seem to be served from a single source. This of course is accomplished by the ultimate application design, high-level software engineering, and power within the Oracle technologies.

Exposing such an application ecosystem is a big job, but the duties of deploying, managing, troubleshooting, tuning, supporting, and maintenance are also important responsibilities. As you may imagine, all of these duties fall on the shoulders of the applications DBA; that’s why the job requires a high-level understanding of EBS-specific features as well as the underlying technologies.

The technology stack starts from the features in EBS and includes the Oracle data model stored in Oracle Database as a built-in data store for EBS. The separation of duties means applications DBAs can be focused on the EBS-specific technologies and leave the database administration to the core database administration. Still, we believe applications DBAs should know the core DBA activities and have the experience in those activities as well.

Understanding the architectural model of Oracle E-Business Suite is as important as knowing commands and which actions to take for administrating an Oracle E-Business Suite environment properly. Thus, it is better to start with understanding the Oracle E-Business Suite architectural model before going into further detail about the E-Business Suite components.

Understanding the Oracle E-Business Suite’s Three-Tier Architecture Model

The Oracle EBS architecture is based on multitier computing and consists of three tiers.

• In the desktop tier, you have PCs or any supported desktop clients that are able to run a browser, which provides the HMTL or HTML-based applications as well as a Java applet for opening Oracle Forms–based applications.
• The application tier consists of Fusion Middleware (FMW), web services, forms services, Java application services, and the concurrent processing server. This tier sits between the desktop and database tiers and drives the business logic. It is also referred to as the middle tier because it supplies the communication between the desktop and database tiers.
• The database tier sits in the back end; it consists of Oracle Database and its services for storing and managing all the data maintained by Oracle EBS.

Figure 1 shows the tree-tier model; it illustrates the technologies and tools that provide the related application services in each tier. You can see that the client interface is provided by the web browser and the Sun Java plug-in, the application services are provided by FMW and the concurrent processing server, and lastly the database tier is actually Oracle Database 11g R2 or 12c.

Figure 1. Tree-tier model presenting the EBS tree-tier architecture

So you have a better understanding of the three-tier architecture, we will go into the details of the each tier and explain the components specific to each tier. Let’s start with the desktop tier.

The desktop tier is about the browser, but we can’t say it is all about the browser because running the Forms Java applet is also an important role of desktop clients. When using EBS HTML pages, all of the processing is done by the web server of EBS, but when it comes to the forms pages/screens, the desktop client plays the big role. The forms screen works in the client by transferring the related JAR files from the network on the fly. So, whenever a client wants to open an EBS forms-based application, the relevant JAR files are transferred automatically from the server to the client machine and the client’s JVM, which can be considered to be a Java plug-in integrated into the browser; it executes the code inside these JAR files and displays the forms screen through an applet running on the client machine.

Forms are widely used within the applications of EBS, but there are some applications (such as self-service applications) that are processed through HTML-based pages and don’t require clients to open any forms screens.

Figure 2 shows a closer look at the process needed to establish a client’s form session and shows what is happening between the client tier and the application tier when a form session is created.

Figure 2. JAR fies supplied to clients

As shown in Figure 2, JAR files are supplied to the clients by the Fusion Middleware server. During the form execution, JAR files are obtained and executed by the client’s Sun J2SE plug-in enabled browser through a Java applet.

The purpose of the application tier is to serve HTTP, Java, forms, and concurrent processing services. The application tier can consist of multiple servers, which can be configured to run in a load balancing and failover manner. A load balancing and failover configuration can be used for web, forms, and concurrent processing services.

The application tier consists of Oracle HTTP Server, Oracle Application Server 10.1.2, Oracle Fusion Middleware, and concurrent processing services. Although all major services are started from the Fusion Middleware, using two application servers is a design choice. These four main technologies work together for supplying EBS services.

When serving HTML-based applications, Oracle HTTP Server provides the web listener for accepting the client requests and directs them to the WebLogic Server present in Fusion Middleware if needed. Oracle WebLogic Server supplies the Oracle Applications Framework and creates the database interaction through a servlet engine. That is, WebLogic validates the user access, obtains the metadata UI definition and relevant data for the page, creates the HTML, and sends the page to the browser.

When serving forms-based applications, EBS uses a forms listener servlet or traditionally a forms server in socket mode. Using servlet or socket mode is a matter of preference and also a requirement for using some features that are not available in socket mode, such as SSL. However, the form servlet is the latest technology in this area. It is more convenient for Internet connections because it offers more robustness and security and because it has the ability to reestablish dropped network connections and requires fewer ports. Oracle EBS 12.2 uses forms servlet by default, but configuring forms socket mode is also possible.

In forms servlet mode, the web listener triggers the forms listener servlet, which creates the forms runtime processes for each client and manages the communication between the client and its associated forms runtime process. The forms listener servlet also communicates with the Oracle database server using Oracle Net, but actual database work is done by the forms runtime process. So, you can consider the forms listener servlet as a bridge between the client, the forms runtime process, and the database. The communication from the client appears to be based on the HTTP responses through the web services. Besides, the forms servlet architecture is compatible with the application industry standards.

In forms socket mode, the client action data such as a clicking a button is passed to the associated form server, in which the UI interface logic runs. This communication is made using the TCP/IP network protocol , so desktop clients access the forms server directly. On the back end, the Oracle Forms runtime process makes the database interaction.

Apart from the applications based on the user interaction, which employs Oracle Fusion Middleware components and the Oracle Forms services, there are long-running batches and reporting and data updating programs inside an EBS environment. These programs may be run as scheduled or triggered from the web interfaces such as forms or HTML-based applications, but they run in the background and are handled by the concurrent processing server. The concurrent processing term is specific to Oracle EBS. The processing done here is actually the management of the back-end program executions. That is, the concurrent processing consists of program managers called concurrent managers, which run on their own operating system processes. These concurrent managers are programs for managing other programs called concurrent requests. Any type of program that is instructed to be executed by the concurrent manager is accepted to be a concurrent program, and its start, finish, termination, and scheduling are managed by its associated concurrent manager.

By default, there are a number of concurrent managers, that come pre-configured with the EBS installation. Of course, these default concurrent managers can be configured and tuned according to the workload. Also, custom concurrent managers for executing some custom programs can be created.

The first concurrent manager started is the Internal Concurrent Manager (ICM ), as it controls all the other concurrent managers. Conflict Resolution Manager (CRM ) is also an important one because it deals with the conflicts among the runnable concurrent programs. Standard Manager is the default concurrent manager for all the concurrent programs. If a concurrent program is not configured to be executed by a specific concurrent manager, Standard Manager runs it.

The database tier in EBS actually means Oracle Database. It has the technology of Oracle Database, where the EBS data model and EBS-specific database objects such as indexes and tables are stored. There are special database schemas for the use of apps DBAs, the EBS tech stack, and the application modules inside of EBS database.

There is no direct communication between the clients and the database. The services, or servers run in the application tier, communicate with the database for storing, updating, deleting, structuring, and querying the data. We will give the details about the data model later in this blog.

So, basically, the HTML services, Java-based services, forms services, concurrent processing services, and Oracle Database are components used in EBS. The HTML, Java-based, and forms services are almost transparent; there are almost no details for you to analyze, the configuration of these services is straightforward, and the actions for managing them are more like starting, stopping, and troubleshooting.

By contrast, this is not the case for concurrent programs. To manage the concurrent tier, you need to know more details.

Concurrent Processing

Concurrent processing in EBS implies the completion of tasks in the background, while maintaining work done by the clients using the EBS web and forms interfaces. Besides, the works in background are done concurrently in concurrent processing, which makes concurrent processing an optimal term for describing this technology.

Concurrent processing is supplied by the concurrent managers, as they are the parent programs that are responsible for managing the program executions. Programs defined to be run by the concurrent managers are called the concurrent programs. The term used for describing the request for running a concurrent program is concurrent request. When a program is requested to run or is scheduled to run, a concurrent request for that program is created and placed in its associated concurrent manager’s queue. The concurrent manager by design checks its queue and meets the concurrent request waiting in its queue. To meet the request, a concurrent manager actually runs the associated concurrent program with its supplied arguments by interpreting the associated concurrent request, as concurrent requests carry this information. There is also a mechanism for controlling the concurrency between these concurrent requests; a separate concurrent manager is dedicated to this work. Any requests that must not be run while another concurrent request is running are placed in this concurrent manager’s queue and wait there until the incompatible concurrent request finishes running. This mechanism is supplied and configured with the rules that are used to define the incompatibility settings.

We’ll now identify the concurrent managers so you have a clearer picture about concurrent processing. The main concurrent managers come predefined in EBS. The most important of these managers are Internal Manager, Standard Manager, Conflict Resolution Manager, and Transaction Managers.

Internal Manager is the main concurrent manager that is programmed to do the internal work. Internal Manager is started by the concurrent manager start script, and it is responsible for starting up, verifying, resetting, and shutting down all other concurrent managers.

Standard Manager is the default concurrent manager of all requests. It accepts and runs all the concurrent requests if they are not configured to run by another manager and excluded explicitly from Standard Manager.

Conflict Resolution Manager is responsible for managing the conflicts between the concurrent requests. Any request breaking the compatibility rules is placed in its queue and waits there until the environment become appropriate for it to run.

Transaction Managers are predefined managers. They support synchronous processing, and they are dedicated to the concurrent request triggered by the client applications. That is, a form interface may have the option to run a concurrent program to do a transaction, and if that is the situation, this concurrent program may be configured to run by the associated Transaction Manager.

In addition, custom concurrent managers can be created and configured to run the custom concurrent programs. Custom managers are often preferred for separating the queues of the standard and custom concurrent programs. This type of configuration guarantees the standard programs to be run without any unpredictable delays that may be caused by the high number of ready-to-run custom concurrent programs filling Standard Manager’s queue.

Database Tier and EBS Data Model

The database tier and the EBS data model make up one of the important layers of EBS. All the application tier components and processes work by considering the EBS data model, and they do all their database activities by connecting to Oracle Database, which comes packaged with EBS.

EBS uses the world’s leading relational database management system (RDBMS), Oracle Database. The database version included with the installation depends on the EBS release. For example, in EBS 12.1, the default database that comes with the installation is 11.1.0.7; in EBS 12.2, Oracle Database 11.2.0.3, 11.2.0.4, or 12.1.0.2 (with the latest installation package) comes as the default database.

Needless to say, the database in EBS can be upgraded to the higher releases, even to 12c, which is supported by all major releases such as EBS 11.5.10.2, 12.1, and 12.2.

EBS’s Oracle Database is managed just like a standard Oracle Database, but there are some extras for DBA’s management activities. This includes a role named Apps DBA.

To manage Oracle Database, DBAs (namely, apps DBAs in EBS environments) need to know the standard core DBA activities. In addition, apps DBAs should know the EBS data model, which is stored inside the database and how to use tools such as Autoconfig and Rapid Clone to manage the apps-specific configuration and apps schema structure. There are important differences even in managing database accounts such as managing database schema passwords. That is, apps DBAs should use a tool for changing a user’s password; they can’t just execute an alter user command from SQL*Plus to accomplish that.

We will go into detail about these tools and management activities later in my blog, but here we’ll introduce the EBS data model.

The EBS data model consists of base product schemas. These base product schemas are the database representation of EBS applications. For storing the General Ledger, there are schemas like GL, the INV schema is used for Inventory, AP is used for Account Payables, PO for Purchase and Orders, and so on. The base product schemas continue in this way, and they store data objects such as tables, sequences, indexes, constraints, and queues of their associated product.

So, the base product schemas store the data, and the schema called APPS stores the product code objects. The APPS schema is the most important schema for apps DBAs because it is used in almost every applications DBA operation. The APPS schema is also important for EBS because it is the schema that drives the application. The APPS schema has the grants and synonyms for accessing the entire Oracle E-Business Suite data model, which consists of all the objects of the base product schemas. This makes the APPS schema special and also is used by the EBS system internally.

After the login, the EBS system uses the APPS schema to connect to the database and do the database-related operations using this schema. No matter what application is used, EBS uses the APPS schema internally to get through the related data model.

There are also other EBS schemas that provide the integrity and make it work. The APPLSYS schema is an example of these kinds of schemas. APPLSYS stores the objects of the applications technology layer products such as Foundation (FND) and Applications DBA (AD).

The GUEST and APPLSYSPUB accounts are important accounts too. GUEST is an EBS account and is used internally by EBS to access and display EBS web pages like the login page when there is no application authentication present.

APPLSYSPUB is a public database account, and it is used for EBS authentication. The supplied application’s usernames and passwords are authenticated inside the database, and this database connection is made using the APPLSYSPUB schema.

The APPLSYSPUB and GUEST schemas are transparent to the APPS DBAs. They have default passwords, do not require any administration operations, and work internally. The base product schemas are managed by EBS actually, but it is important to know the structures of them and their relation with APPS in order to have the full control over an EBS database.

APPLSYS is the application system schema. As mentioned earlier, it stores the APPS systems objects, but it is not involved intensely in administration operations.

Of course, there are also schemas such as SYS and SYSTEM inside the database because they are the system schemas for the Oracle Database itself. In addition, there are schemas to support optional database features such as MDSYS, ORDSYS, OLAPSYS, and CTXSYS. Even the famous sample schema named SCOTT comes with the installation.

Also, custom database schemas can be created for storing the objects related to customizations and the data produced by customized code, but care must be taken here as the custom schema should be added appropriately.

The main focus of an apps DBA is the APPS schema because it means the same thing as the SYSTEM schema for Oracle Database. It has the access rights for reaching the other schemas, it used internally by the EBS system, and it is used in almost every kind of administration operation.

Figure 3 is a good representation for describing the relationship between APPS, APPLSYS, and base product schemas.

Figure 3. Relationship between APPS, APPSSYS, and PRODUCT schemas in EBS 12.2 SCHEMA

As shown in Figure 3, the APPS schema accesses both the base product and APPLSYS schemas to make the EBS system run properly. EBS application tier components use the APPS schema to access all the base product schemas and APPLSYS through grants and synonyms.

There are some situations that require you to re-create these grants and synonyms. Fortunately, an administration tool called Adadmin can be used for accomplishing this task.

Because the data store of EBS is an Oracle database, it is needless to say that the EBS data model stands on the tablespaces. The block size used for the tablespace, actually for the whole EBS database, is 8KB. EBS releases 12.1 and 12.2 both require tablespaces with 8KB in size. This is because having the EBS database with 8KB block sizes makes the whole system perform well, and Oracle E-Business Suite indexes accommodate 8k block size.

In an EBS database, the standard tablespaces such as System, Undo, and Temporary are normally present.

The Undo tablespace and the System tablespace are used instance wide.

The Temporary tablespace in an EBS database can be more than one. That is, dedicated Temporary tablespaces can be created to separate the temp usages of each EBS product.

However, creating dedicated temporary tablespace is not an effective method. Since EBS uses the APPS schema to connect to the database, the Temporary tablespace of the APPS schema becomes the default Temporary tablespace for all the EBS products.

EBS 12.2 uses 12 tablespaces including Temporary, System, and Undo. So, there are nine EBS-specific tablespaces present in EBS 12.2.

These tablespaces are locally managed, and they are delivered to have 128Kb uniform extent sizes by default. Alternatively, you can auto-allocate extent management, which is a simpler and more efficient method and can be used for managing the extent sizes of EBS tablespaces. If auto-allocate extent management is your choice, you can accomplish it by re-creating the tablespaces with the auto-allocate extent management option and re-migrating the objects to these tablespaces. This is required because the Oracle RDBMS server does not support changing the extent management of a locally managed tablespace.

In EBS 12.2, the object-tablespace classifications are based on the Oracle Applications Tablespace Model (OATM ).

Table 1 summarizes the tablespace types, tablespace names, and related contents. The database objects in EBS 12.2 are categorized based on their contents and stored in the relevant tablespaces, which have the desired tablespace type whose definition meets the content characteristics.

Table 1. EBS Tablespaces Providing the Tablespace and Content Types for the Standard EBS Tablespaces

As shown in Table 1, the objects are grouped into tablespaces. OATM makes this classification based on rules called Explicit and Implicit Classification rules. In Implicit Classification rules, OATM classifies the objects based on their object types. That is, while it stores the AQ tables (Queue tables used by Oracle Advanced Queuing) in APPS_TS_QUEUE, which is a dedicated tablespace for advanced queuing objects, it stores the transaction table indexes in APPS_TS_TX_IDX, which is a dedicated tablespace for indexes on transactional tables.

Table 2 shows the implicit rules and the distribution of the objects to the tablespaces.

Table 2. Object Types and Tablespace Type Associations

Explicit rules take this distribution into a higher level because these rules are based on the I/O characteristics of an object. These classifications are seeded by Oracle.

In addition to the information provided earlier, the objects that are not mentioned in the implicit rules are stored in the default tablespace of their owner schemas. It is also important to know that the default tablespace for all the EBS schemas are set to APPS_TS_TX_DATA.

So, you have seen the database tier by going through the database schemas and tablespace model. At this point, you have detailed information about what an EBS database looks like.

Let’s continue with the technology stack components and take a detailed look at them now.

Understanding the EBS 12.2 Technology Stack Components

E-Business Suite’s technology stack consists of application tier technology components and database tier technology components. These components come installed and configured when the installation is complete.

As for technology stack components , there are various technologies to support the diversity of the services that EBS offers to the clients.

The technology stack components in version EBS 12.2 (the latest release 12.2.5) can be categorized as Oracle technologies, Java technologies, technologies delivered in applications (APPL_TOP technologies), and external technologies.

Table 3 summarizes these groups of technologies with the versions delivered with the latest EBS 12.2.5 installation.

Table 3. Oracle Technologies and Their Component Versions in EBS 12.2.5, Deployed with the Latest Installation Package (startCD–startCD 51)

Note

EBS 12.2 is installed as the base release 12.2.0, which is not supported and required to be immediately upgraded to a supported patchset (currently 12.2.2 and upward). At the time of writing this article, the latest patchset level of EBS 12.2 was 12.2.5, so although EBS 12.2.5 is not directly installable because it is provided with an upgrade patch, the following version information provided is based on this patchset level, 12.2.5, because it is currently the most stable and latest patchset among all the supported patchsets of EBS 12.2.

The database tier technology component in EBS 12.2 basically implies Oracle Database.

As for the latest EBS 12.2 release installed with the latest startCD (currently startCD 51), EBS’s database tier is Oracle Database 12.1.0.2, which is a stable release of Oracle Database. As for the EBS 12.2 environments, which are deployed using earlier startCD versions, the database tier can be deployed as Oracle Database 11.2.0.3 or 11.2.0.4 according to the version of the startCD that is used for the installation. On the other hand, as using Oracle Database 12c is supported with EBS 12.2, the database tier can be upgraded to 12c for these environments, as well.

The XML Development Kit (XDK ) for Java is a database feature that contains a set of components, tools, and utilities for building, deploying, and supporting XML-enabled applications. These components can be for various XML processing operations such as parsing XML, validating XML, transforming XML documents into another format, and generating Java and C++ classes from input XML schemas.

So, EBS uses the XDK through Oracle XML Gateway in certain transactions such as inbound transactions; it is used to get the XML files/messages and parse and import the data into the application tables for further processing.

Oracle Application Server 10.1.2.3, also called as Developer Home in EBS 12.2, is used for providing forms and reports services. Forms services are provided by cooperating with FMW. It is in the form of an Oracle Home, which has several binaries, libraries, and configuration files to provide its services.

You can take a deeper look at this process by referring to Figure 4, where the cooperation between the FMW components and Oracle 10.1.2 Home (needed for providing the form services) is described.

Figure 4. The relationship between 10.1.2 Oracle Home and WebLogic forms services

As shown in Figure 4, there is a relationship between 10.1.2 Oracle Home and the WebLogic form services. Figure 4 also shows the WebLogic Oacore and OAFM services reaching the Java classes, HTML pages, and other files and directories stored in the COMMON_TOP directory. (We will explain COMMON_TOP later in this article.)

The EBS modules (formsapp.ear) and the actual forms executable (frmweb) runs on this 10.1.2 application tier Home, but all the major services for frmweb are served by the Oracle Fusion Middleware. So, when an Oracle report program is executed or a client request is made for opening an Oracle form-based EBS screen, the binaries in this Oracle Home are triggered.

Oracle Fusion Middleware (FMW ) 11.1.1.9.0 is the application server for applications that provide the core functionalities in EBS Java code. Using the WebLogic Server that resides in it, FMW hosts the Oacore server to provide the pages developed with Oracle Application Framework (OAF), which is a framework supplied by Oracle to be used for development within the Oracle E-Business Suite OAFM to provide such as web services and a secure enterprise search agent. In addition, it hosts the forms server for services, all the forms functionality, and forms-c4ws to expose forms-based functionalities as web services.

A JSP compiler and JSP engine are also included in FMW.

The WebLogic JSP compiler , weblogic appc, is used for the precompilation of JSP pages in EBS. The SP engine is used for processing the JSP pages and converting them to the servlets.

FMW also includes control mechanisms/utilities for its core WebLogic services, as well as all the JRF files needed by EBS and Oracle HTTP Server to be used as a web entry point for EBS.

So, Oracle HTTP Server, WebLogic Server, 10.1.2 Home services, and the binaries stored in application directories such as COMMON_TOP and APPL_TOP are used together for the application tier processing. Figure 5 shows the FMW components such as Oracle HTTP Server and WebLogic Server, as well as the other technologies such as 10.1.2 Oracle Home and three important top-level EBS directories such as APPL_TOP, COMMON_TOP, and INST_TOP working together.

Figure 5. Oracle E-Business Suite application and database tier components

The XDK is also present in the application tier. The XDK in the application tier is used mostly in the application reports such as the Account Analysis report. Data gathering activities of these kinds of applications are based on XML publisher technology that relies on XDK in the back end.

Oracle FMW comes with Oracle HTTP Server 11.1.1.9.0 for accepting HTTP requests and passing them to the related WebLogic services if needed.

Oracle HTTP Server can provide responses for basic requests, without passing them to the WebLogic servers.

Table 4 summarizes the Java technologies that come with the latest version, EBS 12.2 (12.2.5).

Table 4. Java Technologies and the Versions Used in EBS 12.2.5

There are two JAVA SE developments kits (JDKs) present in EBS 12.2. One of them is used for the programs related to concurrent processing, which are not provided by WebLogic Server. The second JDK is used for Oracle application tier Java code and the application framework.

There is also a native Java plug-in stored in the EBS application tier. This plug-in is used for client-side forms interfaces. That is, if a client requests opening a form-based interface, then this plug-in is transferred to the client on the fly, and by using this plug-in, the client browser can open the forms through the Java applet.

Also, there are technologies deployed in the Oracle applications APPL_TOP directory. Table 5 summarizes technology components delivered within the Oracle applications directory, APPL_TOP.

Table 5. Technology Components in APPL_TOP Directory [CAPTION]

In the APPL_TOP directory of EBS12.2, standard JDeveloper runtime libraries and BI beans are delivered to support applications leveraged from them. In addition, Oracle thin JDBC drivers are provided for use in the database connections.

In addition to the technologies delivered with EBS, there are external technologies that are considered to be part of an EBS environment but are not deployed with an EBS installation.

Table 6 lists these technologies and their supported versions.

Table 6. External Technologies and Their Latest Versions Certified with EBS 12.2.5

Oracle Internet Directory when used with Oracle Access Manager supplies the single sign-on for EBS. Oracle Business Intelligence is a separate program for delivering the business intelligence but can also be integrated into EBS.

Oracle Discoverer brings a reporting solution into an EBS environment. Discoverer is a powerful reporting tool that supplies a reporting platform for creating reports with almost any details and advanced reporting capabilities.

Oracle WebCenter Portal is used to create websites and portals, and the integration of EBS applications to a WebCenter Portal application is certified with EBS. Oracle Portal is a Fusion Middleware component used for creating enterprise portals, and these portals too can be in conjunction with EBS.

With the Release 12.2, Oracle BPEL Process Manager 11.1.1.9 can be used for the integration. Systems like Oracle Transportation Manager can be integrated to EBS using this method.

Oracle Enterprise Manager 12c provides an Oracle EBS plug-in for managing the EBS system using Oracle Enterprise Manager. Enterprise Manager 12c has EBS-specific capabilities such as performance monitoring and cloning support.

We’ve now introduced the technology components, so let’s proceed with the EBS 12.2 file system structure; looking the components explained earlier from the file system may provide a better understanding of them.

Oracle EBS 12.2 File System Structure

The EBS 12.2 file system structure can be classified in two groups: the database tier file system and the application tier file system.

Database Tier File System

The database tier file system consists of a directory structure called Oracle Home , similar to a directory structure that comes after a standard database installation.

The EBS database tier file system structure is similar to a standard database file system structure, but they are not the same. The database tier in EBS has some additions on top of the standard database Home file system structure to support EBS-specific configurations.

The EBS database, when installed using the latest startCD, is delivered as an Enterprise Edition 12.1.0.2 64-bit Oracle Database patched with a list of the latest technology bug fixes required for Oracle E-Business Suite Release 12.2, as well as a set of recommended patches. Oracle Home contains the Oracle Database 12c products (12.1.0.2) delivered with the 12c examples CD, as well. Using a Real Application Cluster (RAC) for the database tier is also an option; it brings a multinode configuration ability to the database tier. Rapidwiz, which is the installation tool of EBS, has an optional Oracle RAC installation, too.

The big difference in an EBS Oracle Home is the existence of an appsutil directory. The appsutil directory inside an Oracle EBS Oracle RDBMS Home contains Perl scripts, bash scripts, SQL scripts, a Java runtime environment, JAR files, a clone directory, and a log directory for the use of application-specific database activities, such as database tier cloning and AutoConfig, as well as pure database-oriented activities such as starting/stopping database and the listener.

The appsutil directory comes with the installation, but it can be rebuilt if needed.

Rebuilding it is easy. To do that, you create an appsutil zip file in the application tier using application utilities designed for this purpose and then copy this zip file to the Oracle Home of the database with the proper file permissions, which lets the Oracle Database software owner use the scripts and all the other files contained in it.

Once the copying is done, you just unzip to extract the content of it. The content is actually the appsutil directory.

So, you have an appsutil directory in the database tier for supporting the EBS-specific database operations. We have mentioned the types of file stored in the appsutil directory. We’ll now cover them in detail.

The appsutil directory consists of several subdirectories and a context file, as listed next.

• Sql: Stores SQL scripts that can be used in apps DBA activities (such as adgrants.sql, which is used for granting necessary privileges on a selected SYS object to the APPS user).
• Java: Stores JAR files (xmlparserv2.jar) and classes (AutoConfigProcess.class, AutoConfigSynchronizer.class, and so on) for use by EBS-specific database utilities such as AutoConfig.
• Media: Contains four standard GIF files for use by Oracle applications, such as the Oracle log. This directory is not relevant to the database tier, but it is there for use by applications, just in case.
• Perl: Contains Perl modules such as AutoConfig.pm for use by TXK utilities such as TXKScript.pl, as well as modules such as Sysutil.pm for use by AD utilities such as adgentns.pl.
• Html: Contains XML and XSL files for use by AutoConfig-related Java classes such as AppltopDrivers.class.
• jre: Provides Java runtime environments for use by Java classes inside the appsutil directory.
• temp: Is a temporary folder for use by application utilities present inside the appsutil directory. This folder acts as temporary file storage. The utilities inside the appsutil directory are designed for placing their temp files within directories related to their core.

Note

txkEBSWrapper.pl sets its temp directory destination to $ORACLE_HOME/appsutil/temp/TXK.

• Clone: Stores the file adcrdb.zip, which contains the scripts adcrdb.sh and adcrdbclone.sql to re-create the control file and start up the database. These script files are used by rapid clone Java classes such as ApplyRmanDatabase.class while creating a clone database. Also, its subdirectory bin (clone/bin) is created by the preclone and stores the post clone-related Perl scripts. 
• Bin: Provides the bash and Perl scripts for application-specific database activities such as AutoConfig. These scripts are normally run by following the directions in the Oracle Support documents, and some of them are used internally, but it is still worth knowing what they’re for. The scripts and their definitions are as follows:
  • pl: This is an AutoConfig tool to generate the context file for the database’s Oracle Home.
  • sh/adchkcfg.cmd (for Windows): This runs the AutoConfig tool to test reconfiguration on the apps tier and the database tier.
  • sh: The checks the system for ld, ar, cc, and make.
  • pl: This is a Perl script that clones the context file.
  • pl: This runs the AutoConfig tool to clone applications.
  • sh: This is an obsoleted script for the same purpose as adclone.pl. It runs the AutoConfig tool to clone applications.
  • pl: This runs the AutoConfig tool to reconfigure the APPL_TOP directory and the database Oracle Home.
  • sh: This runs the AutoConfig tool to reconfigure APPL_TOP.
  • sh/adcustomizer.cmd (for Windows): This is an obsolete script that performs the task of migrating the customizations done by users to AutoConfig-generated files to the custom template. This script has been obsoleted in 12.2 because beginning-to-end customizations are not supported in Release 12.2.
  • sh/adcvm.cmd (for Windows): This manages changes in values of the context file because of changes in the template.
  • pl: This enables/disables password protection for the RDBMS password and changes the password of the already password-protected listener.
  • pl: This creates a database staging area for Rapidwiz, which is the installation tool of EBS.
  • pl: This script is used to generate the tnsnames.ora with all the necessary tns entries, dynamically.
  • sh/adtmplreport.cmd (for Windows): This is a wrapper script for running ATTemplateReport.java, which is a utility to list the template names and their target file names and locations.
  • pl: This displays the cause and action sections of ADX error messages. It uses $AD_TOP/html/adxmsg.xml or <RDBMS_ORACLE_HOME>/appsutil/html/adxmsg.xml as an ADX message repository.
  • pl: This script is used to generate the banner file txkDBSecUserAuditActionBanner.txt in the appsutil/template during an AutoConfig run in the database tier.
  • pl: This script is used to search for a keyword in all product top templates and generate a detailed report (text/HTML).
  • pl: This generates a health check report that contains current versions of the technologies installed, the latest version of the technologies installed, and recommendations, if necessary.
  • pl: This generates a report containing versions of various technology components in the Oracle applications tech stack.
  • pl: This is a simple wrapper script to create a TXK::Script object and run the supplied script.
  • pl: This is a simple wrapper script to create a TXK::Script object and run the supplied script. This script is similar to txkrun.pl, but it takes different arguments like a full path of the script to be executed and the logfile path. This script is generally used within txkInventory.pl for giving an output file to txkInventory.pl to write its report output.
• Admin: Stores some scripts that are transferred from the application tier. Certain patches provide action plans such as “copy the adgrants.sql from Application Server to Database Server and place it inside the $ORACLE_HOME/appsutil/admin directory and run it from there.”
• Out: Stores the output files. This is used for apps utilities in operations such as database cloning. Certain intermediate scripts and their logs that are generated during the cloning operations are placed here (such as restore-single2.rman and run_utlrp.sql).
• log: Stores log files generated during the executions of utilities. An example is the adconfig.log file, which provides the logs generated during an AutoConfig run.
• Template: Stores AutoConfig template files, which are the sources for creating site-specific configuration files. AutoConfig reads the context file and creates the final configuration files by filling these template files with the values it gets from the context file.
• Scripts: Contains scripts for executing AutoConfig, executing preclone, and stopping and starting the database and the listener.
  • sh: This is a script for executing an AutoConfig. It is a wrapper for executing adconfig.sh stored in $ORACLE_HOME/appsutil/bin directory. adconfig.sh in turn calls the adconfig.pl Perl script, which does the actual job.
  • pl: This checks for the existence of the RDBMS $ORACLE_HOME/nls/data/9idata directory and the cr9idata.pl file in that directory.
  • sh: This is a script for starting and stopping the database.
  • sh: This is a script for starting and stopping the database listener.
  • pl: This executes all SQL scripts that update the profiles in an AutoConfig run.
  • sh: This is a wrapper on lsnodes to check whether the cluster manager is available in a RAC environment.
  • pl: This is a Perl script that runs the source system cloning preparation.
  • sql: This is used by addbctl.sh to stop the database.
  • sql: This is used by addbctl.sh to start the database.
• Outbound: Stores file created from inside the database. It is pointed at by the database directory named APPS_DATA_FILE_DIR. It is used as a directory for storing the files created by extracting the data from the database.
• Install: Stores various scripts for EBS-specific database activities such as cleaning the concurrent manager’s queues, creating database directories, and setting some database-related EBS profile options.
• In addition to the appsutil directory, there are two special files in the database tier: the context file and the environment file.
• Context file: The context file is an XML file that stores the inputs mostly used while configuring the EBS system using the autoconfig tool. Its name is in the form of <s_systemname>_<s_hostname>.xml. The context file is used by AutoConfig to make the necessary system-wide configurations for the tier where it is executed. So, it can be considered an input file for the AutoConfig utility. Like the application tier, the context file is also used in the database tier. The context file in the database tier includes configurations for the EBS database. As, various configurations such as the listener port, the domain name can be done using AutoConfig, there are XML tags associated with the configuration of them in the context file.
• Environment file: The environment file is stored in the $ORACLE_HOME directory and used for setting the environment variables for managing EBS’s Oracle database tier from the operating system. Once this file is sourced, you can do the database activities using the environment variables such as ORACLE_HOME, TNS_ADMIN, and so on. Its name is in the form of <s_systemname>_<s_hostname>.env.

So, as shown, the database tier of EBS consists of a standard Oracle RDBMS Home that has some EBS-related additions/utilities on it. EBS-specific utilities bring a need for competence in managing the EBS database stack, as these utilities are used for critical operations. A problem or a misconfiguration in this layer can break down the application tier connections as they rely on apps-specific configurations inside the database. In addition, this adds a new level on top of standard database administration and makes things a little hard. On the other hand, the good news is that once you know what to do and understand the logic, these apps-specific additions (explained earlier) inside the database home make it almost automatic to manage the EBS database.

Well, then, we have explained the database tier file system structure and given the necessary details where needed. Let’s continue with the application file system structure.

Application Tier File System

The root directory of the EBS 12.2 application tier file system is called the base directory. The directory structure branches out from the base directory. The base directory is specified during the installation, and the branches are derived from the base directory.

Just under the base directory, there are three directories named fs1, fs2, and fs_ne and one file called EBSapps.env.

EBSapps.env is the environment file for EBS 12.2. It is EBS 12.2 file system aware and is used by apps DBAs to set the environment for EBS 12.2. EBSapps.env knows the dual file system architecture used in EBS 12.2 and sets the appropriate environment accordingly. That is, when it is executed with the “run” argument, it sets the run time (active file system) environment, and when it is executed with the “patch” argument, it sets the patch environment with all the environment variables pointing to the patch file system directories and files. We will explain the run and patch file system later in this article, but let’s take a quick look now.

The fs acronym is used for referring to the file system, and the numbers denote file system 1, file system 2, and a noneditioned file system. This fs-based file system architecture was introduced in EBS 12.2, and these file system directories, together called a dual file system, are the result of implementing an online patching mechanism. In the online patching mechanism, which is a new feature of EBS 12.2, these file system directories are used to store both the active and patched files in a different directory structure. That is, the fs1 and fs2 directories are used for storing the active (run) file system and patch file system in their subfolders. Thus, they are enabling an environment that can be switched from active to patch and from patch to active. Besides, these directories are switching their roles.

For example, suppose fs1 is the active, and suppose fs2 is the patch file system at time t0; then suppose the apps DBA applies a patch at time t1 and as a result of this patch initiates a cutover operation, which switches the file system from active to patch and from patch to active. So, at time t2, fs2 becomes the active (run), and fs1 becomes the patch file system.

In addition to these active and patch file systems, there is an fs_ne directory just under the base directory.

The directory fs_ne is a noneditioned file system for storing the noneditioned file system objects. Noneditioned here means the fixed files such as concurrent processing log files, adop log files, patch files, and adop wrapper script, which are not changed by any patching operations.

Figure 6 shows the run edition, patch edition, and noneditioned filesystems by providing the top-level directories named fs1, fs2, and fs_ne with their main subdirectories, which store the files that EBS application tier services rely on.

Figure 6. EBS 12.2 dual filesystem and noneditioned filesystem directories: fs1, fs2, and fs_ne

The following environment variables can be used to retrive to full directory paths of fs1, fs2, and fs_ne directories;

• NE_BASE is the environment variable which is set to the full path of the non-editioned file system (fs_ne).
• PATCH_BASE is the environment variable which is set to the full path of the current patch file system (fs1 or fs2, whichever is the patch file system at that time).
• RUN_BASE is the environment variable which is set to the full path of the current run file system (fs1 or fs2, whichever is the run file system at that time).

Under the fs1 and fs2 directories, there are three important top-level directories in an EBS 12.2 application file system structure.

These directories are inst (instance home), EBSapps, and the Fusion Middleware Home (FMW_Home).

The inst directory, also called instance home and pointed at by the $INST_TOP environment variable, contains most of the configuration files created by AutoConfig, configuration files for Oracle Application Server 10.1.3 (which is used by form and reports), and the other files such as forms log files (in the subdirectory pointed by $LOG_HOME), application services start/stop script logs (pointed at by ADMIN_SCRIPTS_HOME environment variable), 10.1.2 make logs, application listener log file, reports cache files, oam diagnostic files, and the context file for the use of AutoConfig.

Figure 7 shows the directory structure of the inst directory and its subdirectories.

Figure 7. Structure of the inst directory ($INST_TOP )

The EBSapps directory is one of the directories in the base directory and at the same level with the instance home directory.

EBSapps consists of three subdirectories. These directories are the appl directory, which is pointed at by the $APPL_TOP environment variable; the common directory, which is pointed at by the $COMMON_TOP environment variable; and the 10.1.2 directory, which is pointed at by the $ORACLE_HOME environment variable.

The appl directory, also known as applications top (APPL_TOP), stores core technology directories, all the product directories, the main EBS environment file (which is in the form of <s_systemname>_<s_hostname>.env and <s_systemname>_<s_hostname>.cmd for Windows), and the consolidated env file in the form of APPS<s_systemname>_<s_hostname>.env and APPS<s_systemname>_hostname.cmd for Windows.

Environment files are for setting the APPS-related environment variables for the executing shells. The APPS<s_systemname>_<s_hostname>.env file is used for setting both the Oracle E-Business Suite and Oracle technology stack environments, whereas the <s_systemname>_<s_hostname>.env file sets the environment for applications only.

That is, the environment file named in the form of <s_systemname>_<s_hostname>.env does not set the environment variable for 10.1.2 Oracle Home that is used by forms and reports.

There are four different environment files for setting the shell environments in EBS 12.2, and each environment file is used for setting a different environment for administrating a different set of Oracle technology products.

Table 7 lists the environment files present in EBS 12.2 and gives information about what they are used for.

Table 7. EBS 12.2 Environment Files

As mentioned earlier, the appl directory consists of several subdirectories, such as the admin directory that stores the adovars.env file to set the location of various files such as Java files, HTML files, and JRE files. The admin directory under the appl directory contains upgrade-related files for all products.

Besides, the appl directory stores several subdirectories for storing the product files.

For every product, there is a subdirectory named with the associated product’s short name. These product directories are used for storing product-specific files and pointed at by the environment variables named with the form <PROD>_Top. <PROD>_Top points to the 12.0.0 directory, which is stored in the product directory. In every product directory, there is a subdirectory named with the release number, which is defined as 12.0.0 for EBS 12.2.

To understand it better, let’s take a look at an example. For example, for General Ledger product files, the gl directory inside the appl directory is used. Thus, the environment variable GL_TOP points to the gl/12.0.0 directory, which resides in the appl directory.

This makes GL_TOP to be $APPL_TOP/gl/12.0.0, and all the GL files are stored there.

Thus, <PROD_TOP> becomes $APPL_TOP/<Product_shortname>/12.0.0.

Figure 8 shows the directory structure of the appl directory, which is pointed at by the APPL_TOP environment variable in a general manner.

Figure 8. APPL_TOP/appl directory structure

As shown in Figure 8, all the product directories contain subdirectories.

In most of the product directories, there are directories named admin, bin, forms, help, html, java, lib, log, mds, media, mesg, out, patch, reports, and sql.

The following list summarizes these subdirectories with the type of files stored in them.

• admin: Contains product-specific files used to upgrade the associated product. This is in distinction to the following.
• driver: Contains driver files (.drv files) to be used in an upgrade.
• import: Contains DataMerge files to be used in seed data upgrades.
• odf: Contains object description files (.odf files) used to create database objects.
• sql: Contains SQL scripts for upgrading and concurrent processing, as well as PLSQL scripts for creating PLsql objects/PL/SQL stored procedures.
• bin: Contains concurrent programs, C programs, and shell scripts.
• forms: Contains Oracle Forms runtime (.fmx) files to be executed by the forms engine. These forms files are stored in subdirectories according to their languages, for example, US to store American English forms.
• help: Contains the online help source files.
• html: Contains HTML, JavaScript, and JSP for HTML-based applications.
• include: Contains C language header files to be linked with the library files stored in the lib directory.
• java: Contains JAR files and Java dependency files. Copies of these JAR files are also located in the directory pointed at by the $AF_JLIB environment variable.
• lib: Contains object files (.o files for UNIX and .obj files for Windows), library files (.a for UNIX and .DLL for Windows), and make files (.mk). These files are used to relink concurrent programs with the Oracle-supplied libraries.
• log: Contains log files for concurrent requests and concurrent managers.
• media: Contains GIF files used to display text and graphics on the desktop tier.
• mesg: Contains message files (msb) to be used by EBS to display messages at the bottom of the forms screens.
• patch: Contains patch files to the data or data model.
• reports: Contains report binary files (rdf). These report files are stored in subdirectories according to their languages, for example, US to store American English Reports.
• resource: Contains PLSQL library files (PLL). These PLL files are later copied to.

Before continuing with the common directory, we want to include some specific information about three subdirectories of the appl directory. That is, there are three important subdirectories inside the appl directory: the ad, au, and fnd directories.

The ad directory is the directory for the AD (Applications DBA product), and it stores the ad utilities such as adadmin and AutoConfig. The au directory is pointed at by AU_TOP, and its name comes from the application utilities.

AU_TOP contains important files such as PL/SQL libraries used by Oracle Forms, forms source files, a copy of all Java files used when regenerating the desktop client JAR, and certain reports needed by products such as Discoverer.

FND is short for Foundation, and the fnd directory pointed by FND_TOP contains important files for building data dictionaries, forms, and C object libraries.

The common directory is also known as COMMON TOP and pointed at by the COMMON_TOP environment variable; it stores files that can be used by several EBS products and even third-party tools. It is called common because it stores the common files such as Java classes, HTML pages, and other files and directories used by multiple products.

Figure 9 represents the COMMON TOP directory structure with all the main subdirectories of it.

Figure 9. Structure of COMMON_TOP/comn directory

The last subdirectory in the EBSapps directory is 10.1.2, and it is pointed at by the $ORACLE_HOME environment variable. As you can probably guess because of its associated environment variable’s name, it is a 10.1.2 Oracle Home, which provides an environment for the server-side 10g forms and report binaries to run properly.

Executables such frmweb, which is the server-side forms process, and rwrun (reports binary) are started from this directory. The application listener, which is used for the FNDFS and FNDSM connections, is also started from this directory.

The Fusion Middleware Home (FMW_Home ) directory consists of the Fusion Middleware components and is pointed at by the $FMW_HOME environment variable. The most important component in this Oracle Home is WebLogic Server, which is the main application server used by the core application services.

There are subdirectories in FMW_Home such as user_projects, wls_10.3, utils, oracle_common, webtier, modules, and Oracle_EBS-appl, as shown in Figure 10.

Figure 10. FMW_Home($FMW_HOME) directory structure

Figure 10 represents the FMW_Home directory and its subdirectories. The subdirectories in the FMW_HOME directory are as follows.

The user_projects directory is a classic directory that is present in every WebLogic-related application environment. It contains the WebLogic domain directory named EBS_domain_<s_systemname> used by EBS application services. This directory is used to deploy Oracle E-Business Suite. EBS_domain_<s_systemname> inside the user_projects directory stores all the configuration and log files related to the EBS domain.

Moreover, all the WebLogic-related environment files and start/stop/control scripts such as setDomain.env and startWebLogic.sh are normally stored in the FMW directory.

• The Wls_10.3 directory is the actual WebLogic server directory. It contains all the binaries and libraries used by WebLogic Server 10.3.6, which comes built in to EBS 12.2.
• The Utils directory contains FMW utilities, such as bsu (Smart Update), which is the patching tool for WebLogic Server.
• The Oracle_common directory contains the JRF files used by Oracle EBS. A JDK comes deployed under this directory, as well.
• The Webtier directory contains all the configuration and log files used by Oracle HTTP Server. Oracle HTTP Server started from this directory, namely, from the ohs subdirectory (webtier/ohs/bin/). In addition, opmn (Oracle Process Manager) for managing the OHS server is stored in here. In addition, this directory has its own JDK stored in its subdirectory named jdk.
• The modules directory contains WebLogic modules, which are presented as JAR files. It also contains applications such as Apache ant, which supplies operations such as compiling, assembling, testing, and running Java applications.
• The last Fusion Middleware directory in the list is the Oracle_EBS-appl directory, which contains the Oracle EBS WebLogic components and the core technology components, which are forms, forms-c4ws, oacore, and oafm. So, they are deployed into this directory. Thus, WebLogic Server inside EBS runs them as applications from this directory. Normally, there is a JDK stored in this Oracle Home. In addition, all the configuration files of these EBS WebLogic components/applications are stored in the Oracle_EBS-appl directory.

You have now seen the main directories in the EBS file system structure. We have gone through the main directories and described their contents. You have seen the important EBS directories, and we have listed their contents with the names and content types of their important subdirectories. Although EBS’s directory structure is a complex one, you have seen the environment variables to reach the desired locations in the directory structure easily.

Important environment variables in this context are listed here:

• IAS_ORACLE_HOME: FMW web tier home directory.
• ORACLE_HOME: 10.1.2 Oracle Home used for forms and reports.
• CONTEXT_FILE: The context file used by the AutoConfig utility. AutoConfig uses it as an input for configuring the EBS system.
• EBS_DOMAIN_HOME: WebLogic domain in where EBS WebLogic deployments are stored.
• ADMIN_SCRIPTS_HOME: Shell scripts for starting/stopping/controlling EBS services.
• EBS_ORACLE_HOME: EBS WebLogic components/applications are stored in this Oracle_EBS-appl directory.
• RW: Oracle Reports directory.
• APPS_VERSION: Returns the EBS version.
• NE_BASE: Nonedition file system base directory.
• APPL_TOP_NE: The appl directory in the nonedition file system.
• RUN_BASE: The run file system directory.
• PATCH_BASE: The patch file system directory.
• APPL_TOP: The appl directory stores core technology directories, all the product directories, and the main EBS environment file.
• COMMON_TOP: The common directory stores files that may be used by several EBS products and even third-party tools.

In addition, you have learned about the EBSapps.env script for setting these environment variables automatically.

When sourced, EBSapps.env sets more than 300 environment variables and thus eases the apps DBA’s work. After connecting to the system using the application owner operating system user and executing EBSapp.env, you can start using these environment variables immediately.

As EBS 12.2 has a dual file system architecture, EBSapps.env is executed by an argument specifying the edition type. When executed with the “run” argument, EBSapps.env sets the environment variable according to the run edition file system. As you may imagine, when executed with the “patch” argument, EBSapps.env sets the environment variable according to the patch edition file system.

Following is an example for setting the run edition environment.

. EBSapps.env run

  E-Business Suite Environment Information

  ----------------------------------------

  RUN File System : /u01/install/APPS/fs2/EBSapps/appl

  PATCH File System : /u01/install/APPS/fs1/EBSapps/appl
  Non-Edition File System: /u01/install/APPS/fs_ne
  DB Host: ermanhost.ermandomain.com Service/SID: ORATEST


Sourcing the RUN File System


. EBSapps.env patch


  E-Business Suite Environment Information

  ----------------------------------------
  RUN File System           : /u01/install/APPS/fs2/EBSapps/appl
  PATCH File System         : /u01/install/APPS/fs1/EBSapps/appl
  Non-Editioned File System: /u01/install/APPS/fs_ne
  DB Host: ermanhost.ermandomain.com Service/SID: ORATEST

Sourcing the PATCH File System

Having a general knowledge about the directory structure is important, but memorizing all the directories inside this huge directory structure is unnecessary because the environment variables do this job.

Later in my blog, we will expand on all the information provided in this article by providing practical examples such as installation, upgrade, patching, and so on. Lastly in this blog, we will look at the technological differences between the major EBS releases.

Technology Stack Changes in EBS 11i/12.1/12.2

Since the first release of EBS, while the product capabilities have improved, so have the technologies used in EBS. In this section, we will explain the technology stack changes in the major EBS releases.

We will cover the technological architectures of EBS 11i (11.5.10.2), EBS 12 (12.1.3), and EBS 12.2(12.2.4/12.2.5) and explain the differences between them. Although mostly the same Oracle technologies are used in almost all of these releases, the versions of the technological components differ according to EBS release, as shown in Figure 11.

Figure 11. Technological differences between the major EBS releases

The database versions displayed in Figure 11 are the supported/certified database versions classified according to the EBS releases. In this manner, while EBS 11.5.10.2 is certified with 9i and 10g databases, EBS 12.1.3 is not. However, Figure 11 does not give any information regarding to the certifications for the exact four-digit database versions like 9.2.0.8 or 10.2.0.5. That is, EBS 12.1.3 is certified with 10g R2, but it is certified only with the specific 10g R2 releases such as 10.2.0.4 and 10.2.0.5. Also, EBS 12.1.3 and 12.2 are up-to-date EBS releases, so these certifications may be updated soon. That’s why we don’t give details about certified database versions here; we recommend you check the Oracle Support Certifications tab for the exact supported database versions for your EBS instances.

EBS 11.5.10.2 is one of the major releases that is still in use in production environments. EBS 11.5.10.2 is a maintenance pack sits on top of 11.5.10, and it is the latest version of EBS 11i. EBS 11.5.10.2 supports 11g R2 and 12c Oracle Database for the database tier. It utilizes 8.1.7 Web HTTP, which contains the Apache and Discoverer 4i products.

On the application server side, 11.5.0.2 uses the version 8.0.6 application server to support the Forms 6i, Concurrent, and Reports 6i services. Clients connecting to EBS 11.5.10.2 can use Jinitiator or Native Java (Sun J2SE) for the client-side Java activities (for displaying the forms screens). At the time of writing this blog, EBS 11.5.10.2 with its extended support patches was still supported by Oracle, but it was supported with an Extended Support policy, which is a restricted support policy, and it was planning to be supported with a Sustaining Support Policy, which is an even more restricted support at the end of the year 2015.

EBS 12.1.3 is a release update pack on top of 12.1, which is considered to be the most stable release among EBS Release 12 releases (12.0, 12.1). EBS 12.1.3 can be considered a completely new EBS for the environments that still use 11.5.10.2. EBS 12.1.3 utilizes a 10.1.3 Oracle Home for delivering Apache, OC4J Container, and Discoverer 10g. From the application technology point of view, 12.1.3 uses a 10.1.2 Oracle Home to support the Forms 10g, Concurrent, and Developer 10.1.2 services. Clients connecting to EBS 12.1.3 must use Native Java (Sun J2SE) for the client-side Java activities (for displaying the forms screens). EBS 12.1.3 comes with an 11.1.0.7 Oracle Database but supports 10gR2, 11GR2, and 12c Oracle Databases as well. EBS 12.1.3 is still in the Premier Support, which can be considered as a full support policy. EBS 12.1.3 will be in Premier Support until the end of year 2016.

EBS 12.2, which is the subject of this blog, is the latest release of E-Business Suite. Although its versioning number starts with 12, it is considered a new release, not just a release update pack. In EBS 12.2 Fusion Middleware is used for providing the HTTP and application services. HTTP Server and WebLogic delivered within the Fusion Middleware deliver the Oracle HTTP Server and support forms 10g and Oacore (services for OAF pages). A 10.1.2 Oracle Home is used to provide Forms 10g, Concurrent, and Developer 10.1.2 services.

EBS 12.2 when installed with the latest startCD is delivered with a 12.1.0.2 Oracle Enterprise Edition database by default. Also, the earlier versioned EBS databases (11.2.0.3 and 11.2.0.4), which are delivered with EBS 12.2 installations packaged with earlier startCDs, can be upgraded to 12C.

Clients connecting to EBS 12.2 must use Native Java (Sun J2SE) for the client-side Java activities (for displaying the forms screens). With the enhancements in underlying technology and software, EBS 12.2 brings outstanding features such as online patching. EBS 12.2 uses a new file system architecture called dual file system and edition-based redefinition features of Oracle Database to support the new online patching feature. The installation in this new release is RAC aware, so apps DBAs can install the EBS database tier into the ASM file system too. A new and enhanced user interface is among these innovations, as well.

My purpose with my blog is to illustrate all the skills required for implementing, configuring, and maintaining a robust Oracle E-Business Suite 12.2 environment.

To give the implementation information properly, as a matter of fact, in the next my blog we will start explaining the installation of EBS 12.2, followed by the upgrade techniques, and then we will continue with subjects such as the dual filesystem, the new patching concept, the new patching tool (adop), and FMW, which are introduced in EBS 12.2 and can considered as enhancements. Subsequently, we will explain the general EBS subjects such as Sysadmin fundamentals, AutoConfig, and performance tuning by focusing on these subjects in the context of EBS 12.2. Lastly, we will take a look at the implementation processes for implementing EBS 12.2 on Oracle-engineered systems because utilizing engineered systems such as the EBS platforms is the new trend.

Summary

In this first article, we introduced to you Oracle EBS by taking a look at the brief history of EBS and listing the EBS 12.2 applications and their product families.

We also explained EBS’s three-tier architectural model, the client-server communication model used in EBS 12.2, and the application and database tier components. We shed a light on the EBS 12.2 file system structure and gave you the technology stack changes from EBS 11i to the latest release EBS 12.2.

With the information we gave you in this article, you now have a general idea about an EBS 12.2 environment, so we think that it is time to proceed with more technical subjects.

Вас заинтересует / Intresting for you:

Business Rules with Oracle BPM 1886 views sepia Wed, 23 May 2018, 17:57:06

Oracle Endeca Information Disc... 1375 views Даниил Wed, 04 Jul 2018, 14:41:32

Oracle Solaris 11 introduction... 3398 views Валерий Павлюков Sat, 12 May 2018, 18:50:40

Oracle Endeca Information Disc... 1893 views Даниил Wed, 04 Jul 2018, 19:12:25