FAQ

Some hints on troubleshooting.

How to test?

Basic testing of the communication

To test if the communication through sockets works, use an TCP/IP tool like socket workbench to test the connection. Socket Workbench can be found here:

SocketWorkbench

You can start it twice to run as a server and as a client. Both instances can send records to your system by using the Send button:

Important hint: You need to check the box “Binary data preceded by “\”” to send the EOT at the end of the string as \04. You find these checkboxes by clicking on the “>>” button (Show transmission options) on the lower right:

Creating an alias for a dynamic IP using dyndns.org

Create a new account here: https://www.dyndns.com/account/create.html

Once you are signed in, you can “Add a New Hostname“ here: https://www.dyndns.com/account/services/hosts/add.html

Choose a host name and click on “Use auto detected IP address“ which is shown underneath “IP Address”. “Service Type” should be “Host with IP address”.

Tell us the IP address you created and we can set the interface accordingly. Whenever your dynamic IP address changes, you can go back to https://www.dyndns.com/account/services/hosts/ and click again on “Use auto detected IP address“ to update the address.

Testing against our server

We provide a server for testing purposes. When your implementation is ready to be tested, we will send you the IP address and ports of this server.

You can connect to this server using remote desktop. (If you are using windows, use mstsc /console so that you will see the debug window). The IP of your server must be known in our interface so that the data can be sent to your server. If you work with a dynamic IP, you can use dyndns.org to create an alias that can be used by our interface. See Creating an alias for a dynamic IP using dyndns.org

To set the IP of your server in our interface, open a command prompt and change to the home directory of SIHOT which is usually c:\sihot on our test servers.

In the command prompt, you can use scmd set sxmlif –h 1.2.3.4 to set the interface to connect to the host 1.2.3.4 . Likewise, you can use the parameter –P (capital P) scmd set sxmlif –P 4711 to change the port to which our interface will connect on your server to 4711 (the default value is 14773).

When you set the value of –p (small p) to a different number, you change the port on our server to which your interface tries to connect. (The default of this port is 14774).

These changes only take effect after (re-)starting the interface. To (re-)start the interface, you can use scmd sta sxmlif . The interface can also be started in a debug mode. To do this, you need to start the interface using scmd stc sxmlif .(stc for console instead of sta) This will open a separate window where all the exchanged data is shown:

How can I generate some records in SIHOT?

Once you are connected to our server, you can use SIHOT to create the records you want to test.

There is an icon to start SIHOT and an icon to start a command prompt in the current SIHOT directory. You will find the log file in this directory and you can check it e.g. with gvim which is installed on the server. The default name of the log file is sxmlif.log but it may vary if more than one user is testing at the same time and therefore, several instances of the interface are running. Start SIHOT by clicking on the icon on the desktop. You don’t need to logon, this happens automatically. There is a short description of the basic handling of SIHOT available. It’s called “SIHOT Starter Manual”. It explains how to create reservations, perform check-ins and check-outs, and more. Of course, all these actions will generate the records specified in this XML documentation. If you need the starter manual, we’ll send it to you. Therefore, here are just two notes on how to generate COS and WU records:

To generate COS records, go to “Phone”, “Housekeeper’s status information”:

Move to a room that is checked in by using the blue arrow to the right which you can find under "Administration". Then you can change the “Outside line facility” to 01 (or 02) and then click on “Modify”:

To generate WU records, go to “Phone”, “Wake-Up calls” and click in the list box. Then hit "Insert" on the keyboard and enter the number of a room that is checked in, e.g. 101. Enter Date and Time and hit "Enter" on the keyboard. To delete this wake-up call, you can hit on "Delete".

How can I test the FSOA record?

To test this record, you need to check-in a guest and to make sure he’s allowed to view his bill on the pay-tv. You can set this also in the Housekeeper’s status information:

If Pay-TV is set to “2 Bill View”, the SOA will be sent to your listening port, NOT on the same socket on which you sent the FSOA. On this socket, you’ll receive the ACK.

Why does the interface not receive the data sent?

The XML interface reads the data and expects an EOT at the end of the data. If this EOT is missing, the interface will run into a timeout.

Who keeps track of the Transaction Number TN?

Each system increases the own TN after the start-up of the interface. So the TN of a message sent by SIHOT may be 4711 while the TN of a message sent by the external system may be 815. The TNs from both sides may also overlap without causing problems.

Where do I send the ACK on a message?

As shown in Communication, the ACK is sent back on the same socket connection where the message came from. It is NOT sent to the listening port of the sending system. After sending the ACK, close the connection.

How do I handle unknown tags or records?

The interface uses an XML structure so that tags or records can be added any time. Any unknown tags or records should be ignored and the rest of the record should be evaluated as if it had been sent without the additional tag.

Should tags be separated by a line feed?

It does not matter whether the records are sent in one line or the tags are separated by line feeds. Both will be evaluated in the same way. If a message contains a line feed WITHIN the contents of a tag, this line feed should be evaluated and not ignored. This could e.g. be sent for an EXMSG containing several lines.

