External device control system, method, electronic device, medium, and product

Abstract

The application relates to the technical field of communication, and provides an external device control system and method, an electronic device, a medium and a product. The system comprises a thin client application server, a remote dictionary server Redis server, an application server and a device control application which are sequentially connected in communication. The thin client application server is used for receiving a control request of a thin client to an external device to be controlled, and publishing a request message to the Redis server based on the control request. The Redis server is used for forwarding the request message to the application server. The application server is used for distributing the request message to the device control application corresponding to an operator ID in the request message. The device control application is used for determining the external device to be controlled based on the request message, and controlling the external device to be controlled to perform an operation corresponding to the control request. The application releases the constraint of the external device connection cable, avoids the stability problem of the direct connection of the thin client and the external device, and can improve the control efficiency of the external device based on the thin client.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to an external device control system and method, an electronic device, a medium and a product. BACKGROUND

[0002] Currently, a thin client application can be connected to some external devices (such as an identity card collection device, a handwriting board, a card writer, etc., which can be referred to as external devices hereinafter) through a serial port or a universal serial bus (USB) port on a terminal, and then installed to the thin client through a control package provided by the device, so as to realize the operation of the external device through an interface method provided by the control package. However, the existing thin client directly connects the external device to perform the operation of the external device, and the connection of the external device is unstable, including that some external devices cannot be accessed, some external devices occasionally appear connection abnormities, and some external devices cannot be accessed when multiple external devices are connected, etc. SUMMARY

[0003] The embodiments of the present application provide an external device control system and method, an electronic device, a medium and a product, so as to improve the control efficiency of the external device based on the thin client and improve the user experience of the operator.

[0004] In a first aspect, the embodiments of the present application provide an external device control system, which comprises a thin client application server, a remote dictionary server Redis server, an application server and a device control application which are sequentially connected in communication.

[0005] The thin client application server is configured to receive a control request of a thin client for an external device to be controlled, and publish a request message to the Redis server based on the control request.

[0006] The Redis server is configured to forward the request message to the application server.

[0007] The application server is configured to distribute the request message to the device control application corresponding to the operator ID in the request message.

[0008] The device control application is configured to determine the external device to be controlled based on the request message, and control the external device to be controlled to perform an operation corresponding to the control request.

[0009] In one embodiment, the thin client application server is specifically configured to:

[0010] The control request is converted into message content; the message content includes the operator's employee number, the operation order number, and the requested operation content.

[0011] The target message service channel is determined based on the content of the requested operation.

[0012] The message content is published as a request message to the target message service channel of the Redis server.

[0013] In one embodiment, the Redis server is specifically used for:

[0014] The request message is forwarded to the application server that has subscribed to the target message service channel.

[0015] In one embodiment, the device control application is further configured to send the operation result data returned by the peripheral device to be controlled to the application server.

[0016] In one embodiment, the application server is further configured to publish a return message to the Redis server, which includes the operation result data returned by the device control application; the return message includes the operator's employee number, the operation work order number, and the operation result data.

[0017] In one embodiment, the Redis server is further configured to forward the returned message to the thin client application server.

[0018] In one embodiment, the thin client application server is further configured to write the return message sent by the Redis server into the Redis storage space based on the key-value pair storage format for the thin client to retrieve.

[0019] In a second aspect, embodiments of this application provide an external device control method, applied to the external device control system described in the first aspect, the external device control method comprising:

[0020] The thin client application server receives control requests from the thin client to the peripheral device to be controlled, and publishes a request message to the Redis server based on the control requests.

[0021] The request message is forwarded to the application server via the Redis server;

[0022] The application server distributes the request message to the device control application corresponding to the operator ID in the request message;

[0023] The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

[0024] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the external device control method described in the second aspect.

[0025] Fourthly, embodiments of this application provide a medium, which is a computer-readable storage medium including a computer program that, when executed by a processor, implements the external device control method described in the second aspect.

[0026] Fifthly, embodiments of this application provide a product, which is a computer program product, including a computer program that, when executed by a processor, implements the external device control method described in the second aspect.

[0027] The external device control system, method, electronic device, medium, and product provided in this application embodiment receive control requests from thin clients to be controlled peripherals through a thin client application server, and publish request messages to a Redis server based on the control requests; the Redis server forwards the request messages to the application server; the application server distributes the request messages to the device control application corresponding to the operator's employee number in the request messages; the device control application determines the peripheral to be controlled based on the request messages and controls the peripheral to execute the operation corresponding to the control requests. The thin client and the terminal where the device control application resides can accurately and stably control the peripherals through the thin client application server, Redis server, and application server background services, eliminating the constraints of peripheral connection cables, avoiding the stability issues of direct connection between thin clients and peripherals, improving the efficiency of peripheral control based on thin clients, and thus improving the user experience for operators. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of an application scenario for the external device control system provided in the embodiments of this application;

[0030] Figure 2 This is a flowchart illustrating how a Redis server acts as a message middleware in an external device control system, as provided in this application embodiment, processes requests initiated by a thin client to a mobile app.

[0031] Figure 3This is a flowchart illustrating how the Redis server acts as a message middleware in the external device control system provided in this application embodiment processes the results returned by the thin client and sends them to the thin client;

[0032] Figure 4 This is a flowchart of thin client polling in an external device control system provided in an embodiment of this application;

