4 Managing Oracle Sensor Edge Services

4.3.3.1 Configuring the Edge Simulator

The Simulator (the EdgeSimulator driver) generates events to simulate a real device. In general, you use the EdgeSimulator driver to test configurations and deployment designs; however, you can also use it for internal functional testing to see how events are processed throughout the system. The EdgeSimulator driver acts the same as any driver, except that instead of connecting to a physical device to read events, it takes parameters from an input file (such as Example 4-3) as instructions on when to generate fake events. This begins as soon as the device starts (which starts when the Oracle Sensor Edge Server starts).

4.3.3.2 Configuring AlienDevice Driver

The AlienDevice driver supports all of the Alien Technology RFID readers. The ALR series of readers has been tested for this release of the Oracle Sensor Edge Server. Configuring the AlienDevice driver includes:

• Finding the IP Address of the Alien RFID reader using the discoverer included in the RFID Gateway demo software provided by Alien Technology (Section 4.3.3.2.1).

• Connecting the Alien RFID reader to a Web browser (Section 4.3.3.2.2).

• Connecting the Alien RFID reader to the Oracle Edge Server by creating a device using the AlienDevice driver (Section 4.3.3.2.3).

4.3.3.3 Configuring the IntermecDevice Driver

The IntermecDevice driver supports all of the RFID readers by Intermec, including the OEM Reader (Microwave, UHF), the PC Reader (PCMCIA), and the Fixed Reader (Serial or Ethernet). Other Intermec readers that support the Intellitag IDK also work with the IntermecDevice driver. For more information, refer to

http://www.intermec.com

Requirements

The IntermecDevice requires the following components, which are bundled and shipped with the Intermec driver:

• IntelliTag IDK

  The IntelliTag IDK (the IDK) is a set of Intermec-supported software libraries and tools. This library, which is the only supported method of communicating with Intermec devices, is supported only on the Windows 32 platform (that is, Windows 2000 and Windows XP). The IntelligTag IDK is available at

  http://www.oracle.com/technology/products/iaswe/edge_server/extensions.html

• Oracle Sensor Edge Server Device Controller

  The Oracle Sensor Edge Server Device Controller (the Device Controller) communicates with the local IDK API and exposes a network protocol that enables the Oracle Edge Server to communicate with the IDK.

• IntermecDevice Driver

  The IntermecDevice driver is the counterpart to the Device Controller, as it communicates with the Device Controller to drive the underlying devices.

The Oracle Sensor Edge Server can run on the same server as the Device Controller and the IDK, or on a separate server. Because the Intermec hardware exposes a Windows 32- based API, you must run the Oracle Sensor Edge Server on a Windows box or dedicate another Windows machine to only the Device Controller and the IDK.

Configuration Steps

Configuring the IntermecDevice driver involves the following tasks:

• Installing the IDK (Section 4.3.3.3.1).

• Registering Serial and PCMCIA readers (Section 4.3.3.3.2).

• Configuring the Intermec readers (Section 4.3.3.3.3).

• Using the Intermec tools to test the Intermec readers (Section 4.3.3.3.4).

• Installing the Device Controller (Section 4.3.3.3.5).

• Starting the Device Controller for the Intermec reader (Section 4.3.3.3.6).

• Creating a device using the IntermecDevice driver to enable communication between the Oracle Sensor Edge Server and the Device Controller for the Intermec reader (Section 4.3.3.3.7).

[Reader_One]
RFID_SWTT_FILE_NAME=C:\Program Files\Intermec\Intellitag IDK\swtt.ini
RFID_ATTR_TYPE=IT500 UAP Reader
IT500_PORT_TYPE=TCPIP
IT500_PORT_NUMBER=6543
IT500_CONNECT_TRIES=1
IT500_PORT_NAME=192.168.200.47
IT500_DEBUG_FILE_NAME="c:\IT500_Reader.log"
IT500_ANTENNA_TRIES=5
IT500_ANTENNAS=1 2 0 0 0 0 0 0
IT500_READ_TRIES=5
IT500_WRITE_TRIES=5
IT500_INTERR_DEBUG=0
IT500_READER_DEBUG=0
dll_name=C:\Program Files\Intermec\Intellitag IDK\it500.dll
IT500_IDENTIFY_TRIES=1
IT500_INITIALIZATION_TRIES=1
IT500_SIM_TAGS=5
IT500_IDENTIFY_READ_END_ADDR=17
IT500_HARDWARE_TYPE_CHECK=0
IT500_AUTOID_TIMEOUT=20

