Application Packaging Standard

Last updated 18-Mar-2019

Development

To implement the reseller customization, an APS application must be updated as explained here.

Resource Model

The central point of the reseller customization is an APS type implementing the ResellerProfile APS type. An APS application defines in this APS type those properties that resellers will change, for example, sub-domain name to bind an application service and credentials for authentication on the application side.

../../../../../_images/resourceModel-reseller.png

In the above diagram, the APS application defines the reseller-profile APS type implementing the ResellerProfile APS type. The provider creates a reference APS resource from that APS type, then creates a resource type bound with the reference APS resource, and adds that resource type to a service template.

When a reseller gets the delegated service template, a separate reference APS resource will be created for the reseller as a copy of the provider’s corresponding APS resource. In that APS resource, the reseller replaces the “white label” (default) values assigned by the provider with their own values.

When a reseller’s customer subscribes to the resellers’ service plan delegated by the provider, the customer’s tenant will be linked to the reseller’s profile. That link helps the respective APS application service get necessary reseller properties when provisioning and configuring the tenant and other related application resources for the customer.

Metadata

For every APS type, the APP-Meta.xml file must declare a service, for example:

<service id="reseller-profiles">
   <code engine="php" path="scripts/reseller-profiles.php"/>
   <presentation>
      <name>Reseller profile</name>
      <summary>App provisioning customization for resellers</summary>
   </presentation>
</service>

Define APS Type and Service

As usually, the APS type and the respective service can be defined in separate files or in the same PHP script. In the latter case, the PHP script must work in the APS PHP framework.

The following sample PHP script defines the login and password as reseller properties:

<?php

require "aps/2/runtime.php";

/**
 * Settings, customizable by resellers, for example
 * @type("http://aps-standard.org/samples/app/reseller-profile/1.0")
 * @implements("http://aps-standard.org/types/core/profile/reseller/1.0")
 */
class ResellerCloud extends APS\ResourceBase {

   /**
    * @link("http://aps-standard.org/samples/app/cloud/1.0")
    * @required
    */
   public $cloud;

   /**
    * @link("http://aps-standard.org/samples/app/context/1.0[]")
    */
   public $contexts;

   ## Customizable per reseller
   /**
     * @type(string)
     * @title(Login)
     * @description("reseller login")
     */
    public $login;

   ## Customizable per reseller
    /**
     * @type(string)
     * @encrypted
     * @title(Password)
     * @description("reseller password")
     */
    public $password;

}

?>

The script also declares the relationship with the application instance and the tenants as per Resource Model.

A schema file generated from the above definition will look as follows:

{
    "apsVersion": "2.0",
    "name": "ResellerCloud",
    "id": "http://aps-standard.org/samples/app/reseller-profile/1.0",
    "implements": [
        "http://aps-standard.org/types/core/profile/reseller/1.0"
    ],
    "properties": {
        "login": {
            "type": "string",
            "title": "Login",
            "description": "reseller login"
        },
        "password": {
            "type": "string",
            "encrypted": true,
            "title": "Password",
            "description": "reseller password"
        }
    },
    "relations": {
        "cloud": {
            "type": "http://aps-standard.org/samples/app/cloud/1.0",
            "required": true,
            "collection": false
        },
        "contexts": {
            "type": "http://aps-standard.org/samples/app/context/1.0",
            "collection": true
        }
    }
}

Update Provisioning Logic

The APS application services used to provision, update, and remove APS resources for customers should interact with the reseller profile. For example, if every reseller uses their own login and password for interacting with the original cloud application, then the tenant service can retrieve those properties through the link with the reseller profile.

In the following example, the service retrieves the reseller’s login and password and saves them in the tenant APS resource stored in the APS controller:

$this->vendorLogin = $this->reseller->login;
$this->vendorPassword = $this->reseller->password;

$apsc = \APS\Request::getController();
$apsc->updateResource($this);

Note

Since password is declared as an encrypted property, it is available for the APS application only. The APS controller does not send it in response to UI or other REST requests.

Prepare Resource Deployment

Since a reseller profile, like a service profile, is a reference APS resource, you should prepare their creation using one of the ways similar to creation of offers:

Conclusion

The described updates in the resource model, metadata, APS types, and provisioning logic are aimed to help you add the support of reseller customization to your APS applications.