Oracle Real Time Decisions

Oracle Real Time Decisions – Interactive Business Intelligence

Oracle next generation BI initiative may be Oracle Real Time Decisions, in this blog post I would like to share an initial view point & how this tool could be used in Enterprise Information

Management basically Line orders & Online customer service initiatives.

Oracle RTD is an apt combination of Business Predictive Analytic’s, Business Rules & Ad-hoc Business Keys.

Oracle Real-Time Decisions RTD provides a manageable infrastructure for the formation of the recommendations in the interaction with the user. Oracle RTD is working in multi-channel real time.

Oracle RTD applies the predictive analytic’s model and business rules for the issuance of the best advice in terms of business goals that may conflict with each other (for example: to achieve maximum profit, to keep the client persistent with us, customer churn propensity).

The process of issuing recommendations to RTD is inextricably linked with the process of

feedback.

This approach provides a much higher efficiency than systems based on rules, as well as the traditional models for forecasting.

Oracle Real-Time Decisions helps companies maximize the surface area of the business processes and

client:

Doing the work of dialogue with the client more intelligent, producing relevant, personalized

recommendations of multi-real-time.

Allowing a self-adjusting (with closed-loop self-tuning) business processes, integrating business intelligence (BI) in the process of interaction.

The skeletal parts of ORTD are :

Oracle Real-Time Decisions Server

Oracle Real-Time Decisions Server is a scalable J2EE transactional applications for management

decision-making in real time. It optimizes business processes and interaction with the client

embedding intelligent analysis of closed-loop processes online, in the contact center, point of sales or on multiple channels simultaneously.

In the core of Oracle Real-Time Decisions is the infrastructure of the decision (Decision

Framework), which allows business users to implement and deploy a “targeted” (differentiated and targeted) corporate “solutions”.

The key Selling points of Oracle Real-Time Decisions are:

Possibility to use several target parameters determining the effectiveness of the decision

Oracle RTD supports arbitration analysis of several potentially conflicting business goals in a way that interested parties can control the logic of issuing the recommendations, specifying the relative weights for business purposes (for example, to maximize clicks, revenue maximization, maximize the time spent on the site (site stickiness), minimizing failures (departures from the

site), minimizing the cost, etc.)

Automated predictive modeling to optimize solutions

Oracle RTD automatically handles the lifecycle of thousands of predictive models, allowing the analyst to implement optimized and customized solutions that take into account any interaction with the client. The core of

Oracle RTD Server is its machine learning models that automatically adjust and adapt, depending on the responses during the interaction.

Business rules for the control of decisions

but the mechanism of forecasting infrastructure decision-making gives Oracle RTD provides

business intelligence is a powerful but easy to use editor for the implementation of logic based on rules. This allows a business analyst to fully control the business logic which management decisions.

Batch

Allows you to use the mechanism of action Oracle RTD for offline data processing ( eg, the formation of intellectual guidance for conducting marketing campaigns via e-mail, training of predictive models based on historical data, etc.)

Oracle Real-Time Decisions Server is a scalable, transactional server to run the logic of decision making, Oracle RTD Server is created with the use of multi-tier, service-oriented architecture and runs on application servers, which supports industry-standard J2EE. Oracle RTD Server provides the performance, scalability and reliability needed for today’s businesses.

Key features of Oracle Real-Time Decisions Server:

Performance. In the architecture of Oracle RTD laid high performance. In particular, the metadata Oracle RTD is compiled into Java code, which enables decision logic to work on the processor speed. In addition, a distributed infrastructure forecasting is optimized for use in real time. With Oracle RTD in making the only true solution is possible to analyze thousands of options, keeping the response time of less than 100 milliseconds.

Scalability. Oracle RTD was created using the J2EE infrastructure. Its use allows to deploy Oracle RTD on J2EE cluster, ie horizontal scale. Besides using vertical scaling SMP-machines (multiprocessor).

