Access method for connecting open platform and remote user and corresponding device

Abstract

An access method for connecting an open platform and a remote user comprises the following steps: step 1, configuring a user, and endowing the user with a key and a signature mode; step 2, performing security inspection according to the request of the user, wherein the security inspection comprises at least one of signature verification, data desensitization and plug-in signature; step 3, performing interface dynamic adaptation, including interface protocol conversion and service model conversion; step 4, performing service management, including current limiting, degradation and monitoring; and step 5, opening corresponding functions to the user.

Description

Technical Field

[0001] The present invention relates to the field of medical electronic platforms, and in particular to an access method and corresponding device for connecting an open platform with remote users. Background Art

[0002] Traditional ERP basically only realizes the self-closed loop within the system, and the connection with the third-party warehousing system is inefficient, difficult, poor in scalability, and supports a single type. How to efficiently and quickly realize the connection of multiple third-party WMS systems is the goal of this invention. Summary of the invention

[0003] The present invention proposes the following solution: an access method for connecting an open platform and a remote user, comprising the following steps: Step 1: Configure the user and assign the user a key and a signature method; Step 2: Perform security checks according to the user's request, including at least one of signature verification, data desensitization, and plug-in signature; Step 3: Dynamically adapt the interface, including interface protocol conversion and service model conversion; Step 4: Perform service governance, including flow control, degradation, and monitoring; Step 5: Open the corresponding functions to the user. Preferably, the functions include at least one of: purchase order, purchase shipment, purchase return and inventory status. Preferably, the security inspection adopts AK / SK certification. Preferably, the interface protocol conversion includes one of an external call to an internal dubbo service and an external http call to an internal http interface. Preferably, the business model conversion is to dynamically convert the business model by configuring scripts to adapt to different external service requests. Preferably, the conversion comprises the following steps: step i, pushing the business data of the open platform; step ii, searching for mapping configuration, assembling commercial business data, and standardizing the request for commercial business interface; step iii, processing commercial business. Preferably, the user has the following information: user key, open platform ID, open platform key, user name, user ID. The present invention also relates to a device for connecting an open platform and a remote user using the above-mentioned access method for connecting an open platform and a remote user, comprising a user configuration module, a security verification module, a dynamic adaptation module, a service management module and a function assignment module. Best, including mobile and computer versions. Preferably, it includes a client and a backend. Through the standardized interface platform, the connection and scheduling of multiple remote WMS management systems are realized and supported. ①. The third-party WMS system can realize remote procurement, inventory synchronization, and entrusted distribution through the open platform. ②. Customers can choose the WMS platform that has been connected to carry out warehousing and logistics management. Including inventory query and logistics tracking. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 The connection objects of the open platform of the present invention are briefly shown; Figure 2 The safety management table involved in the present invention is briefly shown; Figure 3 Briefly illustrate the user configuration involved in the present invention; Figure 4 Briefly show user access; Figure 5 Simplify the conversion process; Figure 6 Briefly show the necessary information of the user configuration module; Figure 7 The process of security verification of the present invention is briefly shown; Figure 8 Simplify the calling process; Fig. 9 Briefly illustrate the interface mapping scheme; Fig.10 A preferred embodiment of parameter mapping configuration is briefly shown; Fig.11 Briefly illustrate an embodiment of the signature of the present invention; Fig.12 The function assignment module in the present invention is shown; Fig.13 The interface for supply confirmation is shown; Fig.14 The interface for initiating a purchase order is shown; Fig.15 It shows the interface that enables three-party docking for customers. Fig.16 Shows the interface for managing customer docking. DETAILED DESCRIPTION

