Implementation Tasks

This chapter covers the following topics:

Understanding Users Required for Implementation

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:

References

SYSADMIN Versus Explicitly Created Administrator User Account

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.

JTF Role Requirements

Some implementation or administration tasks require the administrator user to be granted JTF roles before you log into Oracle Applications.

For example:

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.

Administrator Super Users

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.

Implementation Responsibility Matrix

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

  • Create and administer Oracle Applications users

  • Establish or modify system profile settings

  • Establish the link between Oracle Applications user and an employee in the database

 All
Administrator HRMS Manager

  • Create employees in the enterprise human resources database, if Oracle Human Resource Management Systems (HRMS) is licensed and installed at the enterprise.

 All
Administrator CRM Resource Manager

  • Create employees in the enterprise human resources database, if HRMS is not installed at the enterprise.

  • Import employees from the enterprise human resources database as CRM resources.

  • Create and manage resource groups.

 All
Administrator Scripting Administrator Access the Scripting Administration console. This is required to:

  • Launch Script Author Java applet

  • Deploy scripts associated with an Oracle Applications user name, so the script can be mapped to specific custom Java archives

  • View or remove scripts deployed using the Script Author Java applet

  • View, upload, update, or remove custom Java archives to the database

  • Map custom Java archives to specific scripts

  • Categorize custom Java archives as global to apply to all deployed scripts

  • Generate and view panel footprint reports

 All
Administrator Survey Administrator Access the Survey Administration console. This is required to:

  • Define survey resources (header and footer sections, final pages, and error pages in JSP format)

  • Create survey campaigns

  • Define survey cycles

  • Define or deploy survey deployments

  • View specific responses provided by survey respondents to a previously or currently active deployment

 Survey
Administrator iSurvey User Schedule or run concurrent programs. Survey
Administrator One-to-One Fulfillment Administrator

  • Access the Fulfillment Administration console.

  • Set up or change Fulfillment groups

  • Set up or change mail servers associated with Fulfillment groups

  • View failed Fulfillment requests after concurrent programs succeed in passing requests to the Fulfillment server.

 Survey
These fulfillment administration tasks are required for implementations using targeted (list-based) survey campaigns
Administrator Oracle Marketing Super User

  • Access the Marketing Administration console.

  • Establish campaigns

  • Assign scripts to agents or scripts to campaigns

  • Create, import, modify lists

 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

  • Access the Sales Online Administration console to:

  • Assign agents to campaign schedules

  • Assign campaign schedules to agents

 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

Road Map to User Creation and Administration

Order and Timing of User Type Creation

  1. 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.

  2. 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.

Method of Creating and Administering Users

  1. The first task for user creation and administration is to create employees in the employee database.

    1. If HRMS is installed, you must use Oracle HRMS to create and administer employees. This requires the HRMS Manager responsibility.

    2. If HRMS is not installed, you must use Oracle CRM Resource Manager to create and administer employees. This requires the CRM Resource Manager responsibility.

  2. After creating employees in the database, import each employee as a CRM resource. This requires the CRM Resource Manager responsibility.

    1. 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.

    2. 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.

    3. 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.

  3. Define Oracle Applications users. This requires the System Administrator responsibility.

    1. First select the user name and password. Verify the password.

    2. Assign the appropriate responsibilities for this user. Use the Implementation Responsibility Matrix as a guideline.

    3. If an employee in the database, associate this Oracle Applications user account with the employee in the enterprise database.

Creating Administrators for Oracle Scripting

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

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

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

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.

Fulfillment and List Management Administrators

Implementations requiring execution of targeted survey deployments require additional roles, responsibilities, and must meet or bypass sales group membership requirements. See the following sections:

Administration User Setup Steps

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

  • Assign System Administrator responsibility

  • Access Forms-based applications as a system administrator

 Creating and Administering Users
Create or modify an employee in the enterprise database

  • Assign appropriate HRMS responsibility (based on country) or CRM Resource Manager responsibility (if HRMS not installed)

  • Access HRMS or CRM Resource Manager as appropriate

 Creating an Employee in the Enterprise Database
Create a resource group in CRM Resource Manager

  • Assign CRM Resource Manager responsibility

  • Access CRM Resource Manager to create group and assign membership roles and members

 Creating a Resource Group
