Project Overview

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

Assumptions

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.

Deployment Schema

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.

Resource Model

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.

Start Your Project

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

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

Further Integration Steps

Once you are familiar with the project goals, requirements, and structure, advance to the following integration steps:

1. Development - declare application components in metadata and define the provisioning and presentation logic.
2. Deployment - build the project and then deploy the APS application on your test platform.
3. Provisioning - create and subscribe your test customer to the application services and then create some application resources from the subscription.

← Development Environment

Development →