4.3.3.4 Configuring the Patlite Driver

Unlike the RFID readers or other sensors, the Patlite series of lightstacks and trees do not generate events, but instead act as indicator lights and signals. Sending events to Patlite lightstacks and trees turns on lights or causes them to blink for certain intervals.

Configuring the Patlite driver involves the following tasks:

• Installing the Patlite hardware (Section 4.3.3.4.1).

• Configuring the Device Controller for the Patlite device (Section 4.3.3.4.2).

• Starting the Device Controller for the Patlite device (Section 4.3.3.4.3).

• Configuring the Oracle Sensor Edge Server to communicate with the Device Controller for the Patlite device by creating a device instance (Section 4.3.3.4.4).

Supported Patlite Devices

Patlite's products include those that support both Serial and Ethernet connection. The current version of the Patlite driver in this release supports the Serial connection only.

4.6.2.1 Adding a Filter Instance to a Device or to a Device Group

Adding a filter instance to a device enables pre-device filtering and post-device filtering of events. For a device group, a filter instance provides device group filtering. For more information on device- and device group-level filtering see Section 4.4.

To add a filter instance to a device, select a device from the browsing screen and then click Filter Control. The Filter Control screen appears, displaying the list for the selected device or device group in the Applied Filter Instances pane (Figure 4-3).

Figure 4-3 The Filter Control Screen

Description of "Figure 4-3 The Filter Control Screen"

Select a filter from the Filter drop-down list and then click Add. The parameters specific to the selected filter appear. Define the values as needed and then click Finish to create a instance of the filter for the selected device or device group. The filter instance appears in the Applied Filter Instances pane (Figure 4-3), where it can then be deleted, edited, or sorted.

Figure 4-4 Defining the Values of a Filter

Description of "Figure 4-4 Defining the Values of a Filter"

4.6.2.2 Prioritizing Filter Instances for Devices and Device Groups

The order of filter instances affects the efficacy of the data filtering. For example, if a device or device group is assigned a group filter, which groups IDs into an array of events and treats them as one item and a tag filter the filters out the events for a specific tag, TagXYZ, then applying the group filter before the tag filter results in the Oracle Sensor Edge Server receiving events grouped into chunks based on when they were detected, but only after the tag filter has strained out the events for TagXYZ. Reversing the order of the filters (that is, putting the group filter before the tag filter) would prevent the tag filter from filtering out anything, because it would see only the group events and not those for TagXYZ.

You can arrange the filter instances by selecting a filter instance and then moving it up or down using the arrow keys. To set the filter sequence, click Finish.

4.6.3.1 Configuring the Check Tag ID Filter

A Check Tag is any normal tag used to test if the device (in this case, a reader) is reading tags. Because the Check Tag itself should be physically located within the field of the reader, it should always be read; when other tags move through the field of the reader, the device also reads the Check Tag in conjunction with them.

The Check Tag ID Filter ensures that the device reads a Check Tag periodically. Using this filter enables you to check the status of a driver, its corresponding reader, and attached antennae. Because the Check Tag ID Filter is used solely for diagnostic purposes, it does not provide any events for dispatching to client devices. Instead, this filter generates an event if it does not detect that the device has read a Check Tag for a specified period of time.

Table 4-8 describes the parameters (and associated values) of the Check Tag ID filter.

To define the parameters for the Check Tag ID Filter, you must note the ID of the Check Tag itself (which must be placed within the field of the reading device). Enter this ID as the String value of Check Tag Id. If the filter does not detect that a device has read a Check Tag bearing the specified ID for the period defined in the Tag Check Time Window parameter, it generates an event. Table 4-9 describes the signature of the generated event. Refer to Section 4.1.1 for more information on the Event type.

