View Hudson HWeb Mobile Sample Configuration
Category:HWeb Mobile Devices - BlackBerry Configuration & Use
Hudson HWeb Mobile Sample Configuration
*****APRIL 2007 - document still being updated and revised*****
Hudson Mobile Setup
Due to the complex nature of the Mobile Suite, the need
for documentation that shows some sample configuration sets
has become apparent. In this document you will find a few
different configuration token groups. Each group will
explain what it attempts to accomplish and how to vary it.
Along with configuration, there will be some sample
templates.
Sample Configuration:
To start some basics about configurations must be
discussed. Namely the structure of a configuration token
and common definitions that cover many different tokens.
The structure of a configuration token (config token) is as
follows:
TOKEN_NAME=TOKEN_VALUE|SUBVALUE1|SUBVALUE2|SUBVALUE3|…|SUBVA
LUEN-1|SUBVALUEN. TOKEN_NAME is the name of the token from
the configuration token set (found at
).
This is a case sensitive name. TOKEN_VALUE is the value
that you wish the token to have. Any token can have a
subvalue associated with it. However, most tokens don’t
look at or use its subvalues so putting a subvalue on
certain tokens is pointless.
e.g.
Token with subvalue:
LOGLEVEL=1|0|1|1|1
LOGLEVEL will take the first 4 subvalues and the
TOKEN_VALUE, with each value being either 0 or 1. This
token tells the device what to log. A 1 indicates that log
statements of this nature should be logged and 0 indicates
that the log statements should not be logged.
Token with no subvalue:
COMPANY=The Hudson Group
COMPANY will tell the device what it should replace
%COMPANY% with. Now it is possible to have
COMPANY=The|Hudson|Group, but if this is the config token
then %COMPANY% will be replaced by “The”. This is because
the COMPANY token only looks at the TOKEN_VALUE for its
value.
Amongst many tokens there is a concept of on, off,
always, never, and ask. Some tokens have names that suggest
a yes or no response. In most cases they take values 1 for
on and 0 for off. An example of this would be
QUICKREZENABLED. QUICKREZENABLED=1 means that the unit is
allowed to make quick reservations. QUICKREZENABLED=0 means
that the unit is not allowed to make quick reservations.
Some tokens are not always simply on or off but you would
expect them to behave that way. These tokens take values in
the form of always, never, and ask. Always(value 0) means
that in places where the device is configured to
automatically do this action it will. Never(value 2) means
that the device should never allow this action to continue.
Ask(value 1) means that if the device can print it should
just add a menu item to allow this action. A good example
of this would be ALLOWPRINT. ALLOWPRINT=0 means that in
places where the device allows for automatically printing
(Currently only on creating a reservation) the device will
automatically print. In other places like viewing multiple
reservations the device will add a menu item to allow the
user to print if they want to. ALLOWPRINT=1 means that the
device will never automatically print, but will add the
print command to the menu where printing is a possible
option. ALLOWPRINT=2 means that the print command will
never appear and the device will never automatically print.
To start with the token configurations this document
will go over some of the more basic configuration setups.
Quick Res Configuration
To make quick reservations you will need to have the
following files airports.csv, services.csv, directions.csv,
and
fares.csv. You will also need to have your
reservation number synched up. With that done the
configuration to turn on the ability to make reservations
would be as follows:
QUICKRESENABLED=1 With this the ability to get into the
Quick Res screen is turned on.
Along with this a terminal id must be set. If this id is
not set in the terminal id column of the HudsonConfig web
page then it can be set in the configuration file with
TERMINALID. For now lets assume our TERMINALID is 123. The
configuration for this would be:
TERMINALID=123
With all the above done, it will be possible to make
reservations, however, there is no indication of where to
send these reservations once they are made. Before we can
set the appropriate configuration item a decision of how the
reservations need to get to the local system must be made.
The recommended way is to go through the HWeb Bridge which
connects to the system via a socket connection. This
provides real time results and avoids any strange issues of
text parsing. The other way that the blackberry can send a
reservation to the local system is via email. For email
delivery the HWeb Exchange server is used. For this we will
need the configuration item DELIVERYMETHOD.
For bridge delivery demonstration purposes assume that our
IP is 68.236.122.5 and assume that our PORT is 735. The
configuration would be:
DELIVERYMETHOD=68.236.122.5:735
Alternately you can set:
BRIDGEIP=68.236.122.5
BRIDGEPORT=735
For email delivery assume that our configured email address
is ReservationImport@hudsonltd.com. The configuration would
be:
DELIVERYMETHOD=ReservationImport@hudsonltd.com
However, email requires other configuration options so that
the exchange server knows how to parse and recognize a
reservation email. The problem is that different email
systems alter emails differently. So to solve this problem
the following things are needed: a means to mark the start
of import, a means to mark the end of importing, a means to
mark the end of a reservation record, what to replace spaces
with, and a code to tell the HWeb Exchange server to run the
import process. All of these are configuration items and
should match the settings in HWeb Exchange. For now lets
assume that the HWeb Exchange server has the following
settings: the marker for the start of a import is
,
the marker for the end of import is
, the marker for
the end of a reservation is
, spaces will be replaced
with
, and the import command is ImportReservation.
With this information the configuration on the blackberry
is:
IMPORT=ImportReservation
EMAILEOR=
OPENDELIM=
CLOSEDELIM=
SPACEREPLACE=
So as a recap to enable Quick Res and have the reservations
import using the bridge the configuration would look like
this:
QUICKRESENABLED=1
TERMINALID=123
DELIVERYMETHOD=68.236.122.5:735
Get Reservation Configuration
Along with making reservations it is possible to get
reservations. For this you won’t need any files. However,
you will need some configuration sets.
First Get Reservation needs to be enabled. To do this set
the following configuration item:
ALLOWGETRES=1
Now since the device can be configured to send reservations
by email or bridge the expected outcome can vary
dramatically. The device will use DELIVERYMETHOD to
determine where to send the request if the following
configuration tokens are not set, BRIDGEIPGET and
BRIDGEPORTGET.
Using our above IP and PORT info the setting for this would
be:
BRIDGEIPGET=68.236.122.5
BRIDGEPORTGET=735
With this allowed the device has two ways to get
reservations, either one at a time or a set of reservations.
Starting with getting a single reservation the configuration
item to allow this would be:
GETSINGLERESENABLED=1
However, now that the device has gotten a reservation a
decision has been made about what can be done. Currently
the available options are to mark a reservation Ready to Go,
Cancel a reservation, Charge a reservation, and print. The
configuration for these items is: ALLOWRTG, ALLOWCANCEL,
ALLOWCHARGE, and ALLOWPRINT. To turn these all on the
configuration would look like:
ALLOWRTG=1
ALLOWCANCEL=1
ALLOWCHARGE=0
ALLOWPRINT=0
Note how ALLOWCHARGE and ALLOWPRINT have the values of 0.
This is because they have values in the format of Always
(0), Never (2), and Ask (1). So in the case of Charging
reservations it must be charged before any other action can
be taken. Currently this only applies to the booking
process but may be expanded in the future. In the case
where always is not honored, the device takes on the
functionality of allow.
Now that the device can take actions with a reservation that
has been downloaded one reservation at a time the question
of how to configure the device to get more than one
reservation should be discussed. The means to get more than
1 reservation at a time down to the blackberry is to use a
RECONWHERE command. There are 10 of these that can be used
and are in the format of Label|WhereClause. Label is what
should be displayed as a menu item and WhereClause is the
where clause that should be used to get reservations from
the database. The select statement for this looks like:
Select *
From Reservations
Where WhereClause
So to set the first RECONWHERE to get all reservations with
the name ABC and have a label “Customer ABC” the
configuration is as follows:
RECONWHERE1=Customer ABC|Name=’ABC’
However, since we may want to get more reservations than
just the ones where the name is ABC we can have up to 10
different RECONWHERE commands. To do this, assign a label
and where clause to config tokens RECONWHERE1 –
RECONWHERE10.
Now, when a RECONWHERE command is successfully executed and
reservations are returned by the bridge the blackberry will
display them according to a template. The template allows
for full reservation token replacement. This template will
be applied to each reservation with a selector by each
reservation. The alias for this is: RECONTEMPLATE. An
example of this would be:
RECONTEMPLATE=MultiReservationDisplay
Where MultiReservationDisplay is an alias that exists in
your matchkeys.csv. An example would be the following file:
%ID% \ %NAME% \ %PICKUPLOCATION% \ %DROPOFFLOCATION% \
%SERVICETYPE%
The results with a blackberry set up for reservations in
Chicago looking for reservations with the name ABC could
look like this:
The circles to the left of the data are indicators to show
which reservation is selected. Currently reservation 582832
is selected.
We now have a set of reservations but we can’t mark them all
ready to go, or cancel them all, or charge them all for that
matter. We must do it one at a time. To do this click the
menu and select show reservation. This will bring up a
screen that is also template driven. This template supports
full reservation token replacement and screen items. To
configure this use the RECONTEMPLATE2 config token. An
example would be:
RECONTEMPLATE2=SingleReservationDisplay
Where SingleReservationDisplay is an alias that exists in
your matchkeys.csv file.