This demo project will walk you through the main steps of the APS application life cycle. The scenario imitates provisioning of virtual private servers (VPSes).
In this document:
To avoid overloading you with excessive information, let us assume the following:
Taking into accounts the goals and assumptions, the system deployment schema looks as follows:
In this project, you will create an APS package containing a provisioning (backend) and presentation (UI) logic. At the deployment stage, you will install an APS connector implementing the provisioning logic and plug the custom UI to UX1. For simplicity, the APS connector will not have a connection with a cloud application. Rather than that, it will confirm completion of the provisioning operations requested by the APS controller functioning inside the platform.
The APS controller creates APS resources from APS types (resource schemas) shipped inside the APS package.
There are two APS types that each APS package must contain. One of them must implement the standard Application APS type to create a single resource presenting the application instance on the provider side. The other one must implement the standard Subscription Service APS type to create a single APS resource in each subscription bound directly to the APS resource representing the subscription.
In addition to the mandatory resources, the APS application must provision custom resources representing virtual private servers (VPS). For that, the APS package must define one more custom APS type.
APS resources must be linked to each other to help the system and custom methods identify the related resources. The links are created due to the relationship declared in APS types.
The following resource model shows all three APS types and the relationship between them.
An APS package must declare a unique APS ID for the APS application and for each APS type in a URI format. The diagram above shows only a part of each APS ID for this demo project.
Assuming the application APS ID ends with the
starter suffix, the resource model presents the following APS types:
/starter/app- used to install an APS application instance on the APS connector and create a respective APS resource in the APS database. Every customer subscription with the application resources must contain a reference to this APS resource.
/starter/management- used to create a singular resource in a subscription on the customer side. It presents a management context or a tenant of the application. Normally, it has the relationship with system resources (the customer account and subscription) and the custom application resources, such as VPSes in this demo.
/starter/vps- used to provision VPSes as APS resources.
The following relationship binds resources to each other:
appresource is linked through its
managementslink collection (multiple blue squares) with multiple
managementresources. On the customer side, each
managementresource has a mandatory (red colored) link
appwith the application resource.
managementresource in each subscription is linked with multiple
vpsresources. For this purpose, the APS types declare a link collection
vpsesand a required link
You need to create necessary files in a project folder, for example let us call it
project-starter/. Its content must
coincide with the application resource model:
Download and decompress the
project template and then use its
APP-META.xml- metadata with declaration of general application properties, UI navigation structure, and services.
apps.php- PHP script that defines the
appAPS type and methods of the
managements.php- PHP script that defines the
managementAPS type and methods of the
vpses.php- PHP script that defines the
vpsAPS type and methods of the
2. Every APS type is managed by a corresponding APS service (resource factory) on the one-to-one basis.
Typically, in metadata, an APS service name
is declared in the plural form, for example,
Once you are familiar with the project goals, requirements, and structure, advance to the following integration steps: