Message card generation method, device and storage medium

Abstract

The application discloses a message card generation method and device and a storage medium, relates to the technical field of message cards, and discloses a message card generation method, which comprises the following steps: receiving card configuration information sent by a business system, wherein the card configuration information comprises configuration data of a plurality of component instances; calling a target component from a preset component library according to a component identifier and a component type in the configuration data; and rendering the plurality of component instances by using style attributes, content data and interaction data in the configuration data and rendering logic corresponding to the target component, so as to obtain a message card. Based on the method, template development and subsequent maintenance work need not be repeatedly carried out for various newly-added business scenarios, the development and maintenance cost of a system is reduced, and the adaptability and flexibility of the message card to changes in business requirements are improved.

Description

Technical Field

[0001] This application relates to the field of message card technology, and in particular to a method, device and storage medium for generating message cards. Background Technology

[0002] Most existing message cards are developed based on a fixed template model. Each new business scenario requires the development of a new card template and corresponding rendering logic. As business scenarios continue to increase, the system needs to maintain a large number of different types of card templates, resulting in high development and maintenance costs and making it difficult to meet rapidly changing business needs.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device and storage medium for generating message cards, which aims to solve the technical problem that new card templates are needed when new business scenarios are added, making it difficult to maintain the needs of business changes.

[0005] To achieve the above objectives, this application proposes a method for generating message cards, the method comprising: Receive card configuration information sent by the business system, wherein the card configuration information includes configuration data of multiple component instances; Based on the component identifier and component type in the configuration data, the target component is called from the preset component library; Using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, the multiple component instances are rendered to obtain the message card.

[0006] In one embodiment, the content data includes public content and private content placeholders. After the step of calling the target component from a preset component library based on the component identifier and component type in the configuration data, the message card generation method further includes: Receive user-private data sent by the business system; Replace the private content placeholders in the content data with the user-private data; The step of rendering the multiple component instances to obtain the message card using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, includes: The message card is obtained by rendering the multiple component instances using the style attributes in the configuration data, the updated content data, the interaction data, and the rendering logic corresponding to the target component.

[0007] In one embodiment, after the step of rendering the multiple component instances using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component to obtain the message card, the message card generation method further includes: In response to a trigger operation on the component instance, obtain the terminal type of the current terminal; Match the corresponding interaction action code and interaction action parameters in the interaction data according to the terminal type; Execute the response logic corresponding to the interaction action code and the interaction action parameters to complete the component interaction corresponding to the trigger operation.

[0008] In one embodiment, the plurality of component instances further includes a streaming output component. After the step of rendering the plurality of component instances using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component to obtain the message card, the method for generating the message card further includes: Establish a data connection with the backend streaming output service to obtain the streaming content segments to be output; The streaming content fragment to be output is rendered to the streaming output component.

[0009] In one embodiment, the step of establishing a data connection with the backend streaming output service and obtaining the streaming content segment to be output includes: When the presence of streaming card information is detected in the current message visual window, a data connection is established with the backend streaming output service; A streaming task waiting queue is constructed based on the priority order of the streaming card information, wherein streaming card information that is outside the current message viewing window is in the streaming task waiting queue. The tasks to be processed in the streaming task waiting queue are used as the streaming card information to be output.

[0010] In one embodiment, after the step of establishing a data connection with the backend streaming output service when detecting the existence of streaming card information in the current message visual window, the message card generation method further includes: If the completion process of streaming data reception and rendering is not detected within a preset time period, the server obtains the streaming card information to be output, wherein after the server takes over the streaming task, it pulls the complete streaming output content and updates it to the message card.

[0011] In one embodiment, the pre-built component library contains a number of standardized encapsulated basic components, including at least one of text components, image components, button components, and table components; each basic component corresponds to independent rendering logic and basic interaction logic.

[0012] In one embodiment, the configuration data of the component instance further includes an incremental update identifier; The incremental update identifier is associated with and bound to the component instance, and is used to locate the target component instance to be updated after the message card is issued in order to perform incremental content update.

[0013] In addition, to achieve the above objectives, this application also proposes a message card generation device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the message card generation method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the message card generation method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: By receiving card configuration information containing configuration data for multiple component instances sent by the business system, the system calls the target component from the pre-built component library based on the component identifier and component type in the configuration data. Then, it renders multiple component instances by combining the style attributes, content data, and interaction data in the configuration data with the rendering logic corresponding to the target component to obtain the message card. The system can quickly combine the target component in the pre-built component library with the flexible configuration of pre-built standardized components, thereby quickly building message cards that adapt to different business needs. This eliminates the need to repeatedly develop templates and perform subsequent maintenance work for various new business scenarios, reducing the development and maintenance costs of the system and improving the adaptability and flexibility of message cards to changes in business needs. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the first embodiment of the message card generation method of this application; Figure 2This is a schematic diagram of the message card architecture in the message card generation method of this application; Figure 3 This is another schematic diagram of the message card architecture in the message card generation method of this application; Figure 4 A simplified flowchart illustrating the real-time segmented rendering and generation of the final message for all terminals provided in this application; Figure 5 A schematic diagram illustrating the viewport priority strategy provided in this application; Figure 6 A diagram illustrating full and incremental updates provided for this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the message card generation method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] Most existing message cards are developed based on a fixed template model. Each new business scenario requires the development of a new card template and corresponding rendering logic. As business scenarios continue to increase, the system needs to maintain a large number of different types of card templates, resulting in high development and maintenance costs and making it difficult to meet rapidly changing business needs.

