Bringing Together What Belongs Together
Organizing your products has just become even easier with CodeMeter License Central 2.20: Product bundles allow you to structure your products even better and take the effort out of the sales process.
The Situation
Imagine a typical example: You have a set of products not unlike the popular Microsoft Office suite. The applications in your suite are a word processor, spreadsheet software, presentation software, a mail client, a notepad, and a database frontend. Each can be bought on its own, or as part of one of your package bundles: Basic, Pro, or Ultra. The table below illustrates how the bundles exist in a product matrix.
| Basic | Pro | Ultra |
|---|---|---|---|
Word Processor | X | X | X |
Spreadsheets | X | X | X |
Presentations | X | X | X |
| X | X | |
Notes |
| X | X |
Database |
|
| X |
Coordinating the Licenses
Any software consultant will know and have come in contact with the many different ways in which software licenses can be implemented. The most versatile and flexible way of coordinating the licenses for such a product matrix is to assign a dedicated Product Code to each licensable product. In this example, every license would get a Product Code of the type 1001000, 1001100, 1001200 and so on.
The choice of Product Codes depends on your actual needs. It can make sense to use number sets for different product groups, as we did with the 100xxxx for our hypothetical office application suite. We left a number of gaps in this list of codes to keep the option of licensing special sub-functions available for a later date.
The individual products can be identified by Product Codes in this manner. Alternatively, this can be done with individual bits in a feature map or a specific bit mask in the protected data. Both options are more labor-intensive and limit some of the automatic features built into CodeMeter License Central. Using distinct Product Codes also improves security for the protected applications: Each Product Code has its own secret cryptographic master key, and the most sophisticated hacker, even with access to one key, could not extract any other key.
Items in CodeMeter License Central
Each product is expressed as a distinct item in CodeMeter License Central. If the system is integrated with a SAP or other ERP system, it is advisable to use the same item ID in CodeMeter License Central that you are using as the part number, material ID or SKU in your ERP system. For our example, we are using the Product Code as the item ID.
The products are all flagged as permanent single user licenses (License Quantity = 0 and no Expiration Time). The name of the module is entered in plain text.
Bundle Item
As a next step, an item is created for each bundle:
- Basic (1009901)
- Pro (1009902)
- Ultra (1009903).
The application products we have defined before are now allocated as components of these three items, and the suites are ready to hit the shelves.
In most cases, this simple setup will be more than sufficient. Four additional options can be used to modify their behavior to our needs:
A dedicated Product Code for the bundle
- Component mode
- Order-specific mode
- Activation mode
Dedicated Product Codes
Each bundle can be given its own Product Code. This is not necessary for the application suites in our example.
This option makes sense if one component in a bundle has a higher profile as the main seller, and the other components are mere sub-modules of this main product. In that case, the main product is expressed as a distinct, separate product with a distinct Product Code, and the other products (sub-modules) are allocated as its components.
Another possible scenario would be the option to borrow licenses. This will need a dedicated Product Code as an anchor for Nested Product Items. This new functionality will be available in later versions of CodeMeter License Central.
Component Mode
The component mode is generally relevant if you are using the CodeMeter License Central web interface to produce tickets. In this mode, you get the following options:
- Necessary: The component is a fixed part of the bundle and cannot be removed.
- Opt-out: The component is an optional part of the bundle - it is included as standard, but can be removed.
- Opt-in: The component is an optional part of the bundle. It is not included as standard, but can be included at will.
Order-Specific Mode
This option is only relevant if individual components come with order defined parameters. These parameters can define an individual expiration time, a client’s name, or the number of network licenses when the ticket is created. These entries are not fixed settings for the item, as they are only finally configured when an actual ticket is created. In our example, no such parameters are used, so that the option is not necessary.
- Separate: The component has order-specific parameters. These settings are configured separately for maximum flexibility, although it requires more menial effort.
- Shared: The component receives its order-specific parameters from the bundle. If multiple components have parameters with the same name, these are only recorded once when the ticket is created and then set automatically for all components flagged with this mode.
The entry for an order-specific expiration time that applies to all components in the bundle, for example, would be recorded in one instance only, and the system would set the parameters accordingly in all components. This makes it easier to produce tickets and remove one possible source for human error.
Activation Mode
This option is relevant during activation, e.g. in WebDepot.
- Separate: The components are displayed to the user as individual products during activation and can be activated separately from all other components or the bundle as a whole. If this option is used, the bundle acts mostly as a means of facilitating sales on your side: The users receive only the products they want and activate only those products.
- The bundle itself behaves slightly differently: If all components can be activated separately, and the bundle has no dedicated Product Code itself, it will not be listed during activation since there is nothing left to be activated apart from when the components are activated. If, however, the bundle has its own Product Code, it will appear as a separate entry during activation. In our example, all components can be activated separately. WebDepot therefore displays all six components as individual products (cf. the top screenshot).
- Merge: The component does not appear as a separate product during activation. It is activated transparently in the background as part of the bundle. If this option is used, once a bundle has been created, it is a permanent package and the users can only activate it (or deactivate it, depending on the settings) as such. In our example, the setting for the Ultra suite is changed to merge mode. WebDepot now shows one bundle that the user can only activate completely (cf. the screenshot in the middle).
Behavior in CmContainers
Product bundles are a special feature of CodeMeter License Central. Once a bundle has been activated, it reverts into its original separate components in the CmContainer (cf. the screenshot at the bottom).
In order to keep the link between the components, a separate license number can be allocated to all components as an order-specific parameter during activation, which the software can see and work with accordingly. A more elegant solution is the use of Nested Product Items, which will be a feature in the next version.
Summary
Product bundles make it easier to sell your product suites, bundles, and packages with CodeMeter License Central. Four configuration settings allow you to tailor the behavior of the bundles exactly to your needs.
Product bundles can be a way to facilitate the sale of complex licenses and act as a bracket holding related products together when they are activated in a CmContainer.
In the next issue, you will read more about how the bundle structure will remain in place in CmContainers by using Nested Product Items.
KEYnote 31 – Edition Spring 2016