4.6.3.2 Using the Cross-Reader Redundant Filter

The Cross-Reader Redundant Filter blocks redundant events that are sent from the devices of a device group and does not generate any events. This filter considers events redundant if it finds they have the same tag ID.

The Cross-Reader Redundant Filter is for group-level filtering only; it performs no functions if applied to a device. This filter has no parameters to configure.

4.6.3.3 Using the Debug Filter

The Debug Filter traces events passing through the system. Upon receiving events from its associated device, this filter writes events to a log file. This filter has a single parameter called Event Output File. To define this parameter, enter the full path of the log file to which you want the Debug Filter to write events. (The server must make this file writable.) The format of the Debug Filter's output is as follows:

"Devicename: <devicename> Type: <type> Subtype: <subtype> EventTime: <time>TagIds:<tagid(,tagid)*>Data:<dat(,data)*>\n"

Each event is on a separate line; each line is separated by a newline character (LF or CRLF, depending on the operating system). The <time> value is a long as returned by the time(2) call.

This filter can only be attached to a device, not to a device group.

4.6.3.4 Configuring the Pass Filter

When a tag passes through the range of transmission, or through the gateway of a device reader, it generates a series of "tag is seen" events. The device reports these events periodically, starting when the tag enters the transmission field. The reporting stops when the tag moves out of the reader field.

Applications often do not require the series of events that a device reader generates; instead, these applications only need to know that a tag has passed through a device's gateway or range of transmission. The Pass Filter applies to such situations, as it reduces all of the "tag is seen" events into single events for each unique tag that passes through the field of a reader device.

The Pass Filter has one parameter, Exit Event Threshold Time. To define this parameter, enter the time (an int value), in milliseconds, since the device last read the tag before it is considered to have moved out of the device's transmission field. The parameter settings, which range from 50 milliseconds to under two seconds, dictate the frequency (that is, the reader cycle) in which the device reports these "tag is seen" events. If you set this frequency too high, such as to two seconds, then the device may miss the tag altogether.

When the device first reads a tag, the Pass Filter caches the tag's ID (tagid), notes the time that the tagid was read into the cache, and then immediately sends the pass-through event. The filter blocks subsequent reads for this cached tagid. Each time the filter receives a new read from the device, it updates the time that it read the tagid into the cache. If the sum of the caching time and the value set for Exit Event Threshold Time is less than the current time, then the Pass Filter clears the tagid from the cache. The next time the device reads this tag, the filter considers it a new event, caches its tagid and sends out a new pass-through event. Refer to Section 4.1.1 for more information on the Event type.

Table 4-10 describes the signature of the pass through event.

4.6.3.5 Configuring the Shelf Filter

The Shelf Filter is a device-level filter that generates events when a tag is detected within the field of a reader or when the tag has left the field. Like the Pass Filter, the Shelf Filter has a single parameter, Exit Event Threshold Time. To define this parameter, enter the time (an int value), in milliseconds, since the device last read the tag before it is considered to have moved out of the device's transmission field. Unlike the Pass Filter, however, the Shelf Filter silently clears its cache once the interval defined for the Exit Event Threshold Time parameter elapses and does not generate an event.

4.6.3.6 Configuring the Pallet Pass Thru Filter

The Pallet Pass Thru Filter collects all of the events received during a specified period and sends them out as a single event. When a pallet or container passes through a gateway or through the field of transmission of a reader device, this filter generates a single event for all of these tags. This filter enables you to see what items a container or pallet may hold.

The Pallet Pass Thru Filter includes the following parameters:

• Configuring the Pallet Pass Thru Filter

• Configuring the Pallet Pass Thru Filter

Exit Event Threshold Time

To define this parameter, enter the time (an int value), in milliseconds, since the device last read a tag before it is considered to have moved out of the device's transmission field. The parameter settings, which range from 50 milliseconds to under two seconds, dictate the frequency (that is, the reader cycle) in which the device reports these "tag is seen" events. If you set this frequency too high, such as to two seconds, then the device may miss the tag altogether.

Event Collect Control Time

To define this parameter, enter the time (an int value), in milliseconds, for a device to complete a reading cycle of the tags included in a pallet or container before starting a new reading cycle. When this time elapses, the reading cycle concludes (that is, the device has read all of the new tags) and the Pallet Pass Thru Filter then generates an event with the following signature (described in Table 4-13). Refer to Section 4.1.1 for more information on the Event type.

4.6.3.7 Configuring the Pallet Shelf Filter

The Pallet Shelf Filter collects all of the events received during a set interval and then sends them as a single event. This filter enables you identify when new containers or pallets holding many items enters an area, or exits the field or gateway of a device reader.

The Pallet Shelf Filter has the following parameters:

• Configuring the Pallet Pass Thru Filter

• Configuring the Pallet Pass Thru Filter

Exit Event Threshold Time

To define this parameter, enter the time (an int value), in milliseconds, from the last time that the device read the tag before it is considered to have moved out of the device's transmission field. The Pallet Shelf Filter silently clears its cache once the interval defined for the Exit Event Threshold Time parameter elapses and does not generate an event.

Event Collect Control Time

To define this parameter, enter the time (an int value), in milliseconds, for a device to complete a reading cycle for the tags of a pallet or container before starting a new reading cycle. When this time elapses, the reading cycle concludes (that is, the device has read all of the new tags) and the Pallet Shelf Filter then generates an event.

4.8.2.1 Configuring the Edge Dispatcher to Use Oracle Streams

Configuring the edge dispatcher to use Oracle Streams and Advanced Queuing enables you to control how the edge dispatcher retrieves and distributes event messages. Unlike the OC4J JMS, Web Services, or HTTP dispatcher options, event messages dispatched using the Oracle Streams dispatcher do not have to be relayed directly to an entry point. The Oracle Streams dispatcher supports rule-based process and agent technologies. In addition, the Streams dispatcher only supports UTF-8 encoding.

Event messages are data that is deposited to a staging area (an internal queue). This data, in turn, can be aggregated in different ways for different client devices and applications (the consumers of the event messages). Using Oracle Streams as the dispatcher, the Data and Event layer of the database, not the Oracle Sensor Edge Server or applications, determines what an event is and when it is generated. The Data and Event layer provides a rule-based process that determines the appropriate event message for each client device or application.

Once the event messages are captured and placed into the staging queue, the event message data can be processed through the Rules Evaluation Job, which takes event messages from the staging queue and then compares them to the Oracle Sensor Edge Server rule set. Each rule has an action, which is executed if the rule applies. These actions include a PL/SQL callback for propagating the event message to other queues which could then be consumed by other applications. For more information on Oracle Sensor Edge Server Rule Set, refer to the Oracle Application Server Wireless Developer's Guide

In addition to these rule-based actions, the Rules Evaluation Job invokes applications by calling the Sensor Data Hub (SDH), which receives sensor data from the Oracle Sensor Edge Server or from other sources. The SDH includes the Sensor Data Archive, a set of archive tables that store all of the filtered sensor events in the system:

To configure the Streams dispatcher, select Streams and the define the following information connection information for the Streams staging area:

• The JDBC connection string to the database where the staging area resides. By default, this value is set to the IAS infrastructure database. Enter the URL to an application database providing optimal access and archiving of events and observations. The URL depends upon the driver type. For example, for a thin driver, enter jdbc:oracle:thin@(description=(address=(host=<hostname>)<protocol=tcp)(port=<port>))(connect_data=(sid=<sid>)))

  where <hostname> is the host name or IP of the database server, <port> is the port number for the listener (1521, by default) and <sid> is the service id of the instance.

• The name of the user of the database where the staging area resides.

• The password to the user of the database where the staging area resides.

Select Use Customer Database to configure the Oracle Sensor Edge Server processes to send event messages through an external database.

4.8.2.2 Configuring the Dispatcher to Send Messages Through OC4J JMS

OC4J JMS (OracleAS Containers for J2EE and Java Message Service), which is compatible with J2EE 1.3, is a Java Message Service based on Advanced Queuing (AQ) that provides guaranteed message delivery with auditing.

