Enterprise portal integration method based on user-defined client

Abstract

The invention relates to the technical field of computer software, and discloses an enterprise portal integration method based on a user-defined client, and a desktop end system and a server end system are cooperatively executed. The desktop end system performs signature verification and static compilable verification on the integrated formula package, activates the candidate integrated formula package when both pass the signature verification and the static compilable verification, and returns and activates the previous effective integrated formula package when any one does not pass the signature verification and the static compilable verification; the desktop end system carries out constraint compiling on the precondition expression set and the sequence state machine definition and calculates a satisfiability reachable relation; the desktop end system performs consistency judgment based on the verifiable voucher packet and the target permission range, and outputs entry permission or rejection and reason codes; the server-side system signs and issues a one-time link bill carrying a user after checking a formula version, an interface contract abstract and a sequence state of the bill application parameters; and the desktop end system generates receipt abstracts and idempotent event keys, writes the receipt abstracts and idempotent event keys into an event account book, and compensates and uploads the receipt abstracts and idempotent event keys in batches during offline and network recovery.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, specifically to a method for integrating an enterprise portal based on a custom client. Background Technology

[0002] During enterprise IT infrastructure development, multiple business systems typically run simultaneously, and cross-system data exchange and business collaboration are achieved through an enterprise service bus (OSS). To reduce the operational costs for users switching between multiple business systems, existing technologies often employ an enterprise portal approach to provide a unified entry point. One common implementation involves a desktop system or a custom client serving as the front-end entry point, allowing access to different business systems through embedded pages, pop-up browser windows, or API calls. The server-side system is responsible for communicating and interacting with the OSS and various business systems, providing the desktop system with capabilities such as push notifications, to-do list notifications, and unified login.

[0003] The aforementioned existing technologies still have several technical limitations in actual deployment and operation. First, portal entry and business system access rules are usually maintained by configuration files or backend management interfaces. However, the configuration content often lacks machine-determinable constraints. When the desktop system is running, the judgment of entry accessibility, precondition satisfaction, and cross-system jump order relies on manual agreements or scattered logic. This can lead to inconsistencies between the displayed entry and the actual accessibility status, and a lack of unified handling paths after cross-system jump failures when business systems are added or removed, permission scopes are adjusted, or interface definitions change. Second, access authentication between business systems usually uses session identifiers or token mechanisms. When the portal jumps between systems, it needs to pass the authentication context between multiple systems. Without unified constraints and consistency checks, issues such as token mismatch with the target system's permission scope, interface contract changes leading to inconsistent parameters or return structures, and ticket-type jump parameters being reused or timed out can easily occur, resulting in user requests failing and causing repeated operations. Third, portal systems often need to keep records of user operations, redirection results, and notification processing to support auditing and problem localization. However, in network fluctuations or offline scenarios, the operation records on the client side and the results received on the server side may be inconsistent. In addition, when there is a lack of idempotent constraints and conflict judgment conditions, it is easy to cause duplicate submissions, duplicate entries, or conflict records that are difficult to handle automatically, increasing the operation and maintenance costs.

[0004] Therefore, existing enterprise portal integration methods still have room for improvement in terms of "determinability of entry rules, consistency of cross-system access, controllability of jump order, and consistency of records in offline and network recovery scenarios." There is a need for an enterprise portal integration method that can adapt to custom clients as a unified entry point and can form definite interaction constraints between the server and the client.

[0005] To address this, this invention proposes an enterprise portal integration method based on a custom client, executed collaboratively by a desktop system and a server system: the server system distributes an integration recipe package and issues a one-time link ticket; the desktop system performs signature verification and static compilability verification on the integration recipe package to determine its activation, and constructs a constraint session graph and calculates the reachability relationship based on the activated integration recipe package to complete the entry reachability determination and permission consistency determination; in scenarios requiring tickets, the server system verifies the recipe version, interface contract summary, and sequence status of the ticket application parameters and issues a one-time link ticket carrying a single-use flag and having an expiration date; after completing the target request, the desktop system generates a receipt summary and idempotent event key, writes them to the event ledger, and performs batch compensation uploads and conflict handling in offline and network recovery scenarios. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides an enterprise portal integration method based on a custom client, thereby resolving the problems mentioned in the background section.