[0033] Figure 5 This is a flowchart illustrating the external device control method provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] It should be noted that in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The terms "upper," "lower," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Unless otherwise expressly specified and limited, the terms "installed," "connected," and "linked" should be interpreted broadly, for example, as a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection or an indirect connection through an intermediate medium; or a connection within two elements. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0037] The terms "first," "second," etc., used in this invention are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0038] The following examples and... Figures 1-6 The present invention provides a detailed description of the external device control system, method, electronic device, medium, and product.

[0039] Figure 1 This is a schematic diagram illustrating an application scenario of the external device control system provided in this application embodiment, with reference to... Figure 1 This application provides an external device control system, which may include a thin client application server, a remote dictionary server Redis server, an application server, and a device control application that are connected in sequence.

[0040] The thin client application server is used to receive control requests from thin clients to control peripherals, and to publish request messages to the Redis server based on the control requests.

[0041] A Redis server is used to forward request messages to the application server.

[0042] The application server is used to distribute request messages to the device control applications corresponding to the operator ID in the request message;

[0043] Device control applications are used to determine the peripheral device to be controlled based on request messages, and to control the peripheral device to perform the operation corresponding to the control request.

[0044] Thin client application servers are specifically used for:

[0045] The control request is converted into message content; the message content includes the operator's employee ID, the operation order number, and the requested operation content.

[0046] Determine the target message service channel based on the content of the requested operation;

[0047] The message content is published as a request message to the target message service channel of the Redis server.

[0048] Redis servers are specifically used for:

[0049] The request message is forwarded to the application server that has subscribed to the target message service channel.

[0050] Device control applications are also used to send the operation result data returned by the peripheral device to be controlled to the application server.

[0051] The application server is also used to publish the operation result data returned by the device control application to the Redis server; the return message includes the operator's employee number, operation order number, and operation result data.

[0052] The Redis server is also used to forward returned messages to thin client application servers.

[0053] The thin client application server is also used to write the return messages sent by the Redis server into the Redis storage space in a key-value pair storage format for thin clients to retrieve.

[0054] It should be noted that the device control application is an application program pre-installed in the terminal. In this application, the device control application is used to control the connected peripheral devices.

[0055] A thin client application server can be any server in a backend application server cluster. The thin client application server can communicate with thin clients via a transport network.

[0056] An application server can specifically be an application (APP) server, which can communicate with the terminal (such as a mobile phone) where the application is located through a transmission network.

[0057] In one embodiment, the terminal (e.g., a mobile phone) where the device control application of this application is located can communicate with a designated peripheral device located in a Bluetooth box via Bluetooth. The designated peripheral device in the Bluetooth box may include an ID card area for reading ID cards and a card slot for writing Subscriber Identity Module (SIM) cards.

[0058] It should be noted that before performing business operations, the operator needs to log in to both the thin client's operation interface and the mobile Bluetooth peripheral operation APP (i.e., the device control application mentioned above). The mobile APP and the peripheral establish a connection via Bluetooth and enter the APP Ready mode for receiving operation commands.

[0059] Furthermore, the operator can initiate a request to control a specified peripheral device (hereinafter referred to as the peripheral device to be controlled) from the corresponding application on the thin client (such as a request to read ID card information). The control request is submitted to the thin client application server (also referred to as the thin client backend server), and the thin client then initiates a polling request to the thin client application server to obtain the execution result information of the peripheral device operation. The polling can be configured according to a certain time strategy (such as the first polling is 5 seconds after the operation is initiated, the second polling is at an interval of 3 seconds, and the interval from the third polling onwards is 1 second).

[0060] It should be noted that this application uses a Redis server as the message middleware. The decision to split the message into multiple channels can be assessed based on the business type and volume to prevent blocking in a single business scenario. In this application scenario, thin clients send control requests, controlling the app to subscribe to messages and operate Bluetooth-connected peripherals via devices on the mobile phone. Assuming 30,000 connected terminals and a concurrency rate of 15% (maximum approximately 4,500 connections), a single Redis server supports around 50,000 concurrent connections. Therefore, the number of channels can be arbitrarily set without being affected.

[0061] Redis is an open-source data storage system that can be used as a database, cache, and message broker.

[0062] For ease of business processing in this application scenario, two message middleware services are defined in the Redis server: a Redis message service for receiving tasks and a Redis message service for returning data. These services handle messages for thin client operation requests and messages for mobile client operation result data returns, respectively. Each message service is further divided into two channels based on peripheral device category, corresponding to ID card reader operations and SIM card writing operations.

[0063] In this application's Redis message middleware, under the publish / subscribe (pub / sub) mode, a channel can have multiple subscribers, and a subscriber can also subscribe to multiple channels. In this application scenario, a thin client application server and an application server act as the message publisher and subscriber, respectively.

[0064] Redis's publish / subscribe model features at-most-once message delivery, meaning a message is delivered only once. Once a message is sent by the Redis server, it cannot be sent again. If a subscriber is unable to process a message (e.g., due to an error or network disconnection), the message is lost and must be resent by the publisher. Compared to traditional polling, Redis's publish / subscribe model offers lower latency and higher real-time communication.

