|
Oracle® Sensor Edge Server Guide
10g Release 3 (10.1.3) B25142-01 |
|
 Previous |
 Next |
|
Oracle® Sensor Edge Server Guide
10g Release 3 (10.1.3) B25142-01 |
|
|
Previous |
Next |
This chapter, through the following sections, describes the Oracle Sensor Edge Mobile.
The mobile Oracle Sensor Edge Server (Sensor Edge Mobile) is a client-side (PocketPC only) application (Figure 5-1) configured with drivers that read barcode and read and write RFID tags.
Figure 5-1 Oracle Sensor Edge Mobile Administration Page on a Handheld Device
The architecture is similar to that of the Oracle Sensor Edge Server, in that it includes dispatchers that can communicate directly with applications. For example, Sensor Edge Mobile includes a dispatcher which talks with an ActiveX control that enables management pages written in HTML with JavaScript to control the drivers and display or submit the returned data.
Sensor Edge Mobile sits between the sensor device and the application. On one side, Sensor Edge Mobile interfaces with different types of sensors and devices and on the other end it feeds filtered data events to applications. The communication is bi-directional, with events passing from devices, through the platform, to the application, and instructions passing from the application, through the platform, to the hardware device driver. The Sensor Edge Mobile service runs entirely on the handheld device, and can communicate with other applications or services that are external to it, or operate entirely offline, collecting data for later synchronization with an outside application. The flow of events goes from the collection device to the driver. The queue collects events until the dispatcher can process them. The dispatcher can communicate with the application through an ActiveX control by sending characters to the keyboard buffer, or through almost any other communication method. Only one dispatcher can be active at a time, but that one dispatcher may be communicating with multiple client devices and any number of drivers.
The Sensor Edge Mobile code components include the Driver Manager, Event Manager, and the Configuration Manager. Once these components are started, the main service calls on the Configuration Manager to read the configuration file. It then starts the configured dispatcher and passes in any configuration parameters that have been specified.The Driver Manager is responsible for loading and managing the life cycle of the drivers. The Driver Manager calls on the Configuration Manager to determine which drivers need to be loaded, and what parameters to make available to them on instantiation, and then loads and initializes them. The Driver Manager does not hold any thread internally, but an instance of it is held by the core instance as long as the platform is running.There is only one Event Manager and one Driver Manager in the Sensor Edge Mobile. The Driver Manager may load any number of Drivers.
The Sensor Edge Mobile is designed to allow application programmers to have easy access to events coming from the devices, and to submit instructions to the device. The application may either communicate directly with a dispatcher, or it may communicate through another layer (such as an ActiveX control) to the dispatcher.
Applications interface with Sensor Edge Mobile through such means as:
An ActiveX control, which then communicates with the Sensor Edge Mobile running as a service process in the background.
A keyboard dispatcher, which brings focus to a specified application's window and then pushes characters into the keyboard buffer, just as if the user had typed them. For more information, see "Configuring the Keyboard Dispatcher".
A custom dispatcher. Dispatchers are loaded dynamically, and interfaces are published so that any third party can develop a specialized dispatcher.
Drivers and the current dispatcher retrieve their configuration information at the startup of the Oracle Sensor Edge Mobile service. This configuration is represented as parameters comprised of a name/value pairs.
The drivers and current dispatchers are configured in EdgeMobileCofig.xml (Example 5-1), which is located in the same directory as the Sensor Edge Mobile application. The file describes the single dispatcher used by the service in the <CurrentDispatcher> parameter as well as the driver (or drivers) that are loaded within the <DeviceList> element. These elements pass different parameter values. In Example 5-1, the Keyboard Dispatcher is set as the current dispatcher with the Intemec IP3 driver (named IP3Driver as the sole <device> element defined in this file) passing parameters as required.
Example 5-1 EdgeMobileConfig.xml
<EdgeMobileConfig>
<CurrentDispatcher>
<Name>Keyboard Dispatcher</Name>
<Version>1.0</Version>
<Description>Keyboard Dispatcher</Description>
<Library>KeyboardDispatcher.dll</Library>
<Parameters>
<Param name="DestinationApplication" value="Telnet"/>
<Param name="RFIDReadMacro" value="TelnetMultipleRFID"/>
<Param name="BarcodeReadMacro" value="TelnetMultipleBarcode"/>
<Param name="TelnetSingle" type="KeySequenceMacro">
<tab/><tab/>RFID<tab/>
<data name="TagID"/>
<tab/>
<data name="TagData"/>
<cr/>
</Param>
<Param name="TelnetMultipleRFID" type="KeySequenceMacro">
<tab/><tab/>RFID<tab/>
<Repeat>
<data name="tag_id"/>
<tab/>
<data name="data"/>
<Separator>
<tab/><tab/>
</Separator>
</Repeat>
<Cr/>
</Param>
<Param name="TelnetMultipleBarcode" type="KeySequenceMacro">
<tab/><tab/>Barcode<tab/>
<Repeat>
<data name="data"/>
<Separator>
<tab/><tab/>
</Separator>
</Repeat>
<Cr/>
</Param>
</Parameters>
</CurrentDispatcher>
<DeviceList>
<Device>
<Name>IP3Driver</Name>
<Version>1.1</Version>
<Description>Intermec RFID IP3 driver</Description>
<Library>IP3Driver.dll</Library>
<Parameters>
</Parameters>
</Device>
</DeviceList>
</EdgeMobileConfig>
The Keyboard Dispatcher collects data and puts the data into the keyboard buffer and the keyboard codes into a macro. This macro simulates the user typing while running an application such as a Telnet session or Web browser. The Keyboard Dispatcher performs the following operations (in the following order):
Captures the event data from the device driver.
Brings focus to the window of a specified application.
Sends the data and control characters specified in the KeySequenceMacro language as characters typed into the application window.
By modifying EdgeMobileConfig.xml, you specify which dispatchers and drivers are loaded and pass configuration parameters to these extensions. For Sensor Edge Mobile to use the Keyboard Dispatcher, you must define the Keyboard Dispatcher as the configuration file's <CurrentDispatcher> element as described in Example 5-2.
Example 5-2 Configuring the Keyboard Dispatcher as the Current Dispatcher
<CurrentDispatcher>
<Name>Keyboard Dispatcher</Name>
<Version>1.0</Version>
<Description>Keyboard Dispatcher</Description>
<Library>KeyboardDispatcher.dll</Library>
<Parameters>
<Param name="DestinationApplication" value="Telnet"/>
<Param name="RFIDReadMacro" value="TelnetMultipleRFID"/>
<Param name="BarcodeReadMacro" value="TelnetMultipleBarcode"/>
<Param name="TelnetSingle" type="KeySequenceMacro">
<tab/><tab/>RFID<tab/>
<data name="tag_id"/>
<tab/>
<data name="data"/>
<enter/>
</Param>
<Param name="TelnetMultipleRFID" type="KeySequenceMacro">
<tab/><tab/>RFID<tab/>
<Repeat>
<data name="tag_id"/>
<tab/>
<data name="data"/>
<Separator>
<tab/><tab/>
</Separator>
</Repeat>
<enter/>
</Param>
<Param name="TelnetMultipleBarcode" type="KeySequenceMacro">
<tab/><tab/>Barcode<tab/>
<Repeat>
<data name="data"/>
<Separator>
<tab/><tab/>
</Separator>
</Repeat>
<enter/>
</Param>
</Parameters>
</CurrentDispatcher>
The DestinationApplication parameter defines the name of the application that should be given focus before the keyboard buffer is sent character data from the Sensor Edge Mobile service. The syntax of this parameter is as follows:
<Param name="DestinationApplication" value="Telnet"/>
The application name itself is specified ("Telnet" in Example 5-1), not the path to the application. On the top of the application window of most applications, this name can be seen after the document name and a dash (for example, "Doc1.doc - Microsoft Word" for the Microsoft Word application).If more than one of these application windows are open, then the application window closest to the front (the first window in the "z-order") is brought to the front and acted upon.
The RFIDReadMacro parameter defines which of the key sequence macros in the configuration file should be used for observation data from RFID reads. This parameter allows the definition of many key sequence macros in the configuration file, and one of those to be selected by putting the desired macro's name in this parameter. The syntax of this parameter is as follows:
<Param name = "RFIDReadMacro" value = "TelnetMultipleRFID"/>
The BarcodeReadMacro parameter defines which of the key sequence macros in the configuration file should be used for observation data from barcode reads. This parameter allows the definition of many key sequence macros in the configuration file, and one of those to be selected by putting the desired macro's name in this parameter. The syntax of this parameter is as follows: <Param name="BarcodeReadMacro" value="TelnetMultipleBarcode"/>
The Keyboard Dispatcher sends data collected by Sensor Edge Mobile to the receiving application as if it were typed by the user. To accomplish this for an existing application, you first position the focus of the browser or application window on a specific input control that is to receive the data. For instance, sending the tab character a certain number of times to position the focus on a particular input field. You may also then want to generate an Enter key press to cause the data to be submitted or otherwise acted upon. To specify the specific sequence of keystrokes that the application requires, you must define a key sequence macro (illustrated in Example 5-3).
Example 5-3 Defining a Key Sequence Macro
<Param name="TelnetSessionRFID" type="KeySequenceMacro">
<tab/><tab/>RFID<sp/>Data<tab/>
<data name="tag_id"/>
<tab/>
<data name="data"/>
<enter/>
</Param>
In Example 5-2, the parameter is given a unique user-defined name ("TelnetSessionRFID"), and its attribute type must be specified as "KeySequenceMacro". The body of the macro contains a sequence of control characters, a space specified (<sp/>, and one or more <data> tags to indicate where the data values should be sent, as if the user typed them at the keyboard.For example, if the values coming from the Sensor Edge Mobile for the data value "tag id" is "123456789" and the value for "data" is "0A0B0C0D0E0F" from an RFID tag then the sequence sent to the application is:
\t\tRFID Data\t123456789\t0A0B0C0D0E0F\r
Where \t indicates a tab character in the sequence, and \r indicates a carriage-return (Enter) character. This should tab across the application window to the first input field, type "RFID Data" (the space character code <sp/> is required), then tab to the TagID field and enter it, and then perform the same routine with the TagData field. Finally, it will send a carriage-return (Enter), which may be used to click a button and submit or save the data.Line breaks, tabs, and spaces in the XML are not sent to the application; you can tab and pretty-print the contents of the macro in the configuration file without getting unwanted characters sent to the application. For instance, in Example 5-4, "Macro1" and "Macro2" send the same character sequence:
To build a key sequence macro, record the keystrokes required to get to the input fields of the destination application, and where the data fields are to be typed. Then write this sequence as a key sequence macro as illustrated in Example 5-4. Finally, set the "RFIDReadMacro" or "BarcodeReadMacro" parameter to the name of the new key sequence macro ("MyMacro" in Example 5-5).
Example 5-5 Setting the RFIDReadMacro to the Name of the New Key Sequence Macro
<Param name="RFIDReadMacro" value="MyMacro"/>
<Param name="MyMacro" type="KeySequenceMacro">
<data name="tag_id"/>
<tab/>
<data name="data"/>
<enter/>
</Param>
Now events from an RFID read will generate the key sequence above, inserting the values indicated by the <data> elements.
The examples illustrated thus far only handle one set of "tag_id" and "data" data elements from an RFID tag. To make this macro work for a series of these data value pairs, you must define the concept of repetition. Specify a portion of the key sequence macro that is to be repeated, as well as what character sequence should be sent between repetitions to get the focus to the next row or field of the application using the <Repeat> and <Separator> macro elements.
Example 5-6 Defining <Repeat> and <Separator> Elements
<Param name="TelnetMultipleRFID" type="KeySequenceMacro">
<tab/><tab/>RFID<tab/>
<Repeat>
<data name="tag_id"/>
<tab/>
<data name="data"/>
<Separator>
<tab/><tab/>
</Separator>
</Repeat>
<enter/>
</Param>
Example Example 5-6 illustrates the <Repeat> and <Separator> macro elements. These specify the section of the macro that is to repeat for each data set, and what sequence should be sent between data sets. For three pairs of data observations, with"Tag_id" and "data" value pairs ("Tag1", "Data1"), ("Tag2", "Data2"), and ("Tag3", "Data3"). The sequence generated from the macro above would be:\t\tRFID\tTag1\tData1\t\tTag2\tData2\t\tTag3\tData3\r Breaking this sequence down, the portion before the <Repeat> sent once:
\t\tRFID\t
And the repeated portions <data name="tag_id"/><tab/><data name="data"/>:
Tag1\tData1 Tag2\tData2 Tag3\tData3
each separated by the <Separator> sequence:
\t\t \t\t
And finally the carriage-return (Enter) sent once:
\r
While the <Separator> sequence separates each repeated sequence, it never follows the last repeated sequence. In this example, the "\t\t" separator sequence is not be sent after the last pair of data values (in this case "Tag3\tData3").
To simulate the pressing of any of the keyboard keys that may be required by an application, special control sequences (described in Table 5-1) are provided for use in the keyboard sequence macros.
Table 5-1 Control Sequences for Keyboard Keys
| Element | Key Sequence Sent |
|---|---|
|
|
Spacebar |
|
|
Spacebar |
|
|
Enter key |
|
|
Enter key |
|
|
Backspace key |
|
|
Backspace key |
|
|
Tab key |
|
|
Shift-Tab key |
|
|
Clear key |
|
|
Escape key |
|
|
Page Up key |
|
|
Page Down key |
|
|
End key |
|
|
Home key |
|
|
Left Arrow key |
|
|
Up Arrow key |
|
|
Right Arrow key |
|
|
Down Arrow key |
|
|
Insert key |
|
|
Del key |
|
|
Control-break |
|
|
F1 key |
|
|
F2 key |
|
|
F3 key |
|
|
F4 key |
|
|
F5 key |
|
|
F6 key |
|
|
F7 key |
|
|
F8 key |
|
|
F9 key |
|
|
F10 key |
|
|
F11 key |
|
|
F12 key |
As illustrated in Example 5-6, to send a sequence of literal characters, any spaces or tabs must be explicitly entered, as in <sp/> and <tab/>. Any other tabs and spaces in the macro will be ignored as pretty-print formatting of the XML. The other reason this is done is that the XML standard for parsing tabs and spaces does not preserve all of these "whitespace" characters between elements, and this modification would alter the macro processing in ways that would be difficult to predict.
The <control char="x"/> and <data name="tag_id"/> macro elements (described in Table 5-2) specify generated control keys or positions where data should be typed.
Table 5-2 Keyboard Macro Elements
| Element | Description |
|---|---|
|
<control char="x"/> |
Control-char |
|
<data name="tag_id"/> |
Named data value |
The special <control> element generates a control sequence just as if the user held the Control key and then typed the specified character. For instance, to generate Control-B, specify <control char="b"/>.
The <data> element fetches the current value of the data in the observation event, and inserts it at the current position. The specific names and their meaning (such as "tag_id" representing the Tag-ID of an RFID tag) are made available to the application as name and value pairs. Table 5-3 describes the pre-defined values for the <data> element.
Table 5-3 Pre-Defined Values for the <data> Element
| Name | Description |
|---|---|
|
|
The name of the device generating the observation event. |
|
|
A description of the device generating the observation event. |
|
|
The timestamp of the event creation in a textual presentation format. |
|
|
The index of this event in a block (group) of events. |
|
|
The number of events in this event block. |
|
|
RFID: The TagID of an RFID tag as a hexadecimal string. The data payload is in "data". |
|
|
RFID: The data payload as a hexadecimal string. Barcode: The barcode read data as a hexadecimal string. |
|
|
Barcode: The type of barcode ("1d" or "2d"). |
|
|
Barcode: The checksum value as a hexadecimal string. |
|
|
Barcode: The encoding format. |
The <data> element also acts with the <Repeat> element (described in "Enabling the Key Sequence Macro to Handle Repeating Elements" to iterate through a sequence of data values, if multiple events are returned by a read. See "Handling Observation Events" for more information on the Òblock_indexÓ and Òblock_countÓ data values.
If no tags can be read in an RFID read, an event is returned with the "tag_id" and "data" values set to an empty string ("").
The Device Manager can "ping" devices to determine if they are alive and responsive. devices which do not respond are restarted without user intervention.
The Device Manager records the last time an event has been returned from the device and, if it has been a long time since the last event, issues a ping OS event to the driver. The driver interface contract requires that the device responds with a special response-from-ping event in a reasonable period of time. If the device does not respond in a configurable time, the Device Manager issues a shutdown command to the device. If after a period of time the device has not responded with a shutdown acknowledgement event, then Device Manager will unload the driver .dll and load and initialize a new device.
This revised ActiveX API has a number of major new features and differences from the previous beta release:
The control has no visible rendering of its own, so the designer has the flexibility to process or present the observation data in any way.
The data is returned to the JavaScript by registering a function to receive observation data events. The application can then set input fields with this data, or do whatever it pleases with it.
The new API allows simultaneous access to any of the device classes supported by the currently configured drivers. For example, RFID and Barcode data could be read from one HTML page.
Example 5-7 describes the object declaration of the Oracle Sensor Edge Mobile client control. In this example, the "event_handler" parameter registers the name of the JavaScript function that is to be called when an observation event is received. If no parameter is specified, a call to the default event handler function, "handle_event()" will be attempted. No error is returned if the function does not exist, and processing will proceed without an event handler.
Example 5-7 The Object Declaration of the Sensor Edge Mobile Client Control
<object id="SEMobileControl" name="SEMobileControl"
classid="CLSID:049BE519-EE78-4AA5-8FC8-C5AE084CB26C"
width="0"
height="0">
<param name="event_handler" value="handle_event"/>
<table><tr><td bgcolor="#FF0000">
<hr/>Unable to load Sensor Edge Mobile control.<hr/>
</td></tr></table>
</object>
The Activex API includes the following methods:
The rfid_read() method will issue a read for all tags in range. The method signature is:
var retVal = SEMobileControl.rfid_read( );
The tags read will be returned by zero or more callbacks to the registered event handler method. If the read succeeds, the return value will be zero. If it fails for any reason, a non-zero value will be returned.
The rfid_write() method issues a write for all of the tags in range. The method signature is:
var retVal = SEMobileControl.rfid_write( srcForm.srcData.value,
srcForm.srcPasscode.value );
In this example, the parameters are hidden variables in the form srcForm. The srcData variable represents the data to write, represented as a hexadecimal string, and the srcPasscode contains the pass code for a write. If the write succeeds, the return value will be zero. If it fails for any reason, a non-zero value will be returned.
The rfid_kill() method issues a kill for all tags in range. The method signature is:
var retVal = SEMobileControl.rfid_kill( srcForm.srcTagId.value,
srcForm.srcPasscode.value );
The srcTagId variable represents the TagID of the tag that is to be killed (represented as a hexadecimal string) and the srcPasscode contains the passcode for a kill. If the kill succeeds, the return value will be zero. If it fails for any reason, a non-zero value will be returned.
The barcode_read() method will issue a read of the barcode pointed to by the device. The method signature is:
var retVal = SEMobileControl.barcode_read( );
The barcode read observation event will be returned by a callback to the registered event handler method. If the read succeeds, the return value will be zero. If it fails for any reason, a non-zero value will be returned.
The set_trigger_rfid_read() method will tell Sensor Edge Mobile that when the user pulls the trigger on the device, a read of RFID data should be done. The method signature is:
var retVal = SEMobileControl.set_trigger_rfid_read();
The call is required to register the RFID read operation to the trigger pull. If the call succeeds, the return value will be zero. If it fails, there is no RFID device driver loaded, and a non-zero value will be returned.
The set_trigger_barcode_read() method tells Sensor Edge Mobile that when the user pulls the trigger on the device, a read of barcode data should be done. The method signature is:
var retVal = SEMobileControl.set_trigger_barcode_read();
The call is required to register the barcode read operation to the trigger pull. If the call succeeds, the return value will be zero. If it fails, there is no barcode device driver loaded, and a non-zero value will be returned.
The process_instruction method is a lower-level interface for the processing of instructions by drivers. It is not necessary for the currently defined RFID and barcode operations, but is made available for easy expansion of the instruction repertoire when a custom driver is used. The method signature is
var retVal=SEMobileControl.process_instruction(instruction, data);
The "instruction" is an integer value (expressed as a string) from a list of defined constants. In EdgeMobilehtml_samples is a file named SEMobileCore.js. This file's values can be included in an HTML document by using a script element as follows:
<script type="text/javascript" src="SEMMobileCore.js"></script>
Then the instruction to start an RFID read using these constants would look like:
var retVal=SEMobileControl.rfid_read();
This instruction performs the same operation as the following:
var retVal=SEMobileControl.rfid_read();
Possible values for the commands are:
Symbol Description
RFID_READ START an RFID read. The argument value is ignored. RFID_WRITE DESCRIPTION string for device generating event. RFID_KILL Timestamp of event creation in textual presentation format. BARCODE_READ Index of this event in a block (group) of events. REGISTER_TRIGGER0 Number of events in this event block. TRIGGER_PULL0 RFID: TagID of RFID tag as a hexadecimal string. Data payload is in"data".
The instruction to start a barcode read would look like:
var retVal = SEMobileControl.process_instruction(BARCODE_DEAD. "");
The equivalent method call is:
var retval = SEMobileControl.barcode_read();
The instruction to do an RFID write using these constants would look like:
var retVal = SEMobileControl.process_instruction( RFID_WRITE, "0102030405060708,123");
The hexidecimal value to write is separated from the passcode by a comma. The instruction above is equivalent to the following:
var retVal = SEMobileControl.rfid_write("0102030405060708", "123");
An RFID kill would look like:
var retval = SEMobileControl.process_instruction(RFID_KILL, "0102030405060708,123");
As with the RFID write, the hexidecimal value to write is separated from the passcode by a comma. The instruction above is equivalent to the following:
var retval = SEMobileControl.rfid_kill("0102030405060708", "123);
Finally, the instruction to register the trigger pull to a given read operation would look like:
var retval = SEMobileControl.process_instruction( REGISTER_TRIGGER0, RFID_READ);
The instruction above performs exactly the same operation as the following:
var retval = SEMobileControl.set_trigger_rfid_read();
The is_supported method has a single argument of an instruction code such as RFID_WRITE and returns true or false depending on whether or not there is a configured driver that can process this instruction. The method signature is:
if (SEMobileControl.is_supported( RFID_KILL) {//RFID_KILL instruction supported by a configured driver...}
The "instruction" is an integer value (expressed as a string) from a list of defined constants in the SEMobileCore.js file.
The registered JavaScript event handler function is called by the ActiveX control when an observation event is received. In the event handler method, the event object is referenced by the name of the ActiveX control instance. In Example 5-8 and Example 5-9 "SEMobileControl" is used as the control name.
The event data is available from the ActiveX object until the JavaScript returns from the event handler function. The data that is present in all events is available as properties, and the other data that is specific to a given event type is available by lookup. Table 5-4 lists the event data.
Table 5-4 Available Event Data
| Name | Description |
|---|---|
|
|
The name of the device generating the observation event. |
|
|
A description of the device generating the observation event. |
|
|
Returns "true" id the vent is an RFID read event. |
|
|
Returns "true" if the event is a barcode read event. |
|
|
The timestamp of event creation. |
|
|
The index of this event in a block (group) of events. |
|
|
The number of events in this event block. |
|
|
The type code for the event object. |
|
|
The subtype code for the event type. |
Example 5-8 describes an event handler function that reports on the event by using properties on the event.
Example 5-8 Event Handler Function for Event Reporting
function handle_event()
{
if ( SEMobileControl.is_barcode_read ) {
alert ("Barcode data read from " + SEMobileControl.device_name );
}
if ( SEMobileControl.is_rfid_read ) {
alert ("RFID data read from " + SEMobileControl.device_name );
}
All of these properties are only available until the event handler function has returned. As soon as it returns, the Sensor Edge Management control can again call the handler with another event, and any data associated with the last event is no longer available.When RFID tags are read, the events returned are marked as part of a block (with a read of one tag being represented as a block of one event). To reflect this, all events have a block index and a block count associated with them. If the event is a singleton, the block count and index are set to "1", while if the block contains three events, the block index and count values for the three events in the block will look like (1, 3), (2, 3), and (3, 3). The "block_index" and "block_count" properties above allow access to these values.There may be other data specific to the class of device that is associated with the event. These are represented as name/value pairs, and can be looked up with the following data() method. The data() property looks up a data value specific to an event from a specific device class. Different data names are defined for each device class, and that if the data value is not present in the current event, an empty string ("") is returned. Table 5-5 describes the defined data names and their associated device class.
Table 5-5 Data Names
| Name | Description |
|---|---|
|
tag_id |
RFID: The TagID of an RFID tag as a hexadecimal string. The data payload is in "data". |
|
data |
RFID: The data payload as a hexadecimal string. Barcode: The barcode read data as a hexadecimal string. |
|
type |
Barcode: The type of barcode ("1d" or "2d"). |
|
checksum |
Barcode: The checksum value as a hexadecimal string. |
|
encoding_format |
Barcode: The encoding format. |
Example 5-9 describes how the event handler first determines the device class (RFID or barcode) and then references data() to fetch the device class-specific data value.
Example 5-9 Fetching the Device Class-Specific Data Value
function handle_event()
{
if ( SEMobileControl.is_barcode_read ) {
alert ("Barcode data is " + SEMobileControl.data("data") );
}
if ( SEMobileControl.is_rfid_read ) {
/* Note that "tag_id" is an RFID-specific event value */
alert ("RFID tag ID is " + SEMobileControl.data("tag_id") );
}
}
The current Sensor Edge Mobile ActiveX control can be accessed as follows:
As a visible control on an HTML page containing the observation data collected by the driver.
Through the control's API, where the control is not visible on the page, but provides an API for JavaScript.
As a mixture of a visible control and the APIs in use.
This API only allows access to one device class (that is, either barcode or RFID) from a given HTML page.
|
Note: This API is deprecated in Oracle Sensor Edge Server Version 10.1.3. |
The Administration HTML page (Figure 5-1) enables you to manage Oracle Sensor Edge Mobile. Using this page, you can perform the following tasks:
Extension Configuration and Management
For drivers, the HTML page lists the configured drivers and their state (initializing, active, shutting down, or not responding). Release 10.1.3 of Oracle Sensor Edge Server Mobile 10.1.3 supports the Symbol 9000-G and Intermec IP3 with Color 700 PocketPC attached.
For Symbol 9000-G, Sensor Edge Server Mobile supports the following operations:
For the Intermec IP3, Sensor Edge Mobile supports the following:
For dispatchers, the page displays the configured driver and its current state (initializing, active, or shutting down).
Monitoring Running Status
The page provides the service status of Sensor Edge Mobile (initializing, active, or shutting down).
Service Management
The page provides a Shutdown Service button, which you use after you have configured a driver, changed a dispatcher, or edited the XML configuration file (EdgeMobileConfig.xml).
Figure 5-2 Shutting Down the Sensor Edge Mobile Service
Logging
The pages displays updates to the log entries in real time.
Performance Monitoring
For each loaded driver, the page displays counts of observation data events and the timestamp of the last event from each driver
Configuration
The page enables you to read the configuration XML file (EdgeMobileConfig.xml) and change the configuration of the file as needed.
