Writing a client application for Key Administrator consists mostly of two parts.

1. License Management
2. KA Interaction

License Management contains the major business logic. It determines what license should be created, retrieved, upgraded or canceled. This part would be connected with your internal provisioning systems.

If you manage lease licenses you probably want to develop it in the way that it creates and manages all licenses on demand, meaning that you would only create a new license when needed for a new product installation and that you would cancel (terminate) this license when the product installation is not used anymore.

If you have to manage purchase licenses, you would probably create some kind of pool where you group your licenses by features and product release. Then when a server is provisioned you could take a free license from the pool or create a new one or upgrade a license from another pool. When product installation is taken out of service, the (already paid) license would be put back into the pool for re-usage. Also you need to be aware about SUS (it determines if the license can be upgraded to another major release or not), SUS needs to be renewed/paid every year to remain active. For lease licenses SUS does not expire.

When you store information about licenses in your local licensing manager, you don’t need to store the actual key file as it can always be retrieved on demand via the Partner API. Also you should identify your licenses by the actual key number as “PLSK.00012345” without the 4-digit postfix (that indicates the key file revision).

The second part is the KA interaction. You need to establish a HTTPS connection to the KA server and then exchange XML requests and responses. For code examples and detailed descriptions for several programming languages read the next section.