[0065] Furthermore, upon receiving a control request, the thin client application server converts it into message content, including the operator's employee ID, the operation ticket number (which serves as a unique identifier throughout the entire process and is used as the basis for result retrieval upon final return), and the requested operation content. The request operation content may also include the business type and business parameters. The thin client application server can determine the channel corresponding to the peripheral device to be controlled based on the business type and define it as the target message service channel. Each peripheral device operation request is assigned a unique operation ticket number according to certain rules, such as the operator's employee ID + timestamp + 3-digit sequence number.

[0066] At this point, the background service in the thin client application server acts as a message producer, publishing the message content as a request message to the target message service channel of the Redis server.

[0067] After the background service in the thin client application server publishes a request message to the Redis server, the application server, as a message subscriber, subscribes to the target message service in advance and establishes a long connection between the subscriber and the Redis server. After the target message service channel of the Redis server receives the request message, it forwards the request message to the application server that has subscribed to the channel.

[0068] After receiving the request message from the channel, the application server parses the message content to obtain the operator's ID and business parameters. Then, it iterates through the device control applications that are connected to the application server (the device control applications have been opened in advance and are waiting to receive messages from the application server), identifies the device control application that is logged in with the operator's ID, and pushes the business parameters to the logged-in device control application through the established long connection.

[0069] It should be noted that the device control application has already connected to the specified peripheral via Bluetooth before startup. After receiving the service parameters, the device control application can call the Software Development Kit (SDK) interface of the peripheral to be controlled, and operate the peripheral located in the Bluetooth box to perform the operation corresponding to the control request. For example, it can operate the peripheral to read information (such as blank SIM card information, ID card information) or operate the peripheral to write information (such as writing International Mobile Subscriber Identity (IMSI) information to a blank card). After processing, it returns the operation result data to the device control application, which then sends it to the application server through a long connection, thus completing a positive message request process.

[0070] In this process, after the device control application completes the operation on the peripheral device to be controlled, it obtains the return data from the Bluetooth box and then returns the returned operation result data to the application server. The application server converts the operation result data and information such as the operator's employee number and operation work order number into message content and publishes it as a return message to the corresponding channel of the Redis server (i.e., the target message service channel). At this time, the application server acts as the message producer and completes the message publication.

[0071] The thin client application server, acting as a subscriber to the returned message, parses and processes the returned message from the corresponding channel of the Redis server to obtain the operator's employee ID, operation order number, and operation result data. The obtained data is then written to the Redis server's storage space based on the key-value pair (KV value) storage format, where K is the operation order number and V is the operation order status and operation result data.

[0072] The thin client submits a polling request for the results of peripheral device operations. The thin client application server receives the polling request, queries the memory K-value of the operation order number, retrieves the data corresponding to the V-value, parses it, and returns it to the thin client. At this point, the interface stops waiting, loads the data, and continues to execute other business processes on the thin client. If no K-value record is found, the next polling continues until a timeout occurs, at which point the operation request is re-initiated. The data cleanup of the memory KV values ​​is handled uniformly by the Redis server's cache management strategy.

[0073] In the above process, both the thin client application server and the application server play two roles: both message producer and message subscriber for the Redis server.

[0074] Figure 2 The flowchart illustrating how the Redis server acts as a message middleware in the external device control system provided in this application handles requests initiated by thin clients to the mobile app, is shown below. Figure 2 In one embodiment, the process includes:

[0075] Each thin client (e.g., thin client 1 to thin client n) initiates a request. After receiving the request, the thin client backend service, acting as the message publisher, generates message content, including the operation work order number, the operator's employee number, the business type, and the business parameters. Based on the business type, the message is then published to the corresponding message category channel of the Redis server with the message body corresponding to the channel. In this application scenario, for example, two channels can be set up, one for ID card reader operation and the other for SIM card writing operation.

[0076] After the thin client submits a request, in order to obtain the server's processing result in a timely manner, it uses a polling method to query the memory key-value (KV) value. The interface waits for the return. The polling is configured according to a certain time strategy (e.g., the first polling is 5 seconds after the operation is initiated, the second polling is 3 seconds after the interval, and the interval from the third polling onwards is 1 second). The operation work order number of the memory K value is queried, the V value data is retrieved, parsed and returned to the thin client, the interface stops waiting, the data is loaded, and the thin client continues to process the business. If no K value record is retrieved, the next polling continues until the timeout occurs and the operation request is re-initiated.

[0077] After the thin client backend service publishes a message to the Redis server, the APP application server, as a message subscriber, subscribes to the channel in advance and establishes a long connection between the subscriber and the Redis server. After the Redis server receives the published message in the corresponding channel, it sends the message to the APP client that has subscribed to the messages of that channel (such as ID card recognition messages or SIM card writing messages). After receiving the message from the channel, the APP client parses the message content, obtains the operator's ID and business parameters, and then iterates through the device control applications that are connected to the application server (these applications have been opened in advance and are in a state of waiting to receive messages from the application server), finds the operator's ID, and pushes the business parameter information to the APP client (such as mobile phone 1 to mobile phone n) through the established long connection.

[0078] When the APP starts up, it has already connected to the peripheral device via Bluetooth. After receiving the peripheral device operation message, the APP parses the business parameters, calls the peripheral device's SDK interface, and implements the peripheral device operation. After the peripheral device completes the processing, it returns the operation result data to the APP, which then sends it to the APP client through a long connection. At this point, the system has completed a positive message request process.