[0022] Based on this, this application provides a solution that allows for the rapid construction of message cards adapted to different business needs by quickly combining target components from a pre-built component library through flexible configuration of pre-built standardized components. This eliminates the need for repeated template development and subsequent maintenance for various new business scenarios, reducing system development and maintenance costs and improving the adaptability and flexibility of message cards to changes in business needs.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or message card generating device capable of performing the above functions. The message card generating device is a client, such as a user's mobile phone, tablet, or computer. The following description uses a client as an example to illustrate this embodiment and the subsequent embodiments.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] Based on this, embodiments of this application provide a method for generating message cards, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the message card generation method of this application.

[0026] In this embodiment, the method for generating the message card includes steps S10 to S40: Step S10: Receive card configuration information sent by the business system.

[0027] The card configuration information includes configuration data for multiple component instances.

[0028] In this embodiment, the business system, as the sender of card configuration information, only needs to assemble its own business content into a structured data packet containing configuration data of multiple component instances according to a unified message card description protocol, and send the configuration information to the client through the instant messaging platform's interface. It does not need to concern itself with the underlying rendering implementation of the components, terminal adaptation logic, or the internal rendering process of the instant messaging platform. In enterprise instant messaging scenarios, the business system can be various vertical business back-end systems such as enterprise expense approval systems, OA office workflow systems, customer relationship management systems, intelligent question-and-answer large model service systems, and human resources attendance systems.

[0029] Card configuration information is a structured data set that conforms to the unified message card description protocol and is used to define the overall structure and rendering rules of message cards. Component instances are the specific instances that need to be configured in the card configuration information, such as title components, detail text, and detail links. Each component instance includes configuration data such as component idKey (differentiated identifier), component type (type), attributes (style), content data (content), and interaction (actionData). In actual configuration, business systems build new business cards by combining existing components, thus achieving card message configuration.

[0030] One approach to receiving card configuration information is to use standardized JSON format as the configuration data carrier and receive card configuration information pushed by the business system via a synchronous HTTP interface. Specifically, the business system assembles a JSON-formatted configuration data packet according to a pre-defined unified card description protocol, nesting configuration data from multiple component instances hierarchically within the message content field. The complete card configuration information is then written to a message processing queue and associated with a unique message identifier, awaiting subsequent component matching and rendering.

[0031] For example, the enterprise expense reimbursement system calls the card push interface of the instant messaging platform to push card configuration information in JSON format. This includes configuration data for three component instances: title component, expense details text component, and details jump button component. The configuration data for each component instance includes component identifier, component type, style attributes, content data, and interaction data fields. After the data packet passes the interface verification, it enters the pending queue.

[0032] As an alternative approach, card configuration information can also be received via asynchronous subscription using a distributed message queue. Specifically, the business system serializes the card configuration information and sends it to a designated message queue. The configuration data carries a business scenario identifier and a globally unique message identifier. This asynchronous transmission enables non-blocking interaction between the business system and the card generation and rendering module, allowing the business system to continue executing its business logic without waiting for a response, thus reducing coupling between systems. The client then extracts configuration data from multiple component instances in the data packet, associates them with their corresponding message identifiers, and temporarily stores them locally.

[0033] This embodiment uses fixed structured description rules to define card content, ensuring that each component instance is defined with a unified field structure including component identifier, component type, style attributes, content data, and interaction data. This ensures that regardless of changes in business scenarios, the business system consistently outputs card configurations according to the same data specifications, eliminating the need to design differentiated template data structures for different business scenarios. By constructing a unified message card description protocol at the system level, a standard and unified data input standard is provided for subsequent component reuse, avoiding repetitive adaptation work caused by incompatible data formats in different business scenarios.

[0034] Step S20: Based on the component identifier and component type in the configuration data, call the target component from the preset component library.

[0035] In this embodiment, the pre-built component library is a collection of functional components that have been pre-standardized, encapsulated, and centrally stored. Each component contains a unique component type and component identifier to distinguish different component instances within the same card. The component type is used to match the standard component entity of the corresponding category in the pre-built component library. The pre-built component library can be a component library stored locally on the client or a component library in the cloud. The pre-built component library contains multiple standardized encapsulated basic components, including at least one of text components, image components, button components, and table components. Each basic component also corresponds to independent rendering logic and basic interaction logic. For example, a text component can handle automatic line wrapping and font rendering adaptation for plain text content, while a button component can be bound to preset interaction logic such as click-to-jump and request triggering. When calling a component, only the corresponding parameters in the configuration data need to be read and injected into the target component to complete the initialization of the component instance; there is no need to develop component functionality and interaction logic from scratch.

[0036] As an optional implementation, the target component can be invoked based on a local mapping method. Specifically, the client loads all standardized components from the pre-built component library into local memory and constructs a hash mapping table with component type codes as keys and component entity objects as values. Then, it iterates through all component instance configuration data in the card configuration information, extracts the component type field and component identifier field from each configuration, queries the corresponding component entity in the hash mapping table based on the extracted component type and component identifier fields, and associates and binds the component entity with the configuration data of the corresponding component instance.

[0037] For example, by traversing the configuration of the three component instances of the reimbursement card, the component types are obtained as title, text and button, respectively. The three target component entities of title component, text component and button component are matched in the local hash mapping table, and finally the three component entities are bound to their respective configuration data one by one.

[0038] As an alternative implementation, component resources can be remotely retrieved from a remote component management center and loaded locally. Specifically, the client sends a component query request to the remote component center, carrying the component type code and component version number from the configuration data in the request parameters. The remote component center retrieves the corresponding component resources based on the query conditions and returns the component's rendering logic script and basic attribute definition file to the requesting client. This allows for dynamic loading of component capabilities by remotely distributing executable rendering logic, enabling the addition of new component types or updates to component capabilities without requiring client or server releases. The locally loaded component rendering logic is then instantiated to generate the target component object and bound to the configuration data of the corresponding component instance.

[0039] In this embodiment, common display and interactive elements such as text, images, buttons, and tables are pre-encapsulated as independent standard components and stored in a component library. Each component has built-in fixed rendering logic and basic interactive capabilities, exposing only configurable parameter interfaces to the outside world. The internal implementation of the component is completely decoupled from the specific business logic, thereby completing the standardized encapsulation of various card elements. At the same time, a single standard component can be repeatedly called in cards in any business scenario without the need to redevelop rendering code for similar elements for new business scenarios.

[0040] Step S30: By configuring the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, multiple component instances are rendered to obtain the message card.

[0041] In this embodiment, style attributes are a set of parameters defining the visual presentation of a component, including dimensions such as size, color, font, margin, alignment, and layout rules, used to control the component's appearance. Content data is the specific business information displayed by the component, such as text content, image addresses, table data, and status indicators, which is the core information the component conveys to the user. Interaction data is a set of parameters defining the component's response behavior after being triggered, including trigger conditions, action codes, and execution parameters, used to implement the card's interactive capabilities. Rendering logic is the component's built-in standardized processing rules used to convert input configuration parameters into displayable interface elements.

[0042] As is understandable, a card message consists of basic message information (metaInfo), message content, and additional message attributes. MetaInfo contains the basic information of the card message, including sender and recipient information, message time, etc.; content contains the message content, including public and private content; additional attributes can include message mentions, quoted content, emoji replies, etc. Please refer to [link / reference]. Figure 2 Message content can also include public and private content. Regular message content is usually publicly available, while private content is content that needs to be displayed differently.

[0043] During the process of rendering a message card from a component instance, the client calls the rendering logic of each target component one by one according to the preset component layout order. Combined with configuration parameters, this completes the rendering and layout of all components, ultimately piecing them together into a complete message card. Specifically, the basic message information and additional information framework are rendered first. All standard components in the common content layer are loaded. The target components with bound configuration data are sorted according to the component layout order in the card configuration information to determine the rendering order and layout rules. This ensures that the final card layout structure is consistent with business expectations and avoids component order issues affecting information delivery. Next, the style attributes, content data, and interaction data from each component configuration are sequentially passed to the rendering logic of the corresponding target component. The rendering logic parses the parameters and generates corresponding UI element nodes, thus injecting personalized configuration parameters into the general component rendering logic. This allows the same standard component to present different visual and interactive effects with different parameters, meeting differentiated business display needs.

[0044] Please refer to Figure 2 The message card is divided into basic message information, public content, private content, and additional information. The public content layer mounts standard, generic content components, which are displayed uniformly to all receiving users. The private content layer mounts user-specific content component instances, with different users corresponding to independent component entities. Finally, the client merges the public layer and the corresponding user's private layer components to complete the rendering. Figure 2The message card architecture shown, taking a company's holiday notification group chat card as an example, includes the following basic message information: Message Unique ID: msg_holiday_midautumn_20xx; Sender: Official account of the Administration Department; Receiving Session: Company-wide employee group; Sending Time: 20xx-09-01 14:30:00; Message Type: Componentized Card Message. In the message content, all components are public components, and all recipients see the same public content. These public content components include a title component, a body text component, and a button component. The title component has the following properties: Component Type: title (title text component); Attributes: Font size 16px, bold font, center alignment, top margin 10px; Data: 20xx Mid-Autumn Festival Holiday Arrangement Notification; Interaction: No click interaction. The main text component is a text component (plain text component) with the following attributes: font size 14px, line height 1.6, top and bottom margins 8px; data: holiday from September xx to September xx, a total of x days; September xx (Sunday) is a normal working day; interaction: no click interaction. The button component is a button (action button component) with the following attributes: blue main button, 4px rounded corners, full width, 10px bottom margin; data: view holiday duty roster; interaction: click to jump to the company's internal duty schedule document page. The private content of this message card does not have any differentiated data bound to the user's identity, nor does it set any user-specific content placeholders, therefore it is not associated with any user-specific component data. For additional information, all recipients see the same content, including @mention information as: @all members, no quoted content, and supports likes, rose emojis, and quick replies. When the same card message is sent to the entire employee group, all employees see the same message header, title, body, buttons, and additional information. The entire card does not require user-level content replacement logic, and the client can complete the rendering by directly parsing the common configuration data.