Import an employee as a CRM resource

  • Assign CRM Resource Manager responsibility

  • Access CRM Resource Manager to import employee

 Importing a CRM Resource
Access the Scripting Administration console to perform any of the following:

  • Launch the Script Author Java applet.

  • Create, modify, or deploy custom scripts using Script Author Java applet.

  • View or remove deployed scripts.

  • Deploy, update, or remove custom Java archives to the Applications database.

  • Define uploaded Java archives as global to apply to all deployed scripts.

  • Map uploaded Java archives to one or more specific scripts.

  • View and generate panel footprint reports.

  • Assign Scripting Administrator responsibility

  • Ensure prerequisite JTT system profiles are established.

 Assigning Scripting Administrative Responsibilities to Users
Access the Survey Administration console to administer survey resources

  • Assign Survey Administrator responsibility

  • Provide FTP access to applications server to deploy JSP resources to $OA_HTML and images to $OA_MEDIA as appropriate

 Assigning Survey-Related Administrative Responsibilities to Users
Access the Survey Administration console to perform any of the following:

  • Create survey campaigns and cycles

  • View or modify survey campaign details

  • Create additional cycles

  • Rename cycles

  • Define deployments

  • View or modify deployment details

  • Change or view deployment status

  • Assign Survey Administrator responsibility

 Assigning Survey-Related Administrative Responsibilities to Users
Manage survey campaign responses, including:

  • View individual Web interface responses

  • Send reminders manually to list members

  • Assign Survey Administrator responsibility

 Assigning Survey-Related Administrative Responsibilities to Users
Generate summarized Web interface reports or panel footprint reports

  • Assigning iSurvey User responsibility to access Concurrent Manager

 Assigning iSurvey User Responsibility for Administering Concurrent Programs for Survey Execution
View, generate, or modify lists for list-based survey campaigns

  • Assign Oracle Marketing Super User responsibility

  • Assign sales group membership and roles or bypass group membership requirements
Access the Invitations tab from the Survey Administration console to administer fulfillment documents for list-based survey campaigns

  • Assign JTF_SYSTEM_ADMIN_ROLE role

  • Assign JTF_FM_ADMIN role

See Also

Performing Further Administration Setups

Oracle Scripting has varying requirements for administration, based on the components required for your implementation.

This section includes the following topics:

Assigning Scripting 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.

Assigning Survey-Related Administrative Responsibilities to Users

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:

For a full list of responsibilities that may be required for Oracle Scripting, see the Implementation Responsibility Matrix.

Creating Oracle Scripting Agents

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.

Agent User Setup Steps

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

  • Assign Scripting Agent or Scripting User responsibility
Use the Agent interface to execute scripts from Customer Support component of Oracle TeleService

  • Assign Customer Support responsibility

  • Optionally, create a relationship plan
Use the Agent interface to execute scripts from business applications requiring campaign information (Oracle TeleSales)

  • Assign Scripting Administrator responsibility

  • Access CRM Resource Manager to provide agent with Sales and TeleSales roles

  • Access CRM Resource Manager to add agent to sales group

  • Access Oracle Marketing to create a campaign and a campaign schedule, associate a script to a campaign schedule, assign agents to a campaign schedule or vice versa
Use the Web interface to execute scripts from a self-service Web application in a Web browser

  • Assign self-service Web application responsibility

  • The topic Scripting Engine Users in the Oracle Scripting User Guide
Use the Web interface to execute surveys in a Web browser

  • Access an active survey URL

  • The topic Scripting Engine Users in the Oracle Scripting User Guide
Use the Web interface to execute list-based surveys in a Web browser

  • Access an active survey URL from an e-mail message invitation or reminder

  • The topic Scripting Engine Users in the Oracle Scripting User Guide

See Also

Implementing the Scripting Engine Agent Interface

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:

Assigning Scripting Engine-Related Responsibilities to a User

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:

For a full list of responsibilities that may be required for Oracle Scripting, see the Implementation Responsibility Matrix.

Establishing Profile Settings for the Agent Interface

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.

Guidelines

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.

References

Setting Session Idle Timeout Values for Apache JServ

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 Timeout Requirements

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 iStore Timeout Requirements

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.

