A method and system for dynamic rendering and data loop of interactive cards

Abstract

The embodiment of the application discloses a kind of dynamic rendering and data closed loop method and system of interactive card, it is related to instant messaging technical field.The method defines interactive card template by domain-specific language, including component type, variable placeholder, check rule and callback mapping relationship;When the conversation state machine flows to the trigger node, the actual data in context is filled to template by back end, and is issued to visitor end in JSON format;Visitor end dynamically loads and shows corresponding component in rendering sandbox isolated with main document stream, generates structured event after user operation and submits to safety transfer gateway;Gateway authenticates, checks and format conversion to event, to call target enterprise business system with the identity of agent, write response result after desensitization to conversation context, and trigger corresponding callback.The scheme effectively reduces the analysis error rate of free text interaction, avoids the security risk of front-end direct connection enterprise business system, and guarantees the continuity and consistency of conversation.

Description

Technical Field

[0001] This invention relates to the field of instant messaging technology, and in particular to a method and system for dynamic rendering and data closure of interactive cards. Background Technology

[0002] Instant messaging technology has been widely applied in scenarios such as enterprise customer service, online finance, and medical appointment booking. Represented by workflow orchestration platforms and various chatbots, existing systems use workflow orchestration to call external application programming interfaces (APIs) to perform operations such as information retrieval and status updates, thus expanding upon the limitations of traditional chatbots that can only conduct text-based conversations.

[0003] Currently, the core interaction between chatbots and users is based on natural language-based dialogue. In such systems, when users provide feedback or report information to businesses, they typically use free text input. The system then needs to use natural language processing or large language models to perform intent recognition and entity extraction on the user input. Some existing solutions allow front-end components to directly call the interfaces of enterprise business systems to query and submit data. Furthermore, in multi-step business processes involving appointments, applications, etc., users often need to repeatedly switch between instant messaging chat windows and external form pages.

[0004] However, the above-mentioned existing technical solutions have the following technical problems:

[0005] First, free text-based interaction methods rely on natural language processing or large language models for semantic parsing, which results in high parsing error rates, high computational resource consumption, significant response delays, and issues such as missing fields and inconsistent formats during data conversion.

[0006] Second, the practice of front-end components directly calling enterprise business system interfaces poses security risks, including authentication token leakage, cross-site request forgery, server-side request forgery, and other attack risks. Furthermore, sensitive enterprise data flows directly through the front end, making it difficult to meet data protection compliance requirements.

[0007] Third, in scenarios involving multi-step business processes, users need to switch repeatedly between the instant messaging session window and external pages, which disrupts the continuity of the session, easily leading to user churn and making it difficult to guarantee business conversion rates. Summary of the Invention

[0008] In view of this, embodiments of the present invention provide a method and system for dynamic rendering and data closure of interactive cards, in order to solve the problems in the prior art caused by the use of free text interaction, such as high semantic parsing error rate, large consumption of computing resources, data security and attack surface expansion caused by direct front-end connection to enterprise business systems, and disruption of session continuity and low business conversion rate caused by repeated switching between session windows and external pages.

[0009] In a first aspect, embodiments of the present invention provide a method for dynamic rendering and data closure of interactive cards, including:

[0010] In the management backend of the workflow orchestration platform, interaction card templates are defined using a domain-specific language; wherein, the interaction card template includes component type declarations, variable placeholders, validation rules, and association mappings with callback interfaces;

[0011] When the state machine of the session context transitions to the trigger node, the backend of the process orchestration platform replaces the variable placeholders in the interaction card template with the actual data in the session context, serializes the replaced template into JSON data format, and sends it to the visitor's end.

[0012] The visitor client dynamically loads the corresponding user interface component in a rendering sandbox independent of the main document flow based on the component type declaration carried in the JSON data, so as to construct an interactive user interface component; after the interactive user interface component responds to the user operation, it generates a structured operation event, which contains the user operation data collected by the visitor client.

[0013] The visitor client submits the structured operation event to the backend security relay gateway of the process orchestration platform;

[0014] After receiving the structured operation event, the backend security relay gateway performs session-level authentication, performs field validation on the user operation data according to the validation rules, and maps the user operation data into the data interface format required by the target enterprise business system, and initiates a call request to the target enterprise business system as a proxy of the backend security relay gateway.

[0015] The backend security relay gateway receives the response result returned by the target enterprise business system in response to the call request, performs anonymization processing on the response result and writes it back to the session context, and triggers the callback interface according to the association mapping of the callback interface defined in the interaction card template to complete the data loop.

[0016] Furthermore, the dynamic loading of the corresponding user interface components within a rendering sandbox independent of the main document flow includes:

[0017] The rendering sandbox is constructed using a shadow document object model;

[0018] Define the interactive user interface components according to the web component specification and dynamically load them into the rendering sandbox;

[0019] The shadow document object model isolates the stylesheets and script execution environment of the interactive user interface components from the stylesheets and script execution environment of the main page on the visitor's end.

[0020] Furthermore, the step of initiating a call request to the target enterprise business system as a proxy of the backend security relay gateway includes: initiating the call request carrying enterprise-level authentication credentials, wherein the enterprise-level authentication credentials are not visible to the visitor client;

[0021] The process of desensitizing the response result includes removing sensitive fields from the response result.

[0022] Furthermore, the JSON data also carries card identifiers and session identifiers;

[0023] After the visitor receives the JSON data, it also includes:

[0024] The visitor client maintains the association between the interactive card and the session context based on the card identifier and the session identifier;

[0025] The structured operation event generated by the visitor terminal also includes the session identifier and the card identifier.

[0026] Optionally, the component type is a file upload component; the visitor terminal collects user operation data, including:

[0027] After the user selects a file through the file upload component, the visitor terminal uploads the file to the backend attachment storage interface of the workflow orchestration platform.

[0028] The visitor terminal receives a temporary access locator with a timestamp signature returned by the backend attachment storage interface, uses the temporary access locator as part of the user operation data, and generates the structured operation event.

[0029] Furthermore, after the visitor uploads the file to the backend attachment storage interface of the workflow orchestration platform, the process further includes:

[0030] The backend attachment storage interface uses the session identifier as the storage isolation identifier to store the file in the corresponding bucket of the object storage service;

[0031] The backend attachment storage interface configures an expiration cleanup policy for the object storage service. When the session corresponding to the session identifier ends, all files stored in the bucket corresponding to the session identifier are deleted.

[0032] Optionally, the component type is the time slot selector; the visitor terminal collects user operation data, including:

[0033] After the visitor terminal detects that the user has selected a date through the date picker, it generates a time slot query request carrying the date and submits the time slot query request to the backend security relay gateway.

[0034] The backend security relay gateway receives the time slot query request and, acting as a proxy, calls the reservation interface of the target enterprise's business system to obtain a list of available time slots.

[0035] The backend security relay gateway returns the list of available time slots to the visitor's client after de-identifying it.

[0036] The visitor terminal renders the selectable options of the time slot selector based on the anonymized list of available time slots.

[0037] Furthermore, before the backend security transit gateway anonymizes the list of available time slots and returns it to the visitor's client, the following steps are also included:

[0038] The backend security transit gateway caches the list of available time slots in the backend cache of the process orchestration platform and configures a time-to-live for the cache.

[0039] Furthermore, the associated mapping of the callback interface in the interactive card template also includes a callback mode configuration, which indicates whether the callback interface adopts a synchronous callback mode or an asynchronous callback mode.

[0040] When the callback mode is configured as synchronous callback mode, the backend security relay gateway blocks and waits for the target enterprise business system to return the response result before returning to the visitor terminal;

[0041] When the callback mode is configured as asynchronous callback mode, the backend security relay gateway will temporarily store the response result and then push it asynchronously through the callback interface.

[0042] Secondly, embodiments of the present invention provide a dynamic rendering and data closed-loop system for interactive cards, the device comprising:

[0043] The interaction card definition engine, deployed in the management backend of the process orchestration platform, is configured to define interaction card templates using a domain-specific language; wherein, the interaction card template includes component type declarations, variable placeholders, validation rules, and association mappings with callback interfaces;

[0044] The session context manager, deployed on the backend of the process orchestration platform, is configured to maintain the session lifecycle based on a finite state machine. When the state machine of the session context transitions to the trigger node, the variable placeholders in the interaction card template are replaced with the actual data in the session context. The replaced template is then serialized into JSON data format and sent to the visitor's end.

[0045] A dynamic rendering engine, deployed on the visitor's end, is configured to dynamically load corresponding user interface components in a rendering sandbox independent of the main document flow based on the component type declaration carried in the JSON data, in order to construct interactive user interface components and encapsulate user operations as structured operation events; the structured operation events include user operation data collected by the visitor's end and session identifiers carried in the JSON data;

