This chapter covers the following topics:
Script Author is the component of Oracle Scripting used to create, modify, and deploy scripts. These scripts can be executed using the Scripting Engine component of Oracle Scripting. Script Author is a Java applet intended for use by trained functional users.
You can create both graphical scripts and wizard scripts using the Script Author. Wizard scripts do not contain all the features available for graphical scripts, but provide a useful startup function for novice users.
You can also start a script application by creating a wizard script, and create a graphical script from the wizard script. You can then add in the extra features and custom code that you require into the graphical script.
To access the Script Author Java applet, you must log into Oracle Applications with a user account that is assigned the Scripting Administrator responsibility. This results in the appearance of the Scripting Administration console. From the Home tab, click Launch Script Author. A separate Oracle JInitiator window appears. Subsequently, Script Author executes as a Java applet from the Oracle JInitiator session, using the current logged-in user's database authentication information.
Following are definitions of some terms helpful in understanding Script Author. For more terminology, refer to the glossary.
A script is a miniature program built using Script Author to facilitate the flow of information between an enterprise and other parties. Each script enforces business rules programmed into it by script developers. Script Author provides the ability to create two kinds of scripts: wizard scripts and graphical scripts. Scripts can be executed in any Scripting Engine runtime interface.
A graphical script is any script created or modified using the graphical tools of Script Author. Graphical scripts are created, edited and deployed using the Script Author Java applet.
A wizard script is a script created using the Script Wizard feature of Script Author. Like graphical scripts, wizard scripts are executed in any Scripting Engine interface. By answering questions in a sequence of wizard windows using the Script Wizard, a script developer identifies requirements for the script, and specific panels, questions, and answer choices within the script.
Wizard scripts result in scripts identical in composition to graphical scripts, with two exceptions: you cannot open a graphical script using the Script Wizard, and wizard scripts do not contain all the objects accessible to the graphical script user interface.
Runtime is the execution of any script created using Script Author. Scripts are executed using the Scripting Engine component, which has two interfaces: the agent interface and the Web interface.
The agent interface executes as a Java window launched from an Oracle business application form. The agent interface displays the panel presentation area, a script information area, a shortcut button area, and a progress area, wrapped in a frame with a Disconnect button and, optionally, a Suspend button.
The Web interface executes a script in a Web browser. The Web interface displays the panel presentation area, and the following buttons: Back, Next, Reset to Default, and optionally Save for Later.
Before any script can be executed in the Web interface, survey administration is required, which includes setting up survey resources, creating a hierarchical set of objects - a survey campaign, cycle, and deployment - and activating the deployment.
This section includes the following topics:
A script is a miniature program built using Script Author by a trained functional user (a script developer).
The purpose of a script is to facilitate the flow of information at runtime between an enterprise and other parties. Each script enforces business rules programmed into it by script developers.
Scripts consist primarily of panels, which display at runtime. The composition of each panel is determined by script developers using Script Author, but must contain at minimum a single question. Panels may include any number of questions (there are no limits other than practicality).
Depending on the user interface at run time, users progress through the script, typically by clicking a Next or Continue button.
Although a rigid flow can be enforced, effective scripts typically include carefully constructed logic that branches the end user through different potential paths to appropriate panels, based on responses to earlier script questions. Answers provided at runtime can be changed by the end user before the script is completed. If an answer is changed by the script end user, and the logic for progressing through the script is programmed to change accordingly, the new path will automatically result. If an end user backs up in a script (for example, from panel 10 to panel 5), and changes an answer, and if the answer does not affect branching, then after registering the changed answer (by clicking Continue in panel 5), the script flow resumes at the last unanswered panel (panel 10). In this way, unnecessary duplication of responses is programmatically avoided. This is the intentional behavior of the application, which cannot be changed.
Script Author provides the ability to create two kinds of scripts:
Regardless of creation method, a script can be executed in any interface of the Scripting Engine.
A graphical script is any script created or modified using the graphical tools of Script Author. Graphical scripts employ a visual paradigm similar to a flowchart. Using drag and drop techniques, script developers place graphical objects in a work area (the canvas), and associate properties to those objects. This provides an intuitive method to build, modify, examine, and extend the functionality of a script.
Graphical scripts can contain configurable objects (panels, groups, and blocks) and nonconfigurable objects (start and termination nodes). The main features of each these script objects are the following:
Panels are the only script objects to display at runtime. Each contains at least one question , and (in a graphical script) may contain text, graphics, hyperlinks, and embedded values.
Groups are subgraphs which can logically organize related functions.
Blocks are subgraphs which provide a hook for APIs or SQL functions.
Start and termination nodes are nonconfigurable because the only function they serve is to signal the beginning or end of processing for a graph in a script. A termination node on the root graph (the first graph that appears when a script is opened) represents the end of script processing for the entire script.
Objects in a graphical script are connected with various branch types to control flow at runtime: default branches, distinct branches, conditional branches and indeterminate branches.
Scripts consist of the following:
Objects are processing units that tell the script what to do.
Objects are connected by branches. Branches are processing units that tell the script where to go.
A graphical script contains, at minimum, one graph. This is called the root graph - the graph which is visible when you open any graphical script.
Two objects of a script, groups and blocks, serve specific functions, but do not display at runtime. Groups and blocks serve as containers for other graphs, which are referred to as subgraphs.
When the script is executed, it displays panel content (which may include text, prompts, hypertext links, embedded values, and images) to its end users. Each window is the graphic display of a panel object. In each panel, the end user must provide a response - a mouse click or keyboard command - before progressing in the flow to the next object in the script.
There are three configurable objects in Script Author. A configurable object is an object which has properties that you can modify.
The three configurable objects in a graphical script are:
Scripts consist primarily of panels, the only script objects to display at runtime. The composition of each panel is determined by script developers using Script Author, but must contain at minimum a single question. Panels may include any number of questions (there are no limits other than practicality). Panels in graphical scripts may include text, graphics, hyperlinks, and embedded values. Panels in wizard scripts may contain text in addition to any number of questions.
At runtime, each panel displayed in the agent interface includes a Continue button. In the Web interface, the frame surrounding the panel includes a Next button. Runtime script end users must click the Continue or Next button to progress through the script.
In a graphical script, panel layout can be customized on a panel-by-panel basis. Panels containing graphics must be customized to refer to the graphic on a Web server accessible to the Scripting Engine at runtime.
A group is a container for other objects and branches. It may contain any type of object, including other groups. Groups can be nested as many levels as desired (the only limit is practicality). A group represents a child graph (a subgraph); as such, the graph represented by the group object must meet certain branching and termination requirements (see Minimum Requirements For Any Graph).
Groups are used to:
Logically group a section of the script flow (typically, to contain a single function or process)
Serve as a container for a Shortcut. In the Scripting Engine agent interface, shortcuts appear in the shortcut button area. When clicked at runtime, the agent user is "jumped" to the group in the script containing the referenced shortcut.
Represent an imported script in a graphical script .
Disconnect Group
Some enterprises require the collection of extra information for every script. In a graphical script, if you put the objects collecting this information in the Disconnect group, you can ensure this information is solicited for every interaction. If you add panels to the default Disconnect group, Oracle recommends that you change its name (for example, to WrapUpGroup), to provide a visual indicator to script developers that the group includes content for the wrap-up of each script transaction.
By default, wizard scripts contain a single group called Disconnect. The Disconnect group in the wizard script contains no panels, groups or blocks. It simply represents a graph with start and termination nodes connected with default branching, and serves to end the script immediately upon invocation.
This group contains the shortcut property WrapUpShortcut. When the Disconnect button is clicked at runtime from the Scripting Engine agent interface, the group in the script (if any) containing this shortcut is the resulting destination of the script.
Note: The Disconnect button always appears in the agent interface. If users click the Disconnect button, and WrapUpShortcut or its equivalent is not defined for the Disconnect group, they will get an error.
A block is used for one of two purposes:
When used to query, update, or insert information in a database, it is always associated with one or more database tables and contains database connection information.
When used as a container for an Application Program Interface (API), it contains a Script Author command that references the API.
A block represents a child graph, also known as a subgraph. The subgraph represented by the block object must meet the standard branching and termination requirements (see Minimum Requirements For Any Graph).
The block subgraph can contain panels. The question UI controls in the panel objects can be used in block processing. The subgraph panels are executed before the main query, insert, update, or API operations associated with the block.
There are two nonconfigurable objects in Script Author. A nonconfigurable object is an object which has a single function, and does not contain properties that you can modify. The two nonconfigurable objects in a graphical script are start and termination nodes.
Every time a graph is created in Script Author, it contains a start node. Start nodes cannot be explicitly created, nor deleted. They contain no viewable properties. Start nodes simply visually represent the starting point on any graph. They can be moved about the canvas as desired, and must be attached using a default branch to the first explicitly created object in the script. Any actions associated with a branch from a start node will be ignored.
Termination nodes are required on every graph (unless that graph contains an indeterminate branch). Termination nodes represent the end of the flow of that level of the script at runtime. They are nonconfigurable, containing no viewable properties. A graph may contain two or more termination nodes, each depicting the end of a flow of a particular path. The termination on the root graph signifies the end of script processing.
Objects in a graphical script are connected with various branch types to control flow at runtime. There are four branch types:
Default: The destination is the designated object.
If there is more than one branch from an object, this type of branch must be defined as the last-case default if no other branch is valid. Requires no properties to be associated with it in Script Author. There is no label associated with this branch type, and its name is not required to be unique within a script or even on one graph of a script.
Distinct: The destination is based on the answer provided to a question at runtime in a panel. One or more distinct branches are designed to start from the panel.
The Name property of the distinct branch appears as a branch label on the canvas. This value is not required to be unique.
The Value property of the distinct branch determines the path the script will take if the specified value is selected as the answer choice to a panel question by the script end user at runtime.
You must define one or more answer choices (or lookup values) for a single question - designated as the default for distinct branching - in the panel. For each distinct branch drawn on the canvas from that panel, you must associate one of the answer choices, to specify the correct flow at runtime when the script end user answers the designated question.
Conditional: The destination is based on the evaluation of a Boolean expression.
For this branch type, you must provide and associate Java code to the conditional branch that evaluates a condition to be true or false. The branch is taken at runtime if the Boolean expression is determined to be true.
Note: When you define one or more conditional branches for an object, you must also provide a default branch, to allow for the case that all the conditions are false. Because branches are evaluated in the order specified for the object, ensure that all conditional branches for an object appear before the default branch - see Branches and Branch Order.
Indeterminate: The destination is based on the evaluation of an expression, the result of which is not known until runtime.
This branch type requires the definition of a Script Author Java command to be associated with the branch in the script, referencing corresponding Java code (to provide the expression and destination objects) to be evaluated at runtime. The expression must return a string that is either the name of a sibling object (panel, block or group on the same canvas), or the shortcut name of a destination group (using the Shortcut property), which can be in any graph at any level of the script from the root graph to the deepest nested level.
Note: The terms indeterminate and indeterminant are used interchangeably in Oracle Scripting.
Below the start node, each object placed on the Script Author canvas in a graphical script is typically connected above and below by appropriate branches, ending with the termination node. Outgoing branches (branches drawn from any object) are displayed in the Branch pane that results by clicking the Branch attribute under any object's Property window.
The branches are displayed in the order in which they are created. By default, this determines the order in which the branches are evaluated at runtime. You can change this order after branches are created. Thus, for a panel with multiple branch types, it is crucial to ensure the Default branch is listed last so that other branch types will be evaluated first.
The panel layout editor feature of the Script Author allows script developers to quickly define simple HTML layouts for a panel within a graphical script without writing HTML code. This simple graphic interface provides users with the ability to:
Enter and format simple panel content
Manipulate typeface, font size and color
Create bulleted and ordered lists
Import existing HTML or export panel content as HTML
Create hypertext links
Insert embedded values
Import GIF or JPG images
Note: When an image is imported using the panel layout editor, the HTML for the panel must be exported from the panel in a graphical script, and modified to reference the image in a path accessible to the Oracle Applications Web server at runtime. The modified code is then reimported into the panel, so the image is available to all script end users at runtime.
In addition, the panel layout editor produces syntactically correct HTML content for Scripting-specific features such as embedded values without script designers having to learn custom Oracle Scripting HTML tags and syntax.
Questions (or question UI controls), images, and text can be interspersed and formatted as desired.
The panel layout editor includes one-click formatting of text into two distinct styles:
Instructional text indicates specific instructions to the script end user.
Spoken text indicates text that an agent would speak (using the agent interface) or that a customer or survey respondent would read for communication of primary information for that panel.
The panel layout editor is not intended to be used for complex layout, creation of use of HTML tables, or the use of cascading style sheets, which are not supported with Oracle Scripting. To create complex layout, or to use features of HTML such as tables, it is expected that script developers will use full-function third-party HTML editors (or code HTML by hand) and simply import the HTML content into Script Author using the panel layout editor.
Important: In Oracle Scripting, there is a one-to-one relationship between questions and answers.
When describing Oracle Scripting questions and answers, the terms "question" and "answer" are used interchangeably, with the more appropriate term selected in context.
Every panel requires at least one question user interface (UI) control, because at runtime, every panel requires end user interaction (a mouse click or keyboard action) in order to progress to the next object in a script
Note: When defining a question UI control, you must select Answers from the panel properties tree. The window in which question UI controls are defined is referred to as the Answer Entry Dialog window.
The terms "Question UI Control" and "Answer" are used interchangeably in this section.
For each question UI control you specify, the panel will include one question at runtime.
The question UI control types and their general usage are as follows:
| Question UI Control Type | Description |
|---|---|
| Button | Use to progress the script to a panel. Cannot be defined in Script Wizard.. |
| Check Box | Use to evaluate a simple "true/false" condition. Cannot be defined in Script Wizard. |
| Checkbox Group | Use for a series of conditions for which you can select zero, one, or many values at runtime. |
| Drop Down | Use for a series of conditions for which you must select one value at runtime. |
| Multi-Select List Box | Use for a series of conditions for which you can select zero, one, or many values at runtime. |
| Password | Use for short amounts of text to be entered, with entered data appearing as asterisks. |
| Radio Button | Use for a series of conditions for which you must select one value at runtime. |
| Text Area | Use when soliciting large amounts of text at runtime, with space for inputting several lines. |
| Text Field | Use when soliciting a short text response at runtime. |
The following question UI controls require users to enter data at runtime: Text Field, Text Area, and Password. All the other questions require users to select one or more values at runtime.
Radio Button, Check Box, Button, and Drop Down questions require a single value to be selected.
Checkbox Group and Multi-Select List questions allow for zero, one or many values to be selected.
Each question, whether defined in a graphical or wizard script, has a number of question properties, such as whether it requires a label or a lookup values.
Each question in a panel has a data dictionary associated with it, which stores the main question properties. For example, for questions that support multiple answer choices (radio buttons, drop-down lists, checkbox groups, and multi-select list boxes), these answer choices are determined by the contents of the question's data dictionary.
In wizard scripts, the question properties are visible in the standard question and answer choice windows. In graphical scripts, you can view and edit question properties explicitly in a data dictionary window.
A panel must contain at least one question, and may include any number of questions. There are only two limits: practicality and distinct branching. From a practical standpoint, at runtime, the user should be able to easily navigate each panel. The more questions defined in a panel, then the more extensive the panel layout. Users generally prefer to view the contents of a panel in a single screen, when possible.
On this point, scripts differ in philosophy based on their intended use. When a script is created to collect survey data (whether executed in the agent interface, or more commonly, when executed in a Web browser), it is generally considered acceptable or commonplace to include a large number of related questions on a single page. Often, these are questions of the same type and share the same attributes. For example, you may include a dozen questions asking about satisfaction of a certain aspect of a product or service, each using radio buttons and requiring the end user to provide a rating from one to five.
Regarding distinct branching, only one question per panel can directly affect distinct branching. If a panel uses distinct branching for an outgoing branch type, the question that uses distinct branching must have the "Default for Distinct Branching" option selected.
A shortcut is a property of a group in Script Author. The shortcut exposes the functionality of the group and its contents to the Scripting Engine, enabling that group to be the target or destination of a "jump" from another location of the script.
This jump occurs when the shortcut is invoked using the Oracle Scripting jumpToShortcut API. This API is associated with the script using a Java command, which can be called as an action, pre-action or post-action anywhere in a script.
For more information about commands and actions, see Defining Commands and Defining Actions.
The shortcut property of a group is also used by the indeterminate branch. This branch type requires an expression to be defined. This expression is a Java method which, when evaluated, provides a shortcut name as its return value (based on the conditions tested in the method), invoking the shortcut.
Regardless of whether it is called from an action or an indeterminate branch, when the shortcut is invoked, the flow of the script at runtime jumps from the existing object being processed to the group containing the shortcut name that is returned by the command.
At that time, any pre-actions associated with the group are executed. The group represents a subgraph. Thus, processing then focuses on the objects within the group. When the termination node within that group is reached in the script flow, then any post-actions associated with the group are executed. Flow then returns to the graph on which the shortcut group resides, directed by the outgoing branch of the group containing the shortcut.
If the group containing the shortcut contains one or more panels, then the effect to the script end user after a shortcut is invoked is simply that the script progresses to the first panel within the target group. Processing of any commands, of course, is hidden from view, although data returned from such processing can be displayed at any point during that script session, and commands relying upon such data can be executed at any point during that script session.
Since only panels display at runtime, regardless of which Scripting Engine interface is used, then if the group containing the shortcut contains no panels, then the flow of the script is redirected to a new path. That path starts from the target group. Group or block objects within that group (if any) and any commands associated with them (if any) are processed. At minimum, the group containing the shortcut that was called contains a termination node. When that termination node is reached in the script flow, then processing and script flow returns to the graph on which the shortcut group resides. The script has effectively been redirected to whatever path follows from the shortcut group. In this case, the visual effect to the script end user after the shortcut is invoked is to see the first panel in the new flow of the script, starting with the target group. Again, all processing from other objects or command occurs behind the scenes.
Typical uses of a shortcut are as follows:
To associate a target for a shortcut button in the shortcut button area (displays for the agent interface only).
To associate a target for a group containing specific functionality which must be accessed after meeting a specified condition in a script (for either runtime interface).
To redirect the flow of a script to a new path (starting with the group that contains the shortcut).
Global script properties are those properties that apply to an entire script. This is in contrast to properties of a specific object in a graphical script such as a panel, group, block, or branch. Global script properties are assigned default values when a script is created, and exist for wizard scripts and graphical scripts alike.
Global script properties fall into four categories:
General global script properties
Actions
Static panel
ld
Details on each of these properties appears in the table below.
| Global Script Property | Graphical Script UI Type | Wizard Script UI Type | Graphical Script Default Value | Wizard Script Default Value |
|---|---|---|---|---|
| Script Type | N/A | N/A | Graphical script | Wizard script |
| Name | Text field | Text field | Untitled1 | Untitled |
| Comments | Text field | N/A | Null | N/A |
| Description | N/A | Text area | N/A | Null |
| Script Language | Drop-down list | Drop-down list | AMERICAN | AMERICAN |
| Footprinting | Boolean | N/A | TRUE | TRUE |
| Answer Collection | Boolean | N/A | TRUE | TRUE |
| Suspendable | Boolean | N/A | TRUE | TRUE |
| Override suppression of Continue button | Boolean | N/A | FALSE | FALSE |
| Pre-Actions | Null | N/A | Null | N/A |
| Post-Actions | Null | N/A | Null | N/A |
| Static Panel | Null | N/A | Null | N/A |
| Shortcut Panel | Null | N/A | Null | N/A |
The Static Panel and Shortcut Panel global script properties only affect the Scripting Engine agent interface. These properties, when appropriately configured by a script developer, cause additional objects to appear in the script frame. Like the progress area, the Static Panel and Shortcut Panel properties (if used) are rendered as Java beans that appear in the designated areas of the script frame of the agent interface only. Scripts executed in a Web browser do not display any objects in the script frame other than the panel display area.
Graphical script users can disable the Boolean general script properties for footprinting, answer collection, and script suspendability in the Properties pane of the global script properties window. Accessing global script properties from a graphical script is the only method to disable Boolean general script properties or to add actions, static panel or shortcut button area information.
The first property, Script Type, is determined when you select Graphical script or Wizard script in Script Author (File > New). The sole purpose for this property is to distinguish whether the script is a wizard script or graphical script. The Script Type property is not modifiable, nor is it visible from any Oracle Scripting user interface. Nevertheless, this property is determined by the method you use to create a script.
The script name is the name by which the script is identified in the database. This is distinguished from the file name of the script (which must contain a file extension of .SCR or .SCRIPT). Avoid using special characters such as slash or backslash, percent, asterisk, or other characters that have special meanings to a filing system.
The comments (graphical script) or description (wizard script) fields allow script developers to enter or view comments or descriptions regarding the particular script.
This property is a drop-down list which contains the value of the appropriate language for your environment from the Oracle RDBMS FND_LANGUAGES table. The default value is AMERICAN.
Footprinting records the sequence of panels enabled during a script runtime interaction (regardless of whether the script is viewed in the Scripting Engine or the Survey mode), as well as the start time and end time (in milliseconds) for each panel in an interaction.
Additionally, footprinting records deleted status (indicating that a panel was removed from the final flow based on a changed answer that takes the user down a different flow path).
Footprinting data provides interaction center managers the ability to review existing scripts to determine potential problems and to tune the script accordingly. For example, you can analyze footprinting data to identify areas in the script where substantial amount of time is spent or where a specific panel is often deleted during an interaction. These scripts can then be modified with the goal of decreasing average talk time (for an interaction center) or increasing valid response rate by improving the flow of a script.
The default for this property is true.
When enabled, this data is saved in tables IES_PANEL_DATA and IES_FOOTPRINTING_DATA in the Oracle Applications schema.
Answer collection is the recording of end user responses ("answers") to all question user interface (UI) controls or "questions" during a script transaction.
The default for this property is true.
When answer collection is enabled, script end user responses are collected for each question designated as collectable, and saved in the IES_QUESTION_DATA table in the Oracle Applications schema.
For graphical scripts, individual questions can be designated as uncollectable.
The Suspendable check box option allows scripts to be suspended and resumed, in both of the Scripting Engine interfaces.
The default for this property is true, for both graphical and wizard scripts. The property is visible and editable only from a graphical script, in the script properties dialog (File > Script Properties). The only way to disable the Suspendable option for a wizard script is to graph the script and then edit the graphical script.
The effect of this option at runtime depends on the user interface:
For suspendable scripts running in the agent interface, if the profile option IES : Display Suspend Button on Script Frame is set to True, the agent interface displays a Suspend button on the script frame. This button is hidden if the profile is set to False (or remains null).
For deployments running in the Web interface, when the survey campaign associated with the questionnaire script is marked as Suspendable (either Always Suspend or Allow Suspend), a Save for Later button appears in the Web interface at runtime. The appearance of the button does not depend on any profile option value.
When you click either the Suspend or the Save for Later button at runtime, the current script interaction is suspended.
The way to resume a suspended script also depends on the user interface.
Scripts suspended in the agent interface can only be resumed through facilities built into the Oracle application that launched the script; currently only Oracle TeleSales provides this capability.
Note: For testing purposes only, you can resume a script suspended in the agent interface from the Navigator by an Oracle Applications user with an appropriate responsibility to access Oracle Scripting scripts.
The resumption of scripts suspended in the Web interface depends on whether the scripts executed from a standard or a targeted deployment.
A resumed transaction retains all information collected in a script up to the point at which it was suspended, including footprinting and answer collection information.
When a script is executed in the Scripting Engine Web interface, by default, any Continue buttons created in the script panels are suppressed. This feature is available because the Web interface includes Next and Back buttons to enable you to progress through the script.
If you wish, you can choose to override this suppression, and the Continue buttons will then be visible in the panels.
You cannot suppress the appearance of Continue buttons in scripts executed in the agent interface.
Global script actions (pre-actions and post-actions) are commands that execute prior to the display of the first panel in a script sequence or after the last panel is displayed in a script sequence, respectively. These global script properties can only be assigned from graphical scripts.
The Static Panel, also known as the script information area, is an area that displays, in the agent interface only, above each panel, as the script is executed.
The script information area can contain up to nine data elements. The elements can be of two types, text and timer.
Text elements are for static information, such as a campaign name or business purpose of the script. You provide the static information by associating a text element with a command that specifies either a constant value or a value retrieved from the Oracle Scripting blackboard.
Note: At the start of script execution in the agent interface, you can store blackboard values and parameters either from an Oracle application that calls the script or from a script pre-action.
Note: The static panel text elements are populated after any script pre-action, and cannot be subsequently changed.
Timer elements are typically used to display dynamic information, from dynamic timers. Using Scripting APIs, timers can be started, stopped, and resumed; and data in the script information area can be updated by explicit command.
You provide timer information through a Java method that invokes the Oracle Scripting API startTimer. You can do this in several ways:
Associate the Java command with a shortcut button, which when clicked at runtime, will start the timer.
Attach the Java command as a pre- or post-action command for a script or script object.
In the agent interface at runtime, below the script information area and immediately above the panel display area, the shortcut button area displays shortcut buttons, which may be associated with any Script Author command. You define the shortcut buttons in the Shortcut Panel.
Shortcut buttons contain a command that is executed when the button is clicked in the agent interface at runtime. Often, shortcut buttons contain a command referencing the Oracle Scripting jumpToShortcut API. In this case, the command returns a destination panel or group in the script. When clicked, the script flow at runtime "jumps" to the specified panel (or the first panel in the specified group).
If the button contains another command, the command is executed on the click action. Popular uses for these buttons are to open a browser window with a specified Web address, or to enable or disable an interaction timer in the script information area.
Shortcut buttons can be enabled or disabled at the start of a script. When a shortcut button is enabled, clicking on it at runtime will perform the function associated with the button. When disabled, clicking the button will have no effect. The state of the shortcut button is set when you define a shortcut button, and can also be controlled by invoking Oracle Scripting shortcut button APIs.
A script can contain any number of graphs. The graph shown when you first create or open a script is referred to as the root graph. Any new graph (subordinate in hierarchy to the root graph), created at any level of a script, is known as a child graph or subgraph. The graph from which a subgraph is created is known as the parent graph. The root graph has no parent.
New graphs are created using group or block objects. After creating a group or block object in a graphical script, you must explicitly select it and navigate down into it to view the child graph. Any graph can contain any number of other Script Author objects (including any number of additional child graphs, if required).
When an object in the flow of the script contains a child graph in the form of a group or block, any objects included in that child graph are evaluated before the flow on the root graph continues to be evaluated. A child graph at any level is exited at runtime when the termination node on that graph is reached in the flow of the script. Processing (flow of the script) then returns to the next object in the parent graph.
Certain syntactical rules apply to every graph. All objects in a script must be connected with branches. At minimum, each graph must contain a start node and a termination node, connected by a default branch. When you include a group or block in a script, its child graph must meet the same syntactical rules as the root graph.
Script Author includes a Script Wizard feature. Using this feature, script developers can quickly and easily create simple scripts or surveys by providing script information in a series of windows known as a wizard.
Scripts created with the Script Wizard are called wizard scripts. All features of wizard scripts are compatible with those of graphical scripts, and wizard scripts can be graphed or converted to a copy of a graphical script for viewing or modification using standard graphical tools. There is no backward compatibility, nor can graphical scripts be converted to wizard scripts.
The Script Wizard makes script development more accessible to non-technical users, although an understanding of business rules and business process flow is still absolutely essential to developing successful scripts using this feature. Since wizard scripts are created from Script Author, access to the Scripting Administrator responsibility is also required.
Wizard scripts can be created, edited, saved to the database without deployment, or deployed to the database. Unlike graphical scripts, wizard scripts cannot be saved locally in a computer's file system. Wizard scripts can only be listed in a user interface from within the Script Wizard.
Highlights of wizard scripts include the following:
A wizard script cannot be saved or deployed until it is syntactically correct. When you complete a wizard script, you can save it and continue working in the wizard, you can save and exit the script, or you can save, deploy, and exit. The product of progressing through the Script Wizard and saving your work is always a valid, deployable wizard script.
From the Script Wizard, existing wizard scripts can be edited, copied, deleted, graphed for use in the graphical Script Author tools, or deployed.
Each wizard script automatically contains a valid Disconnect button. This is only visible in the Scripting Engine agent interface.
Each wizard script automatically contains a valid Suspend button, unless the Suspend feature is disabled through other means. This is only visible in the Scripting Engine agent interface.
When defining question detail, wizard script developers can include default answers to questions by providing a value in the Default Value field. These can be accepted or changed at runtime.
When defining question detail, using a few clicks, wizard script developers can include answer validation for responses provided at runtime. You can check that the response provided is either (a) an integer, (b) an integer within a designated start and end range, (c) a valid date, or (d) a date that is not in the past (e.g, the date is equal to SYSDATE or is in the future).
Flow of a script can be controlled in part by providing an exit panel sequence. This method allows panels meant to contain information only (in contrast to panels designated to collect information) to automatically be provided with a Continue button without requiring the Script Wizard user to specify a panel answer.
Wizard scripts can contain panels, default branches, distinct branches, start and termination nodes, and a Disconnect group. Panels contain questions which may have predefined answer choices (lookup values).
For advanced wizard script features, any question may contain a default answer. Additionally, questions requiring text input may have the aforementioned answer validation. Corresponding features in graphical scripts are provided, respectively, by defining constant commands or Java commands referencing custom or best practice Java methods. These are defined for graphical scripts in the data dictionary for the particular question.
Decision-enabling data for branching graphical scripts includes previous end user responses for the current session, information received from external database tables or applications through forms commands, blackboard commands or PL/SQL commands, and events or conditions such as the time of day.
Substantial control of the appearance of a panel at runtime
Ability to add panels to the WrapUpShortcut Group
Ability to change the display value of a Continue button
Ability to associate commands with script objects
Ability to provide conditional and indeterminate branching
Ability to gather related functionalities into distinct groups
Ability to disable Boolean global script properties for footprinting, answer collection and script suspendability
Ability to include graphics in a panel
Graphical scripts intended for execution in the Scripting Engine agent interface may contain global script properties that enable you to define create shortcut buttons and a script information area, which display at runtime in the Scripting Engine agent interface.
In a graphical script you can specify an action as a Script Author command, and associate that action with any object in the script (including the global script object itself). Objects accept pre-actions and post-actions, which are executed either before or after that object is processed at runtime. Branches include actions, which occur as that branch is processed at runtime. By comparison, the only actions that can be associated with wizard scripts are seeded best practice Java methods to provide answer validation to defined questions, or constant commands to provide default answer choices.
Must manually create a WrapUpShortcut Group
Must reference Best Practice Java methods by specific class and method name, including for answer validation
Must define Continue button as panel question
Many steps required to accomplish simple tasks
Scripts can be saved in syntactically incorrect state
Any graphics in a panel require panel HTML customization to reference the graphic on a Web server so that other users can view the graphic at runtime
Decision-enabling data for branching wizard scripts is programmed into a wizard script at two junctures: when specifying a panel's exit panel sequence, and (for those question types that accept answer choices) when defining specific answer choices. Thus, at runtime, branching is controlled at the panel level generally. Wizard script panels with answer choices can define overriding branching instructions. For these panels, in the event that one specific answer choice for one specific question in the panel is selected, a new distinct path is taken for that session of the script.
Wizard scripts cannot be assigned commands other than for panel validation. Thus, wizard scripts do not branch based on the evaluation of commands, and are not routed based on information received from external database tables or applications through forms commands, blackboard commands or PL/SQL commands, or events or conditions such as the time of day.
Saved scripts are always syntactically correct by default.
Each script automatically includes a valid WrapUpShortcut group as the runtime destination of the Disconnect button.
Wizard script users can employ seeded Java methods to provide answer validation within a panel, without requiring a single line of code or without even the need to specify the specific Java class or method.
To do so, users of the wizard specify, in the Define Question Detail wizard window, whether a response is mandatory, if a default value for the question response should appear at runtime, or the type of validation.
Wizard script users also do not need to provide answer choices when the primary purpose for a panel is to provide an informational message and then continue to the next panel.
By specifying "Go to the next panel in sequence" as the exit panel sequence, a Continue button will automatically be generated by the Script Wizard. In contrast, graphical script users must access panel questions, define a question name and question UI type of Button, and access the data dictionary for the question to provide a display value and passed value of the word "Continue."
Wizard scripts can be saved in the database, or deployed to the database for execution, directly from wizard windows. This feature can help reduce the time it takes to train a non-technical Script Author user to create and modify simple scripts or surveys.
Wizard scripts can be graphed, a process in which a copy is converted to a graphical script. Since this process is not reversible, the original wizard script is retained in the database for future access using the wizard. The ability to graph a wizard script allows graphical script users the major benefits of the Script Wizard (rapid script creation, keystroke reduction, and elimination of repetitious processes) by allowing them to begin a script using the wizard, and to subsequently have access to the more complex functionality accessible only in a graphical script.
Once wizard scripts are graphed, this process is irreversible. Any enhancements or changes made to a graphed script must be accessed as a graphical script only.
You cannot associate any commands to scripts globally, or to specific objects in a script, using the wizard.
You cannot disable the Boolean global script properties (footprinting, answer collection, or script suspendability) from a wizard script. The script must be graphed so that these options can be disabled.
You cannot include pre-actions or post-actions to the global script.
You cannot include the script information area or shortcut button area in wizard scripts. These global script properties (which display at runtime only when the script is executed using the Scripting Engine agent interface) are only configurable in a graphical script.
You cannot create conditional or indeterminate branching using the Script Wizard.
You cannot automatically include panel layout text in more than one format (for example, spoken text and instructional text) using the wizard.
You cannot create embedded values in panel text using the Script Wizard.
You cannot create hyperlinks or add graphics to panel layouts using the Script Wizard.
Wizard scripts and graphical scripts are both created from Script Author, and both can be executed in any Scripting Engine interface. But there are many differences, some of which are identified here.
Using the Script Wizard results in scripts identical in composition to graphical scripts, but with separate file structures. These present some practical limitations.
You cannot open a graphical script using the Script Wizard.
From the Script Wizard, you can graph a wizard script, allowing you to see the resulting physical layout of a script you created using the wizard tool.
Any changes you make to the graphical copy cannot be viewed or edited from the Script Wizard.
Global Script Properties fall into four categories: General global script properties, Actions, Static panel, and Shortcut panel. Of these, only general global script properties can be configured for wizard scripts. Actions, Static panel properties (for the Scripting Information window in the agent interface), and Shortcut panel properties (for shortcut buttons in the agent interface) are only configurable in graphical scripts.
Boolean Property Limitations in Wizard Scripts - Wizard scripts limit access to some of the general global script properties. For example, there are three Boolean properties (Footprinting, Answer Collection, and Suspendable). These are automatically enabled for all wizard scripts.
Graphical script users can disable the Boolean general script properties for footprinting, answer collection, and script suspendability in the Properties pane of the global script properties window. Accessing global script properties from a graphical script is the only method to disable Boolean general script properties or to add actions, static panel or shortcut button area information. A wizard script must be graphed before any of these properties can be modified.
Comments or Descriptions - Graphical scripts include a Comments text field as a global script property. Wizard scripts include a Description text area as a global script property. Text entered in either of these fields are not saved to any columns in the database. They are stored in the .SCRIPT file and are not displayed anywhere at runtime, nor are they visible from the Scripting Administration console. The sole purpose for these fields is to allow script developers to enter or view comments or descriptions regarding the particular script, and to allow those comments to be viewed by other script developers.
The Script Type is a global script property. This property is not viewable or modifiable from any Oracle Scripting user interface. However, this property (the value for which is either wizard script or graphical script) identifies the script creation method and thereby, the type of script. When you graph a wizard script, you create a graphical copy (with a graphical script type); the original wizard script is retained.
Panels created with the Script Wizard do not include the single checkbox or the button (submit button or push button) question user interface controls.
Script wizard panels also cannot contain graphic images, hyperlinks, or embedded values.
To add any of the preceding to a wizard script, or to add groups (other than Disconnect) or blocks, you can convert a wizard script to a graphical script. Any modifications you make to the graphed script cannot subsequently be viewed using the Script Wizard tool.
The most obvious difference between panels created with the Script Wizard and in a graphical script is the limitation of question user interface types. The table below compares the question UI types available to graphical scripts versus those accessible in the Script Wizard. Minor differences in control names are indicated based on the labels provided by the user interface for each script creation method.
| Graphical Script | Wizard Script | End User Action Required |
|---|---|---|
| Text Field | Text | Text entry |
| Text Area | Text Area | Text entry |
| Radio Button | Radio Button | Select only one (required) |
| Check Box | [None] | Boolean (null or selected) |
| Button | [None] | Click (required) |
| Drop Down | Dropdown | Select only one (required) |
| Password | Password | Text entry |
| Checkbox Group | Checkbox Group | Select zero, one, or many |
| Multi-Select List Box | Multiselect List | Select zero, one, or many |
Panels in wizard or graphical scripts may contain static panel text, and one or more questions. Questions of the appropriate type that are explicitly defined in a wizard script may include question-level validation commands. In addition, panels in graphical scripts may contain graphic images, dynamic text using embedded values, and validation, database or cursor lookup, or other commands (at the panel level or the question level).
If the purpose of a wizard script panel is simply to provide information to the script end user, then Script Wizard users are not required to define any questions for the panel. The Script Wizard will automatically generate a question called Continue, which displays a Continue button at runtime.
In contrast, panels created with graphical tools must contain one or more explicitly defined questions. If the question UI control selected for a panel is Button, the panel may not contain any other questions. A display value (the contents of the button) and a value must be provided for each button question type created, in the Lookup entry window of the question data dictionary.
Although identical in appearance to the Button question UI type, panels in graphical scripts containing one or more question UI types other than Button will automatically display a Continue button at script runtime. This button is not required to be defined.
Wizard scripts contain panels, branches, start and termination nodes, and a single group (Disconnect) to enable the Scripting Engine agent interface Disconnect button. Wizard scripts do not include any other groups or any blocks.
Wizard scripts do not include conditional or indeterminate branching.
To add groups or blocks, conditional or indeterminate branching, or to modify the Disconnect group, you can convert a wizard script to a graphical script. Any modifications you make to the graphed script cannot subsequently be viewed using the Script Wizard tool.
Each graphical script contains at least one explicitly defined question, resulting in a user interface control displayed in the panel at runtime. If no other question user interface controls are required for the panel, developers of graphical scripts must explicitly define the Continue button, using the Button question UI control. Panels with other question types will include an automatically generated Continue button.
In contrast, each panel in a wizard script includes an automatically generated Continue button. If no other question user interface controls are required for the panel, then wizard scripts differ from graphical scripts by generating the button automatically. You cannot choose to create a Button question UI type, nor can you provide the default button with any value other than Continue from the Script Wizard.
A graphical script is represented as one or more graphs that use visual symbols to represent the three configurable object types (panels, groups, and blocks) connected with the appropriate branch type to control the flow of the script.
Each valid graph within a script will also contain a start node (created on each graph or subgraph automatically) and at least one termination node (inserted on the canvas by the script developer). These two nonconfigurable objects will also be connected with branching as appropriate.
While wizard scripts are constructed by responding to prompts in the Script Wizard, the script is technically constructed with a smaller subset of the objects available to a graphical script. The Script Wizard ensures that all scripts created and saved are syntactically correct.
The shortest syntactically correct wizard script will include:
One panel, on the root graph. This will contain an automatically generated Continue button and does not require any questions to be explicitly defined.
One group, Disconnect, with a shortcut property of WrapUpShortcut. This enables the agent interface Disconnect button. The group represents a subgraph with a start node and a termination node (no panels), connected with default branching.
Two start nodes (one on the root graph, and one in the Disconnect group).
Two termination nodes (one on the root graph, and one in the Disconnect group).
Default branching linking all objects.
To be syntactically correct, a graphical script (or any graph on any level of a graphical script) requires only a start node (created automatically), a termination node, and default branching between those objects. Of course, such a script does not contain any properties that would be processed or displayed at runtime. Only panel contents are displayed. Adding a panel, or any configurable object, includes additional requirements.
Every panel requires at least one "node" or question to be defined in order for the script to be syntactically correct. The reason for this requirement is that every panel displayed at runtime requires end user interaction to progress the flow of the script. This interaction comes in the form of the end user responding to question user interface controls in a script. At minimum, each panel has one question UI control (a button, often labeled "Continue"). If multiple nodes or questions are programmed into a panel, then there will be one question UI control per definition, in addition to a system-generated Continue button.
The panel is the only Script Author object that visible at runtime, displaying panel text, any questions (nodes) that have been defined for the panel, and associated labels for those questions.
When an object such as a group or block exists only as a container, it must still adhere to these rules. Thus, if the container object (whether a group or a block) requires no panels or other objects within it, it must still have a termination node, connected with a Default branch from the start node.
Furthermore, every object on a graph must contain branching, initiating from the start node, in order to be processed by the script and pass a syntax check.
Graphs that contain an Indeterminate branch introduce two exceptions:
An Indeterminate branch contains an action or expression that must be evaluated in order for the flow to be completed. A graph with an Indeterminate branch need not adhere to the requirement for a termination node in order to pass a syntax check. While a termination node is not required, it may be used without causing issues.
Indeterminate branches may contain Java code to "jump" the user to a particular panel (on the same graph) or group (anywhere in the script). Thus, when using Indeterminate branches you may use panels or groups that are not attached from above with branching. These must still be branched appropriately from that point onward on the graph.
This section includes the following topics:
The Script Author development environment is the component of Oracle Scripting which provides the sole means of creating scripts for execution in any Oracle Scripting runtime Scripting Engine interface.
As of Oracle Scripting release 11.5.9 or later (or Interaction Center Family Pack P or later), Script Author is a Java applet accessed through Oracle Applications by a user with the Script Administrator responsibility. In previous versions, Script Author was a standalone Windows Java application that required separate implementation, installation, and setup. Regardless, users that access Script Author are referred to as script developers.
The Script Author provides a graphical user interface intended for the functional user with some technical knowledge.
The graphical development environment provides for reuse of defined commands and existing Scripting components. The script developer will define these commands. Hooks in the Script Author UI reference technical components (for example, Oracle Forms, custom Java methods, and PL/SQL packages stored in the database) which are primarily developed externally. These components provide sophisticated functions to accomplish the functionality most enterprises want. They must be developed by individuals certified and knowledgeable in the relevant technologies. The script developer must work with these highly technical resources to ensure the custom components are appropriately integrated into the script. The script developer must also ensure the code is appropriately loaded in the database or applications server (based on approach) and properly referenced in the script. This will ensure the code is available to the base Java classes that provide Scripting runtime functionality for the Scripting Engine agent or Web interface at runtime.
As of Oracle Scripting release 11.5.9 or later (or Interaction Center Family Pack Q or later), Script Author includes a Script Wizard component accessed through the menu or Script Author toolbar from Script Author. With this new feature, less technical users can quickly and easily create simple scripts or surveys by providing script information in a series of windows known as a wizard.
Script Wizard users have limited access to the more technical features available in the graphical development environment. This provides the opportunity to divide script development amongst, for example, business process engineers with full knowledge of the business and flow requirements of a script, after which they can turn the script over to more experienced developers to add hooks, commands, reference Java or Forms, and so forth.
Users of Script Author include campaign administrators, Java developers or database programmers, business process engineers, and experienced interaction center agents with technical aptitude. The keys to successful script development are: (1) familiarity with how Oracle Scripting captures and processes data, (2) knowledge of associated technologies (including access to experts in these technologies), and (3) adequate training and familiarity with existing documentation.
Using the standalone Script Author Java application, no responsibility was required to launch Script Author on a Windows client. For current and future releases, only the Script Author Java applet, accessed through a validated Oracle Applications session, is supported.
Since script developers can deploy, delete, and otherwise affect scripts in production, and can manipulate information in the applications or other enterprise database, Oracle strongly recommends that only trusted users be provided with the Scripting Administrator responsibility.
Users of the HTML-based Scripting Administration console include script developers (see Script Author Users), who launch the Script Author applet from the Home tab, and administer deployed scripts and custom Java archive files from the Administration tab. Interaction center campaign administrators or system administrators (as well as script developers) will also typically access this console to run panel footprint reports to help tune a script's structure, increase agent performance and reduce average talk time. To access the Scripting Administration console user interface from the CRM Home Page login (or the Single Sign-On login, if implemented), these users must have the Scripting Administrator responsibility.
End users of the Scripting Engine agent interface are trained interaction center agents ("agents") or customer service representatives. These are non-technical users who have received simple but thorough training in the Java-based Scripting Engine interface. These individuals include call center agents taking or presenting information over the telephone, as well as interaction center agents taking advantage of other media such as intranets, enterprise portals over the World-Wide Web, and so forth.
Scripting Engine agent interface users typically launch scripts from a business application such as Oracle TeleSales or the Customer Support component of Oracle TeleService. For testing purposes, the agent interface can also be launched in "standalone" mode. Agent interface users must have access to the appropriate Oracle Applications responsibility to launch the integrated business application from which Oracle Scripting is integrated.
End users of the Scripting Engine Web interface include users of targeted (list-based) or standard (non-list-based) survey campaign deployments, or self-service Web application users. Survey respondents may have been invited to participate in a survey through an e-mail message or through navigation to a survey-enabled site. Self-service Web application users access a script or survey in a Web browser through a self-service Web application scenario such as Oracle iSupport.
To access a survey using a self-service application, the appropriate responsibility to access that application is required. No Oracle Applications responsibilities are required of the end user to execute a script as a standard or targeted survey deployment. The user simply accesses the given survey URL in any Oracle Applications 12 certified Web browser.
Users of the JSP/HTML-based survey campaign administrative console are non-technical users with access to detailed project requirements. These individuals are typically interaction center survey campaign administrators or system administrators.
To access the Survey Campaign administrative interface from Oracle Personal Homepage (PHP) login (or the Single Sign-On login, if implemented), these users must have the Survey Administrator responsibility.
There is no single correct manner in which to create scripts using Script Author. However, certain information is essential to create a successful script, and a recommended flow of events is described in this section to help you use Script Author effectively.
Other tasks are recommended to assist you in properly planning for a script development project.
This section includes the following topics:
The specific major tasks associated with creating and deploying a script are listed as follows.
Create a new script.
Define global script attribute, such as:
For wizard and for graphical scripts, define the standard script properties, such as Script Name and Script Language.
For graphical scripts only, also define additional script properties, such as Footprinting, Answer Collection, and Suspendable.
Global script pre- and post-actions (for graphical scripts)
Script information area (for graphical scripts)
Shortcut buttons (for graphical scripts)
Script Disconnect button (for graphical scripts)
Script Suspend button (for graphical scripts)
Define the scripting objects needed to implement your business rules. This includes:
For graphical scripts, inserting appropriate script objects.
For wizard scripts, adding panels.
Define properties for each configurable script object. This includes:
For graphical scripts, defining panels, groups, and blocks.
For wizard scripts, defining questions, answer choices, and any required validation.
Ensure script flow is defined appropriately. This includes:
For graphical scripts, insert appropriate branching to meet flow objectives.
For wizard scripts, defining the exit panel sequence for a panel, or defining the destination for specific answer choices.
Save the script to the filing system or database. This includes:
For graphical scripts, saving the script to the file system, or publishing a script to the applications database.
For wizard scripts, saving the script with a different name, if applicable.
Deploy the script to the Oracle Applications database:
For graphical scripts, this may include checking the syntax of the script.
For wizard scripts, saving the script and continuing to edit it using the wizard, saving the script and exiting the script wizard, saving the script and deploying it prior to exiting, and optionally creating a graphical copy of the wizard script.
The recommended script creation flow described in this section applies to Oracle Scripting scripts created using any method or combination of methods. Additionally, this recommended flow applies to scripts regardless of their intended Scripting Engine execution interface.
Every script is customized to meet the specific needs of an organization. Even if you are beginning your script development with a building block script or a best practice survey, it is likely that you will want to customize the script to use language, formatting, and flow appropriate to your organization's business objectives. One organization may require the use of several scripts, and it is likely that each of these may differ substantially, based on the intended purpose of the script.
For example, scripts expected to be used by agents in interaction centers often require more time and effort to integrate functions of the script with other business applications. In addition to serving the primary business purpose of a specific script, interaction center scripts may also be required to provide agents with methods to rebut customer concerns, cross-sell or up-sell products, or provide generic (or specific) customer service outside the scope of the intended narrow script objective.
Scripts intended for execution in a Web browser (as surveys or Web scripts) often require more time, effort, and planning for fine-tuning the specific questions and linking them to measurable business objectives. These scripts may also require substantial HTML customization to ensure the appearance of the script is carefully tailored to an organization's requirements, as they are seen by customers and not employees of the organization.
In general, efforts for interaction center scripts focus on agent productivity, whereas efforts for scripts for Web execution typically focus on extracting specific information, or on formatting and layout.
The key to any successful script development project is to clearly define your goals, engage in a process whereby all stakeholders sign off on defined requirements, perform acceptance testing, and avoid scope creep.
Prior to inserting a single panel on the canvas of a graphical script, or defining a single panel using the Script Wizard, a script developer should have in her possession explicit script guidance in the form of detailed requirements. These requirements must be closely tailored to attain the script development project objectives.
In order to develop scripts appropriately, the following, at minimum, must be identified in advance:
The full set of business rules that must be enforced by the script
Any text that must be communicated verbatim to the script audience (such as legal disclaimers, etc.)
Decision points that cause branching in the flow of the script
Data elements which must be captured during a script runtime session and used as a variable or otherwise processed later
Data (table fields) which must be queried from or written to database tables
Script development project administrators must provide detailed requirements to script developers. In addition, they should develop a detailed flowchart depicting the flow of the intended script. With these items in hand, a script developer can begin to implement the business requirements of the proposed script using both Script Author and custom code.
Script Author supports the creation of wizard scripts and graphical scripts. Both can be executed in any Scripting Engine agent interface.
Each method has certain benefits and limitations. Wizard scripts, for example, are created by responding to prompts in a series of windows known as a wizard. No programming knowledge is required in order to create a syntactically correct script and to include sophisticated features such as using preconfigured response validation routines for questions you create, or providing default answers to a question. Wizard scripts do not include any groups or blocks, other than a single Disconnect group which has no content (it serves to enable the Disconnect button in the agent interface at runtime). Wizard scripts are only opened or modified from the Script Wizard feature of Script Author. You can convert or "graph" a copy of a wizard script for subsequent modifications using Script Author's graphical tools. This is a one-way conversion. Any changes made to a graphical script can only be viewed in a graphical script. Using custom commands, changing certain global properties (footprinting, answer collection, or the suspendable option), or including Scripting Engine interface-specific runtime features requires the use of graphical tools.
Scripts created using graphical tools may include, at the outset, Scripting Engine interface-specific runtime features such as the script information panel and shortcut buttons. Custom commands or APIs can be associated from a graphical script. Groups and blocks can be created and configured, and the Disconnect group may be modified in a graphical script to contain other panels, groups, blocks, and so on as appropriate. Structured Query Language (SQL) select (query), insert, or update, commands can be associated with graphical scripts. Other database integration, in the form of Script Author commands referencing PL/SQL packages stored in the database, can be included in graphical scripts. You can also include embedded values in panel text to show information dynamically, or format text in various styles and using various alignment properties in a single panel using graphical tools.
Panel layout created or modified with the panel layout editor feature of a graphical script does not contain any configurable HTML tables. When including graphics, a reference to the image in panel HTML must be further customized externally to point to a corresponding file on a Web server (which must be accessible to the Scripting Engine at runtime), and reimported into the script. Any substantial changes to panel HTML can be made by exporting panel HTML, customizing the code, and reimporting into a panel from the panel layout editor.
If planned appropriately, you can combine script development methods. For example, you can develop the primary flow of a script using the Script Wizard; add custom commands or configure default settings using graphical tools; and to better control the appearance of a script at runtime, you can export panel HTML, modify it using any HTML or text editor, and reimport the modified HTML for each panel as appropriate.
Custom code is used to obtain information needed during the execution of the script, or to enforce specific business rules. Custom code supported by Oracle Scripting includes Java commands, PL/SQL commands, SQL calls to the database, Scripting blackboard commands, forms commands, and constant commands.
Custom code is referenced in the script by associating commands to objects in the script (or to the script itself) before it is deployed to the database from Script Author. Based on the type of command, the code may be stored in the metadata of the script itself (e.g., constant commands or PL/SQL commands), in the Scripting session (blackboard commands), on the applications server (custom Java commands exposed to the application by defining the class path), or in the database (custom Java commands deployed to the database from the Scripting Administration console, and PL/SQL packages stored in the database).
Custom Java can be used with Oracle Scripting in two ways: executing commands at runtime, and replacing agent interface panels with Java beans.
Scripts that reference custom Java methods associated with a Script Author command can execute each method as specified by the command at runtime.
This applies to all scripts executed in the Scripting Engine, using either the agent interface or the Web interface.
Scripts can also use custom Java beans to replace an entire panel in the runtime session on the agent client workstation. This provides agent users with extended functionality as customized in the Java bean. This bean is executed by Oracle JInitiator on the client.
This applies only to scripts executed in the Scripting Engine agent interface.
Note: Replacing a single question in a panel with a user interface Java bean is no longer supported functionality.
Note: This section includes information about Java Development Kit (JDK) and Java Runtime Engine (JRE) compatibility with Oracle JInitiator and with Oracle Applications. The information provided includes version numbers certified at the time of publication. Certification and compatibility information frequently changes. For the latest information, consult My Oracle Support or Oracle iSupport.
When using custom Java in support of Oracle Scripting, there are compilation dependencies based on specific circumstances. These are based primarily on the purpose of the Java archive in question (to provide Script Author commands or to replace panels with Java beans), and include the following environmental factors:
The level of Java Runtime Environment (JRE) used on the Apache Web server for your Oracle Applications environment
The level of Java Development Kit (JDK) used to compile your custom Java code
The Oracle JInitiator version used on the client
The Oracle Scripting architecture type used at the enterprise.
Custom Java for use as a Script Author command is executed by the Java Virtual Machine in the Scripting session. Using the Apache mid-tier architecture of Oracle Scripting, custom Java code is executed on the Apache Web server. Thus, this code must be compiled using a version of JDK that is compatible with the JRE used on the Apache Web server (this must be the same level or lower). At this time, appropriate JDK versions may include JDK 1.3, 1.2, or 1.1.8.
All scripts executed as surveys using the Scripting Engine Web interface use the JVM of the Apache Web server. Thus, this code must be compiled using a version of JDK that is compatible with the JRE used on the Apache Web server (this must be the same level or lower). At this time, appropriate JDK versions may include JDK 1.3, 1.2, or 1.1.8.
Custom Java that replaces a script panel with a user interface Java bean at runtime executes on the agent client. Thus, this code must be compiled using a version of JDK that is compatible with Oracle JInitiator on the agent client (this must be the same level or lower). At this time, appropriate versions may include 1.3 or 1.1.8.
The source code for Java methods or Java beans must be compiled into executable class files and packaged into Java archives in one of two file formats, as described in the table below:
| Format | Description | Example |
|---|---|---|
| JAR | Java Archive (JAR) | SOURCE.JAR |
| ZIP | WinZip archive | SOURCE.ZIP |
Note: Oracle recommends using JAR file formats, although both JAR and ZIP file formats are supported. For the purposes of this document, the term "Java archive" applies to both file formats, assuming the archive contains appropriately compiled and packaged code.
Note: When the Scripting Administration console references Jar files or Jars, appropriately packaged ZIP files are included in this definition.
Prior to Oracle Scripting release 11.5.9 (or Interaction Center Family Pack P), Script Author was available as in installable standalone client application supported on certain Windows platforms only. In current releases, you can access Script Author as a Java applet on any operating system platform supported by Oracle Applications. You must be in a valid Oracle Applications session to use the Script Author Java applet.
Benefits of running Script Author from an existing Oracle Applications session as a Java applet include:
Ability to create, modify and deploy scripts through a firewall using HTTP and secure HTTP.
Single login and authentication to the current production environment.
Logging into the Scripting Administration console and subsequently launching Script Author enables the user to access the database instance, obtain reusable commands from the command library, deploy scripts, and access PL/SQL stored procedures or packages without specifying database connection and login information (providing the same instance is accessed).
No requirement to implement (locate, download, unpackage and install) the Script Author component.
Apps user name and password no longer required to deploy scripts.
You must be in an authenticated Oracle Applications session in order to develop scripts.
In order to deploy the same scripts to multiple environments (for example, test and production instances), you must log into each environment separately, in sequence.
Since Script Author is no longer installed on a script developer's client installation, there is no longer a home directory for Script Author files. As a result:
Script Author standalone online help files, previously available in the Docs directory, is no longer available. For assistance using Script Author, refer to Oracle Scripting User Guide.
The CCTBUILDER.PROPERTIES file is now written to the Oracle JInitiator home directory.
This file, created automatically the first time Script Author is used, and updated each time the application is closed, stores user settings such as Script Author window size and location.
The EN.CONTENTS and BUNDLE.CONTENTS files are no longer created or required.
The default English strings for the Oracle Scripting application are stored in the EN.CONTENTS file. Previously, when the Script Author standalone application was run for the first time after installation, the user was asked to download strings for a specific language from the database. If the user decided not to connect to the database, BUNDLE.CONTENTS was created from EN.CONTENTS.
In current releases, using the Java applet, localized strings for Script Author are downloaded from the database each time Script Author is launched. The applet uses the default language setting for the user and attempts to load the localized strings from the database for that language. If the strings for that language are not found, then the user receives a warning message, and the default strings in English are used.
As of Oracle Scripting release 11.5.9 or later, or Interaction Center Family Pack P or later, Script Author is a Java applet launched from a valid Oracle Applications session. In previous releases, Script Author was a two-tiered Windows-only client application that required separate database login and authentication at the APPS user level. With the introduction of the Java applet version of Script Author, these restrictions are eliminated.
There are currently three points at which backward compatibility is not allowed when opening Script Author scripts.
Scripts saved using applet versions of Script Author (version 1.7.0.x) cannot be opened in Script Author applet versions 1.6.3.x and earlier.
Scripts saved using applet versions of Script Author (version 1.6.2.x) cannot be opened in Script Author client versions 1.6.1.02 and earlier.
Scripts saved using client versions of Script Author (version 1.6.0.x) cannot be opened in Script Author client versions 1.5.0.x and earlier.
A warning message will display for users attempting to save an older script in the new version, indicating that backward compatibility will be lost.
Note that older scripts can be imported as groups without change to the original older script file. This method is recommended when older files must retain their editability in client application versions of Script Author.
Oracle recommends that all scripts deployed to the database from the Script Author standalone application (Script Author versions prior to 1.6.2) be redeployed using the Script Author Java applet, accessed from the Scripting Administration console.
The Script Author application can only open a single script at a given time. Opening a second script causes any open scripts to close, prompting the user to save any changes made to the file. This restriction applies to client application and Java applet versions of Script Author.
To modify two scripts simultaneously, you must open two separate instances of Script Author (from separate Oracle Applications sessions, using two different compatible Web browsers). Objects or data will not be able to be conveyed using the clipboard when working in this fashion, although import and export capabilities are available.
To deploy the same script to multiple environments (for example, to move a fully tested script from a development to a production environment), you must first save a copy of the script from the original environment to a local or shared file system. Then you must log out, log into the target environment, launch the Script Author applet, open the script, and deploy it to the environment.
The Script Author Java applet is accessed from a valid Oracle Applications session, and is automatically aware of the database location of scripts for that environment. Thus, opening Script Author seeded or stored commands in the command library, opening scripts from the database, and saving deployed scripts to the database all occur without the need to establish database connections.
To open deployed scripts from or deploy scripts to a different database instance, you must log into the Oracle Applications instance for that environment and launch the Script Author applet from the corresponding Scripting Administration console.
Connecting to the database from the Script Author client application (prior to Interaction Center Family Pack P or Oracle Scripting release 11.5.9) requires specification of the database host machine, port, and SID, plus use of the APPS level user name and password.