Single Apache JServ Listeners Serving Multiple Application Types

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.

Multiple Apache JServ Listeners

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.

Prerequisites

Steps

  1. 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.

  2. 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.

  3. 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

  1. 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.

  2. Save your work.

  3. Restart the Web server.

Implementing the Scripting Engine Web Interface

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:

See Also

Implementation Considerations

The following requirements are all factors in implementing the Scripting Engine Web interface:

Active Survey Campaign and Survey URL Requirements

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.

Survey Administration Responsibility, Roles and Requirements

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.

Valid Oracle Applications Sessions

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.

Script End User Responsibilities

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).

Oracle Applications Platform and Patch-Level Requirements

Assigning Web Interface Responsibilities to a User

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.

See Also

Implementing Administrative Interfaces

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.

Which Interfaces Do You Need?

System Profile Settings

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.

Reporting Implementation Requirements

Additionally, to generate and view the panel footprint report accessible from the Oracle Scripting Administration console, the following apply:

Follow the procedures below to implement one or more administrative interfaces to meet the requirements of your implementation.

This section includes the following topics:

See Also

Establishing Profile Settings

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

Guidelines

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.

References

Setting Up the Scripting Administrative Interface

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.

Setting Up the Survey 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

Tasks include:

Assigning Fulfillment Administrator Role to Survey Administrators

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.

Guidelines

See Also

Assigning Survey Administrator User to a Fulfillment Group

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.

Prerequisites

Login

Log into Oracle applications using the CRM Home Page login, or the Single Sign-On login if implemented.

Responsibility

One-to-One Fulfillment Administrator

Steps

  1. 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.

  2. To add the survey administrator user to an existing fulfillment group, do the following:

    1. Click on the appropriate Group Name hyperlink.

      The Group Detail page appears.

    2. 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.

    3. 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.

    4. Click Update to confirm your selection.

      The Groups page refreshes.

      Perform the remaining steps to verify that this implementation task was successful.

    5. Select the same Group Name hyperlink from the Groups page.

      The Group Detail page appears.

    6. Verify that the survey administrator user name appears in the list of agents.

  3. To add the survey administrator user to a new fulfillment group, do the following:

    1. Click Create.

      The Create Group page appears.

    2. In the Group Name text field, enter an appropriate unique group name.

    3. Optionally, in the Description text area, enter a description of this group.

    4. From the Server Name list, select an appropriate server on which this Fulfillment group will be created.

    5. 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.

    6. 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.

    7. Repeat steps 3.5 and 3.6 until you have added all agents whom you wish to add to this Fulfillment group.

    8. Click Create to save this group definition with the group members specified.

      Perform the remaining steps to verify that this implementation task was successful.

    9. Select the same Group Name hyperlink from the Groups page.

      The Group Detail page appears.

    10. Verify that the specified user names appear in the list of agents.

  4. Continue your work, or click Sign Out to exit Oracle Applications.

See Also

Configuring the Oracle XML SQL Utility

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.

Login and Responsibility

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.

Prerequisites

Steps

  1. Connect using Telnet to the enterprise system.

  2. 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.

  3. Create a directory called xsu.

  4. 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

  5. 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/

  6. Remove the OracleXSU or OracleXSU12 directory created by the unzip command.

  7. 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.

  8. Load the JSERV.PROPERTIES file into a text editor.

  9. 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.

  10. 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.

  11. Save the JSERV.PROPERTIES file, and exit the text editor.

    Your Web server is now configured to use the Oracle XML SQL Utility.

Guidelines

Setting Display Server for UNIX Environments

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:

Prerequisites

You must have an X Server up and running, on the network and accessible from the Apache JServ machine.

Steps

  1. Access the JSERV.PROPERTIES file.

    This is typically located at <ORAHTTP_TOP>/Jserv/etc/jserv.properties on the Web server.

  2. Make the following changes to implement the Display Server identifier.

    This can be done through xhost +, or through a more secure xauth UNIX command.

  3. Add the following DISPLAY parameter immediately below the wrapper.bin variable.

    wrapper.env=DISPLAY=<xserver-hostname>

    <xserver-displayport>

  4. 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.

  5. 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.

  6. For your changes to take effect, fully stop and then restart the Apache Web server services.

Guidelines

References