[0046] A secure relay gateway, deployed on the backend of the process orchestration platform, is configured to receive the structured operation events submitted by the visitor client, perform session-level authentication, perform field validation on the user operation data according to the validation rules, and map the user operation data into the data interface format required by the target enterprise business system, and initiate a call request to the target enterprise business system as a proxy; the visitor client is restricted to submitting events only to the secure relay gateway;

[0047] The data closed-loop module, deployed on the backend of the process orchestration platform, is configured to receive the response result returned by the target enterprise business system in response to the call request, perform anonymization processing on the response result and write it back to the session context, and trigger the callback interface according to the association mapping of the callback interface defined in the interaction card template.

[0048] Furthermore, the system also includes:

[0049] The attachment storage manager, deployed on the backend of the process orchestration platform, is configured to receive files uploaded by the visitor, store the files in the corresponding bucket of the object storage service using the session identifier as the storage isolation identifier, return a temporary access locator with a timestamp signature to the visitor, and configure an automatic expiration and cleanup policy for the object storage service.

[0050] The data report aggregator, deployed on the backend of the process orchestration platform, is configured to receive the interaction result data pushed by the callback interface, and perform real-time statistics and multi-dimensional report generation.

[0051] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing computer program instructions thereon, wherein the computer program instructions, when executed by a processor, implement the dynamic rendering and data closure method for interactive cards described in the first aspect.

[0052] The technical solution provided by the embodiments of the present invention has the following beneficial effects:

[0053] By replacing free text input with structured interactive cards, user actions directly generate structured operation events containing user operation data, and directly perform field validation on the user operation data without the need for semantic parsing through natural language processing or large language models. This avoids the semantic ambiguity and parsing errors caused by free text interaction, and significantly reduces the consumption of computing resources and response latency.

[0054] After performing session-level authentication, field validation, and data format conversion through the backend security relay gateway, it initiates a call request to the target enterprise business system as a proxy. At the same time, the visitor client is configured to prohibit direct hypertext transfer protocol requests to the enterprise business system, making the enterprise-level authentication credentials invisible to the visitor client. This eliminates the security risks such as authentication credential leakage, cross-site request forgery, and server-side request forgery caused by direct connection to the enterprise business system from the front end at the architectural level, and reduces the attack surface.

[0055] By completing the entire process of interactive card template definition, variable replacement, serialization and distribution, dynamic rendering, user operation collection, structured submission, secure proxy forwarding, response de-identification and write-back, and callback interface triggering within the instant messaging session, users do not need to leave the current session window to jump to an external page during the entire business interaction process. This maintains the continuity of the session, avoids user churn caused by page jumps, and improves business conversion rate. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are 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.

[0057] Figure 1 This is a schematic diagram of the network architecture adapted to the embodiments of the present invention;

[0058] Figure 2 This is an interactive schematic diagram of a dynamic rendering and data closure method for interactive cards provided in Embodiment 1 of the present invention;

[0059] Figure 3This is a schematic diagram of data flow in a file upload component provided in Embodiment 2 of the present invention;

[0060] Figure 4 This is a schematic diagram of the dynamic query process of a time slot selector provided in Embodiment 3 of the present invention;

[0061] Figure 5 This is a schematic diagram of a dynamic rendering and data closed-loop system for interactive cards provided in Embodiment 4 of the present invention. Detailed Implementation

[0062] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0063] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0064] First, the network architecture to which this embodiment of the invention is adapted will be introduced. See [link to relevant documentation]. Figure 1 The architecture includes: a process orchestration platform 101, a visitor terminal 102, and the target enterprise business system 103. Among them:

[0065] The process orchestration platform 101 includes a management backend 1011 and a backend 1012. The management backend 1011 is used for operations personnel to define interactive card templates using a domain-specific language. The backend 1012 is used to perform session context management, variable replacement, template serialization and distribution, security proxy relay, data desensitization and write-back, and callback interface triggering.

[0066] The visitor terminal 102 communicates in real time with the backend 1012 of the process orchestration platform 101 through a message channel. It is used to receive the distributed interactive card data and encapsulate user operations into structured operation events and submit them to the backend 1012.

[0067] The target enterprise business system 103 is deployed independently of the process orchestration platform 101, and the visitor terminal 102 is architecturally prohibited from communicating directly with the target enterprise business system 103.

[0068] In the network architecture, all data requests from the visitor terminal 102 to the target enterprise business system 103 are forwarded as proxies by the backend 1012 of the process orchestration platform 101. During the forwarding process, the backend 1012 performs session-level authentication, field validation, interface mapping conversion, and response de-identification processing, thereby realizing a security architecture for the frontend to access the target enterprise business system 103 with zero permissions. The complete data loop is completed by writing the response de-identification back to the session context and triggering the callback interface.

[0069] The technical solution of the present invention will be described in detail below through various embodiments.

[0070] Example 1

[0071] This embodiment provides a method for dynamic rendering and data closure of interactive cards, applicable to scenarios requiring instant messaging interaction such as online customer service, financial transactions, healthcare services, and government services. It is particularly suitable for enterprise-level business interactions within enterprise customer service systems, banking systems, hospital registration systems, or government service platforms, where structured information collection, confirmation, and submission with users are conducted via instant messaging windows. See also... Figure 2 The method includes the following steps 201-206.

[0072] Step 201: In the management backend of the process orchestration platform, define the interaction card template using a domain-specific language.

[0073] Specifically, operations personnel can define interaction card templates in the management backend interface of a workflow orchestration platform (such as the Delight platform) using a Domain Specific Language (DSL) editor. This DSL editor provides a visual configuration interface, allowing operations personnel to describe the card's interface structure, interactive behavior, and data flow rules using declarative syntax. The interaction card template must at least include component type declarations, variable placeholders, validation rules, and the mapping between the template and callback interfaces.

[0074] The component type declaration defines the types of user interface components included in the interactive card. Specifically, operators can declare one or more components in the template according to the needs of actual business scenarios. These component types include, but are not limited to: radio buttons, checkboxes, text input boxes, file upload components, date pickers, time slot pickers, phone call buttons, and any combination thereof. For example, in an information confirmation scenario, the template can declare a set of radio buttons for users to select "Yes / No / Other"; in an appointment registration scenario, the template can declare a date picker and a time slot picker for users to select the appointment date and time slot; in a document submission scenario, the template can declare a file upload component for users to upload certificates or proof documents. Through component type declarations, the template can adapt to different business interaction needs, allowing the same rendering engine to render diverse interactive interfaces based on different template definitions.

[0075] The variable placeholders are used to mark content that needs to be dynamically replaced in the template. Specifically, operators can define variable placeholders using double curly braces (e.g., {{variableName}}) in the template's description text, component tags, or component attribute values. At runtime, the backend of the workflow orchestration platform replaces these placeholders based on the actual data stored in the current session context. For example, in a transfer confirmation card template, {{payeeName}} and {{amount}} can be used to represent the recipient's name and the transfer amount, respectively. Before issuing the template, the backend extracts the corresponding actual values ​​(such as "Zhang San" and "5000.00") from the session context and replaces them, thereby achieving personalized display of the same template in different sessions or different business nodes.

[0076] The validation rules define the data constraints that users must meet before submitting data. Specifically, operators can configure corresponding validation rules for each component or field requiring validation in the template. These validation rules include, but are not limited to: whether a field is required, regular expressions for input content formatting, text length limits, numerical value ranges, file type restrictions, and file size limits. For example, for an ID card number input field, regular expression validation can be configured to ensure that the user's input conforms to the encoding rules of the ID card number; for a file upload component, allowed file types (e.g., limited to JPEG and PNG formats) and maximum file size (e.g., no more than 5MB) can be configured. It should be noted that the validation rules are configured to be executed at both the front-end visitor interface and the back-end security gateway. Front-end validation enhances the real-time feedback experience of user interaction, while back-end validation serves as the final data security barrier, intercepting malicious submissions that bypass front-end validation.

[0077] The association mapping of the callback interface is used to define the backend service address and invocation mode that the interactive card needs to trigger after the user submits data. Specifically, the operators can configure the Uniform Resource Locator (URL) of the callback interface in the template to instruct the backend of the process orchestration platform to push the interaction result data to which downstream system (e.g., enterprise resource planning system, customer relationship management system, hospital information system, reporting system, etc.) after completing the processing and transformation of the user operation data. The association mapping also includes the configuration of the callback mode, which includes synchronous callback mode and asynchronous callback mode: when configured as synchronous callback mode, the backend security transit gateway of the process orchestration platform blocks and waits for the target enterprise business system to return a response result after calling the target enterprise business system interface, and returns the response result to the visitor after receiving the response result; when configured as asynchronous callback mode, the backend security transit gateway temporarily stores the response result after calling the target enterprise business system interface and pushes it asynchronously to the downstream system through the callback interface.

