Interactive digital business card management system and method

Abstract

The application discloses an interactive digital business card management system and method, and belongs to the technical field of digital business card management, and the method specifically comprises the following steps: in a business workflow, a digital business card data object for binding the identity of a target user is generated based on the process identification of a task node, the digital business card data object is bound to the display interface of the task node, and a trigger rule for responding to user interactive operation is configured; when it is monitored that the target user interactive operation meets the trigger rule, a corresponding interactive component is presented in the display interface, a communication operation between the target user is executed in response to an operation instruction of the communication operation button, and the communication operation is associated with the task node and is stored; the application realizes the deep integration of business card display and business process, improves the information retrieval efficiency, can effectively reduce the risk of unauthorized communication, and is suitable for application scenarios with high concurrency and high permission isolation requirements.

Description

Technical Field

[0001] This invention belongs to the field of digital business card management technology, specifically an interactive digital business card management system and method. Background Technology

[0002] With the development of enterprise informatization and digital collaboration platforms, business communication between employees has gradually shifted from traditional offline exchanges to online collaborative tools. Against this backdrop, electronic business cards or digital business cards, as digital carriers of employee identity and contact information, are widely used in enterprise address books, social platforms, and some office systems.

[0003] Existing digital business card management methods mainly fall into two categories: one is static display business cards, which are usually permanently embedded in the user's personal homepage, organizational structure tree, or contact information page; the other is business cards generated by external independent applications, such as through QR codes or hyperlinks, which can be forwarded and recognized across multiple platforms. While these business card management methods provide basic identity display and contact information transmission functions, they suffer from the following technical shortcomings: business card data is disconnected from business processes, making it impossible to dynamically adjust the displayed content or interaction permissions based on business context. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes an interactive digital business card management system and method.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] Interactive digital business card management methods include:

[0007] In the business workflow, based on the process identifier of the task node, a digital business card data object is generated to bind the target user's identity. The digital business card data object includes an identity field and a communication field. The communication field includes a phone number field and an instant messaging account field.

[0008] The digital business card data object is bound to the display interface of the task node, and a triggering rule for responding to user interaction operations is configured. The triggering rule includes a condition identifier for determining whether to display the communication field.

[0009] When a target user interaction operation that meets the triggering rule is detected, a corresponding interactive component is presented in the display interface. The interactive component includes a communication operation button that corresponds one-to-one with the communication field.

[0010] In response to the operation command of the communication operation button, a communication operation is performed with the target user, and the communication operation is associated with and stored with the task node.

[0011] Specifically, in the business workflow, based on the process identifier of the task node, a digital business card data object for binding the target user's identity is generated, including:

[0012] Upon receiving a task call request containing a process identifier in the business workflow, the process identifier is parsed, and the set of task role identifiers corresponding to the process identifier is obtained from the mapping table.

[0013] Based on the set of task role identifiers, target user identifiers with data access permissions are selected, and the target user identifiers are bound to the current process context to form isolated session identifiers;

[0014] Based on the isolation session identifier, the access scope is limited to the personnel data partition corresponding to the session identifier, and the identity field and communication field that match the target user identifier are extracted from it.

[0015] Write the extracted identity and communication fields into the digital business card data object.

[0016] Specifically, the digital business card data object is bound to the display interface of the task node, and trigger rules for responding to user interaction operations are configured, including:

[0017] After generating the digital business card data object, determine the process node identifier corresponding to the target user;

[0018] Retrieve the preset node interface layout rule table to obtain the interface display position identifier that matches the process node identifier;

[0019] Based on the interface display location identifier, the business card data object is loaded into the target location and a business card reference tag is bound;

[0020] Load the user interaction rule set corresponding to the current process node identifier, the user interaction rule set including the trigger type and the corresponding response operation parameters;

[0021] The user interaction rule set is bound to the business card reference tag, and event listening is performed after binding.

[0022] Specifically, loading the user interaction rule set corresponding to the current process node identifier includes:

[0023] Based on the process node identifier, a rule request instruction is sent to retrieve the pre-stored rule mapping table and determine the interaction rule set identifier that matches the process node identifier;

[0024] Load the rule configuration file corresponding to the interaction rule set identifier, the rule configuration file containing trigger type identifier and response operation parameter pair;

[0025] Each set of trigger type identifier and response operation parameter pair is parsed to generate an executable rule instance, and a rule association table is established according to the business card reference tag;

