This chapter introduces system administration in Oracle Real-Time Decisions (Oracle RTD), describes components, typical system administration tasks, and available system administration tools. It also lists related topics covered in other books, and provides information about system requirements and certification.
This chapter contains the following topics:
Oracle Real-Time Decisions is a real-time decision engine software platform that consists of the following components:
Real-Time Decision Server
Figure 1-1 shows the main service and database components of Oracle Real-Time Decisions and the main runtime interactions between the components. To introduce and illustrate the basic Oracle Real-Time Decisions architecture concepts, the diagram shows a basic Oracle Real-Time Decisions topology, with one occurrence of each of the main services within a single Oracle Real-Time Decisions instance.
The main Oracle Real-Time Decisions services are:
Decision Service is responsible for tracking customers through Inline Service (ILS) sessions and responding to requests for decisions. It implements the decision logic, computes predictions and scores, and returns sorted results to the calling operational systems. It also creates learning records for model update.
A learning record contains session data and information about events that occurred during the session, for example, the fact that three offers were presented and one was accepted.
Learning Service is responsible for updating the models. It reads the learning records created by Decision Service, updates the models and periodically generates new optimized prediction models to be consumed by Decision Service. It also provides the data behind Decision Center reports.
Decision Center is the web-based application that is responsible for producing the Decision Center reports.
The Oracle RTD database is used to store model data and ILS metadata, in addition to the control and configuration data required for the Oracle Real-Time Decisions environment. An ILS is typically deployed to the database through Decision Studio (not shown in Figure 1-1).
The following provides an overview of the main runtime interactions between Oracle Real-Time Decisions components and Inline Services, and includes references to the processes annotated in Figure 1-1.
At runtime, ILS metadata is loaded into Decision Service memory - (A). Enterprise data and results of decision requests are stored in ILS session data (only entity data is highlighted in the diagram, but choice event data is also significant for model updates) - (B), (C).
Either during or at the end of ILS sessions, learning records are written out out to the database by Decision Service - (D).
Learning Service reads the learning records, and produces learning models - (E) - which are periodically written out ("persisted") to the database - (F). Learning Service also periodically creates the prediction models - (G) - that are the basis for many Oracle Real-Time Decisions decisions.
In more detail:
By default, Learning Service wakes up every 15 seconds, and checks to see if there are any new learning records in the database. If so, it retrieves the new records, typically in batches of 1000, and creates or updates the learning models in Learning Service memory.
Each model has a persistence interval, which controls how often learning models are written to the database. If the persistence interval is reached or exceeded since the last write-out to the database, Learning Service writes out the learning models and deletes the old learning records.
Learning records and learning models contain all the attributes (and their values) defined for the session. The key part of the learning process is selecting those attributes and values that are predictive, that is, which correlate with the output that you want to predict, and generating prediction models from them. In general, prediction models are much smaller than learning models, as only a small proportion of attributes are predictive.
You can select whether or not to generate a prediction model for an Oracle RTD model. If predictive modeling is selected, then another model parameter controls when to generate the prediction model. This parameter specifies what percentage of new learning records added to the model will prompt the creation of a new prediction model. The new prediction model replaces the old prediction model.
Prediction models are used by Decision Service as required for Oracle RTD decisions. Decision Service periodically checks if there are any new prediction models, and if so, loads them into its memory - (H). They are retained in Decision Service memory to service subsequent decisions.
Decision Center loads ILS metadata into Decision Service memory when users log in and select an ILS - (I). As required, Decision Center users may edit the ILS and redeploy it to the database. In general, Decision Center as a reporting tool interacts directly with the Learning Service to query the contents of learning models - (J).
Another Oracle RTD component, Batch Service, does not appear in Figure 1-1. For more information on Batch Service, which is currently co-located with Decision Service, see the section "Batch Framework Architecture" in Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.
The Time Window parameter also influences how models are processed and used. Time Window defines a time period, such as Week, Month, Quarter, Year, which is defined (and can be altered) at the model level.
In addition to the standard modeling processing described in this section, which is independent of time windows, learning models are archived at the end of each Time Window period. These model archives are the basis for Decision Center analytic reports, which show data within and across time periods.
Predictions are always made from the most recent data. In general, they derive from the learning records received so far in the current time window together with all the learning records in the previous time window. During the first time window, predictions are made from what is currently available.
Figure 1-2 shows the model processes as they occur in the initial time windows of a model, and shows how Oracle RTD creates new, overlapping instances of models as time passes.
Each model instance starts at the beginning of a time window, exists for two time windows, and, apart from the first model instance, overlaps with the previous model instance.
For each model instance, learning information accumulates during its first time window, at the end of which time a copy is saved as archive for reporting. At that point in time:
The model instance becomes the "primary model instance", and during its second time window it is used for predictions, while also continuing to learn
The next model instance is created, which serves as the "secondary model instance" and is only used for learning purposes until it becomes the primary model itself at the next time window boundary
Predictions derive from the learning records received so far in the current time window together with all the learning records in the previous time window.
Apart from the first time window, predictions only derive from a primary model instance, during the second time window of its existence.
In many production systems, Oracle RTD is installed and deployed in an Oracle RTD cluster. The following considerations apply to Oracle RTD clusters:
Learning Service is a cluster singleton, meaning that only one Learning Service instance is active at a time, although it is can be deployed to multiple Oracle RTD instances for availability, as in the following possible configuration:
In a cluster, Decision Center is typically deployed in the same Oracle RTD instances as Learning Service, because it needs to talk to Learning Service. Decision Center is not a singleton, however, so any instances not co-located with the active Learning Service can communicate with the active Learning Service.
In a cluster, Decision Center is typically deployed in a different Oracle RTD instance from Decision Service, to minimize the performance and memory impact of Decision Center on Decision Service.
For more information on Oracle RTD component cluster configurations, see the section "High Availability for Oracle Real-Time Decisions" in Oracle Fusion Middleware High Availability Guide.
Oracle Real-Time Decisions system administration is described in the following sections:
Table 1-1 shows the typical Oracle RTD system administration tasks that you perform, and indicates where to find related information.
|System Administration Task||More Information|
Viewing Oracle Real-Time Decisions status
Starting and stopping Oracle Real-Time Decisions
Configuring Oracle Real-Time Decisions
Securing the system
Diagnosing problems and resolving issues
Other administration topics that may be useful to Oracle Real-Time Decisions administrators are covered in other Oracle manuals. For more information, see Section 1.3, "Topics of Interest in Other Guides."
Figure 1-3 illustrates the Oracle Business Intelligence components, which include Oracle Real-Time Decisions, that share a common administration framework. Oracle Real-Time Decisions (shown in the diagram as RTD) is an Oracle Fusion Middleware Java component which is deployed as one or more Java EE applications and a set of resources.
For more information, see Section 1.2.3, "Oracle Real-Time Decisions Configured in a WebLogic Domain" and Oracle Fusion Middleware Administrator's Guide.
Oracle Real-Time Decisions is configured in a WebLogic domain which contains the Java components required to run and administer Oracle Real-Time Decisions.
The rest of this section introduces and includes brief descriptions of the main components of WebLogic domains. For more detailed descriptions, see the chapter "Understanding Oracle Fusion Middleware Concepts" in Oracle Fusion Middleware Administrator's Guide.
The Administration Server is a standard JMX MBean container that provides local and centralized management of the domain where Oracle RTD is deployed.
The Administration Server is hosted in the Middleware Home which is part of the WebLogic domain, and contains the Oracle WebLogic Server Administration Console.
The Administration Server can access functions contained within Managed Servers on remote physical machines in order to achieve centralized configuration and provisioning of all the components within the domain where Oracle RTD is deployed.
The main tools to interact with the Administration Server are the following:
Oracle WebLogic Server Administration Console
Oracle WebLogic Scripting Tool (WLST)
For more information, see Section 1.2.4, "Which System Administration Tools Enable You to Manage Oracle Real-Time Decisions?".
A Managed server is an individual JEE application container hosted within each WebLogic instance. It provides local management functions on individual machines for Java and system components contained within the local Middleware home. It refers to the Administration Server for all of its configuration and deployment information.
Oracle WebLogic Server includes Node Manager, a daemon process that provides remote server start, stop and restart capabilities when processes become unresponsive or terminate unexpectedly.
For more information, see Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
The following system administration tools enable you to manage Oracle RTD:
Oracle Enterprise Manager Fusion Middleware Control is a browser-based tool that enables you to monitor and configure Oracle Fusion Middleware components. You can deploy applications, manage security, and create Oracle Fusion Middleware clusters. For more information, see Section 2.1, "Using Fusion Middleware Control to Manage Oracle Real-Time Decisions."
Oracle WebLogic Server is a Java EE application server that supports the deployment of JEE Java components in a secure, highly available, and scalable environment.
You use the Oracle WebLogic Server Administration Console to manage and monitor a WebLogic Server domain. For more information, see Section 2.2, "Using Oracle WebLogic Server Administration Console to Manage Oracle Real-Time Decisions."
For more information about Oracle WebLogic Server, see Oracle Technology Network on
The Oracle Weblogic Scripting Tool (WLST) is a command-line scripting environment that you can use to administer Oracle Real-Time Decisions. The WLST scripting environment is based on the Java scripting interpreter Jython. You can use this tool interactively on the command line; in batch scripts supplied in a file (Script Mode, where scripts invoke a sequence of WLST commands without requiring your input), or embedded in Java code. You can extend the WebLogic scripting language by following the Jython language syntax.
For more information, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Some topics that may be of interest to system administrators are covered in other guides. Table 1-2 lists these topics, and indicates where to go for more information.
|Topic||Where To Go For More Information|
Moving from a test to a production system
General administration under Oracle Fusion Middleware
Upgrading from Oracle RTD Version 220.127.116.11
Backup and recovery
Refer to the system requirements and certification documentation for information about hardware and software requirements, platforms, databases, and other information. Both of these documents are available on Oracle Technology Network (OTN).
The system requirements document covers information such as hardware and software requirements, minimum disk space and memory requirements, and required system libraries, packages, or patches:
The certification document covers supported installation types, platforms, operating systems, databases, JDKs, and third-party products: