|
|
You can configure an WebLogic RFID Edge Server by editing the edge.props file or by using the Administration Console. As installed, the default is to use the Administration Console.
The edge.props file is a configuration properties file for the Edge Server. It is located in RFID_EDGE_HOME/etc, where RFID_EDGE_HOME is the directory in which you installed the RFID Edge Server software.
This file is formatted as a Java properties file, where each line defines a configuration parameter. Lines beginning with a pound sign (#) character are comments and are ignored by WebLogic RFID Edge Server during processing. The file is self-documenting in that each property or set of properties is described by the comments preceding it.
The installation program writes initial configuration settings to this file.
Some setup tasks you might want to perform include:
The following sections provide information related to configuring the readers that will interact with the RFID Edge Server:
You can configure WebLogic RFID Edge Server to communicate with supported readers, printers, filters, and a workflow configuration in one of two ways:
The default behavior is controlled by a property in the edge.props file called com.connecterra.ale.dynamicConfig.enabled. The default setting for this property is true:
com.connecterra.ale.dynamicConfig.enabled = true
This means that you can, for example, configure logical and composite readers using the Administration Console. If you want to add and configure readers by editing the edge.props file, set this property to false.
Important: One group of options is configured only through edge.props, and a second group of options (those mentioned earlier: readers, printers, filters, and workflow configuration) can be configured either through edge.props or through the Administration Console. For this second group of configuration options, if you choose to use:
You can think of the dynamicConfig.enabled property as a single big switch: everything in the second group of properties is configured either through edge.props, or through the console, but not both. Therefore you should change the setting of dynamicConfig.enabled to false only after careful consideration of these implications. (The dynamicConfig.enabled property itself is part of the first group, edge.props only.)
| Note: | If com.connecterra.ale.dynamicConfig.enabled is set to true, the persistence flag, com.connecterra.ale.persistence.disabled, should be set to false (the default value) to allow reader configuration information to persist across invocations of RFID Edge Server. |
RFID Reader Reference provides detailed information about the physical reader driver parameters, acceptable values, and defaults for readers recognized by WebLogic RFID Edge Server.
In specifying an event cycle or programming cycle, an application names one or more readers of interest. This is necessary because a single Edge Server may manage many readers that are used for unrelated purposes. For example, in a large warehouse, there may be 10 doors, with three readers at each door (a total of 30 readers). In such a case, a typical ALE request may be directed at the three readers for a particular door, but it is unlikely that an application tracking the flow of goods into trucks would want the reads from all 30 readers to be combined into a single event cycle.
This raises the question of how applications specify which readers are to be used for a given cycle. One possibility is to use identities associated with the readers themselves; for example, a unique name, serial number, IP address, etc. This is undesirable for several reasons:
To avoid these problems, ALE introduces the notion of a "logical reader." Logical readers are abstract names that an application uses to refer to one or more readers that have a single logical purpose; for example, readers positioned around a door might be called DockDoor42. Logical readers may be usefully thought of as being equivalent to "locations." Within the Edge Server, an association is maintained between logical names such as DockDoor42 and the physical readers assigned to fulfill that purpose. Any event cycle or programming cycle specification that refers to DockDoor42 is understood by the Edge Server to refer to the physical reader (or readers) associated with that name.
In many cases, a single RFID reader may support the use of more than one antenna, with the ability to treat each antenna independently. The Edge Server permits such readers to be configured so that each antenna is exposed through ALE as a separate logical reader. This gives flexibility to applications to use antennas independently or in concert, by simply specifying one or more logical readers in an ECSpec.
If you decide to configure readers through the RFID Devices pane on the Administration Console, see Using the RFID Edge Server Administration Console for full instructions on configuring readers, and refer to the RFID Reader Reference for details on each reader's properties.
The remainder of this section describes the reader configuration parameters used to configure additional readers in edge.props.
Within the edge.props file, each reader is configured by including several related lines of parameter definitions. Every physical reader configuration includes a line having the following form:
com.connecterra.ale.reader.<deviceID>.class = <className>
<deviceID> is the name you assign to the reader being configured. The name must be unique among all physical reader name assignments within the edge.props file, and must consist only of alphanumeric characters, hyphen (-), underscore (_), and plus sign (+).
The physical reader name is used to refer to the reader within the WebLogic RFID Edge Server Administration Console. It also appears in the physicalReaderNames list that is returned as a part of event cycle reports that include data from this reader.
<className> specifies the name of a driver provided by BEA for the specific make and model of the reader. For example, the Reader Simulator is defined as:com.connecterra.ale.reader.SimReadr.class = com.connecterra.ale.readertypes.ThingMagicMercury4PhysicalReader
Accompanying each instance of a reader configuration is a block of additional properties that are specific to that particular reader. The properties for a given physical reader are identified by sharing a common <deviceID> within their property names. The properties required within each configuration block depend on the reader make and model - the particular properties required by each reader type are listed in the
RFID Reader Reference.
Each provisioned physical reader has one or more logical readers associated with it, one logical reader for each operational antenna. The definition of a logical reader specifies the logical reader's name, which is used when identifying the logical reader within an event cycle specification.
Each reader configuration line in edge.props looks like this:
com.connecterra.ale.reader.<deviceID>.<prop1>=<prop1value>
The <deviceID> is the same for all properties corresponding to a particular physical reader, <prop1> is the name of a property, and <prop1value> is the value assigned to that property. If a property is identified as optional, you can omit the corresponding line in the edge.props file and the default value will be used instead.
See Reader Simulator Configuration for an example of the as-shipped configuration for the Reader Simulator in edge.props.
| Note: | A single edge.props file can contain properties definitions for many readers. For testing and development purposes, you may want to keep some definitions (for example, for the simulator) in the file, but inactive. You can prevent the RFID Edge Server from trying to communicate with a reader by commenting out the first line of a reader's property definitions. |
You specify names for logical readers when defining physical readers. You can create additional logical readers by combining existing logical readers. A logical reader created in this way is called a composite reader. By defining composite readers, you can decouple applications from decisions you take at deployment time about how many readers are needed to cover a single location.
For example, suppose that today, you have four logical readers covering a location called LoadingDock23:
You specify these reader names in each ECSpec that you create for LoadingDock23.
Then suppose you discover that you really need five readers to cover LoadingDock23. If you specified single logical reader names in each ECSpec, then you would need to:
Changing every ECSpec is undesirable, especially if some applications generate ECSpec instances for LoadingDock23 on the fly.
The alternative is to define a composite reader called LoadingDock23. Initially, this composite reader is configured to contain LoadingDock23_Reader1 through LoadingDock23_Reader4. Applications that want to read from Loading Dock 23 simply specify LoadingDock23 as the sole logical reader in their ECSpec instances.
Then, when you add your fifth reader, all you have to do is:
For information on how to define composite readers, see Defining Composite Readers.
If you have chosen to configure composite readers through the Composite Readers pane on the Administration Console, see
Using the RFID Edge Server Administration Console for full instructions on configuring readers. The remainder of this section describes how to define composite readers in edge.props.
Use the following lines in edge.props to define composite readers:
com.connecterra.ale.compositeReader.composite_reader_name.members = logical_reader_1 logical_reader_2
composite_reader_name: The name you want to use for this composite reader.
logical_reader_1 logical_reader_2: List the logical (or composite) readers that make up this composite reader. Put a space between each reader name.
com.connecterra.ale.compositeReader.LoadingDock23.members= LoadingDock23_Reader1 LoadingDock23_Reader2 LoadingDock23_Reader3 LoadingDock23_Reader4| Note: | Cyclic member specifications among composite reader definitions are not allowed and will be detected. |
com.connecterra.ale.compositeReader.composite_reader_name.reportFailedMembers = false
composite_reader_name: The name assigned in the statement above to identify this composite reader.
When a reader fails, you can have ECReports include either the name of the composite reader that the failed reader belongs to OR the logical reader name of the failed reader.
true: Lists failed readers by logical reader name.
false: Lists failed reader by composite reader name. This is the default.
You can apply a transient (tag) filter to any logical reader that you configure in edge.props. Different logical readers may share the same filter settings, or have different settings.
For each transient filter you add, three parameters that control its operation:
minReads - The number of times a tag must be read before being included in the filter (i.e., visible to the event cycle).firmInterval - The maximum time (in milliseconds) allowed between reads that increase the minReads count.expiredInterval - The maximum duration (in milliseconds) for a tag not to be read before expiring from the filter.
These parameters control the filter in the following way. A tag is considered "soft" until it has been read minReads times, with no more than firmInterval milliseconds passing between each of those reads. A "soft" tag is not included in the filter's output, and therefore will not be considered by any active event cycles. If a "soft" tag is not read for more than firmInterval milliseconds, the count starts over again the next time the tag is read.
When the count reaches minReads, the tag becomes "firm." A "firm" tag is included in the filter's output, and will be considered by any active event cycles that use this logical reader. A "firm" tag remains "firm" even if the tag is not read in every read cycle, until it is not read for expiredInterval milliseconds. When that happens the tag is considered "expired." The next time the tag is read, it will be considered "soft", and the filter process starts again.
Setting firmInterval to -1 means that the count for a given tag will continue to increase towards minReads regardless of the time between reads, until the filter is reset. Setting expiredInterval to -1 causes any "firm" tag to remain "firm" until the filter is reset.
When choosing values for firmInterval and expiredInterval, you must be aware of the rate at which the logical reader performs read cycles. For most physical reader types, this is the defaultRate parameter times the number of active logical readers. If the firmInterval is less than this, tags will never become "firm" and no tags will be reported to any event cycle. Likewise, if the expiredInterval is less than the defaultRate parameter times the number of active logical readers, then it is equivalent to specifying an expiredInterval of zero.
To add a transient filter to a logical reader, add the following settings in the edge.props file. First, add the following lines to define a named filter (in the example, the filter is named myfilter1):
com.connecterra.ale.filter.myfilter1.class=
com.connecterra.ale.filtertypes.TransientFilterFactory
com.connecterra.ale.filter.myfilter1.minReads = 3
com.connecterra.ale.filter.myfilter1.firmInterval = 1400
com.connecterra.ale.filter.myfilter1.expiredInterval = 1400
Then, for each logical reader to which you want to add the filter, add a line like this (in the example, the logical reader is named myreader):
com.connecterra.ale.logicalReader.myreader.filters = myfilter1
To apply the same filter parameters to more than one logical reader, you may specify the same filter name for more than one reader. Even though more than one logical reader refers to the same filter name, each logical reader is processed by a different filter instance.
WebLogic RFID Edge Server supports the following 64-bit tag formats as defined by the EPCglobal Tag Data Standards Version 1.1:
When encoded onto 64-bit tags, these tag formats require an external translation table to translate the EPC Company Prefix Index field of the tag into an EAN.UCC Company Prefix. EPCGlobal supplies a translation table at this URL (that WebLogic RFID Edge Server uses by default):
http://www.onsepc.com/ManagerTranslation.xml
| Note: | WebLogic RFID Edge Server installations include a copy of this file in the etc subdirectory. |
Alternatively, you can specify a local file as the source of the translation table by changing the value of com.connecterra.ale.epcIndexTableURL in edge.props to file:///c:mydir/myfile.xml, where myfile.xml has the general form:
<GEPC64Table>
<entry index="1" companyPrefix="0037000"/>
<entry index="2" companyPrefix="0041333"/>
...
<entry index="16383" companyPrefix="0614141"/>
</GEPC64Table>
| Note: | The file:/// (three slashes) is the required format for specifying a file in this context. |
If a file name is specified without an absolute path, the path given is assumed to be relative to WebLogic RFID Edge Server's ./etc directory. You may also specify a list of URLs, separated by spaces:
com.connecterra.ale.epcIndexTableURL = http://www.onsepc.com/ManagerTranslation.xml file:///c:/mydir/myfile.xml
The Edge Server will try each URL in turn, from left to right, until it successfully reads from one of the URLs. You can use this syntax to specify the EPCglobal table as the primary source, and use the local file syntax as a backup in case the EPCglobal site is unreachable.
WebLogic RFID Edge Server supports the following 96-bit tag formats as defined by the EPCglobal Tag Data Standards Version 1.1. These tag formats do not require an external translation table.
The Reader Simulator provides a minimal simulation of a ThingMagic Mercury4 reader with two antennas running on your local system on port 5050. To modify the default Reader Simulator configuration using the Administration Console, you can enter properties into the Reader Configuration dialog box; for information on how to do this, see Using the RFID Edge Server Administration Console.
If you are using edge.props for reader configuration, the following properties are the as-shipped defaults for the Reader Simulator:
com.connecterra.ale.reader.SimReadr.class =
com.connecterra.ale.readertypes.ThingMagicMercury4PhysicalReader
com.connecterra.ale.reader.SimReadr.hostname = localhost
com.connecterra.ale.reader.SimReadr.port = 5050
com.connecterra.ale.reader.SimReadr.defaultRate = 0
com.connecterra.ale.reader.SimReadr.uhf2LogicalReaderName = ConnecTerra2
com.connecterra.ale.reader.SimReadr.uhf1LogicalReaderName = ConnecTerra1
See Two Approaches to Configuring Readers: edge.props or Administration Console for a discussion of these reader-configuration mechanisms.
With minor modifications to the command that starts the Reader Simulator in the RunReaderSim script, the simulator can provide a minimal simulation of a Printronix printer. For information on configuring and using the Reader Simulator, see
Using the Reader Simulator.
You can configure the Edge Server to either keep or discard state data each time you stop and start the Edge Server. "State data" means:
ECSpec instances, PCSpec instances, EPCCacheSpec instances, and subscribers that you create through the ALE and ALEPC APIs.ECSpec, PCSpec, EPCCacheSpec information including the number of subscribers for a given ECSpec, PCSpec, or EPCCacheSpec, the number of times it has been activated, and the date/time of last activation and report delivery.
You configure how you want to handle state data by editing edge.props, as described below.
The Edge Server also includes a utility that removes all state data. For information on how to use this utility, see Using ClearEdgeServerState to Delete State Data.
Table 8-1 describes the edge.props properties that define how the Edge Server handles state data:
How frequently to save different types of state data. Can be zero or a non zero positive integer (milliseconds).
|
The ClearEdgeServerState utility removes all state data that you are storing in your state data directory. After you run ClearEdgeServerState, your Edge Server will start with no ECSpec instances defined. This ClearEdgeServerState utility also removes all dynamic configuration data. Be sure that you want the Edge Server in a newly installed stated before you the use this utility.
ClearEdgeServerState as appropriate for your environment:
Windows: From a command line in the RFID_EDGE_HOME\bin directory, type:
ClearEdgeServerState.bat
UNIX: From the RFID_EDGE_HOME/bin directory, type:
ClearEdgeServerState.shClearEdgeServerState displays a confirmation message warning you that running ClearEdgeServerState will reset the Edge Server to the state it was in when it was newly installed, and that client applications that depend on Edge Server state may fail.| Note: | If you run ClearEdgeServerState with the -force flag, no confirmation prompt is displayed. |
YES
To configure the HTTP notification driver, you can use the edge.props timeout values shown in Table 8-2.
com.connecterra.ale.notificationDriver.http.class =
com.connecterra.ale.notifytypes.HTTPNotificationDriver
com.connecterra.ale.notificationDriver.http.connectTimeout = 5000
com.connecterra.ale.notificationDriver.http.readTimeout = 10000
WebLogic RFID Edge Server installations support an SNMP Log Handler, which creates SNMP traps from WebLogic RFID Edge Server log event messages and sends them to one or more configured destinations (called trap sinks). Typically, these destinations are SNMP-based Network Management Systems.
The default installation of WebLogic RFID Edge Server does not enable the SNMP Log Handler. To enable it, use the following instructions to edit the etc/logging.props.edge file. This file contains Java property definitions that control which log messages are forwarded to which handlers.
com.connecterra.mgmtagent.SNMPLogHandler to the comma-separated list of handlers in logging.props.edge.handlers = com.connecterra.mgmtagent.SNMPLogHandler
WARNING or SEVERE to avoid excessive numbers of traps.com.connecterra.mgmtagent.SNMPLogHandler.level= WARNING
sink1 in the following example, and up to four configuration properties. The hostname property is required; the port, snmpversion, and community properties are optional.com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.hostname =
myMgmtStation.acme.com
# port is an optional property. The default SNMP UDP port is 162
com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.port = 162
# snmpversion specifies the version of the SNMP protocol SNMP traps
# directed to this trapSink will be encoded in. This is an optional
# parameter, which if present must be set to either "v1" or "v2c". The
# default value is "v2c".
com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.snmpversion = v2c
# community specifies the community string that appears in SNMP trap
# messages. This is an optional parameter; its default value is "public"
com.connecterra.mgmtagent.SNMPLogHandler.trapSink.sink1.community = public
The MIB files can be found under share/mibs in the WebLogic RFID Edge Server installation directory.
To use the JMS notification driver, you edit various WebLogic RFID Edge Server configuration files to include JMS specifications, which is covered in this section. In addition, you set up a Java Naming and Directory Interface (JNDI) provider and JMS server, which is covered in Setting Up the JNDI Provider and JMS Server.
To use the JMS notification driver, edit the following Edge Server configuration files:
RFID_EDGE_HOME/etc/edge.props (see edge.props)RFID_EDGE_HOME/etc/jms.options (see jms.options)RFID_EDGE_HOME/etc/naming.props (see naming.props)
Find the notification driver properties, and under the property com.connecterra.ale.notificationDriver (shortened to ND in the following example), edit the JMS notification driver properties as follows.
com.connecterra.ale.notificationDriver.jms.class = com.connecterra.ale.notifytypes.JMSNotificationDriver
ND.jms.default.namingPropertiesFile line, then set it to the file name of the JNDI naming properties file. The file name may include either an absolute path or a path relative to the location of edge.props.com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile = naming.props
See naming.props.
ND.jms.default.namingInitialContextClass line. Setting this optional property configures the JMS Driver to use the specified class to perform JNDI lookups. The value of this class must be a valid Java class that is available in the system classpath. The value defaults to javax.naming.InitialContext, which is used when this property is not specified. Other values for this class are:
javax.naming.directory.InitialDirContext
javax.naming.ldap.InitialLdapContext
See the Javadoc for these classes when deciding which class to use.
Edit the JMS_LIB environment variable to indicate the location of the JAR and ZIP files provided by your JMS vendor that provide the naming context factory class (as you previously specified in edge.props) and all other classes required by JMS clients for your JMS vendor's implementation. Vendor-specific samples of JMS options are in samples/JMSSamples.
The exact convention for setting this environment variable depends on your operating system and shell environment.
For WebLogic Server, JMS_LIB must contain the location of wljmsclient.jar; wlclient.jar must also be in the same path. These files are normally installed in the WebLogic Server product installation directory (WL_HOME) in WL_HOME/server/lib; for example, in /bea/weblogic92/server/lib. An alternative is to add both JAR files to the CLASSPATH.
The naming properties file is used to initialize the instance of the javax.naming.Context class. The names and values of the properties specified in the file are used as Context environment properties, as with, for example, the properties from the BEA naming.props file:
java.naming.provider.url=t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
A naming.props file resides in the RFID_EDGE_HOME/etc directory. You can copy other sample files from vendor-specific examples located in:
RFID_EDGE_HOME/samples/JMSSamples/<vendor_name>/etcTo create a naming properties file:
naming.props file from the appropriate JMSSamples/<vendor_name>/etc directory to the RFID_EDGE_HOME/etc directory. (You do not have to name the copy of the file naming.props. What matters is that the file name you use matches the value you set for the namingPropertiesFile property in the next step.)edge.props:com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile
For example, if you copy the BEA naming.props file to etc/naming.props.BEA, the edge.props entry would be:
com.connecterra.ale.notificationDriver.jms.default.namingPropertiesFile = ../etc/naming.props.BEA| Note: | In general, the properties in a naming properties file are considered default values, and can be overridden by a notification subscription URI (by adding the equivalent property to the notification URI as a query parameter). However, when configuring a SAF client, you cannot override naming properties by using a notification subscription URI. SAF only uses the properties in the naming properties file. |
To use WebLogic RFID Edge Server's JMS notification driver, you need to set up the following components in your environment:
The WebLogic RFID Edge Server JMS notification driver in the Edge Server uses the JNDI provider to obtain the necessary JMS objects for sending JMS messages. Examples of JNDI providers include:
You need to configure the JMS server with the appropriate destinations: queue or topic. Each vendor provides administrative tools for configuring the JMS server.
The following sections include configuration instructions for the following vendors:
Use the BEA WebLogic Server Administration Console (for example, http://<wlhost>:7001/console) to configure the JNDI provider and JMS server.
For example, use the following Administration Console page flows:
Services, Messaging, JMS Servers
Create a JMS server. Example: jms_server1
For information on configuring JMS in WebLogic Server 9.x, see Configuring and Managing WebLogic JMS.
Services, JMS, Servers, jms_server1, Configure Destinations, Configure a new JMS Queue
Create a new queue with name (example: TestQ) and JNDI name (example: jms/TestQ)
Note that BEA provides weblogic.jms.ConnectionFactory and weblogic.jms.XAConnectionFactory as default connection factories.
For information on WebLogic JNDI, see Programming WebLogic JNDI.
For additional information, see the WebLogic Server System Administration Documentation:
Use the WebSphere Application Server Administration Console (for example: http://<was_host>:9090/admin) to configure the Internal JMS Server and to configure a listener port.
For example, use the following Administration Console page flows:
Servers, Application Servers, server1, Server Components, JMS Servers
Add queue name (example: TestQ)
Servers, Application Servers, server1, Message Listener Service, Listener Ports, New
Specify Listener Port Name (for example: JMSTestListener)
Specify Connection Factory JNDI name (for example: jms/TestQCF)
Specify Destination JNDI name (for example: jms/TestQ)
Resources, WebSphere JMS Provider, WebSphere Queue ConnectionFactories, New, Create an object for ConnectionFactory "TestQCF" with JNDI name "jms/TestQCF".
Resources, WebSphere JMS Provider, WebSphere Queue Destinations, New, Create an object for Queue "TestQ" with JNDI name "jms/TestQ".
Click on Save link and then Save button to apply changes to master configuration.
Stop the application server and then start the application server to utilize the saved master configuration.
Use the WebSphere Application Server Administration Console (for example: http://<was_host>:9090/admin) to configure a listener port.
For example, use the following Administration Console page flows:
Servers, Application Servers, server1, Message Listener Service, Listener Ports, New
Specify Listener Port Name (for example: MQJMSTestListener)
Specify Connection Factory JNDI name (for example: jms/MQTestQCF)
Specify Destination JNDI name (for example: jms/MQTestQ)
Click on Save link and then Save button to apply changes to master configuration.
Stop the application server and then start the application server to utilize the saved master configuration.
Use the WebSphere MQ Explorer to create a queue manager (for example: QM_host1) and to create a queue (for example: MQ_JMS_Q) under the queue manager.
Use the JMSAdmin tool to define connection factories and queues.
For example, use the JMSAdmin tool to define a connection factory with JNDI name of jms/MQTestQCF and a queue with JNDI name of jms/MQTestQ as follows:
InitCtx> define qcf(jms/MQTestQCF) qmgr(QM_host1)InitCtx> define q(jms/MQTestQ) qmgr(QM_host1) queue(MQ_JMS_Q)For additional information, see the IBM Product Publications:
The following publications are recommended:
JBoss provides a default connection factory (with JNDI name of ConnectionFactory) which can be leveraged without any additional JNDI configuration.
For EJBs (Message Driven Beans configured to receive JMS messages) deployed in the JBoss application server, the JBoss-specific EJB deployment descriptor (jboss.xml) contains the destination JNDI name (example: TestQ) to be configured. Note that JBoss automatically configures the destination JNDI name in the "queue" JNDI context for queues (example: queue/TestQ) or "topic" JNDI context for topics (example: topic/TestTopic).
For more advanced JMS or JNDI configurations, use the JBoss JMX administrative console (example: http://<jboss_host>:8080/jmx-console) to configure the JMS server and JNDI provider.
For more information, see the JBoss Administration and Development Documentation:
http://jboss.org/docs/index
Use the Application Server Admin Console (example: http://<sun_host>:4848/asadmin) to configure the JNDI provider and JMS server.
For example, use the following Administration Console page flows:
Java Message Service, JMS Hosts
Java Message Service, Connection Factories, New
Create a new connection factory with JNDI name (example: jms/TestQCF), type of javax.jms.QueueConnectionFactory, and resource enabled.
Java Message Service, Physical Destinations, New
Create a new physical destination with name (example: PhysicalQueue) and type of queue.
Java Message Service, Destination Resources, New
Create a new connection factory with JNDI name (example: jms/TestQ), type of javax.jms.Queue, and resource enabled.
Add additional property called Name with value of PhysicalQueue.
Stop the application server and then start the application server to utilize the new configuration.
For additional information, see the Sun Java System Application Server Administration Guide. The Platform Edition 8.2 manual is available at:
Use the JMS Administration Tool to create JMS connection factories and queues.
For example, after starting the JMS Server, use the JMS Administration Tool to define a connection factory with JNDI name of TestQCF and a queue with JNDI name of TestQ as follows:
> connect host1:7222
tcp://host1:7222> create factory TestQCF queue
tcp://host1:7222> create queue TestQ
For additional information, see the TIBCO Enterprise for JMS User's Guide, located in the installation directory of TIBCO Enterprise for JMS:
JMS/doc/pdf/tib_jms_users_guide.pdf
The WebLogic JMS SAF Client feature provides a store-and-forward mechanism whereby stand-alone JMS clients can reliably send messages to server-side JMS destinations, even when a JMS client cannot temporarily reach a destination (for example, due to a temporary network connection failure). While disconnected from the server, messages sent by a JMS SAF client are stored locally on the client file system and are forwarded to server-side JMS destinations when the client reconnects.
For detailed information, see Reliably Sending Messages Using the JMS SAF Client in Programming Stand-alone Clients and Messaging (JMS) for BEA WebLogic Server® 9.2.
These interoperability guidelines apply when configuring a JMS SAF client:
The RFID Edge Server installs the 9.2 weblogic.jar file in RFID_EDGE_HOME/lib.
Prerequisites—Before configuring the Edge Server to use client-side JMS SAF:
edge.props, as described in
Setting Up the JMS Notification Driver, edge.props.| Note: | When using the RFID Administration Console to configure an ECSpec JMS subscriber for a Store-and-Forward (SAF) client, if you edit the Naming Service Message Properties values, you must restart the Edge Server for your changes to take effect. In addition, when configuring a subscriber for a SAF client, it is not possible to override naming properties in the naming.props file from the RFID Administration Console. (Note however, that when using the console to configure standard non-SAF JMS properties, the console settings do override the naming properties in naming.props.) |
Follow these steps to configure the Edge Server to use client-side SAF JMS Notifications:
ClientSAFGenerate utility to create a JMS SAF client configuration XML file and then copy it to the /etc directory in your RFID Edge Server installation; for example, RFID_EDGE_HOME/etc/SAFClient-jms.xmlFor detailed instructions, see Generating a JMS SAF Client Configuration File in Programming Stand-alone Clients.
Alternatively, edit the sample JMS SAF client configuration XML file located at RFID_EDGE_HOME/etc/SAFClient-jms.xml to contain your JMS connection-specific properties.
| Note: | You must enable HTTP tunneling in WebLogic Server or change the protocol from HTTP to t3 in the SAF client configuration file loginURL element. See Listing 8-1. For more information on enabling tunneling, see
Configure HTTP Protocol in the WebLogic Server Administration Console Online Help. |
| Note: | All JMS configuration modifications require you to re-generate the JMS SAF client configuration XML file and to copy the updated file to the client machine. |
ClientSAFEncrypt utility and then copy the encrypted remote passwords in the JMS SAF client configuration file. See the sample code snippet in Listing 8-1.For detailed instructions, see Encrypting Passwords for Remote JMS SAF Contexts in Programming Stand-alone Clients.
<saf-remote-context name="RemoteContext0">
<saf-login-context>
<loginURL>t3://localhost:7001</loginURL>
<username>weblogic</username>
<password-encrypted>{Algorithm}PBEWithMD5AndDES{Salt}lfTxvtV1rp8
={Data}+DVLEh419/DSQwIHIEoQ4w==</password-encrypted>
</saf-login-context>
</saf-remote-context>
RFID_EDGE_HOME/etc/naming.props:java.naming.provider.url=file:pathnameToSAFclient.xml
For example, java.naming.provider.url=file:///c:\\2.1.0\\rfid_edge21\\etc\\SAFClient-jms.xmljava.naming.factory.initial=weblogic.jms.safclient.jndi.InitialContextFactoryImpljava.naming.security.credentials=the key-password text you specified when generating an encrypted password in step 2.
If the JMS server or destination queue or topic is unavailable, messages will be stored locally on the client. The default location for stored messages is in the RFID_EDGE_HOME/etc/stores/ directory.
edge.props (see edge.props) and restart the Edge Server.
You can now start your own application development, using the ALE API. For complete reference information, sample applications, and code walkthroughs, see Programming with the ALE and ALEPC APIs.
|