[0026] Perform a state consistency check between the trigger condition corresponding to each rule instance in the rule association table and the current state of the process node identifier.

[0027] Specifically, when a target user interaction operation that meets the triggering rule is detected, the corresponding interactive component is presented in the display interface, including:

[0028] When a target user interaction operation that meets the triggering rules is detected, the permission level corresponding to the target user's user identifier is obtained based on the target user's user identifier;

[0029] Based on the permission level, query the permission policy table of the interactive components corresponding to the current process node identifier, and filter out the set of communication fields that are allowed to be displayed and their corresponding operation interface list.

[0030] Generate an interactive component instance corresponding to the set of communication fields, and limit the loading scope of the interactive component instance to the current target user session context;

[0031] The interactive component instance is mounted to the position corresponding to the business card reference label in the current interface, and the operation path allowed to be called in the operation interface list is injected into the component.

[0032] Specifically, generating an interactive component instance corresponding to the communication field set, and limiting the loading scope of the interactive component instance to the current target user session context, includes:

[0033] The current operation session identifier is generated based on the user identifier of the target user, and the session identifier is bound to the current task node identifier to form an operation context parameter set;

[0034] Based on the operation context parameter set, extract the component template corresponding to the communication field set from the interaction component template library, and generate intermediate representation data of the interaction component;

[0035] Perform permission filtering on the intermediate representation data, and remove field nodes and their associated operation paths that do not meet the permissions according to the permission level of the target user;

[0036] The intermediate representation data, after being filtered by permissions, is loaded as a runtime interactive component instance, and the instance is bound to the session identifier, restricting its component lifecycle and operation scope to the current user context.

[0037] Specifically, the interactive component instance is mounted to the position corresponding to the business card reference tag in the current interface, and the allowed operation paths in the operation interface list are injected into the component, including:

[0038] Bind the current operation session identifier to the component instance, construct a session-level component context identifier, and inject the identifier into the component runtime environment;

[0039] Based on the user's permission level, a subset of interfaces matching the permission level is selected from the list of operation interfaces, and a call path level identifier is assigned to each subset of interfaces.

[0040] The call path level identifiers are registered hierarchically, different levels of interface call boundary conditions are set, and an interface path mapping table is generated inside the component, including the correspondence between path identifiers and call authorization conditions.

[0041] The interface path mapping table is injected into the runtime parameter set of the component instance, and interface access control instructions are set to call the interface only when the boundary conditions are met and the instance is in a matching session context.

[0042] Specifically, in response to the operation command of the communication operation button, a communication operation with the target user is executed, and the communication operation is associated with and stored with the task node, including:

[0043] After receiving a communication operation instruction from the interactive component, the operation type identifier and the target user's user identifier in the communication operation instruction are parsed to form a communication request parameter set;

[0044] Based on the operation type identifier, a communication interface path compatible with the current service is matched from the communication interface mapping table, and the path is verified, including communication permission verification and interface availability detection.

[0045] After successful verification, a stop call request is sent, generating an associated communication call context;

[0046] After completing the communication action, the communication result parameters are written to the action record queue and associated with the task node identifier.

[0047] An interactive digital business card management system is used to implement the aforementioned interactive digital business card management method, including: a data processing module, a triggering module, an interaction module, and a response execution module;

[0048] The data processing module is used to generate a digital business card data object for binding the target user's identity based on the process identifier of the task node in the business workflow.

[0049] The triggering module is used to bind the digital business card data object to the display interface of the task node, and configure triggering rules for responding to user interaction operations.

[0050] The interaction module is used to present the corresponding interaction component in the display interface when a target user interaction operation that meets the triggering rule is detected.

[0051] The response execution module is used to respond to the operation command of the communication operation button, execute the communication operation with the target user, and associate and store the communication operation with the task node.

[0052] Specifically, the interaction module includes: a permission processing unit and an interaction component generation unit;

[0053] The permission processing unit is used to obtain the permission level corresponding to the target user identifier, and based on the permission level, query the interaction component permission policy table corresponding to the current process node identifier.

[0054] The interactive component generation unit is used to generate an interactive component instance corresponding to the communication field set, and to limit the loading scope of the interactive component instance to the current target user session context.

[0055] Compared with the prior art, the beneficial effects of the present invention are:

[0056] This invention proposes an interactive digital business card management system and method. By binding identity information with business process nodes, it dynamically generates business card data objects based on the user's role, task status, and permission level in the business system, and embeds these objects into a designated location in the workflow interface. When the interaction trigger conditions are met, the corresponding communication components are loaded. Simultaneously, it achieves isolated management and context binding of communication operations through permission mapping, path filtering, and behavior recording. This realizes deep integration of business card display and business processes, improves information retrieval efficiency, enhances the process sensitivity and permission control capabilities of communication entry points, effectively reduces the risk of unauthorized communication, supports the archiving and auditing of communication behaviors, and is suitable for application scenarios with high concurrency and high permission isolation requirements. Attached Figure Description

[0057] Figure 1 The flowchart of the interactive digital business card management method provided by the present invention;

[0058] Figure 2 A schematic diagram of the data structure composition of the digital business card provided by this invention;

[0059] Figure 3 The flowchart of the interactive interface call provided by this invention;

[0060] Figure 4 This is an architecture diagram of the interactive digital business card management system provided by the present invention. Detailed Implementation

[0061] The present application will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0063] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0064] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0065] Example 1

[0066] Please see Figure 1 The present invention provides an embodiment of an interactive digital business card management method, which includes the following specific steps:

[0067] Step S1: In the business workflow, based on the process identifier of the task node, a digital business card data object is generated to bind the target user's identity. The digital business card data object includes an identity field and a communication field. The communication field includes a phone number field and an instant messaging account field.

[0068] The specific steps of step S1 are as follows:

[0069] like Figure 2As shown, step S101: After receiving a task call request containing a process identifier in the business workflow, the process identifier is parsed, and the set of task role identifiers corresponding to the process identifier is obtained from the mapping table.

[0070] In this embodiment, the process identifier in the task invocation request serves as an entry parameter of the business process model and is unique. Based on the process structure preset during the process modeling stage, different process identifiers and their corresponding task role sets are statically configured in the mapping table. By parsing the process identifier, the definition of the process in the process model is located, and the set of task role identifiers contained in the process is retrieved. The retrieval process relies on key-value mapping, using the process identifier as the primary key to map out the set of role identifiers related to the process. This set is used to limit the identity range of the downstream business card object generation, ensuring that the business card information is only bound to the role actually associated with the current task.

[0071] Step S102: Based on the task role identifier set, filter out the target user identifiers with data access permissions, and bind the target user identifiers with the current process context to form an isolated session identifier.

[0072] In this embodiment, the task role identifier set only represents the logical definition of a business role and is not equivalent to the actual user who can participate in the operation. During the actual execution process, the logical role is mapped to the user identifier set with specific access capabilities through the permission filtering mechanism. The filtering is carried out by the access control list or the role-based access control model. The role-user mapping relationship is used to check whether the user is effectively authorized by the current process instance. The authorization conditions usually include the user's organization, role validity status, organizational hierarchy relationship with the process initiator, etc. After the filtering is completed, the selected target users are bound to the context. The context information includes elements such as process instance number, task node ID, initiator identifier and timestamp, which are combined to form the isolation session identifier.

[0073] Step S103: Based on the isolated session identifier, limit the access scope to the personnel data partition corresponding to the session identifier, and extract the identity field and communication field that match the target user identifier.

[0074] In this embodiment, the isolated session identifier has the ability to jointly limit user identity and process context in its structure, and can be used as a filtering condition for the access personnel information database. The database is divided into logical data partitions according to the two-dimensional label of process context + user identity. Each partition corresponds to a minimum data access unit bound to the context. By querying the partition, data-level access isolation is formed. During the extraction process, the purpose attributes of the information are distinguished according to the field classification rules. Such as position and name are included in the identity field, and mobile phone number and communication account are included in the communication field.

[0075] Step S104: Write the extracted identity field and communication field into the digital business card data object.

[0076] Step S2: Bind the digital business card data object to the display interface of the task node, and configure trigger rules for responding to user interaction operations. The trigger rules include a condition identifier for determining whether to display the communication field.

[0077] The specific steps of step S2 are as follows:

[0078] Step S201: After generating the digital business card data object, determine the process node identifier corresponding to the target user.

[0079] In this embodiment, the process node identifier is a unique logical number configured for each executable task stage, used to identify the node's position and business semantics in the flowchart. Since the same user plays different roles in different processes or different process instances, a single user identifier is insufficient to determine its node position in the current business. By using the triplet of user identifier + role identifier + process instance number, a precise match is performed in the node mapping table to obtain the unique process node identifier of the user in the current process context.

[0080] Step S202: Retrieve the preset node interface layout rule table and obtain the interface display position identifier that matches the process node identifier.

[0081] In this embodiment, the interface display location identifier serves as the positioning anchor point for the front-end rendering engine and needs to establish a mapping relationship with the business process node identifier. The interface layout rule table establishes a one-to-one or many-to-one mapping relationship between node identifiers and interface area identifiers through manual configuration or rule generation. The query operation uses the process node identifier as the primary key for indexing and returns the associated interface display area identifier. This process ensures that the business card information bound to different process nodes only appears in the specified visible area.

[0082] Step S203: Based on the interface display location identifier, load the business card data object to the target location and bind the business card reference tag.

[0083] In this embodiment, during the interface rendering process, the loading of all dynamic data objects is based on the location identifier to complete the area positioning. The display location identifier provides the structural anchor point. The business card data object needs to be encapsulated into a data fragment that conforms to the front-end rendering engine, such as a component template or HTML fragment. This data fragment is inserted into the matching DOM node or virtual node structure to achieve addressability and controllability of runtime operations. A business card reference tag is introduced as the unique identifier of the component. This tag should be named in combination with business semantics, such as merging the process node identifier and the user identifier to form a reference key with context positioning capability.

[0084] Step S204: Load the user interaction rule set corresponding to the current process node identifier. The user interaction rule set includes the trigger type and the corresponding response operation parameters.

[0085] The specific steps of step S204 are as follows:

[0086] Step S2041: Based on the process node identifier, send a rule request instruction, retrieve the pre-stored rule mapping table, and determine the interaction rule set identifier that matches the process node identifier.

[0087] In this embodiment, the process node identifier serves as a direct identifier of the business process execution status and is used as the primary key index for interaction strategy matching. The rule mapping table predefines the binding relationship between each node and the interaction control rules. During process execution, the appropriate behavior response logic can be quickly determined based on the node status. By sending a request to the rule module and specifying the process node identifier, a rule retrieval process based on key-value matching is triggered. The returned result is a unique identifier of the interaction rule set, which points to a set of loadable rule definition files.

[0088] Step S2042: Load the rule configuration file corresponding to the interaction rule set identifier. The rule configuration file contains a trigger type identifier and a response operation parameter pair.

[0089] In this embodiment, the rule configuration file is designed to configurably bind interaction event types with response behaviors, facilitating the implementation of differentiated interaction strategies in different process nodes. The trigger type identifier includes the semantic classification of user interface operation events, such as click, hover, double-click, and swipe, which serve as registration conditions for event listeners. The response operation parameters define the processing logic to be executed after identifying the corresponding event, involving operations such as data loading, interface switching, and interface calls. The rule set identifier serves as an index field pointing to a specific configuration file, and an event response mapping table is established by parsing this file. This mechanism extracts the interaction logic from the program logic into configuration items, enhancing the controllability of behavior and the adaptability of the process.

[0090] Step S2043: Parse each set of trigger type identifier and response operation parameter pairs to generate an executable rule instance, and establish a rule association table according to the business card reference tag.

[0091] In this embodiment, the trigger-response pairs in the rule configuration file are static configuration items and do not have the ability to be executed in the runtime environment. The parsing process aims to transform the static configuration structure into identifiable and schedulable rule objects, which typically includes generating listener parameters, behavior processor references, and invocation condition flags. The generated rule instances should retain event type, action entry, and execution context information. Business card reference tags are introduced as logical anchors to form a binding relationship between components and rules. The rule association table is essentially a component-level rule mapping index table. During the event triggering phase, the corresponding rule set can be quickly retrieved based on the component identifier to achieve target binding and scope limitation of interactive behaviors.

[0092] Step S2044: Perform a state consistency check between the trigger condition corresponding to each rule instance in the rule association table and the current state of the process node identifier.

[0093] In this embodiment, the triggering condition, as an important component of the rule instance, needs to establish a consistent constraint relationship with the process execution state to ensure the correctness of the behavioral logic throughout the process lifecycle. During the process, the process node goes through multiple states, such as pending execution, executing, completed, and suspended. Although the trigger type in the rule configuration file is based on the user interaction event definition, its execution permission is associated with the process state. For example, initiating a meeting should be restricted to after the node is completed, while viewing business card details can be triggered in any state. During the rule loading phase, the applicable state of each rule is verified. The current node state provided by the process engine is used as the judgment benchmark. The verification logic compares the state field attached to the rule instance with the node state. If they do not match, the event listener registration for that rule is suspended, thereby achieving contextual legality filtering for rule execution.