Easy integration. Oracle RTD is very easy to integrate into multi-tier, client-server and mainframe systems. Oracle RTD publishes a Web service integration points with a guaranteed level of service in order to expand the business processes of the company means making decisions in real time. This approach is based on loosely coupled components, minimizes the burden on IT and reduces the time for the introduction of RTD.

Open architecture. Using Oracle RTD can use existing data, evaluate, model and function as elements of infrastructure decision-making.

Foci of Decision (Decision Center)

Center of decision-making is a component of Oracle Real-Time Decisions Server, which is used by

business users. It enables business analysts to analyze the effectiveness and formed the “Decisions”. Center of decision-making provides a powerful analytical framework for business users, making it possible to understand the drivers (drivers) of the optimization process, identified by self-learning models.

Center decision-making provides 2 types of reports:

Reports to assess the effectiveness of the “Decisions” on time and on channels. Their mission to provide understanding of the relative effectiveness of various “options” ( “choices”)

The reports, aimed at identifying the “drivers” that affect the effectiveness of the “Decisions”.

Self-learning predictive models Oracle RTD are to be interpreted by analysts and business automatically identify the attributes of data, correlate with the events.

(Decision Studio)

Studio decision-making – is a component of Oracle Real-Time Decisions Server, an interface designed for use by a technical specialist. It allows a technician to configure the applications Oracle RTD ( Inline Services) and integrate them into the target environment. Technical users define Oracle RTD connection with all external systems, including data sources and target business processes. In addition, the studio allows you to adjust the model parameters and business rules that form the logic

of decision-making in the In line Service. Decision Studio is a plug-in to Eclipse.

Key features of Decision Studio:

Works on the basis of metadata – metadata for Oracle RTD are stored in XML files, which are edited using the visual editor plug-in Eclipse. Using Eclipse – one of the most powerful development tools – Oracle RTD inherits all the features available in Eclipse: collaboration,version control, workflow, and debugging tools

Extensible Java – using Java as a language extension Oracle RTD not only gets its performance, but also connectivity to other systems in the company. Any system that is available using Java to access Oracle RTD.

Composite “Decisions” – Oracle RTD is designed with the understanding that the “building blocks” of the “Decisions” will be integrated with the objects stored and managed outside Oracle RTD. Thus, “Decisions” Oracle RTD can be formed from a heterogeneous set of external objects ( eg, the recommended content). This enables applications such as Trade Promotion Management TPM, Campaign management, CRM, transactional and other applications to use the functional Real-Time Decisions, without requiring complex re-engineering processes.

OBIEE Caching Configuration

OBIEE Caching Best Practices

One of my recent discussions with a colleague on the caching strategy for OBIEE resulted in the following Best practices, Oracle BI Server is an Intelligent Query Engine that stores database hits in a cache file, This cache file is stored on the BI server.

OBIEE Architectural Best Practice feature is to implement the caching mechanism by using the following methodology where in the configuration tags can be set in optimal fashion as follows:

• Enable: turns caching on/off

• Data_Storage_Paths: defines location to store result files

• Metadata_File: defines location for cache metadata file

• Replace_Algorithm: for discarding entries if cache full

• Buffer_Pool_Size: buffer for caching metadata file

• Max_Rows_Per_Cache_Entry: upper limit on rows in result

