APS Resource Model

The fundamental term in APS is APS Resource. Each application must expose its own set of APS types that declare the structure, properties, and operations of APS resources created from those types.

The APS controller stores APS resources in the JSON (RFC-4627) format and allows the actors on the APS bus to manage the resources through the RESTful API also known as REST).

Application and APS Resources

The conversion of the application original (native) API and resource presentation to the APS REST API and APS resources respectively must be performed by a special integration code (provisioning logic) exposed through the APS application endpoint.

An APS application can expose several services. An APS application service is a factory of APS resources based on a certain APS type. An APS resource is uniquely identified by its APS ID: UUID (Universally Unique Identifier). In the platform, an APS application service is a part of the application provisioning logic. It synchronizes creation, updates, and removal of APS resources with the original application resources.

Model-View-Controller Schema

APS is based on the well-known Model-View-Controller (MVC) architecture.

The MVC components are:

• A data model of an application defined by the ISV and package developer.

  The original application resources are synchronized with the APS resources controlled by the APS controller. The synchronization goes through the services exposed by an application specific APS connector.

• The APS controller as the message broker on the APS bus connecting all APS participants.

  All messages between applications and systems connected to the APS bus go through the APS controller. This makes the APS bus and APS controller terms equivalent.

• The customizable user interface (UI) representing resources through custom view components.

When a user performs an action, the UI code must be able to request the APS controller to perform a CRUD (create-read-update-delete) operations or a custom operation. The APS controller synchronizes all those requests with the application through its endpoint. Each APS resource is created based on an APS type, which is a formal description of the resources. The APS controller processes each REST request in the following order:

1. It finds the APS type in the request and processes the requested operation in the APS database.

2. It finds the mapping between the APS type and the APS application service. Each service is exposed as a unique URL on the APS application connector.

3. The APS controller sends the corresponding REST request to the APS application service to process the respective original application resource.

Development

In accordance with this model, application developers must do the following in an APS package:

• Define metadata of your APS application.

• Define APS types, as they are used for creating APS resources.

  • Each type must be bound to a service running in the APS application connector.

  • APS types are defined using JSON format.

• Develop provisioning logic for the APS application connector, usually based on PHP Framework.

  • Each service is implemented by a PHP or another executable file.

  • A service is accessible through its own unique URL (the service endpoint).

  • A service must process all REST requests related to resources of a certain type.

• Develop custom UI for control panels used by providers and customers based on APS JavaScript framework.

  • UI views (screens) are arranged into navigation trees: one tree for the provider panel, one for the customer panel, and one for the end-user panel. The newest UX1 panel is universal for customers and resellers.

  • Each UI view presents a set of widgets enabling users to monitor and operate the application resources.

  • The UI view code (JavaScript) processes a user request for a resource operation by generating the corresponding REST request for the APS controller.

← Concepts

Types →