[0078] Using the above method, operations personnel only need to define interactive card templates in the management backend via DSL to quickly generate interactive cards that meet business requirements, without writing front-end or back-end interface code. The defined interactive card templates are stored in the configuration database of the workflow orchestration platform in the form of structured data, which can be referenced in subsequent session transitions and card distribution steps.

[0079] Step 202: When the state machine of the session context transitions to the trigger node, the backend of the process orchestration platform replaces the variable placeholders in the interaction card template with the actual data in the session context, serializes the replaced template into JSON data format, and sends it to the visitor's end.

[0080] Specifically, the backend of the workflow orchestration platform can maintain a session context manager, which independently maintains a set of session context data for each instant messaging session. The session context is a data structure used to store all state information and business data of the current session throughout its entire lifecycle, including but not limited to: session identifier, user identity information, the current workflow node, the result data of the previous interaction, and business data fields generated by each workflow node (e.g., transfer amount, recipient name, appointment date, order number, etc.). The session context is continuously updated as the session progresses and user interactions are completed, and subsequent workflow nodes can read any data fields they need from it.

[0081] The session context manager also maintains a session lifecycle management mechanism based on a finite state machine. This finite state machine defines the sequence of states a session experiences throughout the complete lifecycle of an interactive card, from triggering to completion. In this embodiment, the finite state machine includes at least the following states and their transition paths: session active, card awaiting trigger, card rendered, user interaction in progress, data submitted, backend processing in progress, target enterprise business system responding, and returning to the session active state after writing back the context, forming a closed loop. The session context manager drives the state machine to transition between states based on the execution progress of the workflow orchestration and the user's actions, ensuring that each session is in a defined state at any given time and providing contextual data support for subsequent state transitions.

[0082] The trigger node refers to a node in the business process defined by the workflow orchestration platform. Workflow orchestration platforms (such as Delight) allow operations personnel to predefine business processes using visual workflow orchestration tools. These business processes consist of multiple nodes arranged sequentially; each node can be a message sending node, a conditional judgment node, a card issuance node, an API call node, etc. When the session context's state machine transitions to the card issuance node, that node is considered the trigger node. At this point, the workflow orchestration platform's backend determines the interactive card template to be issued based on the node's configuration information and reads the corresponding template definition data from the configuration database.

[0083] When the state machine of the session context transitions to the trigger node, the backend of the workflow orchestration platform first retrieves the corresponding interaction card template from the configuration of that trigger node. Then, the backend iterates through all variable placeholders (e.g., {{variableName}} defined using double curly braces) in the interaction card template, searching for the actual data value corresponding to each placeholder name in the current session context. Specifically, when performing variable replacement, the backend parses each variable placeholder in the template, using the variable name in the placeholder as the key, and performs a matching query in the session context. If a corresponding data value is found, the placeholder is replaced with that data value; if not, the original placeholder can be retained or replaced with an empty value according to the configuration, and a log is recorded for operations personnel to investigate. For example, in a transfer confirmation scenario, the interactive card template contains the descriptive text "You are transferring {{amount}} yuan to {{payeeName}}, please confirm." The backend extracts the value "Zhang San" for the "payeeName" field and the value "5000.00" for the "amount" field from the current session context. After replacing the placeholders with their corresponding actual values, the descriptive text becomes "You are transferring 5000.00 yuan to Zhang San, please confirm." Through this variable substitution mechanism, the same interactive card template can display personalized content in different sessions or different business stages without needing to define different templates for each situation.

[0084] After the variable replacement is completed, the backend of the workflow orchestration platform serializes the replaced interactive card template into object representation (JavaScript, JSON) data format. This JSON data follows a predefined JSON Schema specification, and its structure includes the card's type identifier, card identifier, title, description text, a list of included UI components and their respective types, attributes, validation rules, and callback interface mappings. Through this standardized serialization method, the interactive card template is converted into a platform-independent, structured standard data format, facilitating transmission and parsing across different visitor terminals (e.g., web, mobile), thus ensuring universality and cross-platform compatibility. Optionally, the JSON data also carries a card identifier and a session identifier. The card identifier uniquely identifies the current interactive card instance, and the session identifier identifies the instant messaging session to which the current interactive card belongs.

[0085] Finally, the backend of the workflow orchestration platform will send the serialized JSON data to the target visitor client via a message channel. A message channel is a long-lived connection (such as a WebSocket connection or an HTTP-based long polling connection) built on top of an instant messaging session, used to enable real-time bidirectional communication between the server and the visitor. The backend encapsulates the serialized JSON data into a message and sends it to the visitor client via the message channel. This JSON data conforms to a predefined JSONSchema specification, and the visitor client can parse the JSON data upon receiving the message for subsequent dynamic rendering. Through the message channel's delivery mechanism, interactive cards can be displayed in real-time within the user's current instant messaging session window without the user needing to actively refresh the page or access new links, thus ensuring the immediacy of the interaction and the continuity of the session.

[0086] Step 203: Based on the component type declaration carried in the JSON data, the visitor client dynamically loads the corresponding user interface component in a rendering sandbox independent of the main document flow to construct an interactive user interface component; after the interactive user interface component responds to the user operation, it generates a structured operation event, which contains the user operation data collected by the visitor client.

[0087] Specifically, the visitor client refers to the client of the instant messaging session used by the user, which can take the form of a web page in a browser, a mobile application, or a mini-program. The visitor client receives JSON data from the backend of the workflow orchestration platform through a messaging channel. This data contains a complete structured description of the interactive cards. The visitor client has a built-in dynamic rendering engine that is responsible for parsing the received JSON data and converting it into a visual interface that the user can interact with.

[0088] The dynamic rendering engine first parses the card type identifier and card identifier in the JSON data to determine the unique identifier of the card to be rendered within the entire session context. The card identifier and session identifier carried in the JSON data are also used by the client to maintain the association between interactive cards and the session context: specifically, the client maintains a mapping table locally between card instances and their respective sessions based on the card identifier and session identifier. This ensures that subsequent generated structured operation events correctly carry the session identifier and card identifier, enabling the backend security gateway to accurately trace the session to which the operation belongs and the corresponding card instance after receiving the structured operation event, based on the session identifier and card identifier.

[0089] Then, the rendering engine iterates through the component list in the JSON data, reading the component type declared by each component and its corresponding attribute configuration. The dynamic rendering engine does not directly manipulate the Document Object Model (DOM) tree in the main document on the visitor's side, but performs all rendering operations within a rendering sandbox independent of the main document flow. The rendering sandbox is essentially a rendering container isolated from the main page, containing an independent DOM tree, independent stylesheet scope, and an independent script execution environment. In a preferred embodiment, the rendering sandbox is implemented using shadow DOM technology. The rendering sandbox built with shadow DOM has the following technical characteristics: stylesheets within the sandbox do not leak to the main document, and stylesheets in the main document do not intrude into the sandbox, achieving style isolation; the script execution environment within the sandbox is isolated from the script execution environment of the main page, script variables, functions, and event listeners defined within the sandbox do not pollute the global scope of the main page, and scripts on the main page cannot directly access the DOM nodes within the sandbox, achieving script isolation.

[0090] After constructing the rendering sandbox, the dynamic rendering engine dynamically loads the corresponding user interface components based on the component type declarations carried in the JSON data. In this embodiment, the user interface components are preferably defined according to the Web Components specification. Web Components are a W3C standard technology that allows developers to create reusable custom elements. Specifically, the dynamic rendering engine pre-registers Web Component classes corresponding to each component type, such as those corresponding to radio buttons. <ack-radio>Components, corresponding to the date picker <appointment-date>Components, and the corresponding file upload component <file-uploader>Components, corresponding to time slot selectors <time-slot-selector>Components, etc. When the rendering engine parses the type declaration of a component in the JSON data, it looks up the corresponding web component class based on the type declaration, dynamically loads the instantiated object of the web component into the rendering sandbox built by the shadow document object model, and initializes and assigns property values ​​to the web component according to the property configuration carried in the JSON data.

[0091] Through the architecture defined by web component specifications and rendered in isolation using the shadow document object model, each interactive card and its internal user interface components run in an independent rendering environment, completely isolated from the main page on the visitor's end. This ensures consistent style across different host pages and fundamentally eliminates the possibility of third-party scripts injecting malicious code or stealing user data through interactive cards. After the dynamic loading is completed, a complete interactive user interface component is presented in the visitor's instant messaging window, allowing users to perform various operations on this interface.

