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.
The project does not demonstrate business management operations, such as product sales and billing. The platform in its minimal configuration contains only the OSS management node.
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.
Note
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.
Note
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:
The app
resource is linked through its managements
link collection (multiple blue squares)
with multiple management
resources.
On the customer side, each management
resource has a mandatory (red colored) link app
with the application resource.
The 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 management
.
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
XML, PHP, and JavaScript templates to create the following files in your project:
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 apps
service.
managements.php
- PHP script that defines the management
APS type and methods of the managements
service.
vpses.php
- PHP script that defines the vps
APS type and methods of the vpses
service.
server-new.js
- JavaScript code that defines the VPS creation view.
servers.js
- JavaScript code that shows a list of VPSes and allows a customer to start adding a VPS.
Note
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, apps
or managements
.
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.