• Max_Cache_Entry_Size: upper limit on size (#rows*#bytes/row)

• Max_Cache_Entries: upper limit on #of cached queries

The Following is an in detail Architectural configuration changes that can be implemented for OBIEE Caching

1. Parameter: Enable

• Turns caching on/off

Best Practice

Set to YES if you want caching

1. Parameter: Data_Storage_Paths

• Defines the directory or directories to store cached result files

• Provide location and capacity

  • DATA_STORAGE_PATHS = “d:\OracleBIData\nQSCache” 500 MB

• Least-recently-used cache is purged if full capacity

Best practice

• • use dedicated drive(s): performance and reliability

  • use local disk (not a file share). (Not enforced)

  • capacity should be significantly larger than value of Max_Cache_Entry_Size

Caveats to be kept in mind

• • Disk space must exist (or bad things will happen)

  • Capacity of each location must not exceed 4 GB (2 GB before 7.7)

1. Parameter: Replace_Algorithm

Algorithm used to purge cache entries when the cache is full

“Full” is either:

1. 1. Max_Cache_Entries have been created

   2. Less than Max_Cache_Entry_Size space is available

Removes cache entry that has not been accessed for longest time – not necessarily the oldest “created” cache item

Only choice is LRU (least-recently-used)

1. Parameter: Buffer_Pool_Size

• Defines the amount of memory for caching the cache metadata file.

• Parameter does not affect correctness/behavior of cache – purely a performance setting

Best practice

• Don’t change the default value. No/limited performance gains possible.

1. Parameter: Max_Rows_Per_Cache_Entry

• Defines upper bound on number of rows in a cached result set

• Prevent large or “runaway” queries from consuming too much cache

• Query will run to completion, but if limit exceeded result will not be added to cache – event is not logged

• Set value to 0 if no limit is desired

• Very large cache files are inefficient

  • stored in single file on disk

  • No indexes – full sequential scan to access

Best practice

• • Define a non-zero value (less than 1,000,000 if possible)

  • Max_Cache_Entry_Size is best place to define space limit

1. Parameter: Max_Cache_Entry_Size

• Defines limit on size (#of bytes) of a cache entry

• Used to prevent large cache entries from being created. Query will not be cached if exceeds this limit. No logging of exceeding limit.

• Size: #of rows times #of bytes/row

• #of bytes per row calculation:

  • Unicode expansion (2x or 4x multiplier for char and varchar columns)

  • Column alignment overheads

  • Null value representation overhead

• Cache is purged until Max_Cache_Entry_Size bytes are available

Best practice

• • Set value to at most 10% of cache capacity (of smallest cache directory)

  • More effective limit than Max_Rows_Per_Cache_Entry or Max_Cache_Entries

Caveats

• • Default value (1 MB) is fairly small. Many queries will hit this limit.

ABC’s of Application Integration Architecture

This is an excellent article on oracles next generation Application Integration Architecture it gives us a broad overview of AIA.

http://www.tusc.com/oracle/collateral/ebs/WP-ABCs-of-AIA.pdf

How to Improve Data Quality In a Tight Budget

This is an excellent article linnk by David Loshin discussing on How to improve Data quality in a tight budget scenario to maximize ROI:

http://searchdatamanagement.techtarget.com/generic/0,295582,sid91_gci1363080_mem1,00.html?track=NL-520&ad=722696&Offer=mn_eh082609DTMGUNSC_DQguide&asrc=EM_USC_9063881

How to Secure Oracle BI Adhoc Analytics / Answers

• This Question pops up on the OTN forum on how to secure Oracle BI Adhoc Analytics & Answers functionality, My recent project was an integration warehouse effort and had more of adhoc analytic’s application approach.

• This was my approach on this

• Create an OBI web catalog group named ‘All Functional Area Request Developers’ using ‘Manage Presentation Catalog Groups and Users’. This role will only exist in Presentation Services and be used as a way to consolidate all the individual roles for each functional area.

• This name has spaces and is mixed case so that it is distinguishable from the roles that are synchronized with the warehouse, similar to the Presentation Server Administrators group.

• Create a role web catalog group for each functional area. The role should be named ‘BI_REQUEST_DEVELOPER_XXXXXX_RL’ where XXXXXX should be descriptive of the group using answers. The descriptive part (XXXXXX) may be less than six characters, but not more.

• Each of the functional area roles must now be added to the ‘All Functional Area Request Developers’ web catalog group using ‘Manage Presentation Catalog Groups and Users’.

• Remove privilege from Subject Area for Everyone. Grant read access to each Subject Area in Answers to the appropriate functional area roles. Dashboard viewers do not need access to the Subject Area.

• Grant Answers privilege to the ‘All Functional Area Request Developers’ web catalog group.

• Create a folder:/shared/Functional Area Requests

1. 1. Permissions on this folder:All Functional Area Request Developers – Traverse or Read?, Dashboard Developers – Read, Presentation Server Administrators – Full Control

2. Create sub-folder for each functional area named: XXXXXX Requests

   1. Permissions on this folder: BI_REQUEST_DEVELOPER_XXXXXX_RL – Create/Modify, Dashboard Developers – Read, Presentation Server Administrators – Full Contro

   In addition to this we can also come up with an idea to create a role based connection pool to the database to suffice this Business requirement.

Apt Properties for Oracle BI Dataase

This is an excellent link that gives us the apt properties for the Oracle data base for an OBIEE implementation

http://download.oracle.com/docs/cd/E12104_01/books/AnyInstAdm/AnyInstAdmPreInstall7.html#wp1066442

Modeling Tools Vs Spreadsheets

This  is a great article from TDWI discussing the pros & cons of using a Modeling tool versus a spread sheet and when the business needs to go for the Modeling tool.

http://www.thttp://www.tdwi.org/News/display.aspx?ID=9567dwi.org/News/display.aspx?ID=9567

Sun Microsystem OBIEE Strategy

View more documents Raj Guttikonda.

Articles

http://www.enzeecommunity.com/message/2822

OBIEE Datawarehouse Design Process Iterations

OBIEE Data-warehousing Design Process Inception Phase

Designing the Data Warehouse effort:

The Best practice iterations to design a Data warehouse can be as follows

1. Configuring an Oracle or DB2 or MS Sql Server database for use as a data warehouse

2. Designing the Warehouse if the Warehouse supports more than one LOB the Data Modeler can come up with a Physical warehouse design based on Conformed Bus Architecture with conformed dimensions & Conformed facts which allow the IT to reuse the Data sets across the Business.

3. Managing Schema objects such as Tables, Concurrent programs, Sequences, Schema, Disks, Views, Indexes & Materialized Views

4. Managing & Maintaining the User authentication its a DBA responsibility

5. Developing routines, Streams, ETL Process using an ETL tool or a Push Pull concurrent program code to Leverage operational data resemblance

6. Managing change data capture using tools like CA -7 or Siebel DAC & more

7. Creating Metadata repository, BMM Layer Meta data repository, User Authentication & Authorization Strategy through OBIEE or LDAP or Data base authentication.

8. Backing up the data base & Performing recovery & leveraging fault tolerance

9. Monitoring data-warehouse’s performance using OBIEE tool caching & performance tuning strategies

OBIEE Data-warehousing Design Process Inception Phase

Designing the Data Warehouse effort:

The Best practice iterations to design a Data warehouse can be as follows

1. Configuring an Oracle or DB2 or MS Sql Server database for use as a data warehouse

2. Designing the Warehouse if the Warehouse supports more than one LOB the Data Modeler can come up with a Physical warehouse design based on Conformed Bus Architecture with conformed dimensions & Conformed facts which allow the IT to reuse the Data sets across the Business.

3. Managing Schema objects such as Tables, Concurrent programs, Sequences, Schemas, Disks, Views, Indexes & Materialized Views

4. Managing & Maintaining the User authentication its a DBA responsibility

5. Developing routines, Streams, ETL Process using an ETL tool or a Push Pull concurrent program code to Leverage operational data resemblance

6. Managing change data capture using tools like CA -7 or Siebel DAC & more

7. Creating Metadata repository, BMM Layer Meta data repository, User Authentication & Authorization Strategy through OBIEE or LDAP or Data base authentication.

8. Backing up the data base & Performing recovery & leveraging fault tolerance

9. Monitoring data-warehouse’s performance using OBIEE tool caching & performance tuning strategies