[0007] To achieve the above objectives, the present invention is implemented through the following technical solution: the desktop system, which serves as a unified user entry point, and the server system, which provides the capabilities for formula publishing and invoice issuance, work together to execute the system. The server system interacts with the enterprise business system and the enterprise service bus. The desktop system serves as the unified front-end entry point for the client portal system, providing the portal entry interface and supporting business page access. It is used to display the activation recipe version identifier, online status, and offline queue count at the top of the interface, and to display the rejection reason code and action entry point when a judgment fails or a ticket is rejected.

[0008] When executing the method, the desktop system further executes the following modules: The recipe acquisition and activation module is used to acquire integrated recipe packages from the server system and perform signature verification and static compilability verification on the integrated recipe packages. When the verification passes, the integrated recipe package is activated; when the verification fails, it is rolled back and the previous valid integrated recipe package is activated. Specifically, when both signature verification and static compilability verification pass, the candidate integrated recipe package is activated; when either signature verification or static compilability verification fails, it is rolled back and the previous valid integrated recipe package is activated. The constraint compilation and reachability determination module is used to perform constraint compilation on the set of precondition expressions obtained by parsing the activation integration recipe package and the sequential state machine definition, construct the constraint session graph and calculate the satisfiability reachability relationship; The credential management module is used to perform declaration aggregation and binding factor determination on the client authentication results, generate verifiable credential packages, and calculate credential package digests; The entry verification and handling module is used to perform an reachability determination based on the satisfiability reachability relationship and a consistency determination based on the verifiable credential package and the permission scope of the target business system when a user triggers the target entry. If both determinations pass, access is allowed to continue. If either determination fails, a handling action is performed based on the rejection reason code and handling action mapping defined by the activation integration recipe package. The ticket interaction and sequence control module is used to submit ticket application parameters to the server system and receive the one-time link ticket when the activation of the integrated recipe package indicates that a one-time link ticket is required. It then performs state transition determination according to the sequence state machine. If the determination passes, the one-time link ticket is attached to the target request. If the determination fails, the sequence completion process is triggered. The threshold value X for triggering the completion process ranges from 30 seconds to 300 seconds. The maximum number of completions N_max ranges from 1 to 5 times. When the completion is successful, the sequence state machine enters the allow issuance state or the termination state. When the completion fails, the processing action defined by the activation of the integrated recipe package is executed. The event ledger and compensation synchronization module is used to generate a receipt summary and idempotent event key and write them to the event ledger after the target request is completed. When the network is unavailable, it performs offline accounting. When the network is restored, it performs compensation upload in batches and completes the conflict handling closed loop according to the conflict handling rules defined by the activated integrated recipe package.

[0009] The server system is used to receive recipe acquisition requests and invoice application requests submitted by the desktop system, and execute them: Recipe release processing is used to generate and distribute integrated recipe packages containing recipe version identifiers, recipe signatures, and recipe serialization byte sequences; Contract registration processing is used to register the summary of contracts at the business system interface and provide a basis for contract consistency verification in the invoice issuance processing. The ticket issuance process is used to perform recipe version permission checks, interface contract digest consistency checks, and sequence status permission checks on the ticket application parameters. When the checks pass, a one-time link ticket is issued; when the checks fail, a rejection reason code is returned. The one-time link ticket carries a single-use flag (use_once) and has a validity period (ott_ttl) ranging from 30 seconds to 300 seconds.

[0010] Furthermore, the integrated recipe package shall at least include the following fields: recipe version identifier recipe_ver, business system description record table, precondition expression set, sequential state machine definition, rejection reason code set, rejection reason code to disposal action mapping table, recipe serialization byte sequence R_bytes, and recipe signature recipe_sig; wherein the business system description record table shall at least include business system identifier, entry route identifier, permission scope set, interface contract summary, and jump constraint parameters.