[0092] An interactive user interface component is configured to listen for all user interactions. Each time a user performs an action, the component captures the action and triggers corresponding event handling logic. This event handling logic converts the user's actions into a structured data format, generating a structured operation event. This structured operation event is a JSON-formatted data object containing the following fields: a session identifier (identifying the instant messaging session to which the current operation belongs), a card identifier (identifying the interactive card instance corresponding to the current operation), an operation type (identifying the type of operation performed by the user), and user operation data (carrying the specific data content input or selected by the user). The structured operation event also includes a session identifier and a card identifier, enabling the backend security gateway to accurately trace the source of the operation based on these identifiers in subsequent steps. By encapsulating user actions into structured operation events, the visitor client unifies the user's unstructured and diverse free-flowing actions into structured data objects with defined fields and data types.

[0093] Step 204: The visitor submits the structured operation event to the backend of the workflow orchestration platform.

[0094] Specifically, when an interactive user interface component responds to a user action and generates a structured operation event, the visitor client does not directly send this structured operation event to the target enterprise's business system, nor does it submit it as free text to a general message processing channel. Instead, it submits it to the backend of the workflow orchestration platform, specifically to the backend secure relay gateway. The backend secure relay gateway is an independent service module deployed on the backend of the workflow orchestration platform. As the sole communication intermediary between the visitor client and the target enterprise's business system, it is responsible for receiving, verifying, transforming, and forwarding all data requests sent from the visitor client to the target enterprise's business system.

[0095] Before submitting a structured operation event, the visitor can perform the following preprocessing operations on the structured operation event:

[0096] First, the visitor client verifies whether the required fields in the structured operation event are complete. Specifically, the visitor client checks whether the session identifier in the structured operation event exists and conforms to the preset format specifications (e.g., whether it is a valid UUID format or a custom session number format), whether the card identifier exists and matches the latest card identifier issued in the current session, and whether the user operation data is empty. If the required fields are missing or the format is incorrect, the visitor client does not perform the submission operation, displays an error message in the instant messaging session window, and guides the user to return and re-operate.

[0097] Second, the visitor adds a submission timestamp to the structured operation event. The submission timestamp is used to record the actual time when the user's operation occurs, so that the backend security transit gateway can sort requests, judge timeouts, and audit trace based on the time dimension in subsequent processing.

[0098] Third, the visitor client collects the visitor's device information or user agent information, and encapsulates the device information or user agent information as additional fields into the structured operation event. Device information includes, but is not limited to: device type (e.g., desktop, mobile, tablet), operating system version, browser type and version, etc. The visitor client submits the above device information or user agent information as additional fields to the backend security relay gateway, so that the backend security relay gateway can perform multi-dimensional security verification in the subsequent session-level authentication process, in combination with the device information or user agent information. For example, it can detect whether the same session identifier initiates requests from multiple different device information in an abnormally short period of time, thereby identifying possible session hijacking or malicious attack behavior.

[0099] It is important to note that the visitor client is architecturally configured to prohibit direct HTTP requests to the target enterprise's business systems. This constraint is ensured through mandatory isolation at the system architecture level: the visitor client's front-end code does not contain any interface addresses, authentication credentials, or access tokens of the target enterprise's business systems; simultaneously, all network requests from the visitor client are architecturally restricted to predefined interface addresses of the back-end security gateway of the workflow orchestration platform. Through this architectural design, the target enterprise's business system's interface addresses, authentication credentials, and access tokens are configured and maintained only within the back-end security gateway of the workflow orchestration platform, and are completely invisible to the visitor client.

[0100] After preprocessing, the visitor sends a POST request to the Uniform Resource Locator of the backend security gateway via Hypertext Transfer Security Protocol (HTTPS). The message body of the POST request contains complete JSON data of the structured operation event.

[0101] After the visitor submits a structured operation event to the backend security relay gateway, the visitor can detect the response status of the submitted operation and perform corresponding processing based on the response status. The specific processing process is as follows.

[0102] When the submission operation is successful, that is, when the visitor receives a submission success confirmation response (such as HTTP status code 202 Accepted) from the backend security relay gateway, the visitor ends the current submission process.

[0103] When a submission operation fails, the visitor identifies the corresponding fault type. Fault types include recoverable faults and non-recoverable faults.

[0104] When the fault type is recoverable, the visitor client executes a retry strategy. Recoverable faults include network timeouts (e.g., connection timeout or read timeout) and 5xx class server errors returned by the backend security gateway (e.g., HTTP status code 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout). When executing the retry strategy, the visitor client resubmits the structured operation event with increasing delay intervals (i.e., exponential backoff). Specifically, the visitor client waits for a first delay (e.g., 1 second) before the first retry. If the first retry fails, it waits for a second delay (e.g., 2 seconds) before the second retry. If it fails again, it waits for a third delay (e.g., 4 seconds) before the third retry, and so on, until the retry succeeds or a preset retry threshold (e.g., 3 times) is reached, at which point retrying stops.

[0105] When the fault type is unrecoverable, the visitor client will abandon the retry. Unrecoverable faults include 4xx client errors returned by the backend security gateway, specifically including but not limited to: invalid session identifier (e.g., HTTP status code 400 Incorrect Request Parameters or 401 Unauthorized), non-existent card identifier (e.g., HTTP status code 404 Not Found), and incorrect user operation data format (e.g., HTTP status code 422 Unprocessable Entity). After the visitor client abandons the retry, an error message will be displayed in the instant messaging window to guide the user to repeat the operation or contact customer service for assistance.

[0106] Step 205: After receiving the structured operation event, the backend performs session-level authentication, performs field validation on the user operation data according to the validation rules, and maps the user operation data into the data interface format required by the target enterprise business system, and initiates a call request to the target enterprise business system as a proxy.

[0107] Specifically, upon receiving a structured operation event, the backend security relay gateway first performs session-level authentication. Session-level authentication verifies whether the session currently submitting the structured operation event has legitimate operation permissions. The backend security relay gateway initiates an authentication request to the session context manager, submitting the session identifier and card identifier carried in the structured operation event to the session context manager to verify the following authentication conditions: the session identifier exists and is active; the card identifier matches the card identifier of the latest interactive card issued in the session context; the current state machine state of the session context allows the operation to be submitted; and the device information carried in the structured operation event matches the device information recorded in the session context. If all the above authentication conditions are met, the session-level authentication passes; if any authentication condition is not met, the backend security relay gateway rejects the submission and returns the corresponding error code and error message to the visitor.

[0108] After session-level authentication is successful, the backend security gateway performs field validation on the user operation data according to the validation rules defined in the interaction card template. Independent of the visitor's frontend validation, the backend security gateway re-executes the complete backend validation process. Specifically, the backend security gateway extracts user operation data from structured operation events and validates the data item by item according to the predefined validation rules in the interaction card template, including but not limited to: whether a field is required, whether the input format conforms to a regular expression, whether the text length is within the limit, whether the value is within the range, whether the file type is in the allowed list, and whether the file size exceeds the limit. If the user operation data passes all validation rules, the field validation passes; if any validation fails, the backend security gateway returns a validation failure error response to the visitor and refuses to forward the current submission to the target enterprise business system.

[0109] After field validation passes, the backend security gateway maps and converts the user operation data into the data interface format required by the target enterprise business system. Since different enterprise business systems may differ in interface protocols, data formats, field naming, and data types, the backend security gateway maintains an internal interface mapping configuration. This configuration specifies the mapping rules from the user operation data fields submitted from the front end to the target enterprise business system interface fields for each interactive card template. These mapping rules include, but are not limited to: field name mapping, data type conversion, data format conversion, fixed value injection, and field merging or splitting. Based on the interface mapping configuration, the backend security gateway reads the values ​​of each field from the validated user operation data, performs the conversion according to the mapping rules, and ultimately generates request body data that conforms to the data interface format required by the target enterprise business system.

[0110] After completing the interface mapping conversion, the backend security gateway initiates a call request to the target enterprise business system as its proxy. Specifically, the backend security gateway determines the Uniform Resource Locator (URL) and invocation method of the target enterprise business system based on the target address in the callback interface association mapping configured in the interaction card template. The backend security gateway authenticates and signs the call request using pre-configured enterprise-level authentication credentials (such as OAuth 2.0 tokens or application programming interface keys). These enterprise-level authentication credentials are configured and maintained only within the backend security gateway and are completely invisible to the visitor. When initiating the call request, the backend security gateway places the enterprise-level authentication credentials in the Hypertext Transfer Protocol (HTTP) request header and sends it along with the call request to the target enterprise business system. By initiating the call request as a proxy of the backend security gateway, all enterprise-level authentication credentials are maintained internally within the backend security gateway, achieving a security architecture where the frontend has zero-permission access to the target enterprise business system.