[0094] Step S205: Bind the user interaction rule set to the business card reference tag, and perform event listening after binding.

[0095] Step S3: When a target user interaction operation that meets the triggering rule is detected, the corresponding interactive component is presented in the display interface. The interactive component includes a communication operation button that corresponds one-to-one with the communication field.

[0096] The specific steps of step S3 are as follows:

[0097] like Figure 3 As shown, in step S301: when a target user interaction operation that meets the triggering rule is detected, the permission level corresponding to the target user identifier is obtained according to the user identifier of the target user.

[0098] In this embodiment, the user permission level is uniformly maintained by the enterprise identity management system. It is generated based on factors such as the user's position, department, security policy level, and historical behavior in the organization, and mapped to a standardized level identifier through the permission model. The permission level reflects the range of fields that the user can access and the set of operations that can be invoked. It is the core parameter for execution isolation and demotion control. When the trigger rule is met, the user's permission level is first checked through the user identifier to determine whether subsequent behavior logic is allowed, and then the boundaries of visible fields and invoked interfaces in the current context are further determined.

[0099] Step S302: Based on the permission level, query the interaction component permission policy table corresponding to the current process node identifier, and filter out the set of communication fields that are allowed to be displayed and their corresponding operation interface list.

[0100] In this embodiment, the interaction component permission policy table is constructed according to a two-dimensional structure of process node identifier × permission level. It records the data range that various users can access and the list of operation interfaces that can be called in a specific process context. The current interaction context is located by the process node identifier, and the available permission policies are located by the user permission level. This policy structure enables field display and function call to have dynamic differentiation capabilities, so that the same interaction component can present different interaction capabilities under different users or process stages. By filtering the set of allowed fields and operation interfaces, the boundaries of displayed content and behavior are limited to ensure that the component behavior complies with the principle of least privilege, and the field visibility and interface access control policies are enforced in subsequent interactions.

[0101] Step S303: Generate an interactive component instance corresponding to the set of communication fields, and limit the loading scope of the interactive component instance to the current target user session context.

[0102] The specific steps of step S303 are as follows:

[0103] Step S3031: Generate a current operation session identifier based on the user identifier of the target user, and bind the session identifier with the current task node identifier to form an operation context parameter set.

[0104] In this embodiment, the operation session identifier is a temporary identifier used to identify specific user interaction behaviors. It is used to distinguish operation instances under different times, locations, devices, and process environments. A unique identifier string is generated based on the user identifier, and this identifier is bound to the process task node to form a structured operation context parameter set. The purpose is to limit the boundary conditions of this operation. Through this context set, it is clear in the subsequent process which task node the interaction behavior should apply to, which user triggered it, and which process instance it belongs to. Based on this, processes such as field loading, permission adjudication, and event listening are executed, so that the component behavior is controlled within the scope of the current session and data out-of-bounds or incorrect command issuance is prevented.

[0105] Step S3032: Based on the operation context parameter set, extract the component template corresponding to the communication field set from the interaction component template library, and generate intermediate representation data of the interaction component.

[0106] In this embodiment, the interactive component template library pre-builds various template variations according to dimensions such as field type, permission level, and node context. The operation context parameter set provides complete constraints for the current interaction request, including the range of available fields and user level. Template extraction uses the communication field set as the search condition and matches the permission level to ensure that the selected template can cover the field requirements in terms of structure and does not load component functions beyond the permission range. After extraction, the final component is not directly output. Instead, intermediate representation data is generated as an intermediate state that bridges the template structure and the actual session data. The intermediate state encapsulates field mapping relationships, interaction event hooks, style parameters, and interface path references, and does not depend on a specific UI engine.

[0107] Step S3033: Perform permission filtering processing on the intermediate representation data, and remove field nodes and their associated operation paths that do not meet the permission requirements according to the permission level of the target user.

[0108] In this embodiment, the intermediate representation data structure is an abstract component description injected with context information on the template structure. It includes field configuration, event interface mapping, operation logic reference, etc. The core of the permission filtering process is to prune nodes in the structure that do not match the user level to prevent the leakage of unauthorized information. The filtering is based on comparing the permission tags bound to the field node and the operation path. For example, if the field instant messaging account is bound to the tag L3+ and the current user's permission is L2, the node will be automatically marked as unavailable when parsing the intermediate representation. The node and all its subordinate call paths and event binding structures will be removed from the intermediate representation.

