All Products
Search
Document Center

Instructions on gateway helper classes

Last Updated: Apr 26, 2021

This topic gives an introduction on the related helper classes involved in Mobile Gateway Service (MGS), including interceptor class and MobileRpcHolder, and the corresponding error codes in MSG use.

Implement the function of interceptors

The interceptors are only applicable for non-HTTP services.

Mobilegw-unify-spi-adapter.jar actually calls the service method through Java reflection. The service method is also the method specified in OperatioinType. In the process of method invocation, the business system can implement the interceptors that are defined in SPI package to realize extension.

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

AbstractMobileServiceInterceptor

MobileServiceInterceptor mainly provides four methods: beforeInvoke, afterInvoke (two types: one has the object returned by the business system as incoming parameter and the other one has the JSON string converted from object as incoming parameter), throwsInvoke and getOrder.

flow chart

As shown in the above figure, interception mainly takes place at the following points:

  • Before method invocation: Use the beforeInvoke method, which has a return value. If the return value of this method is not null, the gateway regards the interception a success, skips the beforeInvoke method of other interceptors and the methods of the business system, and then directly goes to the afterInvoke method.

  • After method invocation: Use the afterInvoke method. There are two types of afterInvoke method. One takes the object returned by the business system as incoming parameter. This method has no return value. Such method in all interceptors will be executed. The other one takes the JSON string as incoming parameter, and this method can change the passed-in JSON data and return them. If the return value of this method is not null, the gateway regards the interception a success, and skips the subsequent beforeInvoke methods.

  • Method exception: Use the throwsInvoke method. This method has no return value. Such method in all interceptors will be executed. The method will be called in case of business system exception.

MobileServiceInterceptor

MobileServiceInterceptor inherits the framework’s Ordered interface. Therefore, the interceptors that are implemented by the business system can be executed in a specified order by implementing getOrder method. The smaller value, the higher execution priority.

Code sample

  1. Encode your own interceptor class, inherit AbstractMobileServiceInterceptor class or implement MobileServiceInterceptor class.

       
    1. public class MyInterceptor implements MobileServiceInterceptor {
    2. /*
    3. Parameter description
    4. Method: Method of the business system (method defined in @OperatioinType)
    5. args: An object array, namely the incoming parameters of the business system’s method. The number of the incoming parameters is the array size.
    6. The business system transforms the type based on demand in use.
    7. bean: The interface instance of the business system.
    8. Return value description:
    9. Object: Return data in the interceptor. If the return value is not null, then the gateway regards the interception a success, and will not invoke the business method.
    10. Meanwhile, the gateway skips the `beforeInvoke` method of other interceptors, and executes the `afterInvoke` method in the interceptors.
    11. */
    12. @Override
    13. public Object beforeInvoke(Method method, Object[] args, Object target) {
    14. //Do Something
    15. return null;
    16. }
    17. /*
    18. *Parameter description
    19. *returnValue: Object returned by the business system
    20. * Other parameters are same as the above
    21. */
    22. @Override
    23. public void afterInvoke(Object returnValue, Method method, Object[] args, Object target) {
    24. //Note: The incoming parameter here is the object returned by the business system
    25. }
    26. @Override
    27. public String afterInvoke(String returnJsonValue, Method method, Object[] args, Object target) {
    28. //Note: The incoming parameter here is the JSON string that is converted from the object returned by the business system
    29. //New JSON data can be returned
    30. return null;
    31. }
    32. @Override
    33. public void throwsInvoke(Throwable t, Method method, Object[] args, Object target) {
    34. }
    35. @Override
    36. public int getOrder() {
    37. //Highest (with smallest value) and lowest (with largest value)
    38. return 0;
    39. }
    40. }
  2. Publish the implemented MyInterceptor class, and make it a Bean.

    • Spring Boot:
      Add annotation @service on the class.
           
      1. @service
      2. public class MyInterceptor implements MobileServiceInterceptor{}
    • Spring:
      Make a declaration in the xml configuration file.
           
      1. <bean id="myInterceptor" class="com.xxx.xxx.MyInterceptor"/>

MobileRpcHolder helper class

MobileRpcHolder is a static helper class provided in mobilegw-unify-spi-adapter.jar. This helper class defines the relevant information of a request. The main definition is as follows:

 
  1. Map<String, String> session Save the request session
  2. Map<String, String> header Save the request header related information
  3. Map<String, String> context Save the context that is called by the gateway
  4. String operationType Save the operationType of this request

Before the business system’s service (OperationType) is called, the SPI service will set the above information of MobileRpcHolder according to the MobileRpcRequest forwarded by the gateway. The information will be cleared after the OperationType is called.

The lifecycle of MobileRpcHolder is the whole service invocation process. The information will be cleared after service invocation.

The business system can set the information based on requirement, and the information always exists in the process of business service invocation. In the invocation process, the business service can obtain that information. You can dynamically modify the information saved in obileRpcHolder before or after the method invocation through the interceptors.

The following example illustrates how to use MobileRpcHolder.

Code sample

Here is an example of modifying and obtaining a session.

  1. Modify a session.

    Create an interceptor. For specific procedure, see the above example. The following step assumes to intercept before method invocation:

       
    1. @Override
    2. public Object beforeInvoke(Method method, Object[] args, Object target) {
    3. Map<String, String> session = MobileRpcHolder.getSession();
    4. session.put("key_test", "value_test");
    5. MobileRpcHolder.setSession(session);
    6. }

    In this way, you can modify the session information in MobileRpcHolder.

  2. Obtain a session.

    The business system can obtain the session information from the service that is defined by itself.

       
    1. @OperationType("com.alipay.account.query")
    2. public String mock2(String s) {
    3. Map<String, String> session = MobileRpcHolder.getSession();
    4. }

    For other information like header and context, the operation is the same as the above.

       
    1. // Obtain all information of header
    2. Map<String,String> headers = MobileRpcHolder.getHeaders();
    3. // The context here refers to the context in the request
    4. Map<String,String> context = MobileRpcHolder.getRequestCtx();
    5. // Obtain OperationType
    6. String opt = MobileRpcHolder.getOperationType();

MGS error codes

Mobile Gateway Service has a set of error code specifications. To learn more, see Gateway result codes.

What you have to note is BizException 6666. This error is the exception thrown by the gateway upon business system exception.

To return other error codes when an error occurs, the business system can throw RpcException(ResultEnum resultCode) to control the error on RPC layer. For example, resultCode=1001, the error “have no access privilege” will be returned to the client.

Code sample

 
  1. @Override
  2. public String mock2(String s) throws RpcException {
  3. try{
  4. test();
  5. }catch (Exception e){
  6. throw new RpcException(IllegalArgument);
  7. }
  8. return "11111111";
  9. }

Custom error codes

If the business system is to use the custom error codes, it cannot throw exceptions during service method invocation.

In case of service method exception, the status code 6666 is returned. When the client receives the status code, it regards that an error occurs in the service and will not parse the data returned by the business system. The client parses the returned data only when receiving the status code 1000.

Therefore, the reasonable approach should be that the server and client appoint the specific error codes, catch all exceptions when invoking the service method, and then put the custom error codes in the returned data. In this way, even if the business system has exceptions, the gateway still returns 1000. Meanwhile, the client parses the returned data, and extracts the custom error codes.