Task processing method based on R Shiny application, Shiny server for processing task and client

Abstract

The embodiment of the invention generally relates to the technical field of data analysis, in particular to a task processing method based on an R Shiny application, a Shiny server and a client for processing tasks, a computer program and electronic equipment. The method of the server comprises the following steps: in response to a received to-be-processed task submitted by a Shiny client, creating a task entry corresponding to the to-be-processed task in a task database, and configuring a task state of the created task entry as a first state; the method further comprises the steps of polling the task database to start one or more tasks corresponding to one or more task entries with the task state as the first state in the task database, and configuring the task state of the task entry corresponding to the started task as the second state. And in response to completion of the task, configuring the task state of the task entry corresponding to the completed task in the task database as a third state. The method and the device can avoid loss of calculation results when the current browser page is closed or the webpage is refreshed.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the technical field of data analysis, and in particular, to a task processing method based on R Shiny application, a Shiny client and server for processing tasks, a computer program and an electronic device. BACKGROUND

[0002] As an Internet application development framework under R language environment, R Shiny is being applied to all aspects of bioinformatics industry, from creating interactive data analysis tools to creating systematic data analysis cloud platforms, and has wide applications at home and abroad. A series of products will involve high-intensity task computing, which needs to be calculated for a long time by the server. During this period, the user may also want to do something else on these applications without waiting for a long time in the task submission interface.

[0003] However, the traditional Shiny application needs to rely on good network connection to fix the current conversation window in the scenario of needing to call time-consuming computing resources in the background. The current browser page is closed or the webpage is refreshed, which will cause the loss of the calculation result. SUMMARY

[0004] Embodiments of the present disclosure provide a task processing method based on R Shiny application, a Shiny client and server for processing tasks, a computer program and an electronic device, which are intended to solve one or more of the above problems and other potential problems.

[0005] According to a first aspect of the present disclosure, a task processing method based on R Shiny application is provided, applied to a Shiny server, the Shiny server being configured with a task database for recording task entries, the task entries including information paths, task types, tool information and task states of corresponding tasks. The method comprises, in response to receiving a submitted to-be-processed task of a Shiny client, creating a task entry corresponding to the to-be-processed task in the task database, and configuring the task state of the created task entry as a first state. The method further comprises polling the task database to start one or more tasks corresponding to one or more task entries with the task state being the first state in the task database, and configuring the task state of the task entry corresponding to the started task as a second state. In addition, the method further comprises, in response to the completion of the task, configuring the task state of the task entry corresponding to the completed task in the task database as a third state.

[0006] According to a second aspect of the present disclosure, there is provided a method for processing tasks based on R Shiny application, applied to a Shiny client. The method comprises, in response to a submission of a to-be-processed task in a user interactive webpage, creating a task entry corresponding to the to-be-processed task in a task database of a Shiny server, wherein the task entry comprises an information path, a task type, tool information and a task state of the corresponding task. The method further comprises, in response to a refresh of the user interactive webpage, updating task related information of a task in the user interactive webpage by querying the task entry corresponding to the task in the task database of the Shiny server.

[0007] According to a third aspect of the present disclosure, there is provided a Shiny server for processing tasks, configured with a task database for recording task entries, wherein the task entries comprise an information path, a task type, tool information and a task state of the corresponding task. The server comprises a task entry creation module configured to, in response to receiving a submitted to-be-processed task file from a Shiny client, create one or more task entries corresponding to the to-be-processed task file in the task database, and configure the task state of the created task entries as a first state. The server further comprises a task polling module configured to poll the task database to start one or more tasks corresponding to one or more task entries in the task database whose task state is the first state, and configure the task state of the task entry corresponding to the started task as a second state. In addition, the server further comprises a task monitoring module configured to, in response to a completion of a task, configure the task state of the task entry corresponding to the completed task in the task database as a third state.

