Built-in APS types used for creating the platform resources (for example, users of domains) implement APS abstract types. Inheritance for some of APS resources is presented in the diagram. Key points:
The abstract APS type IDs are in the
All APS types with a few exceptions implement the
Resource APS type.
The platform is presented as a set of APS applications with their own APS types.
The platform specific APS type IDs are
in the two namespaces:
Every custom APS application uses its own unique namespace. The custom APS types typically implement the abstract APS types and can operate the platform APS resources in accordance with the authorization rules.
The suite of diagrams below shows the relationship of built-in APS types in the platform. This helps to find a list of resources bound to a certain platform resource. For example, an anti-spam application might need to know the list of MX records in a certain domain to modify them.
Rectangles represent APS abstract types and the platform types. The platform types are displayed with a red background.
Arrows represent relations. Relations defined or redefined in the platform types are displayed in red.
The platform types can inherit some relations from APS built-in types. In this case, the APS parent presents on top of the platform type, and the relations are presented with black arrows.
The top-most APS abstract parent type is displayed with a blue background.
When designing a package, you need to define relations between the application and the platform APS types. The key points to consider when defining such relations are:
You need to bind customer resources to the main application resource on the provider’s side. Therefore, applications usually provide the context resource to customers. This resource relates to the application resource on one hand and to other customer resources on the other hand.
For an application to be able to operate account subscription and service user resources, the corresponding relations must be established.
If customer resources must be provisioned based on a predefined set of configurations or offers, such offers need to be created on the provider’s side. They must relate to the main application resource on one hand and to the customer resources on the other hand.
Below is an example of custom application relations.