ID attribute | Description |
---|---|
requestHandler | MANDATORY. The fully qualified class name of the RequestHandler. |
presentationHandler | MANDATORY. The fully qualified class name of the PresentationHandler. |
cookies | OPTIONAL. Only applicable to HTTP channel handlers. If set to true, WebSphere® Application Server performs the session management. If set to false, the toolkit performs session management internally. If the field does not exist for a device supporting the HTTP protocol, the default is false. |
runInSession | OPTIONAL. Allows all operations to run without an application session. If the field does not exist, the default is true, to run in session. The toolkit does not require that a session be established before an operation is performed. |
The following table lists the field tags used to define a device using the XML Channel:
ID attribute | Description |
---|---|
processor | MANDATORY. Specifies the concrete implementation of the message processor class. This class must implement the com.ibm.btt.xml.MessageProcessor interface. |
The following table lists the field tags used to define a device using the HTML Channel:
ID attribute | Description |
---|---|
defaultProcessesTimeout | OPTIONAL. Determines when the CSServer checks for expired
processors. (Note: you can also configure the inactivity timeout per processor
instance by setting a value in the processorTimeout attribute of the processor
tag.) When it detects an expired processor, the CSServer fires a new CSProcessorInactivityEvent.
The application must handle this event and perform whatever housekeeping process
is required to free as much memory as possible. The fired event provides the
identifier of the expired processor and the identifier of the session under
which the processor was created. HtmlProcessorManager provides the required
protocol to remove the information related to a specific processor from the
processors table. This tag has a default value of 0, which means the processors never time out. |
The example below shows a keyed collection of channel handlers for Java and HTML clients. This keyed collection would appear in the server-side btt.xml file.
<kColl id="channelHandlers"/> <kColl id="java"/> <field id="requestHandler" value="com.ibm.btt.cs.java.JavaRequestHandler"/> <field id="presentationHandler" value="com.ibm.btt.cs.java.JavaPresentationHandler"/> <field id="cookies" value="true"/> <field id="runInSession" value="true"/> </kColl> <kColl id="html"/> <field id="requestHandler" value="com.ibm.btt.cs.html.HtmlRequestHandler"/> <field id="presentationHandler" value="com.ibm.btt.cs.html.HtmlPresentationHandler"/> <field id="cookies" value="false"/> <field id="runInSession" value="false"/> <field id="defaultProcessesTimeout" value="0"/> </kColl> </kColl>
In the external definition, multiple user agents received from client devices can be mapped to the configured channel handlers, which means the handlers can be reused for several user agents or devices. In the server configuration file (btt.xml) configure the mapping as shown in the following example:
<!-- Associate "User Agents" from a client device to --> <!-- a reusable channel handler --> <!-- "UserAgentFromSpecificCellularComsProvider" may be --> <!-- any "User Agent" being used by existing devices --> <!-- in the market belonging to any communications provider --> <!-- In this example, a channel handler named "wap" should --> <!-- be added in the "channelHandlers" section --> <!-- If description="equals" then the "User Agent" coming --> <!-- in the request must exactly match the specified id --> <!-- If description="contains" then the "User Agent" coming --> <!-- in the request may just contain the specified id --> <!-- This feature allows the system to assign multiple versions --> <!-- of a client device User Agent to a specific channelHandler --> <kColl id="devices"> <field id="UserAgentFromSpecificCellularComsProvider" value="wap" description="equals"/> <field id="WAPUserAgentv4.6.8" value="html" description="contains"/> </kColl>