Tenant handles are represented as Handle objects which an account can set/get from a Tenant object. A tenant handle is the representation of account information in the cloud service in CPBM. For the most part, other than its existence, TenantHandles are opaque to CPBM. A TenantHandle object is represented as follows.

public class TenantHandle {    /* A unique opaque handle to identify the service specific entity corresponding to       this account */    public String getHandle();      /* Can store any json/string data and CPBM will preserve this as it is. This field        may be used to store any additional data the connector would like to associate with        this account handle    */    public String getData();      /* Connector can store apiKey/secret or username/passwords etc in this key and values        in this map would be displayed in the CPBM credentials section.     */    public Map<String, String> getApiCredentials();      /* Back reference to the tenant */    public Tenant getTenant();  }    public class Tenant {  ...    /* Return the handle for the corresponding service instance if exists. Returns null        otherwise */    public TenantHandle getHandle(String serviceInstanceId);    /* Add an tenant handle to the tenant */    public void addHandle(String serviceInstanceId, TenantHandle handle);    /* Remove an tenant handle from the tenant */    public void removeHandle(String serviceInstanceId);  ...  }

The AccountLifecycleHandler SPI is defined as follows:

/**     * Handles account lifecycle.     */  public interface AccountLifecycleHandler {      /* Registers an account as well as account owner user in cloud service and stores the        mapping of the account and account owner user as handles in tenant and        tenant.owner()passed */    public void register(Tenant t);      /* Restrict the account. */    public void restrict(Tenant t);      /* Suspend the account */    public void suspend(Tenant t);      /* Reactivate the account */    public void reactivate(Tenant t);      /* Deletes the account. Connector should clean the handle for tenant by calling          t.removeHandle(serviceInstanceObj) */    public void terminate(Tenant t);      /**     * Sets service level controls at tenant level. Service level     * controls are set under the following scenarios     *     * <ul>     *   <li> When a tenant is newly created, the controls are applied from the tenant's account type     *   <li> When a tenant is updated with new control values     *   <li> when a tenant moves account types     * </ul>     * In all cases, the service is expected to do its best to apply the     *   updated values by triangulating between the  tenant's current     *   settings, the new settings and any current limitations. For     *   example, a tenant's current quota, new quota and currently used     *   amount (against that quota).     *     * @param tenant The tenant to update     * @param controls - Map of control names and their values; Not null when SP edits the service controls     *                   and when a tenant moves account types     */      public void setControls(Tenant tenant, Map<String, String> controls);      /**     * Retrieves service level controls defined at tenant level     * @param tenant     * @return     */      public Map<String, String> getControls(Tenant tenant);      }

• register: Register service specific scope corresponding to an account in CPBM. It is required that the account creation process also handle the master user (owner) creation process as well. The UserLifecycleHandler will NOT be called for the master user. Account handle MUST be added using Tenant.addHandle. The tenant owner can be accessed using Tenant.getOwner() and user handle can be added using User.addHandle() on the owner object. If the connector does not support users the user handle need not be added.
• restrict: restrict all users from managing resources in the cloud service. The resources may still be operational and may be accessible by other means. In general, it is preferred that this state allow users to reduce their resource consumption. It may be sufficient to allow master users access to perform this.
• suspend: prevent users from accessing their resources. The resources should as much as possible cease to be operational. For example, VMs should be shut down but not destroyed. Note that this is not a terminal state so the resources should remain recoverable.
• reactivate: re-enable access to resources for all users in the account so that they can get back in operational state. It is not required that the service make the resources operational (Eg. VMs can be started but the service need not start the VMs).
• terminate: delete the account, all the users and remove all resources used by this account.