This chapter covers the following topics:
Oracle Scripting includes four components: the Scripting Administration console, the Survey Administration console, Script Author, and the Scripting Engine. Any Oracle Scripting project requires a script to be developed using Script Author. This script can then be executed in either the Scripting Engine agent interface (a Java-based user interface used by agents in the interaction center), or in the Scripting Engine Web interface (executed in an Oracle Applications 12 certified Web browser as a series of JSP pages). The same script can be executed in both interfaces.
Appropriate planning for Scripting projects depends on many factors. Chief among them is the intended runtime execution interface for the script. In other words, will the script be executed in the Scripting Engine agent interface? Typical for this scenario is the use of a script in a call center or interaction center (as a call guide, or to help script interactions between customer service agents in an inbound, outbound, or blended environment). Or will the script be executed in the Scripting Engine Web interface (typical uses include using the script as the survey questionnaire in a survey campaign to gather information from a targeted population, or as a Web script from a self-service Web application such as Oracle iSupport). Different considerations apply, and obviously all considerations are applicable in the case of a script intended to execute in both Scripting Engine user interfaces.
Planning Scripting Engine agent interface projects is typically the task of a consulting group within an enterprise. This involves gathering detailed requirements for building the script, understanding the business rules, integration requirements, and short- and long-term goals of interaction center managers. Thus, the primary aspects of planning for Scripting project managers involve project scoping and discovery of existing, emerging and future requirements.
Note: Many of these aspects are also required of scripts to be executed as surveys. As such, this information may also prove relevant to scripts to be run in a Web browser.
This section includes the following topics:
There are three main aspects to the Discovery process as it relates directly to Oracle Scripting:
The text layer refers to the text that is to be read aloud by an agent following a script. In order to appropriately plan a Scripting Engine project, obtain a detailed script or the existing call guide (if one is already in production that will be replaced with Scripting). Ensure you understand fully any changes required to be made to an existing script or call guide.
The logic layer represents a clear understanding of the logic of the desired script, including expected flow, criteria for branching into specific functional areas of a script under specified criteria, and ensuring there are no dead ends in flow or inescapable logic loops. In order to create a clear logic layer, it is important that the implementing enterprise and any consultants understand and map out all business rules covering every eventuality. Oracle Scripting is an excellent tool to present information logically and consistently, but the tool alone is not a guarantee of success. A clear understanding of the business requirements is key. Detailed flowcharting of the entire script and all its possible branches should be performed. This may require specifically trained business analysts and must be completed (and agreed upon by both parties) prior to initiating development.
Note: It is to the benefit of enterprises implementing Scripting as much as to the consultants customizing the scripts to have a complete, clear flow and to design and agree upon acceptance criteria based on the logic layer.
Constant business requirements analysis is typically required during script development as the Oracle Scripting technology automates the process of an agent interacting with customers, and replaces any previous technology. Scripting has limitations which are easily overcome when the objective is clear, which is why it is important for the enterprise using this tool to be educated in Scripting's approach, its question-and-answer paradigm, and any specific obstacles that are encountered and overcome during development of the initial script. It is in the enterprise's interest to follow the progress of the development of the initial script to be delivered, so interaction center managers and technical staff can begin to appreciate techniques, approaches, strengths, and so on. In this way, subsequent script development (or modifications to a script that is delivered and accepted by the enterprise) is greatly simplified. This is true whether performed by the enterprise staff alone, or with additional consulting support.
Considerations for the technology layer include, but are not limited to, an understanding of what technology choices will suit the needs of the script at hand (and specific functionality with in the script). Discovery for the technology layer includes forming choices regarding Script Author objects such as Panels, Groups, Blocks, and appropriate Branches. For example, what technology choice makes for the best, most effective method of text to be delivered by the agent? A single panel? Multiple panels? A group containing logically related questions?
However, the GUI provided by the Script Author has powerful capabilities behind it that greatly extend functionality for the script. Many of these require custom programming. For example, what is the best way for an agent to obtain a set of information required by the business rules? Should the choice be simply to present all customers with a long string of questions in consecutive panels? Or is it better to perform a PL/SQL query to the customer database to determine what information about the customer is known, and determine which remaining information must be collected by creating complex Java methods that analyze the data placed on the Scripting blackboard by the query, and route the agent only to the appropriate questions?
The technology layer includes consideration of, but is not limited to, the following:
Creating and implementing Blocks making database calls or using APIs
Writing PL/SQL procedures
Writing and storing on the database PL/SQL packages
Creating custom Java components
Using APIs to take advantage of Scripting functionality or integrate with other applications
Creating Shortcuts programmed into Groups on the canvas
Using Indeterminate branches combined with custom Java methods to perform "jumps" to different functional Groups within the script (uses the Shortcut property of a group, or the panel or block name if the destination object is on a sibling object)
Populating the global Scripting blackboard with values to be used during execution of the script
Populating the blackboard with key value pairs (by answering questions in a script session) and retrieving them using custom Java methods to control the script flow
Creating custom data tracking in custom database tables
Reusing functionality in existing scripts as templates (importing existing scripts or portions thereof)
Integrating and modifying best practices scripts or surveys
Employing reusable commands to incorporate functionality integrating with other Oracle Applications
The text layer is typically the first to be considered, and while it may be most important to the enterprise implementing the script, it is the least important implementation consideration, providing that specific text is supplied to those building the script, or that there is some flexibility in modifying the required text (for example when the Script Author approach is best served by breaking up a question into two panels).
The text layer can provide certain challenges. For example, in some cases a proposed call guide or script may have undergone legal review prior to coding with Script Author. In the process of building the flowchart representing the final script or building the script itself, changes may be necessitated due to gaps in logic or other reasons. This may then require further approval for any changes, by the legal authority or department of an enterprise. This can impact a delivery schedule if not planned for in advance.
The technology layer aspect of the Discovery process is by far the most time- consuming to implement. Nonetheless, success in determining requirements for the technology layer are strongly dependent on flowcharting being provided as discussed in the logic layer section above. Without detailed business analysis, Discovery for the technology layer will be ineffective and implementing this layer more difficult, time- and resource-consuming.
The technology layer includes many hidden tasks and covers integration points with Scripting and other applications. Full analysis of the logic and technology layers may indicate that a project is more manageable and more likely to serve the needs of the enterprise when broken into a phased approach. In this way, enterprises can benefit enormously from benchmarking efforts required in an initial phase, and determine realistic assessments for subsequent phases to add future Scripting functionality. In the meantime, in early phases the enterprise can have the interaction center up and running using Oracle Scripting, taking the opportunity to train agents and staff while experiencing the advantages of the efficiencies and return on investment of automated scripting.
Appropriate planning is crucial to the success of a Scripting implementation. Tools to assist in this planning include the Oracle Application Implementation Methodology (AIM), a methodology that follows the full life cycle of a custom software implementation. Even if Oracle Scripting is only part of a broader implementation of Oracle Applications, it is recommended to plan for it separately, using a separate Scope, Objectives, and Approach (SOA) document (AIM CR.010) to help plan the resources required for this portion of the implementation.
Part of a consultant's skill set is the ability to perform a thorough Discovery process to fully understand an enterprise's requirements, existing infrastructure and environment, and long-term needs. Included below are some tools to aid in scoping a potential Scripting project. These include the Oracle Scripting Discovery Data Worksheet, which helps to gather information specific to Oracle Scripting that should be obtained for the potential Scripting project in general. The other tool provided here is the Oracle Scripting Discovery Checklist Tool, which should be filled out for each distinct functionality expected to be created in a script (for example, each group on the canvas).
Using these as aids to the Discovery process can help gather information that will be crucial to appropriate planning, allocation of resources, and scoping of the effort in general.
The following worksheet covers an entire Scripting engagement for which you are attempting to gauge the scope in order to properly provide a time estimate and to assess the skill and resource requirements.
For which of the following purposes is Oracle Scripting intended to be used?
Pure conversation scripting purposes
Desktop integration tool
Surveying/Polling
Other (describe:)
If Oracle Scripting will be used for desktop integration, describe the requirements in general:
Characterize the script required:
Inbound Call Guide
Outbound Call Guide
Blended Call Guide
Guided Selling
Survey Questionnaire
Web Script
Undetermined
Are scripts required that support languages other than English? If yes, identify the language or languages.
Note that any translation of an existing script must be physically performed with a copy of the script using Script Author. Changing the language global property of a script does not translate panel text, questions, or answer choices.
How many individual scripts are required to be developed? If undetermined, please indicate.
Is the required script based on an software-driven processes? If so, will any business process reengineering be included as part of this effort? If yes, how many?
Is the required flow already flowcharted?
Is the required script based on an existing script or call guide? If yes, how many?
If required script is based on an existing document, script, or flow, will any business process reengineering be included as part of this effort? If yes, what percentage of the existing script is expected to change?
If appropriate, attach printouts of the existing scripts to this document or note electronic file name and format of existing script.
What guidance currently exists from which Oracle Scripting scripts will be developed?
Narrative
Flowcharting
System Requirements Document (SRD)
Existing scripts or call guides
Is Computer-Telephony Integration (CTI) intended for use in the facility or facilities? Does the customer have a need to display different call guides using CTI? If so, what will be the criteria?
Dialed Number Information Service (DNIS)
Automatic Number Identification (ANI)
Unique ID (UUID)
Account type
IVR information
Other (Describe:)
Is Interactive Voice Response (IVR) unit information required? If so, is IVR in place?
Does CTI currently exist? If so, describe:
From which integrated Oracle business application is the script expected to be launched?
Oracle TeleSales
Oracle TeleService
Oracle iSupport
Other (list:)
Note that executing scripts in the Scripting Engine agent interface in standalone mode (without other Oracle Applications) is not supported except for script testing and evaluation.
If using Oracle TeleSales, does a marketing campaign already exist in Oracle Marketing?
These applications require a script to be associated with a campaign schedule which in turn is associated with a specific Oracle Marketing campaign.
Is integration with other Oracle Applications required?
For survey campaigns, will required survey campaigns be targeted (list-based) or standard (non-list-based)?
For targeted campaigns only: Do appropriate lists already exist in Oracle Marketing?
For targeted campaigns only: Will invitations only be required, or invitations and reminders?
Note that the seeded Survey List Query must be used as the basis for the query associated with an invitation or reminder master document.
Will staff at the implementing enterprise create and maintain its own scripts?
Gap Analysis. Describe in detail any modifications that Oracle (or partner) must make to the generic version of Oracle Scripting in order to satisfy the needs of the customer.
First, qualify each call guide or script required using the following checklist. Then, break down the requirements for each distinct functionality within each script (as represented by groups in the script, or functions separated by agent roles) as the Discovery and Scoping process continues.
Be careful to label each main script checklist, and its dependent checklists, appropriately.
Checklist ID __________
Checklist type:
____ Top-level script checklist ____ Script functionality breakdown checklist
| Check | Number of Panels | Check | Development Level Assessment |
|---|---|---|---|
| ___ | Very Small (1 to 25 panels) | ___ | Very Simple |
| ___ | Small (25 to 40 panels) | ___ | Simple |
| ___ | Medium (40 to 100 panels) | ___ | Lower Intermediate |
| ___ | Medium to Large (100 to 200 panels) | ___ | Upper Intermediate |
| ___ | Large (200 to 400 panels) | ___ | Complex |
| ___ | Very Large (Over 400 panels) | ___ | Very Complex |
| Comments: | Comments: |
| Check | Required Script Objects | Check | Required Branching Types |
|---|---|---|---|
| ___ | Panels | ___ | Very Simple |
| ___ | Groups | ___ | Simple |
| ___ | Blocks | ___ | Default |
| ___ | Primarily Panels and Groups | ___ | Distinct |
| ___ | All object types | ___ | Conditional |
| ___ | Indeterminate | ||
| Comments: | Comments: |
| Check | Script Creation and Modification Method | Check | Panel Modification and Customization |
|---|---|---|---|
| ___ | Graphical script only | ___ | Primarily use automatic panel layout |
| ___ | Wizard script only | ___ | Moderate panel HTML customization |
| ___ | Started with wizard, converted to graphical script | ___ | Substantial panel HTML customization |
| Comments: | Comments: |
| Check | Database Integration | Check | PL/SQL Integration |
|---|---|---|---|
| ___ | No database will be used | ___ | No PL/SQL will be used |
| ___ | Database integration required | ___ | Custom PL/SQL commands required (amount) |
| ___ | Custom tables required | ___ | Required for Oracle Applications schema only |
| ___ | Custom schema(s) available (if so, attach) | ___ | Required for custom tables (schema required) |
| Comments: | Comments: |
| Script Author Command Types | Required? (Yes/No) | Resourced? (Yes/No) | Planned? (Yes/No) | Template Exists? (Yes/No) |
|---|---|---|---|---|
| PL/SQL | ||||
| Java | ||||
| Blackboard | ||||
| Constant | ||||
| Forms |
| Technology | Required? (Yes/No) | Resourced? (Yes/No) | Planned? (Yes/No) | Exists? (Yes/No) |
|---|---|---|---|---|
| HTML | ||||
| Graphics | ||||
| Hyperlinks | ||||
| Best Practice Java Methods | Yes | |||
| Custom Java Methods | ||||
| JavaScript | ||||
| Java Beans |
| Integration | Required? (Yes/No) | Resourced? (Yes/No) | Planned? (Yes/No) |
|---|---|---|---|
| Oracle TeleSales | |||
| Oracle TelesService | |||
| Oracle Forms | |||
| Oracle iSupport | |||
| Oracle One-to-One Fulfillment | |||
| Oracle Marketing | |||
| Discoverer | |||
| Legacy Application |
| Check | Scripting Engine Execution Requirements (Check all that apply) |
|---|---|
| ___ | Agent Interface |
| ___ | Execute scripts in standalone mode (no calling business application) |
| ___ | Integrate with Customer Support component of Oracle TeleService |
| ___ | Integrate with Oracle TeleSales |
| ___ | Integrate with other Oracle Forms-based applications (Identify)___________ |
| ___ | Web interface (requires survey campaign administration) |
| ___ | Execute as survey |
| ___ | Execute as web-based script |
| ___ | Integrate with Oracle iSupport |
| ___ | Integrate with Oracle iStore |
| ___ | Integrate with other Oracle HTML-based applications (Identify)______________ |
| ___ | Includes targeted (list-based) deployment |
| ___ | Includes standard (non-list-based) deployment |
| ___ | List required? (Indicate name if existing)___________________________ Number of list records: ________ |
| ___ | Invitation required? (Indicate name if existing)___________________________ |
| ___ | Reminder required? (Indicate name if existing)___________________________ |
| ___ | Query required? (Indicate name if existing)_____________________ (Must be based on Survey List Query) |
The main purpose for executing scripts as surveys is to obtain data (via a clearly defined survey questionnaire) from a population over a specific period of time for a particular business purpose. Using a script as the questionnaire, enterprises can rapidly solicit and receive such data at low cost by defining a survey campaign in the Survey Administration console. This data is then typically collected and analyzed to serve the enterprise by improving products or processes, or otherwise allowing the enterprise to be responsive to its polled population. Using an Oracle Scripting-specific end user layer in Oracle Discoverer, survey administrators or interaction center managers can subsequently create on-demand reports based on the data received from survey respondents.
This survey data may be solicited from a targeted population (using predefined Oracle Marketing lists) or from a general population. Targeted populations may include customers or prospective customers, but also partners or affiliates, a company's own employees, and so forth. Business purposes may in some cases be served by responses from a random population. At other times business purposes may be best served by receiving feedback from an identified population. Both are supported by Scripting Engine Web interface.
| Step | Description |
|---|---|
| 1. Define survey campaign requirements | Obtain requirements for all aspects of the survey campaign (survey campaign, cycle, and deployment-specific requirements). These should be documented using appropriate methodology; for example, if using the Application Implementation Methodology (AIM), obtain Scope, Objectives and Approach document and Business Requirements documents such as BR.100. |
| 2. Create and deploy script | Create script for survey questionnaire based on documented requirements (captured in step 1) and deploy to appropriate applications database. |
| 3. Decision: Targeted deployments in survey campaign | Are deployments in the survey campaign targeted (list-based), standard, or both? If targeted deployments = NO, go to step 5. If YES, continue at step 4. |
| 4. Generate lists (for targeted survey campaigns) | Generate, create or import lists in the Survey Administration console (one list per deployment, if multiple deployments are required). Note that the same list can be used for multiple deployments (and also for multiple survey campaigns). Generating lists requires the implementation of list management portions of Oracle Marketing. Note that successful delivery of invitations (and reminders) to participate in survey campaigns requires fully implemented and configured Oracle One-to-One Fulfillment (including definition of an outgoing e-mail server) as well as Oracle Marketing. |
| 5. Administer survey resources and survey campaign details | Create and upload (or modify existing) survey resources to be displayed when using survey campaigns. Then define these survey resources in the Survey Administration console. The preceding comprise all survey resources administration steps. Subsequently, administer the survey campaign details in the Survey Administration console. This includes creating a survey campaign and cycle. |
| 6. Define deployments | In the Survey Administration console, define deployment information for one or more deployments subordinate to each cycle in a survey campaign, based on documented requirements. For targeted campaigns, this will include lists, invitations, and (if included in requirements) reminders. |
| 7. Activate survey deployment | In the Survey Administration console, set deployments to Active status. This makes the survey campaign available to respondents immediately (or, for targeted deployments, as soon as the invitations are delivered by the fulfillment engine). |
| 8. Monitor ongoing results | Monitor survey campaign. From the Responses tab of the Survey Administration console, individual responses can be monitored from the moment a deployment becomes active. Each question and the response selected is displayed per respondent. |
| 9. Collect information in Oracle RDBMS | As respondents complete survey questionnaires, information is collected in Oracle RDBMS. No action is required to collect this data. |
| 10. Report survey results | Using Oracle Discoverer along with survey-specific concurrent programs, generate on-demand reports using existing Discoverer workbooks. Knowledgeable Oracle Discoverer administrators can also generate custom reports. Requires implementation of an Oracle Scripting end user layer. |
This section includes the following topics:
Determining If Survey Campaign Requires Targeted Deployments
Administering Survey Resources, Survey Campaign and Cycle Details
Prior to creating a script to use as the survey questionnaire or to administering survey campaign data in the Survey Administration console, a survey campaign must be planned, from top-level strategic aspects down to a detailed level. This includes gathering the requirements for all aspects of the survey campaign, from top-level goals to the names of cycles and deployments and start and end dates of each deployment. Step 1 of the business process flow includes the determination of information that is required for all other steps in the business process flow.
Substantial information must be gathered in the planning stage prior to proceeding to step 2 of the business process flow or beyond. If you are using AIM in your implementation, this data would be identified in various AIM documents.
The following information is required for all survey campaigns:
The goals of a survey campaign must be clearly documented.
The target population (if any) must be identified.
The method of obtaining survey data (the respondent entry point) must be determined.
The requirement for targeted or standard deployments must be indicated. Standard deployments have substantially fewer requirements.
Survey questionnaire requirements must be obtained to a detailed level. The manner in which data will be collected must be defined, including data type, collection method, sequencing and flow.
What type of data will be collected from respondents?
How will this data be used or evaluated?
Will branching logic will be employed? Or will the same questions be asked of all respondents, regardless of previous answers supplied by respondent?
What types of technologies (Java, PL/SQL, Oracle Forms, and so on) will be included in the survey questionnaire script?
What level of skill is required to incorporate the appropriate technology into the script?
In order to ensure that the business goals of the survey campaign will be met, a detailed flowchart and script test plan must be planned for.
The layout, configuration and composition of survey resources (header section, footer section, error page, and final page, if used) intended to display to Web script or survey users must be identified.
The definition of survey resources must be accomplished prior to defining the survey campaign.
The survey campaign name must be identified.
Optionally, a description of the survey campaign (generally including its intended purpose) can be provided.
The base technology stack in which the script is to be executed in a Web browser must be determined. Oracle recommends using the Oracle Applications Framework technology stack, unless compelling reasons exist for using the deprecated JTT technology stack at runtime.
Designation of a survey campaign as a prototype must be identified in advance. This option cannot be changed once the survey campaign is saved.
The survey questionnaire script name (the name designated in the Script Author file properties) must be identified.
Name and number of cycles required must be identified.
Deployment name for each deployment must be identified.
Number and type of deployments per cycle must be identified. Deployments can be either targeted (list-based) or standard (non-list-based).
Deployment start date and time must be identified per deployment.
Deployment response end date and time must be identified per deployment.
For targeted (list-based) deployments, the following must be considered:
The hosting option, which determines authentication method at runtime.
Enterprise Web server and port must be identified as parameters to construct the survey URL, if different than the environment in which administrators log in.
Oracle Marketing and Oracle One-to-One Fulfillment must be implemented. A fulfillment mail server (typically Oracle Email Server) must be configured, and a functioning fulfillment engine established.
Oracle Marketing list must exist, the name must be known, and the list accessible.
Business rules regarding maximum number of responses per Web-based script user must be identified. When set to one (the default value), a list member can take a survey or execute a Web script only one time.
The target response percentage for survey cycles must be identified.
Invitation template must exist and be known, including a master document and associated query. Alternatively, these can be created by a skilled fulfillment administrator at the time of deployment definition (survey flow step 6).
E-mail invitation message subject must be identified.
Requirement for reminders must be determined. If required, Reminder template must exist and be known, including a master document and associated query. Alternatively, these can be created by a skilled fulfillment administrator at the time of deployment definition (survey flow step 6).
The number of reminders and interval between (in days) must be identified if reminders are to be employed.
Survey campaign requirements and detailed information should be collected and documented using a consistent methodology.
Oracle customers, partners and consultants have access to the Application Implementation Method Advantage (AIM). AIM is a set of pre-packaged approaches for implementing Oracle Applications, developed by Oracle's Applications Global Service Line group. There are two subsets (AIM Advantage and AIM FastForward). Each is a proven, scalable toolkit for implementing Oracle Applications.
AIM is broken into six phases to cover the full software life cycle: Definition, Operations Analysis, Solution Design, Build, Transition, and Production.
For the various phases, AIM provides macro-driven document templates to address numerous processes, which typically span more than one phase. Each of these processes is described by a two-letter acronym, as described in the table below.
| Acronym | AIM Process |
|---|---|
| CR | Customer Requirements (Project Management) |
| BP | Business Process Architecture |
| BR | Business Requirements Definition |
| RD | Business Requirements Mapping |
| TA | Application and Technical Architecture |
| MD | Module Design and Build |
| CV | Data Conversion |
| DO | Documentation |
| TE | Business System Testing |
| PT | Performance Testing |
| AP | Adoption and Learning |
| PM | Production Migration |
Documents generated for each AIM process are identified by the process acronym and a number. For example, the top-level document describing the scope, objectives, and requirements of a project (the main customer requirements) is referred to as a CR.010. You may see specific documents within the AIM methodology referenced in various Oracle documentation.
Note that AIM is not a requirement for customer implementations. It is one example of a proven methodology. While planning is required in order to execute an implementation and the subsequent use and administration of a system successfully, any effective methodology will suffice.
A survey campaign has a one-to-one correspondence with a single survey questionnaire. In other words, each survey campaign employs only one script. These survey questionnaire scripts can only be created, modified, and deployed from Script Author.
Part of documenting the requirements for a survey campaign is the detailed definition of the requirements for the survey questionnaire script. This includes information such as specific questions, data format of responses, validation requirements, target audience, branching logic requirements, supporting technologies, questionnaire sequencing and flow. In a best-case scenario, you will have a detailed flow chart depicting the flow of the script, branching, and so forth. You should also have a detailed script test plan to ensure the script, as designed, meets the requirements of the survey campaign. Before creating the script you will need a full understanding of the campaign and enterprise business rules, dependencies, and any integration requirements.
Following a gathering of the requirements, you will need the following to create, modify, and deploy the survey questionnaire script:
The Script Author component of Oracle Scripting is required to build scripts to serve as the survey questionnaire. This requires a networked script development workstation. Network, security, hardware and software resources are indicated below. For more information regarding what is required and recommended for use as a script development workstation, refer to the section entitled "Using Oracle Scripting."
Script Author workstation must be on a network and able to connect with the applications database server in order to deploy scripts.
Script Author uses the thin JDBC driver to communicate with the database. As of release 11.5.6, the Apache mid-tier architecture enables the Scripting Engine to be executed through a firewall using the HyperText Transfer Protocol (HTTP).
If the enterprise uses HTTPS (HyperText Transfer Protocol, Secure), then Oracle Scripting must be configured for HTTPS also.
If the enterprise uses proxy servers, then Oracle Scripting must be configured for the proxy servers also.
The Network access setting in the Basic tab of the JInitiator Control Panel should be set to Applet Host.
Note: If using the Caching Architecture of Oracle Scripting only (supported only for pre-11.5.6 implementations), and if the database and applications servers are on two different physical hosts, the Network access setting in the Basic tab of the JInitiator Control Panel should be set to Unrestricted.
Appropriately configured security settings are the responsibility of Web server administrators at the enterprise.
Hardware required to create and deploy a survey questionnaire script (using Script Author) follows the Oracle CRM hardware requirement standards. Any workstation in your enterprise that meets the requirements for running Forms-based applications is suitable.
It is from this workstation that the script will be deployed to the applications database. The script can be created on this workstation or created on another workstation with Script Author, and copied to the workstation within the enterprise firewall to deploy.
Operating system: Any operating system supporting Oracle Applications.
Script Author Java applet, accessible from Oracle Applications for a user with the Scripting Administrator responsibility.
Oracle Applications certified Web browser (see My Oracle Support for a description of the latest current certifications).
Additional software required for Java development:
Java IDE such as Oracle JDeveloper
Java Development Kit (JDK)
Additional software required for database and PL/SQL development:
Appropriately configured TNSNAMES.ORA and SQLNET.ORA files
SQL tools such as SQL Plus or SQL Worksheet
Oracle Client (recommended)
Since survey questionnaires are often a series of simple questions and answers, the questionnaire script can be created by relatively non-technical users trained in the use of Script Author. This is particularly true with survey questionnaires employing primarily sequential logic, or building scripts using the Script Wizard.
However, because the survey functionality is based on Oracle Scripting, it also provides the ability to include very sophisticated functions in the script, if required. Therefore, in order to create adequate survey scripts, script developers must have received training in using Script Author.
Based on the complexity of the script in question, script developers must also be knowledgeable in the various supporting technologies, or have access to resources with such knowledge. The selection of supporting technologies required depends on specific requirements for each survey campaign, as well as the degree to which Scripting-supported technologies will be utilized. These technologies can include custom Java and application of APIs, PL/SQL, Oracle Forms, or Scripting-specific commands such as Constant and Blackboard commands. For more information, see Trained Java, PL/SQL, Oracle Forms, and API Programmers below.
Enterprises that intend to leverage the full capabilities of Oracle Scripting in survey campaigns may require the services of highly trained Java developers with experience customizing application program interfaces (APIs), PL/SQL programmers, developers experienced in accessing and working with Oracle Forms, logic and flow experts, business process engineers, and so forth.
Use of custom Java will also require deployment of custom code to the enterprise server, which requires an understanding of packaging of JAR files.
Any custom PL/SQL packages for use with the survey campaign must be appropriately built, deployed to the enterprise database, and tested. Deploying PL/SQL packages to the enterprise's applications database may require database administrator (DBA) privileges.
To develop a script that meets the survey campaign requirements, individuals creating scripts or supporting code will need access to existing flow charts or other documented script-specific requirements. Script developers must also be apprised of any dependencies, business rules, and predefined integration requirements. Upon completing development, script developers will need access to any existing test plans ensuring survey questionnaire requirements have been met.
From an AIM perspective, in order to achieve acceptance of the script it must meet the requirements of the system design (as represented by MD.070 or MD.080) and any and all test documents (as represented typically by the TE.040).
Scripts must be deployed to the applications database. Using the Script Author Java applet, this can now be performed through a firewall. Scripts are deployed to the specified database instance from the Script Author applet without need to define connection information; previously, one needed to define the database host name, TNS port and SID.
The Script Author Java applet is launched from the Home tab of the Scripting Administration console. Upon clicking Launch Script Author, Oracle JInitiator opens in a new browser window, and the Script Author applet connects to an Apache mid-tier servlet via HTTP. This Script Author servlet makes a JDBC connection to the database, and all database-based operations in Script Author are executed by this servlet. The servlet uses values identified in the Apps Servlet Agent system profile.
To deploy a script to a different environment, you must begin a new Oracle Applications session in the appropriate instance, open the Scripting Administration console, and launch Script Author using the servlet for that instance, and deploy the script. Thus, environment-specific information is now determined entirely by the current Oracle Applications session.
Trained individuals use the Script Author tool to visually lay out the flow of a script based on the script requirements. All of the requirements must be made known to the developer of the script to create an effective survey questionnaire. The information in the table below includes the type of information required to successfully create a script that meets the survey campaign requirements. For any script, other information may be required that is not listed below.
| Requirement Type | Description |
|---|---|
| Panel content | Text (and, for graphical script users, graphics) that appear in any HTML page. This includes any information assigned to the "Label for Reporting" field when defining a panel answer. |
| Lookup values | Predefined answer choices. |
| Constant commands (graphical script) or Default Answers (wizard scripts) | Used to provide or change an answer default. When executing scripts in a Web browser (using the Scripting Engine Web interface), the first selection in the range of answer choices becomes the default choice. This is different in the Java client, or the Scripting Engine agent interface. In a graphical script, if you wish to provide a different answer choice as the default, use a constant command to provide a different default value for a dropdown, radio button, text field or text area. If using the Script Wizard, you can provide a default value in the Define Question Detail window, when defining a question control of a text, text area, or password type. When defining answer choices in a wizard script for a radio button or dropdown list using the Define Answer Choice for (Panel Name) window, you can specify whether any given answer choice is the default using the Should this be the default answer for this question option. When defining answer choices in a wizard script for a multi-select control type (such as the multi-select list or checkbox group) using the Define Answer Choice for (Panel Name) window, you can specify whether any given answer choice is the default using the Default answer option. In a wizard script, there is no equivalent to the single checkbox control type. You can use the checkbox group control, in which you have the option of setting the default answer at runtime. There is no method for establishing no answer choice as the default. |
| Validation ranges or requirements | Validation can be enforced in a question UI control. For graphical scripts, this requires associating a Java method with a question in the data dictionary and must be explicitly programmed. The requirement for validation on a particular answer (and the range of valid answers, if part of the validation routine) must be provided to the developer of the script in advance. For wizard scripts, validation that a response is provided or validation of a date in a certain range is established by selecting options in the UI. |
| Branching logic | If a survey questionnaire is appropriately planned, branching logic can be clearly indicated in a flowchart. |
| PL/SQL packages | PL/SQL commands that are loaded in the applications database can be referenced from a graphical script. All such commands must be identified prior to development of the script. If using the Script Wizard, you must graph a script to provide custom commands. |
| Database table or view field names and locations | If tables are referenced from a script, the precise table names and locations must be made available to the individual building that portion of the script. If using the Script Wizard, you must graph a script to provide data dictionary details such as tables or views. |
The third step in the Survey business process flow is a decision block, indicating the requirement to determine if the survey campaign contains requirements for targeted (list-based) deployments. This determination affects the remaining process flow in terms of order of steps and complexity of survey campaign setup and administration.
A survey campaign may have an existing list comprised of members of a targeted population. For a list-based survey campaign, this list is created using Oracle Marketing.
Targeted survey campaigns obtain survey feedback by inviting list members to participate in the survey. This invitation is an Oracle One-to-One Fulfillment document that is sent to list members by electronic mail using Oracle One-to-One Fulfillment capabilities. The same list may be used to send reminders, an e-mail message typically reinforcing the deadline for list member participation. List members that respond by taking a survey are the survey respondents.
This section includes the following topics:
If the ability to execute targeted deployments within a survey campaigns is not required, step 4 of the process flow (generate lists) is skipped and step 6 (define deployments) is substantially simplified. Prerequisites such as implementation of Oracle One-to-One Fulfillment and Oracle Marketing are also precluded. The abilities you sacrifice by choosing a standard (non-list-based) survey campaign include the ability to invite members of a list to participate in a survey, the ability to track survey respondents by name or ID number, the ability to send reminders, or the ability to execute subsequent deployments that reaches the same precise audience.
When planning to implement or use the survey functionality of Oracle Scripting with targeted survey campaign deployments, the business process flow requires list generation as the next step. Some information is included in Oracle Scripting Implementation Guide. For more information, refer to Oracle Marketing product documentation.
Step 4 of the survey process flow is the generation of lists using Oracle Marketing. These lists are used to send invitations and reminders via e-mail to list members, encouraging them to click the included URL and participate in a survey.
Additional implementation requirements for enterprises using targeted (list-based) survey campaign deployments. These require administration of Oracle Marketing and Oracle One-to-One Fulfillment for list management and fulfillment template management, respectively.
Implementation of list management aspects of Oracle Marketing are required. Once these prerequisites are met:
Oracle Marketing can be used to create and administer lists for use with surveys.
Lists can be generated (Oracle Marketing functionality) from within the Survey Administration console.
See Oracle Marketing Implementation Guide for more information on implementing Oracle Marketing. See Oracle Marketing User Guide for more information on working with and generating Oracle Marketing lists.
Additional Oracle One-to-One Fulfillment implementation and configuration requirements are prerequisite for executing list-based survey campaigns. This includes:
Implementation and configuration of the Oracle One-to-One Fulfillment server, including:
An identified outgoing e-mail server
An associated survey group
Survey administrator users added to fulfillment server group
A functioning fulfillment engine
Once these prerequisites are met, Oracle One-to-One Fulfillment can take Oracle Marketing lists and merge data from those lists into survey campaign-specific invitations and reminders and send these out through the identified e-mail server. These steps must be accomplished by a fulfillment administrator (an Oracle Applications user with the One-to-One Fulfillment Administrator responsibility).
After obtaining requirements (step 1), creating and deploying a script (step 2), determining whether lists are required (step 3) and generating lists if appropriate (step 4), you are ready to administer survey resources and administer survey campaign information. Survey resources are files that can display when a respondent takes a survey or a user executes a Web script. There are two types of resources: section resources and page resources.
Section resources include the header section and the footer section.
For scripts executed in the OAF technology stack, these resources are comprised of HTML and are optional. If not designated, no section resource displays.
For scripts executed in the JTT technology stack, header resources are required, and the footer section is optional. Both must be JSP files.
Page resources include the error page, and the final page.
For scripts executed in the OAF technology stack, page resources are comprised of HTML. Defining these and specifying a predefined error or final page resource is optional, but the component is not. If not designated, a default error or final page displays at runtime.
For scripts executed in the OAF technology stack, you can also specify a URL redirect for a final page. This routes the user to the URL you specify upon completion of the script.
For scripts executed in the JTT technology stack, error and final pages are mandatory. There is no system-generated default. Both must be JSP files.
This information is entered by a Survey administrator in the Survey Administration console, accessed from the Oracle Applications HTML login.
This step in the flow also includes the creation of a survey campaign and its child object, the cycle. Both can be created from the Survey Campaigns tab. A survey campaign may contain more than one cycle. Cycles can also be created from the Survey Campaigns tab.
Note: The order of steps described here is not arbitrary. Survey resources must be defined before they are specified.
For planning purposes, the following types of information are required:
Survey Campaign-Level Information
Script name
Survey campaign name
Survey resources:
Names for header section, footer section, error page, or final page resources. To use specific resources, they must first be defined.
Cycle names
Number of cycles required
Minimum response percentage
Deployments are associated with a specific cycle, which in turn is associated with a single survey campaign. On the same HTML page, information specific to list-based survey campaigns is also required.
Note: If a survey campaign is standard, no list information will appear on the page.
The information you will need in order to define a deployment includes:
Survey under which this deployment is associated.
Cycle under which this deployment is associated.
Deployment name for each deployment.
Deployment start date and time.
Response end date and time.
Deployment type (standard or targeted).
Enterprise Web server URL and port
The hosting option
Enterprise Web server and port, if different than default
Marketing list name
Maximum number of responses
Target response percentage
Invitation template name
E-mail subject name for invitation
Reminder template name
E-mail subject name for reminders
Reminder interval, in days
Once one or more deployments have been defined under a cycle for a survey campaign, each can be activated immediately.
For standard deployments, the act of setting a deployment to Active status (formerly known as deploying a deployment) enables respondents to take surveys as soon as you press the Deploy button.
For targeted deployments, setting a deployment to Active status allows e-mail invitations to be sent out based on the date and time parameters established for each specific deployment. This requires:
An invitation Master Document, with an appropriate query matching all merge fields and associated with the Master Document.
An Oracle One-to-One Fulfillment template, associating a specific Master Document and its components.
Another template is required if reminders are used.
Fully configured lists, typically generated in Oracle Marketing.
Appropriately configured concurrent processes.
When a deployment is set to Active, a concurrent job request is posted to the Concurrent Manager. The Concurrent Manager is functionality built on Oracle Application Object Library (AOL) classes, which are included in Oracle Applications 12 with an appropriate Rapid Install.
The Deploy Date and Deploy Time are passed to the Concurrent Manager as the appropriate execution time to run the process. If the date and time specified are past the SYSDATE, the job executes immediately. Otherwise, the request remains on the concurrent request queue until the execution time arrives, and a fulfillment request ID. Upon execution time, the fulfillment server is notified to follow the instructions provided to it by the Oracle One-to-One Fulfillment template. The template is associated with a particular Master Document (invitation or reminder) and query. The query pulls the contact information of the list member from Oracle Marketing and unique id from IES_SVY_LIST_ENTRIES to merge them in the Master Document, personalizing the email invitation and providing the appropriate list-based unique URL.
This personalized message, containing the data from all merge fields (at minimum, typically, the customer name and survey URL), is then sent to the outgoing e-mail server identified by the fulfillment group and its member users (Survey administrators), and delivered through the fulfillment server.
If reminders are associated with a deployment, then upon setting the deployment to active, concurrent jobs are submitted for reminders with calculated reminder dates and times, and instructions regarding the date to execute the job. These are also processed by the specified template, merging information as necessary and sending out the e-mail messages to the e-mail server identified with the fulfillment group and its member users.
There are no hard and fast requirements for monitoring survey results. As soon as respondents complete a survey over the Web, the information is passed to the Scripting schema in the Oracle applications database. From the Survey Administration console, each individual response can be reviewed on an ongoing basis by accessing the Response View option from the update deployment page of any specific deployment in the Survey Administration console.
When scripts are executed, information is automatically collected into the Scripting schema in the Oracle applications database. When surveys are taken over the Web, additional information is made available in survey transaction tables. No action or planning is required for this collection to take place.
If you want to view reports generated by survey operations, you can implement an end user layer (EUL) for the Oracle Discoverer tool.
For more information, refer to Appendix C of Oracle Scripting Implementation Guide.
If no surveys in a deployment have received responses, no information will be available to display in these reports.
To generate meaningful data, the Summarize Survey Data concurrent program should be executed to ensure all data in the summary tables have been compiled and are available to view as reports. For information on concurrent programs, see Administering Concurrent Programs for Survey Execution in Oracle Scripting Implementation Guide.
When a script is executed as a survey through the Web, the Summarize Survey Data concurrent program moves survey transaction information from the Scripting schema into survey transaction summary tables from which Survey campaign reports are generated. Summary tables can also be updated at scheduled times, as described in Administering Concurrent Programs for Survey Execution in Oracle Scripting Implementation Guide.
For more information, see Reporting and Analyzing Survey Respondent Data in Oracle Scripting Implementation Guide.
Web scripts are scripts executed by users of Oracle self-service Web applications such as Oracle iSupport or Oracle iStore.
In terms of planning, essentially the same level of thought is required for a Web script as is required of a script to be executed as a survey. Since this scenario involves an existing user executing a script from within the application UI, list management and fulfillment template management are not required.
Setup for the purposes of user authentication are also not required, as this scenario uses the Oracle Applications authentication information from the current applications session.
One unique concern is the customization of the Web application user interface to include a valid survey URL, allowing application users to launch a Web script from the application.