[0045] This embodiment employs a full-scale client-side rendering approach, decoupling style, content, and interaction configuration parameters from the general component rendering logic. This ensures that the number, type, arrangement, and display effect of card components are dynamically determined by the input configuration data, rather than being fixed by pre-made templates. Multiple independent standard components can be freely combined and flexibly arranged through configuration, ultimately forming a complete message card. This allows the same set of standard components to generate differentiated card effects through different configurations. Business users only need to adjust configuration parameters to adapt to new business scenarios without redeveloping components and rendering logic, solving the problem of repeatedly developing templates and rendering logic when adding new business scenarios under a fixed template model. Furthermore, when adding a new business scenario, the business user only needs to select components suitable for their business needs from the existing standardized component library, arrange component configuration data according to a unified description protocol, and quickly generate message cards for the corresponding business scenario. The entire process requires no modification to the core card generation process code and no new template code is added. This simplifies the work of adding new scenarios from code development to parameter configuration, reducing development and maintenance costs, shortening the iteration cycle, ensuring the client can quickly respond to constantly changing business needs, and avoiding the maintenance burden caused by the disorderly expansion of a large number of templates.

[0046] This embodiment provides a method for generating message cards. By using a standardized component library and configurable assembly, message cards can be generated. Business systems do not need to develop separate card templates and corresponding rendering logic for new business scenarios. They can quickly generate message cards that adapt to business needs simply by combining existing standardized components and configuring corresponding parameters. This effectively reduces the development and maintenance costs of the message card system and improves the ability of the message card system to expand and adapt to changes in business needs.

[0047] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Furthermore, before step S30, the method for generating the message card further includes steps S40-S50: Step S40: Receive user-private data sent by the business system.

[0048] Step S50: Replace the private content placeholders in the content data with user-private data.

[0049] User-private data refers to exclusive business content data generated by a business system for a specific user. This data is uniquely bound to the user's identity and can only be viewed or displayed by the corresponding user. Private content placeholders, on the other hand, are standardized identifier fields embedded in the content of public components. Using a unique idkey as a matching marker, they are used to mark the content areas that need to be replaced with private data.

[0050] In this embodiment, during message distribution, the business system sends the original card template content and the user's private data together to avoid increasing rendering time due to multiple network requests. Therefore, in the same message chain where the client receives public card configuration information, it simultaneously receives the private data packet sent by the business system, which is bound to the currently logged-in user's identity.

[0051] The client parses and verifies the received private data packets. After confirming that the user to whom the data belongs matches the currently logged-in user, it extracts all IDkey identifiers and their corresponding private content, and constructs a hash mapping table between IDkeys and private data in local memory. Next, it iterates through all bound target components, scanning the content data fields of each component, identifying private content placeholders that conform to a preset format, and extracting the IDkey identifiers within the placeholders. Based on the extracted IDkey identifiers, it retrieves the corresponding private data from the local hash mapping table and completely replaces the placeholders in the component's content data with the retrieved private content data. The data structure of the component after replacement remains consistent with the original public content structure.

[0052] Furthermore, after replacing the private content placeholders in the content data with user-private data, multiple component instances can be rendered using style attributes in the configuration data, updated content data, interaction data, and rendering logic corresponding to the target component to obtain message cards, eliminating the need for multiple data requests from the client to retrieve private card content. Therefore, during the rendering process, after receiving the message data packet, the client first renders the basic message information and additional information framework, loading all standard components of the public content layer. Then, based on the currently logged-in user's identity, it matches the corresponding exclusive content component from the private content layer. Finally, the public components and the matched private components are concatenated according to a preset layout order to render a complete message card. When the message card is output on the client, Zhang San and Li Si can see the same message title and general description, while the salary details area in the middle displays their respective exclusive data, thus achieving a personalized display of the same card message for each user, perfectly corresponding to the layered architecture shown in the diagram.

[0053] For example, please refer to Figure 3 , Figure 3 For message cards containing private data, taking the salary notification card in a department group as an example, the content displayed to users in the basic message information layer is completely consistent, and the instance parameters are as follows: Message unique ID: msg_salary_20xx08_001 Sender: HR Human Resources System Receiving conversation: R&D Department All Staff Group Sent at: 20xx-08-15 10:00:00 Message type: Componentized card message.

[0054] The public content layer contains a title component and a general description component. The private content layer does not store the general public components; instead, it stores independent, user-specific content component instances. For example, user A (employee Zhang San) corresponds to content component 1, and user B (employee Li Si) corresponds to content component 2. Each user-specific component conforms to the content component structure specifications and is only visible and renderable to the corresponding user. The private content components are as follows: Content component 1 (salary details component) corresponding to user A (Zhang San) Component type: Form detail table component Attributes: Two-column layout, font size 13px, divider style, top and bottom margins 8px Data: Gross salary x 1 yuan, Individual income tax x 2 yuan, Social security and housing fund contributions x 3 yuan, Net salary x 4 yuan Interaction: Clicking "View Details" will redirect you to the salary details page for Zhang San. User B (Li Si) corresponds to content component 2 (salary details component). Component type: Form detail table component Attributes: Two-column layout, font size 13px, divider style, top and bottom margins 8px Data: Gross salary Y1 yuan, Individual income tax Y2 yuan, Social security and housing provident fund Y3 yuan, Net salary Y4 yuan Interaction: Click "View Details" to jump to the salary details page for the four people, including Li.

