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.
AbstractMobileServiceInterceptor
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 thebeforeInvoke
methods of the remaining interceptors, while skipping the method of the calling business side and going directly to theafterInvoke
method of the interceptor.After the method is called: the method is
afterInvoke
. There are two types ofafterInvoke
. 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
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.
Example
Code your own interceptor classes, and inherit from
AbstractMobileServiceInterceptor
classes, or implementMobileServiceInterceptor
interfaces.public class MyInterceptor implements MobileServiceInterceptor { /* Description 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. */ @Override 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 */ @Override public void afterInvoke(Object returnValue, Method method, Object[] args, Object target) { // Note: The input parameter is the object returned by the business party. } @Override 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; } @Override public void throwsInvoke(Throwable t, Method method, Object[] args, Object target) { } @Override public int getOrder() { // The highest level (the smallest value) and the lowest level (the largest value). return 0; } }
Releases the implemented class
MyInterceptor
as Bean.Spring Boot: Add the annotation
@service
directly to the class.@service public class MyInterceptor implements MobileServiceInterceptor{}
Spring: declaration in the
xml
file of the configuration.<bean id="myInterceptor" class="com.xxx.xxx.MyInterceptor"/>
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.
Example
Here, we take modifying and obtaining a session as an example.
Modify the session. Create an interceptor. For more information, see the preceding interceptor example. The following example uses interception before a method call:
@Override public Object beforeInvoke(Method method, Object[] args, Object target) { Map<String, String> session = MobileRpcHolder.getSession(); session.put("key_test", "value_test"); MobileRpcHolder.setSession(session); }
This allows you to modify the session information in the
MobileRpcHolder
.Gets the session. The business party can obtain the session information in the service defined by itself.
@OperationType("com.alipay.account.query") 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
@Override
public String mock2(String s) throws RpcException {
try{
test();
}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.