To integrate an original cloud application with the platform, the provider must deploy the corresponding APS application on the platform. Typically, an APS application logic consists of the two parts:
The presentation logic implemented by a JavaScript code plugs the application custom UI into the platform control panels and thus allows the provider and its customers to manage the application resources.
The provisioning logic (backend logic) of an APS application is implemented by an APS connector that exposes an APS application endpoint. The latter must be able to receive REST requests from the APS controller. The APS connector converts APS REST requests to the application original API and backward.
In this document:
Typically, an APS application is installed from the application APS package, which usually contains the following parts:
Metadata with general description of the APS application and the package
APS types that will be used for creating APS resources; normally generated by the aps build command from the provisioning scripts
Provisioning logic, for example, PHP scripts, containing definition of each services declared in metadata; also may contain the source definition of APS types
Presentation logic implemented by a JavaScript code rendering and processing visual and control elements in control panels
Note
Depending on the application complexity, the package structure can be more complicated and it can contain much more files.
The deployment of an APS package is a part of the whole APS application deployment and consists of the following steps:
The whole package must be imported to the platform. The APS controller will need general application metadata, definition of types and services for subsequent application configuration and provisioning. The presentation logic will be embedded to the specified control panels.
The provisioning scripts must be used to set up an APS connector. The latter exposes the APS application endpoint for the APS controller.
During the installation of an APS application instance step, the APS controller configures an APS application instance through the APS application endpoint.
On completion of the above steps, the provider will be able to proceed to the following configuration steps:
The Setting Reference Resources step is needed when the application requires some parameters to be applied globally to the application resources.
The Creating Resource Types and Creating Service Template steps are the required deployment steps for any service provided through the platform. APS specifics here is that platform resource types are bound to APS reference resources or to APS types.
To sell application resources, the provider should proceed to Sales Configuration in BSS.
The developer of an APS application must choose a deployment method that allows the providers to reliably and simply deploy the APS application on their platform.
There are different approaches to the deployment of APS connectors as explained in the following documents.
Note
The deployment of the presentation logic (UI) is fully automated and does not depend on the methods used to deploy APS connectors.
For the providers, the Docker based deployment is the preferable method to deploy APS connectors due to its simplicity and reliability. It uses the Docker virtualization technology to deploy every APS connector in its own Docker container.
The deployment schema includes a server that must be registered in the management node to carry out the APS Endpoint Node role. A Docker registry server is used to pull container images when creating Docker containers.
When creating an APS package, the developer or integrator must also create a container image and save it in the Docker registry.
To deploy an APS application connector on a platform, the provider runs only two simple operations in the provider control panel: import the package and install an APS application instance.
When deploying an APS connector to connect a platform with an original application, the provider can install the APS connector in the private network or in the Internet as explained in the Deployment Schemas document.
When testing and debugging APS applications on a lab platform, you should enable the APS development mode that changes the platform functionality in the following way:
The platform removes the restriction on updating an APS application by importing another package that has the same application ID and version.
Some of APS related screens will not be cached in web browsers. This allows the developers to see effect of script changes immediately. At the same time, it may delay screen rendering.
The platform log will store more details on APS operations.
You can enable this mode on your lab platform following these steps:
In the provider control panel, navigate to System > Settings.
Follow the System Properties link.
On bottom of the System Properties screen, click the Edit button.
Mark the APS development mode check-box and click Submit to save the setting.