A multi-service entity-oriented web page upload task unified management method

Abstract

The application provides a webpage end material uploading task unified management method for multi-service entities. The method comprises the following steps: a user client creates a task through a service component; the service component generates service parameters of the task and sends the service parameters to a global uploading task management module; the global uploading task management module uniformly converts the service parameters in different tasks into global uploading tasks carrying service contexts, and uploads corresponding files to a server; after the server successfully receives the files, the server sends a file uploading success response information to the global uploading task management module; and the global uploading task management module executes post-service actions according to registered post-action types and parameters in the task. The method makes each service component only need to register uploading tasks and service contexts, and the global uploading manager is responsible for file direct transmission, file level progress display and service post-action triggering after uploading is completed, so that uploading experience is improved and server transfer pressure is reduced.

Description

Technical Field

[0001] This invention relates to the fields of file uploading, task management, and business process collaboration, and in particular to a unified management method for web-based upload tasks for multiple business entities. Background Technology

[0002] In existing web applications, file uploads are typically handled by specific business pages or pop-up components. For example, a meeting details component might upload meeting references or recordings, a smart dialogue component might upload attachments to input fields, and a to-do or task details component might upload business-related attachments. This approach usually couples all the logic—file selection, upload request, upload progress, business API calls after successful upload, failure notifications, retries, and redirection—into the local component that initiates the upload.

[0003] The existing file upload methods in web applications have the following drawbacks. First, the upload status is strongly tied to the lifecycle of local components. If the user closes the pop-up, switches routes, or leaves the initiating page during the file upload process, the upload status may become invisible, and the business components may find it difficult to continuously display the upload progress and results.

[0004] Second, multiple business modules repeatedly implement the upload logic, resulting in inconsistent user experiences for progress display, error handling, cancellation, retry, and success notifications, leading to high maintenance costs.

[0005] Third, traditional links often use the "browser -> web application Node.js middleware -> upload service" method to forward binary files. The Node.js layer needs to receive and forward large files, which increases server bandwidth, memory and timeout pressure, and is not conducive to the browser side's precise control of upload progress and cancellation.

[0006] Fourth, after file uploads are completed, subsequent business actions are usually triggered. For example, after meeting materials are uploaded, the attachment list is saved; after meeting recordings are uploaded, the backend is notified to start offline parsing tasks; and after smart dialogue attachments are uploaded, an attachment object that can be sent with messages is generated. Existing solutions often write these subsequent actions directly in the upload callback of local components. When the user leaves the component or the business interface fails briefly, the upload result and the business action result can easily be confused. Fifth, when uploading multiple files, if each file triggers business saving independently, the use of old business data snapshots may cause the problem of later writes overwriting earlier writes. Summary of the Invention

[0007] The embodiments of the present invention provide a unified management method for web-based data upload tasks for multiple business entities, so as to effectively improve file upload efficiency.

[0008] To achieve the above objectives, the present invention adopts the following technical solution.

[0009] (Corresponds to the claims)

[0010] As can be seen from the technical solutions provided by the embodiments of the present invention described above, the method of the present invention allows each business component to register only the upload task and business context, while the global upload manager is responsible for direct file upload, file-level progress display, failure retry, local record persistence, and triggering of business post-actions after the upload is completed, thereby improving the upload experience, reducing server relay pressure, and ensuring that the upload process can be continuously managed across pages.

[0011] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of the invention. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram illustrating the implementation principle of a unified management method for web-based data upload tasks for multiple business entities, provided in an embodiment of the present invention. Figure 2 A flowchart illustrating a unified management method for web-based data upload tasks for multiple business entities, provided in an embodiment of the present invention; Figure 3 A flowchart illustrating the triggering of post-upload business actions after a successful file upload, provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating a file-level retransmission process after an upload failure, as provided in an embodiment of the present invention. Detailed Implementation

[0014] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0015] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or couplings. The term “and / or” as used herein includes any and all combinations of one or more of the associated listed items.

[0016] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0017] To facilitate understanding of the embodiments of the present invention, the following will provide further explanation and description with reference to the accompanying drawings and several specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0018] This invention provides a globally unified data upload management method based on web applications. The method sets up a global upload manager in the root-level runtime environment of the web application. Business components register upload tasks, and the global upload manager uniformly executes file direct upload, progress management, failure retries, local persistence, post-upload business actions, and upload result display.