[0055] This embodiment provides a method for generating message cards. Based on the implementation of public templates, private data separation, and local replacement on the client side, it achieves personalized display of the same card message for each user without changing the overall componentized card architecture. Furthermore, the differentiated adaptation can be completed simply by configuring the corresponding private content components under the same card framework, without the need to develop and maintain a separate card template for each user.

[0056] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, after step S30, steps S60~S80 are also included: Step S60: Respond to the trigger operation for the component instance and obtain the terminal type of the current terminal.

[0057] In this embodiment, the message card supports configuring interactive event information. When a user clicks on a content element, a corresponding interactive action is executed based on the user's terminal. This triggering operation is an interactive input action performed by the user on the message card component instance that can be recognized by the client, typically a click operation, and serves as the trigger condition for initiating the component's interactive process. The terminal type is a classification identifier for the hardware form, operating system, and operating mode of the client's running device, used to distinguish terminal information configurations for different device environments.

[0058] Specifically, after rendering all components of the message card, the client registers a click event listener mechanism for all component instances that have pre-bound interactive data. This gives the corresponding components interactive attributes, ensuring that user actions can be accurately captured and located to specific component instances. When a user clicks on a target component instance, the client triggers an interactive response process, extracting the unique identifier of the target component instance from the event context information. Subsequently, the client reads the system attributes of the local runtime environment and its own package identifier, and combines information such as operating system type, screen size, and client operating mode to determine the terminal type code of the current device.

[0059] For example, in a Windows desktop enterprise IM, a user clicks the "View Details" button component marked btn_detail on the payroll notification card. After the client listens to the click event of the button, it confirms that the target component that triggered the interaction is the button component, and then reads the local system information to determine that the current terminal type is a PC desktop, thereby obtaining the terminal type information.

[0060] Step S70: Match the corresponding interaction action code and interaction action parameters in the interaction data according to the terminal type.

[0061] Interaction data is structured configuration data pre-bound to component instances, containing multiple sets of interaction rules corresponding to different terminal types. Each set of rules consists of a terminal identifier, an interaction action code, and interaction action parameters. The interaction action code is a populated value that defines the type of interaction operation, including page redirection, message receipt, etc., used to match the corresponding processing logic within the client. Interaction action parameters are the input data required to execute the interaction operation, such as the page redirection address and the receipt content.

[0062] In this embodiment, the bound interaction data is first extracted using the instance identifier of the triggered component. After matching the corresponding interaction data, the extracted interaction protocol data is parsed and split, and the terminal identifier, action code, and action parameters in each configuration are identified one by one. A mapping relationship between terminal type and interaction configuration is then constructed. Next, the current terminal type is matched with the terminal identifier in the mapping relationship to filter out the corresponding interaction action code and interaction action parameters for the current terminal. If multiple matching items exist, the optimal configuration is selected according to a preset priority.

[0063] For example, the client parses two sets of terminal configurations from the interaction data bound to the button component for viewing details: one set of terminal identifiers is PC, corresponding to action code 1 (page redirection), and the action parameter is the web address of the PC-side expense reimbursement management system. The other set of terminal identifiers is APP, corresponding to action code 1, and the action parameter is the address of the mobile H5 expense reimbursement page. After matching the current PC terminal type with the identifier, the client obtains the redirection action code and page address parameters corresponding to the PC side.

[0064] Step S80: Execute the response logic corresponding to the interaction action code and interaction action parameters to complete the component interaction corresponding to the trigger operation.

[0065] In this embodiment, upon receiving the interaction action code, the corresponding response handler is retrieved from the local logic mapping table. Simultaneously, the interaction action parameters are passed to the retrieved response logic as input data for execution, and the corresponding handler or script completes the specific business operation. After the interaction operation is completed, the client outputs operation feedback prompts to the user, such as switching to the corresponding page during page navigation or displaying a success message after submitting the operation.

[0066] This embodiment configures multi-terminal interaction rules in the component interaction data, and the client matches and executes the corresponding response logic according to the current terminal type. This enables differentiated interactive responses of the same component in the same message card on different terminals, eliminating the need for business systems to develop and push different versions of card messages for different terminals, thus improving the adaptability of message cards to complex business needs.

[0067] Based on the first embodiment of this application, in the fourth embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Furthermore, multiple component instances also include streaming output components; therefore, after step S30, steps S90~S100 are also included: Step S90: Establish a data connection with the backend streaming output service and obtain the streaming content segment to be output.

[0068] It's important to note that IM (Instant Messaging) messages typically have their complete content assembled before being sent. However, large-scale question-and-answer models primarily use streaming output. Currently, generating message cards requires waiting for the large model to finish outputting its answers before constructing the IM message and sending it, thus lengthening the user's perceived time. Furthermore, after a user asks a question, the page prevents message sending until the model's output is complete before allowing further message sending. This model is unsuitable for IM-based office work.