[0111] Step 206: The backend security relay gateway receives the response result returned by the target enterprise business system in response to the call request, performs anonymization processing on the response result and writes it back to the session context, and triggers the callback interface according to the association mapping of the callback interface defined in the interaction card template to complete the data closure.

[0112] Specifically, after initiating a call request to the target enterprise's business system, the backend security relay gateway waits for the target enterprise's business system to respond to the call request. The backend security relay gateway manages the waiting process through a pre-configured timeout control mechanism. If a response is received within the preset timeout threshold, subsequent processing begins; otherwise, a timeout error message is returned to the visitor.

[0113] After receiving the response, the backend security gateway performs data anonymization on it. Sensitive fields in the response are identified according to preset anonymization rules, including but not limited to complete ID card numbers, complete bank card numbers, mobile phone numbers, home addresses, medical diagnosis information, and account balances. The backend security gateway then performs anonymization operations on these sensitive fields according to the preset rules, including but not limited to complete hiding, partial hiding, format-preserving anonymization, and hash-based anonymization. Through this anonymization process, necessary business status information in the response is retained while ensuring that sensitive data is not exposed in plaintext to visitors or stored in logs.

[0114] After the anonymization process is complete, the backend security gateway writes the anonymized response back to the session context. Specifically, the backend security gateway sends a write-back request containing the session identifier and the anonymized response to the session context manager. The session context manager looks up the corresponding session context based on the session identifier, updates the anonymized response in key-value pairs to the session context's data storage area, and transitions the session context's state machine from "backend processing" to "target enterprise business system has responded." Through this write-back operation, the processing result of the target enterprise business system is persistently stored in the session context, available for subsequent process nodes or subsequently issued interaction cards in the current session, enabling cross-card variable transfer and session context inheritance.

[0115] After writing back the response result, the backend security relay gateway triggers the callback interface according to the association mapping of the callback interface defined in the interaction card template. Specifically, the backend security relay gateway encapsulates the session identifier, card identifier, de-identified response result, and interaction result data into a callback message, and sends the callback message to the Uniform Resource Locator (URL) using a Hypertext Transfer Protocol (HTTP) POST request according to the URL configured in the association mapping. The callback modes configured in the association mapping include synchronous callback mode and asynchronous callback mode: when configured in synchronous callback mode, the backend security relay gateway blocks and waits for the callback receiver's response after sending the callback message, and uses the response returned by the callback receiver as the final response to the visitor's initial submission request, returning it to the visitor through the original message channel; when configured in asynchronous callback mode, the backend security relay gateway does not need to wait for the callback receiver's response after sending the callback message, and directly returns the operation completion status to the visitor.

[0116] After completing all the above operations, the session context manager will transition the state machine from the target enterprise business system's responded state back to the session active state, awaiting the next trigger node, thus completing a complete interaction loop. At this point, the entire data flow path of the interaction card—from template definition, variable replacement, serialization and distribution, dynamic rendering, user operation collection, structured submission, session-level authentication, field validation, interface mapping conversion, proxy call, response anonymization and writing back to the session context, to triggering the callback interface—is completed, achieving a complete data loop.

[0117] The technical solution provided in this embodiment firstly replaces free text input with structured interactive cards, enabling user operations to directly generate structured operation events containing user operation data and perform backend field validation. This eliminates the need for semantic parsing through natural language processing or large language models, thus avoiding semantic ambiguity and parsing errors caused by free text interaction and significantly reducing computational resource consumption and response latency. Secondly, all visitor requests are uniformly received and forwarded through a backend secure relay gateway. After performing session-level authentication, field validation, and interface mapping conversion, the gateway initiates calls to the target enterprise's business system as a proxy, making enterprise-level authentication credentials completely invisible to the visitor. This eliminates security risks such as authentication credential leakage, cross-site request forgery, and server-side request forgery caused by direct frontend connection to the target enterprise's business system at the architectural level. Finally, by completing the entire process of defining, issuing, rendering, submitting, proxying, de-identifying and writing back, and triggering callbacks of interactive cards within the instant messaging session, users do not need to leave the current session window during the entire business interaction process, thus maintaining session continuity, avoiding user churn due to page jumps, and improving business conversion rates.

[0118] Example 2

[0119] This embodiment, based on Embodiment 1, provides a detailed explanation of the specific implementation process of the file upload component and the session isolation bucketing storage and expiration cleanup strategy. The technical solutions described in Embodiment 1 are still applicable to this embodiment. This embodiment will not repeat the process described in Embodiment 1, but will only supplement the explanation of the differentiated processing in the file upload scenario.

