Activation Overview

Overview

RLM Activation Pro allows you to deliver a pre-generated activation key to your customer, and when they are ready to use your product, a transaction with the activation server running at your site allows the license to be fulfilled without manual intervention. When using activation, there is no need for you to get your user’s hostid information - this is transmitted to the activation server automatically.

In the case of a node-locked product, a typical scenario would be that your customer runs the product on the desired machine, and if the license had not been fulfilled earlier, the product asks for an activation key. Once the activation key is supplied, the license is retrieved transparently. From this point on, the product runs with its license in place.

Floating licenses would operate in a similar manner, except that the number of floating licenses to be activated is required.

RLM Activation Pro utilizes a MySQL database for storing all activation data for quick access to large amounts of activation data. The RLC back office GUI is written in PHP and runs against the same databases as the activation license generator. The Activation Pro customer portal is also part of this same interface.

The RLM kit contains a demo of the activation capability. For more information on this demo and how to run it, see Getting Started with ActPro.

How Activation Works

RLM Activation is driven by two main data items - Product Definitions and Activation Keys. The RLM License Center tool (RLC) allows you to define various products to be activated.

Product definitions consist of a product definition name, a product name, version, expiration specification, and node-locked/floating indication. In addition, product definitions can contain additional attributes for the license. All product definition attributes are described in detail in Product Definitions.

Once a product is defined, you can add additional licenses to the product definition by editing that product definition. Once the product definition is complete, activation keys can be created. An activation key specifies the product to be fulfilled, the type of fulfillment, and how many fulfillments are allowed by this activation key. In addition, activation keys allow you to specify the license expiration and/or additional attributes for the license. If any of the attributes specified in the activation key are non-zero and differ from the attributes specified in the product definition, the activation key version of these attributes will be used. All activation key attributes are described in Your Activation Database.

Once activation is set up, you give your customer an activation key, which they then use to retrieve the license for the particular machine which they are using. The license fulfillment happens via the internet, using the license generator (isvname_mklic) on your website (or on the Reprise hosted activation website if you are using our Hosted Activation product).

The request is made by your customer via either calls you make to the activation request API or the Reprise-supplied activation GUI built into the RLM web server.

If you use the activation request API (rlm_activate()), you will get another opportunity to add additional attributes to the generated license. These attributes will override any specified in either the activation key or the product definition.

Warning

The system date/time on the requesting computer must be within 7 days of the system clock on the activation server. If the clocks differ by more than 7 days, an RLM_ACT_CLIENT_TIME_BAD error status will be returned, and no license will be generated.

Activation Pro Components

RLM Activation Pro consists of 5 components:

  • Activation admin tool (RLC)

  • Activation server license generator (actpro_mklic + isvname.gen, or isvname_mklic)

  • Activation data

  • Activation request API (rlm_activate())

  • Optional activation GUI (built into the RLM web server)

The activation admin tool, RLM License Center (RLC), allows you to set up the parameters for activation: product definitions; activation keys; list of banned hosts: and other setup data. It also allows you to view records of license fulfillments.

The activation server license generator (actpro_mklic + isvname.gen, or isvname_mklic) runs on your website (in the cgi-bin directory) and processes activation requests, recording the results in the activation database.

The activation data consists of product and activation key definitions, banned host definitions, RLC setup data, as well as records of license fulfillments. The data is described in the Your Activation Database section below, and is all stored in a MySQL database.

The activation request API (rlm_activate() or the older rlm_act_request()) allows you to embed activation requests within your application or your installation tools.

The optional activation GUI is built into the RLM web server (using the activation request API) to provide a generic activation user interface.

You will always be able to provide a simpler activation user interface to your customers by using the activation request API, since you know the answers to many of the questions which the Reprise-supplied activation GUI must ask. However, you can use the activation GUI in the RLM web interface to get started without modifying your applications.

Rehostable Licenses

Activation can be set up to support rehosting of licenses by the end user without ISV involvement. This involves the use of the rehostable hostid type, which was new in RLM v9.3. A rehostable hostid is requested at the time that rlm_activate() is called, and the activation server issues the license to this hostid. Later, if the user wishes to move this license to another system, the rlm_act_rehost_revoke() call can be used to revoke the rehostable license and allow it to be activated on another system.

Note

Rehostable licenses work for nodelocked licenses only, and multiple-license product definitions cannot be activated with a rehostable hostid.

The rehostable hostid is a copy-protected file, and if the system should crash, the hostid cannot be retrieved. As an ISV, you will need a policy to deal with this situation – e.g., to give the customer another activation in order to continue. Since this situation should be rare, a non-automated request procedure might be quite sufficient. If you use the Normal fulfillment type with Rehostable licenses, the expiration date should be fixed. If you want an expiration date that is relative to the time of activation, you should use the ReActivate fulfillment type, and set the fulfillment count to the number of times you want to allow your customer to revoke and re-activate the license.

Why should Normal fulfillments use fixed license expirations? Well, when your customer revokes a rehostable license, the activation server returns the fulfillment count back to the activation key. If, for example, you issue 60-day licenses with Normal fulfillment type, your customer could fulfill the license, then on day 59 revoke that license and re-activate it and get a new 60-day license. If the activation key specifies a fixed expiration date, that is not an issue. Also, if you use a ReActivate fulfillment type, the original expiration date will be preserved on a new activation.

What happens if my customer doesn’t have an internet connection?

For cases such as this, you can create a webpage so that your customer support people can activate the license for your customer, then email it to them. The RLM kit has an example HTML file that can be customized for this use. It is called activation_example.html and it is in the examples directory of the RLM kit. Modify this file for your use, and put it on an internal site for your support people to use.