11 Notification Engine

11.1.1 Architecture

Notification Engine is an event server which performs the following tasks:

• Evaluates incoming events to find the set of users interested in a specific event

• Invokes an application to generate the relevant content for the event

• Delivers messages to users with the generated content.

Events are triggered when there are changes in the underlying data source; the data sources provide certain data for evaluation of this event.

Figure 11-2 Notification Architecture

Description of "Figure 11-2 Notification Architecture"

The notification mechanism consists of four layers:

• Event Generator Layer, of which OracleAS Wireless has 3 types:

  • Data Feeder—generate value events by providing a stream of data to the notification engine at specified intervals from a content source. The data feeder takes an input parameter (provided by the user), and returns a row of data for the specified input parameter. Each column in this row is considered as an output parameter by the notification engine. For example, a stock feed can retrieve stock price, P/E and price change for a given stock symbol.

  • Timer—generates time events at user-specified intervals.

  • Location Event Agent—generates location events when user-specified conditions are validated.

• Event Handler Layer—each time an event is received from the corresponding event generator, this component finds a set of users who are interested in this specific event; it derives a set of users whose conditions are met by the incoming data. For example, when a data feeder generates an event by pushing stock prices for the stock ORCL, a value event handler finds users who are interested in ORCL, and whose value conditions are met with the current stock price.

• Service Invoker Layer—for users whose conditions are met, the appropriate application is invoked by OracleAS Wireless Tools to retrieve content that will be pushed to the end-user as a notification message. This process involves passing available data (which is provided by the data feeder) to the application, creating a user session, authentication and finally retrieving the content.

• Message Dispatcher delivers the generated content to an end-user through the XMS layer.

11.1.2 Key Features

The key features of the Notification System are:

• Actionable Notifications—OracleAS Wireless enhances notifications by enabling user interaction. Not only can users can receive notification messages, but they can also reply to these messages to perform further processing. For example, users can reply to a stock notification with an order to sell their stocks. For more information about actionable notifications, see Chapter 10, "Creating Messaging Applications".

• Flexible Message Content—Since notification message content is generated through application invocation, the notification engine provides the flexibility to generate any type of notification. This also enables executing specific application logic while generating content. Actionable notifications can be used to provide further processing for this application logic (that is, sending a message with a confirmation request to sell the stocks when Oracle stock reaches a certain value).

• Location Support—You can specify a location condition with a set of location criteria, expiration time and evaluation mode. Location criteria is defined by region (system region, custom region or user-defined region), target (OracleAS Wireless user, community or mobile device) and type (IN or OUT). The relation between specified criteria is defaulted to AND by the location server, meaning this condition will be satisfied only when all criteria are met. Evaluation mode for a location condition can be evaluate once, for which the location condition will not be evaluated after the first time it is satisfied, or evaluate until the expiration time.

• Time Based Notifications—Use in conjunction with value based predicates. For this case, notification messages can be sent when either both time-based and data-based predicates are met, or when at least one of them is met.

• Personalized Content versus Generic Content—By invoking a master application, the notification engine can provide more customizable content. However, due to the fact that application invocation is a relatively expensive operation (compared to processing a message template), this feature may slow down the notification processing, and degrade engine performance. To overcome this challenge, the notification engine can invoke the target application once for a specific event for content that is not user-specific, and share the content between all users who are interested in this event and content.

• Message Templates—Instead of creating a master application for content generation, you provide a message template with variables, which will be substituted with existing data at runtime. Since the notification engine generates messages by invoking an application, a default master application can be generated by the notification engine, and parameter-mapping will also be handled by the notification engine.