[0011] Furthermore, when the recipe acquisition and activation module performs static compileability verification on the integrated recipe package, it performs at least the following verification items: Verification of precondition expressions is only permitted using a set of limited predicates; the set of limited predicates consists of at least the following predicates: token existence predicate has_token(app_id), permission scope inclusion predicate scope_has(scope), binding factor consistency predicate bind_ok(factor), recipe version consistency predicate ver_eq(recipe_ver), and interface contract digest consistency predicate contract_eq(contract_hash); For a sequential state machine, at least an initial state and a final state must be checked. Perform verification on state transition conditions that are decisionable conditions; Perform a check if the set of rejection reason codes is a finite enumeration and if there is no missing key in the mapping table from rejection reason codes to action.

[0012] Furthermore, when the constraint compilation and reachability determination module constructs the constraint session graph, it uses the business system as the node and the "precondition expression set and jump constraint" as the edge constraint; the satisfiability reachability relationship is obtained by judging the truth of all precondition expressions on the path one by one, and outputting the binary reachability result.

[0013] Furthermore, when the credential management module generates a verifiable credential package, it writes at least: a token set, a declaration set, and a binding factor; the declaration set writes at least the user identifier, organization identifier, role set, permission scope set, and expiration time; the credential package digest is obtained through chained digest calculation. The chain digest is obtained by performing a hash operation after concatenating the recipe version identifier, user identifier, token set, declaration set, and binding factor in a deterministic order.

[0014] Furthermore, the two judgments performed by the entry verification and processing module when the user triggers the target entry satisfy the following: Reachability is determined by the satisfiability of the reachability relation, and the output is either pass or fail. The consistency determination is obtained by calculating the intersection of the permission scope set in the verifiable credential package and the permission scope set of the target business system. The determination is successful when the intersection is not empty, and unsuccessful when the intersection is empty. When any judgment fails, the action value is limited to: re-fetching the integrated formula package, re-authenticating, rolling back to the previous valid integrated formula package, triggering the sequence completion process, and prohibiting ticket application, and is determined by the rejection reason code to the action mapping table.

[0015] Furthermore, the invoice application parameters submitted by the invoice interaction and sequence control module to the server system shall carry at least the following: formula version identifier, target business system interface contract summary, voucher package summary, sequence constraint identifier, and current sequence status.

[0016] Furthermore, when the event ledger and compensation synchronization module generates an idempotent event key, it is calculated using the user identifier, business system identifier, target path, and time window start timestamp, wherein the time window width ranges from 10 seconds to 120 seconds. When the same idempotent event key exists in the event ledger, the idempotent overwrite rule is limited to: the old record is overwritten and updated only if the client timestamp of the new record is greater than the client timestamp of the old record; otherwise, the old record remains unchanged. When the network is restored, compensation uploads are performed in batches, with the batch size ranging from 50 to 500 records. The enqueue constraint for the compensation queue is limited to allowing enqueue uploads only when the sequential state machine of the corresponding record is in the completed state. The conflict determination condition is limited to identical idempotent event keys and different receipt digests. The conflict handling rule is limited to "based on the newer client timestamp" or "based on the server's authoritative receipt," and is determined by the enumeration value issued by the activation integration recipe package.

[0017] This invention provides a method for integrating an enterprise portal based on a custom client. It offers the following advantages: 1. This invention introduces a signed and statically verifiable integrated recipe package mechanism into the desktop system. It uniformly distributes and activates the business entry relationships, precondition constraints, sequential state machines, and rejection reason codes and handling action mappings involved in the enterprise portal in the form of a deterministic data structure. This enables the client to complete entry judgment and access control based on the verified recipe content during the runtime phase. This avoids the problems of rule inconsistency, difficulty in rollback, and non-reproducibility caused by relying on scattered configuration files or hard-coded rules in the prior art, and improves the controllability and consistency of the portal integration logic.

[0018] 2. This invention constructs a satisfyability reachability relationship and sequential state machine constraint on the client side, and combines it with a one-time link ticket issuance and verification mechanism, so that business entry access is only allowed to be executed when the preconditions, sequential state and interface contract consistency are met. Thus, without changing the implementation of the existing business system, it realizes unified gating of cross-system access order and permission consistency, and solves the technical problem of "only performing page aggregation and lacking access order and state constraints" that is common in existing enterprise portals.

[0019] 3. This invention sets up an event ledger and an offline compensation upload mechanism on the client side, generates idempotent event keys for business access results and records them locally. It supports offline recording when the network is unavailable, performs batch compensation uploads after the network is restored, and completes closed-loop conflict handling according to pre-issued conflict resolution rules. This makes the portal access process traceable, compensable, and replayable, overcoming the problem of lost access results or inconsistent status caused by network fluctuations in the prior art, and improving the data integrity and operational stability in enterprise portal integration scenarios. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a method for integrating an enterprise portal based on a custom client; Figure 2 This is a structural diagram of the integrated formula package of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0022] In this embodiment, the desktop system is deployed on the user terminal and serves as the unified portal entry point; the server system is deployed on the enterprise network side and communicates with the enterprise business system and the enterprise service bus. The desktop system and the server system interact via HTTPS.

[0023] To ensure process reproducibility, this embodiment imposes the following limitations on key data objects and storage media: Integrated formula pack Figure 2 The data packet generated and distributed by the server system contains the following fields: recipe_ver (recipe version identifier), R_bytes (recipe serialization byte sequence), recipe_sig (recipe signature), business system description record table, set of precondition expressions, sequential state machine definition, set of rejection reason codes, and mapping table from rejection reason codes to disposal actions.

[0024] The business system description record table should include at least: business system identifier, entry route identifier, permission scope set, interface contract summary, and jump constraint parameters.

[0025] Candidate integration recipe package: The integration recipe package obtained by the desktop system from the server system is in the candidate state before the signature verification and static compileability verification are completed.

[0026] Activate the integrated recipe pack and the previous valid integrated recipe pack: a locally persistent copy of the integrated recipe pack on the desktop system; the activated integrated recipe pack is the currently effective version, and the previous valid integrated recipe pack is the version used as a rollback.

[0027] Verifiable credential package: A data object generated by the desktop system based on the client authentication result, containing: a token set, a claim set, a binding factor, and a credential package digest; the claim set contains the user identifier, organization identifier, role set, permission scope set, and expiration time; the credential package digest is obtained through chain digest calculation.

[0028] One-time link ticket: A ticket issued by the server system, carrying a single-use flag (use_once), and a validity period (ott_ttl) ranging from 30 seconds to 300 seconds.

[0029] Event Ledger: A local storage table on the desktop system, with the following fields: event_key (idempotent event key), uid, app_id, target_path, recipe_ver, resp_digest (receipt summary), ts_client, upload_state, offline_flag, and retry_count.

[0030] The time window width ranges from 10 seconds to 120 seconds, and the compensation upload batch size ranges from 50 to 500 items.

[0031] The present invention will now be described in detail with reference to the accompanying drawings: Example 1 (refer to) Figure 1 This provides a complete closed loop for enterprise portal integration based on a custom client, namely desktop system startup—recipe verification—portal access—invoice redirection—ledger compensation.

[0032] The server-side system generates an integrated recipe package to be distributed by executing the recipe release process, specifically: S1-1: By reading the registration information of the business system, a set of business system identifiers is obtained; by extracting the entry route of each business system, an entry route identifier is written; by reading the permission scope configuration of the business system, a permission scope set is written.

[0033] S1-2, an interface contract summary is generated by using a summary calculation method on the business system interface definition file, and the interface contract summary is written into the business system description record table.

[0034] S1-3 generates an expression consisting of a set of qualified predicates by applying a generative method to the set of precondition expressions, and writes it into the integrated recipe package. The set of qualified predicates includes: has_token (app_id), scope_has (scope), bind_ok (factor), ver_eq (recipe_ver), and contract_eq (contract_hash).

[0035] S1-4, by defining measures for the sequential state machine, write the initial state, the final state and the set of state transition conditions.

[0036] S1-5, By using configuration writing measures to map the set of rejection reason codes to the action mapping table, a rejection reason code to action mapping table is formed.

[0037] S1-6, R_bytes is generated by deterministic serialization of the above recipe content, and recipe_sig is generated by signature algorithm on R_bytes. Recipe_ver, R_bytes and recipe_sig are written into the integrated recipe package and sent to the desktop system.