[0019] This invention provides an implementation principle for a globally unified data upload management method based on web applications, as follows: Figure 1 As shown, the module structure of this method includes: a user client, a relay client, and a server. The user client includes business components and an upload result display module. The relay client includes a global upload task management module, and the server includes an upload file response module. The global upload task management module stores global upload tasks and manages information such as the upload task list, runtime file objects, cancellation controller, upload success callbacks, upload failure callbacks, and task operation methods.

[0020] This invention provides a processing flow for a globally unified data upload management method based on web applications, as follows: Figure 2As shown, the processing steps include the following: Step S10: The user creates a task through the business component, the business component generates business parameters, and sends the business parameters to the global upload task management module.

[0021] The user client associates and stores the business context and files corresponding to each business scenario. Multiple business components are set up in the web application of the user client, each corresponding to a business scenario such as uploading meeting materials, uploading meeting recordings, uploading chat attachments, and uploading to-do items. After a user triggers a file selection or drag-and-drop upload operation in any business component, that component obtains the corresponding business context and the file to be uploaded based on its current business scenario, and performs format, size, quantity, or business condition validation on the file to be uploaded. Upon successful validation, the business component generates business parameters, including the file object, upload type, belonging entity, belonging entity title, redirect address, upload target, post-action type and parameters, prompt text, and callback function parameters, and then calls the unified upload interface or the unified upload adapter component. For example, in a meeting recording upload scenario, the business component verifies the audio format in the file, reads the audio duration, calculates the meeting start and end times, generates the upload directory and upload file name, and assembles the business parameters used to notify the backend to start the offline parsing task.

[0022] Business components call the unified upload interface or the unified upload adapter component to transmit business parameters to the global upload task management module. The global upload task management module resides in the root-level user client environment of the same web application instance, and it receives business parameters submitted by multiple business components within the same user client.

[0023] Step S20: The global upload task management module creates the business upload record and file upload details corresponding to the global upload task, and executes the file upload operation corresponding to the global upload task.

[0024] The business upload adaptation module in the global upload task management module uniformly converts business parameters from different tasks into global upload tasks carrying business context. After receiving the business parameters submitted by the business component, the business upload adaptation module first normalizes the parameters under different business scenarios. For example: for meeting material uploads, business parameters include meeting entity information, meeting material save path, existing attachment list, and post-action for saving meeting materials; for meeting recording uploads, business parameters include meeting entity information, recording file name, recording upload directory, recording duration, meeting start and end times, and post-action for offline parsing notification; for to-do attachments or dialogue attachment uploads, business parameters include the corresponding to-do, task or dialogue entity information, attachment upload target, and post-action for attachment generation or saving.

[0025] The business upload adaptation module unifies the various business parameters mentioned above into a global upload task input structure. This input structure includes at least the upload type, the entity to which it belongs, field tags, file set, upload target generation rules, post-action information, display tags, and task callback. The global upload task management module generates a task identifier and creation time based on this input structure, recording each business upload intent as a business upload record; simultaneously, it generates a file identifier for each file in the file set and generates file upload details. Each file upload detail includes the filename, file size, file type, initial progress, initial status, and upload target.

[0026] The upload type is used to distinguish business sources such as meeting materials, meeting recordings, dialogue attachments, and to-do attachments; the associated entity records the meetings, dialogues, to-dos, or tasks associated with the task, and provides a title and jump address; the upload target indicates whether the file is uploaded to a document library path-type target or a general attachment target; and the post-upload action information indicates whether to perform business actions such as saving meeting attachments, notifying offline parsing of recordings, or generating attachment objects after the file upload is successful. Therefore, different business components do not need to maintain a complete upload lifecycle separately, but instead connect to the global upload task management module through a unified task model.

[0027] The global upload task management module assembles global upload tasks based on the aforementioned business upload records and file upload details. It converts files, their parent entities, upload targets, and subsequent action parameters from business components into global upload tasks.

[0028] The aforementioned global upload task comprises two layers: business upload records and file upload details. Business upload records express a user's business intent, including task identifier, upload type, associated business entity, entity title, redirect address (the page triggered by the business), creation time, update time, post-action type, and post-action parameters. File upload details express one or more specific files under this business intent, including file identifier, filename, file size, file type, upload progress, upload status, upload target, and upload service return result. Upload targets can include document library path-based upload targets and general attachment upload targets; document library path-based upload targets upload files to a specified document library, storage space, or directory path, while general attachment upload targets upload files to a general business attachment service. The upload service return result can include file key, access URL, download key, and raw response.

