What is Oracle E-Business Suite?

What is Oracle E-Business Suite?

Oracle E-Business Suite (i.e., Oracle Applications, Oracle Apps, Oracle Financials, Oracle Manufacturing, Oracle CRM) is the suite of products that used to be called Oracle Financials. Oracle Financials was first released in the late 1980s and has evolved into a full-fledged solution for enterprise processes for companies of nearly any size . The Oracle E-Business Suite contains over 55 integrated modules for financial management, supply chain management, manufacturing management, project management, human resources management, and sales force automation all pulled together to provide business automation. Oracle E-Business Suite combines ERP and CRM into one fully integrated package that can meet all of a company's needs. Oracle E-Business Suite can provide a company with business performance metrics, current financial ratios, profit and loss report summaries, and other information that can be tracked across departments, across product lines, even across geographies. It allows information to be shared across the enterprise. It further allows a company to centralize a single definition of what a customer is, what a supplier is, what an employee is, a business partner is, or product is, and maintaining this definition and its connected information across the enterprise. Oracle E-Business Suite allows upper management to access its business intelligence information and take immediate action when situations warrant it. The Customer Resource Management module allows a company to manage customer information, from leads to sales to revenue through multiple channels of input (e.g., Web, phone, mail order, or e-mail).

Oracle E-Business Suite also incorporates a powerful, flexible combination of state-of-the-art technology integrated to aid in rapid implementation. Various implementations in varying configurations can be found in shops with fewer than 200 employees to many of the Fortune 500 companies. Oracle Applications 11i also brings the evolution of the core technology, which saw its start with terminal emulation, to true Internet computing architecture. Where, in past releases, users needed some special piece of software installed on their workstations to run Financials (these could have included a terminal emulation package or Forms and Reports executables or the like), now the only piece of software that is really necessary to use Apps 11i is a Java-compliant browser. The only Oracle E-Business Suite specific software today that ends up on the end user 's computer is a Java applet (JInitiator client platform) that is downloaded and cached the first time the PC connects to applications. This new, evolved architecture has opened the door for new modules and new functionality.

Difference between an Apps DBA and a Regular DBA

The question is often raised: What is the difference between a regular Oracle DBA and an Apps DBA? While the answer may sound trite, the difference is what you make it. There are many different thoughts on this from many different people. Some people suggest that there is no difference and to an extent that is probably true. In reality, Apps DBAs are regular DBAs who have to remember and be concerned with a variety of additional influences. Further, Apps DBAs will likely work closer with other people, or teams of people, with whom they may never have been involved, before.

You, the Applications DBA, will be responsible for managing, sizing, maintaining, and tuning the database (just like any DBA). Your Apps database is an OLTP (online transaction processing) system. Along with the other responsibilities, go all of the wait and lock concerns that you would have in any transactional system. Oracle E-Business Suite also has some fairly hefty batch jobs (e.g., some creating reports, others bringing data in from outside sources, and still others doing massive calculations on the existing data). The scheduling and specifics of these jobs are not going to be under your control. You will have little to say about when they are kicked off or run. These jobs will be run at the discretion of the finance or accounting departments; therefore, it is important to maintain a harmonious working relationship with them and an open line of communication. Oracle E-Business Suite is also, potentially , a Business Intelligence System (BIS) and can have many of the same kinds of reports run against it that could be run on a data warehouse. After all, you are dealing with your company's financial data over time. This will be the kind of information that the executives want to run historic reports, trends, and what if scenarios on. Tuning will become a problem at some point for you. These factors combine to bring many sizing and performance concerns that go along with a reporting and a batch environment, an in-depth analysis system and a transactional system. What follows is a list of 11 things that you may want to consider as part of what it means to administer Oracle Applications and just a few of the jobs that you will have as you proceed through the often thorny environment that you now find yourself.

1. Get familiar with Concurrent Managers; there are no friendly manuals that you can read to help you with these or any in-depth documents to help. Chapter 9 — Installation and Migration will help you along the way and will point you at some other information that may be of assistance.

2. Remember that, while you run mostly a transactional system with the end users entering row at a time information through the interface, you are not dealing with a true OLTP system. When a batch gets kicked off through a concurrent request is not usually under your control. An end user from the finance department may decide when to submit a payment batch and not realize that there may be ramifications to that decision. The more modules that you implement and the more people who have reason to submit a resource intensive batch process, results in a greater impact that these processes will have on your system. Excellent communications and coordination between you and all of the stakeholders will make your life easier.

3. Never apply a patch to the production databases unless you have tested it multiple times and get user acceptance testing done and end user sign off that the patch in question both fixed the problem that it was meant to fix (for a patch that is applied to fix a problem) and that it did not have any unforeseen side effects or break anything in the system (for all patches that are applied). Remember, it is quite likely your fault if a patch breaks production.

