All Products
Document Center

Mobile Platform as a Service:Use the gateway auxiliary class

Last Updated:May 08, 2023

This article describes the use of relevant auxiliary classes used in gateways, including interceptor classes, MobileRpcHolder, and gateway error codes.

Implement the interceptor function

Interceptors are only applicable to non-HTTP services.

mobilegw-unify-spi-adapter.jar actually call the business method through Java reflection, that is, the method specified by the OperatioinType. In the process of method invocation, the business side can implement the interceptor defined in the SPI package to implement the extension.

The gateway's SPI package defines two interceptors: the AbstractMobileServiceInterceptor abstract class and the MobileServiceInterceptor interface.


The MobileServiceInterceptor mainly provides four methods: beforeInvoke, afterInvoke (divided into two types: one type of input parameter is the object returned by the business, and the other type of input parameter is the JSON string converted from the object), throwsInvoke, and getOrder.


As shown in the preceding figure, the interceptor mainly intercepts in the following three situations:

  • Before the method is called: that is, the beforeInvoke method, which has a return value. Once the return value of the method is not empty, the gateway determines that the interception is successful and will skip the beforeInvoke methods of the remaining interceptors, while skipping the method of the calling business side and going directly to the afterInvoke method of the interceptor.

  • After the method is called: the method is afterInvoke. There are two types of afterInvoke. One type of input parameter is Object, which is the object returned by the business side. This method has no return value and will be executed by all interceptors. The other type of input parameter is a JSON string converted from Object. This method can change the incoming JSON-formatted data and return it. If the return value is not empty, the gateway determines that the interception is successful and subsequent interceptors are ignored.

  • The method has an exception: that is, the throwsInvoke method. This method has no return value, and all interceptors of this method will be executed. It is called when an exception occurs on the business side.


MobileServiceInterceptor inherits the Ordered API of the framework, the interceptor implemented by the business side can also specify the execution order by implementing the getOrder method, the smaller the value set, the higher the priority of execution.


  1. Code your own interceptor classes, and inherit from AbstractMobileServiceInterceptor classes, or implement MobileServiceInterceptor interfaces.

    public class MyInterceptor implements MobileServiceInterceptor {
         method: the method of the business party (the method defined by @ OperatioinType)
         args: an object array, that is, the input parameters of the business-side method. The number of input parameters is equal to the array size. 
              When used, the business party performs type conversion as needed.     
         bean: the interface instance of the business side. 
     Response parameters:
         Object: Data can be returned in the interceptor. Once the return value is not empty, the gateway considers that it has been intercepted and does not call the business method again.
             At the same time, the beforeInvoke method of other interceptors is directly skipped, and the afterInvoke method in the interceptor is executed.        
     public Object beforeInvoke(Method method, Object[] args, Object target) {
         //Do Something
         return null;
     * Parameter description
     * returnValue: the object returned by the business method.
     * Other parameters as above  
     public void afterInvoke(Object returnValue, Method method, Object[] args, Object target) {
         // Note: The input parameter is the object returned by the business party.
     public String afterInvoke(String returnJsonValue, Method method, Object[] args, Object target) {
         // Note: The input parameter is a JSON-formatted string converted from the object returned by the business party.
         // The new JSON-formatted data can be returned.
         return null;
     public void throwsInvoke(Throwable t, Method method, Object[] args, Object target) {
     public int getOrder() {
         // The highest level (the smallest value) and the lowest level (the largest value). 
         return 0;
  2. Releases the implemented class MyInterceptor as Bean.

    • Spring Boot: Add the annotation @service directly to the class.

      public class MyInterceptor implements MobileServiceInterceptor{}
    • Spring: declaration in the xml file of the configuration.

      <bean id="myInterceptor" class=""/>

MobileRpcHolder helper class

MobileRpcHolder is a static auxiliary class provided in the mobilegw-unify-spi-adapter.jar, which defines the relevant information in a request process, the most important definition is as follows:

Map<String, String> session Save the requested session
The Map<String, String> header holds information about the request's header
Map<String, String> context saves the context information of a gateway call
String operationType to save the operationType of this request 

Before the service (i. e. OperationType) of the service side is called, the SPI service sets the MobileRpcHolder information according to the request MobileRpcRequest forwarded by the gateway. This information is cleared after the service is called.

The lifecycle of a MobileRpcHolder is the entire service invocation process, which is cleared after the invocation.

The business side can also set this information as needed. This information will always exist in the process of calling the business service, and the business service can obtain this information during the calling process. Specific settings can be used by interceptors to dynamically modify the information stored in the MobileRpcHolder before and after method calls.

The following examples illustrate how the MobileRpcHolder can be used.


Here, we take modifying and obtaining a session as an example.

  1. Modify the session. Create an interceptor. For more information, see the preceding interceptor example. The following example uses interception before a method call:

     public Object beforeInvoke(Method method, Object[] args, Object target) {
         Map<String, String> session = MobileRpcHolder.getSession();
         session.put("key_test", "value_test");

    This allows you to modify the session information in the MobileRpcHolder.

  2. Gets the session. The business party can obtain the session information in the service defined by itself.

     public String mock2(String s) {
         Map<String, String> session = MobileRpcHolder.getSession();

    Other information such as the header and context can be modified and obtained in the same way.

    // Obtain all information about the header.
     Map<String,String> headers = MobileRpcHolder.getHeaders();
     // The context information refers to the context information in the request.
     Map<String,String> context = MobileRpcHolder.getRequestCtx(); 
     // Obtain the OperationType.
     String opt = MobileRpcHolder.getOperationType();

Error codes for using the gateway

Mobile gateways have a set of error code specifications. For more information, see Gateway result codes.

Note that BizException 6666, this error is thrown by the gateway after a service exception occurs.

If you want to return other error codes when specific errors occur, you can control RPC layer errors by throwing RpcException(ResultEnum resultCode), such as resultCode=1001, which will return "no permission to access" to the client.

Sample code

public String mock2(String s) throws RpcException {
    }catch (Exception e){
        throw new RpcException(IllegalArgument);
    return "11111111";

Custom error codes

If you want to use a custom error code, you cannot throw an exception when calling a business method.

The business method returns status code 6666 whenever an exception occurs. At the same time, the client receives the status code, that is, it considers that the service is incorrect and does not parse the data returned by the service. The client parses the returned data only when it receives the 1000 status code.

Specifically, the server and the client agree on specific error codes, and then catch all exceptions when calling business methods, and put the custom error codes in the returned data. In this way, the service is abnormal and the gateway returns 1000 success. At the same time, the client parses the returned data and extracts custom error codes.