[0029] After the global upload task management module starts a global upload task, the file direct upload execution module within it executes the corresponding file upload operation, constructing the upload address and form data according to the upload target in the file upload details. The file direct upload execution module, through the root-level upload manager, allows the upload process to continue execution independently of the business component's lifecycle. It uploads a file request body to the server via the browser, carrying a browser cookie for authentication; it does not read or persist the HttpOnly token. The file direct upload execution module sets credentials or withCredentials when uploading files, enabling the browser to carry authentication information according to same-origin or cross-domain credential rules. The file direct upload execution module is used to directly send the file binary to the upload service via the browser's XMLHttpRequest or an equivalent transmission method that allows monitoring of upload progress.

[0030] Step S30: The upload progress monitoring module monitors the file upload progress.

[0031] The upload progress monitoring module in the global upload task management module listens for the `upload.onprogress` event of XMLHttpRequest (a browser-provided network request capability that allows monitoring upload progress) and writes the upload progress of a single file to the corresponding file details. Since this event reflects the progress of the browser sending the file upload request body to the server, and does not indicate whether the server has completed writing, transferring, or generating a response, the file progress can remain at 99% when the upload request body has been sent but the server has not yet returned a success response. Only after the server returns a success response to the client and the response content is parsed will the system set the file progress to 100%, and then the server will send a file upload success response message to the client.

[0032] Step S40: After the file upload is successful, the post-upload task management module in the global upload task management module executes the post-upload task according to the post-upload task type and parameters.

[0033] After receiving the file upload success response from the server, the user client sends the same response back to the user client. The upload result display module in the user client then displays this response to the user. This module is used to display the upload task result information globally, such as in the client's sidebar.

[0034] The post-upload task management module in the global upload task management module executes the post-upload action according to the post-upload action type and parameters registered in the task, and sends the post-upload action execution result information to the user client. The upload result display module in the user client displays the post-upload action execution result information to the user.

[0035] Figure 3 This invention provides a flowchart of a business post-upload action triggered upon successful file upload. For meeting material uploads, after all files in the same business upload record have been successfully uploaded, the system assembles the multiple file results into an attachment list and calls the meeting details saving interface. For meeting recording uploads, the system sends the original upload service response to the offline audio upload callback interface to notify the backend to start the offline recording parsing task. For intelligent dialogue attachment uploads, the system converts the upload service return result into an attachment object that can be sent with a message.

[0036] The post-processing business action module is triggered uniformly by the global upload task management module based on the callback of task registration, rather than being triggered again locally by the business component.

[0037] The file upload status and subsequent action status are decoupled. When the upload result display module shows the result to the user, it uses the successful return of file information by the file upload service as the criterion for determining whether the file upload was successful. If the file upload is successful but the subsequent business action fails, such as the meeting recording callback interface returning an error due to backend version rollback, the upload center will still display "uploaded successfully" for the file. The failure of the subsequent business action can be handled separately through console alarms, business page prompts, or backend task monitoring. This avoids users misunderstanding "the file has been successfully uploaded but the business processing has temporarily failed" as "the file was not successfully uploaded".

[0038] Cross-component continuation steps. After the upload task is created, the runtime file object, cancellation controller, and post-action callback are stored in the global upload task management module. In addition to storing persistent upload task metadata, the global upload task management module also maintains temporary runtime data corresponding to the task during runtime. This temporary runtime data includes a set of original file objects, a set of cancellation controllers, upload success callbacks, upload completion callbacks, and upload failure callbacks. The set of original file objects is used to store the File object selected by the user during the current browser page runtime; the set of cancellation controllers is used to create a corresponding AbortController or equivalent cancellation control object for each file being uploaded.

[0039] When the global upload task management module performs a file upload, it creates a cancellation controller for each file upload detail and associates and saves the cancellation controller with the file identifier. When a user triggers a cancellation operation in the upload results display module, clears incomplete tasks, or logs out, the global upload task management module finds the corresponding cancellation controller based on the task identifier, calls the cancellation method to interrupt the ongoing upload request, and updates the task or file detail status to "cancelled".

[0040] The original file object and cancellation controller are only stored during the current web application runtime and are not written to local storage. After the page is refreshed, the browser cannot restore the original File object. Therefore, for tasks that are not completed and have no upload response, the system marks them as interrupted, canceled, or prompts the user to select a new file; for tasks that have received an upload service response, their task metadata, upload results, and redirection information are retained.

