Cross-network and cross-region financial robot networking structure and application method

Abstract

The invention discloses a cross-network and cross-region financial robot networking structure and an application method.The networking structure comprises a networking center module, a data center module and a dispatching center module, server sides are deployed in a group network in a centralized mode, and robot sides are deployed in a molecular company network or the group network; the server side and the robot side are in network intercommunication, a client selects a task instruction at a console of the server side, and the robot side polls a console interface to obtain the task instruction; loading a scene script package and executing a task by a robot end executor according to a task instruction, selecting a multi-task cooperation strategy according to a task template, triggering multi-task cooperation, and forming a task chain; after multi-task cooperation is completed, a console interface is called, and result data is returned; according to the networking structure and the application method, network topology structures of different users can be accurately identified, the working difficulty and intensity of manual inspection are greatly reduced, and cross-network, cross-organization and cross-region business scene grid-connected operation is realized.

Description

Technical Field

[0001] The present invention relates to the field of financial robot networking structure and application technology, and in particular to a cross-network and cross-regional financial robot networking structure and application method. Background Art

[0002] In recent years, with the rapid development of artificial intelligence technology, more and more corporate groups have begun to introduce financial robots to assist personnel in processing automated business. However, due to the characteristics of corporate groups such as the Internet public network, group network, local area networks of various branches and subsidiaries, and the cross-regional dispersion of their organizational structures, when deploying financial robots, the existing technology and practices are to independently deploy them on a provincial company basis. The business scenarios executed by financial robots are closed and run based on the local area network of the deployed provincial company. Not only is the group headquarters unable to monitor the operating status and distribution of the robots of its branches and subsidiaries, but the branches and subsidiaries are also unable to link the operation of business scenarios, which greatly affects the advancement of the overall financial robot intelligence level of the corporate group.

[0003] like Figure 1 As shown in the figure, the financial robot is independently deployed in provincial companies. The main reason is that the intranet of the group company involves multiple environments, such as the group's general network, independent LANs of branches and subsidiaries, and the Internet public network. When making specific deployments, the financial robot is determined according to the form of its server deployment. For the decentralized server deployment mode, the financial robot is located in each regional network, which results in the financial robot users in the group network and the decentralized deployment networks being unable to access each other. In particular, for special scenarios such as intelligent order review, which require the use of external network OCR parsing services, when the financial robot server is deployed with the console backend, its intelligent order review, scenario database agent and other microservices need to use the internal and external network data penetration service to access the network gate, which has an impact, and overall restricts the overall financial intelligence construction of the group.

[0004] The invention application with application number 202211484986.5 discloses a financial robot financial management system. In this application, the purpose of the financial robot operation platform is to build a set of "human-machine collaborative" intelligent financial work models with sustainable growth capabilities, and introduce digital employees into the financial business department of the enterprise. Improve the overall fund control capabilities, reduce the risks of financial management, and promote the steady development of the enterprise. However, its system also has the following problems: the financial robots of branches and subsidiaries cannot be automatically adapted, which is not conducive to the grid-connected operation of business scenarios across networks, organizations, and regions. Summary of the invention

[0005] In response to the above-mentioned problems, the purpose of the present invention is to provide a cross-network and cross-regional financial robot networking structure and application method, quickly identify the network topology of different users, automatically adapt financial robots to branches and subsidiaries, and realize the networked operation of business scenarios across networks, organizations and regions.

[0006] The embodiment of the present invention provides a cross-network and cross-regional financial robot networking structure and application method.

[0007] Aspect 1: A cross-network and cross-regional financial robot networking structure, including:

[0008] The network center module is used to adapt to the network topology of different customers and achieve network intercommunication between the server and robot sides of the financial robot;

[0009] The data center module is used to manage robot-side actuators and scenario script package software, store task execution retention data, and encrypt task data;

[0010] The dispatch center module formulates multi-task collaboration strategies, intelligently allocates robot terminals based on customer tasks, and handles branch tasks independently according to the collaboration strategies during the task flow process.

