The Difference in Synergy Device Licensing

Experienced Synergy developers are familiar with traditional Synergy server-based licensing. When a Synergy application starts up, it sends a license login request to a Synergy license server. If the quota for that license has not been reached, the request is granted and the program can proceed. Otherwise, the user is prevented from running the application. This licensing model has worked very well for many years over a large selection of computer platforms supported by Synergy DBL. However, this model makes a big assumption: that the client program can connect to the license server every time the program is run.

Over the past few years devices have taken hold of the industry. Most devices are connected to the Internet; however, assuming a device can always connect to a license server sitting somewhere locally on the network all the time is a mistake. Sometimes devices are used in scenarios where they are purposely not connected to any network or to the Internet. For example, delivery drivers may download their schedules in the morning and not reconnect their devices to the network until they get back later in the day. This type of disconnected computing does not fit well with the traditional Synergy licensing model.

Device licensing is a new 10.3 licensing model that supports a “sometimes connected” scenario. That is, at some point the device has the ability to connect to the Internet. When this happens, the device can be authorized to use a license for 30 days. Before that 30-day period is over, the device renews the license with the Internet-based license service for another 30-day period. This ability to be connected only sometimes is a great advantage and suits the work environments in which some devices are used.

It is important to note that traditional Synergy licensing makes a login request every time the program is run. If the program cannot reserve a license, the program is prevented from executing. Device licensing is a bit more forgiving. When the program is run for the first time, the device license client runtime attempts to connect to the device license service to reserve a license using authorization information entered by the user. If it can connect, the request is made, and, if the authorization information is correct, the license is reserved for 30 days. If it can’t connect, or if the authorization information is incorrect, the client program is put into a 7-day grace period, and the client program is allowed to run unobstructed for those 7 days. While under the grace period, the user is re-prompted to activate every time the program is run. Once successfully activated, the program will run, unprompted and unobstructed, for 30 days. During the last 7 days of that period, the device licensing client runtime will quietly attempt to synchronize the license to renew the licensing period for another 30 days, and it will continue this cycle every 30 days until the license subscription expiration is reached. If the customer is unable to activate the device before the initial grace period ends, the runtime will prevent the application from starting.

As previously described, for traditional Synergy licensing a Synergy license server must run somewhere on the network on which the client runs. For devices that are not always on the local network, that would mean the license server would have to run on the device itself. However, installing a license server on every device requires too much overhead and a lot of unnecessary installations on the client, making the configuration of regular Synergy licensing unwieldy and impractical for devices.

In contrast, device licensing uses an Internet-based license service to make licensing requests. For device licensing to work, each device must have the device licensing client runtime installed and HTTPS access to the device license service only when a device request is made. This device license service, found at https://licensing.synergex.com/licensing, supports four different types of licensing requests: get a unique device identifier, activate a device, synchronize a device, and deactivate a device. Because the service is web based, Synergex can set up an entire purchased block of licenses for a customer before the devices are given to users. This makes the installation and distribution of licenses much easier, because it reduces the amount of work required to install on each device. In addition, license administrators can access extra functionality through the Synergy licensing website for such tasks as revoking an entire license block, defining new password/token combinations, or deactivating a particular device on the website if a device becomes lost or stolen.

Traditional Synergy licensing doesn’t require any extra coding unless you use the Synergy/DE Licensing Toolkit API to enforce licensing for your application.  Support for device licensing, on the other hand, takes a bit more coding. For device licensing you will need to add the assembly attribute SynergyDeviceLicenseAttribute and provide an implementation of the ISynergyDeviceCallback interface containing three methods: Init, ActivationDialog, and Synchronize.

• Init initializes the device by making a call to DeviceLicensing.GetDeviceGUID().
• ActivationDialog should present a dialog to get a token, password, and device description and make a call to DeviceLicensing.Activate() to activate the device license.
• Synchronize should make a call to DeviceLicensing.Synchronize() to renew the device license.

Within your implementation of these methods you should handle error conditions returned from calls to the license service and display the results as you wish.

You can find WPFDeviceLicense, an example of the recommended use of device licensing in a WPF application, in Synergy CodeExchange in the Resource Center on the Synergex website. Synergy device licensing makes installing, configuring, managing, and using licenses on a device much easier. If you haven’t seen it in action yet, grab Synergy version 10.3 today and see for yourself.

Get more information about Synergy/DE 10.3.