These two records are identical:

<?xml version="1.0" encoding="ISO-8859-1"?>
<SIHOT-Document>
  <TN>4790</TN>
  <OC>ACK</OC>
  <RC>0</RC>
</SIHOT-Document>

and

<?xml version="1.0" encoding="ISO-8859-1"?><SIHOT-Document><TN>4790</TN><OC>ACK</OC><RC>0</RC></SIHOT-Document>

Is the order of the tags fixed?

No, the tags can be sent in any order. An XML parser should be able to parse the tags without the need of a specific order.

When should postings be sent?

The CO record is sent when the Check-Out is completed. At that time, the account is already deactivated and it is not possible any more to post any charges. Therefore, any charging records (PS or PE) need to be sent before the Check-Out, preferably at the moment when the charge accrues, e.g. upon completion of a phone call or when ordering a movie.

What is the difference between RN and PH?

The tag <RN> signifies the room number whereas <PH> signifies the extension number of a phone in a room. There may be up to 5 phone numbers in any given room. Room numbers are strings, meaning 0101 is different from 101 while extensions are numbers, meaning 00101 is the same as 101.

What is the difference between SWU/PWU and WUN?

The interface sends two types of records. The PABX should use either SWU and PTU or WUN. When using SWU and PTU, the PABX stores the wake up calls internally – in case of PWU a daily wake up call until check-out. When using WUN, the PABX sends a wake up call to the extension immediately, all wake up calls are stored in SIHOT. The answer WA needs to be sent in both situations with the date and time as sent by SIHOT in the SWU/PWU or WUN record. The WUN record does not have a date so the WA needs to use the current date then.

What is the difference between CO and PCO?

The interface sends a PCO when a guest pays his bill but does not leave yet. The interface sends a CO when the guest leaves. After receiving either of these records, no further postings to the account are allowed. After a PCO, some records like wake up requests are still possible though. See Pre Check-Out.

How should I deal with PCIIDs that went lost?

Interfaces that evaluate CR records and depend on the PCIID to identify a guest should be aware of the fact that a guest-stay can be deleted from a reservation and thus the PCIID will not show up any more in any records.

A CR record will always contain a complete list of all the guests attached to the specific reservation at the time of sending the record. So if a previously sent CR record contained a PCIID and a new CR record with the same RNO does not contain this PCIID any more, the guest-stay was deleted from the reservation and should be deleted in the receiving system as well.

Note: if the interface evaluates FC records, too, the database can be checked against the information contained in the FC record. It will always include all current reservations and all current PCIIDs. Any PCIIDs that are known in the receiving system but missing in the FC record should be deleted in the receiving system.

How are suites being handled?

When a room number defines a suite and not a single room, the rooms implied in this suite are sent within the tag <ROOMSIMPLIED>. Alternatively, the other system can store the suite numbers and the implied rooms when the system is set up and later handle these numbers accordingly. In this case, the tag <ROOMSIMPLIED> can be ignored.

Example

The other system receives the following record (abridged):

<OC>CI</OC>
<HN>4711</HN>
<RN>100</RN>
<ROOMSIMPLIED>
  <RN>101</RN>
  <RN>102</RN>
</ROOMSIMPLIED>
...

This will cause a check-in of the suite 100 if this is defined in the other system or of the rooms 101 and 102 if suites are not defined. With an access control system, a check-in (or create card) of the suite 100 would mean the creation of a key that opens the rooms 101 AND 102. Likewise, it would allow the use of video on demand in both rooms if the other system is a video on demand system.

Notes:

• When a record (CI, CO, RM, PCO, …) for a “normal” room is sent, the tag <ROOMSIMPLIED> is not present.
• In the RM record, the <ROOMSIMPLIED> will contain <RN> for the new room and <ORN> for the old room. See Room Move.
• Since each room can contain up to five extensions, PH can go beyond PH4, up to 5 times the number of rooms implied.
• The COS record is sent separately for all rooms implied.
• Postings can be sent with the number of the suite or with the number of any of the rooms implied. They will always be charged to the suite since there is no account on any of the rooms implied.

Why room move (RM) instead of CO/CI?

When a guest moves from one room to another, a RM record is sent so that all data connected to the guest (e.g. stored messages) can be moved from the old to the new room. When a RM record is sent, the CO and CI records are not sent but implied.

Can I send any text in the ORG tag?

Yes, you can. The text identifies the workstation that sent this record.

Why is a CI record missing?

A CI record is only sent for owners of an account. So if two people share a room, there is only one CI record for the person who has an account.

How do I know which number to use? (Bed, room)

Any record containing <BEDSIMPLIED> also contains <NR_FOR_THIS> which defines where the record originated from. This number can be the number of a suite when the whole suite was processed, of a room when only the room was processed or a bed if only a bed was processed. Unless you need to perform an action for all numbers affected by this record, you can always rely on using solely <NR_FOR_THIS> or <KCID_FOR_THIS> if you need the keycard id for this number.