[0011] Furthermore, the network types in the networking center module include group network, branch and subsidiary network, external Internet and isolation gateway; the financial robot includes a server side and a robot side, the server side is centrally deployed in the group network, and the server side is deployed with a console, order review and scenario script database microservices; the robot side is deployed in a branch and subsidiary network or a group network, and the robot side is deployed with an actuator.

[0012] Furthermore, the robot-side actuator software package is based on Python language, developed and constructed using the pyside (QT) framework, and automatically updated and iterated;

[0013] The scenario script package is developed and constructed based on Python language using Selenium, OCR, and OpenCV frameworks, automatically updated and iterated, and sent to the local robot end through the console.

[0014] Furthermore, the data center module is used to store task execution retention data, including:

[0015] Task creation information based on task running type, corresponding scenario script package, user-specified parameters and uploaded resource files;

[0016] Real-time status information during task execution based on task execution progress, task execution process prompts and task execution logs;

[0017] The result file after the operation is completed for users to download;

[0018] Data generated during multi-task collaboration.

[0019] Furthermore, the data center module encrypts the task data, including:

[0020] The network transmission data between the console and the robot is encrypted by the AES algorithm, and the sensitive configuration information is encrypted by the RSA algorithm.

[0021] A second aspect: an application method based on the networking structure of the first aspect, comprising the steps of:

[0022] S1. The financial robot server and the robot are interconnected through the network. The customer selects the task instruction in the server console, and the robot polls the console interface to obtain the task instruction.

[0023] S2. According to the task instruction, the robot-side executor loads the scenario script package, executes the task, and selects a multi-task collaboration strategy according to the task template, triggers multi-task collaboration, and forms a task chain;

[0024] S3. After multi-task collaboration is completed, the console interface is called to return the result data.

[0025] Furthermore, the task chain in S2 is a task chain of customer-oriented tasks composed of a device code on the robot side and a task tag marked on the robot side, and a robot side matrix is ​​formed based on the task chain.

[0026] Furthermore, when the network between the server and the robot in S1 is interconnected, a robot-side instruction mechanism is established, including:

[0027] The robot actively initiates polling of the server console interface, batch queries the command request queue, obtains commands from the request queue, calls the task template according to the command requirements, and performs subsequent multi-task collaboration.

[0028] Furthermore, the network between the server-side console and the robot-side in S1 is interconnected, and authentication is performed when data is interacted, including:

[0029] The robot obtains the authorization token, calls the JReap organization authority service interface, uses the authorization token, and the console uses the JReap single sign-on authentication mechanism to determine the authorization token. Only after the authentication is passed can the business be carried out normally.

[0030] Furthermore, the formulation of the multi-task collaboration strategy in S2 includes:

[0031] Before the task runs, configure multiple downstream collaboration strategies for the task template;

[0032] When the task is running, the scenario script selects the downstream collaboration strategy based on the running situation.

[0033] A third aspect: An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method provided in the second aspect when executing the program.

[0034] A fourth aspect: A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the second aspect.

[0035] Beneficial effects of the present invention:

[0036] 1. The networking structure and application method of the present invention can quickly and automatically detect the network environment of all robot terminals of different business entities within the group, accurately identify the network topology of different users, and greatly reduce the difficulty and intensity of manual inspection.

[0037] 2. The networking structure and application method of the present invention can define quick mapping relationships based on the URLs and API interfaces of the business system in different networks for the robot side independently deployed by branches and subsidiaries, and automatically adapt the robot side when the business system is adjusted.

[0038] 3. The networking structure and application method of the present invention can automatically network and integrate financial robot environments in different network environments without modifying the existing network architecture, thereby realizing cross-network, cross-organizational and cross-regional business scenario parallel operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A schematic diagram of the deployment structure of the existing financial robot;

[0040] Figure 2 This is a schematic diagram of the network type structure of the networking center of the present invention;

[0041] Figure 3 A schematic diagram of the application method of the networking structure of the present invention;