4. Document all the patches: the day applied, the reason for applying, the errors that they were supposed to solve, and the errors created after applying. Keep the logs of all the patches and do not ever erase them; Oracle will ask for that patch log after maybe six months when one of your current patches bombs . More on patch documentation and patching can be found in Chapter 10.

5. Remember that Oracle Applications is heavily indexed; rebuilding the indexes periodically will improve performance significantly. There is a Concurrent Process that will help you with performing this action. Try to schedule it for a time when there is a minimum of users on the system.

6. Monitor the rollback segments. This is probably one of the most important and one of the trickiest parts . This is particularly true if you have not implemented Automatic Undo Management. (See Chapter 2 — 11i, 8i, and 9i New Features for more on this Oracle 9i feature.) If, for example, a Concurrent Program fails because it is not able to allocate rollback segments, the whole program is rolled back and this can clog the CPU (central processing unit) because of the extreme backup of other programs in the concurrent queue. Often, this will leave behind interim tables and indexes that have to be cleaned up carefully and manually. Extreme care must be taken with the interim tables as other programs may reuse them for reporting, posting, purging, or other functions.

7. Never attempt to add additional indexes for performance without first asking Oracle Support. It is Oracle's application and Oracle Support should know better than anyone if the addition of your proposed index is liable to make the core application perform worse . If you do attempt some changes, make sure that you document exactly what you did. The next patch you apply would quite probably identify the changes that you made and replace them with the canned functionality, placing you back at square one.

8. Understand how patch application works. You will be spending a great deal of time involved with some portion of patching: from planning which patches to apply, to acquiring the patches, to applying the patches, to testing and documenting post patching, just in time for the next time you start planning which patches to apply next. Chapter 10 — Patching will help with this.

9. Know that there will be many invalid objects any time that there are any changes made to the database. Any time you do anything that might have an affect on the database, check the number of invalid objects, and periodically run utlrp to recompile them. Utlrp.squ, located in the Oracle Home Directory's rdbms/admin subdirectory, is responsible for compiling invalid objects. When run as the 'SYS' user, it attempts to recompile all invalid objects to all schema owners . Anytime that you encounter a new error, check for invalids and recompile the database first before initiating an iTAR (Internet created Technical Assistance Request).

10. Understand Alerts. Especially understand Periodic and Event Alerts and understand how they differ from database triggers.

11. Remember, being an Apps DBA is pretty simple. With the exception of setting up printers (which can be tricky due to initialization settings) everything is fairly straightforward and you will learn quickly. You will soon become at ease in your environment.

You will create test and development databases (maybe more) and you will keep them refreshed by copying (cloning) the production database. How many instances you choose to create and maintain is enterprise dependent. Much of the decision on exactly how many databases will depend on what the business dictates. Minimally, I suggest having at least three complete and separate environments and four complete sets is even better. First, have a development environment where your developers can develop custom reports and custom PL/SQL (Procedure Language extension to Structured Query Language) packages to support those reports. This environment can be refreshed on a move up cycle or whenever the developers feel that the data is no longer representative of what is in production. This is likely the first environment into which to apply patches. Next, have a test environment where you apply patches before final user acceptance testing and user signoff. Test should be as close as possible to production data before a patching cycle starts, so that the end users can test with data as fresh as possible. Finally, you will have your production environment. Production is self-explanatory. Optimally, you will have a fourth environment: I will call it patching (if you installed the vision environment, you can use this for the patching environment). Patching is where you can apply patches and fix them when they break without having any impact on any of the users of the system. This is a place you can consider your playground. You can test out changes to the system without worrying if your changes are breaking anything or if they are having ill effects on what anyone else is doing.

Cloning (see Chapter 11) is making an exact duplicate environment (both the applications layer and the database layer) against which patches are applied and tested, reports are written and tested, upgrades start and are tested, and in which problems are fixed and the fixes tested all before any of these goes to production.

Patches, both ORACLE Applications and RDBMS (relational database management system) patches, will need to be applied and tested. These should start in the development database (unless you have one just for patching) and migrated to test and later to production. You will need to have a handle on how to patch, patch management, and version control of all of your individual systems.

Further, in your capacity as applications administrator, you can likely find yourself involved in the following roles:

• Oracle Applications DBA

• Capacity planning and sizing the hardware

• Architecture and design of the Applications system

• Installation of Applications 11i with respect to planned architecture

• Instance management

• Cloning Applications 11i and scripts

• Splitting and merging the nodes, single node to multiple node and vice versa

• Workflow installation and configuration and setting up test workflow

• Oracle WebServer (OWS), Oracle Application Server (OAS) tuning

• Tuning Apache

• Application security, post-implementation

• Tuning Concurrent Managers

• Tuning application UNIX server and identifying issues

• Tuning scripts and other Application troubleshooting

