Friday Jul 27, 2012

Five Errors Customers Make When Migrating E-Business Suite 12 (Part 4)

This is the fourth in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, patching, upgrades, and maintenance. This article discusses migrations.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Exporting from a 9i database and importing into a fresh 10g/11g database.

ORACLE’S RECOMMENDATION: When working with 10g onwards you must use datapump. Refer to the opening section of the relevant import/export Note to establish database version compatibility for exports/imports (including datapump). When importing into a 10g or 11g database the source database must be 10g or later.

COMMON ERROR #2: Assuming that Linux x86_64 is a certified application tier platform for 11i.

ORACLE’S RECOMMENDATION: Linux x86_64 is only certified for the 11i database tier of the E-Business Suite. Linux x86_64 can be used as both an application and database tier platform with Release 12 onwards. There are no plans to certify Linux x86_64 as a platform for the 11i application tier. Linux x86_64 using any form of 32 bit emulation is also not a certified 11i application tier platform.

COMMON ERROR #3: Migrating the E-Business Suite environment to a new platform by performing a fresh install of the E-Business Suite using Rapidwiz on the new platform and then performing an export/import of the database.

ORACLE’S RECOMMENDATION: You must use the migration tools documented in the link below to migrate the application tier to the new platform. Only use Rapidwiz to create the new application tier technology stack.

COMMON ERROR #4: Migrating EBS 11i application tier servers to Exalogic servers.

ORACLE’S RECOMMENDATION: The Exadata platform is certified for use as a database tier for both 11i and R12. Both 11i and R12 require Oracle Database 11gR2. The Exalogic platform can be used as an application tier for R12 but not for 11i.

COMMON ERROR #5: Installing or upgrading your E-Business Suite technology stack components requires downloading the entire R12 installation media.

ORACLE’S RECOMMENDATION: It is possible to build a staging area that only contains the components you require. Refer to the E-Business Suite Installation Guide for instructions on how to build a partial staging area that contains only the technology stack or E-Business Suite components that you require.

References

Related Articles


Thursday Jul 26, 2012

Oracle Access Manager 11gR1 BP03 Certified with EBS 12

I'm pleased to announce that the Oracle Access Manager team has certified Oracle Access Manager 11gR1 Bundle Patch 3 (a.k.a. 11.1.1.5.3 or BP03) with E-Business Suite Release 12.  Applying Oracle Access Manager 11gR1 BP03 will provide you with the latest set of fixes for Oracle Access Manager 11gR1 which have been validated with Oracle E-Business Suite Release 12.

References

The following documents have been updated to include a new table listing Oracle Access Manager 11gR1 bundle patches that have been certified with Oracle E-Business Suite Release 12:

Related Articles

Friday Jul 20, 2012

Five Errors Customers Make When Patching E-Business Suite 12 (Part 3)

This is the third in a series of short articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, migrations, upgrades, and maintenance. This article discusses patching. Subsequent articles will cover migrating, upgrading, and general maintenance. Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Assuming that all patches can be applied using the hotpatch and nocheckfile parameters.

ORACLE’S RECOMMENDATION: The adpatch ‘hotpatch’ parameter should be used very sparingly and is not intended to be an easy way of applying patches to your system without shutting down the application tier services. Most patches should only be applied during scheduled downtimes when all users are logged off the system, application tier services have been shut down and Maintenance Mode enabled. From the adpatch documentation:

“If an emergency patch can be applied without shutting down services, the customized instructions generated by PAA will explicitly state so. If the customized instructions do not explicitly state this, assume that you need to shut down services and enable Maintenance mode before applying the patch.”

Similarly, the ‘nocheckfile’ parameter should not be used on all patches. Nocheckfile forces the patch to run all jobs in a patch regardless of whether the jobs have been run before. It degrades patch performance and should only be used in specific circumstances where it is genuinely needed. It should not be used as the default option for applying all patches. There are very few cases in which you would want to run with nocheckfile.


COMMON ERROR #2: Assuming that patches can be applied “manually” or backed out of “manually”.

ORACLE’S RECOMMENDATION: There is no manual alternative to using adpatch to apply a patch. It is not supported to selectively choose only certain files from a patch and manually copy or execute these files in your E-Business Suite environment. Similarly, there is no simple method of reversing a patch.

COMMON ERROR #3: Increasing the number of patch workers in an attempt to make patches run faster.