[0120] In business scenarios involving information submission, such as online loan applications requiring supplementary ID photos and income certificates, online customer service work orders requiring uploaded screenshots of malfunctions, and government services requiring the submission of electronic supporting documents, operators can declare the component type as a file upload component when defining the interactive card template using a domain-specific language. When the interactive card template contains a file upload component, in addition to executing the processes described in steps 201 to 206 of Embodiment 1, the dynamic rendering and data closure method of the interactive card also executes the following specific processing flow for file uploads: steps 301 and 302 (e.g. Figure 3 (As shown).

[0121] Step 301: After the user selects a file through the file upload component, the visitor client uploads the file to the backend attachment storage interface of the workflow orchestration platform.

[0122] Specifically, when the interactive card containing the file upload component is rendered in the instant messaging window on the visitor's end, the user selects a file to upload from local storage devices (such as computer hard drives, mobile device photo albums, or file managers) by clicking the file selection button of the file upload component. After the file upload component detects that the user has completed the file selection operation, it does not directly submit the file data as part of the structured operation event to the backend secure relay gateway. Instead, it first uploads the file to the backend attachment storage interface of the workflow orchestration platform.

[0123] The backend attachment storage interface is an independent service module deployed on the backend of the workflow orchestration platform (as part of the backend security relay gateway or as a supporting service deployed in parallel with it). It is specifically designed to receive and process file upload requests from the visitor client. During the file upload process, the visitor client streams file data to the backend attachment storage interface via Hypertext Transfer Security Protocol (HTTPS) using a multipart form data format or a chunked upload protocol. To ensure the reliability of large file uploads, the visitor client supports a resume mechanism, meaning that the upload can resume from the point of interruption after a network outage without retransmitting the entire file.

[0124] Optionally, before uploading a file, the visitor client also performs front-end validation on the file according to the validation rules corresponding to the file upload component in the interactive card template: verifying whether the media type of the file is within the allowed type list (e.g., whether it is limited to JPEG, PNG image format, or PDF document format); verifying whether the file size does not exceed the preset maximum file size threshold (e.g., not exceeding 5MB or 10MB). If the front-end validation fails, the visitor client directly displays the corresponding error message in the instant messaging session window (e.g., "File format not supported, please upload JPEG or PNG format image" or "File size exceeds 5MB limit, please compress and re-upload"). The user can then reselect a file that meets the requirements and trigger the upload process again.

[0125] When a guest uploads a file to the backend attachment storage interface, they include a session identifier in the upload request. Upon receiving the file, the backend attachment storage interface uses the session identifier as a storage isolation identifier to store the file in the corresponding bucket of the object storage service and returns a temporary access locator with a timestamp signature to the guest.

[0126] Specifically, after receiving a file uploaded by a visitor, the backend attachment storage interface does not store the file in a publicly accessible storage location. Instead, it uses the session identifier as the storage isolation identifier and stores the file in the corresponding bucket of an object storage service (such as Amazon S3, Alibaba Cloud OSS, MinIO, etc.). The object storage service pre-creates multiple storage buckets according to the session dimension, with each bucket corresponding to a session identifier. The backend attachment storage interface determines the target storage bucket based on the session identifier carried in the upload request, writes the file into that bucket, and generates a unique object key for that file within the object storage service.

[0127] Using the bucketed storage mechanism described above, which uses session identifiers as storage isolation identifiers, files uploaded by different sessions are physically isolated and stored in different storage buckets. Multiple files within the same session are stored uniformly in the same bucket corresponding to that session. A guest client in one session has no right to access files in the storage buckets of other sessions, thus eliminating the risk of data leakage from cross-session file access at the storage level.

[0128] After successfully writing the file to the corresponding bucket in the object storage service, the backend attachment storage interface generates a temporary access locator with a timestamp and signature, and returns this temporary access locator to the visitor. The temporary access locator with a timestamp and signature is a time-sensitive Uniform Resource Locator (URL), containing the file's storage path in the object storage service and a signature generated by the backend attachment storage interface. The signature includes a timestamp indicating the URL's expiration date. The backend attachment storage interface configures a preset validity period (e.g., 5 or 10 minutes) when generating the temporary access locator. After this validity period, the URL automatically expires, and any access request based on this URL is rejected. Through this mechanism of temporary access locators with timestamps and signatures, even if the URL is intercepted during network transmission, attackers cannot access the file using the URL outside its validity period, thus further ensuring file storage security. Furthermore, the temporary access locator is only used to reference the file in subsequent structured operation events, rather than directly embedding file data into the operation events, avoiding transmission efficiency issues caused by excessively large amounts of operation event data.

[0129] Step 302: The visitor receives a temporary access locator with a timestamp signature returned by the backend attachment storage interface, uses the temporary access locator as part of the user operation data, and generates a structured operation event.

[0130] Specifically, after receiving the temporary access locator returned by the backend attachment storage interface, the visitor client does not immediately submit the structured operation event. Instead, it continues to wait for the user to complete the operations of other components in the interactive card (such as filling in remarks, selecting a date, etc.). Once the user completes the operations of all components in the interactive card and clicks the submit button, the visitor client collects all the data entered by the user on the interactive card, uses the temporary access locator as the field value corresponding to the file upload component in the user operation data, and encapsulates it along with the user operation data of other components to generate a structured operation event. The structured operation event includes a session identifier, card identifier, operation type, and user operation data. The field value corresponding to the file upload component in the user operation data is the temporary access locator, not the file's binary data or original filename.

[0131] After the visitor submits the structured operation event to the backend security gateway, the backend security gateway performs session-level authentication and field validation according to step 205 in Example 1. During the field validation phase, the backend security gateway performs backend validation on the temporary access locator based on the validation rules corresponding to the file upload component in the interaction card template. This verifies whether the temporary access locator's signature is valid, whether the temporary access locator is within its validity period, and whether the file corresponding to the temporary access locator actually exists in the corresponding bucket of the object storage service. If the validation passes, the backend security gateway maps the temporary access locator in the user operation data to the data interface format required by the target enterprise business system and initiates a call request to the target enterprise business system as a proxy. If the validation fails (e.g., the temporary access locator has expired), the backend security gateway returns a validation failure error response to the visitor, guiding the user to re-upload the file.

[0132] Furthermore, after the visitor uploads the file to the backend attachment storage interface of the workflow orchestration platform, the backend attachment storage interface also configures an expiration cleanup policy for the object storage service. When the session corresponding to the session identifier ends, all files stored in the bucket corresponding to the session identifier are deleted.

[0133] Specifically, the backend attachment storage interface configures a lifecycle management policy for each storage bucket or each storage object in the object storage service. The lifecycle management policy defines the expiration conditions and post-expiration cleanup actions for each storage bucket or storage object. In this embodiment, the expiration condition is the end of the instant messaging session corresponding to the session identifier. Session end includes, but is not limited to, the following situations: the user actively closes the instant messaging session window; the user does not perform any operation for an extended period, causing the session to time out (e.g., more than 7 days without any activity); the session terminates naturally after the user completes all business processes; and operations personnel manually terminate the session in the management backend. The backend attachment storage interface listens for session state change events in the session context manager. When it detects that the state of any session has changed to "ended," the backend attachment storage interface searches for the storage bucket corresponding to that session identifier in the object storage service based on the session identifier, triggers the execution of the expiration cleanup policy, and deletes all files stored in that bucket.

[0134] By implementing the above-mentioned automatic expiration and cleanup strategy, on the one hand, a large number of obsolete files from ended sessions are avoided in the object storage service, thereby saving storage resources and reducing storage costs; on the other hand, automatically deleting all files related to the session after it ends complies with the principle of data minimization and the requirements of data protection regulations, avoiding the risk of data leakage caused by long-term file retention.

[0135] In this embodiment, both the backend attachment storage interface and the backend security relay gateway in Embodiment 1 are deployed on the backend of the process orchestration platform. They share the same session-level authentication mechanism to ensure that file upload operations and structured operation event submission operations are under unified session security control.

[0136] Thus, through steps 301 to 302 above, this embodiment, based on the general interactive card data closed-loop process of Embodiment 1, further realizes the complete data flow path of the file upload component: from the user selecting a file in the file upload component, to the file being uploaded to the backend attachment storage interface and stored in the object storage service in buckets with session identifiers, to the generation of a temporary access locator with a timestamp signature and returned to the visitor, to the temporary access locator being encapsulated as part of the user's operation data into a structured operation event, to the backend security transit gateway performing backend verification and mapping conversion on the temporary access locator, and finally to the automatic cleanup of all files in the corresponding bucket after the session ends. The above scheme works in conjunction with the process in Embodiment 1 to jointly construct a complete interactive card dynamic rendering and data closed-loop scheme in the file upload scenario.

[0137] Example 3

[0138] This embodiment, based on Embodiment 1 above, provides a detailed description of the dynamic query process of the time slot selector. The technical solutions described in Embodiment 1 are still applicable to this embodiment. This embodiment will not repeat the processes described in Embodiment 1, but will only supplement the explanation of the time slot selector-related processes.

[0139] In business scenarios involving appointment services, such as online hospital registration, government service appointments, hotel room reservations, and vehicle maintenance appointments, operators can declare the component type as a time slot selector when defining the interaction card template using a domain-specific language. The time slot selector provides users with a list of available time slots for appointment selection. Since available time slots typically depend on real-time conditions such as the user's selected date, department, and service type, and the available time slots change dynamically for different dates, the options for the time slot selector cannot be statically determined during the interaction card template definition. Instead, they need to be retrieved in real-time from the target enterprise's business system after the user selects a date. The time slot selector is usually used in conjunction with a date selector. The user first selects a date using the date selector, and the interaction card then dynamically loads the corresponding list of available time slots based on the selected date. When the interaction card template contains a time slot selector and its associated date selector, the dynamic rendering and data closure method of the interaction card, in addition to executing steps 201 to 206 in Example 1, also executes the following specific processing flow for dynamic querying of the time slot selector: Steps 401-404 (e.g.) Figure 4 (As shown).

[0140] Step 401: After the visitor detects that the user has selected a date through the date picker, it generates a time slot query request carrying the date and submits the time slot query request to the backend security transit gateway.

[0141] Specifically, after the interactive card containing a date picker and a time slot picker is rendered in the instant messaging session window on the visitor's end, the user performs a date selection operation on the date picker (e.g., clicking on a date in the calendar control). Once the date picker component listens for the user's date selection event, it triggers the time slot query process. The visitor's end does not directly send a time slot query request to the target enterprise's business system; instead, it first generates a time slot query request carrying the date and submits it to the backend security relay gateway.

[0142] The time slot query request is a structured data object conforming to the JSON data format, containing the following fields: Session ID, used to identify the instant messaging session to which the current operation belongs; Card ID, used to identify the current interactive card instance; Operation Type, with a value of "query_slots", used to identify that this request is a time slot query type; and the date selected by the user, carried in a standard date format (e.g., "2026-07-15"). The visitor sends the time slot query request to the predefined interface address of the backend security relay gateway via the Hypertext Transfer Protocol. Similar to the architectural constraints in step 204 of Embodiment 1, the visitor is configured to prohibit directly initiating any Hypertext Transfer Protocol requests to the target enterprise business system, and the time slot query request is also forwarded by proxy through the backend security relay gateway.

[0143] Step 402: The backend security relay gateway receives the time slot query request, calls the reservation interface of the target enterprise's business system as a proxy, and obtains the list of available reservation time slots.

[0144] Specifically, after receiving a time slot query request from a visitor, the backend security gateway first performs session-level authentication. This verifies whether the session identifier exists and is active, whether the card identifier matches the card identifier of the most recently issued interactive card in the session context, and whether the current session state allows the query operation. If authentication is successful, the backend security gateway extracts the user-selected date from the time slot query request.

[0145] Subsequently, the backend security gateway, acting as a proxy, calls the appointment interface of the target enterprise's business system to obtain a list of available appointment time slots. Specifically, the backend security gateway determines the Uniform Resource Locator (URL) and invocation method of the target enterprise's business system's appointment interface based on the appointment interface mapping information configured in the interaction card template. The appointment interface mapping information pre-configures the request parameter formats required by the target enterprise's business system's appointment interface, such as the field name of the date parameter (e.g., "date" or "apptDate"), the parameter format (e.g., "YYYY-MM-DD" or "YYYY / MM / DD"), and fixed parameters that need to be injected additionally (e.g., departmentId, serviceType, doctorId, etc., which are pre-configured by the management backend of the workflow orchestration platform and do not require user input). The backend security gateway converts the user-selected date according to the appointment interface mapping information and automatically injects the fixed parameters, generating a query request body that conforms to the data format required by the target enterprise's business system's appointment interface. The backend security relay gateway uses pre-configured enterprise-grade authentication credentials (such as OAuth 2.0 tokens or application programming interface keys) to authenticate and sign query requests, places the enterprise-grade authentication credentials in the Hypertext Transfer Protocol request header, and initiates a call request to the reservation interface of the target enterprise's business system as a proxy.

[0146] Upon receiving the call request, the target enterprise's business system queries the corresponding available time slots based on the user-selected date and fixed parameters (such as department identifiers), and returns the query results to the backend secure relay gateway as a response. The response contains a list of available time slots for that date, with each time slot including at least a start time (e.g., "09:00"), an end time (e.g., "09:30"), and a status indicating whether the time slot is available for booking. The target enterprise's business system may also return a list of unbookable time slots for that date, or only a list of available time slots, depending on the target enterprise's business system's interface design.

[0147] Step 403: The backend security transit gateway returns the list of available appointment time slots to the visitor's client after de-identifying the data.

[0148] Specifically, after receiving the response from the target enterprise's business system, the backend security gateway first performs anonymization processing on the response. This anonymization includes removing business-sensitive fields from the response, such as internal doctor IDs, department codes, and internal identifiers for appointment resources—internal data fields that the visitor doesn't need to be aware of. Simultaneously, it retains the information necessary for the visitor to render the time slot selector, including but not limited to the time slot start time, time slot end time, and appointment availability. Through this anonymization process, the backend security gateway ensures that only the minimum necessary dataset required by the visitor is returned to the visitor, preventing the exposure of internal system information.

[0149] Before returning the list of available time slots to the visitor, the backend security gateway caches the list in the backend cache of the workflow orchestration platform and configures a time-to-live (TTL) for the cache. Specifically, the backend security gateway uses a combination of the session identifier and the user-selected date as the cache key to store the list of available time slots returned by the target enterprise's business system in the backend cache of the workflow orchestration platform, and configures a preset TTL (e.g., 5 minutes) for this cached data. Within the TTL, if a user in the same session queries available time slots for the same date again (e.g., a user switches to another component and then switches back to the time slot selector), the backend security gateway will first read the list of available time slots from the backend cache and return it directly to the visitor, without having to call the reservation interface of the target enterprise's business system again. Through this caching mechanism, on the one hand, the interface pressure on the target enterprise's business system caused by repeated queries for the same date within the same session is avoided, improving the overall system response efficiency; on the other hand, by configuring the TTL, it is ensured that the cached data is not valid indefinitely, avoiding data inconsistency issues caused by changes in the reservation status in the business system (e.g., a time slot is booked by another user within the cache validity period).

[0150] Step 404: The visitor's client renders the available options for the time slot selector based on the anonymized list of available time slots.

[0151] Specifically, after the visitor receives the anonymized list of available time slots from the backend security relay gateway, the dynamic rendering engine updates the list of available options in the time slot selector based on this list. The time slot selector renders available time slots as clickable and selectable, and unavailable time slots as disabled (e.g., displayed in gray), allowing users to visually identify available time slots in the interface. After a user clicks on any available time slot in the time slot selector, the selector records the selection and generates a structured operation event according to steps 203 to 206 in Example 1, completing the subsequent submission, authentication, verification, conversion, proxy call, anonymization write-back, and callback triggering processes. In the subsequent submission process, the user-selected time slot information, as part of the user's operation data, is mapped and converted by the backend security relay gateway into the data interface format required by the target enterprise's business system. Then, acting as a proxy, it initiates a reservation confirmation request to the target enterprise's business system, completing the full closed loop of the reservation process.

[0152] In another optional embodiment, when the date carried in the time slot query request changes (i.e., the user reselects a different date on the date selector), the visitor clears the current list of available options in the time slot selector, re-executes steps 401 to 404 above, obtains the corresponding list of bookable time slots based on the new date, and re-renders the time slot selector.

[0153] Thus, through steps 401 to 404 above, this embodiment, based on the general interactive card data closed-loop process of Embodiment 1, further realizes a complete dynamic query and data flow path for the time slot selector: from the user selecting a date in the date selector, to the visitor generating a time slot query request and submitting it to the backend security relay gateway, to the backend security relay gateway calling the target enterprise's business system reservation interface as a proxy to obtain the list of available time slots, to the backend security relay gateway caching the list of available time slots in the backend cache and configuring its lifetime, to returning the anonymized list of available time slots to the visitor, and finally, to the visitor rendering the selectable options of the time slot selector based on the list of available time slots. The above scheme, in conjunction with the process in Embodiment 1, jointly constructs a complete dynamic rendering and data closed-loop scheme for interactive cards in the time slot selector scenario.

[0154] Example 4

[0155] This embodiment provides a dynamic rendering and data closure system for interactive cards, which can be used to execute the dynamic rendering and data closure method for interactive cards described in this embodiment of the invention. See also Figure 5 The system comprises the following components.

[0156] An interaction card definition engine 501, deployed in the management backend of the workflow orchestration platform, is configured to define interaction card templates using a domain-specific language. Each interaction card template includes component type declarations, variable placeholders, validation rules, and mappings to callback interfaces. Optionally, the interaction card definition engine 501 is also used to configure callback modes within the interaction card templates, including synchronous and asynchronous callback modes.

[0157] The session context manager 502, deployed on the backend of the workflow orchestration platform, is configured to maintain a session lifecycle based on a finite state machine. When the state machine of the session context transitions to a trigger node, it replaces the variable placeholders in the interactive card template with the actual data in the session context, and serializes the replaced template into JSON data format before sending it to the visitor client. Optionally, the session context manager 502 is also configured to carry a card identifier and a session identifier in the JSON data, so that the visitor client can maintain the association between the interactive card and the session context.

[0158] A dynamic rendering engine 503, deployed on the visitor's end, is configured to dynamically load corresponding user interface components within a rendering sandbox independent of the main document flow based on the component type declaration carried in the JSON data. This constructs interactive user interface components and encapsulates user actions as structured operation events. The structured operation events include user operation data collected from the visitor's end and a session identifier carried in the JSON data. Optionally, the dynamic rendering engine 503 is specifically used to construct the rendering sandbox using a shadow document object model, define the interactive user interface components using a web component specification and dynamically load them into the rendering sandbox, and isolate the stylesheets and script execution environment of the interactive user interface components from the stylesheets and script execution environment of the visitor's main page through the shadow document object model. Optionally, the dynamic rendering engine 503 is also used to maintain the association between the interactive card and the session context based on the card identifier and the session identifier carried in the JSON data, and include the session identifier and the card identifier in the structured operation events.

[0159] The secure relay gateway 504, deployed on the backend of the process orchestration platform, is configured to receive the structured operation events submitted by the visitor client, perform session-level authentication, perform field validation on the user operation data according to the validation rules, and map the user operation data into the data interface format required by the target enterprise business system, and initiate a call request to the target enterprise business system as a proxy; the visitor client is restricted to submitting events only to the secure relay gateway 504. Optionally, when initiating a call request to the target enterprise business system, the secure relay gateway 504 carries enterprise-level authentication credentials, which are not visible to the visitor client. Optionally, when the component type is a time slot selector, the secure relay gateway 504 is also configured to receive a time slot query request carrying a date submitted by the visitor client, call the reservation interface of the target enterprise business system as a proxy to obtain a list of available time slots, and return the list of available time slots to the visitor client after de-identification. Optionally, the secure transit gateway 504 is further configured to cache the list of available time slots in the backend cache of the workflow orchestration platform before returning the list of available time slots to the visitor terminal after de-identification, and to configure a time-to-live for the cache.

[0160] The data loop module 505, deployed on the backend of the process orchestration platform, is configured to receive the response result returned by the target enterprise business system in response to the call request, perform anonymization processing on the response result, write it back to the session context, and trigger the callback interface according to the association mapping of the callback interface defined in the interaction card template. Optionally, when the data loop module 505 performs anonymization processing on the response result, it removes sensitive fields from the response result. Optionally, when the callback mode is configured as synchronous callback mode, the secure relay gateway 504 blocks and waits for the target enterprise business system to return the response result before returning it to the visitor; when the callback mode is configured as asynchronous callback mode, the secure relay gateway 504 temporarily stores the response result and then pushes it asynchronously through the callback interface.

[0161] Optionally, the dynamic rendering and data closed-loop system for interactive cards in this embodiment further includes:

[0162] The attachment storage manager 506, deployed on the backend of the workflow orchestration platform, is configured to receive files uploaded by the visitor client, store the files in the corresponding bucket of the object storage service using the session identifier as the storage isolation identifier, return a temporary access locator with a timestamp signature to the visitor client, and configure an automatic expiration and cleanup policy for the object storage service. Optionally, after the user selects a file through the file upload component, the visitor client uploads the file to the attachment storage manager 506; the visitor client receives the temporary access locator with a timestamp signature returned by the attachment storage manager 506, uses the temporary access locator as part of the user operation data, and generates the structured operation event.

[0163] The data report aggregator 507 is deployed on the backend of the process orchestration platform and is configured to receive the interaction result data pushed by the callback interface, perform real-time statistics and generate multi-dimensional reports.

[0164] The interactive card dynamic rendering and data closure system provided in this embodiment of the invention can execute the interactive card dynamic rendering and data closure method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment can be found in any method embodiment of the invention.

[0165] Furthermore, embodiments of the present invention also provide a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the dynamic rendering and data closure method for interactive cards described in the foregoing embodiments.

[0166] It should be noted that in this article, relational terms such as first and second are only used to refer to...

[0167] Distinguishing one entity or operation from another does not necessarily require or imply these distinctions.

[0168] There is no such actual relationship or order between entities or operations. Furthermore, the terms "including" and "package" do not apply.

[0169] The word "comprise" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0170] In this embodiment of the invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0171] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0172] In particular, the device embodiment is basically similar to the method embodiment, so the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0173] For ease of description, the above apparatus is described by dividing it into various functional units / modules. Of course, in implementing this invention, the functions of each unit / module can be implemented in one or more software and / or hardware.

