Here, you will find the updates in the platform SDK and in this documentation since the previous release.
With the new mechanism of aliases, the actors on the APS bus can use less and much shorter REST requests to call some APS operations of both kinds CRUD and custom. Now, instead of the long “implementing” RQL function to specify an APS type ID, a REST request can refer to the alias of that APS type directly as explained in the APS Types document. For example, instead of:
you can use:
All singleton resources (services) have aliases. With the service alias, you do not need to preliminary identify the APS ID of the service to call an operation afterwards. For example, instead of the two operations:
use only one operation:
The access to APS resources for APS connectors can now be limited by means of the impersonation mechanism. An application can require impersonation at one of the levels, either provider level (means unlimited and it is the default for those applications that are not aware of the new mechanism), reseller level, customer level, or none. When installing an APS application instance, the provider can allow or reject the required level of impersonation. The feature improves security for applications and increases the platform robustness from occasional or intentional application misbehavior.
The order management API is extended with the following new features:
With the new APS-Actor-Scope HTTP header, APS application UI can specify a scope of APS resources it wants to get from the APS controller.
With the new aps/MultiLine widget, it is possible to align the
widgets into a column or a row using various styles.
The new GDPRSupport APS type makes it easier for APS applications to comply with the General Data Protection Regulation (GDPR) of the European Union. The new Personal Data document explains the concepts and provides some examples.