[0042] Figure 4 This is a schematic diagram of the robot side page structure of the present invention;

[0043] Figure 5 This is a schematic diagram of the multi-task collaboration configuration of the console page of the present invention;

[0044] Figure 6 This is a schematic diagram of multi-task collaborative task messages on the console page of the present invention;

[0045] Figure 7 It is a schematic structural diagram of the electronic device of the present invention. DETAILED DESCRIPTION

[0046] The embodiments of the present invention are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar symbols throughout represent the same or similar elements or elements with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0047] Currently, when deploying financial robots, they are mostly deployed independently in branches and subsidiaries. The business scenarios executed by financial robots are operated in a closed manner based on the local area network of the deployed branches and subsidiaries. Not only is the group headquarters unable to monitor the operating status and distribution of the robots in its branches and subsidiaries, but the branches and subsidiaries are also unable to link the business scenario operations, which greatly affects the advancement of the overall financial robot intelligence level of the enterprise group.

[0048] In view of the above problems, the present invention provides a cross-network and cross-regional financial robot networking structure, which includes a networking center module, a data center module, a scheduling center module, etc.

[0049] Among them, the networking center module is used to manage the regional network, adapt to the network topology of different customers, and maintain its configuration in the system; activate and deploy the robot side of the assigned customer; establish a financial robot instruction mechanism based on the HTTP protocol, and establish short or long connections in a targeted manner to achieve network interoperability between the console and the robot side; access the single sign-on authorization solution of the self-developed framework JReap to complete the authentication between the robot side and the server side.

[0050] The data center module is used to manage robot-side actuators and client software developed and built based on the Python language using the pyside (QT) framework, and supports version iteration; it also manages scene script packages developed and built based on the Python language's built-in Selenium, OCR, OpenCV and other framework libraries, and supports version iteration; it is also used to store task data involving retained data during operation and result files for users to download; it is also used for encrypted data storage and sensitive information configuration.

[0051] The dispatch center module is used to formulate multi-task collaboration strategies, including robot-side matrix networking rules, task operation mode, and task flow branch control logic. It is also used to intelligently allocate robot sides based on the network environment, customer hardware resources, and task operation status, and automatically prioritize idle robot sides. It also supports the creation and issuance of tasks in parallel and serial modes. During the task flow process, it handles branches independently according to the collaboration strategy and the data packets transmitted during operation.

[0052] The networking center divides the network types into group network, branch and subsidiary network, external Internet and isolation network gateway. The server side of the financial robot is centrally deployed in the group network. Microservices such as console, order review and scenario script database are deployed in the server side. The server accepts customer task instructions based on the web page and feedbacks the task results through the web page; the robot side is deployed in the branch and subsidiary network or the group network, and the robot side is deployed with an actuator.

[0053] Based on the above cross-network and cross-regional financial robot networking structure, such as Figure 3 As shown, the present invention also discloses an application method of a cross-network and cross-regional financial robot networking structure, comprising the steps of:

[0054] S1. The financial robot server and the robot are interconnected through the network. The customer selects the task instruction in the server console, and the robot polls the console interface to obtain the task instruction.

[0055] S2. According to the task instruction, the robot-side executor loads the scenario script package, executes the task, and selects a multi-task collaboration strategy according to the task template, triggers multi-task collaboration, and forms a task chain;

[0056] S3. After multi-task collaboration is completed, the console interface is called to return the result data.

[0057] Specifically, Figure 2 As shown, the networking center divides network types into group network, branch and subsidiary network, external Internet and isolation network gateway.

[0058] The group network belongs to the group level. Some branches and subsidiaries do not have their own branch and subsidiary networks. They share the group network's human resources, finance, production and other office networks with the group to access some of the group's commonly used system applications.

[0059] Branch and subsidiary network means that some branches and subsidiaries have their own office networks, including their own human resources, finance, production and other office networks. Some commonly used system applications are located in the branch and subsidiary networks and can access the group network at the same time, but not vice versa.