[0041] As long as the web application is not refreshed and the global upload task management module is not uninstalled, the file upload will continue even if the user closes the original business pop-up, switches pages, or reopens the upload center later. Upon successful upload, the post-upload actions registered when the task was created will still be triggered. If the user remains in the original business component waiting for the upload to complete, the post-upload actions will only be triggered once by the same upload task execution chain in the global upload task management module, and will not be triggered repeatedly simply because the business component still exists.

[0042] Figure 4 This invention provides a flowchart of a file-level retransmission process after an upload failure. When a file upload fails, the upload result display module shows the failure status and a retry button in the corresponding file details row. If the original File object is still saved during the current page runtime, after the user clicks retry, the system only resets the details of the unsuccessfully uploaded file to the waiting-to-upload state and re-executes the file direct upload step. After the file is successfully re-uploaded, the system continues to execute the subsequent business actions registered for this upload task. If a page refresh causes the original File object to be lost, the system prompts the user to select a new file. This retry mechanism is not used to retry subsequent business actions that are decoupled from the file upload status.

[0043] Local persistence steps. Upload task metadata is saved to the client's local storage, for example, to the `localStorage` item with the key "file-center:uploads". Persistent content includes business upload records, file details, status, progress, upload response, error messages, and redirect targets, excluding file binary data and sensitive authentication tokens. When a user logs out, the system clears the local upload task record. After the page refreshes, for upload tasks that have not received an upload service response, the system can mark them as canceled or prompt for re-upload; for tasks that have received an upload service response, the system retains their historical upload results and redirect information.

[0044] Same-origin proxy assistance steps. In a production environment, the browser can directly access the upload service based on the same domain as the front-end and back-end. In local development or network-restricted environments, local access can be configured to use the same-origin address of the current web application, and the preset upload path can be proxied to the upload service address accessible by the server through the same-origin proxy or path forwarding mechanism on the web application server. This same-origin proxy is only used to assist the browser in cross-domain and cookie carrying, and does not restore the original Node.js business upload interface mode of receiving and forwarding file binary data.

[0045] This same-origin proxy helps resolve cross-domain and cookie issues in development environments by assisting direct uploads. Specifically, in a production environment, the upload service can reside on the same site as the web application or be under a domain permitted by the browser's cookie policy. The browser directly accesses the upload service via a direct upload request and completes authentication via cookies. In local development, intranet deployment, or network isolation environments, if the browser cannot directly access the upload service domain, or if cross-domain requests cannot carry authentication cookies as expected, the browser-side upload address can be configured to a same-origin path of the current web application, such as using a preset upload path under the current web application domain as the request entry point. The web application server forwards or reverse proxies this preset upload path, forwarding the request to the actual upload service address. The role of this same-origin proxy is to ensure that upload requests issued by the browser complete cookie carrying and cross-domain restriction avoidance under the same-origin address, while maintaining the business semantics of the upload request as a direct file upload initiated by the browser. The upload progress is still listened to by the browser-side XMLHttpRequest's upload.onprogress event, and upload cancellation is still triggered by the browser-side cancellation controller. This same-origin proxy differs from the traditional business upload interface relay mode. In the traditional model, the Node.js business interface of a web application needs to parse, cache, or process file binary data before actively calling the upload service. In contrast, the same-origin proxy in this solution only serves as an auxiliary channel for network paths and authentication contexts. It does not change the unified management of upload tasks, progress, cancellation, retries, and post-actions by the global upload task management module, nor does it restore the scattered upload logic in business components.

[0046] The upload results display module's interaction steps are as follows. The upload results display module can be placed in a global location, such as above the user's avatar in the web application sidebar. The task card displays the upload type, the associated entity, and file details. The associated entity is displayed as "Associated Meeting," "Associated Conversation," "Associated To-Do," or "Associated Task," etc., depending on the type. File details display the filename, size, progress, and status of each file. The upload center does not display the average total progress of the entire business record, but rather the actual progress of each file. The task card provides a "View" button to jump to the corresponding meeting, conversation, to-do, or task; single-entry deletion and clearing all entries are completed through a lightweight secondary confirmation pop-up.

[0047] (5) Decouple the file upload result from the business post-action result; (6) Provide a retry mechanism based on the runtime File object in the failed file line, and continue to execute the original task post-action after the retry is successful; (7) Save non-sensitive upload task metadata through the client's local storage and clean it up when logging out; (8) Solve the cross-domain and cookie carrying problems in the development environment by using the same-origin proxy to assist direct upload.