[0038] Deterministic serialization measures: output fields in a fixed order; output sets in lexicographical order; output byte sequences using UTF-8 encoding.

[0039] Step S2: The desktop system obtains the candidate integrated recipe package and performs double verification. The desktop system completes the acquisition and verification of candidate integrated recipe packages by executing the recipe acquisition and activation module: S2-1, by sending a request to the server system for the recipe acquisition request, the latest integrated recipe package is requested, and after receiving it, the integrated recipe package is set as a candidate integrated recipe package.

[0040] S2-2, the signature verification result is obtained by applying signature verification measures to R_bytes and recipe_sig of the candidate integrated recipe package.

[0041] S2-3, By employing static compileability verification measures on the candidate integrated recipe package, the following verification items are performed: Only precondition expressions are allowed to use a limited set of predicates; A sequential state machine has at least an initial state and a final state; The state transition condition is a decisionable condition; The set of rejection reason codes is a finite enumeration and there are no missing keys in the mapping table from rejection reason codes to action.

[0042] Path verification passed: When both signature verification and static compileability verification pass, the desktop system activates the candidate integration recipe package to form the activated integration recipe package, and sets the previously activated integration recipe package as the previous valid integration recipe package.

[0043] Path where verification fails: When either signature verification or static compileability verification fails, the desktop system rolls back and activates the previous valid integrated recipe package, and writes the failure reason code to the "Recipe Verification Failure Event" in the local log and event ledger.

[0044] Step S3: The desktop system parses and activates the integrated recipe package and generates satisfiability reachability relations. The desktop system completes the construction of the constraint session graph and the calculation of satisfiability and reachability relationships by executing the constraint compilation and reachability determination module. S3-1, by parsing the business system description record table of the activation integrated formula package, a set of nodes with business systems as nodes is obtained.

[0045] S3-2, by using edge construction measures on the "precondition expression set and jump constraint parameters" in the activation integrated recipe package, a constraint session graph with the "precondition expression set and jump constraint" as edge constraints is generated.

[0046] S3-3 uses configuration measures to limit the path enumeration depth to no more than 3 hops by adopting a step-by-step truth-checking measure for all precondition expressions on each path; when all expressions on a path are true, the output is "reachable"; otherwise, the output is "not reachable", forming a binary reachability relationship.

[0047] The path enumeration depth is determined by the desktop system based on the statistical value of the number of portal entry points; when the number of entry points does not exceed 50, 3 hops are used, otherwise 2 hops are used to ensure that the calculation is executable.

[0048] Step S4: The desktop system generates a verifiable credential package and calculates the chain digest. The desktop system generates a verifiable credential package by executing the credential management module: S4-1 uses a claim aggregation method on the client authentication results to form a claim set, which includes at least the user identifier, organization identifier, role set, permission scope set, and expiration time.

[0049] S4-2, By adopting deterministic measures on the binding factor, a binding factor is generated. The binding factor is taken as the digest value of the unique identifier on the device side or the digest value of the certificate serial number, and written into the verifiable credential package.

[0050] S4-3: By concatenating the recipe version identifier, user identifier, token set, declaration set, and binding factor in a deterministic order and performing a hash operation, a credential package digest is obtained and written into the verifiable credential package.

[0051] Deterministic order: First output recipe_ver, then output user identifier, then output token strings in fixed index order of token set, then output "key=value" strings in lexicographical order of declared field keys, and finally output binding factor.

[0052] Step S5: When a user triggers the target entry point, two judgments are performed and a branch is processed. The desktop system executes an entry point verification and handling module to determine the target entry point triggered by the user: S5-1 uses a table lookup method on the ingress route identifier to locate the target business system identifier and the target path, and reads the target business system permission scope set.

[0053] S5-2 obtains the reachability determination result by reading the reachability relation of satisfiability, and outputs either pass or fail.

[0054] S5-3: The consistency determination result is obtained by calculating the intersection of the permission scope set in the verifiable credential package and the permission scope set of the target business system; the determination is passed when the intersection is not empty, and the determination is failed when the intersection is empty.

[0055] Path determination: When reachability and consistency are both determined to be successful, the desktop system allows continued access and proceeds to step S6.