[0060] External Internet refers to the commonly used public network, also known as the extranet; the group network and branch and subsidiary networks are also known as the intranet (built through a dedicated network line); the extranet and the intranet are relatively isolated and separated by an isolation firewall.

[0061] The isolation network gate is mainly the DMZ area. According to the location of the subsidiary and the network structure of different branches, the isolation network gate is in the intranet and the extranet. The DMZ area may deploy corresponding intranet and extranet data penetration services. For example: the financial machine server deploys multiple microservices such as the console, order review, and scenario database agent. Among them, the order review needs to call the extranet OCR parsing service, so the isolation network gate will be used to provide intranet and extranet data penetration services.

[0062] Taking subsidiaries as units, different subsidiaries may be located in different branch networks or group networks; for example, a subsidiary of Guangxi Branch is located in the Guangxi Branch network, while a subsidiary of Sichuan Branch is located in the Sichuan Branch network; but there are exceptions, for example, a subsidiary of Guangxi Branch is directly located in the group network.

[0063] Different network structures have different accessible business systems. Therefore, according to the requirements of the automation scenarios, financial robots may be deployed in the above-mentioned various network structures. However, as customers' demand for automation scenarios increases, some complex cross-network scenarios have emerged. The intranet involves multiple environments and also includes the office intranets of various branches.

[0064] The financial robot server is deployed in a centralized deployment mode in the group network to ensure that users and robot terminals of all branches and subsidiaries can access it.

[0065] The networking center also manages the financial robots deployed in the network, specifically:

[0066] In the process of financial robots executing business scenarios, the robot side not only completes tasks as an independent individual, but also needs to participate as an independent individual in a group for intelligent allocation for certain special business scenarios, forming a robot side matrix oriented to the task chain.

[0067] In order to realize a robot-side matrix oriented to the task chain, minimize human involvement in decision-making, and realize intelligent scheduling of the robot side, it is necessary to mark the robot side with enough task tags. At the same time, the system generates a unique device code for each robot side, which is stored locally on the robot side and in the database as a unique credential.

[0068] The process of labeling the robot end is completed during the activation and deployment stage of the robot end. When the robot end is activated, the database will bind the robot end to a department of the customer (subsidiary) based on the label and identification code. The network status of the branch and subsidiary where this department is located can be obtained from the associated regional network configuration. Based on the hierarchical organizational structure in the database, the robot end can be divided into robot end groups for different customers, and further applied to cross-branch and subsidiary business alliances.

[0069] Establish the robot-side command mechanism based on the networking center, specifically:

[0070] Based on the development cost of the financial robot and the stability of the customer's network, short or long connections are selected to achieve remote network interaction between the server-side console and the robot side, and a set of instruction mechanisms are designed to agree on the data interaction format between the console and the robot side.

[0071] To realize network data interaction between the console and the financial robot, in the C / S network architecture, only the console can provide external network interface monitoring services, while the robot cannot. The ordinary console cannot actively send messages to the robot. The group's network security system stipulates that only the designated server console has the authority after approval. If the business requires it, the robot has already established a connection with the console first, and only the robot can initiate the connection.

[0072] For the group network, due to the use of dedicated lines, the intranet bandwidth resources put into operation are very limited. The transmission efficiency across network segments and network environments cannot reach the level of some CDN acceleration on the public network, which is an important aspect of the data transmission solution. As a plug-in tool software, the robot side cannot force the network environment for task operation to be very perfect. Only by taking appropriate design and optimization measures to maximize robustness and ensure that the automation scenario can work effectively under various conditions, robustness is required.

[0073] Taking short connection as an example (for long connection, please refer to the data interaction format), establish the robot-side command mechanism, including:

[0074] The robot polls to obtain pending instructions, requests the console interface every 1 second, batch queries the instruction request queue, takes out task instructions one by one from the request queue, completes simple and fast verification or behavior, and returns data to the console interface to avoid the console judging that the instruction sending timeout; according to the requirements of the instruction queue, perform subsequent time-consuming operations, and call the console interface after completion to return the result data.