Finally, installs and upgrades will be your responsibility, as well as making sure those upgrades and installs are supported. Oracle Support does not support many release configurations and if you choose to install one of these configurations (e.g., 11.5.8 with a Version 8.0.6 database), you will likely not be able to rely on Oracle Support if something goes wrong. Oracle Support's solution will be to upgrade to a supported configuration. Always make sure that any installation or upgrade is a supported combination. This means the operating system (OS) version with the middle tier, the OS version with the database, and the middle tier with the database. Along with dealing with upgrades, you will need to know how to handle any customizations that were done to your system, so they can be handled in the upgrade process. This includes program units, interim tables, custom reports, and custom forms.

You also need to determine the timing and type (e.g., hot, cold, Recovery Manager, or any combination) of backups and when you can practice your recoveries . Remember, if you do not know (have not practiced) that you can recover using your backup method of choice, you do not have a backup and recovery plan. A backup is worthless if you cannot recover from it.

Most likely, you will be responsible for starting and stopping the Concurrent Managers and managing their functionality and performance. It may be your responsibility to create request sets for users to use to submit reports and batch jobs.

The help desk will probably turn to you when it is alerted to a problem. You will be the second tier support.

You may be called on to administer other pieces that are used in conjunction with your Apps install. These may include Discoverer, Forms and Reports, and other software used inhouse that interfaces with Oracle E-Business Suite. When custom programs, forms, or reports are created or altered , adding these to the system and registering them with Applications will also become something that you do. Again, this is where you will have to have a handle on versioning and version control.

Interim tables, their functions, and what they can and should do are also things that you will have to have a hand in, at some point. Interim tables are the means by which you get external data into your financials database from outside sources. These are the only tables that anyone should ever need to touch from a design standpoint.

Applications' middle tier and the database are intricately connected; that is part of what makes it such a powerful and complex piece of software. What affects one piece often affects others and usually affects the whole. If there are server problems on the database tier, they can become painfully obvious to your users accessing the Apps front end. If a form is not performing correctly, you could see performance issues on your database. Many times, following a patch installation, completely untouched forms and reports will change how they are acting or cease functioning. Concurrent Managers, regardless of what tier they reside on, can create their own sets of interesting problems.

You will also need to have a working knowledge of Oracle's Apache Server and the iAS Suite and their foibles on your OS. JServ, Apache, and the internals to iAS that come with Oracle Apps are what allow your users to access your system cleanly.

There are Forms and Reports Servers running on the middle tier. Those may become something that you need to maintain during a patch cycle or upgrade, if at no other time.

Metalink (http:// metalink .oracle.com) is an invaluable tool that you will turn to on a regular basis. You will become better and better at finding notes and solutions to the problems that will be laid at your doorstep. This is where you will download patches, research problems, and find considerable documentation and white papers. It will also be a source of much frustration, because an iTAR may be assigned to a very good analyst (which will make solving problems simpler) or to someone who will run you around in circles and add greatly to your frustration (which will likely make you wonder how any problem ever gets solved ). Bear with it; in the end they are one of your best resources. Chapter 11 — Cloning will give you more information on what is involved in dealing with Oracle Support.

To better serve your end users, you will have to gain some basic understanding of the underlying structure and architecture. If there are other systems feeding your installation, you may need to understand where the data comes from and what could, potentially, go wrong in the transfer. You do not have to know everything about accounting and FASB (Financial Accounting Standards Board), but it does help to know things like AR is accounts receivable (money that is coming into your company), AP is accounts payable (money going out), and GL is general ledger (the accounts that the money goes into and out of).

If you are dealing with any Windows version as your middle tier, you will need to have a basic understanding of registry entries and how that can affect you and the differences in how path and environment variables are set. If you have multiple instances running on a Windows machine, the complexity of your install will be increased, the software components that come into play are increased, but some of the solutions to really weird problems can be simpler.

Besides you, who is responsible for what? It will be helpful to your organization to have a help desk to which the functionals and other technical people can turn when there is a problem, a point of contact. If you have one of these, it can add layers through which problems need to be routed that may be time consuming, but it also might be a way to centrally track if you are having ongoing similar types of problems and the resolutions to them.

System administrators ( sysadmins ) will most likely install, upgrade, or replace the OS and any of the hardware on which the pieces of your installation reside. They will monitor disk usage and physically perform the backups. A combination of administrators may also maintain and manage the physical printers and print queues. Although, defining those printers to the applications may be your responsibility.

Above all, you will be dealing with some of the most complex and powerful software that you may ever have been connected with. The parts of this application cannot be treated entirely independent of each other.

In short, an Apps DBA will need to know a little bit about a lot of things. This book will help you along the way.

Similar products

• 

  Oracle E-Business Suite Development & Extensibility Handbook (Oracle Press)

• 

  Oracle E-Business Suite Financials Handbook (Osborne ORACLE Press Series)

Similar products