[0079] Figure 3 The flowchart for the Redis server acting as a message middleware in the external device control system provided in this application embodiment, which processes the results returned by the thin client and sends them to the thin client, is shown below. Figure 3 In one embodiment, the process includes:

[0080] After the mobile APP application (hereinafter referred to as the APP, implemented through mobile phone 1 to mobile phone n) returns data to the APP application service, the APP application server publishes a message to the corresponding message category channel of the Redis server. At this time, the APP application server becomes a message publisher. The message content includes the operation work order number, the operator's employee number, the business type, and the operation result parameters (such as ID card data, the result of SIM card operation). According to the business type, the message is published to the corresponding channel of the Redis server. In this application scenario, two channels are set up, corresponding to the business types of ID card reading information return and SIM card writing operation result return respectively.

[0081] The thin client backend service then transforms into a message subscriber, establishing a long connection between the subscriber and the Redis server. After receiving the operation result message from the Redis server in the corresponding channel, the thin client backend service parses the message content to obtain the operator's employee number, operation order number, and operation result parameters (such as ID card data reading or SIM card operation result). The operation order number is used as the K value, and the operator's employee number and operation result parameters are used as the V value. These KV key-value pairs are recorded in the distributed memory of the Redis server.

[0082] The thin client application (e.g., thin client 1 to thin client n) polls the thin client backend server for peripheral operation results. The thin client backend server queries the distributed memory data by operation order number. If a result is found, the information is returned to the thin client; otherwise, the thin client is notified that the operation result has not yet been returned. Polling has a timeout setting. If no record is obtained within the timeout period, the thin client exits the waiting state and displays a timeout message to the operator.

[0083] After the thin client polls for a request and receives a message from the thin client's backend server, if the message indicates a successful operation result, the polling ends, the interface stops waiting, and subsequent business processing continues based on the returned data. This completes one reverse message feedback and realizes a closed-loop processing process involving the thin client, backend server, Redis server, APP server, APP, and peripherals. If the message indicates that no operation result was obtained and the polling has not timed out, the client waits for the set polling time limit and initiates the next polling. If the polling has timed out, the polling is stopped, and relevant business logic is processed as if the operation failed.

[0084] Figure 4 The flowchart of thin client polling in the external device control system provided in this application embodiment is referred to. Figure 4 In one embodiment, in order to quickly obtain the return data of the operation results on the mobile terminal (device control application), a polling query process for the return results is added to the thin client. The query condition is the request initiated by the thin client. An operation work order number is generated based on the request. This work order number is automatically generated each time a request is initiated and is not repeated.

[0085] Furthermore, the thin client interface enters a polling state, during which no operation can be performed;

[0086] Furthermore, determine whether the operation work order number has been returned within the predetermined time. If so, exit the waiting state, read the data, and continue to the next business operation.

[0087] Otherwise, check if a timeout has occurred. If not, re-enter the polling process. If so, exit the waiting state, provide a prompt, and indicate that the operation request needs to be initiated again.

[0088] It should be further noted that, in this application, the connection between the mobile app and the Bluetooth box requires that the peripheral terminal support connection via Bluetooth between Android / iOS terminals, and Bluetooth functionality is a basic requirement for Android / iOS terminals.

[0089] Functions for connecting to Bluetooth boxes: Detect Bluetooth permissions and whether Bluetooth is enabled, display a list of available Bluetooth devices, refresh the Bluetooth list, connect to Bluetooth devices, disconnect Bluetooth devices, record / update recently connected Bluetooth devices, and automatically connect to recently connected Bluetooth devices.

[0090] Specifically, this may include the following steps:

[0091] Detecting Bluetooth devices:

[0092] To check Bluetooth device permissions and whether Bluetooth connection is enabled, the app needs to request and obtain Bluetooth / location permissions.

[0093] If Bluetooth permission is not obtained, authorization must be enabled on the terminal side first; if permission has been obtained, check if Bluetooth is enabled on the phone. If it is not enabled, enable it and list the Bluetooth devices; if permission has been obtained and Bluetooth is enabled, display the list of available Bluetooth devices.

[0094] Connecting Bluetooth devices:

[0095] Select the Bluetooth device required for the business and connect to it. Call the connect(Stringmac) method that provides the Bluetooth box protocol to try to connect to the Bluetooth box device, and perform corresponding processing according to the interface call method. Save the Bluetooth device information. If the Bluetooth connection fails to return within the set time, the device connection will fail.

[0096] Disconnect Bluetooth:

[0097] If the business operation has been completed using the Bluetooth box and a message has been returned to the APP server, and it is necessary to disconnect, then call the disconnect() method of the Bluetooth box protocol to disconnect the Bluetooth box device.

[0098] Bluetooth box connection business operations:

[0099] Using the interface protocols of the SDK package provided by the Bluetooth box, including methods for reading ID cards, reading SIM cards, and writing SIM cards, the corresponding business functions of the thin client are completed, and the processing results are returned to the server for processing.