[0008] According to a fourth aspect of the present disclosure, there is provided a Shiny client for processing tasks. The client comprises a task submission module configured to, in response to a submission of a to-be-processed task in a user interactive webpage, create a task entry corresponding to the to-be-processed task in a task database of a Shiny server, wherein the task entry comprises an information path, a task type, tool information and a task state of the corresponding task. In addition, the client further comprises a task query module configured to, in response to a refresh of the user interactive webpage, update task related information of a task in the user interactive webpage by querying the task entry corresponding to the task in the task database of the Shiny server.

[0009] According to a fifth aspect of the present disclosure, there is provided a computer program product comprising a computer program. The computer program, when executed by a processor, implements the method of the first aspect or the second aspect.

[0010] According to a sixth aspect of the present disclosure, there is provided an electronic device comprising one or more processors, and a memory associated with the one or more processors. The memory is configured to store program instructions that, when read and executed by the one or more processors, perform the steps of the method of the first aspect described above. BRIEF DESCRIPTION OF DRAWINGS

[0011] The above and other objects, features and advantages of embodiments of the present disclosure will be more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which a number of embodiments of the present disclosure are shown by way of example, and in which, like reference numerals refer to like elements, and in which:

[0012] Figure 1 A flowchart of a R Shiny application-based task processing method according to an embodiment of the present disclosure is shown.

[0013] Figure 2 A flowchart of another R Shiny application-based task processing method according to an embodiment of the present disclosure is shown.

[0014] Figure 3 A composition diagram of a R Shiny application-based task processing system according to embodiments of the present disclosure is shown.

[0015] Figure 4 A block diagram of a Shiny server for processing tasks according to an embodiment of the present disclosure is shown.

[0016] Figure 5 A block diagram of a Shiny client for processing tasks according to an embodiment of the present disclosure is shown.

[0017] Figure 6 A flowchart of a task processing between a Shiny server and a Shiny client according to an embodiment of the present disclosure is shown.

[0018] Figure 7 A block diagram of an electronic device according to embodiments of the present disclosure is shown.

[0019] In the various drawings, identical or corresponding reference numerals show identical or corresponding parts. DETAILED DESCRIPTION

[0020] Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which some embodiments of the present disclosure are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and fully convey the scope of the disclosure to those skilled in the art.

[0021] In the description of embodiments of the disclosure, the term "comprising" and its similar words are understood to encompass open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", and the like can refer to different or the same objects. The following can also include other explicit and implicit definitions.

[0022] As mentioned before, the process of R Shiny application transferring computing tasks and results between user side (browser) and server mainly relies on WebSocket protocol and two-way real-time communication mechanism. This mechanism requires the WebSocket connection to keep open, so that the Shiny application can achieve real "real-time interaction". Therefore, in the scenario where the traditional Shiny application needs to call time-consuming computing resources in the background, it needs to rely on good network connection to fix the current conversation window. The current browser page is closed or the webpage is refreshed, which will cause the loss of the calculation result. Even in the related prior art, the toolkits such as promises, callr, coro, mirai, crew in R Shiny application can perform asynchronous task scheduling, they can only perform asynchronous task scheduling based on the same browser conversation environment (i.e., in a single-page application), so they become pseudo-asynchronous scheduling tools, which cannot meet the demand of efficient interaction and full use of computing resources.

[0023] The following will be described in conjunction with Figure 1 A flowchart of a task processing method 100 based on R Shiny application according to an embodiment of the disclosure is described. It should be understood that the numbering in the flowchart of the method 100 does not represent the order of execution of these steps, some or all of these steps can be executed in parallel, or the order of execution can be interchanged, and the disclosure does not limit this. In addition, Figure 1 The method in the above