To enable event message dispatching using OC4J JMS, you must configure a JMS topic queue called edgeTopic to which the dispatcher posts new event messages. In addition, you specify edgeEventsConnectionFactory as the connection factory. To enable the Oracle Sensor Edge Server components to access this topic, you must configure the jms.xml file under the OC4J container. Refer to the Oracle Application Server Containers for J2EE Services Guide for more information on configuring the JMS queue.

To create a JMS dispatcher that enables the Oracle Sensor Edge Server processes to send event messages to the JMS topic queue, edgeTopic:

1. Define the following values:

   • The URI of the OC4J instance where the edgeTopic queue is stored. This URI is used internally by OC4J ORMI to connect to the server. For example, enter ormi://oc4j.us.oracle.com.

   • The user name of the administrator of the OC4J instance where the edgeTopic queue is stored.

   • The password used by the administrator of the OC4J instance where the edgeTopic queue is stored.

   • Set the acknowledgement mode to CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE. The default mode is AUTO_ACKNOWLEDGE.

   • Set enterprise_mode to true.

2. Perform the following steps for each middle tier that uses the JMS dispatcher:

   1. Add the oc4j.jar and edgeclient.jar libraries to the classpath section of opmn.xml, located in the ORACLE_HOME/opmn/conf/directory by adding the following lines under the process type with the ID of "edgeserver_server"::

      <environment>
      <variable id="CLASSPATH" value="$ORACLE_HOME/j2ee/home/oc4j.jar" append="true"/>
      <variable id="CLASSPATH" value="$ORACLE_HOME/wireless/lib/edgeclient.jar" append="true"/>
      <environment>
      

      
      

      Note: The value for ORACLE_HOME depends on the location of an OracleAS Wireless middle tier.

      
      

   2. Copy edgeclient.jar to ORACLE_HOME\wireless\lib\. The edgeclient.jar is available from the Oracle Technology Network (http://www.oracle.com/technology/products/iaswe/edge_server/).

   3. Stop and then restart the OracleAS Wireless middle tier.

4.8.2.3 Configuring the Dispatcher to Send Event Messages to a Web Service

A client device or application can register a SOAP call which the Oracle Sensor Edge Server invokes when a new message must be delivered.

To configure the Web Service dispatcher to distribute event messages through Web Services, select Web Services and then define the parameters for this dispatcher type by entering the service URL of the WSDL (Web Service Definition Language) document that describes the client call. This URL must point to the EndPoint (port) of the Web Service. For example, enter http://localhost:8888/wsdl/mytest.wsdl. This document must contain the portType of EdgeClientCallback and the call, processEvent, as its child element. Upon startup, the Oracle Sensor Edge Server attempts to connect and bind to the service defined in this WSDL document.

4.8.2.4 Configuring the Dispatcher to Send Event Messages Through HTTP

Configuring the dispatcher to route events to clients using HTTP 1.0 results in the Oracle Sensor Edge Server posting each event message separately to the client. Because the Oracle Sensor Edge Server performs these posts sequentially, if one post is blocked, then all following posts are also blocked. Select HTTP to configure the HTTP dispatcher and then enter the URL of the servlet, JSP, or CGI to which the Oracle Sensor Edge Server posts event messages whenever they are dispatched. To configure this dispatcher, enter the URL in the following format:

http://hostname:port/serverPath

If the Oracle Sensor Edge Server uses the HTTP dispatcher, then the client interface must tell the Oracle Sensor Edge Server how (and when) to call it.

Refer to the Oracle Application Server Wireless Developer's Guide for a description of the parameters posted by the Oracle Sensor Edge Server to the client application.

Click OK to complete the dispatcher configuration. Ensure that the selected dispatcher method functions after you complete this configuration. For more information on the configuring the dispatcher to route events through HTTP, refer to the tutorial, Writing Sensor Based Applications Using JSP, on the Oracle Technology Network (http://www.oracle.com/technology/)

4.8.2.5 Using the Null Dispatcher

The Null dispatcher, which is created by default, discards all of the events passed to it. These events are not saved or spooled. Use this dispatcher only if you want to prevent the Oracle Sensor Edge Server from dispatching events.