[0109] Step S3034: Load the intermediate representation data after permission filtering into a runtime interactive component instance, and bind the instance to the session identifier, restricting its component lifecycle and operation scope to the current user context.

[0110] In this embodiment, the intermediate representation data is essentially a structured component configuration description used to decouple template and context binding logic. The process of loading it as a runtime interactive component instance is essentially to compile the static structure through the runtime engine and inject it into the interface framework, while configuring the response chain and behavior binding module to bind the component to the operation session identifier. This identifier provides the access scope, permission context, and state tracking path. After the component is loaded, all related interactive operations, data calls, and state updates must be verified and authorized through this identifier. This effectively limits the scope of component operations, prevents it from calling resources across users, processes, or nodes, and enables automatic component unloading through session expiration or switching events, achieving lifecycle management and interaction isolation control.

[0111] Step S304: Mount the interactive component instance to the position corresponding to the business card reference label in the current interface, and inject the operation path allowed to be called from the operation interface list into the component.

[0112] The specific steps of step S304 are as follows:

[0113] Step S3041: Bind the current operation session identifier to the component instance, construct a session-level component context identifier, and inject the identifier into the component runtime environment.

[0114] In this embodiment, a session-defined context identifier is formed by generating a binding structure between the session identifier and the component instance. This identifier identifies the running entity of the component and includes context information such as the current permission level, user identity, and process node identifier. After this context identifier is injected into the component's runtime environment, it is embedded as a control parameter of the execution path in the component's event listener, field access controller, and interface scheduler. All component behaviors must match this context identifier when triggered; otherwise, they will be rejected. This achieves boundary constraints on component behaviors.

[0115] Step S3042: Based on the user's permission level, select a subset of interfaces that match the permission level from the list of operation interfaces, and assign a call path level identifier to each subset of interfaces.

[0116] In this embodiment, each method in the operation interface list is mapped to a backend service path or behavior instruction. Based on the user's permission level, a subset of interfaces is filtered at runtime. The filtering rules come from the interface access policy mapping table, which maps permission levels to the set of available interfaces. After filtering, a call path level identifier is generated for the retained interfaces to determine whether the component call path matches the current permission and to indicate the call source and permission range. This achieves multi-dimensional control of interface access based on permission layering, context restriction, and behavior tracing.

[0117] Step S3043: Perform hierarchical registration of the call path level identifier, set different levels of interface call boundary conditions, and generate an interface path mapping table inside the component, including the correspondence between path identifiers and call authorization conditions.

[0118] In this embodiment, hierarchical registration uses path identifiers as indexes and explicitly defines their corresponding calling conditions and execution boundaries, including constraint parameters such as minimum permission level, allowed process state, time range, and node context. After registration, an interface path mapping table is constructed, which is a mapping relationship from path identifiers to authorized condition sets. This mapping table is maintained internally by the component and is read before the interface is triggered to verify whether the current session context meets the interface call boundary conditions.

[0119] Step S3044: Inject the interface path mapping table into the runtime parameter set of the component instance, and set the interface access control instruction to call the interface only when the boundary conditions are met and the instance is in a matching session context.

[0120] In this embodiment, the runtime parameter set stores field data and style status, and also includes behavioral control parameters, such as interface access rules. After the mapping table is injected, the component can access the restrictions of its call path in real time during runtime. Each interface is bound to a control instruction, and before the event is triggered, the consistency of the current operation context and the boundary conditions set in the mapping table is checked. The judgment criteria include: whether the current user's permission level meets the minimum level requirement, whether the process node status is in the stage allowed by the rules, whether it is the same operation session, etc. Only when multiple checks are met is the control instruction allowed to call the corresponding interface.

[0121] Step S4: Respond to the operation command of the communication operation button, execute the communication operation with the target user, and associate and store the communication operation with the task node.

[0122] The specific steps of step S4 are as follows:

[0123] Step S401: After receiving the communication operation instruction from the interactive component, parse the operation type identifier and the target user's user identifier in the communication operation instruction to form a communication request parameter set.

[0124] In this embodiment, the communication operation instruction is initiated by the front-end component and includes the operation type, target identity, and trigger context. Parsing the instruction is to transform the unstructured component behavior into identifiable communication scheduling parameters, which are then mapped to a standard category that the communication module can recognize through a rule mapping table. By extracting the user identifier of the target user as the primary key for looking up its communication fields, the final set of communication request parameters provides the input interface for communication behavior scheduling.