[0024] As mentioned before, the process of R Shiny application transferring computing tasks and results between user side (browser) and server mainly relies on WebSocket protocol and two-way real-time communication mechanism. This mechanism requires the WebSocket connection to keep open, so that the Shiny application can achieve real "real-time interaction". Therefore, in the scenario where the traditional Shiny application needs to call time-consuming computing resources in the background, it needs to rely on good network connection to fix the current conversation window. The current browser page is closed or the webpage is refreshed, which will cause the loss of the calculation result. Even in the related prior art, the toolkits such as promises, callr, coro, mirai, crew in R Shiny application can perform asynchronous task scheduling, they can only perform asynchronous task scheduling based on the same browser conversation environment (i.e., in a single-page application), so they become pseudo-asynchronous scheduling tools, which cannot meet the demand of efficient interaction and full use of computing resources. Figure 1As shown, method 100 can be executed on the Shiny server of the R Shiny application. In one or more embodiments of this disclosure, the Shiny server can be a physical server, a virtual machine instance, or a cloud service instance (such as AWS EC2, Azure VM, Google Cloud Compute Engine), or a cluster of multiple servers. These devices can run a Linux operating system and install the R language environment and Shiny Server software to support the deployment, operation, and multi-user concurrent access requirements of the R Shiny application. The server has a stable Internet connection (wired or wireless). The Shiny application can be deployed on the Shiny server, and a persistent WebSocket connection can be established with the client through a session to achieve a bidirectional real-time communication mechanism. In one or more embodiments of this disclosure, the Shiny application can include a user interface (UI) portion, which defines interactive elements (such as sliders, buttons, drop-down menus, charts, and other visual components). In addition, the Shiny application also includes a server logic portion, which is used to receive client input events, execute R language computing tasks (including data processing, model calculation, and result generation), and provide feedback to the client. The client only needs a browser to access the Shiny application on the Shiny server and obtain the services provided by the Shiny application.

[0025] In one or more embodiments of this disclosure, the Shiny server is further configured with a task database for recording task entries. The task database can be any relational database in the prior art, and the data storage format in the task database can vary depending on the project, using different database software such as MySQL, SQLite, or PostgreSQL. Each task entry corresponds to a task, and the task entry can include task information, task type, tool information, and task status. In one or more embodiments of this disclosure, the task information can be a JSON-formatted information path, used to represent the API path or internal processing path in the Shiny application for processing the task; the task type can be a task category or type represented by a string; the tool information can be a string representing the tools, libraries, or dependencies required to execute the task; and the task status field is used to represent the processing status of the task. For example, a task entry corresponding to a data visualization task might have the following values: Task Information field value could be an API path ' / analysis / task / submit'; Task Type field value could be the string 'data_visualization' representing the data visualization task; and Task Tools field value could be the string 'R:ggplot2,dplyr; Python:pandas,scikit-learn', indicating that executing the task requires the ggplot2 and dplyr packages for R, and the pandas and scikit-learn libraries for Python. Based on this information, the Shiny server can find the correct processing function on the server, ensuring that the necessary tools for task execution are available, and tracking and managing task execution. The Task Status field value could include a first state indicating that the task has not yet been started (e.g., represented by the string 'Fresh'), a second state indicating that the task has been started and is being processed (e.g., represented by the string 'Busy'), and a third state indicating that the task has been completed (e.g., represented by the string 'Done'). In one or more embodiments of this disclosure, the task entry may also include fields such as task execution time and task resource consumption to record more task-related information.

[0026] like Figure 1As shown in block 102, method 100 can, in response to receiving a pending task submitted by the Shiny client, create a task entry corresponding to the pending task in the task database and configure the task status of the created task entry to a first state. In one or more embodiments of this disclosure, the pending task can be a data analysis task (such as data filtering, statistical calculation, and feature extraction), a model training and prediction task (such as adjusting machine learning parameters, performing model training, and generating prediction results), a visualization configuration and rendering task (such as selecting chart type, color scheme, or axis variables and updating the chart in real time), and a data export request submitted by the user through the Shiny client. In one or more embodiments of this disclosure, the pending task can be integrated by the Shiny client into a JSON-formatted pending task file for easy transmission to the Shiny server. The Shiny server can directly write the received pending task file to the disk; this process does not involve file storage and is very fast. In one or more embodiments of this disclosure, the Shiny server can also extract individual task information from the task files while storing them to disk. This information typically includes the task's JSON-formatted path, task type, and the runtime tool information required by the task (referred to as tool information). These are used as the values ​​for the task's path field, task type field, and tool information field, respectively, and written to the task database, thereby creating a task entry corresponding to that task in the task database. Subsequently, the task status field value of the created entry is set to the field value corresponding to the first status (e.g., 'Fresh') to indicate that this is a new task that has not yet been started.

