This section includes the following topics:
If you cannot locate a responsibility name as described in the Oracle Scripting Implementation Guide or other Oracle documentation, your environment may have been customized, or may be using a specific installation type. In some Oracle Applications environments, responsibility names differ based on installation choices. Oracle Applications can be installed in one of three configurations:
If you cannot locate a responsibility name as described in the Oracle Scripting Implementation Guide or other Oracle documentation, your environment may have been customized, or may be using a specific installation type. In some Oracle Applications environments, responsibility names differ based on installation choices. Oracle Applications can be installed in one of three configurations:
Test installation: installed for testing applications and database functionality.
Production instance: installed for use in production in an enterprise.
Test and Production installations do not include the sample database.
For example, production instances use the name Scripting User for the responsibility to launch a script in the Scripting Engine agent interface in stand-alone mode. However, environments using the Vision installation call the same responsibility Scripting Agent, Vision Enterprises. In both environments, the responsibility key will be IES, and the responsibility ID may be identical.
For information on finding a responsibility ID, see Finding Application and Responsibility ID Values.
This section includes the following topics:
The responsibility for administering the Survey component of Oracle Scripting is known to Oracle Applications as Survey Administrator. Do not confuse the Survey Administrator responsibility (required for administering survey campaigns) with the iSurvey User responsibility (required for executing or scheduling concurrent programs).
When you are logged into Oracle Applications as a system administrator and are searching for responsibilities in Forms-based applications, it is recommended to search using the percent wildcard character, for example "%SURVEY%", because:
Searching under "iSurvey" will only result in finding the iSurvey User responsibility, which does not have the required administrative privileges to access the Survey Administration console.
Searching under "Survey" will only result in finding the Survey Administrator responsibility, which does not have the required privileges to administer, schedule, or run concurrent programs.
If you cannot successfully view the Survey Administration console:
Check that the Web server and database are up and running in your environment.
Check that the User ID and Password used to access Oracle HTML-based applications have been created in Oracle Forms administrative screens by a user with the System Administrator responsibility, and that the user has been assigned the Survey Administrator responsibility.
Check that the appropriate profile settings have been established for the application at the site level, and for the application at the user level (the User Name in Forms-based applications matches the User ID and Password you used to access the Oracle CRM HTML-based application).
If You Cannot See Fulfillment Page
If you can successfully enter the Survey Administration console, but cannot view the Fulfillment page:
Check that Oracle One-to-One Fulfillment has been implemented appropriately and the Fulfillment server is up.
Check that you appropriately assigned the JTF_FM_ADMIN role.
Check that after moving the JTF_FM_ADMIN role into the Assigned Roles list, you clicked Update.
Ensure that all the Oracle One-to-One Fulfillment (fm.db) objects in the database are valid.
If you can successfully enter the Fulfillment tab, displaying a Fulfillment sub-tab and displaying the Master Document page, you have verified that:
You have appropriately assigned the Fulfillment Admin role to the Survey administrator user.
Oracle One-to-One Fulfillment is implemented in your environment.
This section includes the following topics:
This section includes the following topics:
Deploying a script to the database with the Author fails.
The tablespace for the IES_DEPLOYED_SCRIPTS table may not be large enough. Particularly indicative is the scenario in which previous scripts were deployed to the database without difficulty. To resolve, increase the size of the tablespace (usually named USER_DATA) to an appropriate size (based on database usage and other installed applications). Consult your database documentation for details.
Connection to the Oracle Applications database instance has failed because the database is down. Check with the database administrator.
When testing a script, it is not enough to ensure the script will launch in the appropriate interface (in the Java interface for agents, or in a Web browser for surveys). You must also test each path in the script to ensure all commands are functioning as expected. It is important to ensure each component is functioning on its own and in consonance with all others. From the standpoint of the script itself, one must test:
The "call guide" or "survey" (the script document developed with Script Author)
All custom Java methods developed to support the script
All PL/SQL procedures attached as commands to panels, blocks, branches, etc.
All Blackboard commands
All Forms commands
All Constant commands
All Delete actions
This section includes the following topics:
A yellow bar appears on the bottom of all Forms windows that reads Warning: Applet Window.
This is a security configuration issue. From a Scripting perspective, you cannot launch Scripts after logging into Forms-based applications.
This may be an indication that the proper security certificate has not been installed on the client JInitiator. Improper security configuration on the client can lead to a variety of problems in Oracle Scripting. Among them, the ability to copy and paste to and from fields in Scripting will be disabled. Be sure to properly configure applet security on each client machine. First, empty your Oracle JInitiator cache and try logging in again. If the yellow bar reappears, uninstall and re-install Oracle JInitiator.
This may be an indication that the Applications JAR files have not been signed properly on the server. For more details on proper security configuration, consult your Oracle Applications installation documentation.
While in the middle of running a script in the agent interface, users will occasionally (and seemingly randomly) receive errors indicating that their sessions have expired.
Note: This error message can also indicate a legitimate issue if the user has been idle for a long time. For more information, see Setting Session Idle Timeout Values for Apache JServ.
While in the middle of taking a survey, users will occasionally (and seemingly randomly) get a browser page with the error message "Incorrect URL" after clicking the Submit button on a survey page.
Oracle Scripting is a stateful application. As with all stateful HTTP applications on load-balanced Apache/JServ environments, the load balancer must be configured to route requests from one client to the same Apache/JServ for the duration of the session. Otherwise, the Scripting Engine will not be able to find the user session's state, and will fail, as described above. This behavior is applicable to Oracle Scripting releases 11.5.6 and later. This is applicable both for Scripting Engine implementations executing scripts in Oracle Forms (the agent interface) in the Apache mid-tier architecture, and for implementations for executing surveys in a Web browser (the Web interface). This information is not applicable to implementations executing scripts in the agent interface in the Caching Architecture.
Note that this issue is caused by incorrect load balancer configuration, not by Oracle Scripting.
Scripting Engine operations in the Apache mid-tier architecture for agent script and survey execution can be set in many different mid-tier configurations, ranging from a single Apache/JServ on a single mid-tier server to many mid-tier server machines, each running many Apache and JServ instances. In fact, it is this flexibility which allows Scripting to easily scale to handle a large number of concurrent users, simply by adding mid-tier server machines and Apache/JServ instances as necessary. In environments with multiple Apache/JServ instances spanning multiple mid-tier server machines, a load balancer must be used, so that requests to a single virtual URL can be appropriately distributed to a physical machine and an Apache/JServ on that machine. Load balancers can be either hardware or software components. There are a large variety of vendors who make such components. Because the Scripting Engine is a stateful application, there is a required implementation step when implementing Scripting in an environment with multiple, load-balanced Apache/JServ instances. When configured for only stateless HTTP applications (e.g. iStore), a load-balanced Apache/JServ environment can simply distribute each incoming client request to any Apache/JServ. With a stateful HTTP application like Scripting, the application must maintain individual user sessions and the state of each user session in Scripting is stored in the servlet session in the JServ. Thus, when the first client request is received to establish a Scripting user session, that request can be routed to any Apache/JServ. But each subsequent request for the same user must be routed to the same Apache/JServ as the first, or the application will not find the user session state, and the application will error out.
Load balancers have support for ensuring that client requests for stateful applications get routed to the same JServ. One vendor, Cisco Systems, refers to this as "stickiness." Regardless of the vendor of the load balancer, the implementor must ensure that a load-balanced environment running Scripting is configured to redirect client requests to the same JServ.
For more information on proper configuration of a load balancer, please consult with a networking professional familiar with your environment and your specific load balancer or refer to your vendor's load balancer documentation.
During an Oracle Scripting transaction in the agent interface, the following error message appears:
Error: Your Scripting transaction has expired due to inactivity. Please close the Scripting window and restart the script. Also, please contact your system administrator to increase the Apache JServ session idle timeout setting.
This requires the agent to close the Scripting Engine agent interface window, launch the script again, and recapture all information from the expired session.
In the Scripting Engine agent interface (when using the Apache mid-tier architecture only), the Scripting servlet runs in an Apache JServ. Every Apache JServ has a session idle timeout setting that controls how long a servlet session can be idle before it is automatically timed out (expired and terminated) by the Apache JServ. This behavior ensures that abandoned sessions in the servlet are not left to consume resources unnecessarily. When a servlet session is active in the JServ, but is idle (has received no client requests) for longer than the specified idle timeout setting, the JServ will automatically time out or expire the session.
The behavior exhibited by the application in the problem description above differs based on patch level. Regardless, all data from the expired session will be lost. Recovery requires ending the script manually by closing the window, and starting a new script session.
To avoid such problems, consider extending the session idle timeout setting. For more information, see the topic Setting Session Idle Timeout Values for Apache JServ in Oracle Scripting Implementation Guide.
This section includes the following topics:
When taking a JTT-based survey, styles designated in a cascading style sheet included in panel text or JSP resources are ignored.
Neither the agent interface nor the Web interface of the Scripting Engine support the use of cascading style sheets (CSS) in panel layout HTML.
For executing scripts as surveys, any style sheet used in survey resources other than the default CSS specified in JTF properties will be ignored. The agent interface will ignore any style sheets referenced in panel layout HTML.
Format panel text using the panel layout editor. Alternatively, export panel text and generate formatting on a character or paragraph tag level rather than applying styles.
For JSP resources, use styles referenced in JTFUCSS.CSS only, or specify in JSP code the desired formatting on a character or paragraph tag level.
At script runtime, JavaScript imported into panel text HTML is ignored or displays incorrectly.
The Scripting Engine agent interface does not support the use of JavaScript or JScripts.
Do not include JavaScript or JScript scripts in panel text HTML for any script intended to be executed in the Java-based agent interface.
The Scripting Engine Web interface uses the Web browser to interpret code. Oracle Applications 12-certified Web browsers such as Netscape Navigator and Microsoft Internet Explorer interpret JavaScript (and JScript) scripts differently.
The following solutions are recommended:
Build JavaScript or JScript scripts carefully, using certified scripting language experts.
To ensure compatibility with all browsers, it is recommended to include a savvy browser detection scheme in any scripts used, to supply appropriate rendering in JScript or JavaScript as required by the end user's browser client.
Recognize that using scripts within customized panel content is customization. As with all custom code, such issues are not supported by Oracle.
Many custom JavaScripts are required to be included within the <HEAD> and </HEAD> tags of any HTML page. Ensure the script is appropriately referenced in custom panel HTML.
Microsoft FrontPage does not allow the inclusion of any content after the </HTML> tag. When editing panel text containing any embedded values, ensure that the HTML editor has not removed embedded value codes. One workaround is to create embedded values after otherwise customizing panel layout content.
Prior to upgrading to the Apache mid-tier architecture, certain debug statements or messages appeared in the Java console that are no longer visible.
The JVM executing code is located on the Apache Web server whereas before the messages were "printed" to the client's Java console.
To view debugging messages in the Apache Mid-Tier architecture, change any Java code using "System.out.println" to "System.err.println". This will result in the messages being written to the jserv error logs.
The following are troubleshooting tips specifically regarding undelivered invitation or reminder master documents for list-based survey campaigns. Invitations and reminders are HTML master documents sent by Oracle One-to-One Fulfillment to invite a list member (or to remind an already invited list member) to participate in a survey campaign.
When you click Deploy for a list-based survey deployment, a concurrent request is generated which is scheduled to run at the deploy date and time (specified when defining a deployment). The purpose of this concurrent program is to make a request to Oracle One-to-One Fulfillment to send out e-mail invitations to the target population specified by the list.
Upon selecting Deploy, the status of the deployment changes from "Open" to "Active." If the status of the corresponding parent objects (cycle and survey campaign) status were "Open," the status of each will change to "Active."
As soon as the page refreshes, the corresponding concurrent request ID is immediately visible in the Deployment Detail page. You can use this concurrent request ID to monitor the fulfillment request submission through the Oracle Forms-based interface associated with the iSurvey User responsibility.
When the request executes, either it will succeed or fail to complete.
Successful Request: A successful request is indicated in the Request Detail form as Phase: Complete, Status: Normal. Such a status indicates that the request was executed, but does not necessarily indicate that the Fulfillment request has successfully been received by the fulfillment server. This distinction is important because it helps determine how to fix any emerging problem. Additional information is available in the Requests list by clicking View Log on the appropriate request. If a request was executed but there was an internal error, the log may indicate the presence of such an error. For example, if the survey administrative user deploying the survey is not associated with a fulfillment group, this is indicated in the log.
Request Not Completed: A failed request is indicated in the Request Detail form as Phase: Complete, Status: Error. Such a status indicates that the request has been executed but was not completed. See below for more information.
If the request is successful, a fulfillment request ID is generated. This is visible from the Survey Administration console in the Deployment Detail screen, immediately above the concurrent request ID.
This request can be tracked using the Fulfillment tabs within the Survey Administration console, using this fulfillment request ID. If necessary, the same ID can be used by a fulfillment administrator, accessing the full functionality of Oracle One-to-One Fulfillment by logging into the Fulfillment Administration console.
Once a fulfillment request has been successfully submitted to Oracle One-to-One Fulfillment, there is no communication with the Survey Administration console regarding any possible problems in executing that fulfillment request. If necessary, obtain the fulfillment request ID from the Deployment Detail page of the Survey Administration console, and attempt to remediate using Oracle One-to-One Fulfillment debugging techniques.
In Concurrent Manager, a fulfillment request that is not completed can be detected in the Request Detail form as Phase: Complete, Status: Error.
Additional information to help determine why a request failed may be visible by clicking View Log in the Request form.
In the Survey Administration console, when deploying a list-based survey, the status is set to "Active" upon a successful request to Concurrent Manager. However, if the status of the deployment changes back to "Open," this may indicate a failure to execute the fulfillment request.
Once a Fulfillment request has been successfully submitted to Oracle One-to-One Fulfillment, the Fulfillment Engine then needs to process it. Only successful processing by the Engine results in an e-mail message being sent out and the subsequent receipt of respondent data for a list-based survey campaign.
The Fulfillment Engine will fail if the query associated with the master document fails. Therefore, once a fulfillment request ID is generated, use Oracle One-to-One Fulfillment debugging methods to troubleshoot the failure point within Oracle One-to-One Fulfillment.
Log into Oracle applications and check the Phase and Status of the concurrent request. Additional information to help determine why a request failed may be visible by clicking View Log in the Request form of the Concurrent Manager.
Failure may indicate Oracle One-to-One Fulfillment implementation, configuration issues, or invalid Oracle One-to-One Fulfillment packages.
You may also need to check Oracle One-to-One Fulfillment configuration, implementation, or that the Fulfillment server is functioning.
For Oracle One-to-One Fulfillment information, refer to Oracle One-to-One Fulfillment Implementation Guide.
You have successfully executed a concurrent program, and a Fulfillment request has been successfully submitted to Oracle One-to-One Fulfillment. However, once the deployment date and time have passed, no survey responses are allowed (deployment is not valid, is not active, or you are using an invalid URL).
Check the Survey Administration console to see if the response end date has already passed or the status has changed from Active to Closed or Cancelled.
Check the invitation to see if the URL in the e-mail link is in the appropriate format as indicated below:
http://<server>.<domain>:<port>/OA_HTML/OA.jsp?OAFunc=IES_SURVEY_OARUNTIME?dID=xx&rID=xxxxxxxx
where dID = the deployment ID and rID = the unique respondent ID
If the URL associated with the hyperlink is incorrect, you must fix the query associated with the Oracle One-to-One Fulfillment master document in the template used for that survey. Then you must resubmit the request using Concurrent Manager.
Check the Fulfillment Administration console to determine if there is a Fulfillment server problem.
If the Fulfillment request indicates Phase: Completed, Status: Error, you can resubmit the request. To resubmit it:
Copy the parameters from the Request Detail form.
Return to the Navigator.
Navigate to Survey Administration > Requests > Run.
Select "Single Request" from the Submit a New Request dialog and click OK.
The Submit Request form will appear.
In the Names field, enter "SUBMIT GROUP FM REQUEST FROM IES" and press Tab.
You can enter partial criteria and use the % wildcard character, if desired.
The Parameters dialog will appear.
One at a time, enter the parameters you copied from the failed request, and click Submit.
There are 9 parameters, each separated by a comma. If nothing appears before a comma, that parameter is null and can be left blank.
After clicking submit, a dialog will appear with a request ID. Copy the request ID and use this to track your request.
Note: The deployment detail page will still indicate the original request ID. This will not be updated; ensure you use the new request ID to track your request.
Oracle Applications is a rich, full-functioned, constantly evolving software suite. It is the only available software suite that offers the world's most proven and scalable database, a commonly implemented applications server, mature back-end ERP functionality such as human resources and financials, and cutting-edge front-office customer-facing CRM applications, of which Oracle Scripting is just one offering. Considering the scope of its function, Oracle Applications is necessarily complex, and patching takes experienced administrators, careful attention to detail, and adherance to requirements indicated in readme and about documents.
As indicated in our Send Us Your Comments section, Oracle welcomes your input, including any corrections you feel are appropriate to this document. Note, however, that if you see discrepancies between the application user interface and the procedures documented herein, there are several potential causes. These include, but are not limited, to the following:
Applications patch level.
User interface changes occur from release to release.
Technology Stack patch level.
Underlying techology components
Problems encountered with Oracle Scripting may differ in origin based on the component being used and the source of the error. Oracle Scripting includes various tools to help users and administrators detect and eliminate problems.
Oracle Scripting includes four primary components, most of which have one or more subcomponents for which information and problems are reported either to a message log (typically stored as log files in the database) or as an entry in a debug console.
Script Author includes a Java applet and a servlet.
The Scripting Engine is executed on the middle tier (the Apache Web server), and may encounter problems at that level. Further, the Scripting Engine is comprised of an agent interface (a Java client, in which the script executes as Java on the agent's client workstation, wrapped in an Oracle Form) and a Web interface (an Oracle Applications 12-compatible Web browser, in which the script executes in the browser's main window). The Scripting Engine hosts a PL/SQL integration layer, in which database operations execute and the results can be displayed as determined by the script.
The Survey Administration console is an HTML application using the Oracle Applications Framework (OAF) technology stack. This component is used to administer survey campaigns, a prerequisite in order to execute scripts using the Scripting Engine Web interface.
The Scripting Administration console is an HTML application using the Oracle CRM Technology Foundation (JTT) technology stack. This component is used to administer files supporting Oracle Scripting (deployed scripts, custom Java for scripts, and script/Java mappings).
Problems encountered with Oracle Scripting can be detected and debugged by determining the source of the error and tracking down the appropriate informational message. Based on the source of the problem or the interface experiencing difficulties, error, informational, or debug messages may be located as follows:
| Component | Subcomponent | Configuration | How to View Logs | Runs on Client Desktop |
|---|---|---|---|---|
| Script Author | Java Applet | Script Author Debug Console | Yes | |
| Script Author | Servlet | Four AFLOG profiles | Log Viewer | No |
| Scripting Engine | Apache mid-tier | Four AFLOG profiles | Log Viewer | No |
| Scripting Engine | Forms/Java Client | IES : Debug Mode profile | Java Client Debug Console and Jinitiator Console | Yes |
| Scripting Engine | HTML Client | Four AFLOG profiles | Log Viewer | No |
| Scripting Engine | Forms PLSQL Integration Layer | Four AFLOG profiles | Log Viewer | No |
| Scripting Engine | Survey Runtime | Four AFLOG profiles | Log Viewer | No |
| Survey Administration console | N/A | Four AFLOG profiles | Log Viewer | No |
| Scripting Administration console | N/A | Four AFLOG profiles | Log Viewer | No |
Various system profiles control the logging of error and informational messages.
IES : Debug Mode profile (set to Debug off or Debug on) controls display at runtime of informational and error messages for Scripting Engine operations. When enabled, these messages are displayed in a Java-based Debug console that appears (in a separate window) when a script is executed in the Scripting Engine agent interface.
IES : Debug Mode (set to Debug off or Debug on) controls display at runtime of informational and error messages for Scripting Engine operations. These messages are logged to the FND_LOG_MESSAGES database table in the Oracle Applications schema, and are typically viewed by accessing Diagnostics. Generally set to Debug off unless troubleshooting specific issues.
Problems with the Script Author Java applet are displayed in the Syntax tab of the Script Author Java applet. Clicking on any specific error displays an error message in the Debug pane, which appears immediately below the graphical Script Author canvas (the visual work area). This is accessed by a user with the Scripting Administration responsibility.
Status and error information about Scripting Engine mid-tier operations, the Scripting Engine HTML client, PL/SQL information passed between the database and the Scripting Engine, scripts executed in the Scripting Engine Web interface, and transactions in the Scripting Administration console and the Survey Administration console is recorded to server logs in the Applications Common Logging infrastructure. These logs are viewed by users of an OA Framework HTML application when the FND: Diagnostics profile is set to Yes. These logs are accessed when the user selects the Diagnostics global button or link.
Error messages for the Scripting Engine Web interface are recorded both to the Oracle JInitiator console, and the "Engine Debug console". The Oracle JInitiator console is visible if the Show Java Console option is enabled in the Oracle JInitiator Properties window. If Oracle JInitiator is installed on your computer, you can access these properties by selecting Start > Programs > JInitiator Control Panel. The Engine Debug console is accessed.
This section includes the following topics:
When executing the Scripting Engine, any resulting errors are stored in various places and viewed differently based on the genesis of the error.
This section includes the following topics:
When an agent is running a script, if an error occurs on the client end (from the Forms client), this error is written to the JInitiator Java console.
To view the JInitiator Java console, select the Show Java Console option in the Basic tab of the Oracle JInitiator Properties dialog accessed from the JInitiator Control Panel (typically Start > Programs > JInitiator Control Panel [Version]).
If an error occurs in the servlet or session, this error is written to the IES server logs.
For example, if an action calls a Java method that does not exist, this is a server error.
When a respondent is taking a survey, errors are distinguished by the two components of the JSP layer:
The Scripting HTML client, which takes the script and renders HTML.
The survey-specific layer that wraps the output to the HTML client in survey-specific functionality (such as checking Deployment IDs for a valid deployment URL).
In general:
Any errors in the Scripting Engine session or generic HTML client layer are logged, in detail, in the IES server log.
A summarized version of the error is passed back and displayed by the Web browser.
Any errors occurring in the survey-specific layer are displayed by the Web browser.
If you have set the JTF debug mode on, survey-specific debug messages, as well as other debug information, will be logged in JTF-specific server logs.
From a Survey perspective, the Scripting Engine is a set of Java classes on the middle tier that receives requests from the JSP layer (including the message to launch a script), and processes them. All business logic as determined by the survey questionnaire script, custom code or database calls, and respondent actions are evaluated by the Scripting Engine, which passes processing information to the JSP layer to interpret, which in turn sends information to the Web browser to display. Scripting Engine errors are automatically stored in the server and can be viewed with the CRM HTML-based server log viewer, regardless of the debug mode.
Errors in the interpretation of the survey questionnaire script, custom code or database calls, and respondent actions will automatically store error messages in the server and can be viewed with the CRM HTML-based server log viewer. These errors are written to the server logs regardless of debug being on or off. Additional informational messages are also stored in the server logs when debugging mode is enabled.
The Java Server Pages layer includes a survey functionality component and an HTML client component in the middle tier. When a request to process a URL linked to a particular survey campaign deployment is received in the middle tier, it is evaluated by the survey processing component. This component receives the request, processes it, and validates it. If there is an error (such as invalid deployment ID, invalid URL or invalid date due to an expired or inactive deployment), the survey processing component generates an error message to be sent to the Web browser. The error message is displayed in the Web browser as an error page. Viewing the source of the page from the browser may provide additional information regarding the error, such as stack trace messages useful for troubleshooting.
If valid, the request is sent to the HTML client component, which sends a request to the Scripting Engine. The HTML client component serves as a broker between processing occurring in the Scripting Engine and the survey processing component, which passes information to the Web browser to display.
This section describes functionality that is not supported with Oracle Scripting.
This section includes the following topics:
In Script Author, you have correctly formatted an embedded value to provide a blackboard value in a panel at runtime. There is no other content in the panel (other than the Continue button). In other panels, the same procedure was effective, while at runtime in this case, no value appears (only the Continue button).
In the Script Author, you cannot include in panel layout an embedded value only, with no other content.
Attempting to include only an embedded value (with no other characters) in the panel layout will result in the blackboard value not appearing in the panel at runtime.
As a work-around, you must include at least one character (a space character is acceptable) before and after the embedded value, and highlight these additional characters also when establishing the embedded value.