[0048] In summary, this embodiment of the invention improves the global visibility of the upload process. Upload tasks are uniformly managed by the upload result display module, allowing users to view upload progress and results from a unified entry point even after leaving the business component that initiated the upload.

[0049] Reduce resource consumption in the Node.js middleware layer of web applications. File binary files are uploaded directly from the browser to the upload service, reducing the pressure on the Node.js server for receiving, caching, and forwarding large files, and lowering bandwidth, memory, and timeout risks.

[0050] Improve user experience consistency. The same upload task model, progress display, deletion confirmation, clear confirmation, failure retry, and redirection mechanism are reused across different business scenarios, such as meeting materials, meeting recordings, and intelligent dialogue attachments, to avoid fragmented user experiences across different business pages.

[0051] Improve failure recovery efficiency. When an upload fails, the system can retry the failed file within the current page while retaining the original file object. After a successful retry, the system automatically continues to execute the subsequent business actions in the original task, reducing the cost for users to repeatedly select business contexts and reoperate.

[0052] Reduce the risk of business data overwriting. For multiple files in a single business upload record, the system can perform a unified business save operation after all files are successfully uploaded, avoiding the overwriting of attachment lists caused by multiple files being saved independently.

[0053] Improve the accuracy of upload status display. The upload center uses the file upload service's return result as the basis for judging whether the file upload was successful. It decouples subsequent actions such as offline callback of meeting recording and saving meeting materials from the file upload result, avoiding the possibility that users may mistakenly believe that the file was not uploaded successfully due to backend business interface version rollback or temporary failure.

[0054] Enhance cross-page continuity. Once an upload task is created, it continues execution from the root-level upload manager, independent of business pop-ups or local pages, enabling the upload process in single-page applications to run continuously across routes and business regions.

[0055] Enhanced scalability. The upload task model reserves business entity types such as the associated meeting, conversation, to-do list, and task. When adding new data upload business in the future, only the upload target and subsequent actions need to be provided to connect to the unified upload center.

[0056] Enhance security and controllability. The client's local storage only saves upload task metadata, file upload responses, and redirect targets; it does not save file binary data or sensitive tokens. Local upload records are cleared when a user logs out.

[0057] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

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

[0059] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatus or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The apparatus and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0060] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A unified management method for web-based data upload tasks for multiple business entities, characterized in that, include: The user client creates a task through a business component, which generates business parameters for the task and sends these parameters to the global upload task management module. The global upload task management module receives business parameters from different tasks submitted by multiple business components within the same user client, converts the business parameters from different tasks into a unified global upload task carrying a business context, and uploads the file corresponding to the global upload task to the server. After the server successfully receives the file, it sends a file upload success response message to the global upload task management module. The post-upload action module in the global upload task management module executes the post-upload action according to the post-upload action type and parameters registered in the task.

2. The method according to claim 1, characterized in that, The user client creates a task through a business component, which generates business parameters for the task and sends these parameters to the global upload task management module, including: In the user client, the business context and files corresponding to each business scenario are associated and stored. In the web application of the user client, multiple business components are set up. Each business component corresponds to a business scenario. After the user triggers a file selection or drag-and-drop upload operation in any business component in the user client, the business component obtains the corresponding business context and the file to be uploaded based on the corresponding business scenario, and verifies the file to be uploaded. After the verification is successful, the business component generates business parameters. The business parameters include file object, upload type, belonging entity, belonging entity title, jump address, upload target, post-action type and parameters, prompt text and callback function parameters. Business components call the unified upload interface or the unified upload adapter component to transmit business parameters to the global upload task management module, which is located in the root-level user client environment of the same web application instance.

3. The method according to claim 2, characterized in that, The global upload task management module receives business parameters from different tasks submitted by multiple business components within the same user client, converts these parameters into a unified global upload task carrying the business context, and uploads the file corresponding to the global upload task to the server, including: The global upload task management module receives business parameters submitted by multiple business components within the same user client. After receiving the business parameters submitted by the business components, the business upload adaptation module first normalizes the parameters under different business scenarios, and then converts the different business parameters into a unified global upload task input structure. This input structure includes upload type, associated entity, field tags, file set, upload target generation rules, post-action information, display tags, and task callback. The upload type is used to distinguish the business source; the associated entity is used to record the meetings, conversations, to-dos, or tasks associated with the task, and provides a title and jump address; the upload target is used to indicate whether the file is uploaded to a document library path-type target or a general attachment target; the post-action information is used to indicate whether to perform business actions such as saving meeting attachments, offline parsing notification of recording, or generating attachment objects after the file upload is successful. The global upload task management module generates a task identifier and creation time based on the input structure, and records a business upload intention as a business upload record; at the same time, it generates a file identifier for each file in the file set and generates file upload details. The global upload task management module assembles a global upload task based on the above business upload records and file upload details. The global upload task comprises two layers: business upload records and file upload details. The business upload records express a user's business intent, including task identifier, upload type, business entity, entity title, redirect address, creation time, update time, post-action type, and post-action parameters. The file upload details express one or more specific files under this business intent, including file identifier, file name, file size, file type, upload progress, upload status, upload target, and upload service return result. The upload target includes document library path-type upload targets and general attachment upload targets. The upload service return result includes file key, access URL, download key, and raw response. After the global upload task management module starts the global upload task, the file direct upload execution module in the global upload task management module performs the file upload operation corresponding to the global upload task.