[0027] In box 104, method 100 can poll the task database to start one or more tasks corresponding to one or more task entries in the task database whose task status is in the first state, and configure the task status of the task entries corresponding to the started tasks to the second state. In one or more embodiments of this disclosure, the Shiny server can periodically (e.g., at intervals of a few seconds) query the task database through the query interface to check whether there are task entries in the task database whose task status is in the first state. For example, the Shiny server can check whether the task status of each task entry in the task database is the first state 'Fresh'. Alternatively, the Shiny server can match all task entries in the task database whose task status is the first state 'Fresh'. For a task entry whose task status is in the first state, the Shiny server can extract one or more field values ​​of the task entry, such as one or more of the information path, task type, and tool information. In one or more embodiments of this disclosure, one or more of the information path, task type, and tool information of the task entry can be passed as script parameters to the BASH script to facilitate the automated startup of the corresponding task. After a task is started, the Shiny server can access the task database through the corresponding interface and modify the task status of the task entry to the second status (e.g., 'Busy') to indicate that the task is being processed but has not yet been completed.

[0028] In one or more embodiments of this disclosure, when it is determined that a task entry with a first state exists in the task database, the computing resources required for the task to be processed corresponding to the task entry can be calculated based on one or more of the information path, task type, and tool information of the task entry. For example, how many CPUs and how much memory are required. After (or before) determining the computing resources required for the task, the system will traverse all available computing nodes and match the current CPU, memory, GPU, and other resource usage of each node with the task requirements. Specifically, the system will filter out a set of computing nodes that can meet the minimum resource requirements of the task, and then select the node with the lowest resource utilization rate among these nodes as the task processing node. For example, if the task requires 2 CPU cores and 4GB of memory, the system will check the available resources of each computing node, exclude those nodes that cannot meet the requirements, and then select the node with the lowest current load among the remaining nodes (such as a node with 15% CPU utilization rather than a node with 70% CPU utilization), ensuring that the task allocation not only meets the resource requirements but also maximizes the utilization of server resources, avoids resource waste, and maintains overall system load balance. After determining the computing node with the lowest load, the Shiny server can designate this node as the node to process the corresponding task through its built-in task scheduling mechanism. In one or more embodiments of this disclosure, the Shiny server can encapsulate information such as the task path, task type, and tool information of the task entry corresponding to the task to be processed into a message, send it to the selected computing node through a preset communication interface, and then modify the task status of the task entry corresponding to the task to be processed to a second status.

[0029] In block 106, method 100 may, in response to task completion, configure the task status of the corresponding task entry in the task database to a third state (e.g., 'Done'). In one or more embodiments of this disclosure, for a completed task, the storage path of the task's calculation or processing result can be obtained by querying the information path field of the corresponding task entry, thereby obtaining the task's calculation or processing result.

[0030] This approach separates Shiny application task processing from the session, preventing the loss of computation results due to page refresh or closing. Furthermore, separating task processing from the session allows it to be separated from the corresponding R process of the Shiny application, avoiding blocking of R process tasks and optimizing resource allocation on the Shiny server.