[0069] Furthermore, to help understand the complete processing flow of combining large-scale streaming content generation with IM message cards, please refer to... Figure 4 , Figure 4 This diagram illustrates a simplified workflow of real-time segmented rendering at the question-asking end, followed by the finalization of the official message across all terminals. Specifically, the large model service, acting as the content generation source, receives user questions and executes content generation logic, continuously generating answer text fragments segment by segment, rather than waiting for all content to be generated before outputting it all at once, thus providing the raw data source for streaming display. The streaming output service, acting as an intermediate forwarding and control layer, connects to the output port of the large model service, receives the content fragments generated segment by segment from the large model, and pushes the streaming data to the client that initiated the question in real-time via a long-connection protocol. The client-side Stream processing stage is the streaming data processing module on the client side. It receives the content fragments pushed by the streaming output service, performs data parsing, format validation, and message attribution matching, locates the corresponding card's streaming output component, and drives the interface to update content. When the card content refreshes, the client locates the corresponding streaming output component on the already rendered message card skeleton, appends the received content fragments segment by segment to the component, and performs partial rendering refresh, allowing users to see the content generation process in real-time without waiting for the complete answer to be generated. In the server-side message solidification and full-scale push process, this link faces all terminals within the session and is responsible for solidifying the complete content into a formal IM message after generation, ensuring content accessibility and message consistency for all users. Corresponding to the downward branching sub-paths in the diagram, when the large model service completes all content generation and outputs the last segment (last frame), the streaming output service recognizes the generation end signal, marking the formal termination of the streaming generation phase. Next, the IM message service assembles the complete content into formal message card data, triggering the message update logic. Finally, the IM message service pushes the formal card message carrying the complete content to all receiving terminals within the session, allowing all users in the group chat to view the complete final response. This also completes the persistent solidification of the entire message, ensuring message data traceability and consistency across multiple terminals.

[0070] Therefore, in this embodiment, the backend streaming output service is a backend service that connects to the large model generation capability and supports the return of generated content segment by segment. It can continuously push content fragments to the client through a long connection protocol. Streaming content fragments are local content units output sequentially during the large model generation process. A task scheduling mechanism prioritizing the visual window can be used to obtain streaming content fragments. When streaming card information is detected within the current message visual window, a data connection is established with the backend streaming output service. A streaming task waiting queue is constructed based on the priority order of the streaming card information. Streaming card information outside the current message visual window is placed in the streaming task waiting queue. Finally, the tasks to be processed in the streaming task waiting queue are used as the streaming card information to be output. The message visual window is the chat message area visible within the current user's screen, used to determine the range of messages the user is currently interested in. The streaming task waiting queue is an ordered queue used to temporarily store streaming card tasks for which no connection has been established, used to manage the number of concurrent connections and avoid system resource overload.

[0071] Specifically, please refer to Figure 5 After card rendering is complete, the client iterates through all card messages in the current chat session, identifying streaming cards that contain streaming output components but whose content generation is not yet complete. It records the message generation time and position coordinates of each streaming card within the chat scrolling container. Based on the scroll offset of the current chat scrolling container and the height of the visible area, the client calculates the current visible window's position range and compares the position coordinates of each streaming card with this range, filtering out streaming cards within the visible window. Finally, the streaming cards are prioritized in reverse order of their message generation time. The highest-priority streaming card within the visible window is designated as the current pending task, establishing a long connection with the backend streaming output service. Streaming cards outside the visible window are stored in a streaming task waiting queue according to their priority, without establishing connections yet. The most recently generated streaming card has the highest priority. This scheduling rule, prioritizing visible areas and new messages, maximizes the matching of users' actual browsing needs while limiting the number of concurrent connections, avoiding excessive long connections that consume message channel bandwidth and ensuring the stable operation of basic instant messaging functions.

[0072] After the connection is successfully established, the client continuously receives streaming content segments pushed by the backend streaming output service as input data to be rendered. Real-time segmented content push can be achieved through long-lived connections.

[0073] For example, a user asks three questions to the intelligent assistant in a corporate IM group. Three card messages with streaming output components are generated sequentially in the chat window. The two most recent question cards are currently visible, while the earliest one has scrolled out of the visible window. After the client identifies all the streaming cards, it determines that the most recent card in the visible window has the highest priority and establishes a data connection with the backend streaming service for it. The other card in the visible area and the card outside the window enter the streaming task waiting queue in sequence. After the connection is established, the client continuously receives the large-scale model answer fragments corresponding to that card as the streaming data to be output.

[0074] This embodiment employs a visual window-first task scheduling mechanism. By limiting the number of concurrent connections, it avoids streaming tasks consuming excessive message channel resources, ensuring that the basic sending and receiving functions of instant messaging are not affected. It does not require locking input boxes to restrict user operations, while also ensuring the streaming display experience of currently visible messages. The content that the user is viewing receives real-time rendering effects first, achieving a balance between concurrency control and user experience. Furthermore, it is compatible with the componentized card architecture, performing task scheduling only for streaming output components without affecting the normal display and interaction of other components.

[0075] Step S100: Render the streaming content fragment to be output to the streaming output component.

[0076] The streaming output component is a dedicated content component in the message card used to carry streaming generated content.