[0125] Step S402: Based on the operation type identifier, match a communication interface path compatible with the current service from the communication interface mapping table, and perform verification on the path, including communication permission verification and interface availability detection.

[0126] In this embodiment, the operation type identifier is a semantic mark of the behavior instruction, which is mapped to a schedulable service path by the communication interface mapping table. The table maintains a many-to-many mapping between a set of communication types and system-supported interface paths, and marks the applicable environment, authentication requirements and calling conditions for each path. The path matching process makes a comprehensive judgment based on the operation type, business deployment architecture and running node policy to ensure that the selected path is executable in the current context. The subsequent permission verification step is used to verify whether the initiator has the corresponding communication behavior permission under the current process role.

[0127] Step S403: After successful verification, send a stop call request and generate a related communication call context.

[0128] Step S404: After completing the communication behavior, write the communication result parameters into the behavior record queue and associate and bind them with the task node identifier.

[0129] Example 2

[0130] Please see Figure 4 Another embodiment of the present invention provides an interactive digital business card management system, comprising: a data processing module, a triggering module, an interaction module, and a response execution module;

[0131] The data processing module is used to generate a digital business card data object for binding the target user's identity based on the process identifier of the task node in the business workflow.

[0132] The triggering module is used to bind the digital business card data object to the display interface of the task node, and configure triggering rules for responding to user interaction operations.

[0133] The interaction module is used to present the corresponding interaction component in the display interface when a target user interaction operation that meets the triggering rule is detected.

[0134] The response execution module is used to respond to the operation command of the communication operation button, execute the communication operation with the target user, and associate and store the communication operation with the task node.

[0135] The interaction module includes: a permission processing unit and an interaction component generation unit;

[0136] The permission processing unit is used to obtain the permission level corresponding to the target user identifier, and based on the permission level, query the interaction component permission policy table corresponding to the current process node identifier.

[0137] The interactive component generation unit is used to generate an interactive component instance corresponding to the communication field set, and to limit the loading scope of the interactive component instance to the current target user session context.

[0138] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0139] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An interactive digital business card management method, characterized in that, include: In the business workflow, based on the process identifier of the task node, a digital business card data object is generated to bind the target user's identity. The digital business card data object includes an identity field and a communication field. The communication field includes a phone number field and an instant messaging account field. The digital business card data object is bound to the display interface of the task node, and a triggering rule for responding to user interaction operations is configured. The triggering rule includes a condition identifier for determining whether to display the communication field. When a target user interaction operation that meets the triggering rule is detected, a corresponding interactive component is presented in the display interface. The interactive component includes a communication operation button that corresponds one-to-one with the communication field. In response to the operation command of the communication operation button, perform a communication operation with the target user, and associate and store the communication operation with the task node; In the business workflow, based on the process identifier of the task node, a digital business card data object is generated to bind the target user's identity, including: Upon receiving a task call request containing a process identifier in the business workflow, the process identifier is parsed, and the set of task role identifiers corresponding to the process identifier is obtained from the mapping table. Based on the set of task role identifiers, target user identifiers with data access permissions are selected, and the target user identifiers are bound to the current process context to form isolated session identifiers; Based on the isolation session identifier, the access scope is limited to the personnel data partition corresponding to the session identifier, and the identity field and communication field that match the target user identifier are extracted from it. Write the extracted identity and communication fields into the digital business card data object; When a target user interaction operation that meets the triggering rule is detected, the corresponding interactive component is presented in the display interface, including: When a target user interaction operation that meets the triggering rules is detected, the permission level corresponding to the target user's user identifier is obtained based on the target user's user identifier; Based on the permission level, query the permission policy table of the interactive components corresponding to the current process node identifier, and filter out the set of communication fields that are allowed to be displayed and their corresponding operation interface list. Generate an interactive component instance corresponding to the set of communication fields, and limit the loading scope of the interactive component instance to the current target user session context; The interactive component instance is mounted to the position corresponding to the business card reference label in the current interface, and the operation path allowed to be called in the operation interface list is injected into the component.