[0031] In one or more embodiments of this disclosure, the Shiny server, upon receiving a task query request from a Shiny client, can also query one or more tasks specified in the task query request from the task database. For the task to be queried, the Shiny server can access the task database through its interface to obtain the task entry corresponding to the queried task. Then, based on the task entry corresponding to the queried task, it generates a feedback result for the task query request and sends it to the Shiny client to respond to the client's task query request. In one or more embodiments of this disclosure, the Shiny server first determines the task status based on the task status field of the task entry corresponding to the queried task. If the task status is in the first or second state, it indicates that the task has not yet been completed, and it is not necessary to obtain the task processing result; the task status is simply packaged in the feedback result of the task query request. If the task status is in the third state, it indicates that the task has been completed, and the storage path of the task processing result can be found through the information path field of the task entry. The task processing result is then obtained, packaged in the feedback result of the task query request, and sent to the Shiny client.

[0032] The following is combined with Figure 2 A flowchart is provided describing a task processing method 200 based on an R Shiny application according to an embodiment of this disclosure. It should be understood that the numbers in the flowchart of method 200 do not indicate the order in which these steps are executed; some or all of these steps may be executed in parallel, or their execution order may be interchanged, and this disclosure does not limit this. Furthermore, Figure 2 The methods described may also include additional steps not shown and / or the steps shown may be omitted, and the scope of this disclosure is not limited in this respect.

[0033] like Figure 2 As shown, method 200 can be executed on the Shiny client of the R Shiny application. In one or more embodiments of this disclosure, the client can be a conventional device capable of supporting web applications, such as a regular PC, laptop, tablet, or smartphone. The client has a stable internet connection (wired or wireless) and typically has a web browser installed, such as Chrome, Firefox, Safari, Edge, etc. The browser has a built-in JavaScript engine for displaying the UI of the Shiny application to interact with the user. This enables the Shiny application on the client to interact with the user (receiving user input and displaying output) through a web browser, communicate with the Shiny server via HTTP / HTTPS protocol, and access the R Shiny application deployed on the Shiny server.

[0034] like Figure 2As shown in box 202, method 200 can respond to the submission of a task to be processed in the user interaction webpage by creating a task entry corresponding to the task in the task database of the Shiny server. The task entry includes the information path, task type, tool information, and task status of the corresponding task. In one or more embodiments of this disclosure, the task to be processed can be a data analysis task (such as data filtering, statistical calculation, and feature extraction), a model training and prediction task (such as adjusting machine learning parameters, performing model training, and generating prediction results), a visualization configuration and rendering task (such as selecting chart type, color scheme, or axis variables and updating the chart in real time), and a data export request submitted by the user through the Shiny client. In one or more embodiments of this disclosure, the user interaction webpage can be the UI interface of the Shiny application. The user can access the UI interface of the Shiny application in the Shiny client browser and input tasks through the input bar on the user interaction webpage. In one or more embodiments of this disclosure, the input bar on the user interaction webpage can include one or a combination of several input methods such as character input, numeric input, and drop-down options. In one or more embodiments of this disclosure, the user interaction webpage is further configured with a control for user-triggered task submission. After completing the task input, the user can trigger the submission of the input task by operating (e.g., clicking, swiping, etc.) the task submission control.

[0035] In one or more embodiments of this disclosure, in response to the submission of tasks to be processed in a user interaction webpage, the client's browser can obtain the information path, task type, and tool information of each task submitted in the user interaction webpage. The client can integrate all tasks to be processed (including information path, task type, and tool information) submitted in the user interaction webpage into a JSON format task file. Subsequently, the client can generate a corresponding task processing request based on the task file and send it to the Shiny server, causing the Shiny server to execute the method steps at block 102, create a task entry corresponding to the task to be processed according to the task database, and configure the task status of the created task entry to a first state.