ORACLE’S RECOMMENDATION: Do not assume more workers automatically improves patch performance. When you first test a patch, accept the default number of workers. Use this as the performance benchmark. If you think a different number of workers will improve patch performance then try this once you have your default benchmark, but do not exceed the default number of workers without good justification for doing so. Once a patch is started, the number of workers cannot be changed mid-patch.


COMMON ERROR #4: Ignoring or skipping patch workers that fail on products that are not used or needed.

ORACLE’S RECOMMENDATION: You should aim to have zero errors when applying a patch. All E-Business Suite products are installed in the E-Business Suite database whether you are licenced to use them or not. Patches will update all products in the database whether they are licenced or not. If you find yourself having to skip jobs or ignore errors during patching then this indicates an underlying problem in your system that should always be investigated and addressed. Review the patch prerequisites and ensure all steps have been completed successfully.


COMMON ERROR #5: Using adpatch default log file names during patching.

ORACLE’S RECOMMENDATION: Identify each new patch log file with a unique patch log file name. If you always choose the default log file name in adpatch, your adpatch.log quickly becomes enormous. This makes it very difficult to identify individual patch information in the log file and makes it difficult to keep an accurate record of your patch history. Use a simple naming convention, e.g. choose a unique adpatch log name for each patch (<patchnumber>.log. Archive and then delete your main patch log and worker files after each patch so each patch has new log and worker files.

References

Related Articles


Thursday Jul 19, 2012

Latest DSTv18 Timezone Patches Available for E-Business Suite R12

Hourglass iconIf your E-Business Suite Release 11i or 12 environment is configured to support Daylight Saving Time (DST) or international time zones, it's important to keep your timezone definition files up-to-date. They were last changed in October 2011 and released as DSTv17.

DSTv18 is now available and certified with Oracle E-Business Suite Release 12. The DSTv18 update includes the timezone information from Olson tzdata 2012c. 

Is Your Apps Environment Affected?

When a country or region changes DST rules or their time zone definitions, your Oracle E-Business Suite environment will require patching if:

  • Your Oracle E-Business Suite environment is located in the affected country or region OR
  • Your Oracle E-Business Suite environment is located outside the affected country or region but you conduct business or have customers or suppliers in the affected country or region

The latest DSTv18 timezone definition file is cumulative and includes all DST changes released in earlier time zone definition files. DSTv18 includes changes to the following timezones since the DSTv17 release:

  • Africa/Casablanca,
  • America/Bahia,
  • America/Havana,
  • America/Port-au-Prince,
  • America/Santiago,
  • America/Blanc-Sablon,
  • Antarctica/Casey,
  • Antarctica/Davis,
  • Antarctica/Palmer,
  • Asia/Yerevan,
  • Asia/Gaza,
  • Asia/Damascus,
  • Atlantic/Stanley,
  • Europe/Minsk,
  • Pacific/Easter,
  • Pacific/Fiji,
  • Pacific/Fakaofo,
  • Cuba,
  • Chile/Continental,
  • Chile/EasterIsland

What Patches Are Required?

In case you haven't been following our previous time zone or Daylight Saving Time (DST)-related articles, international timezone definitions for E-Business Suite environments are captured in a series of patches for the database and application tier servers in your environment. The actual scope and number of patches that need to be applied depend on whether you've applied previous DST or timezone-related patches. Some sysadmins have remarked to me that it generally takes more time to read the various timezone documents than it takes to apply these patches, but your mileage may vary.

We've published the following Notes which identify the various components in your E-Business Suite environment that may need DST patches:

Related Articles

Wednesday Jul 18, 2012

New Whitepaper: Defining Web Applications Desktop Integrators That Return Error Messages

Oracle Web Application Desktop Integrator (Web ADI) is Oracle E-Business Suite's solution for integrating E-Business Suite applications with desktop applications such as Microsoft Excel, Word and Projects.  "Integrators" encapsulate the metadata and other information needed to integrate a particular Oracle E-Business Suite task with a desktop application.  You can use the Desktop Integration Framework (DIF) to create custom integrators for Oracle Web ADI in Oracle E-Business Suite Release 12.1.2. The ability to create custom importers was added in EBS 12.1.3.

I am pleased to announce the release of a new white paper that provides a step-by-step tutorial on how to use the Desktop Integration Framework to define a Microsoft Excel-based integrator.  The example in the tutorial shows how to define an importer that returns error messages for any spreadsheet rows that failed to import into an E-Business Suite database. It describes the steps in 3 phases: 

  • Preparing that database and application objects

This phase provides the sample code to create a custom table and PL/SQL package which will be used for importing the data from a Microsoft Excel spreadsheet into an E-Business Suite table. It also describes the steps to create an FND Lookup code and its value, which will be used to map error codes and their corresponding messages.

  • Phase A: Defining an integrator that downloads and uploads data

This phase provides the steps to create a basic integrator using the Web ADI Desktop Integration Framework. It describes the steps to define the integrator's Interface, Content, Uploader, Layout, and Mapping.

  • Phase B: Defining an integrator importer that returns error messages

This phase provides the steps to define importer. It extends the integrator definition to process the data uploaded in the interface table and return error messages back to the desktop document for any rows that failed to import.

Screenshot of SQL query definition screen

The intended audience of this document is custom desktop integrator developers who are familiar with Oracle E-Business Suite and Oracle Web Applications Desktop Integrator.

Your feedback is welcome

We are very interested in hearing about your experiences with this new tool.  Please post your comments here or drop me an email at email.jpg

Download the new whitepaper

The white paper is available in two places -- Oracle Learning Library (OLL) and My Oracle Support:

References

Related Articles

Tuesday Jul 17, 2012

Critical Patch Update for July 2012 Now Available

The Critical Patch Update (CPU) for July 2012 was released on July 17, 2012. Oracle strongly recommends applying the patches as soon as possible.

The Critical Patch Update Advisory is the starting point for relevant information. It includes a list of products affected, pointers to obtain the patches, a summary of the security vulnerabilities, and links to other important documents.

Supported products that are not listed in the "Supported Products and Components Affected" Section of the advisory do not require new patches to be applied.

Also, it is essential to review the Critical Patch Update supporting documentation referenced in the Advisory before applying patches, as this is where you can find important pertinent information.

The Critical Patch Update Advisory is available at the following location:

The next four Critical Patch Update release dates are:

  • October 16, 2012
  • January 15, 2013
  • April 16, 2013
  • July 16, 2013
E-Business Suite Releases 11i and 12 Reference

Monday Jul 16, 2012

Five Errors Customers Make When Cloning E-Business Suite 12 (Part 2)

This is the second in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, patching, migrations, upgrades, and maintenance. This article discusses cloning. Subsequent articles will cover patching, migrating, upgrading, and general maintenance.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day-to-day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1
: Assuming that use of the Rapid Clone utility is optional when cloning your Apps environment.

ORACLE’S RECOMMENDATION: Rapid Clone greatly simplifies the process of cloning your E-Business Suite environment. Simply copying your E-Business Suite environment to new host machines, editing the context files to reflect the new environment and then running AutoConfig is not a supported cloning method. Devising your own cloning methodology that bypasses Rapid Clone is a dangerous strategy. If Rapid Clone does not work for you, then raise a Service Request and ask for help in fixing the issue. Do not create an alternative cloning method that you hope will sidestep whatever issue you are seeing.


COMMON ERROR #2
: Assuming that the preclone scripts only need to be run once on an environment.

ORACLE’S RECOMMENDATION: You must run the preclone scripts immediately before each clone, prior to shutting down the application and database tiers in order to copy the files for cloning (or RMAN backup). It’s also good practice to remove or rename the database tier $ORACLE_HOME/appsutil/clone and application tier $COMMON_TOP/clone before running the preclone script. Always check the cloning documentation for the latest patches before each clone.


COMMON ERROR #3
: Mistakenly using Rapid Clone to migrate from 32 bit Linux to 64 bit Linux.

ORACLE’S RECOMMENDATION: Although these platforms are binary compatible, cloning your E-Business Suite from 32 bit Linux to 64 bit Linux will only produce a 32 bit E-Business Suite environment on your 64 bit operating system. In order to fully exploit your 64 bit operating system you should follow specific migration documentation for your E-Business Suite environment. The same applies to other certified operating systems available as both 32 and 64 bit.


COMMON ERROR #4
:  Mistakingly forgetting to update the central inventory when overwriting a previous clone with a new clone in the same location.

ORACLE’S RECOMMENDATION: If you regularly repeat a clone to the same location on a target node, you must ensure the central inventory entries for the previous clone are removed before configuring the new clone. As with a repeated installation, when deleting an E-Business Suite environment prior to cloning to the same location, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new clones may fail.


COMMON ERROR #5: Assuming that the clone is not a completely accurate copy.

ORACLE’S RECOMMENDATION: A system created using Rapid Clone is the most genuine and supported copy you can create. It has an identical database, application tier and technology stack as the source environment it was created from. The only significant difference between a source and target clone environment is the data specific to the new hardware (node names, directory locations etc.). It is supported to clone your production environment, apply patches to the clone and then clone the patched system back to become your new production environment. Assuming the cloning documentation is followed correctly, an E-Business Suite environment does not degrade through being repeatedly cloned.

References

Related Articles

Friday Jul 13, 2012

Five Errors Customers Make When Installing E-Business Suite 12 (Part 1)

One customer recently asked if we could supply documentation and scripts to remove all the E-Business Suite objects from their database leaving them with an empty database. After a few questions, it became apparent they were concerned about performance and a third party consulting organisation had advised the best solution to performance problems was to export and then import the whole database.

Whilst it’s true an export/import might solve performance problems, there are many other things you can do before you conclude the best solution is an export/import; it’s certainly not the default solution. That’s a pretty extreme example but there are quite a few myths and misunderstandings which seem to crop up regularly in Service Requests.

This is the first in a series of short articles that lists a few of the technical myths or misunderstandings about Oracle E-Business Suite. Other articles have covered cloning, patching, migrations, upgrades, and maintenance. This first article discusses installations.

Each article is absolutely not definitive and I’d be particularly interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: In a global implementation, putting your database tier host in your global data centre and putting local application tier hosts in each country.

ORACLE’S RECOMMENDATION: You must put all host nodes of your E-Business Suite environment in one data centre with the fastest possible network connection between nodes. This applies regardless of the location of your users.


COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.


COMMON ERROR #3: Installing only the default database character set although you know that you will need a different character set later.

ORACLE’S RECOMMENDATION: Failing to consider national language support (NLS) and database character set requirements when installing a new environment is a critical mistake. You should normally have a very good idea of language requirements before you start your installation. Implement the correct languages and database character set when you perform your installation. Characters sets can be changed later and languages can also be added but if you think you are going to need them then implement them early in your project. Realising that you have forgotten the purchasing team in Denmark the day before you go live will not make you a popular DBA.

You cannot specify a different character set when upgrading to R12. The R12 upgrade process cannot do a character set conversion.


COMMON ERROR #4: Separating Oracle database and application tier ownership by different operating system users/groups.

ORACLE’S RECOMMENDATION: In simple single node installations the whole E-Business Suite file system (including the database) can be owned by a single user/group. This can simplify installation and maintenance. Oracle documentation and Oracle Support engineers sometimes refer to the ‘applmgr’ user and the ‘oracle’ user. These are generic terms used loosely to describe the operating system owner of the application and database tier file systems respectively – they are not mandatory user names. It is also not mandatory to perform E-Business Suite installations as the root user.


COMMON ERROR #5: Before retrying a failed installation, forgetting to remove its entries from the central inventory.

ORACLE’S RECOMMENDATION: When deleting an E-Business Suite environment, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new installations may fail.

References

Related Articles

Monday Jul 09, 2012

Webcast Replay Available: Scrambling Sensitive Data in E-Business Suite Release 12 Cloned Environments

I am pleased to release the replay and presentation for ATG Live Webcast:

Scrambling Sensitive Data in EBS 12 Cloned Environments (Presentation)

E-Business Suite Data Masking Architecture

Eric Bing, Senior Director, Jagan Athreya, Enterprise Manager Product Management, and Elke Phelps, Senior Principal Product Manager, discussed the Oracle E-Business Suite Template for Data Masking Pack, and how it can be used in situations where confidential or regulated data needs to be shared with other non-production users who need access to some of the original data, but not necessarily every table.  Examples of non-production users include internal application developers or external business partners such as offshore testing companies, suppliers or customers. (July 2012)

Finding other recorded ATG webcasts

The catalog of ATG Live Webcast replays, presentations, and all ATG training materials is available in this blog's Webcasts and Training section.

Friday Jul 06, 2012

Building Extensions Using E-Business Suite SDK for Java

We’ve just released Version 2.0.1 of Oracle E-Business Suite SDK for Java.  This new version has several great enhancements added after I wrote about the first version of the SDK in 2010.  In addition to the AppsDataSource and Java Authentication and Authorization Service (JAAS) features that are in the first version, the Oracle E-Business Suite SDK for Java now provides:

  • Session management APIs, so you can share session information with Oracle E-Business Suite
  • Setup script for UNIX/Linux for AppsDataSource and JAAS on Oracle WebLogic Server
  • APIs for Message Dictionary, User Profiles, and NLS
  • Javadoc for the APIs (included with the patch)
  • Enhanced documentation included with Note 974949.1
Integration between custom apps and EBS

These features can be used with either Release 11i or Release 12. 

References

What's new in those references?

Note 974949.1 is the place to look for the latest information as we come out with new versions of the SDK.  The patch number changes for each release.  Version 2.0.1 is contained in Patch 13882058, which is for both Release 11i and Release 12.  Note 974949.1 includes the following topics:

  • Applying the latest patch
  • Using Oracle E-Business Suite Data Sources
  • Oracle E-Business Suite Implementation of Java Authentication and Authorization Service (JAAS)
  • Utilities
  • Error loggingSession management 
  • Message Dictionary
  • User profiles
  • Navigation to External Applications
  • Java EE Session Management Tutorial

For those of you using the SDK with Oracle ADF, besides some Oracle ADF-specific documentation in Note 974949.1, we also updated the ADF Integration FAQ as well.

EBS SDK for Java Use Cases

The uses of the Oracle E-Business Suite SDK for Java fall into two general scenarios for integrating external applications with Oracle E-Business Suite:

  1. Application sharing a session with Oracle E-Business Suite
  2. Independent application (not shared session)

With an independent application, the external application accesses Oracle E-Business  Suite data and server-side APIs, but it has a completely separate user interface. The external application may also launch pages from the Oracle E-Business Suite home page, but after the initial launch there is no further communication with the Oracle E-Business Suite user interface.

Shared session integration means that the external application uses an Oracle E-Business Suite session (ICX session), shares session context information with Oracle E-Business Suite, and accesses Oracle E-Business Suite data. The external application may also launch pages from the Oracle E-Business Suite home page, or regions or pages from the external application may be embedded as regions within Oracle Application Framework pages.

Both shared session applications and independent applications use the AppsDataSource feature of the Oracle E-Business Suite SDK for Java. Independent applications may also use the Java Authentication and Authorization (JAAS) and logging features of the SDK.

Applications that are sharing the Oracle E-Business Suite session use the session management feature (instead of the JAAS feature), and they may also use the logging, profiles, and Message Dictionary features of the SDK.  The session management APIs allow you to create, retrieve, validate and cancel an Oracle E-Business Suite session (ICX session) from your external application.  Session information and context can travel back and forth between Oracle E-Business Suite and your application, allowing you to share session context information across applications.

Note: Generally you would use the Java Authentication and Authorization (JAAS) feature of the SDK or the session management feature, but not both together.

Send us your feedback

Since the Oracle E-Business Suite SDK for Java is still pretty new, we’d like to know about who is using it and what you are trying to do with it.  We’d like to get this type of information:

  • customer name and brief use case
  • configuration and technologies (Oracle WebLogic Server or OC4J, plain Java, ADF, SOA Suite, and so on)
  • project status (proof of concept, development, production)
  • any other feedback you have about the SDK

You can send me your feedback directly at Sara dot Woodhull at Oracle dot com, or you can leave it in the comments below.  Please keep in mind that we cannot answer support questions, so if you are having specific issues, please log a service request with Oracle Support.

Happy coding!

Related Articles

Tuesday Jul 03, 2012

Webcast Replay Available: Technical Preview of EBS 12.2 Online Patching

[Sep. 20, 2013 Update:  EBS 12.2 is now available for download.  See this article for details.]

I am pleased to release the replay and presentation for ATG Live Webcast:

Technical Preview of EBS 12.2 Online Patching (Presentation)

Online patching editions

Kevin Hudson, Senior Director and one of the Online Patching architects, discussed one of the cornerstone new features in our upcoming Oracle E-Business Suite 12.2 release. This ground-breaking feature is based upon Edition-Based Redefinition, a new 11gR2 Database feature that was built to Oracle Applications division specifications to allow the E-Business Suite's database tier to be patched while the environment is running.  Online Patching combines the use of Edition-Based Redefinition and new E-Business Suite technologies to allow patching to the E-Business Suite's database and application tier servers while the environment is being actively used by its end-users. (June 2012)

Finding other recorded ATG webcasts

The catalog of ATG Live Webcast replays, presentations, and all ATG training materials is available in this blog's Webcasts and Training section.

About

Search

Categories
Archives
« July 2012 »
SunMonTueWedThuFriSat
1
2
4
5
7
8
10
11
12
14
15
21
22
23
24
25
28
29
30
31
    
       
Today