[0056] Path failure determination: When either the reachability determination or the consistency determination fails, the desktop system determines the action based on the rejection reason code and action mapping limited by the activated integrated recipe package. The action values ​​are limited to: re-fetch the integrated recipe package, re-authenticate, roll back to the previous valid integrated recipe package, trigger the sequence completion process, and prohibit ticket application. The rejection reason code and action entry are displayed at the top of the interface.

[0057] Step S6: When a ticket is needed, request a one-time link ticket and perform a sequential state transition determination. When the activation of the integrated recipe package indicates that a one-time link ticket is required, the desktop system completes the ticket request by executing the ticket interaction and sequence control module: S6-1, the desktop system submits ticket application parameters to the server system. The ticket application parameters shall carry at least the following: recipe version identifier, target business system interface contract summary, voucher package summary, sequence constraint identifier and current sequence status.

[0058] S6-2, the server system performs formula version permission verification, interface contract digest consistency verification, and sequence status permission verification on the invoice application parameters by executing the invoice issuance process.

[0059] Path verification passed: When all three verifications pass, the server system issues a one-time link ticket and returns it. The ticket carries a single-use flag (use_once) and a validity period (ott_ttl) ranging from 30 seconds to 300 seconds. The desktop system performs a sequential state transition determination locally. If the determination passes, it attaches the one-time link ticket to the target request and proceeds to step S7.

[0060] Validation failure path: When any of the three validations fails, the server system returns a rejection reason code; the desktop system displays the rejection reason code and the entry point for the handling action at the top of the interface, and proceeds to step S8 or executes the mapped handling action.

[0061] Step S7: Perform business access and write to the event ledger The desktop system initiates a target request and receives a response by accessing the target business system via a page or API call; and generates a receipt summary and idempotent event key, which are then written to the event ledger in the following manner: S7-1, by concatenating the target path, response status code and response body digest in a deterministic order and then performing a hash operation, the receipt digest resp_digest is obtained.

[0062] S7-2, the time window width W is set by configuration measures, with W ranging from 10 seconds to 120 seconds; the starting timestamp ts_window of the time window is obtained by rounding down the client timestamp ts_client.

[0063] S7-3 obtains the idempotent event key event_key by performing a hash operation on the user identifier, business system identifier, target path, and ts_window.

[0064] S7-4 writes event_key, resp_digest, uid, app_id, target_path, recipe_ver, and ts_client into the event ledger.

[0065] Idempotent write via the following path: When the same event_key does not exist in the event ledger, a new write is performed.

[0066] Idempotent writes do not pass through paths: When the same event_key exists in the event ledger, the old record is overwritten and updated only if the ts_client of the new record is greater than the ts_client of the old record; otherwise, the old record remains unchanged.

[0067] Step S8: Closed-loop processing of offline accounting and compensation upload The desktop system uses the event ledger and compensation synchronization module to enable offline accounting and compensation uploads after network recovery. S8-1: By taking measures to detect the network status, when the network is unavailable, the offline_flag is set to true and the accounting in step S7 continues.

[0068] S8-2, when network recovery is detected, a set of records to be uploaded is generated by selecting records with offline_flag=true and upload_state=to be uploaded by adopting construction measures on the compensation upload queue.

[0069] S8-3 uses a decision-making mechanism to restrict the enqueueing constraints of the compensation queue to enqueueing only when the sequential state machine of the corresponding record is in the completed state; if the enqueueing constraints are not met, the sequential completion process is triggered.

[0070] S8-4, perform compensated uploads in batches, with the batch size B ranging from 50 to 500 records; the batch size is calculated by the desktop system based on the maximum size of a single request body and the maximum available local memory, and then trimmed to the above range.

[0071] S8-5: When an upload conflict occurs, perform conflict determination according to the conflict determination conditions, which are limited to the same idempotent event key and different receipt digests; and execute the conflict handling rules according to the enumeration value issued by the activation integration recipe package, which are limited to "based on the newer client timestamp" or "based on the server authoritative receipt". After the handling is completed, update the upload_state of the corresponding record in the event ledger.

[0072] Example 2 provides a processing path for formula rollback and prohibition of invoice application in an enterprise portal integration method based on a custom client.

