Creating a Real-Time Decisions Project : Day 2

In yesterday's posting, I set the scene for an Oracle Real-Time Decisions project that I'm going to integrate into the Oracle SOA Suite Order Bookings BPEL process. At present, the Order Bookings process allocates manufacturing jobs based on who provided the lowest quote; in the demo I'm going to build, jobs will be allocated based on a predictive model that takes into account the customer and their order, information about the context of the order, directives from me on what my current business priorities are, and comes up with a manufacturer recommendation that is mostly likely to help me meet my business goals.

Before diving in though, it's worth taking a few moments to think about some of the key concepts in Oracle Real-Time Decisions.

At the most basic level, what you build in Real-Time Decisions is an "Inline Service", a process that you can call using in and out parameters that makes a decision for you. The inline process takes your input parameters, runs them past it's model and comes up with a decision, based on various weightings that you give to your various business priorities.

At the end of the process, you feed back to the Inline Service the actual choice that the customer made, so that Real-Time Decisions can fine tune it's predictive model in order to come up with more and more appropriate decisions, of offers, for the customer. The Inline Service can either be called via a Java client interface, or we can register it as a Web Service and call it from, for example, a BPEL process.

Within a Real-Time Decisions project, there are five main "elements" that you need to work with:

1. Entities, the main "actors" in a system. Entities have properties and are effectively the variables that you populate at the start of the process, read details from as needed and the load up prior to passing back the decision to the calling application.
2. Performance Goals are the key performance indicators that the the Inline Service tracks and optimizes.
3. Choices, the possible process outcomes, such as as offers, agents, service providers and so on. In our example, the choices will be the various manufacturers that can be used to deliver the order - Select Manufacturer, Rapid Manufacturer, and some others that we'll come up with.
4. Models and Rules are the predictive models that RTD builds up, and the rules that you define as part of the inline service definition, that are used to work out what score each particular choice attracts, and
5. Decisions take the output of the model, apply weightings based on your performance goals and come up with the most appropriate decision.

Another key concept in RTD is "informants". Informants are the interfaces into the Inline Service, and provide, for example, feedback on what the customer's call is actually about, whether they accept an offer, whether they take up the offer some time down the line and so on. All of the above elements, plus the informants and the predictive models, are built up using a tool called Oracle RTD Studio, a Java GUI based on the Eclipse framework that builds up an RTD project in much the same way that you'd build an OWB project, or a Java application.

Tomorrow, we take the Order Bookings process and pull out from it the RTD elements and potential informants that we'll use in the project.