There are various ways to view integration of Oracle Scripting. Since Oracle Scripting consists of several components, you can consider integration from this perspective. Since Scripting involves technologies using applications built with Oracle Forms Developer (referred to as Oracle Forms-based applications) and applications using Java Server Pages (JSP) technology built on HTML, you can consider integration by technology stack. Finally, Scripting includes pre-built integration, while also allowing custom integration with Application Program Interfaces (APIs). Integration can also be described from this perspective. Each is described in turn below.
This section includes the following topics:
Oracle Scripting consists of Script Author, Scripting Engine, Scripting Administration console, and Survey Administration console. Each has different integration considerations.
This section includes the following topics:
The Script Author is the component of Oracle Scripting used to create, modify and deploy scripts. As of Oracle Applications release 11.5.8 (CRM Family Pack P), Script Author is a Java applet that is launched from an existing Oracle Applications session.
To launch Script Author, log into Oracle applications using the CRM Homepage login (or the Single Sign-On login, if implemented) as a user with the Scripting Administrator responsibility, and click Launch Script Author from the Home tab of the Scripting Administration Console. Oracle JInitiator launches in a separate browser window, and then Script Author opens in a separate applet window on the client. Since the connection is established and associated with a specific database and applications instance, using the Script Author Java applet allows script developers to open, save, and deploy scripts to and from that database instance. Database connection information is not required to be specified to save commands to the command library or to import library commands into a script.
The Script Author Java applet replaces a standalone Script Author Java application available in prior releases which required a Windows operating system on the client. Using the standalone application also required the client to be on the same side of the firewall as the applications database, and necessitated apps database user access to deploy scripts or otherwise access the database.
The Script Author applet can be used on the same computer as any other Oracle Application, but as a Java applet is not in itself integrated with other applications.
The Scripting Engine is the runtime component of Oracle Scripting. Scripts created using Script Author are executed in one of two following interfaces:
The first of the Scripting Engine's two interfaces is the agent interface, which is a set of Java components wrapped in an Oracle form. Users of the agent interface are typically interaction center agents. The Scripting Engine agent interface provides enterprises with a method of scripting interactions with customers or prospects and integrating desktop workflow between various applications.
Integration with the Scripting Engine agent interface occurs in three ways:
Scripts can be launched from integrated Forms-based business applications (Oracle TeleSales and Oracle TeleService).
Note: In previous releases, scripts could also be launched from Oracle Collections.
Scripts can get, create, or update records in the applications database or in custom tables.
Scripts can get or set information from any open Oracle form in Oracle TeleService, using the Script Author Forms commands setValueInForm and getValueFromForm.
Using custom Forms commands, scripts may get and set information from some other Forms-based applications.
The agent interface is intended to be used in combination with integrated Oracle E-Business Suite applications to take full advantage of the contact handling, sales, or service features of those applications. Interaction centers leveraging business applications and the Scripting Engine agent interface therefore have the full benefit of interaction center communications.
Agents can also execute scripts in "standalone" mode, without accessing other applications. In the standalone model, integration is typically limited to reading or writing to the Oracle applications database. Login to an Oracle Applications session is still required. Execution of scripts in standalone mode is not supported by Oracle.
The Scripting Engine Web interface executes scripts in any Oracle Applications 12-certified Web browser. Scripts executed in the Web interface rely on survey campaign information administered using the Survey component.
The Scripting Engine Web interface is integrated with self-service Web applications such as Oracle iSupport. After using the application, customers can be surveyed regarding their self-service Web application experience by clicking on a hypertext link provided in the application interface. This links to a URL for an activated survey campaign deployment.
With customization to add the valid URL of any activated survey deployment, any Oracle self-service Web application is integrated with the Scripting Engine Web interface.
For execution of targeted survey deployments, HTML invitations and reminders are sent from Oracle One-to-One Fulfillment to list members of Oracle Marketing lists, inviting those members to participate in a survey or Web script by accessing a valid survey URL. The survey URL includes a JSP template parameter, defining how the script executes in a Web browser at runtime. It also identifies the deployment (dID), and each individual potential respondent (using the parameter rID).
Additional information is also appended to the survey URL, which makes that information available to the Scripting blackboard during execution of the script. Parameters passed include the following:
| Parameter | Blackboard Key | Description |
|---|---|---|
| apps user ID | IES_FND_USER_NAME | User name for the current apps session.
|
| parent party ID | P_PARTY_ID |
|
| contact party ID | P_CONTACT_PARTY_ID |
|
These parameters are only passed for targeted deployments.
The apps user ID identifies the apps-level guest user if the hosting option is standalone. If it is menu-based, this parameter holds the Oracle Applications user name of the person currently logged in when the script is executed.
The parent party ID and the contact party ID are data items from the trading community architecture (TCA).
The parent party ID and the contact party ID are passed from columns stored in the AMS_LIST_ENTRIES table within the Oracle Applications schema.
The parent party ID column in AMS_LIST_ENTRIES, PARENT_PARTY_ID, is stored in the blackboard as blackboard key P_PARTY_ID.
The contact party ID column in AMS_LIST_ENTRIES , PARTY_ID, is stored in the blackboard as blackboard key P_CONTACT_PARTY_ID.
Because TCA accounts for contacts that are either the primary party or a contact within an organization, you must understand how TCA handles data differently for each situation. For example, P_PARTY_ID could either be the name of a person or of an organization. Accordingly, CONTACT_PARTY_ID will be null when both fields are not required (when the contact type is a person).
If the party type of a selected contact is an organization, then the P_PARTY_ID parameter holds the name of the organization. In this case, the name of the specific contact person within the organization is stored in the parameter P_CONTACT_PARTY_ID.
If the party type of a selected contact is person, then the P_PARTY_ID parameter holds the name of the person. In this case, the parameter P_CONTACT_PARTY_ID is null.
The Scripting Administration console is an HTML administration console built on the deprecated JTT technology stack. This console is accessed by logging into Oracle HTML-based applications using an Oracle Applications user account with the Scripting Administrator responsibility. Using the Scripting Administration console, script administrators can launch Script Author as a Java applet, administer deployed scripts and custom Java archive files, and view panel footprint reports.
There is no integration between this component and other Oracle Applications. Like other HTML applications, users with multiple responsibilities can access other application functionality by changing the current responsibility for the authenticated Oracle Applications session.
The Survey Administration console is an HTML administration console built on the Oracle Applications framework. Using the Survey Administration console, survey administrators create, administer, and deploy survey campaigns and monitor progress in existing survey campaign deployments.
The Survey Administration console integrates directly with Oracle Marketing and Oracle One-to-One Fulfillment by hosting tabs from those HTML-based applications in the administration console. These tabs are the Audience tab and the Invitations tab, respectively.
The same business rules, prerequisites, and requirements for accessing the user interface of integrated applications also apply to the survey administrator.
For example, to access the Invitations tab, the user requires not only the Survey Administrator responsibility, but also must be assigned the JTF_FM_ADMIN_ROLE role. For more information, see Granting JTF Roles.
The invitations tab provides access from the survey administration console to the same application pages that you can access using the Template, Query, and Status subtabs in the Fulfillment Administration console. Note that a fulfillment administrator is still required to set up fulfillment servers, groups, and to monitor fulfillment requests.
In addition to survey-specific functionality, the survey administration console provides access to an Audience tab. This tab displays the same content that you can see in the Oracle Marketing user interface under the Audience tab (for Oracle Marketing releases prior to 11.5.10) or the Audience Workbench tab (for Oracle Marketing release 11.5.10 and later). To access this tab from the Survey Administration console, the Oracle Applications user account must have a sales group ID and a sales role. These are administrative setup steps required to be performed by a user with the CRM Resource Manager responsibility. You can also configure the Survey Administrator responsibility to bypass this requirement. For this procedure, see Bypassing the Sales Resource Group Membership Requirement.
This section includes the following topics:
This section includes the following topics:
Using self-service Web-based applications such as Oracle iSupport, customers can launch a script in the Scripting Engine Web interface, and execute it using a Web browser.
Note: While this section describes application functionality within context of Oracle iSupport, scripts in this interface can be hosted in any Oracle self-service Web application.
When Oracle Scripting is integrated with self-service Web applications such as Oracle iSupport, users log into the application using an Oracle Applications 12-certified Web browser and a user with the appropriate responsibility.
Users then access a page in the UI with one or more hypertext links. These links are created through application customization, in which an application administrator previously customized the UI to include, within the code for each hypertext link, a valid survey URL for an active standard survey campaign deployment.
From this page, the application user clicks the hypertext link. The page refreshes, displaying the survey questionnaire's first panel as an HTML page in the same Web browser instance. If the survey campaign details specify a survey resource header section or footer section, these appear on each HTML page of the script.
Each page (corresponding to a single script panel) contains one or more question controls, including at minimum a submit button (typically labeled Continue). Clicking the Continue button progresses the script to the next panel, which appears as a separate HTML page.
If an error results, or when the script is complete, the survey resources designated as the error page or final page display, as appropriate.
There are two hosting options for survey deployments: Menu Based and Standalone.
For deployments designated as menu-based, the navigational menus (tabs) of the self-service Web application are retained at the top of each page throughout. These are also referred to as hosted surveys or Web scripts. In all cases, hosted deployments use the Oracle Applications authentication information for an existing session. After a hosted survey is completed, the user can continue to use the application from which a script is launched in the Web browser.
For deployments set as standalone, the Oracle Applications session (always required in order to execute a script) is initiated using a guest user. The only privilege granted to the guest user is to execute the Web script or survey specified by the survey campaign. After the script completes its execution and the final page is displayed, the Oracle Applications session is de-authenticated.
For standard (non-list-based) Web scripts or surveys using the Oracle Applications framework, the session will always be hosted, if the survey URL is selected from an authenticated Oracle Applications session. This is because all Scripting Engine Web interface transactions using the Oracle Applications framework use the same JavaServer page, OA.JSP, as the template from which to execute all scripts. Upon completion of the script in the Web browser, the Oracle Applications session is still valid, and you can return to other functions in that application.
In contrast, targeted (list-based) Web scripts or surveys do not support the menu-based hosting option if using the Oracle Applications framework. Regardless of the hosting option selected, the applications guest user will initiate the Oracle Scripting session. Even if the user is logged into an Oracle self-service Web Application when a link to an active targeted survey URL is selected, the menus from any open self-service Web application will not be hosted in the Web browser at script runtime. Upon completion of the script, any active Oracle Applications session will expire; you can do no additional work in the open application without logging back into the application.
If the Base Tech Stack setting for the survey campaign is Deprecated - JTT, you can control whether a script executed in a Web browser is hosted in the self-service Web application's UI (and the session remains open upon script completion), or whether guest user authentication is used to run the script, and the applications session is terminated upon script completion. This hosting option (and the Oracle Scripting session authentication method) is determined by the JSP template parameter used in the survey URL. If the survey URL includes IESSVYMENUBASED.JSP, then the application uses the authentication of the existing Oracle Applications session. If the survey URL includes IESSVYMAIN.JSP., then the guest user Oracle Applications account is used to authenticate a new session, and is restricted to executing a script only. Upon completion of the script in the Web browser, the Oracle Applications session is terminated.
When defining targeted survey campaign deployments, there is a hosting options list selection. For JTT survey campaigns, when the survey administrator selects Standalone, the JSP template parameter IESSVYMAIN.JSP is used, and when the administrator selects Menu Based, the IESSVYMENUBASED.JSP template is added to the survey URL.
As indicated above, for an OAF deployment, even if Standalone is selected, if the survey URL is clicked from a valid Oracle Applications session, it will be hosted in the application's user interface.
To force a script to execute using guest user authentication using the Oracle Applications framework (in other words, to force it to execute with a standalone hosting option), copy the survey URL and paste it into a separate Web browser session with no current authentication and no valid cookie to a current authenticated session. For example, if you are using Oracle Applications with Netscape Communicator in an application such as Oracle iSupport, copy the survey URL, paste it into the Address field of a different supported Web browser (such as Microsoft Internet Explorer). Then the session will use the seeded guest user account for authentication. At the end of any session using the guest user, the Oracle Applications session will be terminated.
For more information, see the Survey URL topic in the Oracle Scripting User Guide.
For hosted surveys using the OA framework, you can redirect the user to any URL defined as a survey resource, upon script completion in the Web browser.
For hosted surveys using the JTT framework, you can designate the page listing survey links as the Final page survey resource, if you define it as a survey resource. As a script user, after you complete the Web script or survey, you return to the page from which you launched the survey script. Other links on that page can be customized as desired by Oracle iSupport administrators.
For hosted surveys using the JTT framework, you can use the test resource IESSVYMENUBASEDTESTERROR.JSP (seeded with Oracle Applications) as the basis for your error page. Some customization is required.
From the user interface of Oracle iSupport or another hosted self-service Web application, the user clicks a hypertext link for an active survey URL. The survey or Web script starts in the current Web browser window, preserving the menu structure.
The survey is expected to be completed in order to deliver reliable information. Abandoned survey responses are tracked but not displayed in most reports.
Upon completion of the script, you can continue working in the hosted application, as the Oracle Applications session remains valid.
Oracle One-to-One Fulfillment provides enterprises with an automated method for sending information to its customers. Interaction center agents use Oracle One-to-One Fulfillment directly or through automated applications such as Oracle Marketing. Agents often receive customer requests for information, literature, and other correspondence. These requests include product and service inquiries, pricing questions, billing inquiries, and general customer care issues. Agents can immediately fulfill these requests using e-mail to automatically deliver predefined fulfillment items to identified customers.
Oracle One-to-One Fulfillment is set up and maintained by a Fulfillment administrator, who must configure and run a Fulfillment Server to monitor fulfillment requests, and a Fulfillment Email Server (a logical channel for the output device that delivers electronic documents to customers).
From an Oracle Scripting perspective, Oracle One-to-One Fulfillment can be used to deliver "invitation" and "reminder" master documents (HTML documents) using electronic mail, inviting identified parties to participate in a survey campaign by visiting a defined URL.
The parameters required for integration with Oracle One-to-One Fulfillment for inviting potential respondents via e-mail to participate in a survey are included in the deployment details section of the Survey Administration console.
The Survey Administration console also includes an Invitations tab, which hosts Oracle One-to-One Fulfillment functionality. Survey administrators that need to access this tab must be assigned the JTF_FM_ADMIN_ROLE role. For more information, see Granting JTF Roles.
Oracle Marketing is a tool used to create and manage marketing and sales campaigns, assign scripts to particular campaign schedules, assign agents to specific campaigns, etc. You can create lists of customers in Oracle Marketing, and invite them using e-mail (using Oracle One-to-One Fulfillment "invitation" and "reminder" master documents) to participate in a survey campaign by visiting a defined URL.
The parameters required for integration with Oracle Marketing to use existing marketing lists as the source for sending e-mail invitations and reminders are included in the deployment details section of the Survey Administration console.
The Survey Administration console also includes an Audience tab, which hosts Oracle Marketing functionality. The Oracle Applications user account for survey administrators that need to access this tab must have a sales group ID and a sales role. For more information, see Bypassing the Sales Resource Group Membership Requirement.
Oracle Forms-based eBusiness applications that integrate with Oracle Scripting include Oracle TeleSales and Oracle TeleService.
Note: Oracle Collections was integrated with Oracle Scripting in earlier releases.
From an interaction in these integrated business applications, an agent can launch a script in the Scripting Engine agent interface. Each business application supports at least two models: (1) allowing the agent to select any script from a list of deployed scripts for that instance, and (2) specifying a particular script to launch upon a particular condition or action. No additional configuration is required to enable the first model. To enable launch of a particular script, specific setup steps are required, which vary by application. Each of these is discussed in the section for integrating the particular business application. For more information, see Oracle Scripting Implementation Guide and the implementation guide for each specific application in question.
To execute scripts in the agent interface, the agent's Oracle Applications account must have the correct responsibility associated with it to launch the business application in question. The table below indicates, by application, responsibilities which may be required, and from which form in the application the script can be launched.
| Business Application | Required Responsibility | Form |
|---|---|---|
| Oracle TeleSales | TeleSales Agent | eBusiness Center |
| Oracle TeleService | Customer Support | Contact Center |
Other responsibilities for a particular business application may also have access to execution of scripts. The ones listed in the table above are established for agent-level privileges. For more information, consult the product documentation for the appropriate application.
Each of these Oracle Forms-based business applications are typically used by interaction center agents for sales or service, respectively. The functionality of these business applications can be greatly extended and customized by creating and using scripts launched from the appropriate business application.
After logging into the appropriate business application, no specific Scripting responsibilities are required for an agent to launch a script.
These scripts are launched in the Scripting Engine agent interface in a separate window.
If choosing from the full list of deployed scripts, the agent must select the appropriate script name and language from the Script Chooser list.
The script is expected to be completed prior to returning to the business application.
If the script commits changes to the customer information in the database, these changes will not be reflected in the business application until a fresh request for customer information from the database is made from the business application.
Individual implementation, setup, or configuration steps may be required in order to access the business applications listed above. For example, membership in a sales or telesales group (for Oracle TeleSales) is required. Other conditions may apply for each application. These steps are outside the scope of this document. For more information, refer to the appropriate documentation for the relevant business application.
For relevant information regarding Oracle Forms-based applications, refer to Oracle Applications Developer's Guide. Specifically, refer to the section Menus and Function Security.
Interaction centers using the Scripting Engine agent interface can not only interact with customers but can also integrate desktop workflow between various applications. Oracle Scripting is intended to be used in combination with integrated Oracle E-Business Suite applications (Oracle TeleService and Oracle TeleSales) to take full advantage of the service and sales features of those applications, respectively. In terms of prebuilt integration, scripts can be launched from any of these customer-facing, interaction-based business applications. Additionally, Oracle TeleSales automatically sends values for a selected customer to the Scripting blackboard for use in a script interaction.
Note: Oracle Collections was integrated with Oracle Scripting in earlier releases.
Oracle Marketing is seeded with several Oracle Scripting building block scripts. These enable users of Oracle Marketing to authenticate customers, register for an event, create leads, and so on.
This section includes the following topics:
This section includes the following topics:
From the Navigate To menu, select All Scripts.
The Oracle Scripting window (commonly referred to as the Script Chooser) appears.
From the Script Chooser, select a script name and language.
Click Start Scripting.
The script will launch in a separate window.
From Oracle TeleSales, you can launch in the Scripting Engine agent interface a designated script deployed to your Oracle Applications instance, leveraging Oracle Marketing campaign information.
There are three models for launching this designated script:
Automatic launch of a specific script when a call is received.
Automatic launch of a specific script when an interaction is started in the eBusiness Center.
Launch of a specific script based on explicit agent request (agent clicks View Script button).
To designate the specific script to launch from Oracle TeleSales using any of these models requires the script to be designated at the campaign schedule level. As a prerequisite of launching a designated script, you must administer campaigns in Oracle Marketing. Oracle Marketing requirements include the following:
A valid campaign.
A valid campaign schedule associated with the campaign.
An inbound or outbound script associated with the campaign schedule.
Agents must be associated to the campaign schedule, or campaign schedules must be assigned to agents.
For more information on these steps, see Oracle Marketing product documentation or the topic Administering Campaigns in Oracle Marketing.
Obviously, there is no explicit action to be taken by the agent for automatic launch of a script. Based on the type of automatic launch (on call delivery or on start of interaction), when the event or condition is met, the script launches in a separate window. The procedure below applies to launching a specified script from the eBusiness Center at a time chosen by the agent.
Specific profile settings are required to accomplish each method of launching a specified script. These are described in the guidelines below.
At least one appropriate script must be deployed from Script Author to the applications database.
If custom code is referenced in the script, that code must be available to the Scripting Engine at runtime.
A campaign must exist in Oracle Marketing with a valid campaign schedule, and the agent using the appropriate business application must be associated with the campaign schedule associated with the campaign.
The specific deployed script must be associated to either the campaign schedule from Oracle Marketing in order to launch without accessing the Script Chooser.
System profiles must be set according to the guidelines indicated.
Oracle TeleSales sends a set of values for the selected customer to the Scripting blackboard when a script is launched from the eBusiness Center. In order to receive those values and use them in a script, the agent must be in an active Oracle TeleSales transaction with a customer selected in the eBusiness Center.
Log into Oracle applications using the Personal Home Page login, or the Single Sign-On login if implemented.
TeleSales Agent
As indicated above, campaign administration of Oracle Marketing is required.
For any model of launching scripts from Oracle TeleSales, set the OTS: Scripting Installation profile to Yes.
For any model of automatically launching a specified script, also set the OTS: Script Launch on Interaction profile to Yes.
For Oracle TeleSales to launch a script upon delivery of the call to the agent desktop only, also set the OTS: Script Launch on UWQ Delivery profile to Yes.
For more information about the OTS profile options relevant to Oracle Scripting, see Effects of OTS Profile Settings for Oracle Scripting.
Steps
Ensure a customer is selected in the eBusiness Center.
Ensure a campaign is selected in the Overview tab.
The selected campaign, or a campaign schedule associated with the campaign, must have a script associated with it.
From the Navigate To menu, select View Script, or from the Overview tab, click View Script.
The script will launch in a separate window.
The following table describes the effects of the OTS profile settings for Oracle Scripting:
| Profile Option | Setting | Result |
|---|---|---|
| OTS: Script Launch on UWQ Delivery | Yes | Automatic launch of a specific script in a separate window when a call is received in Oracle TeleSales. |
| OTS: Script Launch on UWQ Delivery | No or Null | No script launches on call delivery. |
| OTS: Script Launch on Interaction | Yes | When an Oracle TeleSales interaction starts, the specified script automatically launches in a separate window. |
| OTS: Script Launch on Interaction | No or Null | No script launches on start of interaction. |
| OTS: Scripting Installation | Yes | This setting allows scripts to be launched from Oracle TeleSales. |
| OTS: Scripting Installation | No | Regardless of other profile settings, if set to no, scripts will not launch from Oracle TeleSales. |
| Profile Option | Setting |
|---|---|
| OTS: Script Launch on UWQ Delivery | Yes |
| OTS: Script Launch on Interaction | Yes |
| OTS: Scripting Installation | Yes |
| Profile Option | Setting |
|---|---|
| OTS: Script Launch on UWQ Delivery | No or null |
| OTS: Script Launch on Interaction | Yes |
| OTS: Scripting Installation | Yes |
| Profile Option | Setting |
|---|---|
| OTS: Script Launch on UWQ Delivery | No or null |
| OTS: Script Launch on Interaction | No |
| OTS: Scripting Installation | Yes |
Oracle TeleSales integrates with Oracle Scripting by passing parameters from a current Oracle TeleSales interaction to the Scripting Blackboard each time a script is launched from Oracle TeleSales. The parameters passed are listed in the table below, and mostly relate to the Trading Community Architecture.
The Oracle Trading Community Architecture (TCA) is a data model that provides a virtual representation of the community in which that business is conducted. This model includes parties and related party entities.
A party is defined as a person, organization, relationship, or collection of parties that can enter into business relationships with other parties. TCA is used by Oracle Applications to store sets of information in the database about our customers. If an individual is a customer, the party type is Person. If an organization or enterprise is a customer, then the party type is Organization. Relationships or groups further define specific individuals or groups of individuals as contacts within an organization. The TCA model is valuable because, with strategies to store and access information in specified tables and columns and business rules to govern these, the same database schema is used despite whether the business relationship is business-to-business (B2B) or business-to-consumer (B2C).
The following list shows the parameters currently being sent by Oracle TeleSales to the Scripting blackboard:
| Parameter | Description | Comments |
|---|---|---|
| ADDRESS_ID | Location ID | For PARTY_TYPE of RELATIONSHIP, Address ID is not related to a given PARTY_ID |
| AST_RESOURCE_ID | Resource ID | This resource ID is derived from the global variable AST_RESOURCE_ID from Oracle Marketing. |
| CAMPAIGN_ID | Source Code ID | If a campaign is associated with a campaign schedule, this is the ID associated with the campaign source code. Otherwise, this value is null. |
| CAMPAIGN_NAME | Campaign name | If a campaign is associated with a campaign schedule, this is the name of the campaign. Otherwise, this value is null. |
| CAMPAIGN_SOURCE_CODE | Source Code | If a campaign is associated with a campaign schedule, this is the source code associated with the campaign. Otherwise, this value is null. If you do not provide a source code in Oracle Marketing, a unique code is generated by the system. |
| CONTACT_ID | Person Party ID | Contact ID if the selected contact is a party type of person. Otherwise, this value is null. |
| CUST_ACCOUNT_ID | Account ID | The account ID for this party. |
| INTERACTION_ID | Interaction ID | The interaction ID from the eBusiness Contact Center for the interaction record of the given party type. |
| P_PARTY_ID | Party ID of the account owner. | For an individual, the Person ID of the selected party. For a relationship customer, the organization party ID will be passed. |
| PARM.PARTY_ID | Party ID of the account owner. | For an individual, the Person ID of the selected party. For a relationship customer, the organization party ID will be passed. |
| PARTY_CONTACT_ID | Organization Party ID | Contact ID if the selected contact is a party type of organization. Otherwise, this value is null. |
| PARTY_ID | Party ID of the account owner. | For an individual, the Person ID of the selected party. For a relationship customer, the organization party ID will be passed. |
| PARTY_TYPE | Party type | Identifies the party relationship: person, organization, or relationship. |
| TM_ANI | ANI | This parameter (automatic number identification or ANI) indicates the billing number from which an inbound call originates. This is sometimes referred to as the caller ID. |
| TM_DNIS | DNIS information | This parameter indicates the number from which an inbound call originates. The Dialed Number Identification Service (DNIS) parameter indicates which number for an inbound call was dialed by the caller. DNIS information is often used for call routing or to separate campaigns and functions. |
The following parameters are no longer supported using this model:
| Parameter | Description | Comments |
|---|---|---|
| COLLATERAL_ID | Obsolete | Not applicable in this release. |
| EVENT_ID | Obsolete | Not applicable in this release. |
| LEAD_ID | Obsolete | Not applicable in this release. |
| OPP_ID | Obsolete | Not applicable in this release. |
| P_RESOURCE_ID | Obsolete | Not applicable in this release. |
| SOURCE_FORM_ID | Obsolete | Not applicable in this release. |
| SOURCE_FORM_FUNCTION | Obsolete | Not applicable in this release. |
Values are passed each time a script is launched from the eBusiness Center.
Any parameters not available from the integrated Oracle business application will be null in the Scripting Blackboard.
A customer must be selected in Oracle TeleSales in order to receive some or all values into the script.
If a script relies on values passed from Oracle TeleSales for critical processing, the script should include a test for a null value before attempting the process. If a null value is found, the script should include panels to collect the required information at runtime, populating them with the appropriate blackboard answer keys to ensure the script can continue its processing.
If a blackboard value retrieved into a script is subsequently changed in the business application before the script is completed, the updated value will not display in the script. If the script is completed and started again, the updated value will be retrieved into the script.
This section includes the following topics:
Using Oracle TeleService, you can launch a script of your choice in the Scripting Engine agent interface from the full set of scripts deployed to your Oracle Applications instance.
At least one appropriate script must be deployed from Script Author to the applications database.
If custom code is referenced in the script, that code must be available to the Scripting Engine at runtime.
System profiles must be set according to the guidelines indicated below.
If the script being called uses any Forms commands from any TeleService form, that form must be open and appropriately populated with information in the Contact Center for those values to be made accessible to the script.
Log into Oracle applications using the Personal Home Page login, or the Single Sign-On login if implemented.
Customer Support
For Oracle TeleService to launch a script upon delivery of the call to the agent desktop, the following profile must be set:
| Profile Option | Setting |
|---|---|
| Customer Care: Automatically Launch a Script for Identified Callers | <global script name> |
Note: In some cases, this profile option display value may be Customer Care: Default Contact Center Script.
Steps
Ensure a customer is selected in the Contact Center.
From the Tools menu, select Script, or click on the Script icon in the toolbar.
The Oracle Scripting window (commonly referred to as the Script Chooser) appears.
From the Script Chooser, select a script name and language.
Click Start Scripting.
The script will launch in a separate window.
Using Oracle TeleService in a media-enabled environment, you can automatically launch a designated script in the Scripting Engine agent interface. As soon as a call is delivered to the Oracle TeleService Contact Center, if at least one of three parties is identified, the designated script launches in a separate window. In the event that a party is not identified (the TeleService screen pop is blank), the script is not launched. Only one of three possible parties (organization, person, or relationship) is required to launch the script, as identified by the HZ_PARTIES table in the Oracle Applications schema.
There is no explicit action to be taken by the agent for automatic launch of a script other than appropriate setup, as indicated in the guidelines below.
Oracle TeleService must be media-enabled.
To launch a designated script automatically, the calling party (rel party) must be identified.
At least one appropriate script must be deployed from Script Author to the applications database.
If custom code is referenced in the script, that code must be available to the Scripting Engine at runtime.
System profiles must be set according to the guidelines indicated below.
If the script being called uses any Forms commands from any TeleService form, that form must be open and appropriately populated with information in the Contact Center for those values to be made accessible to the script.
Log into Oracle applications using the Personal Home Page login, or the Single Sign-On login if implemented.
Customer Support
For Oracle TeleService to launch a script upon delivery of the call to the agent desktop, the following profile must be set:
| Profile Option | Setting |
|---|---|
| Customer Care: Default Contact Center Script | <global script name> |
Steps
From the Navigator, select Contact Center and click Open.
The Contact Center window opens.
When a call is received, the designated script launches in a separate window.
Complete interaction within the script before returning to the Contact Center.
In addition to being able to launch a script from Oracle TeleService, Oracle Scripting can retrieve values from the TeleService Contact Center using Forms commands in Script Author. Upon execution of the Forms command at script runtime, the Contact Center retrieves the appropriate contact information, and passes this information on to Scripting.
Some typical Forms commands used to pass values from Oracle TeleService to Oracle Scripting are listed in the table below:
| Forms Command | Value Passed to Script |
|---|---|
| GetInteractionId | Interaction ID |
| GetCustomerId | Account ID/Party ID |
| GetCustAccountId | Customer Account ID |
| GetCustomerType | Customer Type |
| GetContactId | Contact ID |
| GetContactPointId | Contact Point ID |
| GetContactPointType | Contact Point Type |
| GetContactType | Contact Type |
| GetPrimaryFlag | Primary Flag |
For more information on Forms commands, see the Forms Commands section of the Oracle Scripting Developer's Guide.
A script can also be associated with a Relationship Plan. For information on relationship plans, refer to Oracle TeleService Implementation Guide.
Oracle Scripting integrates with Oracle Forms-based applications. To create a service request by calling a PL/SQL package from Scripting, the following fields must be populated:
SR Type
SR Status
SR Severity
Summary
Group Owner (see guidelines)
Individual Owner (see guidelines)
If set to "Yes", the Oracle TeleService profile option, Service: Group Owner Mandatory, requires the user to enter a group owner when creating a service request.
If set to "Yes", the Oracle TeleService profile option, Service: Default Group Owner for Service Requests, requires either the group owner or an individual owner to be entered when creating a service request. This profile takes precedence over the Service: Group Owner Mandatory profile option, if set.
The usage of a CRM resource must be defined as "Support" for the resource to be available in the Service Request tab in Oracle TeleService. This usage is set when the resource is defined using Oracle CRM Resource Manager.
Oracle Marketing is seeded with several Oracle Scripting building block scripts. These robust seeded scripts are supported and maintained by the Oracle Marketing team, and are documented in Oracle Marketing Implementation Guide.
These new building block scripts expand the offering previously available to include scripts for business-to-consumer (B2C) functions in addition to the business-to-business (B2B) functions provided by the Oracle Scripting building block scripts. The Oracle Marketing scripts also take advantage of changes to the APIs used to create leads and events that were introduced in Oracle Marketing release 11.5.9. The API changes included in the new scripts will not be reflected in the original set of Oracle Scripting building block scripts.
Additionally, they replace completely the lead creation and event registration functionality previously accessible using the Oracle Scripting Building Block scripts.
| Building Block Script | Function |
|---|---|
| AMSCAUTH.SCR | Customer Authentication |
| AMSERB2B.SCR | B2B Event registration (supersedes Oracle Scripting building block script IESEVENT.SCR) |
| AMSERB2C.SCR | B2C Event registration |
| AMSERWCA.SCR | Event registration with customer authentication |
| AMSLDB2C.SCR | B2C Lead creation |
| AMSLDB2B.SCR | B2B Lead creation (replaces Oracle Scripting building block script IESLEAD.SCR) |
| AMSLDWCA.SCR | Lead creation with customer authentication |
| AMSDATACQ.SCR | Data acquisition |
These scripts are seeded with Oracle Marketing in current releases, and can be downloaded from the applications server from the product top directory ( $AMS_TOP/scripts). Oracle suggests that users first transfer the files to a local directory, then launch Script Author, open each relevant building block script, modify as required, and deploy to the specific instance.
The Java code needed by the Marketing scripts is also delivered as part of the Marketing 11.5.9 release, so developers do not need to create any custom Java in order to use the Java methods.