[0036] In box 204, method 200 can respond to a refresh of the user interaction webpage by querying the task entry corresponding to the task in the user interaction webpage from the Shiny server's task database, and updating the task-related information of the task in the user interaction webpage. In one or more embodiments of this disclosure, refreshing the user interaction webpage refers to a refresh operation for a task in the user interaction webpage. For example, refreshing the user interaction webpage can be a complete refresh of the user interaction webpage, a reopening of the user interaction webpage, a refresh of only the task list used to display the processing tasks in the user interaction webpage, or a refresh of at least one task bar in the user interaction webpage. In one or more embodiments of this disclosure, when the client browser detects a refresh of the user interaction webpage, it can obtain all tasks in the user interaction webpage that involve refresh operations (i.e., refreshed tasks). There can be one or more tasks. The client can generate a corresponding task query request based on the information path of the refreshed task and send it to the Shiny server. After receiving the task query request from the client, the Shiny server sends a feedback result for the task query request to the Shiny client in response to the request. In one or more embodiments of this disclosure, the task-related information can include at least the task's processing status and processing result. The processing status of a task corresponds to the task status field value of the task entry in the task database. Based on the received feedback, the Shiny client can first determine the task status and whether it needs to update the task processing result in the user interaction webpage. If the feedback indicates the task's processing status is in state one or two, it means the task has not yet been completed, and there is no need to retrieve the task's processing result. If the feedback indicates the task's processing status is in state three, then the task processing result needs to be extracted from the feedback and the displayed content in the corresponding user interaction webpage updated.

[0037] This approach separates Shiny application task processing from the session, preventing the loss of computation results due to page refresh or closing. Furthermore, separating task processing from the session allows it to be separated from the corresponding R process of the Shiny application, avoiding blocking of R process tasks and optimizing resource allocation on the Shiny server.

[0038] Based on the above method embodiments, please refer to the appendix. Figure 3 This invention provides a task processing system 300 based on the R Shiny application, including a Shiny server 301 and a Shiny client 302.

[0039] Shiny server 301 is configured with a task database 311 for recording task entries. Each task entry includes the information path, task type, tool information, and task status of the corresponding task. In response to receiving a pending task submitted by Shiny client 302, Shiny server 301 can create a task entry corresponding to the pending task in task database 311 and configure the task status of the created task entry as a first state. Shiny server 301 can also poll task database 311 to start one or more tasks corresponding to one or more task entries in task database with a first state, and configure the task status of the started task's corresponding task entry as a second state. Furthermore, Shiny server 301 can also configure the task status of the completed task's corresponding task entry in task database 311 as a third state upon task completion.

[0040] In response to the submission of a pending task in the user interaction webpage 321, the Shiny client 302 creates a task entry corresponding to the pending task in the task database 311 of the Shiny server 301. The Shiny client 302 also responds to a refresh of the user interaction webpage 302 by querying the task database 311 of the Shiny server 301 for the task entry corresponding to the task in the user interaction webpage, and updates the task-related information of the task in the user interaction webpage 321.

[0041] Figure 4 A block diagram of a Shiny server 301 according to some embodiments of the present disclosure is shown. The various embodiments in this specification are described in a progressive manner, with reference to each other for similar or identical parts. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. Figure 4As shown, the Shiny server 301 is configured with a task database 311 for recording task entries. Each task entry includes the information path, task type, tool information, and task status of the corresponding task. The server 301 includes a task entry creation module 312, configured to create one or more task entries corresponding to the pending task file in the task database 311 in response to receiving a pending task file submitted by a Shiny client, and configure the task status of the created task entry as a first state. The server 301 also includes a task polling module 313, configured to poll the task database 311 to start one or more tasks corresponding to one or more task entries in the task database with a task status of first state, and configure the task status of the task entry corresponding to the started task as a second state. The server 301 also includes a task monitoring module 314, configured to configure the task status of the task entry corresponding to the completed task in the task database 311 as a third state in response to task completion.

[0042] Figure 5 A block diagram of a Shiny client 302 according to some embodiments of the present disclosure is shown. The various embodiments in this specification are described in a progressive manner, with reference to each other for similar or identical parts. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. Figure 5 As shown, the Shiny client 302 includes a task submission module 322, configured to create a task entry corresponding to the task in the Shiny server's task database in response to the submission of a task to be processed in the user interaction webpage 321. The task entry includes the task's information path, task type, tool information, and task status. The Shiny client 302 also includes a task query module 323, configured to update the task-related information in the user interaction webpage by querying the Shiny server's task database for the task entry corresponding to the task in the user interaction webpage in response to a refresh of the user interaction webpage.

