Öñ¼ä¸ó

In this Document
  Goal
  Solution
     What is a Focus Issue?
     Why are Focus Issues Experienced?
     Symptoms Indicating a Loss in Focus
     Strategy for Investigating and Resolving Focus Issues
     The Right Checks to Ensure it's a Focus Issue
     Fixing Known Focus Issues
     Determining the Current Forms Version and MLR Patch (Release 11i)
     Determining the Current Forms Version and MLR Patch (Release 12)
     Setting Expectations on Results After  MLR Patch Application
     Gathering the Right Information
     Debugging Steps for Focus Issues
     Reporting a Focus Loss to Oracle Support Services
     History
  References

Applies to: Oracle Applications Technology Stack - Version: 12.1
Oracle Applications Technology Stack - Version: 11.5.10 to 11.5.10.2
Oracle Applications Technology Stack - Version: 12.0
Information in this document applies to any platform.
Goal

With the move to using Sun's Java Runtime Environment (JRE) on the client desktop instead of Oracle's Jinitiator for E-Business Suite Release 11i (Release 12 only uses Sun's JRE) some users are reporting intermittent or random problems with maintaining cursor focus when using the mouse whilst, in the main, keyboard navigation works as normal.

The aim of this article is to raise awareness, knowledge and understanding of what have now been commonly termed as "Forms Focus Issues" or "Focus Issues" in E-Business Suite R11i and R12. It will do so by providing information on how to diagnose, analyze, and debug this type of problem.

Before proceeding please note the following points:

• Users reporting a problem with mouse navigation in Forms. Since the symptoms or behaviour is identical in many cases this seems to point at a single issue. However, the same symptoms do not mean the same cause. Existing cases also show there can be multiple issues occurring, with each one needing to be addressed individually for a complete resolution.
  
• Users reporting focus problems as 'intermittent' or "random" with no pattern. Once the problem starts mouse navigation doesn't work any more giving the impression it happens everywhere. However, when investigating the problem it's often possible to narrow down the user's actions or events that trigger the problem allowing it to be reproduced at will. 

A focus issue is a specific series of user actions and/or internal events that causes the Forms Focus Model to break down with the event queues that maintain synchronicity or 'state' between the client and middle tier becoming out of synch i.e the client believes focus is in ITEM A whilst the middle tier believes focus is in ITEM B. By the time the user notices the symptoms the series of steps or events that caused  the problem may have long since past giving the impression that the loss in focus is random when it's not.

Typically the user has to exit their application's session and log back in to begin working as normal again.

• The focus model and event queue management that spans the middle and client tiers is a complex and sensitive area of code.
• The forms applet on the client executes within Sun's Java Runtime Environment (JRE) and is subject to changes within it's event model.
• Changes to fix one problem can have a knock on effect causing another that may not be immediately obvious.
• It's difficult to identify focus issues during Certification and QA as each one requires a very specific series of user actions and/or internal events.

If a user reports some of the symptoms mentioned below this is an indication that they have run into a focus issue.

Navigation

• Users not being able to navigate to another item using the mouse. The cursor returns to previous item when clicked on another. However, navigation using keyboard works as expected.
• The current record indicator does not move to another record when clicked in a multi-record block.
• Navigation doesn't work as expected when switching to another application and back.
• Having to click in the java console window or completely restarting the browser to correct navigation problems.

Data Entry

• The first character of an entry being highlighted and then over written by the second.
• User facing problems entering data into a text field using the mouse.
• Focus issue is not seen when user enters data using keyboard.

List of Values (LOV)

• LOV clicked in one item opens the LOV of another item.
• Use the mouse to go to any LOV. Selecting the LOV button raises "FRM-41026: Field does not understand operation". 

Focus issues are highly visible and can be a source of frustration for E-Business Suite users. Before going into the detailed steps it's useful to understand the general approach and strategy for investigating and resolving this type of problem.

1. Confirm the users problem has the characteristics commonly associated with focus issues.
2. Verify the problem is not being caused by custom code or product code sending the focus to a disabled item. In these situations the owner of the custom code or product team must be involved to fix the problem.
3. Many focus issues have already been identified and fixed. To resolve these known issues ensure the environment has the latest Merge Label Request (MLR) patch is applied. It's also highly recommended to upgrade to the latest certified Forms version (R11i - Patchset 19, R12.0 - Forms 10.1.2.3). For these versions new MLR patches are automatically requested and released, while for older versions MLR's are only created upon request and with supporting justification.
4. If the problem persists after applying the latest MLR further analysis is needed to diagnose the problem. In this article a number of steps are discussed including what information to collect about the circumstances of when the problem occurs. The most important, but also most difficult and potentially time consuming, step is to identify the steps to reproduce the problem and create an internal test case.
5. Based on the internal test case it may be needed to have a bug logged with Development. These will further analyse and release a fix to address the new Forms Focus issue.

When investigating a suspected focus issue start by verifying the following:

• Do the symptoms match those typically seen for a loss in focus?
• Does the problem reproduce with custom code turned off?
  • This confirms if the problem is reproducible with the seeded form.
  • If the problem does not occur when custom code is turned off the issue is related to customizations and must be further investigated first from that perspective. 
  • Verify if with the custom code enabled the FRM-40112 can be reproduced (see below). In this case the custom code must be rectified to stop sending the cursor to a disabled item.
• Does Help->Diagnostics > Examine show the correct block and item? 
  • Type SYSTEM in 1st field, CURSOR_ITEM in 2nd field. Value appears in the 3rd field.
  • If after the navigation was done the correct block and item are reported the navigation was successful and it's less likely to be a focus issue.

• Does the user see or does the Forms Runtime Diagnostics (FRD ) log contain a  'FRM-40112: Attempted go_item to non enabled item' after setting environment variable FORMS60_REJECT_GO_DISABLED_ITEM=1 (11i) or FORMS_REJECT_GO_DISABLED_ITEM=1 (R12)?

  • This environment variable must be set before starting the Forms Servlet or Forms Server

  • If the problem does not reproduce with this environment setting enabled and a FRM-40112 is raised the product team should be involved for rectifying their code to stop sending the cursor to a disabled item.

• Does the same steps reproduce the same symptoms
  

  • On multiple environments?

  • With the latest JRE?
  • With the lasted certified forms patch set?
  • With an alternative browser?

Identifying, diagnosing and fixing focus issues can be difficult, complex and time consuming. Many focus issues have already been identified and resolved so it's recommended to apply the latest Forms MLR patch. This means that no time is lost diagnosing problems that already have a resolution.

Forms version

Check the current Forms version as follows: 

• In Forms session select menu 'Help > About Oracle Applications...'. The section Forms Server shows a line like:

----------------------------------------
Forms Server
----------------------------------------
Oracle Forms Version : 6.0.8.28.0

Note: For ATG_PF.H RUP5 or higher the user must have profile 'FND: Diagnostics = Yes' to see values in this section.

OR

• Open telnet/PTTY connection to server and source APPS environment
• Call the Forms runtime executable using:

# f60run \? | grep Forms | grep Version | awk '{print $6}'

• This shows the version of Forms used, for example:

6.0.8.28.0

The Forms version must be one of the below to be certified using Sun JRE instead of JInitiator.

Form version	Patchset
6.0.8.27	18
6.0.8.28	19

Latest MLR Patch

The latest MLR patch can be checked using following references:

There are 2 ways to verify if MLR patch is applied:

The simplest method is to check if backup files are available. The README advices to backup existing classes by doing a copy from <xxx>.class to <xxx>.class_PRE_BUG<YYYYY>. For example the "FormsMouseWheelHandler.class.PRE_BUG7156414" indicates that Patch 7156414 was applied.

It's however a bit tricky to rely only on the availability of backup files for the following reasons:

• The backup files are the result of manual copy action. When this step is skipped and only the classes from the patch are copied over the existing ones there are no backup files. Although not recommended it is possible to delete backup files after patch application. In both cases the 'evidence' the patch is applied is not visible anymore
• There is no mechanism (as in adpatch) to verify the class delivered in the patch is newer then the existing class. If an older MLR patch is 'reapplied' you simply copy the class from the patch over the existing class. This leads to a situation where backup files indicate the newer patch is applied, while in fact the classes from an older patch are used.

For example:

• (New) Patch 7482264 is applied delivering the UICommon.class with a size of 23480 bytes.
• Later (old) Patch 7156414 is reapplied delivering the UICommon.class with a size of 23466 bytes
• Despite UICommon.class.PRE_BUG7482264 is found indicating Patch 7482264 is applied, the reality is that fndforms.jar includes the UICommon.class from (old) Patch 7156414.

When not taking proper care here you easily end up in a situation where APPS DBA reports "Patch XXX is applied" while users testing report "Problem is not fixed" because the expected fixes are not included in the Forms JAR files.  

Also after applying the MLR patch the Forms JAR files must be regenerated using ADADMIN. This  makes that the 'native' Forms classes will be included in the 'Applications' JAR files downloaded to the client PC. When this action is not performed the Applications JAR files still include old versions of the classes, even when the steps from README of the MLR patch are performed correct.

To rule out any doubts on classes downloaded to the client PC the best way is to verify which classes are included in $OA_JAVA/oracle/apps/fnd/jar/fndforms.jar. 

Perform the following to verify the classes delivered in fndforms.jar

• Run the following command to save a listing of the contents to a file.

# unzip -l $OA_JAVA/oracle/apps/fnd/jar/fndforms.jar >> fndforms.lst

• Open the MLR patch in Winzip showing the classes delivered.
• Compare the sizes of the classes delivered in the MLR patch with the sizes listed in fndforms.lst.

If the sizes match it's confirmed the expected classes from the MLR patch are used. In case these are not the same further investigation is required.

• Check the size of the class saved in $ORACLE_HOME/forms60/java. For example the 'oracle/forms/handler/UIComm.class' in the patch is copied to $ORACLE_HOME/forms60/java/oracle/forms/handler/UICommon.class.

If the class found matches the one from the MLR patch it shows the patch was applied, but the Forms JAR files were not regenerated using ADADMIN, so this needs to be done as follows:

• Start ADADMIN and select '1. Generate Applications Files menu' followed by '5. Generate product JAR files'. It will be best to use the Force option to make sure all JAR files are refreshed.

If the classes found do not match the classes from the MLR patch expected to be applied this indicates the patch was not applied or other patch was applied later delivering different classes. In this case perform the following

• Make sure that the MLR patch being checked is indeed the latest (*)
• Reapply that MLR patch using the steps in the README and regenerate the JAR files.

(*) For example when comparing with MLR patch 7156414, but newer Patch 7482264 was applied later different classes are seen. In this case the problem is not that incorrect classes are included, but that comparison is done with the incorrect MLR patch.

Taking the example used before, these actions will make sure it's discovered the fndforms.jar does not include the (expected) UICommon.class from Patch 7482264 but comes from Patch 7156414. This explains why problems fixed in Patch 7482264 are still experienced.

Version of EWT

Next to the classes in the fndforms.jar also the EWT version in the fndewt.jar may be verified. Patchset 19 included an older version of EWT (3_4_46) causing some regressions. The latest MLR patches deliver EWT version 3_4_49 or higher. If MLR Patches are applied the EWT version should not be an issue.

When in doubt the expected EWT version is used the following is a quick scan what version of EWT is installed

• Run the following command to check EWT versions extracted in the 8.0.6 HOME

# ls -lrt $ORACLE_HOME/forms60/java/oracle/ewt | grep 3_4

• Run the following command to check EWT version included in the fndewt.jar

# unzip -l $OA_JAVA/oracle/apps/fnd/jar/fndewt.jar | grep 3_4

• The output of both step 1. and 2. should list "3_4_49" (or higher) as EWT version

The above indicates that a MLR patch delivering the EWT version was applied. However it may still happen that an older MLR Patch got reapplied an has overwritten EWT classes. To confirm the expected EWT classes are indeed used a comparision must be done between the fndewt.jar and ewt3.jar delivered in the MLR Patch applied.

• Create a listing of the contents of the fndewt.jar

# unzip -l $OA_JAVA/oracle/apps/fnd/jar/fndewt.jar > fndewt.txt

• Open the ewt3.jar from the MLR patch in Winzip to see the files included
• Compare the timestamp and size of the classes listed in fndewt.txt with the classes in ewt3.jar. If these match the expected version of EWT is used.

In case differences are found in step 3 it's needed to extract the ewt3.jar again (See readme of the MLR patch for exact steps) and regenerate the Applications JAR Files using adadmin. Then recheck to verify the discrepancy found is resolved.

Forms Version

Check the current Forms version as follows: 

• In Forms session select menu 'Help > About Oracle Applications...'. The section Forms Server shows a line like:

----------------------------------------
Forms Server
----------------------------------------
Oracle Forms Version : 10.1.2.2.0

Note: The user must have profile 'FND: Diagnostics = Yes' to see values in this section.

OR

• Open telnet/PTTY connection to server and source APPS environment
• Call the Forms builder executable using:

# frmbld \? | grep Forms | grep Version | awk '{print $6}'

This shows the version of Forms used, for example:

10.1.2.2.0

For Release 12 the following version are applicable:

Form version	Patchset
10.1.2.0.2	Base for R12
10.1.2.2.0	Oracle AS Patchset 10.1.2.2.0 (Patch 4960210)
10.1.2.3.0	OracleAS Patchset 10.1.2.3.0 (Patch 5983622)

Latest MLR Patch

The latest MLR patch can be checked using following references:

(*) These are the final patches for Forms 10.1.2.0.2. If these do not resolve the issue you are requested to upgrade to the latest certified version of Forms following Note 437878.1.

Release 12 uses opatch to apply the MLR patches and records these in the Inventory. To list the  patches applied perform the following:

• Source the Applications environment, so that ORACLE_HOME point to 10.1.2 HOME
• Run the following command

# opatch lsinventory -invPtrLoc $ORACLE_HOME/oraInst.loc

• The result of the the command is a listing of the patches applied as saved in the Inventory. Also a log file is created with the same contents. The onscreen listing also shows the exact location and name.

$ORACLE_HOME/.patch_storage/LsInventory__<mm_dd_yyyy_hh-mm-ss>.log

The above is the default location. It could be that setup in specific environment uses a different location, so make sure to note down the exact location reported when command in run. Also see that the .patch_storage includes a '.' indicating this is a hidden directory not visible when using a 'blind' ls command

Verify if the results report the latest MLR patch being applied. If this is not the case apply the latest MLR patch to obtain the latest Forms focus fixes and retest if the problem persists.

Keep in mind that upgrading to the latest certified Forms version and/or application of latest MLR patch is not a guarantee that all focus issues will be resolved. The problem reported may be currently being dealt with in an open bug, waiting for inclusion into an upcoming MLR patch or it could be a new issue to be diagnosed and reported to development. Having the latest versions as recommended has proven in the past to limit the number of focus issues reported by the users and allows to concentrate on the ones still occurring.

The following information is needed to further diagnose the focus issue when the problem persists after application of the latest MLR patch.

Version of Forms and Sun JRE

The version of Forms has been determined in the previous step. The version of the Sun JRE must be verified on the client PC. Some options to check the JRE version:

• The following steps will show page in Java Control Panel showing version (e.g. Version 6 update 14 (build 1.6.0_14-b08)

Start > Control Panel > Java > General > About 

• Check the Java Console output (see Java console log from session reproducing the issue below)

Recorded OWC or DITO

A recorded OWC or DITO (Note:11.1) provides the exact navigation steps performed leading to the issue and will be the starting point to reproduce the problem in an internal Oracle environment.

List of patches applied

This information has been collected in the previous step and is to

• Confirm that issue reproduces when latest MLR patch has been applied
• Lists all the patches to be used in the internal environment used to replicate the issue reported

 For Release 12 the output file from the # opatch lsinventory can be used for this.

Java Console Log from Session Reproducing the Issue

The Java console output gives the details on the Forms version, JAR files downloaded and errors if any while reproducing the focus issues.  The Java console can be enabled using following steps

Start > Control Panel > Java > Advanced > Java Console > Show Console

Start a new browser session to have the change picked up. When Forms is started a 2nd window is opened showing the Java console output.

FRD Log From Session Reproducing the Issue

Follow Note 150168.1 to enable FRD tracing for the Forms session. The FRD trace will show the Forms code being executed in the session. This may contain valuable information leading up to and around the time the focus issue occurred.  

Output from Help->About Oracle Applications

In the Help > About Oracle Applications a lot of information about the Forms session is available like

• Forms version used
• A number of environment settings like FORMS_PATH
• Exact version of the Form and libraries used (Patch level of the Application)

 To see all the information available make sure the user has profile FND: Diagnostics = Yes (if using R11.5.10RUP5+ or R12)

Forms JAR Files

The JAR files allow a comparison of the sizes of class files and EWT version used with the version provided in the latest MLR patch fixing focus issues. Also the JAR files will show if these have been properly signed. If the jars are not signed properly we may hit focus issues. If signed properly these will contain Cust.dsa and Cust.sf

Collect the JAR files as follows: (For R11i only the steps 1-3 are needed. The steps 4+5 only apply to R12)

1. Open a telnet session to the server and source the environment.
2. Navigate to directory $OA_JAVA/oracle/apps/fnd/jar.
3. Collect the following files
   • fndforms.jar
   • fndewt.jar
4. Navigate to $ORACLE_HOME/forms/java. 
5. Collect the following file
   •  frmall.jar

Changes Made in the Environment

If the issue did not occurred earlier what was last changed in the instance. Any information answering questions like

• When did the problem start?
• Changes made around the same time
  • Forms upgrade / MLR patch applied
  • New version of the Sun JRE
  • (Product) patch applied

may help to narrow down what introduced the problem into the environment and will also help in understanding the exact circumstances to reproduce the problem.

The Steps to Reproduce

The steps to reproduce deserve a special mention because they can be the hardest of all the information to collect for a focus issue. Focus issues are not random, there will be a pattern but it will take time, effort and determination to work them out. Start by looking at the typical working patterns of a user. Re-iterating the steps over and over again should highlight the necessary steps. Remove the redundant steps and don????????????????????????t assume all focus issues have the same triggers.

This section describes the steps for debugging focus issues and the analysis required of collected information. Some points have been mentioned before, but to have complete list these are mentioned again to prevent being missed.

Check the Forms Version and Applied Patches

The Forms Version should be upgraded to latest certified version.

Release 11i

Follow Note 125767.1 "Upgrading Developer 6i with Oracle Applications 11i"

Release 12

Follow Note 437878.1 "Upgrading Forms and Reports 10g R12". Only apply the patches mentioned in this Note and do not apply other (MLR) patches.A  few OS specific MLR patches were released including some Forms focus issues making that those issues are fixed, but others may still occur. These patches will report a patching conflict during application of the MLR patch recommended by ATG Forms development.

The "ATG recommended" patch should take precedence. If the OS specific MLR was applied to fix a specific issue (may be not focus related) check with ATG Forms development on how to deal with this. Most of the time however these patches have been the results of an incorrect advice.

Verify Contents of the Forms JAR Files

For various reasons it may happen that MLR patch is applied, but the new classes are not up taken in the Forms JAR files downloaded to the client PC. The result of this is that problems expected to be fixed are still reported by the users. To exclude this being the case the Forms JAR files must be reviewed to be 100% certain the expected classes are used. To perform this verification:

Release 11i

For release 11i see section "Determine the current Forms version and MLR patch (Release 11i)- Latest MLR Patch" for detailed steps to verify this. Due to the manually actions and no checking being done there is a potential risk that not the expected classes are included in the Forms JAR files downloaded to the client PC.

Release 12 

• Verify if the size of the frmall.jar matches with the one delivered by the latest MLR patch released.
• Open the fndforms.jar (downloaded to the client) using winzip
• Open the frmall.jar (provided by the MLR patch) using winzip
• Compare the sizes of the following classes:
  • UICommon
  • VBean
  • ComponentItem
  • FormWindow
  • FormCanvas
  • AlertDialogue
  • BlockScroller
  • MDIContainer

If the sizes in both JAR files are identical it's confirmed that MLR patch is included in the Applications JAR files.

These actions are also useful to perform when customer applied a new MLR patch and reports the issue expected to be fix still reproduces  In a number of cases this was caused by the fact the MLR patch was applied, but for some reason the new versions of the classes were not included in the fndforms.jar file.  Performing a 'Generate Product JAR files' in adadmin with FORCE option mostly does the trick in these cases

Test with Latest Available Sun JRE

Sun releases new versions of the JRE plug-in on a regular basis delivering the latest fixes. It is recommended checking if the focus issue reproduces using the latest available version of the Sun JRE 1.6.0.x plugin.This can be especially important when using Sun JRE 1.5.0.x as the later stream of the plug-in may resolve the issue and a JRE upgrade may be considered a solution to the problem. The latest JRE 6 plug-in releases use a non-static versioning model by default. This pushes the onus of plug-in selection to the desktop which means you can easily switch versions simply by installing/uninstalling plug-in versions on a desktop without altering the Oracle E-Business Suite web server set up.

For further information please see the 'Enabling Multiple Desktop Client Java Plug-in Versions' section of the relevant note below. These notes also list the latest certified releases of the Sun JRE plug-in;

Release 11i

Note 290807.1 Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite 11i

Release 12

Note 393931.1 Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 12

Check the Cursor Position After Each Navigation Step

To confirm the user has a focus issue check the cursor position from

Help->Diagnostics->Examine

Enter the following in the fields to obtain the item currently having the focus

• Field 1: SYSTEM
• Field 2: CURSOR_ITEM
• Field 3: shows the value after tabbing out of the 2nd field

After changing the cursor to another item the value should change. Check it repeatedly during the steps to reproduce to help understand when focus is being lost.

Review the FRD Trace File

The main information collected from the FRD log is a confirmation of the Forms version and the Products Files. This information assists in finding a proper internal environment to be used for replicating the issue. The FRD log can also be used to see the flow of events and watch out for additional WINDOW switch events around the lines where the focus was lost.

If none of the above techniques have resolved the Focus issue the last step is to log a Service Request with Oracle Support Services to have the issue investigated. The support engineer may double-check steps from this note to confirm that nothing has been missed.

The starting point for the further analysis is to identify the exact navigation steps leading to the problem. A good starting point is an OWC session demonstrating the focus loss to the support engineer. With the recorded OWC the support engineer can verify if a bug has been logged for this issue. It may have been reported but is still under investigation, or a fix was created and is scheduled to be released in an upcoming patch.

If the problem has not been reported before the support engineer needs to log a new bug with Development. Next to the information about the versions used a key deliverable is a reproducible test case on a internal Oracle environment. This environment is used by development to analyse the steps leading to the problem. Each mouse event, keyboard navigation is important to reproduce in focus issues. The steps to reproduce deserve a special mention because they can be the hardest of all the information to collect. Focus issues are not random, there will be a pattern but it will take time, effort and determination to work it out. Any information, like removing redundant steps, which simplify reproducing the focus issue will be helpful for the support engineer to create the internal test case and have the issue addressed by Development.

ReferencesNOTE:125767.1 - Upgrading Developer 6i with Oracle Applications 11i
NOTE:232313.1 - Information on Previous Versions of Developer 6i Patchsets
NOTE:290807.1 - Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite 11i
NOTE:393931.1 - Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 12
NOTE:437878.1 - Upgrading OracleAS 10g Forms and Reports in Oracle E-Business Suite Release 12
NOTE:750359.1 - Upgrading to Previous Version of OracleAS 10g Forms and Reports in Oracle E-Business Suite Release 12

ת×Ô£ºhttps://support.oracle.com/CSP/ui/flash.html#tab=KBHome(page=KBHome&id=()),(page=KBNavigator&id=(bmDocID=760250.1&from=BOOKMARK&bmDocDsrc=KB&viewingMode=1143))#tab=KBHome(page=KBHome&id=()),(page=KBNavigator&id=(bmDocID=760250.1&from=BOOKMARK&bmDocDsrc=KB&viewingMode=1143))