• Comprehensive Time Predicates:

  • Activation and expiration dates—users can specify when to activate a specific notification, and provide a date for expiration.

  • Suspend start and end dates—users can choose to suspend a specific notification for a given period (for example: when the user is on vacation).

  • Specific date notifications—users can pick a specific date to deliver a one time notification (that is, sending flight information on user's departure date/time).

  • Repetitive notifications—users can request repetitive notifications in a specific time period. For example, a user can subscribe to a stock notification to receive stock quotes every 30 minutes between 1:00PM and 4:00PM.

  • Notification times can be specified in <Hour:Minute> granularity with frequencies as Daily, Weekdays and Weekends.

  • User time zones (provided by the user profile) play an important role in time predicates. Every user-specified notification time is considered to be in that user's time zone. For example, if two users subscribe to a notification to receive stock quotes at 9:00AM with one having GMT and other PST as their time zones in their profiles, the user who has GMT in his profile will get the notification 8 hours before the second user.

• Device Support—users can pick a device for delivering notification messages. Since it is possible to set a maximum for the number of notifications that can be sent to a device on a daily basis, users can also specify what to do in case this maximum is reached. The alternatives are: send rest of the notifications to an alternate device, or ignore them.

• Presence-aware device selection—If users do not specify a device for notification delivery, OracleAS Wireless will pick a device using contact rules defined by the user and the optimum channel. For more information about Contact Rules, see Chapter 6, "Wireless Customization Portal".

• Data Based Condition relation—Notifications can be defined to contain more than one condition, for example: price is greater than 20 and/or change is less than 10%. For multiple conditions, it is possible to specify a relation type between these conditions. Relation can be either AND or OR; mixed relations are not supported.

11.1.3 Backward Compatibility

There have been significant changes in the notification engine since the previous release. The most important architectural difference is the way content is generated; now, content is retrieved from an application instead of processing a message template. Due to this paradigm shift, it is not possible for the new engine to process old type of notifications (referred to as alerts, alert services, and master alert services in previous Wireless releases).

To overcome this backward compatibility problem, administrators can create separate notification processes. Notifications created by the two different versions will be intact. The new engine will only handle the new type of notifications; new features will not be available for notifications created using the older version.

Since OracleAS Wireless Notification Engine supports message template specification (as explained in Section 11.1.2, "Key Features"), it is easy to migrate alert services (that is, notification applications) created with the old version into the new version; tools to automate this process are provided. After migration, migrated alerts will be handled by the new engine, then you can use new features included in this version.

11.2.1 Defining a Master Notification Application

This section describes how to define a master notification application.

<?xml version = "1.0" encoding = "UTF-8" standalone="yes" ?>
<SimpleResult>
  <SimpleContainer>
    <SimpleText>
      <SimpleTitle>OracleAS Wireless</SimpleTitle>
      <SimpleTextItem>Sample Notification: price: &price; and change: &change; for stock: &sym;</SimpleTextItem>
    </SimpleText>
  </SimpleContainer>
</SimpleResult>

MetaLocator m = MetaLocator.getInstance();
ModelFactory f = m.getModelFactory();
ModelServices s = m.getModelServices();
 
//Locate the data feed that will be used by this notification
DataFeeder df = s.lookupDataFeeder("StockFeed")
 
//Create a master notification with timebase enabled.
//Note that, new master notification interface is oracle.panama.mobilealert.MasterAlertService
MasterAlertService mAS = null;
mAS = f.createMobileMasterAlertService("StockNotification", true, "Stock Master Notification", df);
 
//Set the condition relation type to "AND"
mAS.setConditionRelationType(MasterAlertService.RELATION_AND);
 
//Set time based typed to strictly time based
mAS.setTimeBasedType(true);
 
//Enable Location based support
mAS.enableLocationBaseAlert(true);
 
StringBuffer msgTemplate = new StringBuffer("<?xml version = \"1.0\" encoding 
= \"UTF-8\" standalone=\"yes\" ?>"); 
msgTemplate.append("<SimpleResult>"); 
msgTemplate.append("<SimpleContainer>"); 
msgTemplate.append("<SimpleText>"); 
msgTemplate.append("<SimpleTitle>OracleAS Wireless</SimpleTitle>"); 
msgTemplate.append("<SimpleTextItem>Sample Notification: price: &price; and 
change: &change; for stock: &sym;</SimpleTextItem>"); 
msgTemplate.append("</SimpleText>"); 
msgTemplate.append("</SimpleContainer>"); 
msgTemplate.append("</SimpleResult>"); 
 
//Provide the default message template 
//that can be used with default notification master service
mAS.setFormattedXMLTemplate(msgTemplate.toString());
 
//add conditions with default valuesto this notifications, i.e. if "price > 10 "
 
AlertConditionType cType1 = s.getMobileAlertConditionTypeByName("GT");
FeedMetaData fmdPrice = df.getOutputParameter("price");
mAS.addConditionDefinition("PriceMax", fmdPrice, cType1, "23");
 
AlertConditionType cType2 = s.getMobileAlertConditionTypeByName("GT");
FeedMetaData fmdChange = df.getOutputParameter("Change");
mAS.addConditionDefinition("ChangeMax", fmdChange, cType2, "10");
 
//Notification object does not use the persistent store/wireless caching
//Any create/update operation has to be committed with the save
mAS.save();

11.2.2 Mapping a Master Notification Application to a Master Application

Application invocation is the recommended way for generating notification content. Designers should map master notification applications to master applications that will be used for generating notification content. In some cases, applications may need to have access to some or all of the input or output parameters of the master notification application, in order to perform further processing. For example, a stock price watch notification can trigger a stock selling application to sell the stocks in case of a significant price drop. In this case, the stock selling application must access the stock ticker so that it will know what to sell. To provide this information, application developers would map master notification application input and output parameter(s) to the master application input parameter(s).

Since the Notification Engine is a generic event server that can handle various event generators and invoke multiple applications, it is possible to create many-to-many mappings between master notification applications and master applications. Simply put, a particular master notification application can be mapped to many master applications such as: stock trade master application, or stock news master application. For example, a stock notification engine can invoke a master application that will sell the stocks for user A, and this engine can also be used to invoke a master application that sends the latest news about that particular stock for user B. The same engine can be used to deliver a simple message template for user C. Likewise, a stock trade master application can be invoked by a master notification application that checks if the stock has reached a certain value at some time (time and value-based) and/or another master notification application that is fired upon a significant price change (value-based); for example, a 10% price drop.

OracleAS Wireless Tools can only manage 1-to-n mappings due to user interface constraints (same master notification application can be mapped to many master applications). However, it is possible to accomplish m-to-n mapping using notification APIs.

As mentioned in Section 11.1.2, "Key Features", the notification engine can generate personalized content by invoking the target application separately for each user, or invoke it once per event and share the content between all users who are interested in that event. When application designers create a mapping, they must choose the proper content generation type depending on user requirements.

//Locate the existing master notification service
MasterAlertService mAS = s.lookupMobileMasterAlertService("StockNotification");
 
//Locate the existing stock trade master service
MasterService masterService = s.lookupMasterService("/master/examples/StockTradeMasterService");
 
//Create the mapping definition between the notification service and master service
MAlertServiceMapping map = mAS.createMapping(masterService, "StockNotificationMapping");
 
//Retrieve input arguments for the master service
Arguments args = masterService.getInputArguments();
InputArgument inpArgTicker = args.getInput("symbol");
InputArgument inpArgPrice  = args.getInput("price");
 
//Retrieve notification parameters (including input and output)
AlertParameterMeta[] alertParams = mAS.getParameters(); //returns symbol, price
 
//Map notification master service parameter "symbol" to stock trade input argument "ticker"
map.addChainParameter(alertParams[0], inpArgTicker);
 
//Map notification master service parameter "price" to stock trade input argument "price"
map.addChainParameter(alertParams[1], inpArgPrice);
 
//This invocation has to be performed in "personalized content mode", for each user separately
map.setInvocationType(false);
 
//Commit changes
mAS.save();

//Locate the existing master notification service
MasterAlertService mAS = s.lookupMobileMasterAlertService("StockNotification");
 
//Create a simple master service
MasterService templateMasterService = f.createMasterService("StockInfo", s.lookupUser("orcladmin"), s.lookupAdapter("HttpAdapter"), s.lookupFolder("/master/examples"));
 
//Parameter mappings will be handled by the createTemplateMapping method
//this method will also modify the provided master service to use default template processor
mAS.createTemplateMapping(templateMasterService);
 
//Commit changes
mAS.save();

11.2.3 Subscription

After notification creation, mapping the notification to a application and publishing it as an application, users can start subscribing to this notification-enabled application by using OracleAS Wireless Portal. The reason for subscribing to a application instead of notification is that end-users care about the content that is generated, but not how it is generated. Since the content is generated by an application that can be invoked by any notification, they do not and should not care about the underlying infrastructure.

As the notification creation process defines the structure and metadata by specifying predicate information, users must provide the required parameter values for each predicate in the subscription step. For each predicate type, users should set the following information:

• Data Based—Input Parameter(s) required by the data feeder, and triggering condition parameters.

• Time Based:

  • Notification Frequency—Possible values are daily, weekday, weekend and once.

  • When to receive notifications—This can be a specific time (with hour and minute information), or a time period in a day. Time periods require a start time (hour and minute), end time (hour/minute) and interval. For example, between 3:00PM and 5:00PM every 15 minutes.

  • Blackout Period—During the specified blackout period (which is between two dates), users will not receive any notifications. This can be useful for cases in which the user is on holiday.

  • Expiration Date—After the specified date, users will not receive any notification. Due to UI complexity issues, OracleAS Wireless Portal does not provide support for the expiration date.

• Location Based—Location predicates are based on location conditions objects. Location condition consists of one or more location criteria, each of which are defined by a target, region and criteria (movement) type. Target is what the location server will track, which can be a user, user group or mobile phone number. Criteria type is the type of movement the location server should monitor, such as when the user moves into a region, or moves out of a region. Due to UI complexity issues, OracleAS Wireless Customization Portal does not support multiple criteria creation for a single location condition, and only one criteria can be created using this tool for a specific subscription. However, it is possible to include multiple criteria by using the provided Java API.

Along with this information, users can pick a device to use for receiving notifications, and an alternative device to send notifications to when the maximum number of notifications is reached for the primary device. Device selection is an optional step.

When the notification engine validates user subscription predicates and generates message content for a user, it hands over this message to the XMS layer for delivery. If the user has selected a device for notification retrieval, XMS will use the selected device (or the specified alternative device, if the daily maximum is reached) to deliver end-user messages with the appropriate protocol. However, if the user prefers not to specify a device, XMS will pick the best device to use depending on contact rules, user profile and message content type. For more information about device selection, see Section 11.4, "Migrating the Notification System".

    //Locate the master notification service
    MasterAlertService mAS = s.lookupMobileMasterAlertService("StockNotification");
    //Locate the stock trade master service
    MasterService masterService =
              s.lookupMasterService("/master/examples/StockTradeMasterService");
    //Locate the stock trade link
    Link link = s.lookupLink("/Examples/StockTradeLink");
    //Locate the user
    User user = s.lookupUser("orcladmin");
 
    //Locate primary and alternative device addresses
    DeviceAddress addr1 = s.lookupDeviceAddress(DeliveryType.SMS, "1234567890");
    DeviceAddress addr2 = s.lookupDeviceAddress(DeliveryType.E-MAIL,
              "Okan.Alper@oracle.com");
 
    //Create a subscription for orcladmin on the stock trade link
    ServiceAlertSubscription sub = mAS.addUserAlertSubscription(user, link);
 
    //Set the data feed input parameter (ticker) to ORCL
    AlertInputParamValue[] paramVals = sub.getInputParameters();
    paramVals[0].setValue("ORCL");
 
    //Set triggering condition values: price:30 and change: 12
    AlertConditionValue[] conVals = sub.getConditions();
    conVals[0].setValue("30"); //price
    conVals[1].setValue("12"); //change
 
    //Set frequency to daily, receive notifications on weekdays
    AlertTimeFrequency freq = AlertTimeFrequencyImpl.getAlertTimeFrequencys()[0];
 
    //Activate the notification tomorrow
    Calendar startDate = Calendar.getInstance();
    startDate.add(Calendar.DATE, 1);
 
    //User will be subscribed for 365 days
    Calendar expirationDate = Calendar.getInstance();
    expirationDate.add(Calendar.DATE, 366);
 
    //User will be going on vacation 30 days from now,
    //so deactivate them temporarily in that period for 10 days
    Calendar blackoutStartDate = Calendar.getInstance();
    blackoutStartDate.add(Calendar.DATE, 30);
    Calendar blackoutEndDate = Calendar.getInstance();
    blackoutEndDate.add(Calendar.DATE, 40);
 
    //Create location condition for monitoring myself for getting into a region with id 18191.
    LocationPrivacyDomain lbDomain = new LocationPrivacyDomain(masterService);
    LBCondition lbCondition = f.createLBCondition(LBCondition.MODE_REPEAT,
                expirationDate, user, lbDomain);
    lbCondition.addCriteria("orcladmin", "user", "IN", 18191);
 
    //Set data and time predicates for this subscription.
    //This notification will evaluate the conditions starting at 8:00 a.m. till 1:30pm
    //every 45 minutes, on every weekday (Monday-Friday).
    sub.setCondition(paramVals, conVals, 8, 0, 13, 30, 45, freq,
                 expirationDate, startDate);
    //Set the location condition
    sub.setLocationCondition(lbCondition);
 
    //Set the primary device that notifications will be send to
    sub.setSubscriptionDevice(addr1);
    //When the max. number of notifications is reached,
    //send the notifications to the alternative device
    sub.setAlternativeType(ServiceAlertSubscription.AFTERMAX_DEVICE);
    //Set the secondary device as alternative device
    sub.setAlternativeDevice(addr2);
 
    //Set blackout periods, activation/deactivation information
    sub.setSuspendStartDate(blackoutStartDate);
    sub.setSuspendEndDate(blackoutStartDate);
    sub.setStartDate(startDate);
    sub.setExpirationDate(expirationDate);
 
    //save the subscription
    sub.save();

11.2.4 Notification Administration

Notification Engine must run in continuos mode by managing its own resources (such as threads), so that it can process incoming events to determine which subscriptions are eligible for notification delivery. Upon successful notification creation, application developers should create a separate process for the notification engine, and attach appropriate notifications that are designed ahead of time.

Since Notification Engine is designed as a scalable system, OracleAS Wireless Tools, as part of Oracle Enterprise Manager, can create multiple processes to manage a single notification. In this case, load (incoming events) is distributed among these processes; each of these processes handle incoming events independently, meaning each process will perform the filtering for a specific event that they receive.

For notifications that do not consume much resource, it is also possible to share the resources among various notifications in a single process. In this case, application designers should create a process, and add multiple notifications to this process.

As explained earlier, data-based notifications rely on incoming data events, which are provided by the data feeders. Therefore, a separate data feeder process should also be created and started for the Data Feeder instance that will be providing data events for the notification engine.

11.2.5 Notification Migration

It is possible to migrate 9.0.2.x notifications (referred to as alerts hereinafter) to the current release by running the provided migrateNotifications.sh[.bat] script. For migrating:

1. Navigate to ORACLE_HOME/wireless/bin/

2. Do one of the following:

   1. Run migrateNotifications.sh[.bat] name <deprecated master alert name(s)> -owner <owner username>

      The name parameter is used to locate the alerts (that will be migrated) by name.

      You can use wild cards, such as % in <deprecated master alert name(s)>. All 9.0.4.x notification-related objects (such as master notification application, master application, application link) will be owned by the given username.

   2. You can also run the same script with the -oid option as:

      migrateNotifications.sh[.bat] -oid <deprecated master alert oid> -owner <owner use name>
      

Using the OID option locates a specific notification by object ID.

Running (a) or (b) above performs the following operations:

• Create a new master notification application; name will be <old master alert name>_New. This process involves converting the message template to a valid mobile xml if necessary.

• Create a new folder as /master/notifications for the master application if this folder does not exist.

• Create a new master application with the name <old master alert name>_MS.

• Create a mapping for the new master notification and new master application based on the old master alert's message template.

• Create a new folder for the link as /Users Home/<username>/notifications if this folder does not exist.

• Detect all associated 9.0.2.X AlertService (notification application) objects and convert them to link objects. Topic-level authorization will be flattened into link level authorization during this process.

• Transform all subscriptions for alert applications converted in the previous section.

migrateNotifications.sh  -name StockAlert% -owner orcladmin

migrateNotification.sh -name StockAlert -owner systemadmin

migrateNotification.sh -oid 1973 -owner systemadmin

11.3.1 Building a Data Feeder

You can create a data feeder using OracleAS Wireless Tools, or programatically. OracleAS Wireless Tools provides you with a wizard to guide you through each step of the creation process. For more information, see OracleAS Wireless Administrator's Guide.

Creating a data feeder includes these steps:

1. Create a named data feeder—all data feeders must have a name; the name may be changed. The data feeder also has an object ID which is permanent and unique, and is generated by the system when created.

2. Set Content Provider parameters—set the protocol and format for the current Content Provider. There are constants for the built-in protocols and formats.

3. Create Data Feeder Input parameters—a data feeder must have at least one input parameter. For each input parameter you specify, you must give an internal name and data type. Parameters may have options that depend on the chosen format. If the format chosen is delimited text, you have the option of specifying the column number in which the input parameter appears. This is useful if the input parameter is also included in the output from the content provider. The index for the columns starts at 1, as SQL. If 0 is specified, then the input parameter is assumed to not be in the output.

4. Create Data Feeder Output parameters: A data feeder must have at least one output parameter. The output parameter can be customized in the same manner as an input parameter.

5. Finalize the Feed—finally, you must call the DataFeeder method createFeedDefinition. This method creates the feed metadata definition in the repository, which is required to use the feed and the feed cache table. Once the feed definition has been created, feed parameters cannot be deleted, only renamed.

11.3.2 Creating a Pass-Through Data Feeder

A pass-through data feeder requires that you specify the classname of the pass-through data feeder to use. It does not require all the information that a regular data feeder needs; in particular, the protocol and format to use is irrelevant.

The code in Example 11-6 creates a pass-through data feeder.

ModelFactory mf = MetaLocator.getInstance().getModelFactory();
// Create a named datafeeder
PassthroughDataFeeder df = mf. createPassThroughDataFeeder ("stock_passthrough")
// Set the class name to use for implementation
df.setClassName("fully.qualified.package.and.Class");
// Create input parameters
FeedMetaData fmi = df.createMetaData("sym", "TEXT_30");
df.addInputParameter(fmi):
// Create output parameters
FeedMetaData fmo1 = df.createMetaData("price", "NUMBER");
df.addOutputParameter(fmo1);
 
FeedMetaData fmo2 = df.createMetaData("change", "NUMBER");
df.addOutputParameter(fmo2);
 
// Finalize the feed -- create feed definition 
// in repository
df.createFeedDefinition();

11.3.3 Sample Applications

This section contains descriptions of sample applications.

ModelFactory mf = MetaLocator.getInstance().getModelFactory();
// Create a named datafeeder
DataFeeder df = mf.createDataFeeder("stock_screamingmedia");
// Set content provider parameters
ContentProviderInfo cpi = df.getContentProviderInfo();
cpi.setProtocolType(ContentProviderInfo.PROTOCOL_HTTP);
cpi.setPrimarySource("http://www.screamingmedia.com/");
cpi.setFormatType(ContentProviderInfo.FORMAT_XML);
// Create input parameters
FeedMetaData fmi = df.createMetaData("sym", "TEXT_30");
df.addInputParameter(fmi);
// Set the parameters for this parameter and content provider
Map paramOptions = new Hashtable();
paramOptions.put(ContentProviderInfo.COLUMN_NUMBER, new Integer(1));
cpi.setParamArguments(fmi, paramOptions);
 
 
// Create output parameters
FeedMetaData fmo1 = df.createMetaData("price", "NUMBER");
df.addOutputParameter(fmo1);
paramOptions.put(ContentProviderInfo.COLUMN_NUMBER, new Integer(2));
cpi.setParamArguments(fmo1, paramOptions);
 
FeedMetaData fmo2 = df.createMetaData("change", "NUMBER");
df.addOutputParameter(fmo2);
paramOptions.put(ContentProviderInfo.COLUMN_NUMBER, new Integer(3));
cpi.setParamArguments(fmo2, paramOptions);
// Finalize the feed -- create feed definition in repository
// create cache table as needed
df.createFeedDefinition();

ModelFactory mf = MetaLocator.getInstance().getModelFactory();  // Create a named datafeeder  DataFeeder df = mf.createDataFeeder("test_1");  // Set content provider parameters  ContentProviderInfo cpi = df.getContentProviderInfo();  cpi.setProtocolType(ContentProviderInfo.PROTOCOL_HTTP);  @ cpi.setPrimarySource("http://www.screamingmedia.com/");  cpi.setFormatType(ContentProviderInfo.FORMAT_XML); 
// Create input parameters  FeedMetaData fmi = df.createMetaData("sym", "TEXT_30");  df.addInputParameter(fmi);  // Set the parameters for this parameter and content provider  Map paramOptions = new Hashtable();  paramOptions.put(ContentProviderInfo.COLUMN_NUMBER,"1");  cpi.setParamArguments(fmi, paramOptions); 
// Create output parameters  FeedMetaData fmo1 = df.createMetaData("price", "NUMBER");  df.addOutputParameter(fmo1);  paramOptions.put(ContentProviderInfo.COLUMN_NUMBER, "2");  cpi.setParamArguments(fmo1, paramOptions); 
FeedMetaData fmo2 = df.createMetaData("change", "NUMBER");  df.addOutputParameter(fmo2);  paramOptions.put(ContentProviderInfo.COLUMN_NUMBER, "3"); 
cpi.setParamArguments(fmo2, paramOptions);  // Finalize the feed -- create feed definition in repository  // create cache table as needed  df.createFeedDefinition();  mf.save(); 

// Look up existing data feeder
DataFeeder df = ModelServices.getInstance().lookupDataFeeder("stock_yahoo");
// Want to add input params for ORCL
Map params = new Hashtable();
params.put("sym", "ORCL");
df.setData(params);

ModelServices ms = MetaLocator.getInstance().getModelServices();
DataFeeder df = ms.lookupDataFeeder("stock_yahoo");
Map params = new Hashtable();
params.put("sym", "ORCL");
Map values = df.getData(params);
Iterator i = values.keys(); 
while(i.hasMore()) {
	String key = (String)i.next();
	String val = (String)values.get(key);
	System.out.println(key + " = " + val);
}
Running this code we while get the following output:
sym = ORCL
price = 18.75
change = 0.5

ModelServices ms = MetaLocator.getInstance().getModelServices();
DataFeeder    df = ms.lookupDataFeeder("stock_yahoo");
UpdatePolicy  up = df.getUpdatePolicy();
up.setStartTime(9,0,0);
up.setEndTime(17,0,0);
up.setUpdateDays(UPDATE_WORKDAYS);
// Set update interval to 300 seconds, i.e. update every 
// 5 minutes
up.setUpdateInterval(300); 

<?xml version="1.0"?>
<market-data>
<quote-set>
<quote symbol="ORCL" name="ORACLE CORPORATION" type="stock" exchange-code="NASDAQ" last="32.000000" close="28.562500" close-flag="closed" change="3.4375" percent-change="12.04%" volume="56362800" open="30.0" high="32.4375" low="29.9375" bid="32.0" ask="32.0625" bid-size="36" ask-size="90" high-52-week="46.468998" low-52-week="15.438" shares-outstanding="5629833" pe-ratio="29.299999" volatlity="16.150000" yield="0.000000" earnings-per-share="1.092000" status="ok"/>
</quote-set>
</market-data>
The stylesheet for transforming this result would then look like this:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="quote-set">
    <omfeed_result>
      <xsl:for-each select="quote">
        <omfeed_datarow>
            <omfeed_datacolumn>
              <xsl:attribute name="name">sym</xsl:attribute>
              <xsl:value-of select="@symbol"/>    
            </omfeed_datacolumn>
            <omfeed_datacolumn>
              <xsl:attribute name="name">price</xsl:attribute>
               <xsl:value-of select="@last"/>
            </omfeed_datacolumn>
            <omfeed_datacolumn>
              <xsl:attribute name="name">change</xsl:attribute>
              <xsl:value-of select="@change"/>
            </omfeed_datacolumn>
        </omfeed_datarow>
      </xsl:for-each>
    </omfeed_result>
  </xsl:template>

11.4.1 Notification Migration Scenario

Here is a typical notification migration scenario:

1. Start with a pure 9.0.2.x environment.

2. Start upgrade, and have an OracleAS Wireless 9.0.2.x and 9.0.4.x mixed environment. At this time, use only 9.0.2.x-style notifications.

3. Complete upgrade to OracleAS Wireless 9.0.4.x environment.

4. Run the script migrateNotifications to upgrade 9.0.2.x-style notifications to 9.0.4.x-style.

5. Use only 9.0.4.x-style notifications from this point on. The script is further described later in this section.

11.4.2 Structural Changes

There have been significant structural changes to notifications in this release. Major differences include:

• Section 11.4.2.1, "Event Generation"

• Section 11.4.2.2, "Message Content Generation"

• Section 11.4.2.3, "Authorization"

11.4.3 Migration Limitations

After upgrading to 9.0.4.x, users must not mix 9.0.4.x notifications with 9.0.2.x. Use 9.0.2.x notifications only until you are ready to migrate to the 9.0.4.x notifications, and use only 9.0.4.X notifications after a successful migration.

The 9.0.4.x OracleAS Wireless Webtool utility is defaulted to show/create only 9.0.4.x notifications. Likewise, the 9.0.4.x OracleAS Wireless Mobile Portal utility can only process 9.0.4.x subscriptions. If you want to process 9.0.2.x notifications using 9.0.4.x OracleAS Wireless Webtool, you must modify the System.properties file located in ORACLE_HOME/wireless/server/classes/oracle/panama/core/admin directory as follows:

• Edit the ORACLE_HOME/wireless/server/classes/oracle/panama/core/admin/System.properties using a standard text editor.

• Locate the parameter named: DeprecatedAlertSupport, and change its value to true.

• Save this file, and restart your OC4J Portal instance.

Since the subscription process and authorization are completely different in 9.0.2.x and 9.0.4.x, it is not possible to use OracleAS Wireless Mobile Portal to process 9.0.2.x subscriptions. To do so, users should either enable 9.0.2.x Customization Portal utility or develop their own subscription mechanism. Sample code is provided at the end of this section demonstrating how to migrate your existing code for subscription handling.

11.4.4 Running the Migration Script

It is possible to transform (migrate) any 9.0.2.x notification to 9.0.4.x using a script provided with OracleAS Wireless. This script performs the following operations:

• Creates a new template-based 9.0.4.x master notification using the information defined in the 9.0.2.x master notification. If the 9.0.2.x notification is time based, then the time-based type will be set to non-strictly time-based in 9.0.4.x. This can be changed any time using the OracleAS Wireless Webtool. The name of the 9.0.4.x master notification will be <OLD_MASTER_NOTIFICATION_NAME>_NEW, the script will append _NEW to the 9.0.2.x master alert name. All information (such as message template triggering conditions), is copied over, and partial message templates are transformed into well-formed mobile XMLs if necessary.

• Creates a master application and maps it to the new master notification. The name of this master application will be <OLD_MASTER_NOTIFICATION_NAME>_MS, and the master application will be created in a folder called /master/notifications.

• Creates a link based on the new master application for each 9.0.2.x alert. The name of this link will be the same as the alert service, and again, it will be created in the /notifications folder.

• Migrates all group and user access information for the given 9.0.2.x master notification application related objects (that is: AlertService, Topic, and others).

• Converts all existing subscriptions to 9.0.4.x subscriptions.

Although the migration script does not remove or disable the old master alert service for integrity and security purposes, you should disable the old master alert services once the migration process is successfully completed.

To run this script:

1. Stop all notification processes that use the master notifications that are to be migrated, or remove these master alert service from those processes and restart them.

2. Change directory to ORACLE_HOME/wireless/bin

3. Execute migrateNotifications.[sh|bat] by providing parameters as follows:

   1. migrateNotifications.[sh|bat] -name <9.0.2.X master alert name(s)> -owner <owner user name>

   2. migrateNotifications.[sh|bat] -oid <9.0.2.X master alert oid> -owner <owner user name>

   3. You can use % as a wildcard for the name parameter, but not for the OID.

   4. The Owner user name will be used to create required master applications, application links and folders. Some examples are listed in Table 11-1.

   Table 11-1 Migration Script Examples

   Script	Function
   migrateNotifications.[sh|bat] -name StockAlert -owner orcladmin	Migrates the master notification named "StockAlert"
   migrateNotifications.[sh|bat] -name Stock% -owner orcladmin	Migrates all master notifications starting with "Stock", such as "StockAlert", "StockTransaction"
   migrateNotifications.[sh|bat] -name % -owner orcladmin	Migrates all master notifications.
   migrateNotifications.[sh|bat] -oid 1089 -owner orcladmin	Migrates the master notification that has the oid 1089.

   
   

4. Check OracleAS Wireless Webtool and Mobile Portal to verify the migration process for the master notification, master application, link and subscriptions.

5. Create a new notification process and attach migrated master alerts to this process.

Remember that you must stop existing notification processes that contain migrated 9.0.2.x notifications, or remove these master notifications from those processes and restart them. As explained before, the migration script does not remove or disable 9.0.2.x notifications. Therefore, if these processes are not maintained correctly, users will receive 2 copies of each notification, one from the old master notification and one from the new one.

    MetaLocator m = MetaLocator.getInstance();
    ModelServices s = m.getModelServices();
 
    //Assuming we have a user named "DemoUser"
    User myUser = s.lookupUser("DemoUser");
 
    //Assuming we have a validated E-Mail address, the first e-mail device address
    DeviceAddress[] deviceAddrList = 
            myUser.getDeviceAddresses(DeliveryType.E-MAIL);
    DeviceAddress subscriptionDeviceAddr = deviceAddrList[0];
 
    //Retrieve the alert service object that will be used to create a subscription
    oracle.panama.alert.AlertService alert = s.lookupAlertService("StockNotification");
 
    alert.setUserAlertDevice(subscriptionDeviceAddr);
 
    oracle.panama.alert.UserAlertSubscription userSub =
            alert.addUserAlertSubscription(myUser);
 
    userSub.setDisplayName("DemoSubscription");
 
    // Set subscription time to 13:30 in daily mode.
    userSub.setHour(13);
    userSub.setMinute(30);
    userSub.setFrequency(
            new oracle.panama.alert.impl.AlertTimeFrequencyImpl(
                    oracle.panama.alert.AlertTimeFrequency.DAILY));
 
    // Expiration time set to one month ahead
    Calendar expireAt = Calendar.getInstance();
    expireAt.add(Calendar.MONTH, 1); //Expire next month
    userSub.setExpirationDate(expireAt);
 
    //Set the input parameter, i.e. stock ticker to ORCL
    oracle.panama.alert.AlertInputParamValue[] pVs = userSub.getInputParameters();
    pVs[0].setValue("ORCL");
 
    // set the triggering condition, i.e. stock price >= 20
    oracle.panama.alert.AlertConditionValue[] acv = userSub.getConditions();
    acv[0].setValue("20");
    userSub.setCondition(pVs, acv);
 
    // Save subscription
    userSub.save();
 
    // Save AlertService, so that user alert device can be persisted
    alert.save();
 
Sample code for adding the  9.0.4.X subscription after migration:
 
 
    MetaLocator m = MetaLocator.getInstance();
    ModelServices s = m.getModelServices();
 
    //Retrieve the master alert service object that will be used to create a subscription
    oracle.panama.mobilealert.MasterAlertService masterAlertService =
            s.lookupMobileMasterAlertService("StockAlert");
 
    //Retrieve the link that will be used to create a subscription,
    //note that it has the same name as the AlertService object
    Link myLink = s.lookupLink("/notifications/StockNotification");
 
    //Assuming we have a user named "DemoUser"
    User myUser = s.lookupUser("DemoUser");
 
    //Assuming we have a validated E-Mail address, the first e-mail device address
    DeviceAddress[] deviceAddrList =
            myUser.getDeviceAddresses(DeliveryType.E-MAIL);
    DeviceAddress subscriptionDeviceAddr = deviceAddrList[0];
 
    //
    oracle.panama.mobilealert.ServiceAlertSubscription userSub =
            masterAlertService.addUserAlertSubscription(myUser, myLink);
 
    userSub.setSubscriptionDevice(subscriptionDeviceAddr);
    userSub.setAlternativeType(ServiceAlertSubscription.AFTERMAX_DISCARD);
 
    userSub.setDisplayName("DemoSubscription");
 
 
    // Set subscription time to 13:30 in daily mode.
    //Since start/end time are same, interval can be any value
    userSub.setHour(13);
    userSub.setMinute(30);
    userSub.setEndHour(13);
    userSub.setEndMinute(30);
    userSub.setInterval(1);
    userSub.setFrequency(
            new oracle.panama.mobilealert.impl.AlertTimeFrequencyImpl(
                    AlertTimeFrequency.DAILY));
 
    // Expiration time set to one month ahead
    Calendar expireAt = Calendar.getInstance();
    expireAt.add(Calendar.MONTH, 1); //Expire next month
    userSub.setExpirationDate(expireAt);
 
    //Set the input parameter, i.e. stock ticker to ORCL
    oracle.panama.mobilealert.AlertInputParamValue[] pVs = 
            userSub.getInputParameters();
    pVs[0].setValue("ORCL");
 
    // set the triggering condition, i.e. stock price >= 20
    oracle.panama.mobilealert.AlertConditionValue[] acv = userSub.getConditions();
    acv[0].setValue("20");
 
    // Save subscription information
    userSub.save();