[0077] In this embodiment, each time the client receives a segment of streaming content, it locates the corresponding streaming output component in the message card based on the card message ID and component identifier corresponding to the current streaming task. This ensures that the streaming content is accurately written to the corresponding position, avoiding content crosstalk in multi-card concurrent scenarios. Subsequently, the client appends the newly received streaming content segment to the end of the existing content of the streaming output component, while updating the content display state of the component. Only the newly added content area is partially rendered and refreshed, without redrawing other components within the card or the overall card framework. This reduces the scope of interface redrawing through local incremental rendering, lowers the performance consumption during streaming display, avoids overall card flickering or layout jumps, and ensures a smooth browsing experience.

[0078] Understandably, the client continuously receives segments and appends rendering until it receives a streaming end marker, marking the content generation of the streaming card as complete.

[0079] For example, when the client receives the first segment of streaming content, "The maximum reimbursement for accommodation in first-tier cities is," it locates the streaming output component of the corresponding salary Q&A card, replaces the placeholder text with this segment of content, and renders it. Subsequently, it receives content fragments such as "500 yuan / day, 400 yuan / day for second-tier cities" and "A general VAT invoice is required," and appends them to the component one by one; until it receives the end-of-stream marker, the component content stops updating, and all the answer content is fully displayed.

[0080] This embodiment uses an incremental rendering method based on component positioning to achieve real-time dynamic display of streaming content without changing the overall card structure or redrawing other components. This significantly shortens the perceived waiting time for users and improves the response experience of large model question answering. At the same time, it reuses the incremental update capability of componentized cards, eliminating the need to develop a separate rendering framework for streaming scenes.

[0081] Furthermore, this embodiment also includes a server-side fallback mechanism, which is automatically triggered if the client fails to complete the streaming task within a preset time, ensuring the complete execution of the streaming task. Therefore, if the completion process of streaming data reception and rendering is not detected within the preset time, the server retrieves the streaming card information to be output, wherein, after taking over the streaming task, the server pulls the complete streaming output content and updates the message card.

[0082] Specifically, after the server sends a streaming card message, it starts a timer to continuously monitor the completion status of the corresponding streaming task. If no streaming task completion notification is received from the client within a preset time period, and no continuous data connection from the client is detected, it is determined that the client has not completed the streaming task normally, triggering the server takeover mechanism. After the server takes over the streaming task, it actively initiates a content retrieval request to the backend streaming output service to fully retrieve all generated content corresponding to the task. The server completes the acquisition of all content on behalf of the client, without relying on the client's connection status, ensuring that the streaming task can be completed. After the server retrieves the complete streaming content, it updates the complete content to the streaming output component of the corresponding message card in an incremental update manner and pushes the updated card message to all receiving users. The principle of this action is to solidify the final complete content into the official message content through message updates, ensuring that all users can view the complete result and making up for the content loss caused by client anomalies.

[0083] For example, after a user asks a question to the group's intelligent assistant, they immediately close the IM client and log out. If the server does not detect any streaming connection or task completion report from the client within a preset 30-second period, it triggers the takeover mechanism. The server proactively retrieves the complete answer to the question from the large model service and then updates the complete answer to the corresponding card message in the group using incremental updates. All other members in the group can see the complete answer, and the result will not be unavailable due to the questioner's offline status.

[0084] By setting up a server-side timeout takeover mechanism, common anomalies such as client disconnection, logout, and session exit in IM scenarios can be effectively addressed. This prevents streaming tasks from failing to complete due to client-side issues, thus ensuring that other users in the group cannot view the complete results. While guaranteeing the real-time streaming experience on the client side, it also takes into account the integrity of message content and the accessibility of content in multi-user scenarios, thereby improving the stability and scenario adaptability of the streaming card solution.

[0085] This embodiment provides a method for generating message cards. By combining visual window-first streaming task scheduling, component-level incremental streaming rendering, and server-side timeout fallback, it achieves large-model streaming content display in message card scenarios. It provides feedback on content progress to users without waiting for complete content generation, reducing perceived waiting time. Simultaneously, the server-side takeover mechanism further ensures the integrity of message content in multi-user scenarios and availability in abnormal scenarios. Based on a componentized card architecture, it expands the streaming content carrying capacity, improving the business adaptability and user experience of the message card system.

[0086] Based on any of the above embodiments, in the fifth embodiment of this application, the content that is the same as or similar to any of the above embodiments can be referred to the above description, and will not be repeated hereafter. In addition, the configuration data of the component instance also includes an incremental update identifier, which is associated and bound to the component instance and used to locate the target component instance to be updated after the message card is issued, so as to perform incremental content updates. Specifically, please refer to... Figure 6 The incremental update identifier is called `customKey`. When the card message is first sent, the business system pre-binds a unique `customKey` to the component instance that has subsequent update requirements. This identifier corresponds one-to-one with the component instance and is sent along with the component configuration data and rendered into the message card, serving as the accurate location basis for subsequent incremental updates. The card message supports both full update and incremental update modes, which can be flexibly selected according to the business scenario.

[0087] When the business scenario message status is simple and the update scope covers the entire card, a full update mode is adopted. A full update data packet carrying the target message's msgid and the updatecard update command is used to completely overwrite and replace the content of all components within the card message. When the card contains a large amount of component content and only a small portion needs to be updated later, an incremental update mode is adopted. The business system sends an incremental update data packet, which carries the target card's msgid, the customKey corresponding to the component to be updated, and the updateContent. After the client receives the data packet, it first locates the target card message using the msgid, then matches the target component instance bound to the corresponding identifier within the card using the customKey. Only the original content of that component is replaced with the new content in updateContent. Other components within the card not bound to the corresponding customKey (such as...) are not updated. Figure 6 Component 1 and Component 2 retain their original content and do not require redrawing, thus reducing the amount of data in the update message.