[0043] Figure 6 A task processing flowchart between the Shiny server and the Shiny client according to an embodiment of this disclosure is shown. Figure 6 As shown, task processing includes the task creation process, as detailed below:

[0044] At box 6a1, the Shiny client detected that the user submitted a task through the user interaction webpage of the client browser.

[0045] At box 6a2, the Shiny client browser retrieves all tasks submitted by the user, thereby determining the tasks to be processed.

[0046] At box 6s3, the Shiny client generates a task file based on the defined tasks to be processed and sends it to the Shiny server via a task processing request.

[0047] At box 6s4, the Shiny server receives a task processing request, determines the task to be processed, and creates a corresponding task entry in the task database 611 based on the determined task to be processed. The task status of the created task entry is set to 'Fresh' (i.e., the first state), which indicates that the task has not been processed.

[0048] like Figure 6 As shown, task processing also includes the task processing procedure, as detailed below:

[0049] At box 6b1, the Shiny server polls the task database 611 to determine whether there is a task entry in the task database with a task status of the first status.

[0050] At box 6b2, the Shiny server identifies the task corresponding to the task with the first status as the task to be processed.

[0051] At box 6b3, the Shiny server initiates the determined pending task and accesses the task database 611, modifying the entry status of the corresponding task entry in the task database to indicate that it is currently being processed as 'Busy' (i.e., the second state).

[0052] At box 6b4, when the Shiny server finishes executing the corresponding task, it will access the task database 611 and modify the status of the task entry corresponding to the completed task in the task database to indicate that the processing is complete (i.e., the third state).

[0053] like Figure 6 As shown, task processing also includes a task query process, as detailed below:

[0054] At box 6c1, the Shiny client detected a user refresh operation on the user interaction webpage.

[0055] At box 6c2, the Shiny client browser retrieves the refreshed tasks from the user's interactive webpage as query tasks and generates a task query request to send to the Shiny server.

[0056] At box 6c3, after receiving a task query request, the Shiny server accesses the task database 611 and generates a feedback result as a response to the task query request based on the task entry corresponding to the queried task.

[0057] At box 6c4, after receiving the feedback, the Shiny client updates the relevant task information on the user interaction webpage.

[0058] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0059] Figure 7 A block diagram of an electronic device 700 that can implement various embodiments of the present disclosure is shown. (See diagram for reference.) Figure 7 As shown, the electronic device 700 includes a processor 710, a disk drive 720, an input / output interface 730, a network interface 740, and a memory 750. The processor 710, disk drive 720, input / output interface 730, network interface 740, and memory 750 can communicate with each other via a communication bus 760.

[0060] The processor 710 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0061] The memory 750 can be implemented in the form of ROM (Read Only Memory), RAM (Read Access Memory), static memory, dynamic storage devices, etc. The memory 750 can store the operating system 751 for controlling the operation of the electronic device 700, and the basic input / output system (BIOS) 752 for controlling the low-level operations of the electronic device 700. Additionally, it can store a web browser 753, a data storage management system 754, etc. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 750 and is called and executed by the processor 710.

[0062] The input / output interface 730 is used to connect input / output modules to enable information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0063] The network interface 740 is used to connect the communication module (not shown in the figure) to enable communication and interaction between the device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0064] Bus 760 includes a pathway for transmitting information between various components of the device, such as processor 710, disk drive 720, input / input interface 730, network interface 740, and memory 750.

[0065] It should be noted that although the above-described device only shows the processor 710, disk drive 720, input / output interface 730, network interface 740, memory 750, bus 760, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the method of this application, and does not necessarily include all the components shown in the figures.