[0174] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0175] The above description is merely a specific 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 method for dynamic rendering and data closure of interactive cards, characterized in that, include: In the management backend of the workflow orchestration platform, interaction card templates are defined using a domain-specific language; wherein, the interaction card template includes component type declarations, variable placeholders, validation rules, and association mappings with callback interfaces; When the state machine of the session context transitions to the trigger node, the backend of the process orchestration platform replaces the variable placeholders in the interaction card template with the actual data in the session context, serializes the replaced template into JSON data format and sends it to the visitor's end. The visitor client dynamically loads the corresponding user interface component in a rendering sandbox independent of the main document flow based on the component type declaration carried in the JSON data, so as to construct an interactive user interface component; after the interactive user interface component responds to the user operation, it generates a structured operation event, which contains the user operation data collected by the visitor client. The visitor client submits the structured operation event to the backend security relay gateway of the process orchestration platform; After receiving the structured operation event, the backend security relay gateway performs session-level authentication, performs field validation on the user operation data according to the validation rules, and maps the user operation data into the data interface format required by the target enterprise business system, and initiates a call request to the target enterprise business system as a proxy of the backend security relay gateway. The backend security relay gateway receives the response result returned by the target enterprise business system in response to the call request, performs anonymization processing on the response result and writes it back to the session context, and triggers the callback interface according to the association mapping of the callback interface defined in the interaction card template to complete the data loop.