[0075] The network transmission robot and the server are authenticated according to the network center. Specifically:

[0076] From the perspective of network transmission security, data interaction between the server and the robot requires authentication. The single sign-on authorization solution of the self-developed framework JReap can be used, including:

[0077] The robot side obtains the authorization token, calls the JReap organization authority service interface / jreap / authorizeApp.form, and caches it locally; when the robot side calls the console interface, it is required to carry the authorization token and use the authorization token. If the authorization token is judged to be expired, it will be automatically re-obtained; the console interface authenticates the authorization token through the JReap single sign-on authentication mechanism, and only those who pass the authentication can conduct business normally.

[0078] The data center is used to manage software packages such as robot-side actuators. Software packages such as robot-side actuators are based on Python language and developed and built using the pyside (QT) framework, supporting version iteration. In the console backend web management interface, the system administrator uploads the updated version of the robot-side actuator software package.

[0079] When the robot obtains the task instruction request queue, the console will transmit the latest version information to it. When the robot obtains the updated version, it will automatically download the latest version of the software package during the task idle phase to complete the self-upgrade. The local running program of the robot executor uses an encrypted exe file or pyd file.

[0080] Through the upgrade and maintenance mechanism, the robot-side actuator version is consistent with the console version, which can better complete the tasks assigned to the financial robot.

[0081] The data center is also used to manage scenario script packages.

[0082] The scene script package is based on Python language and is built with framework libraries such as Selenium, OCR, OpenCV, etc. It supports version iteration. Each scene script package is sent to the robot locally through the console in a plug-in manner. When the task is sent later, the robot will call the scene script package to execute the task.

[0083] The third-party libraries (Selenium, OCR, OpenCV, etc.) that the scene script package depends on will be pre-installed in the executor installation package in advance, which can greatly reduce the size of the scene script package.

[0084] When multi-task collaboration generates new requirements and requires changes to the scenario script package (or bug fixes), the console can also automatically issue the latest version based on the version changes of the scenario script package and deploy it in batches to the client robot with the corresponding task tag through the command mechanism. It supports automatically triggering the re-issuance upgrade operation when the robot is restarted or goes from offline to online, is compatible with common abnormal situations, and avoids the high cost and low efficiency of manual completion of related operations by operation and maintenance personnel. Figure 4 As shown, you can query the robot end operation and obtain relevant information.

[0085] The data center is also used to store business scenario task execution data, mainly involving valuable data generated during the execution of business scenario tasks, including retained data during task operation and result files for users to download. The data is stored in the corresponding table of the database, and the dynamic data structure is stored in Json format. Specifically, it includes:

[0086] Task creation information such as task running type, corresponding scenario script package, user-specified parameters and uploaded resource files; real-time status information during task running, such as task running progress, task running process prompts and task running logs; ZIP format compressed packages for users to download after the financial robot business scenario is executed, and other result files after the operation is completed; reservation data transmitted by upstream and downstream tasks, data shared by the task chain, and other data generated in the multi-task collaboration chain.

[0087] The data center is also used to encrypt business scenario task data, including:

[0088] The network transmission between the console and the robot is binary stream based on HTTP protocol, but there are only two forms at both ends of the transport layer: file and text. For files, whether it is the console or the robot, the program will encrypt them before transmission, using the AES symmetric encryption algorithm and a 128-bit key length (RSA encryption will also be performed on the key). For texts involving sensitive configuration information (such as account passwords), they will also be encrypted before transmission, using the RSA asymmetric encryption algorithm.

[0089] The dispatch center is used to formulate multi-task collaboration strategies: Multi-task collaboration strategies include robot-side matrix networking rules, task operation mode, task flow branch control logic multi-task collaboration, etc., which can be divided into two stages: preparation and operation:

