RDPWin

RDPWin and the Kaba Interface

Click here for tutorials

Kaba Interface

This interface allows the front desk staff to issue request to encode key cards for guests at check-in time, upon changes to the reservation (date change, room move), issue replacement cards, issue new cards. The interface can also request the ATLAS system to read back the data encoded on a guest's card. RDPWin display this information.

Check-in and the Kaba Interface

Upon completion of RDPWin's guest check-in process (or other option that requires the system to prompt for keys to be encoded) the KeyCardRequest form is shown to the user and allows selection of both the number of keys to encode and the encoder to use.

Using the VingCard and Kaba/TCP-IP interfaces and the Submit button is clicked, a request file is assembled and placed in the KeyCard folder. The request file is picked-up and processed by the RDPKeyCard stand-alone application. The RDPKeyCard application returns to the RDP client the result of the encoding request of the key system using an answer file.

When using the interface protocol, Kaba Web Service, and the user clicks the Submit button, instead of creating a request file, RDPWin communicates directly with the Kaba Web Service. The RDPKeyCard application is not employed for properties using RDPWin exclusively at the front desk.

Click the Submit button on KeyCardRequest form to install an object from a new class in RDPWinCore named RDPKabaWeb which processes the request by formatting the data for the required parameters and calls the appropriate method of the Kaba/ATLAS Web Service.

ATLAS User Name

RDPWin stores an ATLAS user name and password set for each front desk user. This can be stored in Users.dat, WinConfig or some other place.

Kaba Web Service

The URL for the Web service address needs to be stored in RDPWin such as the Program Control Table for KeyCard Interface (Table PL).

RDP Key Card

RDPKeyCard currently monitors the KeyCard folder under \RDP for request files from RDP-DOS and RDPWin client computers. There is an object in memory using a separate thread for each encoder configured. When a request is found for a given encoder, that object's thread processes the request.

RDPKeyCard has two different object types that inherit a base class which does the file monitoring and TCP/IP communications. These are: (1) VingCard and (2) is the current Kaba TCP/IP interface. A third object is needed and also inherits the base.

This class continues to monitor the KeyCard folder for requests but wraps the RDPKabaWeb object to communicate with ATLAS instead of using the TCP/IP method.

The configuration for RDPKeyCard must be changed to store the UserName, Password and URL.

Cards can be encoded for reservations with a future arrival date or current system date. Select the number of cards to be encoded. The sum of People 1-4 as configured is the default setting. The arrival date is used as the "valid from" date and the preset arrival time is used as the "valid from" time. This is a pre-checkin feature. The number of keys made is stored on the Reservation Miscellaneous Tab.

Click these links for Frequently Asked Questions or Troubleshooting assistance.

09/02/2009