9
REProxyBatch API Examples and Usage

This chapter provides examples of REProxyBatch API use. In some instances, we provide coding skeletons; in others, we describe an approach for solving certain kinds of problems using OP.

REProxyBatch API Basic Usage

The REBatchProxy methods described in Chapter 8 permit to write Java programs that generate recommendations.

Note: The RE Batch API classes are installed on the system where Oracle9iAS is installed. The tables that they use are installed on a different system (the system where Oracle9i is installed.) The following steps must be performed on the correct system.

To use REProxyBatch API calls, you must perform the following steps:

1. Create and deploy a package to the RE that you will use for recommendations.

2. Create an instance of REBatchProxy.

3. Create any required tables. (Alternatively, you can create the tables using SQL before you execute the program.)

4. Load customer profiles.

5. Execute the desired recommendation methods.

6. Purge the customer profiles that you loaded in step 4.

7. Destroy the database connection that you created in step 2.

You will now have a table containing the recommendations that you requested. You can use SQL to examine the table.

Code Sample: Recommend Top

The following code sample illustrates obtaining a recommendation:

// Create an instance of REProxyBatch

// Create customer table

// Load customer profiles

// Execute recommend_top

// Purge customer profiles loaded above

// Destroy the database connection held by REProxyBatch

Code Sample: Recommend Cross Sell

The following code sample illustrates obtaining cross-sell recommendations:

// Create an instance of REProxyBatch

// Create Items table

// Execute cross sell for items

// Destroy the database connection held by REProxyBatch

Recommendation Engine Usage

REBatchProxy requires at least one recommendation engine (RE) in at least one recommendation engine farm.

We recommend that the REs used for bulk recommendations not be used for any other purpose.

Note: If you try to deploy a package an RE while a batch program is running, the deployment will fail.

In general, you may want to use more than one RE to get satisfactory recommendation performance. Most applications will use multiple REs on different machines and subsequently different database instances.

Typically, for a given application, these REs will belong to the same RE farm. If a physical system has multiple processors, and the processors can be leveraged effectively by the database, the number of REs required for a given number of users can be reduced, perhaps even to one. See the administrator's guide for more information.

If your application has more than one RE available for use, it must determine which one to use. You can load different sets of customer profiles into different REs, generate appropriate recommendations, and them merge the recommendation tables, if desired.

Handling Multiple Currencies

OP stores currency data in the demographic table (for example, someone's income) as numbers; that is, OP does not store any kind of label. Both ten dollars (US) and ten pounds sterling (UK) are stored as "10".

There are several ways to ensure that currency data is interpreted correctly; the solution that you pick for your application depends on the way your application uses currency data.

• Include a country code in customer demographics.

  This solution allows the country to be taken into account, but it does not closely associate the value with the country.

• Convert all currencies to a common currency such as Euros or United States dollars.

  This solution permits you to compare individual currency values in a meaningful way (10 pounds sterling is more than $10 US) but does not permit you preserve the difference between data such as a salary of $30,000 US in the US, versus the same $30,000 US salary in Brazil. You need such information if, for example, you want to recommend items to highly remunerated individuals in both the US and Brazil; the salary in US dollars of highly remunerated individuals will vary considerably from country to country.

  This approach requires that you preprocess the data outside of OP before OP creates recommendations.

• Bin currency values according to the mean to get relative values that can be compared across countries.

  This solution would permit you, for example, to determine the highly remunerated individuals for a given country, but it requires that you determine and maintain the bin boundaries appropriately.

  This approach requires that you preprocess the data outside of OP before OP creates recommendations.

Using Demographic Data

The schema of the MTR_CUSTOMER table consists of 50 generic attributes that can be mapped to any column in the site database. In order to support all different data types, all attributes are of type VARCHAR. Therefore, the mapped columns should be converted to strings. In this release of OP, these mapped columns are treated as categorical or numeric only. If any of the mapped columns is a DATE attribute, it should be converted to a number using the TO_NUMBER function. The converted values can then be binned just like any other attribute by specifying the bin boundaries.

There is binning for demographic data. The attributes that are binned can be of type boolean. In OP, the bin numbers are represented internally as integers, but the actual values are passed back to the calling applications. That is, the Web application passes in the actual values and gets back actual values.

Handling Time-Based Items

For certain items, such as airline tickets, the price depends on when the item is purchased. For example, an airline ticket for a Boston to London flight has one price if it purchased 6 months before the date of the flight and a different price if it is purchased two days before the date of the flight.

If the Web application assigns the same item ID to all tickets for the same trip, regardless of when they are purchased, then the items should have different item types, such as "6 month advance", "2 day advance", etc. Alternatively, the application could define taxonomies on the items and get recommendations on the categories.

If the application assigns different item IDs to the same flight purchased at different times (so that a ticket purchased 6 months before the flight has a different ID from a ticket for the same flight purchased 2 days before the flight), all tickets can have the same item type. In this case recommending item IDs may not be appropriate; therefore, the application should define a taxonomy and request recommendations on the categories.