[0090] like Figure 5 As shown in the figure, before the task starts, the system administrator presets some indicator parameters in the console, and together with the scenario script, determines: which tasks, when and in what mode the tasks are added to the collaboration chain; the optional range of the robot side when the task starts running; during and after the task, which scenario users can view the process and details in the console; the collaboration strategy serves the business objectives of some scenarios, and configures multiple downstream collaboration strategies for the task template; when the task is running, the robot side can select the collaboration strategy by loading the scenario script to trigger the task collaboration.

[0091] The following examples illustrate different scenarios of multi-task collaboration strategy configuration:

[0092] For example, the scenario is task A1 [Bank Reconciliation]. After completing the task [Bank Reconciliation], the scenario task B1 [Tax Declaration] is triggered. After completing the task [Tax Declaration], the task ends. At this time, task A1 [Bank Reconciliation] and task B1 [Tax Declaration] form a multi-task collaboration. Figure 6 As shown, you can view the task status.

[0093] For example, the scenario is task A1 [Bank Reconciliation]. After completing the task [Bank Reconciliation], scenario task B1 [Tax Declaration] is triggered, and scenario task B2 [Tax Declaration] is also triggered, forming a single scenario triggering multiple tasks collaboration.

[0094] Another example: multiple tasks are executed continuously, the scenario is task A1 [Bank Reconciliation]. After A1 [Bank Reconciliation] is completed, the scenario task B1 [Tax Return] is triggered. After B1 [Tax Return] is completed, the scenario task A2 [Bank Reconciliation] is triggered. After A2 [Bank Reconciliation] is completed, the scenario task A10 [Bank Reconciliation] is triggered, etc., until all task collaborations are completed according to the task template. During use, the number of tasks can be controlled by the maximum number threshold, for example: no more than 20 tasks.

[0095] The multi-task collaboration strategy also supports logical control for task triggering, and supports logical control and different branches. After a task is completed, should another task be triggered? And which scene's task should be triggered? It is determined by the scene script, and parameters can be specified, for example:

[0096] After completing scenario task A1 [Bank reconciliation], determine whether the "reconciliation results" are normal. If normal, trigger scenario task B1 [Tax declaration]; if abnormal, no other tasks will be triggered.

[0097] The above tasks are immediate tasks, and you can also specify scheduled tasks, which are downstream tasks triggered according to time intervals. For example, after the completion of scenario task A1 [Bank reconciliation], the system sets the scenario task B1 [Tax declaration] to be triggered 1 hour later.

[0098] Downstream tasks support specifying task parameters and resource files. The task templates corresponding to upstream and downstream tasks may be the same or different. Regardless of whether the task templates are the same, the task parameters and resource files of the downstream tasks need to be provided, and support flexible provision of scenario scripts. The task parameters of downstream tasks also support the password reuse function, and support password reuse for personal accounts and public accounts.

[0099] For example: After the completion of scenario task A1 [Bank reconciliation], scenario task B1 [Bank receipt re-scanning] is triggered and the task is completed. The task parameter "Company Name" of task B1 is specified by A1, and the resource file "Bank receipt" of task B1 is uploaded and provided by A1, which continues to trigger scenario task B2 [Bank reconciliation]. The task parameter "Comprehensive Query System User Name" of task B2 is specified by task B1 during operation. Its password is extracted with the help of the password reuse function for downstream tasks. It can be used in subsequent scenario tasks through the console drop-down options and password reuse related parameters.

[0100] For example, scenario task A1 [Bank Reconciliation] is completed, and the "scenario user" of task A1 is "Zhang San" of the "Inner Mongolia" branch, who assigned the task in the position of "Inner Mongolia - Financial Management Department";

[0101] Trigger scenario task A2 [Bank Reconciliation]. The "scenario user" of task A2 is "Li Si" of the "Guangdong" branch, who is assigned the corresponding position of "Guangdong-Financial Management Department".