2. The interactive digital business card management method as described in claim 1, characterized in that, Bind the digital business card data object to the display interface of the task node, and configure trigger rules for responding to user interaction operations, including: After generating the digital business card data object, determine the process node identifier corresponding to the target user; Retrieve the preset node interface layout rule table to obtain the interface display position identifier that matches the process node identifier; Based on the interface display location identifier, the business card data object is loaded into the target location and a business card reference tag is bound; Load the user interaction rule set corresponding to the current process node identifier, the user interaction rule set including the trigger type and the corresponding response operation parameters; The user interaction rule set is bound to the business card reference tag, and event listening is performed after binding.

3. The interactive digital business card management method as described in claim 2, characterized in that, The loading of the user interaction rule set corresponding to the current process node identifier includes: Based on the process node identifier, a rule request instruction is sent to retrieve the pre-stored rule mapping table and determine the interaction rule set identifier that matches the process node identifier. Load the rule configuration file corresponding to the interaction rule set identifier, the rule configuration file containing trigger type identifier and response operation parameter pair; Each set of trigger type identifier and response operation parameter pair is parsed to generate an executable rule instance, and a rule association table is established according to the business card reference tag; Perform a state consistency check between the trigger condition corresponding to each rule instance in the rule association table and the current state of the process node identifier.

4. The interactive digital business card management method as described in claim 3, characterized in that, The step of generating an interactive component instance corresponding to the set of communication fields, and limiting the loading scope of the interactive component instance to the current target user session context, includes: The current operation session identifier is generated based on the user identifier of the target user, and the session identifier is bound to the current task node identifier to form an operation context parameter set; Based on the operation context parameter set, extract the component template corresponding to the communication field set from the interaction component template library, and generate intermediate representation data of the interaction component; Perform permission filtering on the intermediate representation data, and remove field nodes and their associated operation paths that do not meet the permissions according to the permission level of the target user; The intermediate representation data, after being filtered by permissions, is loaded as a runtime interactive component instance, and the instance is bound to the session identifier, restricting its component lifecycle and operation scope to the current user context.

5. The interactive digital business card management method as described in claim 4, characterized in that, Mount the interactive component instance to the position corresponding to the business card reference label in the current interface, and inject the allowed operation paths from the operation interface list into the component, including: Bind the current operation session identifier to the component instance, construct a session-level component context identifier, and inject the identifier into the component runtime environment; Based on the user's permission level, a subset of interfaces matching the permission level is selected from the list of operation interfaces, and a call path level identifier is assigned to each subset of interfaces. The call path level identifiers are registered hierarchically, different levels of interface call boundary conditions are set, and an interface path mapping table is generated inside the component, including the correspondence between path identifiers and call authorization conditions. The interface path mapping table is injected into the runtime parameter set of the component instance, and interface access control instructions are set to call the interface only when the boundary conditions are met and the instance is in a matching session context.

6. The interactive digital business card management method as described in claim 5, characterized in that, Responding to the operation command of the communication operation button, performing a communication operation with the target user, and associating and storing the communication operation with the task node, including: After receiving a communication operation instruction from the interactive component, the operation type identifier and the target user's user identifier in the communication operation instruction are parsed to form a communication request parameter set; Based on the operation type identifier, a communication interface path compatible with the current service is matched from the communication interface mapping table, and the path is verified, including communication permission verification and interface availability detection. After successful verification, a stop call request is sent, generating an associated communication call context; After completing the communication action, the communication result parameters are written to the action record queue and associated with the task node identifier.

7. An interactive digital business card management system, used to implement the interactive digital business card management method according to any one of claims 1-6, characterized in that, include: Data processing module, triggering module, interaction module, and response execution module; The data processing module is used to generate a digital business card data object for binding the target user's identity based on the process identifier of the task node in the business workflow. The triggering module is used to bind the digital business card data object to the display interface of the task node, and configure triggering rules for responding to user interaction operations. The interaction module is used to present the corresponding interaction component in the display interface when a target user interaction operation that meets the triggering rule is detected. The response execution module is used to respond to the operation command of the communication operation button, execute the communication operation with the target user, and associate and store the communication operation with the task node.

8. The interactive digital business card management system as described in claim 7, characterized in that, The interaction module includes: a permission processing unit and an interaction component generation unit; The permission processing unit is used to obtain the permission level corresponding to the target user identifier, and based on the permission level, query the interaction component permission policy table corresponding to the current process node identifier. The interactive component generation unit is used to generate an interactive component instance corresponding to the communication field set, and to limit the loading scope of the interactive component instance to the current target user session context.

Images