[0088] Furthermore, the incremental update data package also carries the component version number. Before the client executes the content update, it will check the validity of the version number. The content replacement will only be performed if the version number of the data package to be updated is higher than the currently rendered version of the component. In this way, the update order of component content is guaranteed in the scenario of multiple rounds of concurrent updates, and the timing disorder caused by the old version content overwriting the new version content is avoided.

[0089] This application provides a message card generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the message card generation method described in the first embodiment above.

[0090] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a message card generation device suitable for implementing embodiments of this application. The message card generation device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7The device for generating message cards shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0091] like Figure 7 As shown, the message card generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the message card generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the message card generating device to communicate wirelessly or wiredly with other devices to exchange data. Although message card generating devices with various systems are shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0092] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0093] The message card generation device provided in this application, employing the message card generation method described in the above embodiments, can solve the technical problem that the need to add new card templates when new business scenarios are added, making it difficult to maintain the needs of changing business. Compared with the prior art, the beneficial effects of the message card generation device provided in this application are the same as those of the message card generation method provided in the above embodiments, and other technical features in this message card generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0094] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0096] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the message card generation method in the above embodiments.

[0097] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM, or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0098] The aforementioned computer-readable storage medium may be included in the message card generating device; or it may exist independently and not be assembled into the message card generating device.

[0099] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the message card generating device, cause the message card generating device to: Receive card configuration information sent by the business system, wherein the card configuration information includes configuration data of multiple component instances; Based on the component identifier and component type in the configuration data, the target component is called from the preset component library; Using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, the multiple component instances are rendered to obtain the message card.

[0100] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0102] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0103] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described message card generation method. This solves the technical problem that adding new card templates when new business scenarios are added makes it difficult to maintain the needs of changing business requirements. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the message card generation method provided in the above embodiments, and will not be repeated here.

[0104] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for generating a message card, characterized in that, The method includes: Receive card configuration information sent by the business system, wherein the card configuration information includes configuration data of multiple component instances; Based on the component identifier and component type in the configuration data, the target component is called from the preset component library; Using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, the multiple component instances are rendered to obtain the message card.

2. The method for generating a message card as described in claim 1, characterized in that, The content data includes public and private content placeholders. After the step of calling the target component from the preset component library based on the component identifier and component type in the configuration data, the message card generation method further includes: Receive user-private data sent by the business system; Replace the private content placeholders in the content data with the user-private data; The step of rendering the multiple component instances to obtain the message card using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component, includes: The message card is obtained by rendering the multiple component instances using the style attributes in the configuration data, the updated content data, the interaction data, and the rendering logic corresponding to the target component.

3. The method for generating message cards as described in claim 1, characterized in that, After the step of rendering the multiple component instances using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component to obtain the message card, the message card generation method further includes: In response to a trigger operation on the component instance, obtain the terminal type of the current terminal; Match the corresponding interaction action code and interaction action parameters in the interaction data according to the terminal type; Execute the response logic corresponding to the interaction action code and the interaction action parameters to complete the component interaction corresponding to the trigger operation.

4. The method for generating a message card as described in claim 1, characterized in that, The plurality of component instances further include a streaming output component. After the step of rendering the plurality of component instances using the style attributes, content data, and interaction data in the configuration data, and the rendering logic corresponding to the target component to obtain the message card, the method for generating the message card further includes: Establish a data connection with the backend streaming output service to obtain the streaming content segments to be output; The streaming content fragment to be output is rendered to the streaming output component.

5. The method for generating a message card as described in claim 4, characterized in that, The steps of establishing a data connection with the backend streaming output service and obtaining the streaming content segment to be output include: When the presence of streaming card information is detected in the current message visual window, a data connection is established with the backend streaming output service; A streaming task waiting queue is constructed based on the priority order of the streaming card information, wherein streaming card information that is outside the current message viewing window is in the streaming task waiting queue. The tasks to be processed in the streaming task waiting queue are used as the streaming card information to be output.

6. The method for generating a message card as described in claim 4, characterized in that, After the step of establishing a data connection with the backend streaming output service when detecting the existence of streaming card information in the current message visual window, the message card generation method further includes: If the completion process of streaming data reception and rendering is not detected within a preset time period, the server obtains the streaming card information to be output sent by the server. After the server takes over the streaming task, it pulls the complete streaming output content and updates it to the message card.

7. The method for generating a message card as described in claim 1, characterized in that, The pre-built component library contains multiple standardized encapsulated basic components, including at least one of text components, image components, button components, and table components; each basic component corresponds to independent rendering logic and basic interaction logic.

8. The method for generating a message card as described in claim 1, characterized in that, The configuration data of the component instance also includes an incremental update identifier; The incremental update identifier is associated with and bound to the component instance, and is used to locate the target component instance to be updated after the message card is issued in order to perform incremental content update.

9. A message card generation device, characterized in that, The message card generation device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the message card generation method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the message card generation method as described in any one of claims 1 to 8.

Images