[0073] Step S1: Recipe verification failure triggers rollback When the desktop system fails to perform signature verification or static compileability verification on a candidate integrated recipe package, it rolls back and activates the previous valid integrated recipe package, and writes the failure reason code to the top display area of ​​the interface. At the same time, the desktop system triggers the action of re-fetching the integrated recipe package, and re-requests the candidate integrated recipe package at a period of T_pull, where T_pull ranges from 5 seconds to 60 seconds. T_pull is obtained by the desktop system by rounding up and trimming the P95 statistical value of recipe fetch round-trip latency over the past 7 days.

[0074] Step S2: Rejection of negotiable instrument triggers prohibition of negotiable instrument application. When the server system verifies the parameters of the invoice application and returns a rejection reason code, and the action for activating the integrated formula package is mapped to "prohibit invoice application", the desktop system writes the target business system identifier into the local prohibition list and sets a prohibition deadline. During the prohibition deadline, the desktop system will no longer initiate invoice applications for the target entry point, but will directly display the rejection reason code and the action entry point at the top of the interface. The action entry points include "re-authenticate" and "re-fetch integrated formula package".

[0075] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for integrating an enterprise portal based on a custom client, characterized in that, The method is executed collaboratively by a desktop system that serves as a unified user entry point and a server system that provides recipe publishing and invoice issuance capabilities. The server system interacts with enterprise business systems and the enterprise service bus. The desktop system serves as the unified front-end entry point for the client portal system, providing the portal entry interface and supporting access to business pages. This is used to display the activated recipe version identifier, online status, and number of offline queue entries at the top of the interface, and to display the rejection reason code and action entry when a judgment fails or a ticket is rejected.

2. The enterprise portal integration method based on a custom client according to claim 1, wherein the desktop system further executes the following modules when executing the method: The recipe acquisition and activation module is used to acquire the integrated recipe package from the server system and perform signature verification and static compilability verification on the integrated recipe package. When the verification passes, the integrated recipe package is activated. When the verification fails, the process is rolled back and the previous valid integrated recipe package is activated. When both signature verification and static compileability verification pass, the candidate integration recipe package is activated; when either signature verification or static compileability verification fails, the process reverts and activates the previous valid integration recipe package. The constraint compilation and reachability determination module is used to perform constraint compilation on the set of precondition expressions obtained by parsing the activation integration recipe package and the sequential state machine definition, construct the constraint session graph and calculate the satisfiability reachability relationship; The credential management module is used to perform declaration aggregation and binding factor determination on the client authentication results, generate verifiable credential packages, and calculate credential package digests; The entry verification and handling module is used to perform an reachability determination based on the satisfiability reachability relationship and a consistency determination based on the verifiable credential package and the permission scope of the target business system when a user triggers the target entry. If both determinations pass, access is allowed to continue. If either determination fails, a handling action is performed based on the rejection reason code and handling action mapping defined by the activation integration recipe package. The ticket interaction and sequence control module is used to submit ticket application parameters to the server system and receive the one-time link ticket when the activation of the integrated recipe package indicates that a one-time link ticket is required. It then performs state transition determination according to the sequence state machine. If the determination passes, the one-time link ticket is attached to the target request. If the determination fails, the sequence completion process is triggered. The threshold value X for triggering the completion process ranges from 30 seconds to 300 seconds. The maximum number of completions N_max ranges from 1 to 5 times. When the completion is successful, the sequence state machine enters the allow issuance state or the termination state. When the completion fails, the processing action defined by the activation of the integrated recipe package is executed. The event ledger and compensation synchronization module is used to generate a receipt summary and idempotent event key and write them to the event ledger after the target request is completed. When the network is unavailable, it performs offline accounting. When the network is restored, it performs compensation upload in batches and completes the conflict handling closed loop according to the conflict handling rules defined by the activated integrated recipe package.