[0100] The external device control system provided in this application embodiment receives control requests from thin clients to be controlled peripherals through a thin client application server, and publishes a request message to a Redis server based on the control request; the Redis server forwards the request message to the application server; the application server distributes the request message to the device control application corresponding to the operator's employee number in the request message; the device control application determines the peripheral to be controlled based on the request message and controls the peripheral to execute the operation corresponding to the control request. The thin client and the terminal where the device control application resides can accurately and stably control the peripherals through the thin client application server, Redis server, and other background services of the application server, eliminating the constraints of peripheral connection cables, avoiding the stability problems of direct connection between thin clients and peripherals, improving the efficiency of peripheral control based on thin clients, and thus improving the user experience for operators.

[0101] This application addresses the issue of stable access to peripherals by thin clients by providing a solution for collaborative operation of peripherals via mobile phone. The peripherals must support Bluetooth connectivity, allowing the mobile app to directly control them after the phone connects via Bluetooth. When a thin client needs to control a peripheral, it sends the relevant request to the corresponding mobile app server via a Redis message middleware subscription. The application server then notifies the relevant application, which connects to the peripheral via Bluetooth and executes the business operation.

[0102] In this application, the server-side of the APP application and the server-side of the thin client act as subscribers and publishers of the Redis message channel. Through the application of the two servers, the categories of the operator's employee ID and the operator's peripheral device are combined, and the broadcast message service transmission mechanism of the Redis server is transformed into a point-to-point message connection service, realizing a point-to-point message mode for business message publishing and subscription.

[0103] Thin clients and mobile phones collaborate through Redis messages and background services, enabling thin client applications to transparently and seamlessly operate Bluetooth peripherals. The operator perceives the thin client's actions as similar to operating a directly connected peripheral. This application improves the collaboration efficiency between thin clients and peripherals by introducing a publish / subscribe pattern from Redis message middleware for operation coordination.

[0104] Figure 5 A flowchart illustrating the external device control method provided in this application embodiment is shown below. Figure 5 This application provides an external device control method, which may include:

[0105] Step 100: Receive control requests from the thin client to the peripheral device to be controlled via the thin client application server, and publish request messages to the Redis server based on the control requests;

[0106] Step 200: Forward the request message to the application server via the Redis server;

[0107] Step 300: Distribute the request message to the device control application corresponding to the operator ID in the request message through the application server;

[0108] Step 400: The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

[0109] It should be noted that the execution subject of the external device control method provided in this application embodiment can be the aforementioned external device control system.

[0110] It should be noted that the device control application is set in the terminal and is used to control peripherals.

[0111] A thin client application server can be any server in a backend application server cluster. The thin client application server can communicate with thin clients via a transport network.

[0112] An application server can specifically be an application (APP) server, which can communicate with the terminal (such as a mobile phone) where the application is located through a transmission network.

[0113] In one embodiment, the terminal (e.g., a mobile phone) where the device control application of this application is located can communicate with a designated peripheral device located in a Bluetooth box via Bluetooth. The designated peripheral device in the Bluetooth box may include an ID card area for reading ID cards and a card slot for writing Subscriber Identity Module (SIM) cards.

[0114] It should be noted that before performing business operations, the operator needs to log in to both the thin client's operation interface and the mobile Bluetooth peripheral operation APP (i.e., the device control application mentioned above). The mobile APP and the peripheral establish a connection via Bluetooth and enter the APP Ready mode for receiving operation commands.

[0115] Furthermore, the operator can initiate a request to control a specified peripheral device (hereinafter referred to as the peripheral device to be controlled) from the corresponding application on the thin client (such as a request to read ID card information). The control request is submitted to the thin client application server (also referred to as the thin client backend server), and the thin client then initiates a polling request to the thin client application server to obtain the execution result information of the peripheral device operation. The polling can be configured according to a certain time strategy (such as the first polling is 5 seconds after the operation is initiated, the second polling is at an interval of 3 seconds, and the interval from the third polling onwards is 1 second).

[0116] It should be noted that this application uses a Redis server as the message middleware. The decision to split the message into multiple channels can be assessed based on the business type and volume to prevent blocking in a single business scenario. In this application scenario, thin clients send control requests, controlling the app to subscribe to messages and operate Bluetooth-connected peripherals via devices on the mobile phone. Assuming 30,000 connected terminals and a concurrency rate of 15% (maximum approximately 4,500 connections), a single Redis server supports around 50,000 concurrent connections. Therefore, the number of channels can be arbitrarily set without being affected.

[0117] For ease of business processing in this application scenario, two message middleware services are defined in the Redis server: a Redis message service for receiving tasks and a Redis message service for returning data. These services handle messages for thin client operation requests and messages for mobile client operation result data returns, respectively. Each message service is further divided into two channels based on peripheral device category, corresponding to ID card reader operations and SIM card writing operations.

[0118] In this application's Redis message middleware, under the publish / subscribe (pub / sub) mode, a channel can have multiple subscribers, and a subscriber can also subscribe to multiple channels. In this application scenario, a thin client application server and an application server act as the message publisher and subscriber, respectively.

[0119] Redis's publish / subscribe model features at-most-once message delivery, meaning a message is delivered only once. Once a message is sent by the Redis server, it cannot be sent again. If a subscriber is unable to process a message (e.g., due to an error or network disconnection), the message is lost and must be resent by the publisher. Compared to traditional polling, Redis's publish / subscribe model offers lower latency and higher real-time communication.