2. The method according to claim 1, characterized in that, The dynamic loading of corresponding user interface components within a rendering sandbox independent of the main document flow includes: The rendering sandbox is constructed using a shadow document object model; Define the interactive user interface components according to the web component specification and dynamically load them into the rendering sandbox; The shadow document object model isolates the stylesheets and script execution environment of the interactive user interface components from the stylesheets and script execution environment of the main page on the visitor's end.

3. The method according to claim 1, characterized in that, The step of initiating a call request to the target enterprise business system using the proxy identity of the backend security relay gateway includes: initiating the call request with enterprise-level authentication credentials, wherein the enterprise-level authentication credentials are not visible to the visitor client; The process of desensitizing the response result includes removing sensitive fields from the response result.

4. The method according to claim 1, characterized in that, The JSON data also carries card identifiers and session identifiers; After the visitor receives the JSON data, it also includes: The visitor client maintains the association between the interactive card and the session context based on the card identifier and the session identifier; The structured operation event generated by the visitor terminal also includes the session identifier and the card identifier.

5. The method according to claim 4, characterized in that, The component type is a file upload component; The visitor terminal collects user operation data, including: After the user selects a file through the file upload component, the visitor terminal uploads the file to the backend attachment storage interface of the workflow orchestration platform. The visitor terminal receives a temporary access locator with a timestamp signature returned by the backend attachment storage interface, uses the temporary access locator as part of the user operation data, and generates the structured operation event.

6. The method according to claim 5, characterized in that, After the visitor uploads the file to the backend attachment storage interface of the workflow orchestration platform, the process further includes: The backend attachment storage interface uses the session identifier as the storage isolation identifier to store the file in the corresponding bucket of the object storage service; The backend attachment storage interface configures an expiration cleanup policy for the object storage service. When the session corresponding to the session identifier ends, all files stored in the bucket corresponding to the session identifier are deleted.

7. The method according to claim 1, characterized in that, The component type is the time slot selector; The visitor terminal collects user operation data, including: After the visitor terminal detects that the user has selected a date through the date picker, it generates a time slot query request carrying the date and submits the time slot query request to the backend security relay gateway. The backend security relay gateway receives the time slot query request and, acting as a proxy, calls the reservation interface of the target enterprise's business system to obtain a list of available time slots. The backend security relay gateway returns the list of available time slots to the visitor's client after de-identifying it. The visitor terminal renders the selectable options of the time slot selector based on the anonymized list of available time slots.

8. The method according to claim 7, characterized in that, Before the backend security transit gateway anonymizes the list of available time slots and returns it to the visitor's client, the following steps are also included: The backend security transit gateway caches the list of available time slots in the backend cache of the process orchestration platform and configures a time-to-live for the cache.

9. The method according to claim 1, characterized in that, The association mapping of the callback interface in the interactive card template also includes a callback mode configuration, which indicates whether the callback interface adopts a synchronous callback mode or an asynchronous callback mode. When the callback mode is configured as synchronous callback mode, the backend security relay gateway blocks and waits for the target enterprise business system to return the response result before returning to the visitor terminal; When the callback mode is configured as asynchronous callback mode, the backend security relay gateway will temporarily store the response result and then push it asynchronously through the callback interface.

10. A dynamic rendering and data closed-loop system for interactive cards, characterized in that, include: The interaction card definition engine, deployed in the management backend of the process orchestration platform, is configured to define interaction card templates using a domain-specific language; wherein, the interaction card template includes component type declarations, variable placeholders, validation rules, and association mappings with callback interfaces; The session context manager, deployed on the backend of the process orchestration platform, is configured to maintain the session lifecycle based on a finite state machine. When the state machine of the session context transitions to the trigger node, the variable placeholders in the interaction card template are replaced with the actual data in the session context. The replaced template is then serialized into JSON data format and sent to the visitor's end. A dynamic rendering engine, deployed on the visitor's end, is configured to dynamically load corresponding user interface components in a rendering sandbox independent of the main document flow based on the component type declaration carried in the JSON data, in order to construct interactive user interface components and encapsulate user operations as structured operation events; the structured operation events include user operation data collected by the visitor's end and session identifiers carried in the JSON data; A secure relay gateway, deployed on the backend of the process orchestration platform, is configured to receive the structured operation events submitted by the visitor client, perform session-level authentication, perform field validation on the user operation data according to the validation rules, and map the user operation data into the data interface format required by the target enterprise business system, and initiate a call request to the target enterprise business system as a proxy; the visitor client is restricted to submitting events only to the secure relay gateway; The data closed-loop module, deployed on the backend of the process orchestration platform, is configured to receive the response result returned by the target enterprise business system in response to the call request, perform anonymization processing on the response result and write it back to the session context, and trigger the callback interface according to the association mapping of the callback interface defined in the interaction card template.

11. The system according to claim 10, characterized in that, Also includes: The attachment storage manager, deployed on the backend of the process orchestration platform, is configured to receive files uploaded by the visitor, store the files in the corresponding bucket of the object storage service using the session identifier as the storage isolation identifier, return a temporary access locator with a timestamp signature to the visitor, and configure an automatic expiration and cleanup policy for the object storage service. The data report aggregator, deployed on the backend of the process orchestration platform, is configured to receive the interaction result data pushed by the callback interface, and perform real-time statistics and multi-dimensional report generation.

12. A computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 9.

Images