[0102] The publisher of the "scenario user" of Task A2, "Li Si", and the corresponding position when it was issued, "Guangdong-Financial Management Department", are obtained by the task parameter "Comprehensive Query System User Name" of Task A2 specified by Task A1. The password reuse configuration is based on the "personal account" and its password is extracted with the help of the "personal account" in the password reuse function. The "personal account" of the "scenario user" of Task A2 is extracted in combination with the console account of the "scene user" of Task A2. The reused password is one of the "personal accounts" of A2 specified by Task A1.

[0103] Trigger scenario task B1 [Master Data Maintenance]. The "scenario user" of task B1 is "Wang Wu" of the "Jiangxi" branch, who issues the task in the corresponding position of "Jiangxi-Financial Management Department". The "scenario user" of task B1, "Wang Wu", and the corresponding position "Jiangxi-Financial Management Department" when it was issued are both specified by A2. The task parameter of task A2, "Comprehensive Query System User Name", is configured for password reuse based on the "shared account", and its password is extracted with the help of the "shared account" in the password reuse function.

[0104] The dispatch center is also used to automatically prioritize idle robot terminals based on the network environment, customer hardware resources, and task operation status, and to intelligently allocate robot terminals. Specifically:

[0105] According to the department where the scene user is located, the department bound to the robot end when it is activated, and the hierarchical relationship of the organization, the scope of the list of robot ends used by the scene user is analyzed. For specific tasks, it exists in some specific network environments, and only specific robot ends can support operation. In this case, the console will intervene in the robot end range through some configuration parameters to prevent the robot end from being allocated incorrectly.

[0106] Intelligent allocation of robot ends reduces the probability of task accumulation on a certain robot end and can improve the utilization rate of idle robot ends.

[0107] The busy / idle judgment rules for intelligent allocation of robot terminals include: filtering out "idle robot terminals" that are not currently executing tasks based on task requirements; if there are "idle robot terminals", use them; if there are no "idle robot terminals", use the robot terminal with the least number of tasks in the queue.

[0108] The dispatch center is also used to control the issuance of business scenario tasks, and supports the creation and issuance of tasks in parallel and serial modes. A robot can only perform one task at a time, and the parallel and serial execution of tasks is equivalent to the parallel and serial execution of the robot. During the task flow process, it handles branches independently according to the collaboration strategy and the data packets transmitted during operation.

[0109] The parallel dispatch of tasks includes: in the same task collaboration chain, multiple tasks start at the same time, or one task has not yet ended while other tasks have already started running.

[0110] The serialization of task dispatching includes: in the same task collaboration chain, multiple tasks are queued and run in order, and the downstream task is not allowed to start when the upstream task has not been completed.

[0111] With the help of multi-task collaboration strategy, combined with branch selection during scenario operation, downstream task allocation robot side is determined in two stages:

[0112] During the running of the upstream task, when the robot-side executor executes the scenario script package, based on the results of the running process, it has determined whether it is necessary to trigger which downstream task to run after the task is finished. At this time, the console "Booking Collaboration Task" interface can be called to notify the next task which collaboration strategy is used, forming a parallel running mode.

[0113] After the upstream task is finished, the console knows that the upstream task has been completed, and also knows which collaboration strategy is used by the scenario script "Booked Collaboration Task" of the upstream task, and then obtains the specified task based on the parameter configuration of the corresponding collaboration strategy. At the same time, based on the strategy, the robot end is intelligently allocated to form a serial operation mode.

[0114] The present invention also provides an electronic device, Figure 7 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, such as Figure 7 As shown, the electronic device may include: a processor, a communications interface, a memory, and a communications bus, wherein the processor, the communications interface, and the memory communicate with each other via the communications bus. The processor may call the logic instructions in the memory, for example, to execute the following method:

[0115] S1. The financial robot server and the robot are interconnected through the network. The customer selects the task instruction in the server console, and the robot polls the console interface to obtain the task instruction.

[0116] S2. According to the task instruction, the robot-side executor loads the scenario script package, executes the task, and selects a multi-task collaboration strategy according to the task template, triggers multi-task collaboration, and forms a task chain;

[0117] S3. After multi-task collaboration is completed, the console interface is called to return the result data.