[0120] Furthermore, upon receiving a control request, the thin client application server converts it into message content, including the operator's employee ID, the operation ticket number (which serves as a unique identifier throughout the entire process and is used as the basis for result retrieval upon final return), and the requested operation content. The request operation content may also include the business type and business parameters. The thin client application server can determine the channel corresponding to the peripheral device to be controlled based on the business type and define it as the target message service channel. Each peripheral device operation request is assigned a unique operation ticket number according to certain rules, such as the operator's employee ID + timestamp + 3-digit sequence number.

[0121] At this point, the background service in the thin client application server acts as a message producer, publishing the message content as a request message to the target message service channel of the Redis server.

[0122] After the background service in the thin client application server publishes a request message to the Redis server, the application server, as a message subscriber, subscribes to the target message service in advance and establishes a long connection between the subscriber and the Redis server. After the target message service channel of the Redis server receives the request message, it forwards the request message to the application server that has subscribed to the channel.

[0123] After receiving the request message from the channel, the application server parses the message content to obtain the operator's ID and business parameters. Then, it iterates through the device control applications that are connected to the application server (the device control applications have been opened in advance and are waiting to receive messages from the application server), identifies the device control application that is logged in with the operator's ID, and pushes the business parameters to the logged-in device control application through the established long connection.

[0124] It should be noted that the device control application has already connected to the specified peripheral via Bluetooth before startup. After receiving the service parameters, the device control application can call the Software Development Kit (SDK) interface of the peripheral to be controlled, and operate the peripheral located in the Bluetooth box to perform the operation corresponding to the control request. For example, it can operate the peripheral to read information (such as blank SIM card information, ID card information) or operate the peripheral to write information (such as writing International Mobile Subscriber Identity (IMSI) information to a blank card). After processing, it returns the operation result data to the device control application, which then sends it to the application server through a long connection, thus completing a positive message request process.

[0125] In this process, after the device control application completes the operation on the peripheral device to be controlled, it obtains the return data from the Bluetooth box and then returns the returned operation result data to the application server. The application server converts the operation result data and information such as the operator's employee number and operation work order number into message content and publishes it as a return message to the corresponding channel of the Redis server (i.e., the target message service channel). At this time, the application server acts as the message producer and completes the message publication.

[0126] The thin client application server, acting as a subscriber to the returned message, parses and processes the returned message from the corresponding channel of the Redis server to obtain the operator's employee ID, operation order number, and operation result data. The obtained data is then written to the Redis server's storage space based on the key-value pair (KV value) storage format, where K is the operation order number and V is the operation order status and operation result data.

[0127] The thin client submits a polling request for the results of peripheral device operations. The thin client application server receives the polling request, queries the memory K-value of the operation order number, retrieves the data corresponding to the V-value, parses it, and returns it to the thin client. At this point, the interface stops waiting, loads the data, and continues to execute other business processes on the thin client. If no K-value record is found, the next polling continues until a timeout occurs, at which point the operation request is re-initiated. The data cleanup of the memory KV values ​​is handled uniformly by the Redis server's cache management strategy.

[0128] In the above process, both the thin client application server and the application server play two roles: both message producer and message subscriber for the Redis server.

[0129] Figure 2 The flowchart illustrating how the Redis server acts as a message middleware in the external device control system provided in this application handles requests initiated by thin clients to the mobile app, is shown below. Figure 2 In one embodiment, the process includes:

[0130] Each thin client (e.g., thin client 1 to thin client n) initiates a request. After receiving the request, the thin client backend service, acting as the message publisher, generates message content, including the operation work order number, the operator's employee number, the business type, and the business parameters. Based on the business type, the message is then published to the corresponding message category channel of the Redis server with the message body corresponding to the channel. In this application scenario, for example, two channels can be set up, one for ID card reader operation and the other for SIM card writing operation.

[0131] After the thin client submits a request, in order to obtain the server's processing result in a timely manner, it uses a polling method to query the memory key-value (KV) value. The interface waits for the return. The polling is configured according to a certain time strategy (e.g., the first polling is 5 seconds after the operation is initiated, the second polling is 3 seconds after the interval, and the interval from the third polling onwards is 1 second). The operation work order number of the memory K value is queried, the V value data is retrieved, parsed and returned to the thin client, the interface stops waiting, the data is loaded, and the thin client continues to process the business. If no K value record is retrieved, the next polling continues until the timeout occurs and the operation request is re-initiated.

[0132] After the thin client backend service publishes a message to the Redis server, the APP application server, as a message subscriber, subscribes to the channel in advance and establishes a long connection between the subscriber and the Redis server. After the Redis server receives the published message in the corresponding channel, it sends the message to the APP client that has subscribed to the messages of that channel (such as ID card recognition messages or SIM card writing messages). After receiving the message from the channel, the APP client parses the message content, obtains the operator's ID and business parameters, and then iterates through the device control applications that are connected to the application server (these applications have been opened in advance and are in a state of waiting to receive messages from the application server), finds the operator's ID, and pushes the business parameter information to the APP client (such as mobile phone 1 to mobile phone n) through the established long connection.

[0133] When the APP starts up, it has already connected to the peripheral device via Bluetooth. After receiving the peripheral device operation message, the APP parses the business parameters, calls the peripheral device's SDK interface, and implements the peripheral device operation. After the peripheral device completes the processing, it returns the operation result data to the APP, which then sends it to the APP client through a long connection. At this point, the system has completed a positive message request process.

