Account Lifecycle


A Connector package can implement account provisioning lifecycle handler so that accounts in CPBM can be mapped to a corresponding entity in the underlying cloud service. CPBM has accounts and each account minimally has an owner, who is called a master user. Users in CPBM initiate all actions and if a service does not differentiate between an account and a user then it should return same handle for both account as well as a user. In such a case the service should not implement the User Provisioning Lifecycle handler. In this case, the service will not be able to expose user specific access.

CPBM creates these mapping lazily i.e. the mapping is not created at CPBM account creation time but rather at first subscription provisioning time. See Subscription Lifecycle handling for details on provisioning.

Connectors should use the account lifecycle handler to be in synchronization with CPBM account lifecycles. Connectors should implement all methods in AccountLifecycleHandler if they need to represent an account in their service. Connectors may choose to not distinguish between certain states (like restrict and suspend) or may choose to do nothing for certain states.


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 handle string should be the same one that is used to identify the tenant in the usage record.


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);      }

The SPI implementation should implement these methods as follows:

  • 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.

For UserHandle structure and processing, see UserLifecycleHandler section. The same applies to the master user as well.

Figure 1. Account Lifecycle Handler

For information on service onboarding a customer, see Onboarding and managing a service.
또 다른 질문이 있으십니까? 문의 등록


Adding comment, please wait....

Provide Feedback on Article:

Zendesk 제공