[0118] In addition, the logic instructions in the above-mentioned memory can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0119] An embodiment of the present invention further provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the method provided in each of the above embodiments is implemented, for example, including:

[0120] S1. The financial robot server and the robot are interconnected through the network. The customer selects the task instruction in the server console, and the robot polls the console interface to obtain the task instruction.

[0121] S2. According to the task instruction, the robot-side executor loads the scenario script package, executes the task, and selects a multi-task collaboration strategy according to the task template, triggers multi-task collaboration, and forms a task chain;

[0122] S3. After multi-task collaboration is completed, the console interface is called to return the result data.

[0123] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0124] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-network and cross-regional financial robot networking structure, characterized in that: include: The network center module is used to adapt to the network topology of different customers and achieve network intercommunication between the server and robot sides of the financial robot; The data center module is used to manage robot-side actuators and scenario script package software, store task execution retention data, and encrypt task data; The dispatch center module formulates multi-task collaboration strategies, intelligently allocates robot terminals based on customer tasks, and handles branch tasks independently according to the collaboration strategies during the task flow process.

2. The networking structure according to claim 1, characterized in that: The network types in the networking center module include group network, branch and subsidiary network, external Internet and isolation gateway; the financial robot includes a server side and a robot side, the server side is centrally deployed in the group network, and the server side is deployed with a console, order review and scenario script database microservices; the robot side is deployed in a branch and subsidiary network or a group network, and the robot side is deployed with an actuator.

3. The networking structure according to claim 2, characterized in that: The robot-side actuator software package is based on Python language, developed and built using the pyside (QT) framework, and automatically updated and iterated; The scenario script package is developed and constructed based on Python language using Selenium, OCR, and OpenCV frameworks, automatically updated and iterated, and sent to the local robot end through the console.

4. The networking structure according to claim 1, characterized in that: The data center module is used to store task execution retention data, including: Task creation information based on task running type, corresponding scenario script package, user-specified parameters and uploaded resource files; Real-time status information during task execution based on task execution progress, task execution process prompts and task execution logs; The result file after the operation is completed for users to download; Data generated during multi-task collaboration.

5. The networking structure according to claim 1, characterized in that: The data center module encrypts the task data, including: The network transmission data between the console and the robot is encrypted by the AES algorithm, and the sensitive configuration information is encrypted by the RSA algorithm.

6. An application method based on the networking structure according to any one of claims 1 to 5, characterized in that: Includes steps: S1. The financial robot server and the robot are interconnected through the network. The customer selects the task instruction in the server console, and the robot polls the console interface to obtain the task instruction. S2. According to the task instruction, the robot-side executor loads the scenario script package, executes the task, and selects a multi-task collaboration strategy according to the task template, triggers multi-task collaboration, and forms a task chain; S3. After multi-task collaboration is completed, the console interface is called to return the result data.

7. The application method according to claim 6, characterized in that: The task chain in S2 is a task chain for customer-oriented tasks composed of the device code of the robot side and the task tag marked on the robot side, and a robot side matrix is ​​formed according to the task chain.

8. The application method according to claim 6, characterized in that: When the network between the server and the robot in S1 is interconnected, a robot-side instruction mechanism is established, including: The robot actively initiates polling of the server console interface, batch queries the command request queue, obtains commands from the request queue, calls the task template according to the command requirements, and performs subsequent multi-task collaboration.

9. The application method according to claim 6, characterized in that: In S1, the server-side console and the robot-side are interconnected over the network, and authentication is performed during data interaction, including: The robot obtains the authorization token, calls the JReap organization authority service interface, uses the authorization token, and the console uses the JReap single sign-on authentication mechanism to determine the authorization token. Only after the authentication is passed can the business be carried out normally.

10. The application method according to claim 6, characterized in that: The multi-task cooperation strategy formulated in S2 includes: Before the task runs, configure multiple downstream collaboration strategies for the task template; When the task is running, the scenario script selects the downstream collaboration strategy based on the running situation.

Images