4. The method according to claim 3, characterized in that, The file direct upload execution module in the global upload task management module performs the file upload operation corresponding to the global upload task, including: The global upload task management module constructs the upload address and form data according to the upload target in the file upload details. The file direct upload execution module uploads a file request body carrying the file corresponding to the global upload task to the server through the browser's XMLHttpRequest. The file upload request body carries the browser cookie to complete the authentication, but does not read or persist the HttpOnly token. The upload progress monitoring module in the global upload task management module listens for the upload.onprogress event of XMLHttpRequest. This event reflects the progress of the browser sending the upload file request body to the server and writes the upload progress of a single file to the corresponding file details. When the upload file request body is sent but the server has not yet returned a success response, the file progress remains at 99%. Only when the server returns a file reception success response to the global upload task management module in the relay client and the response content is parsed will the system set the file progress to 100%. The global upload task management module returns a file upload success response message to the user client. After receiving the file upload success response message, the upload result display module in the user client displays the file upload success response message to the user.

5. The method according to claim 4, characterized in that, The post-upload task management module in the aforementioned module executes post-upload actions based on the post-upload action type and parameters registered in the task, including: After receiving the file upload success response from the server, the user client sends the file upload success response to the user client. The post-upload success response module in the global upload task management module executes the post-upload action according to the post-upload action type and parameters registered in the task, and sends the post-upload action execution result information to the user client. The upload result display module in the user client displays the post-upload action execution result information, the file-level progress, status, failure reason, retry entry and business jump entry of the upload task to the user. When the upload result display module is presented to the user, it uses the successful return of file information by the file upload service as the criterion for determining the success of the file upload. If the file upload is successful but the subsequent business action fails, the upload center will still display "upload successful" for the file. The failure of the subsequent business action will be handled separately through console alarms, business page prompts, or backend task monitoring. When a file upload fails, the upload result display module will show the failure status and a retry button in the corresponding file details row. If the original File object is still saved during the current page runtime, after the user clicks retry, the system will only reset the details of the file that was not successfully uploaded to the waiting upload status and re-execute the file direct upload step. After the file is successfully uploaded again, the system will continue to execute the subsequent business actions registered for the upload task. If the original File object is lost due to page refresh, the system will prompt the user to select a new file.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: In addition to storing persistent upload task metadata, the global upload task management module also maintains temporary runtime data corresponding to the tasks during runtime. This temporary runtime data includes a set of original file objects, a set of cancellation controllers, upload success callbacks, upload completion callbacks, and upload failure callbacks. The set of original file objects is used to store the File object selected by the user during the current browser page runtime. The set of cancellation controllers is used to create a corresponding AbortController or equivalent cancellation control object for each file being uploaded. When the global upload task management module performs a file upload, it creates a cancellation controller for each file upload detail and saves the cancellation controller with the file identifier. When the user triggers a cancellation operation in the upload result display module, clears incomplete tasks, or logs out, the global upload task management module finds the corresponding cancellation controller based on the task identifier, calls the cancellation method to interrupt the ongoing upload request, and updates the task or file detail status to canceled.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: In a production environment, the upload service and the web application reside on the same site or under a domain permitted by the browser's cookie policy. The browser directly accesses the upload service via a direct upload request and completes authentication via cookies. In local development, intranet deployment, or network isolation environments, if the browser cannot directly access the upload service domain, or if cross-domain requests cannot carry authentication cookies as expected, the browser-side upload address can be configured to the same origin path as the current web application. The upload progress is listened to by the browser-side XMLHttpRequest's upload.onprogress event, and upload cancellation is still triggered by the browser-side cancellation controller.

Images