[0134] Figure 3 The flowchart for the Redis server acting as a message middleware in the external device control system provided in this application embodiment, which processes the results returned by the thin client and sends them to the thin client, is shown below. Figure 3 In one embodiment, the process includes:

[0135] After the mobile APP application (hereinafter referred to as the APP, implemented through mobile phone 1 to mobile phone n) returns data to the APP application service, the APP application server publishes a message to the corresponding message category channel of the Redis server. At this time, the APP application server becomes a message publisher. The message content includes the operation work order number, the operator's employee number, the business type, and the operation result parameters (such as ID card data, the result of SIM card operation). According to the business type, the message is published to the corresponding channel of the Redis server. In this application scenario, two channels are set up, corresponding to the business types of ID card reading information return and SIM card writing operation result return respectively.

[0136] The thin client backend service then transforms into a message subscriber, establishing a long connection between the subscriber and the Redis server. After receiving the operation result message from the Redis server in the corresponding channel, the thin client backend service parses the message content to obtain the operator's employee number, operation order number, and operation result parameters (such as ID card data reading or SIM card operation result). The operation order number is used as the K value, and the operator's employee number and operation result parameters are used as the V value. These KV key-value pairs are recorded in the distributed memory of the Redis server.

[0137] The thin client application (e.g., thin client 1 to thin client n) polls the thin client backend server for peripheral operation results. The thin client backend server queries the distributed memory data by operation order number. If a result is found, the information is returned to the thin client; otherwise, the thin client is notified that the operation result has not yet been returned. Polling has a timeout setting. If no record is obtained within the timeout period, the thin client exits the waiting state and displays a timeout message to the operator.

[0138] After the thin client polls for a request and receives a message from the thin client's backend server, if the message indicates a successful operation result, the polling ends, the interface stops waiting, and subsequent business processing continues based on the returned data. This completes one reverse message feedback and realizes a closed-loop processing process involving the thin client, backend server, Redis server, APP server, APP, and peripherals. If the message indicates that no operation result was obtained and the polling has not timed out, the client waits for the set polling time limit and initiates the next polling. If the polling has timed out, the polling is stopped, and relevant business logic is processed as if the operation failed.

[0139] Figure 4 The flowchart of thin client polling in the external device control system provided in this application embodiment is referred to. Figure 4 In one embodiment, in order to quickly obtain the return data of the operation results on the mobile terminal (device control application), a polling query process for the return results is added to the thin client. The query condition is the request initiated by the thin client. An operation work order number is generated based on the request. This work order number is automatically generated each time a request is initiated and is not repeated.

[0140] Furthermore, the thin client interface enters a polling state, during which no operation can be performed;

[0141] Furthermore, determine whether the operation work order number has been returned within the predetermined time. If so, exit the waiting state, read the data, and continue to the next business operation.

[0142] Otherwise, check if a timeout has occurred. If not, re-enter the polling process. If so, exit the waiting state, provide a prompt, and indicate that the operation request needs to be initiated again.

[0143] It should be further noted that, in this application, the connection between the mobile app and the Bluetooth box requires that the peripheral terminal support connection via Bluetooth between Android / iOS terminals, and Bluetooth functionality is a basic requirement for Android / iOS terminals.

[0144] Functions for connecting to Bluetooth boxes: Detect Bluetooth permissions and whether Bluetooth is enabled, display a list of available Bluetooth devices, refresh the Bluetooth list, connect to Bluetooth devices, disconnect Bluetooth devices, record / update recently connected Bluetooth devices, and automatically connect to recently connected Bluetooth devices.

[0145] Specifically, this may include the following steps:

[0146] Detecting Bluetooth devices:

[0147] To check Bluetooth device permissions and whether Bluetooth connection is enabled, the app needs to request and obtain Bluetooth / location permissions.

[0148] If Bluetooth permission is not obtained, authorization must be enabled on the terminal side first; if permission has been obtained, check if Bluetooth is enabled on the phone. If it is not enabled, enable it and list the Bluetooth devices; if permission has been obtained and Bluetooth is enabled, display the list of available Bluetooth devices.

[0149] Connecting Bluetooth devices:

[0150] Select the Bluetooth device required for the business and connect to it. Call the connect(Stringmac) method that provides the Bluetooth box protocol to try to connect to the Bluetooth box device, and perform corresponding processing according to the interface call method. Save the Bluetooth device information. If the Bluetooth connection fails to return within the set time, the device connection will fail.

[0151] Disconnect Bluetooth:

[0152] If the business operation has been completed using the Bluetooth box and a message has been returned to the APP server, and it is necessary to disconnect, then call the disconnect() method of the Bluetooth box protocol to disconnect the Bluetooth box device.

[0153] Bluetooth box connection business operations:

[0154] Using the interface protocols of the SDK package provided by the Bluetooth box, including methods for reading ID cards, reading SIM cards, and writing SIM cards, the corresponding business functions of the thin client are completed, and the processing results are returned to the server for processing.

[0155] The external device control method provided in this application embodiment receives control requests from a thin client to a peripheral device to be controlled through a thin client application server, and publishes a request message to a Redis server based on the control request; the Redis server forwards the request message to the application server; the application server distributes the request message to the device control application corresponding to the operator's employee number in the request message; the device control application determines the peripheral device to be controlled based on the request message, and controls the peripheral device to execute the operation corresponding to the control request. The thin client and the terminal where the device control application resides can accurately and stably control the peripheral device through the thin client application server, Redis server, and other background services of the application server, eliminating the constraints of peripheral connection cables, avoiding the stability problems of direct connection between thin clients and peripherals, improving the efficiency of peripheral control based on thin clients, and thus improving the user experience for operators.

