Introduction
To create a plugin, you can use any programming language from the .Net family, and the output should be an assembly for .Net 4.7.2, which SyrveFront will load at startup. For loading each plugin, SyrveFront creates a separate process container and loads the plugin into it, which helps avoid dependency conflicts and ensures system reliability (a failure in one of the plugins will not crash everything else). Each plugin is installed in a separate subfolder of the Plugins folder, which is by default located at C:\Program Files\Syrve\SyrveRMS\Front.Net. The plugin assembly must contain a class that has a public default constructor (without parameters) and implements the IFrontPlugin interface. Interaction between the plugin processes and the SyrveFront application is carried out through an IPC channel, and object transfer occurs either by reference (such objects must inherit from MarshalByRefObject) or by value (data classes, which must be serializable).
The entry point is the plugin class. When the plugin is started, an instance of this class is created, and its constructor can load the necessary data for operation, establish connections, subscribe to interesting events, and so on. Before stopping and unloading the plugin, the Dispose method is called, which is intended for unsubscribing from events, closing connections, and releasing other resources.
Interaction with the API begins with the static class PluginContext, which contains all functions and services:
PluginContext.Operations— operations service,PluginContext.Notifications— notifications service,PluginContext.Licensing— licensing,PluginContext.Services— all available services, including those listed above, as well as services from other API versions,PluginContext.Log— logging,PluginContext.Shutdown()— shutting down the plugin.
Main Contracts
Data Structures
Data is collected in the namespace Resto.Front.Api.Data and grouped by areas:
Organization— enterprise structure and its settings,Assortment— menu nomenclature,Orders— orders, including guests, dishes, modifiers, discounts, etc.,Kitchen— kitchen orders,Brd— abbreviation for “banquets, reservations, and deliveries”,Security— data necessary for plugin authorization,Licensing— license management,- …
Mainly, data objects are read-only — an interface with get-only properties is published for them, so the plugin cannot create new instances of such objects or modify the values of existing fields. Many objects, such as IProduct, ITable, or IUser, cannot be edited at all; they are reference data defined through the Syrve Office application. Some types of objects can be edited indirectly by applying certain actions to them. Finally, there is a special category of objects located in the namespace Resto.Front.Api.Data.DataTransferObjects, which can be created and edited on the plugin side.
Operations Service
Almost all actions are performed through IOperationService. The methods included in this interface can be divided into groups:
- data reading — obtaining all objects of a certain type (
GetProductGroups), obtaining a specific object (GetProductGroupById), obtaining related objects (GetChildGroupsByProductGroup), - data modification — single actions (
PrintBillCheque), batch actions (viaCreateEditSession), - other operations — displaying messages (
AddWarningMessage), checking permissions (CheckCanEditOrder), and others.
When working with IOperationService, the initiative is on the plugin side.
Notifications Service
INotificationService allows subscribing to interesting events. Notifications about data changes are implemented using the Reactive Extensions (Rx) library, and events are published as IObservable<T> sequences, where T is the event argument (the changed object). Rx allows working with the event stream as conveniently as LINQ with IEnumerable<T>. For an introduction to the capabilities of reactive programming, there is a good resource Introduction to Rx. Here, you can also subscribe to operations such as opening or closing a cash shift, printing a service or cash receipt, and so on. In addition to directly notifying about the operation being performed, additional capabilities may be available; for example, when closing a cash shift, you can print an additional report, when printing a receipt, add marketing information to it, when transitioning to the payment screen, add a gift dish to the order and payment from the bonus account, and some operations can even be canceled by generating an OperationCanceledException.
When working with INotificationService, the initiator of actions is SyrveFront, and the plugin is the observer.
Examples
In addition, the SDK includes several plugin examples in source code. It makes sense to familiarize yourself with them before starting to develop your own plugin.
SamplePlugin
This example demonstrates various scenarios for using the API:
- adding promotional information to receipts,
- working with orders (creating an order, adding guests, adding and removing dishes and modifiers, changing the number of servings, printing service receipts and pre-receipts, payment, etc.),
- working with deliveries,
- working with banquets and reservations,
- working with client directories, streets,
- displaying non-modal notifications on the terminal screen,
- viewing the enterprise structure (halls, tables, employees),
- viewing the hierarchical menu,
- viewing kitchen performance statistics,
- managing license connections,
- registering additional operations in the SyrveFront menu,
- …
CustomerScreenPlugin
This example represents a ready-made implementation of a customer screen for terminals with two monitors, where the main monitor, facing the cashier, displays the SyrveFront application, and the additional monitor, facing the customer, shows the enterprise logo and promotional videos, displaying a simplified view of the current order.
Resto.Front.Api.SampleScalePlugin
An example of a plugin that implements integration with scales. It shows how to connect and use scales that are not natively supported through the plugin.
Resto.Front.Api.SampleCashRegisterPlugin
Demonstrates working with arbitrary fiscal registrars.