[0005] like Figure 1 A method for connecting an open platform and a remote user is shown. Step 1: Configure the user and assign the user a key and a signature method; Step 2: Perform security checks according to the user's request, including at least one of signature verification, data desensitization, and plug-in signature; Step 3: Dynamically adapt the interface, including interface protocol conversion and service model conversion; Step 4: Perform service governance, including flow control, degradation, and monitoring; Step 5: Open the corresponding functions to the user. from Figure 1 It can also be seen that the functions include at least one of: purchase order, purchase shipment, purchase return and inventory status. Through the standardized interface platform, the docking and scheduling of multiple remote WMS management systems are realized and supported. Figure 2 In the security verification, AK / SK authentication is used. Configure users ak and sk to implement the SignStrategyService interface. The specific business logic of the three-party signature is written in the implementation class. The signature implementation class of the docking interface is maintained in the saas_request_third_router table, such as Figure 3 shown. like Figure 4 As shown, the interface protocol conversion includes one of an external call to an internal dubbo service and an external http call to an internal http interface. 1. Add pom dependency 2. Call the interface and call the ThirdInterfaceApi.invoke(RequestParamDtorequestParamDto) method, such as Fig. 9 shown. 3-3. Request parameters, pass in RequestParamDto object, requestParamJson, partnerId, apiName, requestNo (uuid generated, request unique identifier), convert request parameters into json object string, and pass it to requestParamJson. Among them, partnerId and apiName are configured and allocated by the platform. Figure 4 As shown, the business model conversion is to dynamically convert the business model by configuring scripts to adapt to different external service requests. The corresponding configuration script is found through the unique representation of the application of the docking party. The script contains request parameters, response parameter conversion, and request protocol. like Figure 6 As shown, the conversion includes the following steps: step i, pushing the business data of the open platform; step ii, searching for mapping configuration, assembling business data, and standardizing the request business interface; step iii, processing business. Figure 7 In the example, the user has the following information: user key, open platform ID, open platform key, user name, and user ID. The present invention also relates to a device for connecting an open platform and a remote user using the above-mentioned access method for connecting an open platform and a remote user, comprising a user configuration module, a security verification module, a dynamic adaptation module, a service management module and a function assignment module. User configuration module such as Figure 8 shown. Configure user identity information, connect to third-party application information, etc. Security verification module: user security verification. Identity identification includes: recording the basic information of the partner, assigning the partner an appId (partner ID, ensuring uniqueness) and a secretKey (used for interface encryption, MD5 value). Anti-tampering involves: parameter signature: arrange non-empty request parameters (including appId) in ascending alphabetical order of the request parameter name, and concatenate them into stringA using the format of URL key-value pairs (i.e. key1=value1&key2=value2…); concatenate Secretkey to stringA to get string signTemp; perform MD5 operation on signTemp, and convert all characters of the obtained string to uppercase to get the sign value. The request carries the parameters appId and Sign, and only those with a legitimate identity appId and a correct signature Sign can be released. This solves the problems of identity authentication and parameter tampering. Even if the request parameters are hijacked, a legitimate request cannot be forged because the SecretKey cannot be obtained (it is only used for local signatures and does not participate in network transmission). Anti-replay involves: The tampering problem has been solved, but there is still a risk of forging a second request by reusing request parameters. Use the timestamp+nonce+redis solution. Add the current timestamp to each request. If the request validity period set by the open platform is 60s, when the request reaches the server, first compare the timestamp with the system time. If it is within 60s, the timestamp verification passes. If it is greater than 60s, the request expires. If only the timestamp is used to prevent replay, the request can still be replayed within 60s, so it is still not enough. A nonce random number (4 bits) also needs to be set. When the request reaches the server, search for the string with the key sign:nonce in redis. If not, create this key and set the expiration date to the expiration date of the timestamp, such as 60s. If this key exists, it means that the request has been requested within 60s, and the verification fails. Implement the demo request interface: http: / / api.test.com / test? name=hello&home=world&work=java, the client generates the current timestamp timestamp=now and a unique random string nonce=random. Arrange the non-empty request parameters (including appId) in ascending alphabetical order according to the request parameter name stringA = "appId = access & home = world & name = hello & work = java × tamp = 12323454324 & nonce = 2323"; concatenate the key SecretKey stringSignTemp = "appId = access & home = world & name = hello & work = java × tamp = 12323454324 & nonce = 2323 & secretKey = secret"; MD5 and convert to uppercase sign = MD5 (stringSignTemp).toUpperCase (); the final request is http: / / api.test.com / test? name = hello & home = world & work = java × tamp = 12323454324 & nonce = 2323 & sign = sign; the server filter intercepts. Figure 7 shown. Dynamic Adaptation Module: When partners call internal services, the open platform forwards requests and faces the following problems: The interfaces called by each platform are different. How to perform dynamic configuration? New interfaces may be added each time the connection is made. How to avoid transparent transmission development every time? When the solution open platform forwards the partner's request, it uses dubbo to generalize and call the internal service, without developing it every time; the open platform receives the request url, and then cuts off the last " / " in the request url, and uses the prefix as the source_url and the suffix as the method of the dubbo interface. The corresponding registration center and the corresponding interface class are found through source_url, and the corresponding method is dynamically called through reflection instantiation (the instantiated object needs to be cached, and does not need to be instantiated for each request). The interface routing table is designed as follows: CREATE TABLE `saas_request_router`( `id`int(11)NOT NULL AUTO_INCREMENT, 'application' varchar(50) NOT NULL COMMENT' Application template block(user / product / order / purchase)′, 'source_url' varchar(500) NOT NULL COMMENT' Request URL (if route_method = dubbo, request path format: / order / prescription / list, source_url= / order / prescription, that is One API class one source_url, where list is dubbo service provider Legal name)′, 'target_url' varchar(500) NOT NULL COMMENT 'Route URL (if route_method = dubbo, target_url is downstream dubbo service class name)′, 'url_desc' varchar(20) NOT NULL COMMENT 'Interface description', `registry`varchar(500)NULL DEFAULT NULL COMMENT'Registration center address (not required for REST interface)', `route_method`varchar(10)NOT NULLDEFAULT′dubbo′ COMMENT 'Routing method (get / post / redirect / dubbo)', `create_time`datetime(0)NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'creation time', `update_time`datetime(0)NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(0)COMMENT'Update time', The calling flow chart is as follows Figure 8 shown. Fig. 9 and 10 The interface parameter mapping conversion (output) of the internal service calling the partner interface faces the following problems: for the same business, the partner interface address and parameter fields are different, how to avoid customized development each time; the signature rules of the partner interface are different, how to dynamically expand. Interface parameter mapping scheme, dynamically generate request parameters and dynamic calls based on field mapping. exist Fig.11 In the design, plug-in signature scheme, modular design of open platform, data encryption means and identity authentication strategy are adopted in the process of developer access. The strategy mode is adopted to abstract the signature algorithm, the signature extension is configurable, and the signature extension is dynamically loaded. Several signature rules of external docking platforms are abstracted, and a signature strategy interface SignStategy is defined. Each signature rule abstracts the classes SignA, SignB, and SignC, and implements SignStategy. An interface adapter ApiAdapter is defined, which depends on SignStategy. When the interface adapter receives a call, it determines the signature strategy based on the appId parameter to generate the corresponding signature strategy instance, and uses the corresponding signature strategy instance for signing. Fig.12 A function granting module is provided: it can be used to enable / disable multiple third-party business connections for users. Fig.13 Provides computer operation and Fig.14 Initiate a purchase order as shown. Fig.15 The figure shows a client for providing a client with the capability of connecting with three parties and configuring client information. Fig.16It shows the three-party system for user management customer docking, and the management end of adaptation, security, service governance, etc.

Claims

1. A method for connecting an open platform and a remote user, characterized in that: The steps include: Step 1: Configure the user and assign the user a key and a signature method; Step 2: Perform security checks according to the user's request, including at least one of signature verification, data desensitization, and plug-in signature; Step 3: Dynamically adapt the interface, including interface protocol conversion and service model conversion; Step 4: Perform service governance, including flow control, degradation, and monitoring; Step 5: Open the corresponding functions to the user.

2. The method for connecting an open platform and a remote user according to claim 1, characterized in that: The functions include: at least one of purchase order, purchase shipment, purchase return and inventory status.

3. The method for connecting an open platform and a remote user according to claim 2, characterized in that: The safety inspection adopts AK / SK certification.

4. The method for connecting an open platform and a remote user according to claim 3, characterized in that: The interface protocol conversion includes one of external calling of internal dubbo service and external http calling of internal http interface.

5. The method for connecting an open platform and a remote user according to claim 4, characterized in that: The business model conversion is to dynamically convert the business model by configuring scripts to adapt to different external service requests.

6. The method for connecting an open platform and a remote user according to claim 5, characterized in that: The conversion includes the following steps: step i, pushing the business data of the open platform; step ii, searching for mapping configuration, assembling commercial business data, and standardizing the request for commercial business interface; step iii, processing commercial business.

7. The method for connecting an open platform and a remote user according to claim 6, characterized in that: The user has the following information: user key, open platform ID, open platform key, user name, user ID.

8. A device for connecting an open platform and a remote user using the access method for connecting an open platform and a remote user according to any one of claims 1 to 7, characterized in that: It includes user configuration module, security verification module, dynamic adaptation module, service governance module and function assignment module.

9. The device for connecting an open platform and a remote user according to claim 8, characterized in that: Including mobile phone and computer.

10. The device for connecting an open platform and a remote user according to claim 8, characterized in that: Including client and backend.

Images