[0156] This application addresses the issue of stable access to peripherals by thin clients by providing a solution for collaborative operation of peripherals via mobile phone. The peripherals must support Bluetooth connectivity, allowing the mobile app to directly control them after the phone connects via Bluetooth. When a thin client needs to control a peripheral, it sends the relevant request to the corresponding mobile app server via a Redis message middleware subscription. The application server then notifies the relevant application, which connects to the peripheral via Bluetooth and executes the business operation.

[0157] In this application, the server-side of the APP application and the server-side of the thin client act as subscribers and publishers of the Redis message channel. Through the application of the two servers, the categories of the operator's employee ID and the operator's peripheral device are combined, and the broadcast message service transmission mechanism of the Redis server is transformed into a point-to-point message connection service, realizing a point-to-point message mode for business message publishing and subscription.

[0158] Thin clients and mobile phones collaborate through Redis messages and background services, enabling thin client applications to transparently and seamlessly operate Bluetooth peripherals. The operator perceives the thin client's actions as similar to operating a directly connected peripheral. This application improves the collaboration efficiency between thin clients and peripherals by introducing a publish / subscribe pattern from Redis message middleware for operation coordination.

[0159] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include a processor 610, a communication interface 620, a memory 630, and a communication bus 640, wherein the processor 610, the communication interface 620, and the memory 630 communicate with each other via the communication bus 640. The processor 610 can call a computer program stored in the memory 630 to execute the steps of an image generation method, such as:

[0160] The thin client application server receives control requests from the thin client to the peripheral device to be controlled, and publishes a request message to the Redis server based on the control requests.

[0161] The request message is forwarded to the application server via the Redis server;

[0162] The application server distributes the request message to the device control application corresponding to the operator ID in the request message;

[0163] The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

[0164] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0165] On the other hand, this application discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as: receiving a control request from a thin client to a peripheral device to be controlled through a thin client application server, and publishing a request message to a Redis server based on the control request.

[0166] The request message is forwarded to the application server via the Redis server;

[0167] The application server distributes the request message to the device control application corresponding to the operator ID in the request message;

[0168] The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

[0169] On the other hand, embodiments of this application also provide a storage medium, which is a computer-readable storage medium storing a computer program. The computer program is used to cause a processor to execute the steps of the methods provided in the above embodiments, including, for example:

[0170] The thin client application server receives control requests from the thin client to the peripheral device to be controlled, and publishes a request message to the Redis server based on the control requests.

[0171] The request message is forwarded to the application server via the Redis server;

[0172] The application server distributes the request message to the device control application corresponding to the operator ID in the request message;

[0173] The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

[0174] The computer-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic storage (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical storage (e.g., CD, DVD, BD, HVD), and semiconductor storage (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0175] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0176] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0177] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An external device control system, characterized in that, This includes a thin client application server, a remote dictionary server (Redis server), an application server, and a device control application that are connected in sequence. The thin client application server is used to receive control requests from thin clients to the peripheral devices to be controlled, and to publish request messages to the Redis server based on the control requests; The Redis server is used to forward the request message to the application server; The application server is used to distribute the request message to the device control application corresponding to the operator employee number in the request message; The device control application is used to determine the peripheral device to be controlled based on the request message, and to control the peripheral device to be controlled to perform the operation corresponding to the control request. The thin client application server is specifically used for: The control request is converted into message content; the message content includes the operator's employee number, the operation order number, and the requested operation content. The target message service channel is determined based on the content of the requested operation. The message content is published as a request message to the target message service channel of the Redis server.

2. The external device control system according to claim 1, characterized in that, The Redis server is specifically used for: The request message is forwarded to the application server that has subscribed to the target message service channel.

3. The external device control system according to claim 1, characterized in that, The device control application is also used to send the operation result data returned by the peripheral device to be controlled to the application server.

4. The external device control system according to claim 3, characterized in that, The application server is further configured to publish a return message to the Redis server, which includes the operation result data returned by the device control application; the return message includes the operator's employee number, the operation work order number, and the operation result data.

5. The external device control system according to claim 4, characterized in that, The Redis server is also used to forward the returned message to the thin client application server.

6. The external device control system according to claim 5, characterized in that, The thin client application server is also used to write the return message sent by the Redis server into the Redis storage space based on the key-value pair storage format for the thin client to retrieve.

7. An external device control method, characterized in that, The external device control method, applied to the external device control system according to any one of claims 1-6, comprises: The thin client application server receives control requests from the thin client to the peripheral device to be controlled, and publishes a request message to the Redis server based on the control requests. The request message is forwarded to the application server via the Redis server; The application server distributes the request message to the device control application corresponding to the operator ID in the request message; The device control application determines the peripheral device to be controlled based on the request message and controls the peripheral device to perform the operation corresponding to the control request.

8. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the external device control method of claim 7.

9. A medium, said medium being a computer-readable storage medium, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the external device control method of claim 7.

10. A product, said product being a computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the external device control method of claim 7.

Images