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:
We will not use a real cloud application with an original API. The demo will focus on the APS interface only.
In the project, we will not customize the default built-in provisioning operations in the APS connector. Instead, the APS application will use them as is.
The custom UI will demonstrate a minimum set of APS SDK possibilities. It will show a list of provisioned servers and allows a customer to use only one provisioning operation - create a VPS.
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:
app resource is linked through its
managements link collection (multiple blue squares)
On the customer side, each
management resource has a mandatory (red colored) link
app with the application resource.
management resource in each subscription is linked with multiple
vps resources. For this purpose,
the APS types declare a link collection
vpses and 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
app APS type and methods of the
managements.php - PHP script that defines the
management APS type and methods of the
vpses.php - PHP script that defines the
vps APS type and methods of the
We do not pay attention to the deployment data that will be explained in the deployment step.
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:
Development - declare application components in metadata and define the provisioning and presentation logic.
Deployment - build the project and then deploy the APS application on your test platform.
Provisioning - create and subscribe your test customer to the application services and then create some application resources from the subscription.