|
Oracle® Application Server Personalization Programmer's Guide
10g Release 2 (10.1.2) B14051-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Personalization Programmer's Guide
10g Release 2 (10.1.2) B14051-01 |
|
|
Previous |
Next |
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 OracleAS Personalization.
The REBatchProxy methods described in Chapter 8 permit you to write Java programs that generate recommendations.
|
Note: The RE Batch API classes are installed on the system where Oracle Application Server 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:
Create and deploy a package to the RE that you will use for recommendations.
Create an instance of REBatchProxy.
Create any required tables. (Alternatively, you can create the tables using SQL before you execute the program.)
Load customer profiles.
Execute the desired recommendation methods.
Purge the customer profiles that you loaded in step 4.
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.
Refer to Appendix B, "REProxyBatch Sample Program" for code samples on how to obtain recommend top and cross-sell recommendations.
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.
