Order Change Notifications via httpordernotify

Introduction

The interface is designed for sending the information on cash station events through the HTTP protocol to the address indicated in the driver parameter.
The main task is to transfer data on order changes, but other cash station events are also supported.

There are two variants to set up notifications:

Using the mailing mechanism for version 7.6.5.440 and later
Via HTTP Order Notify interface for versions earlier than 7.6.5.440

Procedure

Once started, the driver waits either for the cash station events or for the cash server to shut down.

Events are sent by the driver strictly in FIFO order. At the moment, the maximum number of events in the queue is 256. Once it is reached, newer events are not accepted until there is space for them. This mechanism is intended to prevent memory overflow and a cash server crash in case it is impossible to send messages, for example, if the event reception server does not respond.

For each address, there is a separate mailing list, as well as a separate log file. After the cash server is stopped, pending events will not be sent.

There is no waiting interval (timeout) for data delivery as the driver tries to send data immediately upon their arrival.

The driver is loaded once the cash server is started. Regardless of the cash station availability, the message on the cash server start with the Situation = 1 is put on a queue. This event is similar to the ordinary cash start but with a limited number of nodes.

An example message appearing after cash server loading and initializing:

<?xml version="1.0" encoding="utf-8"?>
<a RestCode="199990093" DateTime="2020-01-14T15:38:23" Situation="1" seqnumber="1" guid="{9ECCB1B5-97EE-4B88-9840-8568F05586D0}" name="Started" ShiftNum="1" ShiftDate="2019-11-18T00:00:00">
<Server id="15002"/>
<Item/>
</a>

In this event, only the cash server identifier is specified. If the address is specified in the cash server properties, the server notifies the driver about its availability. After that, the event arrives.

When the POS station is started, a similar message is queued, but it has an extended set of nodes:

<?xml version="1.0" encoding="utf-8"?>

<Item/>

</a>

It has both the extended information on the POS server and data on the POS station. This mechanism allows to separate the events of the POS server loading and POS station loading for their separate processing.

The GUID shown in the example is not a constant and can be changed.

Supported commands sent by the driver (the Situation attribute):

Situation	Event
1	POS server or POS station start
3	Order changing
4	Order calculation
5	Receipt closing
9	Closing the order
10	POS station locking (logoff)
11	Creation of a New Order
12	Opening an existing order
13	Order saving
14	Receipt deleting
18	POS station closing
21	POS station sign in
24	Switching to the receipt print mode

You will not find a detailed description of these commands here, but some commands are relatively simple while others, for example, order changing (3), can contain varying data depending on the actions that include adding or deleting dishes, discounts, modifiers, prepayments, payments; changing the dish quantity or prices, etc.

XML Examples

Signing into the POS Station

<?xml version="1.0" encoding="utf-8"?>

</Waiter>

<Item/>

</a>

Creation of a New Order

<?xml version="1.0" encoding="utf-8"?>

</Waiter>

</Creator>

</Waiter>

</Guests>

</Order>

</Author>

</Creator>

</Session>

</a>

Setup

Now you add the HTTP Order Notify driver to the POS server

Here you should define three parameters:

Name

Description and possible values

Log File

The path to the file that will be used as a driver action log. Can be missing but in this case it will be difficult to identify issues in driver functioning

LogLevel

The logging level, can take one of the following three values:

Value	Description
0 - errors only	In this mode, the log will have only the most important messages (for example, notifications on interface loading) or error messages: exceeded number of events in the queue, failure to send data to the HTTP server, etc.
1 - input xmls and errors	In this mode, in addition to the errors only mode, some other important messages are added, for example, those on the start of sending XMLs to the HTTP server address
2 - max log	The most complete logging mode that comprises the most detailed information on driver functioning including incoming and outgoing XMLs, the status of the messaging queue, etc.

DestURLs

The HTTP address to which data are sent. It is entered in the conventional URL address format. Can contain only one address. If you need to send data to multiple HTTP servers, an individual HTTP Order Notify driver must be added for each of those servers

Troubleshooting

When functioning, the driver adds information on its work to the log to facilitate localization of possible issues. A regular problem is that data does not arrive to the receiving HTTP server. In this case you should check the correctness of the address in the DestURLs parameter of the driver and the HTTP server health. If it is impossible to send data, the log will have messages containing the substring "HTTP: Post error", for example:

18.12.2019 16:25:32:343 HTTP: Post error: Socket Error # 10061

Frequently encountered error codes:

HTTP Code	Description
10061	'Connection refused' means that it is impossible to connect to the server
10054	'Connection reset by peer' means that the connection is closed by the server

In this case you should check the HTTP server settings

Messages of the type

SEND_THREAD: Signal [Send] ENTER, items in queue: 19

contain the current number of objects in the queue. Once the maximum number is reached, the log will display the following message:

XML: Can't add command. Max queue size: 256

Child pages

Order Change Notifications via httpordernotify

Introduction

Procedure

XML Examples

Signing into the POS Station

Creation of a New Order

Troubleshooting