3. The enterprise portal integration method based on a custom client according to claim 1, wherein the server system is used to receive recipe acquisition requests and invoice application requests submitted by the desktop system, and execute: Recipe release processing is used to generate and distribute integrated recipe packages containing recipe version identifiers, recipe signatures, and recipe serialization byte sequences; Contract registration processing is used to register the summary of contracts at the business system interface and provide a basis for contract consistency verification in the invoice issuance processing. The ticket issuance process is used to perform recipe version permission checks, interface contract digest consistency checks, and sequence status permission checks on the ticket application parameters. When the checks pass, a one-time link ticket is issued; when the checks fail, a rejection reason code is returned. The one-time link ticket carries a single-use flag (use_once) and has a validity period (ott_ttl) ranging from 30 to 300 seconds.

4. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, The integrated recipe package must contain at least the following fields: recipe version identifier (recipe_ver), business system description record table, precondition expression set, sequential state machine definition, rejection reason code set, rejection reason code to disposal action mapping table, recipe serialization byte sequence (R_bytes), and recipe signature (recipe_sig); wherein the business system description record table must contain at least the business system identifier, entry route identifier, permission scope set, interface contract summary, and jump constraint parameters.

5. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, When the recipe acquisition and activation module performs static compilability verification on the integrated recipe package, it performs at least the following verification items: Verification of precondition expressions is only permitted using a set of limited predicates; the set of limited predicates consists of at least the following predicates: token existence predicate has_token(app_id), permission scope inclusion predicate scope_has(scope), binding factor consistency predicate bind_ok(factor), recipe version consistency predicate ver_eq(recipe_ver), and interface contract digest consistency predicate contract_eq(contract_hash); For a sequential state machine, at least an initial state and a final state must be checked. Perform verification on state transition conditions that are decisionable conditions; Perform a check if the set of rejection reason codes is a finite enumeration and if there is no missing key in the mapping table from rejection reason codes to action.

6. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, When constructing the constraint session graph, the constraint compilation and reachability determination module uses the business system as the node and the "precondition expression set and jump constraint" as the edge constraint; the satisfiability reachability relationship is obtained by judging the truth of all precondition expressions on the path one by one, and outputting the binary reachability result.

7. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, When the credential management module generates a verifiable credential package, it writes at least: a token set, a declaration set, and a binding factor; the declaration set writes at least the user identifier, organization identifier, role set, permission scope set, and expiration time; the credential package digest is obtained through chained digest calculation. The chain digest is obtained by performing a hash operation after concatenating the recipe version identifier, user identifier, token set, declaration set, and binding factor in a deterministic order.

8. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, The entry verification and processing module performs two checks when a user triggers the target entry, and these checks satisfy the following conditions: Reachability is determined by the satisfiability of the reachability relation, and the output is either pass or fail. The consistency determination is obtained by calculating the intersection of the permission scope set in the verifiable credential package and the permission scope set of the target business system. The determination is successful when the intersection is not empty, and unsuccessful when the intersection is empty. When any judgment fails, the action value is limited to: re-fetching the integrated formula package, re-authenticating, rolling back to the previous valid integrated formula package, triggering the sequence completion process, and prohibiting ticket application, and is determined by the rejection reason code to the action mapping table.

9. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, The invoice application parameters submitted by the invoice interaction and sequence control module to the server system shall include at least: recipe version identifier, target business system interface contract summary, voucher package summary, sequence constraint identifier and current sequence status.

10. The enterprise portal integration method based on a custom client according to claim 1, characterized in that, When the event ledger and compensation synchronization module generates an idempotent event key, it is calculated using the user identifier, business system identifier, target path and time window start timestamp, wherein the time window width ranges from 10 seconds to 120 seconds. When the same idempotent event key exists in the event ledger, the idempotent overwrite rule is limited to: the old record is overwritten and updated only if the client timestamp of the new record is greater than the client timestamp of the old record; otherwise, the old record remains unchanged. When the network is restored, compensation uploads are performed in batches, with the batch size ranging from 50 to 500 records. The enqueue constraint for the compensation queue is limited to allowing enqueue uploads only when the sequential state machine of the corresponding record is in the completed state. The conflict determination condition is limited to identical idempotent event keys and different receipt digests. The conflict handling rule is limited to "based on the newer client timestamp" or "based on the server's authoritative receipt," and is determined by the enumeration value issued by the activation integration recipe package.

Images