This chapter introduces the components of Oracle Real-Time Decisions (Oracle RTD), with particular emphasis on the development tool Decision Studio and the Web-based application Decision Center. This chapter also introduces Inline Services, which are created to model business processes, gather statistics, and make recommendations, and describes how Inline Services are used in the development cycle. Decision Studio is used to configure Inline Services, and Decision Center enables business analysts to monitor and optimize deployed Inline Services.
Oracle Real-Time Decisions (Oracle RTD) provides a new generation of enterprise analytics software solutions that enable companies to make better decisions in real time at key, high-value points in operational business processes.
Oracle RTD easily integrates with enterprise applications both on the front end (such as websites and CRM applications) and on the back end (such as enterprise data stores). Oracle RTD also includes other helpful load testing and debugging tools.
This chapter contains the following topics:
Oracle RTD consists of five components:
Real-Time Decision Server
Inline Service refers to the configured application that is deployed.
Inline Services are configured and deployed using Decision Studio and analyzed and updated using Decision Center. Inline Services run on Real-Time Decision Server.
An Inline Service consists of the metadata that describes how the Real-Time Decision Server should gather data and analyze characteristics of enterprise business processes on a real-time and continuous basis.
Elements are one of the following types of objects:
Application: The application object identifies application level settings including default model parameters, and any parameters needed for the Inline Service globally.
Performance Goals: Performance Goals identify the Key Performance Indicators (KPIs) used for setting the decision criteria for the scoring of choices in Oracle RTD.
Choices: Choices represent the offers that will be presented through the Inline Service or the targets of study to be tracked by the self-learning models of Oracle RTD.
Rules: Rules are graphically configured rules used to target segments of population, decide whether a choice is eligible or score a particular choice.
Decisions: Decisions score and rank eligible choices based on the weighted scores for each associated performance goal.
Selection Functions: Selection Functions can be used by Decisions as a custom way to select which choice to send back through the Oracle RTD Advisors.
An Advisor is an Integration Point. For more information, see the topic Integration Points that follows in this list.
Entities: Entities represent the actors in the system. Entities are a logical representation of data used for Oracle RTD modeling and decisioning. The attributes of an entity can be populated via data sources, as incoming parameters from integration points, or derived in real time through custom logic.
Data sources: Data Sources retrieve data from tables or stored procedures.
Integration Points: Integration Points serve as the touchpoints with outside systems interacting with Oracle RTD. There are two classes of Integration Points: Informants and Advisors. Informants receive data from outside systems, whereas Advisors receive data and also send recommendations back to outside systems.
Models: Self-learning, predictive models that can be used for optimizing decisions and providing real-time analysis for desired targets of study.
Statistics Collectors: Statistic Collectors are special models that track statistics about entities.
Categories: Categories are used to segment data for display in Decision Center.
The following terms are referenced throughout the Oracle RTD documentation:
RTD_HOME: This is the directory into which the Oracle RTD client-side tools are installed.
RTD_RUNTIME_HOME: This is the application server specific directory in which the application server runs Oracle RTD.
Decision Studio is the development tool for configuring Inline Services, the services that are created to model business processes, gather statistics, and make recommendations. Decision Studio is fully integrated with Eclipse, an open source Java IDE produced by the Eclipse Foundation. Decision Studio exists as a standard plug-in to the Eclipse environment. If you are using Eclipse, you have the advantage of using the environment for additional development and advanced features. If you are not familiar with Eclipse, it is completely transparent to using Decision Studio. Eclipse and Decision Studio both have online help available through the Help menu. Decision Studio allows you to work with an Inline Service from several perspectives. A perspective defines the initial set and layout of views and editors for the perspective. Each perspective provides a set of functionality aimed at accomplishing a specific type of task or works with specific types of resources. Perspectives control what appears in certain menus and toolbars.
To select or change to a different perspective (such as Inline Service, Java, Resource, and so on), click the Window menu in Decision Studio and choose Open Perspective, then choose from the list of available perspectives. The default perspective when starting Decision Studio for the first time is Inline Service. We will use this perspective in this tutorial. In general, this will be the perspective you use to develop Inline Services.
The default Inline Service perspective contains four views and an editor area, as shown in Figure 1-1.
This section contains the following topics:
The Inline Service Explorer View organizes all of the elements of the Inline Service that are configured by the user.
The Problems View shows validation (.sda files) and compilation errors (.java files) as you build and compile your Inline Service. If you double-click a validation error, Problems View opens the metadata/element-editor at the point of the error. If you double-click a compilation error, Problems View opens the generated source code (
.java files) at the point of the error. You should not edit generated source code files directly; instead, fix related metadata/element problems, which will then regenerate and recompile the source code.
The Test View allows you to test your Inline Services directly from Studio after you deploy them to the server.
The Cheat Sheets View provides step-by-step instructions for common tasks. After installation, it is located on the right-hand side of the window.
You may want to close the Cheat Sheets View to give more editor space. The Cheat Sheets are not used in this tutorial.
The center area of the Inline Service Perspective is the editor area, and shows an editor that is specific to the node on the project tree you have selected. To change to a new editor, double-click the element you want to edit from the Inline Service Explorer View.
Tabs on the editors indicate the names of resources that are currently open for editing. An asterisk (*) indicates that an editor has unsaved changes.
You can drag the views and editors of a perspective to any space on the screen. Views and editors will resize themselves to fit the area in which they are placed. Occasionally, portions of an editor (where you do your main work) or view will become covered by other views, or resized to an area that is not convenient to use. To resize the editor or view, either close other open views and the remaining will automatically resize, or maximize the editor or view by double-clicking the editor tab.
Both editors and views can be toggled between Maximize and Minimize by double-clicking the tab, or by using the right-click menu item.
To show additional views or open views that were closed, click the Window menu in Decision Studio and choose Show View, then choose from the list of available views.
Decision Center is a Web-based application that allows the business analyst to monitor and optimize deployed Inline Services. From Decision Center, you can view statistics gathered from the models and fine-tune campaigns such as cross-selling, as well as adjust how decisions are made. The Decision Center user interface displays Inline Services in two panes. The left pane shows the list of Inline Service elements, while the right pane displays detailed information related to the selected element.
Inline Services are created using Decision Studio. Figure 1-3 shows the Inline Service Lifecycle.
The following steps outline the overall process by which Inline Services are created, deployed, and downloaded:
Create: Using Decision Studio, elements are configured to align with the business process into which Oracle RTD is to be integrated. Examples of elements are: Choice Groups, Performance Goals, Decisions, Informants, Advisors, Entities, and Data Sources.
Some elements allow the use of Java scriptlets in Logic and Asynchronous Logic attributes. For instance, an Informant element is shown in Figure 1-4. This element is named 'Call Begin.' In addition to the Description and the Advanced button, there are three tabs, each with a set of attributes for the Informant.
In the Logic tab of this 'Call Begin' Informant, we can write optional Java code to perform specific tasks, as shown in Figure 1-5.
As elements are created and saved, XML metadata is created in memory that describes the object.
Save: By saving the Inline Service in Decision Studio, the metadata is written to an Inline Service directory on the local file system, in XML files with the extension
*.sda. The metadata that follows is an example of the content saved for the Informant 'Call Begin', in a file called
<?xml version="1.0" encoding="UTF-8"?> <sda:RTAPType xmlns:sda="http://www.sigmadynamics.com/schema/sda" internalName="CallBegin" lastModifiedTime="1133228616435" name="Call Begin" schemaVersion="20050818" forcesSessionClose="false" order="1.0"> <sda:description>The Call Begin Informant starts the session after the customer's call enters the IVR system. Logic could be added here to pre- populate certain values (example: customer profile) that may be used later on.</sda:description> <sda:system ref="Ivr"/> <sda:sessionKey path="customer.customerId" relativeTo="session"/> <sda:requestMapper internalName="RequestMapper"> <sda:entity type="ApplicationSession" var="session"/> <sda:dataSource type="RequestDataSource" var="result"> <sda:arg> <sda:path localVarName="session" path="request" relativeTo="local"/> </sda:arg> </sda:dataSource> </sda:requestMapper> <sda:requestData internalName="RequestDataSource"> <sda:param internalName="message" dataType="object" objectType="com.sigmadynamics.client.wp.SDRequest"/> <sda:request> <sda:resultSet/> </sda:request> </sda:requestData> <sda:body> <sda:java order="0">/* Trigger data retrieval */
session().getCustomer().fill(); </sda:java> </sda:body> <sda:postOutputBody/> </sda:RTAPType>
The attributes that were assigned to the element in Decision Studio, such as Session Key and External System, are represented here. Note that the Java scriptlet is also inserted into the body of the XML file.
As Inline Service elements are added, configured, and saved, Decision Studio automatically generates the necessary Java code and compiles them into Java class files. Two classes of Java code are generated. The first set is the base Java files used by the Inline Service; these files are named the element id preceded by
GEN. For example, the CallBegin element will produce a file called
The second set of Java files is created to allow overriding of the generated code. These files are named the same as the element ID. For instance, the CallBegin element will produce a file named
CallBegin.java. Note that by default, the Java class
CallBegin simply extends the class
When the Inline Service is compiled, the generated code is used unless we specifically instruct that the override code be used. To do this, update and move the override Java file (for example,
CallBegin.java) from the generated source files folder:
to the override source files folder:
Decision Studio will now compile using the override Java file instead of the generated Java file.
The XML for any Inline Service object can be viewed with Decision Studio's built-in Text Editor. Right-click an Inline Service object in the Inline Service Explorer View, then select Text Editor from the Open With menu. To switch back to normal editor format, select the option Inline Service Editor.
Note that you should not edit the XML (
*.sda) files directly to modify the Inline Service objects; instead, use the corresponding Inline Service Editors.
Deploy: The Inline Service is deployed to Real-Time Decision Server using Decision Studio. The Management Service on the server receives the metadata and compiled Inline Service files, stores the Inline Service in the database, and loads the Inline Service into memory. The Inline Service can now be utilized to process requests, view reports, and so on.
View and Update: Reports and learnings are viewed through the browser-based Decision Center interface. Selected elements and parameters of your Inline Service can be updated from Decision Center. Updated Inline Services are not available for run-time use until they are redeployed.
Redeploy: If updates are made to the Inline Service in Decision Center, the changes can be made available for use by redeploying the Inline Service in Decision Center. The Management Service will regenerate all necessary metadata and Java files, recompile the Inline Service, store the Inline Service in the database, and load it in memory.
Download: Using Decision Studio, you can download a deployed Inline Service from the server. Downloading involves copying the Inline Service that resides in the database and placing all of the metadata, Java, and class files into a Decision Studio project on the hard drive. This is useful if you were not the original developer of the Inline Service and thus do not have the metadata files. Even if you had originally developed and deployed the Inline Service from Decision Studio, if your business process allows other users to make changes and redeploy the Inline Service through Decision Center, then to make additional changes to the Inline Service in Decision Studio, you would first need to download the latest version from the server.