[0066] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0067] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0068] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for task processing based on R Shiny application, applied to a Shiny server, characterized in that, The Shiny server is configured with a task database for recording task entries, the task entries including information path, task type, tool information and task status of corresponding tasks, and the method comprises: in response to receiving a submitted pending task of a Shiny client, creating a task entry corresponding to the pending task in the task database, and configuring the task status of the created task entry as a first state; polling the task database to start one or more tasks corresponding to one or more task entries with a first state in the task database, and configuring the task status of the task entry corresponding to the started task as a second state; and in response to completion of a task, configuring the task status of the task entry corresponding to the completed task in the task database as a third state.

2. The method of claim 1, wherein, Further comprising: in response to a task query request of a Shiny client, determining one or more task entries corresponding to one or more tasks corresponding to the task query request from the task database; based on the determined one or more task entries, generating a feedback result for the task query request and sending it to the Shiny client.

3. The method of claim 1, wherein, The polling of the task database to start one or more tasks corresponding to one or more task entries with a first state in the task database comprises: determining whether there are task entries with a first state in the task database; in response to determining that there are task entries with a first state in the task database, based on one or more of the information path, task type and tool information of the task entries with a first state, calculating the computing resources required for the pending task corresponding to the task entries with a first state; based on the computing resources required for the pending task, determining a computing node matching the pending task from one or more computing nodes of the Shiny server; and assigning the pending task to the determined computing node for processing.

4. A method for task processing based on R Shiny application, applied to a Shiny client, characterized in that, Comprising: in response to the submission of a pending task in a user interactive web page, creating a task entry corresponding to the pending task in the task database of the Shiny server, wherein the task entry includes the information path, task type, tool information and task status of the corresponding task; and in response to refreshing of the user interactive web page, updating the task related information of the tasks in the user interactive web page by querying the task entries corresponding to the tasks in the user interactive web page from the task database of the Shiny server.

5. The method of claim 4, wherein, in response to the submission of a pending task in a user interactive web page, creating a task entry corresponding to the pending task in the task database of the Shiny server comprises: in response to the submission of a pending task in a user interactive web page, obtaining the information path, task type and tool information of each pending task submitted in the user interactive web page; generate a JOSN format task file corresponding to the user interaction webpage according to the information path, the task type and the tool information of the task to be processed obtained; generate a corresponding task processing request based on the task file to be processed and send it to the Shiny server.

6. The method of claim 4, wherein, In response to refreshing of the user interaction webpage, the task related information of the task in the user interaction webpage is updated by querying the task entry corresponding to the task in the user interaction webpage from the task database of the Shiny server, including: In response to refreshing of the user interaction webpage, one or more tasks are determined from the user interaction webpage; Based on the one or more tasks determined, a corresponding task query request is generated and sent to the Shiny server; and Based on the response of the Shiny server to the task query request, the task related information of the corresponding task in the user interaction webpage is updated.

7. A Shiny server for processing a task, characterized in that, The Shiny server is configured with a task database for recording task entries, and the task entries include information path, task type, tool information and task state of the corresponding task, and the server includes: A task entry creation module is configured to create one or more task entries corresponding to the task file to be processed in the task database in response to receiving the submitted task file to be processed of the Shiny client, and configure the task state of the created task entry to a first state; A task polling module is configured to poll the task database to start one or more tasks corresponding to one or more task entries in the task database whose task state is the first state, and configure the task state of the task entry corresponding to the started task to a second state; and A task monitoring module is configured to configure the task state of the task entry corresponding to the completed task in the task database to a third state in response to completion of the task.

8. A Shiny client for processing a task, characterized in that, including: A task submission module is configured to create a task entry corresponding to the task to be processed in the task database of the Shiny server in response to submission of the task to be processed in the user interaction webpage, wherein the task entry includes information path, task type, tool information and task state of the corresponding task; and A task query module is configured to update the task related information of the task in the user interaction webpage by querying the task entry corresponding to the task in the user interaction webpage from the task database of the Shiny server in response to refreshing of the user interaction webpage.

9. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-6.

10. An electronic device comprising: one or more processors, and a memory associated with the one or more processors, the memory for storing program instructions which, when read and executed by the one or more processors, perform the steps of the method of any one of claims 1-6.

Images