This chapter covers the following topics:
Before creating and administering users for Oracle Scripting, you must understand the types of users required, the applicable responsibilities to assign to the appropriate Oracle Applications login, and the specific tasks to accomplish.
From an implementation perspective, you need to create administrator users and agent users. The responsibilities that must be associated with each user type depends on how Oracle Scripting will be implemented at the enterprise, and which Oracle Applications functions will be required.
This section addresses which user account to use to create other users, and possible requirements for JTF roles for a specific user. It also describes a rationale for creating a super user for implementation purposes. This section then includes an implementation responsibility matrix, and a discussion regarding the approach to creating users for your Oracle Scripting implementation.
This section includes the following topics:
Additional specific information for creating administrators and for creating agents can be found, respectively, at Creating Administrators for Oracle Scripting and Creating Oracle Scripting Agents.
Step-by-step procedures to accomplish user creation tasks are described in Creating and Administering Users.
Implementors often access the seeded SYSADMIN Oracle Applications user account when administering or configuring Oracle Applications. For security purposes, some enterprises restrict access to this account. For this reason, this document assumes you will create (or have created for you) at least one distinct Oracle Applications user account, and provide this new account with all of the required roles, responsibilities and privileges required for implementation, administration, and testing. For planning purposes, if an enterprise has the SYSADMIN account locked down, you may need to request in advance that an administrator user account be created for you.
To create an administrator for Oracle Scripting, you must know all of the tasks the administrator will perform, and how Oracle Scripting will be used at the enterprise.
Some implementation or administration tasks require the administrator user to be granted JTF roles before you log into Oracle Applications.
For example:
A Survey Administrator user must be granted the JTF_FM_ADMIN role in order to access the Invitations tab on the Survey Administration console, or to access any tab on the Fulfillment Administration console.
If performing tasks involving modification of JTF advanced system properties (for example, removing the Quick Find menu from the Scripting Administration console), your Oracle Applications user account must be granted the JTF_SYSTEM_ADMIN_ROLE role.
If using an administrator user to create other users with roles (such as the JTF_SYSTEM_ADMIN_ROLE or the JTF_FM_ADMIN role), the user account accessed to assign JTF roles to another user must already be granted those JTF roles.
If required, you can use the seeded SYSADMIN Oracle Applications user account. If you do not have access to this account, request that the specific JTF roles needed are assigned to your administrator user.
Your implementation may require you to define an administrator in the enterprise who is also a "superuser" (a user with administrator and agent privileges). This superuser not only administers users and system profiles, but also performs work in CRM applications. To achieve this, you must give this superuser the appropriate end user privileges and responsibilities, as described in the topic Creating Oracle Scripting Agents.
Review the information below to determine which requirements apply to your administrator user(s). Then define users, assign responsibilities, and otherwise perform all steps as applicable.
Note: Some tasks (such as granting roles for list and fulfillment administration, or adding JTF system-level properties) require existing JTF roles such as JTF_SYSTEM_ADMIN_ROLE and JTF_FM_ADMIN role. Your Oracle Applications login must already be granted JTF roles in order to assign them or to administer advanced system-level properties. For this purpose, if required, you can use the seeded SYSADMIN Oracle Applications user account.
A matrix of responsibilities that may be required for various users is included below. The matrix includes user type (administrator or agent), responsibility name, the function provided by the responsibility, and the specific component that may require the responsibility.
Not all responsibilities listed in the matrix for each user type is necessarily required. For example, if Oracle Human Resource Management Systems is not installed, the HRMS Manager responsibility is not required. Similarly, for survey implementations, Oracle Marketing and Oracle One-to-One Fulfillment administration responsibilities are only required for list-based survey implementations.
Review the specific requirements for your implementation. Each implementation or administration task in this document lists the responsibility required to perform that task.
User Type | Responsibility | Function | For Component(s) |
---|---|---|---|
Administrator | System Administrator |
|
All |
Administrator | HRMS Manager |
|
All |
Administrator | CRM Resource Manager |
|
All |
Administrator | Scripting Administrator | Access the Scripting Administration console. This is required to:
|
All |
Administrator | Survey Administrator | Access the Survey Administration console. This is required to:
|
Survey |
Administrator | iSurvey User | Schedule or run concurrent programs. | Survey |
Administrator | One-to-One Fulfillment Administrator |
|
Survey These fulfillment administration tasks are required for implementations using targeted (list-based) survey campaigns |
Administrator | Oracle Marketing Super User |
|
Scripting Engine for agent application If Oracle TeleSales agents must launch a specific script, the script must be associated with a campaign or campaign schedule. Survey For list-based survey campaigns, lists must be created and administered. |
Administrator | Sales Online SuperUser |
|
Scripting Engine for agent application If Oracle TeleSales agents must launch a specific script, the script must be associated with a campaign or campaign schedule. |
Administrator | CRM HTML Administration | Administer Oracle CRM HTML applications, including verifying or adding Guest User JTF system-level properties so that survey respondents using the non-hosted IESSVYMAIN.JSP template can start an Oracle applications session. | Survey |
Agent | Scripting User or Scripting Agent |
Launch scripts in "standalone mode" from Oracle Forms, typically to test deployed scripts. | Scripting Engine for agent interface |
Agent | Customer Support | For agents accessing Oracle Scripting from within the integrated Oracle TeleService application. | Scripting Engine for agent application |
Agent | TeleSales Agent | For agents accessing Oracle Scripting from within the integrated Oracle TeleSales application. | Scripting Engine for agent application |
Create and administer one or more administrator user with the appropriate responsibilities for your implementation.
Administrator users must be created first, and are used to accomplish all other implementation and administration steps. Use the Implementation Responsibility Matrix as a guideline.
Note that at least one administrator user requires the JTF_SYSTEM_ADMIN_ROLE to perform some implementation administration steps. Any administrator user that requires access to Oracle One-to-One Fulfillment also requires the JTF_FM_ADMIN role. Any user that must grant roles to other users must also already possess the role in question. For more information, see Granting JTF Roles.
Optionally, create and administer one or more agent user with the appropriate responsibilities for your implementation.
The order in which agent users are created is at your discretion. You may choose to create Oracle Applications users for each agent immediately following the creation of an administrative user, assuming you have all information required. Alternatively, agent users can be created immediately prior to use of an agent login for administration or testing purposes.
Use the Implementation Responsibility Matrix as a guideline. Specific steps are detailed in Oracle Interaction Center Server Manager Implementation Guide.
The first task for user creation and administration is to create employees in the employee database.
If HRMS is installed, you must use Oracle HRMS to create and administer employees. This requires the HRMS Manager responsibility.
If HRMS is not installed, you must use Oracle CRM Resource Manager to create and administer employees. This requires the CRM Resource Manager responsibility.
After creating employees in the database, import each employee as a CRM resource. This requires the CRM Resource Manager responsibility.
If resource group membership is required for the user, create and administer groups first. Ensure you provide the appropriate role types, roles, and usages to the group. If the appropriate group already exists and has the appropriate attributes, skip this step.
After resource group creation (if applicable), import the employee as a CRM resource. Ensure you provide the appropriate role type and role for the employee. Employees do not have usages.
If required, query the appropriate group and associate the employee from within the group. Verify that the person has the appropriate role types and roles.
Define Oracle Applications users. This requires the System Administrator responsibility.
First select the user name and password. Verify the password.
Assign the appropriate responsibilities for this user. Use the Implementation Responsibility Matrix as a guideline.
If an employee in the database, associate this Oracle Applications user account with the employee in the enterprise database.
For the purposes of Oracle Scripting implementation and use, administrators fall into three categories: system administrators, script administrators, and survey campaign administrators. The first two categories are required for all implementations. Survey administrators are required for any implementation in which scripts are intended to be executed in a Web browser. You can establish the same individual with all administration privileges, or you can create two or more administrative users.
System administrators have the System Administrator responsibility, and administer users and applications across the broad spectrum.
One task of a system administrator is to create users. To start the process of creating users for Oracle Scripting, you can either use SYSADMIN or you can create your own system administrator user.
Script administrators access the Scripting Administration console, an HTML user interface that provides access to the Script Author Java applet, allows administration of Oracle Scripting files, and provides access to agent interface report generation and analysis. Individuals who develop scripts using the Script Author component require access to this administrative UI.
Survey administrators access the Survey Administration console, an HTML user interface that provides the ability to establish survey campaigns and to administer targeted survey campaign deployments using Oracle One-to-One Fulfillment and Oracle Marketing functionality. This console also provides access to view individual responses to a Web-enabled survey campaign: individuals who monitor campaign status for ongoing active survey campaigns or who analyze past campaigns require access to this administrative UI.
Note: Administrator users can be created by any Oracle Applications user account with the System Administrator responsibility, with one exception. If implementing the survey component, the administrator user must be granted the JTF_SYSTEM_ADMIN_ROLE and may require the JTF_FM_ADMIN role. Your Oracle Applications login must already be granted JTF roles in order to assign them. For this purpose, you can use the seeded SYSADMIN Oracle Applications user account.
Implementations requiring execution of targeted survey deployments require additional roles, responsibilities, and must meet or bypass sales group membership requirements. See the following sections:
Consult the table below to determine which administrator user setup steps are required for your implementation.
Note: If your administrator also needs agent functions, see Creating Oracle Scripting Agents.
Then perform all steps as applicable.
If administrator needs to do this... | Perform these steps... | Consult these documented tasks... |
---|---|---|
Create or modify Oracle Applications users |
|
Creating and Administering Users |
Create or modify an employee in the enterprise database |
|
Creating an Employee in the Enterprise Database |
Create a resource group in CRM Resource Manager |
|
Creating a Resource Group |
Import an employee as a CRM resource |
|
Importing a CRM Resource |
Access the Scripting Administration console to perform any of the following:
|
|
Assigning Scripting Administrative Responsibilities to Users |
Access the Survey Administration console to administer survey resources |
|
Assigning Survey-Related Administrative Responsibilities to Users |
Access the Survey Administration console to perform any of the following:
|
|
Assigning Survey-Related Administrative Responsibilities to Users |
Manage survey campaign responses, including:
|
|
Assigning Survey-Related Administrative Responsibilities to Users |
Generate summarized Web interface reports or panel footprint reports |
|
Assigning iSurvey User Responsibility for Administering Concurrent Programs for Survey Execution |
View, generate, or modify lists for list-based survey campaigns |
|
|
Access the Invitations tab from the Survey Administration console to administer fulfillment documents for list-based survey campaigns |
|
Oracle Scripting has varying requirements for administration, based on the components required for your implementation.
All new or upgraded implementations require a Scripting administrator.
Implementations requiring execution of a script in a Web browser require a survey administrator.
Implementations requiring execution of list-based surveys require additional roles, responsibilities, and group membership requirements.
Implementations requiring customization of self-service Web applications need administrators of the appropriate application to customize the JSP pages to include survey URL links.
Implementations using Oracle Applications on the UNIX platform have additional configuration steps based on platform and patch level.
Implementations requiring multiple Apache listeners require Apache Web server administrators intimately familiar with Oracle Applications administration.
This section includes the following topics:
Assigning Scripting Administrative Responsibilities to Users
Assigning Survey-Related Administrative Responsibilities to Users
The Scripting Administrator responsibility is required for a user to log into the Scripting Administration console, from which the Script Author Java applet can be launched, deployed scripts can be viewed and deleted, Java archives can be viewed, deleted, or mapped to deployed scripts, and agent interface reports can be generated and analyzed.
Assign the Scripting Administrator responsibility to users of the Scripting Administration console, as described in Defining Oracle Applications Users.
For testing purposes, you may want to test scripts by executing them after they are created and deployed. In this case, you will also want the Scripting Agent, Vision Enterprises, or Scripting User responsibility as well.
You can provide the Scripting administrator with a responsibility to launch a business application such as Oracle TeleSales or the Customer Care component of Oracle TeleService.
To allow the user to manage and control scripts to be executed in the Scripting Engine Web interface, you must enable the same administrator user to perform survey administration tasks. In this case, follow all additional recommendations in Assigning Survey-Related Administrative Responsibilities to Users.
For a full list of responsibilities that may be required for Oracle Scripting, see Implementation Responsibility Matrix.
Assign the appropriate Survey-related responsibilities to appropriate administrator users as described in Defining Oracle Applications Users.
The following is a summary of Oracle Applications responsibilities for using Survey:
The Survey Administrator responsibility is required for a user to log into the Survey Administration console, from which survey campaigns are created, deployed, and managed.
The iSurvey User responsibility is required to run Concurrent Manager for processing and scheduling of concurrent programs required to support survey operations.
Optionally, you can assign the One-to-One Fulfillment Administrator responsibility, required to access Oracle One-to-One Fulfillment, to an Oracle Applications user with the Survey Administrator responsibility. In this way, the same user would have the ability to administer all aspects of Oracle One-to-One Fulfillment required for list-based survey operations.
Note: While assigning the One-to-One Fulfillment Administrator to a survey administrator user is not required, logging into Oracle Applications as a fulfillment administrator is required in order to perform the implementation step described in Adding Survey Administrator User to a Fulfillment Group.
For a full list of responsibilities that may be required for Oracle Scripting, see the Implementation Responsibility Matrix.
Many CRM applications require users to be associated with CRM resource identification codes. This requires users to be defined as employees in the enterprise database, and to be imported as CRM resources. Oracle recommends that these steps be performed for all agent users as the first steps in agent creation.
You must define agent users that can log into an Oracle Applications session. Each agent user must be assigned the appropriate responsibilities to perform a particular set of functions. To define an agent for Oracle Scripting, you must know all tasks the agent will perform, and how Oracle Scripting will be used at the enterprise.
Additionally, applications that rely on campaign information (such as Oracle TeleSales and Oracle Marketing) may require agents to have specific group membership and roles assigned to them, and also for the script to be explicitly associated with a campaign.
Review the information below to determine which requirements apply to your agent users. Then define users, assign responsibilities, and otherwise perform all steps as applicable.
Consult the table below to determine which agent user setup steps are required for your implementation. Then perform all steps as applicable.
If agent needs to do this... | Perform these steps... | Consult these tasks... |
---|---|---|
Use the Agent interface to execute scripts in standalone mode |
|
|
Use the Agent interface to execute scripts from Customer Support component of Oracle TeleService |
|
|
Use the Agent interface to execute scripts from business applications requiring campaign information (Oracle TeleSales) |
|
|
Use the Web interface to execute scripts from a self-service Web application in a Web browser |
|
|
Use the Web interface to execute surveys in a Web browser |
|
|
Use the Web interface to execute list-based surveys in a Web browser |
|
|
The implementation tasks detailed in this section are required only for Scripting Engine operations for the Java-based interaction center agent application.
In addition to these tasks, you will also need to set up the Scripting Administration console as described in Setting Up the Scripting Administrative Interface.
This section includes the following topics:
Assign the appropriate Scripting Engine-related responsibilities to appropriate agent and administrator users as described in Defining Oracle Applications Users.
The agent interface for the Scripting Engine is a Java bean that runs in an Oracle form. A script can be executed in the agent application by any Oracle Applications user with the appropriate responsibility.
Scripts can be launched in the agent application either in standalone mode (recommended for testing), or from an integrated application. In either case, you must have the appropriate responsibility for that application assigned to your Oracle Applications login.
Following is a summary of Oracle Applications responsibilities for using the Scripting Engine in the agent application:
The Scripting User or Scripting Agent responsibility is required for a user to launch scripts in standalone mode.
The Customer Support responsibility is required to run the Oracle Support component of Oracle TeleService, from which a user can launch a script in the agent interface.
The TeleSales Agent responsibility is required to run Oracle TeleSales, from which a user can launch a script in the agent interface.
For a full list of responsibilities that may be required for Oracle Scripting, see the Implementation Responsibility Matrix.
Setting system profiles determines the behavior of Oracle Applications. To implement the Scripting Engine agent interface, follow the procedure described in Setting System Profile Values for the following system profile options.
See the Guidelines for information on these settings.
Note: If your implementation requires a separate Apache JServ listener established for Oracle Scripting, select the Application option. This may be required to avoid session timeout errors, as described in Setting Session Idle Timeout Values for Apache JServ.
Step | Option | Level | Value |
---|---|---|---|
1 | IES : Architecture Type | Site | Apache Mid Tier/Servlet Architecture |
2 | IES : Debug Mode | Site, Application, Responsibility, or User | Debug off or Debug on |
3 | IES : Display Suspend Button on Script Frame | Site, Application, Responsibility, or User | False or True |
4 | IES : Initial Script Frame Size | Site, Application, Responsibility, or User | <Desired frame size, based on agent desktop resolution or overall requirements> |
5 | IES : Scripting Panel Display Mode | Site | Display Multiple Panels at a time in Scripting window or Display Single Panel at a time in Scripting window |
6 | IES: Proxy Server Name | Site or Application | <Name of Proxy server if used for Scripting Engine agent UI> |
7 | IES: Proxy Server Port | Site or Application | <Port of Proxy server if used for Scripting Engine agent UI> |
8 | Apps Servlt Agent | Site or Application | <URL for the Servlet zone of the enterprise Apache Web server> |
A full list of profile option settings required to implement Oracle Scripting is included in Oracle Scripting Profile Options.
Author Debug: Turning Author Debug Mode on will log additional informational messages regarding Script Author operations. When enabled, this profile option provides additional informational and error messages for Script Author debugging, generated in the Apache server logs. Note that you must administer (configure) your Apache Jserv to send console output to the Apache error log.
Architecture Type: The only supported architecture type is the Apache Mid-Tier/Servlet Architecture.
Note: If Apache Mid Tier/ Servlet Architecture value is not in the list of values, and instead you see Two Tier Mode and Three Tier Mode, stop your work and see your systems administrator. This means your environment has not been upgraded beyond Oracle Applications 11.5.5. Do not select Three Tier Mode.
Note: New Scripting Engine implementations with this profile option configured for the Caching Architecture will not be supported.
Debug Mode: Turning Debug Mode on will log additional informational messages regarding Scripting Engine execution and other operations. Message logs for debugging or informational purposes are accessible from OAF technology stack applications such as the Survey Administration console in which the Diagnostics global button appears. This button is displayed in the UI only when the FND: Diagnostics button is set to Yes at the site, application, responsibility, or user level.
Display Suspend Button on Script Frame: Deployed scripts which have the global Suspendable script property option checked (set to True) can suspend Oracle Scripting transactions when this option is set to True. If enabled, a Suspend button displays on the bottom of the script frame (next to the Disconnect button). This button is hidden if the profile is set to False (or remains null). Oracle recommends setting this option to True only (a) if the agent interface is used in standalone mode, or (b) when applications integrated with Oracle Scripting are updated to include the ability to resume the script from the business application. This can be set at the site, application, responsibility, or user level, as required.
Initial Script Frame Size: This profile option controls the initial size of the Scripting Engine frame window in the Forms/Java agent user interface. Default size is 800 pixels in width and 600 pixels in height. Administrators can now select other options including 1024 X 768, 1280 X 1024, or Maximized. This can be set at the site, application, responsibility, or user level, as required.
Scripting Panel Display Mode: There are two lookup values from which to choose: Display Multiple Panels at a time in Scripting window and Display Single Panel at a time in Scripting window. Using single-panel mode, only the current (active) panel will appear on the screen at any given time in the agent UI. Under multi-panel display mode, the active panel will have focus, but panels previously visited will appear in the UI, scrolling out of site. Panels that are not active are de-emphasized (they appear smaller and gray). Active panels display unformatted, spoken, instructional, and custom text in black, blue, magenta, and custom colors as designed. For more information, see the topic "The Panel Display Area" in the section "Understanding the Scripting Engine" of the Oracle Scripting User Guide and online documentation.
Proxy Server Name: This references the name of any proxy server required for using Oracle Scripting, and enables the use of HTTPS. This is only required for Scripting Engine agent UI implementations using a Proxy server.
Proxy Server Port: This references the port number of the appropriate proxy server required for using Oracle Scripting, and enables the use of HTTPS. This is only required for Scripting Engine agent UI implementations using a Proxy server.
Apps Servlet Agent: Type the URL for the Servlet zone of the Apache JServ listener intended for Oracle Scripting in this field.
Syntax:
http://<servername>.<domain>:<Apache Web server port>/<servlet_zone>
Example:
http://server1.yourcompany.com:7777/oa_servlets
This setting is required for Apache mid-tier architecture implementations of Oracle Scripting. This profile is populated with the servlet zone of the Apache Web server. If your implementation requires only one Apache Web server listener, this profile is set at the site level and is used for all applications. Some environments require multiple Apache Web server listeners. For example, if some applications require short session idle timeout settings and others (like Oracle Scripting) require longer idle timeout settings, additional listeners may be configured. In such cases, the URL of the alternate listener is set at the application level for this profile. The specified applications will then reference the alternate Apache JServ instance.
In the Oracle Scripting Apache mid-tier architecture, 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. Sessions in the Apache JServ can be abandoned due to a variety of causes (end user walked away from the computer without logging out, network failure, etc.).
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. In Scripting, the servlet session stores all of the state information of a running script (panels accessed, answers given, etc.). Therefore, a timeout of a Scripting servlet session while an agent is running a script is a fatal error, causing the agent to lose all data that was collected in that session of the script. When this occurs, the agent must close the Scripting window and start a new session of the script, recapturing all information. To avoid this problem, you should verify that the ZONE.PROPERTIES file for the appropriate Apache JServ instance configured for Oracle Scripting has an appropriate timeout setting, and modify this setting if required.
Oracle Scripting requires longer Apache JServ session idle timeout settings than other types of applications using Apache JServ. Interaction centers generally use a relatively small number of dedicated Oracle Scripting agents, who will typically remain logged in throughout the course of the day. In between script transactions, Scripting agents may be idle (from an application perspective) for long periods of time (possibly hours). During an active script transaction, when the agent is conversing on the telephone with customers, agents will be generally more active, but will still have some idle periods, possibly lasting several minutes. It is critical to ensure the Scripting session does not expire during a script transaction, as all data and history collected during the script transaction is lost when a session times out. Due to the usage pattern for Scripting and the importance of keeping the session intact throughout an active script transaction, session timeout values for an Apache JServ instance that is running Scripting sessions should be verified and may need to be extended.
The session idle timeout setting for Apache JServ must be set to a large enough value that it will not cause session time-outs during a script transaction. Naturally, this value will vary based on your specific business needs, as well as agent behavior and training, and the use of other applications relying on Apache JServ. In general, a value of 30 minutes is reasonable for typical Oracle Scripting configurations.
Oracle applications using Apache JServ that have many users and who log in for short periods of time throughout the day have different idle timeout requirements. For applications that follow this model (for example, Oracle iStore), the JServ should time-out idle sessions quickly (after a few minutes) so that resources are freed and available for other users.
Generally, it is not recommended to have the Apache JServ session idle timeout value set longer than 30 minutes if you have an application using the Apache JServ in which many users log in for short periods of time throughout the day, as well as other users who log in for extensive periods of time and have long idle periods.
If your Apache is currently serving both types of applications, Oracle recommends configuring one Apache listener for each application type. Each Apache port/listener will have its own respective ZONE.PROPERTIES file, and can therefore support different session idle timeout settings per Apache listener. Thus, for example, if using Oracle iStore and Oracle Scripting, the ZONE.PROPERTIES file for the Apache listener configured for Oracle iStore should be set for a short session idle timeout, whereas the other should be set for a longer timeout for Scripting operations.
Using multiple Apache listeners may require changing the Apps Servlet Agent profile to specify a different Apache servlet zone at the Application level specifically for Oracle Scripting.
Use the following guidance to verify or set the session idle timeout to a value that will prevent any Scripting servlet session from timing out while an agent is in the middle of a script transaction.
This procedure is only required for Oracle Scripting release 11.5.6 or later implementations using the Scripting Engine agent interface in the Apache mid-tier architecture. This problem does not affect the Survey component of Oracle Scripting.
At least one ZONE.PROPERTIES file must exist from appropriate installation of Apache Web server software installed during Oracle Applications implementation.
As with all customization, you should back up the ZONE.PROPERTIES file before modification in the event of data failure.
Modifications should occur at low-traffic times so the Web server can be taken offline momentarily.
Stop the Apache Web server prior to modification.
Change to the directory where your Apache Web server is installed.
Refer to Apache documentation or consult your Apache Web server administrator if you are not sure where to find this.
Change to the directory in which the ZONE.PROPERTIES file resides.
This file is generally in the location <ORAHTTP_TOP>/Jserv/etc/ but may vary, depending on your specific Apache JServ configuration.
Open the ZONE.PROPERTIES file and locate the section of the file containing the session.timeout parameter.
This is preceded by several commented lines (prepended with "#"). The section of the ZONE.PROPERTIES file should appear similar to the following:
# Set the number of milliseconds to wait before
# invalidating an unused session.
# Syntax: session.timeout=(long)>0
# Default: 1800000 (30 mins)
session.timeout=1800000
Verify that the value (in milliseconds) meets requirements for this Apache listener. If not, change the value after "session.timeout=" (adjust it higher or lower accordingly).
Note: There are 60,000 milliseconds in one minute.
Save your work.
Restart the Web server.
Using the Scripting Engine Web interface, you can execute scripts in an Oracle Applications 12-certified Web browser, either from a self-service Web application, or as an information-gathering survey.
This section includes the following topics:
The following requirements are all factors in implementing the Scripting Engine Web interface:
Active survey campaign requirements corresponding to a survey URL
Appropriate survey administrator responsibilities, roles and requirements
A valid Oracle Applications session
Appropriate script end-user responsibility
Oracle Applications platform and patch level
Executing a script using the Scripting Engine Web interface requires appropriate survey campaign information, which must be administered in the Survey Administration console.
To execute a script in a Web browser or to participate in a Web-based survey, the Scripting Engine Web interface end user typically clicks a hyperlink to access a survey URL. The survey URL references a specific active survey deployment (identified by the dID parameter) on the surveying enterprise's Apache Web server listener port. This may be the same Apache listener port established for all Oracle Applications at the enterprise, or it may reference an Apache JServ instance specifically set up for Oracle Scripting operations.
The survey URL accessed by the script end user in the Web interface is generated when a survey administrator completes all requirements for a survey campaign in the Survey Administration console and makes the deployment active.
Administering survey campaign information is performed by an Oracle Applications user with the Survey Administrator responsibility. This administrator must have access to existing survey resources, survey campaign requirements (including start and end dates), and a valid, tested deployed script.
This administrator must have access to Oracle One-to-One Fulfillment master documents and lists created with Oracle Marketing. To access the Invitations tab from the Survey Administration console, this administrator user must be added to the appropriate fulfillment group, and requires two JTF roles (JTF_SYSTEM_ADMIN_ROLE and JTF_FM_ADMIN). This user will also require the One-to-One Fulfillment Administrator responsibility if the same Oracle Applications user will also be the administrator for Oracle One-to-One Fulfillment.
Accessing the script or survey in a Web browser associated with the survey URL requires a valid, authenticated Oracle Applications session by an Oracle Applications user typically associated with one or more responsibilities.
For individuals executing a script in a Web browser from an integrated application such as Oracle iSupport, the Oracle Applications login information for the current valid Oracle Applications session is used. The individual selects a link from the customized self-service Web application interface (e.g., Oracle iSupport) to take the survey, which starts immediately using current login authentication.
For individuals executing a script in a Web browser who are not authenticated users of Oracle Application session, a guest user Oracle Applications account is accessed behind the scenes. This guest user account (seeded with Oracle Applications) provides access to an Oracle Applications session with privileges only to execute the designated script. The session starts upon accessing the survey URL, and is terminated upon completion of the script.
Individuals executing a script in a Web browser from a self-service Web application such as Oracle iSupport will use the appropriate responsibility for that application.
Individuals executing a script in a Web browser as a survey use a guest user login. No responsibilities are typically associated with a guest user. As of this release, there are no setup steps required for the guest user (a common Oracle Applications guest user is now used; in previous releases, a guest user for the JTT technology stack was used and sometimes required administration).
Display server setup for UNIX servers
Manual configuration of XML SQL utility
Accessing the script or survey in a Web browser associated with the survey URL requires a valid, authenticated Oracle Applications session by an Oracle Applications user typically associated with one or more responsibilities.
For individuals executing a script in a Web browser from an integrated application such as Oracle iSupport, the Oracle Applications login information for the current valid Oracle Applications session is used, including appropriate iSupport responsibility. The individual selects a link from iSupport to take the survey, which starts immediately using current login authentication.
For individuals executing a script in a Web browser as a survey, an Oracle Applications session is initiated using the Oracle Applications guest user login. No responsibilities are typically associated with a guest user.
Oracle Scripting has two administrative interfaces: the Scripting Administration console and the Survey Administration console. While both are HTML consoles accessed by administrators, they are built on different Oracle Applications technology stacks.
Some setup steps common to both administrator interfaces, some are specific to one interface, and others relate to the installation, patch level, or platform for Oracle Applications.
The Scripting Administration console is built on the JTT technology stack. This console provides the user interface with which script developers can launch Script Author as a Java applet, and script administrators can administer Oracle Scripting files (deployed scripts and Java archives), as well as generate, view and analyze agent interface reports.
The Survey Administration console is built on the Oracle Applications framework. This console provides the user interface with which survey campaign administrators can administer survey resources, create and administer standard and targeted (list-based) survey campaign requirements, and monitor individual responses.
As of Oracle Scripting release 11.5.8 (Interaction Center Family Pack P and later), all implementations require the Scripting Administration console.
Any implementation making use of the Scripting Engine Web interface to execute a script in a Web browser will also require the Survey Administration console.
Users of either administrative interface must have Oracle Applications profile settings appropriately established. The Scripting Administration console additionally requires the administration of some system profiles used by that technology stack. While not required by the Survey Administration console, all implementations inherit the requirement to establish or verify JTF system profiles, as described below.
To generate and view reports for analysis of survey information using Oracle Discoverer, you must perform certain post-installation implementation and administration steps, as outlined in Oracle Discoverer Workbooks.
Additionally, to generate and view the panel footprint report accessible from the Oracle Scripting Administration console, the following apply:
Users of Oracle Applications installed between releases 11.5.1 and 11.5.4 must configure the Oracle XML SQL utility if this is not already configured.
Users of Oracle Applications installed on a UNIX platform must set up a display X server.
Follow the procedures below to implement one or more administrative interfaces to meet the requirements of your implementation.
This section includes the following topics:
Setting system profiles determines the behavior of Oracle Applications. When implementing Oracle Scripting, follow the procedure described in Setting System Profile Values for the following system profile options. These include six JTF profiles establishing default behavior of JTT HTML-based applications and one ICX profile establishing the default language.
See the Guidelines below for information on these settings. Set the following profiles as indicated. Order below is recommended only; you can set these options in any sequence.
The settings below are provided as recommendations. Some may not apply; for example, you may not wish for Oracle Scripting to be established as the default for JTT applications, or you may wish to display a different number of rows. If there are business rules or requirements in your environment for other settings, let those requirements take precedence, or set profile settings at lower levels for the specified users.
Step | Option | Level | Value |
---|---|---|---|
1 | JTF_PROFILE_DEFAULT_APPLICATION | Site or User | 519 (see Guidelines below) |
2 | JTF_PROFILE_DEFAULT_BLANK_ROWS | Site | 3 |
3 | JTF_PROFILE_DEFAULT_CSS | Site | JTFUCSS.CSS |
4 | JTF_PROFILE_DEFAULT_CURRENCY | Site | <Applicable currency. For example, USD for U.S. Dollars> |
5 | JTF_PROFILE_DEFAULT_NUM_ROWS | Site | 10 |
6 | JTF_PROFILE_DEFAULT_RESPONSIBILITY | Site or User | (see Guidelines below) |
7 | ICX: Language | User | As required. Example: American English |
Default Application: This setting assumes this Survey administrator user does not already have other functions in Oracle CRM technology foundation (JTT) HTML-based applications. Should other responsibilities exist for this user, confer with your systems administrator or the specific user to determine whether to modify the existing setting, or set this at the user level. As indicated in the preceding table, 519 is the product code for Oracle Scripting. This setting is not environment-specific.
Default Responsibility: This setting determines the responsibility that is displayed when a user logs into CRM HTML-based applications. If no other responsibilities existed for this user, select Survey Administrator or Scripting Administrator, based on the requirements of your administrative users. If this user already has other responsibilities, it may be a requirement to leave this setting, or set this at the user level. The value for this setting may be specific to each environment. For more information, see Oracle CRM Technology Foundation (JTT) Profile Options.
ICX Language: This setting establishes language for the Internet Cartridge Exchange for Web-based transaction settings. This value is selected from the appropriate language from the FND_LANGUAGES table, and is typically set at the user level.
The Scripting Administration console provides users who are assigned the Scripting Administration responsibility with the user interface from which Script Author can be launched as a Java applet. Additionally, from this user interface, you can view and remove scripts deployed to the database; you can view, upload, and map custom Java archives to any script deployed to the database; and you can generate, view and analyze panel footprint reports.
In earlier releases, the Survey Administration console included a Quick Find menu feature to locate survey campaigns, cycles, or deployments. For certain users upgrading Oracle Applications, this menu continues to display in any CRM Technology Foundation (JTT technology stack) application associated with product code IES (Oracle Scripting), even though it is obsolete. (This menu will not appear in new implementations.) For upgrading implementations prior to Interaction Center Family Pack Q or release 11.5.9, this menu will appear in the Scripting Administration console. You can remove the Quick Find menu from Scripting applications manually, after which it will not appear. See Removing the Quick Find Menu.
Other than performing installation, patch level, or platform-specific setup steps, no other tasks are required to implement the Scripting Administrative Interface.
The Survey Administration console provides users assigned the Survey Administration responsibility with the user interface from which survey campaigns are created and administered. Active survey campaigns are required in order to execute a script in a Web browser using the Scripting Engine Web interface.
From this user interface, you can administer survey resources, define or change survey campaign information and status, access Oracle Marketing and Oracle One-to-One Fulfillment functionality required for targeted (list-based) survey deployments, and view responses received from users who executed the survey campaign script in a Web browser.
Other than performing installation, patch level, or platform-specific setup steps, no other tasks are required to implement the Survey Administrative interface for use with standard (non-list-based) survey campaigns.
Implementations using targeted deployments require the fulfillment administrator role to be assigned to the survey administrator, and require the survey administrator to be a member of a fulfillment group.
Tasks include:
For list-based survey implementations, a user with the One-to-One Fulfillment Administrator and Survey Administrator responsibilities must also be assigned the Fulfillment Administrative role (JTF_FM_ADMIN). This role provides access to Oracle One-to-One Fulfillment's user interface from within the Survey Administration console.
To perform some Oracle HTML-based applications administration, including this task, your Oracle Applications user must be granted the JTF_SYSTEM_ADMIN_ROLE. If required, you can use the seeded SYSADMIN Oracle Applications user account. For more information, see Granting JTF Roles.
This step is only required for implementations requiring targeted (list-based) survey deployments, to allow access to the Invitations tab. If you only wish to access Oracle One-to-One Fulfillment from within that application's user interface (and not from the Invitations tab in the Survey Administration console), then perform this step for the Oracle Applications user assigned the One-to-One Fulfillment Administrator responsibility.
Note: This step is not required for standard (non-list-based) survey campaign implementations, which will not be leveraging Oracle One-to-One Fulfillment capabilities.
The user with the Survey Administrator and One-to-One Fulfillment Administrator responsibilities must be an employee in the enterprise database, must be available as a CRM resource, and must be associated with an Oracle Applications login.
The Oracle Applications login must have the CRM HTML Administrator responsibility assigned to provide access to CRM HTML-based applications as an administrator with full privileges. This includes establishing the appropriate set of system profiles for site and user levels as discussed in previous implementation tasks.
Oracle One-to-One Fulfillment does not need to be implemented at the enterprise to perform this step. Note, however, that Oracle One-to-One Fulfillment must be implemented in order to use the survey administration component of Oracle Scripting for list-based implementations, including for testing.
This task is only required for list-based implementations, and should be performed once per Survey administrator user. However, this step is not required for non-list-based survey campaign implementations, which will not be leveraging Oracle One-to-One Fulfillment capabilities.
Use this procedure to add the Survey Administrator user to a Fulfillment group.
An Oracle HRMS employee must already exist in the enterprise, must be available as a CRM resource, and must be associated with an Oracle Applications login.
An Oracle Applications user account must already be assigned both the Survey Administrator responsibility and the One-to-One Fulfillment Administrator responsibility.
An Oracle One-to-One Fulfillment group must exist in order to perform this step.
Oracle One-to-One Fulfillment does not need to be fully implemented at the enterprise to perform this step, as long as a Fulfillment group has been created. Note, however, that must be implemented in order to use the survey component of Oracle Scripting for list-based implementations, including for testing.
Log into Oracle applications using the CRM Home Page login, or the Single Sign-On login if implemented.
One-to-One Fulfillment Administrator
From the Fulfillment Administration console, click the Group tab.
The Groups page appears. A hyperlinked list of defined group names (if any) appear in a table.
Note: If no group names appear in the list, you must first create a valid Fulfillment group as documented in Oracle Oracle One-to-One Fulfillment Implementation Guide.
To add the survey administrator user to an existing fulfillment group, do the following:
Click on the appropriate Group Name hyperlink.
The Group Detail page appears.
In the Name text field of the Agents table, add the Oracle Applications user name of the agent (survey administrator) whom you wish to add to the Fulfillment group, and click Go.
The Select Agent page appears.
Click the appropriate hyperlinked user name in the Agent User Name column.
If necessary, refine your search for the appropriate user name in the Select Agent text field and click Search. You can narrow your criteria using the % wildcard character.
The Group Detail page refreshes. The user name you selected now appears in the Agents list.
Click Update to confirm your selection.
The Groups page refreshes.
Perform the remaining steps to verify that this implementation task was successful.
Select the same Group Name hyperlink from the Groups page.
The Group Detail page appears.
Verify that the survey administrator user name appears in the list of agents.
To add the survey administrator user to a new fulfillment group, do the following:
Click Create.
The Create Group page appears.
In the Group Name text field, enter an appropriate unique group name.
Optionally, in the Description text area, enter a description of this group.
From the Server Name list, select an appropriate server on which this Fulfillment group will be created.
In the Name field under the Agents area, enter search criteria for the first agent whom you wish to add to this Fulfillment group and click Go.
Note: The name criteria should specify the Oracle Applications user name.
Search criteria is case-sensitive.
You can use the % wildcard character.
The Select Agent page appears.
Click the appropriate hyperlinked user name in the Agent User Name column.
If necessary, refine your search for the appropriate user name in the Select Agent text field and click Search. You can narrow your criteria using the % wildcard character.
The Create Group page refreshes. The user name you selected now appears in the Agents list.
Repeat steps 3.5 and 3.6 until you have added all agents whom you wish to add to this Fulfillment group.
Click Create to save this group definition with the group members specified.
Perform the remaining steps to verify that this implementation task was successful.
Select the same Group Name hyperlink from the Groups page.
The Group Detail page appears.
Verify that the specified user names appear in the list of agents.
Continue your work, or click Sign Out to exit Oracle Applications.
Enterprises that implemented Oracle Applications using Rapid Install 11.5.1 through 11.5.6 that wish to use reporting in the Scripting or Survey Administration consoles must manually configure the Oracle XML SQL utility.
Oracle Applications implementations using Rapid Install 11.5.7 or later include automatic configuration of the Oracle XML SQL utility and do not require this task to be performed.
Use this procedure to obtain the appropriate files from your Web server, locate them appropriately, and modify the classpath in the JSERV.PROPERTIES file used by the servlet engine in Oracle HTTP Server.
Note: There is more than one way to specify a class path. If the method described below is not supported by your enterprise implementation, consult with your Apache Web server administrator to determine the appropriate method for your environment. This may include identifying the classpath in a control file or another configuration.
You must have physical or Telnet access to the Web server, and have applmgr or sysadmin privileges. Use the appropriate login for these privileges in your environment.
Your Web server must be configured to use JDK 1.2.2 or above. If you are using a JDK version below JDK 1.2.2, you can upgrade to the most recently certified JDK version with Oracle Applications using My Oracle Support Note 130091.1, titled Upgrading to JDK 1.3 with Oracle Applications 11i; this Note also applies to Release 12 sites that have a JDK version below 1.2.2.
You must retrieve the necessary Java libraries from the $COMMON_TOP/util directory of your Web server to configure your Web server properly. Obtain Xsu12.zip (for 11.5.1 installations) or XSU12_ver1_2_1.zip (for 11.5.2 through 11.5.5 installations).
Connect using Telnet to the enterprise system.
Change to the directory where your Oracle HTTP Server is installed. Refer to the Appendix of your Oracle Applications Installation manual if you are not sure where to find this.
Create a directory called xsu.
If the Java library you obtained is xsu12.zip, extract this file using the command:
unzip $COMMON_TOP/util/Xsu12.zip OracleXSU/lib/oraclexmlsql.jar
If the Java library you obtained is XSU12_ver1_2_1.zip, extract this file using the command:
unzip $COMMON_TOP/XSU12_ver1_2_1.zip OracleXSU12/lib/xsu12.jar
Copy the file you just extracted to the new xsu directory.
For example, on UNIX, you would execute one of the following commands:
cp OracleXSU/lib/oraclexmlsql.jar xsu/
or
cp OracleXSU12/lib/xsu12.jar xsu/
Remove the OracleXSU or OracleXSU12 directory created by the unzip command.
Change to the directory in which the JSERV.PROPERTIES file resides.
Note: The actual name of this file may include an underscore and the Apache JServ port (for example, JSERV.PROPERTIES_9404). For the purposes of this document, the Apache Web server configuration file will be referred to generically as the JSERV.PROPERTIES file. If you have any difficulties locating the file, consult with your Apache Web server administrator.
The location of this file is environmentally dependent. It may be in one of the following paths:
<ORAHTTP_TOP>/Jserv/etc/jserv.properties
<ORAHTTP_TOP>/apache39/conf
The ORAHTTP_TOP variable may not be set for your environment, in which case the path will be fully qualified to identify the entire physical path in the file system. If your configuration is different, consult with your Apache Web administrator to locate this directory.
Load the JSERV.PROPERTIES file into a text editor.
Look in the JSERV.PROPERTIES file for several lines beginning with wrapper.classpath=.
This is the section in the file that sets the CLASSPATH used by the Web server.
If the Java library you obtained is xsu12.zip, add the following line to the JSERV.PROPERTIES file to include the XML SQL Utility libraries in your CLASSPATH:
wrapper.classpath=[ORAHTTP_TOP]/xsu/oraclexmlsql.jar
If the Java library you obtained is XSU12_ver1_2_1.zip, add the following line to the JSERV.PROPERTIES file to include the XML SQL Utility libraries in your CLASSPATH:
wrapper.classpath=[ORAHTTP_TOP]/xsu/xsu12.jar
Note: Replace [ORAHTTP_TOP] with the physical path where your Oracle HTTP Server is installed.
Save the JSERV.PROPERTIES file, and exit the text editor.
Your Web server is now configured to use the Oracle XML SQL Utility.
Back up your JSERV.PROPERTIES file prior to customization. After configuring and testing, also back up your customized JSERV.PROPERTIES file in a separate location.
Note: When you apply a patch, any customizations you have made to the JSERV.PROPERTIES file may be lost. In this case you will need to restore customizations to this file after patching.
This procedure applies to Oracle Applications built on the Oracle CRM Data Model (JTF) technology stack using Unix operating systems on the applications tier. From an Oracle Scripting perspective, this applies to Oracle Scripting implementations (on the Unix platform) that require generation and analysis of panel footprint reports from the Scripting Administration console.
Oracle Applications can dynamically generate and cache images with embedded text at runtime. These dynamic images are used, for example, to create buttons and tab menu bars displayed throughout various HTML-based transaction pages.
JFC/SWING and AWT (graphics libraries that are standard components within Java) require access to the native library of the operating system to process graphics (e.g., to display a window, paint a picture, generate a GIF image, and so on).
The reporting functionality for Oracle Scripting (the panel footprint report available from the Reports tab of the Scripting Administration console) employs JFC/SWING and AWT on the middle tier, where GIF images are processed in support of dynamically generated reports with graphics, and to render a script in a Web browser using HTTP.
Java AWT on Windows servers (Windows NT, Windows 2000) does not need a display server to render the graphics dynamically. However, in order for Java AWT to perform dynamic image generation on UNIX, you must specify an X Server that will be used as a display server to generate dynamic images. Images are generated and cached on the file system. Once these images have been cached, they need not be generated again. For this reason, the display server does not need to be a high-powered machine, nor is it required to be a dedicated server. However, it must be accessible by the Apache server that will call it.
To ensure graphics display functions in all UNIX environments, there are two processes you should perform in a UNIX environment:
Modify JSERV.PROPERTIES to implement the Display Server identifier
Reference the X Server in the apachectl or jservctl file (whichever is used in your environment to start the JServ).
You must have an X Server up and running, on the network and accessible from the Apache JServ machine.
Access the JSERV.PROPERTIES file.
This is typically located at <ORAHTTP_TOP>/Jserv/etc/jserv.properties on the Web server.
Make the following changes to implement the Display Server identifier.
This can be done through xhost +, or through a more secure xauth UNIX command.
Add the following DISPLAY parameter immediately below the wrapper.bin variable.
wrapper.env=DISPLAY=<xserver-hostname>
<xserver-displayport>
Replace <xserver-hostname> and <xserver-displayport> with the machine name and port number where the X Server is running.
Example:
wrapper.env=DISPLAY=myxserver.mycorp.com:0.0
Note: You can also reference a Windows NT machine that is running a UNIX emulator such as Exceed. See the man (UNIX manual) pages for xhost and xauth for more information.
Reference the X Server in the apachectl or jservctl file:
Example:
export DISPLAY=myxserver.mycorp.com:0.0
Note: Whichever file is used to start the JServ for your environment (apachectl or jservctl) should be modified to reference the X server.
For your changes to take effect, fully stop and then restart the Apache Web server services.
Establishing an X Server as a display server is no longer required for UNIX systems in order for survey respondents or self-service Web application users to participate in a survey or script using a Web browser.
Establishing an X Server as a display server is no longer required for UNIX systems using the Survey Administration console.
This step is still required in order to view reports from the Scripting Administration console.