|ASP||App Service Provider|
|ASC||App Service Consumer|
|RPC||Remote Procedure Call|
There are currently four RPCs related to app services which must be supported by every ASP:
Direction: ASP -> Core
This request is sent by the ASP to initially create the service. This is where the service's manifest is defined, which includes the type of data provided by the service as well as what RPCs can be handled by the service.
Direction: ASC -> Core -> ASP
The ASP can receive this message only when its service is active.
This request is sent to the ASP when an ASC sends this message. The ASP is expected to respond to this message with its most recent service data.
Direction: ASP -> Core -> ASC
The ASP is expected to send this message only when its service is active.
This notification is expected to be sent by the ASP whenever there are any significant changes to its service data or if its service becomes active. Core will forward this message to any ASCs that have subscribed to data for this service type.
Direction: ASC -> Core -> ASP
This ASP can receive this message regardless of whether its service is active, since it is directed at a specific service.
This request is sent to the ASP when an ASC sends this message with the ASP's specific service ID. This indicates that the ASC wishes to perform a service-specific function on the ASP. The API for such interactions must be defined by the ASP separately. The ASP is expected to process this message and respond with
SUCCESS or return an error response if the interaction was not successful.
There are a number of existing RPCs which are allowed to be handled by the ASP based on service type:
ButtonPresswith the following values for
When RPC passing is performed with a request which relates to several components (such as ButtonPress), not all uses of this RPC will be intended for this service. As such, it is expected that the ASP will indicate when they are unable to process a specific instance of an RPC by responding with an
UNSUPPORTED_REQUEST response code. This informs Core that it should pass this specific request to another component or app service that handles this RPC.
This "Waterfall" flow used by Core during RPC passing is defined as follows:
UNSUPPORTED_REQUEST(indicating that it cannot handle some part of the request), return to step 2
When Core passes an RPC to a ASP according to its
handledRPCs list, it performs no additional processing on the message. This means that there is no guarantee that this message is valid according to the RPC Spec. This approach is taken specifically for forward-compatibility reasons, in case the ASP supports a newer version of the RPC Spec than Core (which could include breaking changes). As a consequence, the ASP will need to perform validation on this message itself.
Validation steps for existing passthrough RPCs:
buttonNameis correctly tied to the
With regards to permission handling during RPC passing:
allow_unknown_rpc_passthroughpolicy field) to send this message, even if it is handled by the ASP.