Component dynamic configuration method and device for payment management system

Abstract

The invention relates to the technical field of development assistance, is suitable for the fields of finance and medical treatment, and provides a dynamic component configuration method and device for a payment management system, and the method comprises the steps: obtaining the display association information of a payment business management scene; based on the display association information, a component display logic tree is determined, and the component display logic tree is used for reflecting a component association relationship among a retrieval function component, an editing function component of a retrieval result and a data display component of the retrieval result; determining a display configuration file of the payment business management scene based on the component display logic tree; and dynamically calling a code implementation block of each component in the component display logic tree by reading the display configuration file so as to generate a function display page of the payment service management scene. According to the technical scheme, the display page meeting the requirement can be quickly generated for the payment service management scene without repeatedly writing codes, and the development difficulty and the maintenance cost are reduced.

Description

[Technical Field]

[0001] This application relates to the field of development support technology, applicable to the financial and medical fields, and particularly to a method and apparatus for dynamic configuration of components in a payment management system. [Background Technology]

[0002] Developing functional display pages for payment business management scenarios in payment management systems faces numerous challenges. Traditional development methods result in fixed and inflexible page functions. For example, components such as search functions, data display, and editing operations must be hard-coded, leading to long development cycles and difficulty in adapting to changing business needs. Furthermore, different payment scenarios, such as premium payment and medical insurance settlement, require differentiated display logic and interaction rules, and existing development methods cannot quickly respond to these changes. In addition, the complex relationships between components make manual development and adjustments prone to errors and maintenance costs high.

[0003] Therefore, how to achieve dynamic configuration and flexible assembly of function display pages in payment business management scenarios has become an urgent technical problem to be solved. [Summary of the Invention]

[0004] This application provides a method and apparatus for dynamic component configuration in a payment management system, aiming to solve the technical problem of high development and maintenance costs caused by insufficient flexibility in the development of functional display pages for payment business management scenarios in related technologies.

[0005] In a first aspect, embodiments of this application provide a method for dynamic component configuration in a payment management system, including:

[0006] Obtain display association information for payment business management scenarios, wherein the display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with payment business and payment management business;

[0007] Based on the display association information, a component display logic tree is determined. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0008] Based on the component display logic tree, a display configuration file for the payment business management scenario is determined. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0009] By reading the display configuration file, the code implementation blocks of each component in the component display logic tree are dynamically called to generate the functional display page of the payment business management scenario.

[0010] In one embodiment of this application, optionally, determining the component display logic tree based on the display association information includes:

[0011] Obtain the business processing flow of the payment business management scenario, wherein the business processing flow includes multiple business processing steps and at least one sub-step under each business processing step;

[0012] According to the hierarchical relationship and function of the business processing flow, the functional components that match the function of the step are associated according to the hierarchical relationship of the step to obtain the component display logic tree.

[0013] In one embodiment of this application, optionally, determining the display configuration file for the payment business management scenario based on the component display logic tree includes:

[0014] In the components of the component display logic tree, determine the first target component associated with each of the plurality of business processing steps and the sub-steps under the at least one business processing step;

[0015] Based on the displayed association information, the component configuration parameters for each of the first target components are determined;

[0016] The component configuration parameters of each first target component are filled into the component path corresponding to the component display logic tree to obtain the display configuration file of the payment business management scenario.

[0017] In one embodiment of this application, optionally, determining the component display logic tree based on the display association information includes:

[0018] According to the management function requirements of the payment business management scenario, extract multiple functional requirement items involved in displaying the related information. Each functional requirement item includes a parent functional requirement item and a sub-functional requirement item located under the parent functional requirement item.

[0019] Based on the requirement relationships of multiple functional requirement items, the functional components that match the parent and child functional requirement items are associated to obtain the component display logic tree.

[0020] In one embodiment of this application, optionally, determining the display configuration file for the payment business management scenario based on the component display logic tree includes:

[0021] In each component of the component display logic tree, determine the second target component associated with each of the functional requirement parent items and the functional requirement child items within the plurality of functional requirement items;

[0022] Based on the displayed association information, the component configuration parameters for each of the second target components are determined;

[0023] The component configuration parameters of each second target component are filled into the component structure corresponding to the demand association relationship to obtain the display configuration file of the payment business management scenario.

[0024] In one embodiment of this application, optionally, the step of dynamically invoking the code implementation blocks of each component in the component display logic tree by reading the display configuration file includes:

[0025] In response to the read operation of the display configuration file, a hook function that replaces the original page generation method is dynamically generated based on the display configuration file;

[0026] According to the component path or component structure displayed in the configuration file, the code implementation blocks of each component in the component display logic tree are dynamically called through the hook function to generate the functional display page of the payment business management scenario.

[0027] Secondly, embodiments of this application provide a component dynamic configuration device for a payment management system, comprising:

[0028] The display association information acquisition unit is used to acquire display association information of the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business.

[0029] The logic tree construction unit is used to determine the component display logic tree based on the display association information. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0030] The display configuration file determination unit is used to determine the display configuration file for the payment business management scenario based on the component display logic tree. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0031] The scenario dynamic development unit is used to dynamically call the code implementation blocks of each component in the component display logic tree by reading the display configuration file, so as to generate the functional display page of the payment business management scenario.

[0032] Optionally, in one embodiment of this application, the logic tree construction unit includes:

[0033] A business processing flow acquisition unit is used to acquire the business processing flow of the payment business management scenario. The business processing flow includes multiple business processing steps and at least one sub-step under each business processing step.

[0034] The step hierarchy and component association unit is used to associate functional components that match the step functions according to the step hierarchy relationship and step functions of the business processing flow, so as to obtain the component display logic tree.

[0035] Optionally, in one embodiment of this application, the display configuration file determination unit includes:

[0036] The first component association unit is used to determine, in each component of the component display logic tree, the first target component associated with each of the plurality of business processing steps and the sub-steps under the at least one business processing step.

[0037] The first configuration parameter setting unit is used to determine the component configuration parameters of each first target component based on the display association information;

[0038] The first configuration file generation unit is used to fill the component configuration parameters of each first target component into the component path corresponding to the component display logic tree to obtain the display configuration file of the payment business management scenario.

[0039] Optionally, in one embodiment of this application, the logic tree construction unit includes:

[0040] The functional requirement item extraction unit is used to extract multiple functional requirement items involved in the display of related information according to the management functional requirements of the payment business management scenario. Each functional requirement item includes a functional requirement parent item and a functional requirement sub-item located under the functional requirement parent item.

[0041] The functional requirement and component association unit is used to associate the functional components that match the parent and child functional requirements according to the requirement association relationship of multiple functional requirement items, so as to obtain the component display logic tree.

[0042] Optionally, in one embodiment of this application, the display configuration file determination unit includes:

[0043] The second component association unit is used to determine, in each component of the component display logic tree, the second target component associated with each of the functional requirement parent item and the functional requirement child item within the plurality of functional requirement items;

[0044] The second configuration parameter setting unit is used to determine the component configuration parameters of each second target component based on the display association information;

[0045] The second configuration file generation unit is used to fill the component configuration parameters of each second target component into the component structure corresponding to the demand association relationship, so as to obtain the display configuration file of the payment business management scenario.

[0046] Optionally, in one embodiment of this application, the scene dynamic development unit includes:

[0047] The hook function construction unit is used to respond to the read operation of the display configuration file and dynamically generate a hook function to replace the original page generation method based on the display configuration file.

[0048] The hook function application unit is used to dynamically call the code implementation blocks of each component in the component display logic tree according to the component path or component structure displayed in the display configuration file, so as to generate the functional display page of the payment business management scenario through the hook function.

[0049] Thirdly, embodiments of this application provide a computer device, including: 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, the instructions being configured to perform the method described in the first aspect above.

[0050] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for performing the method described in the first aspect above.

[0051] The above technical solution addresses the high development and maintenance costs caused by insufficient flexibility in the development of functional display pages for payment business management scenarios. This solution obtains display-related information from the payment business management scenario, constructs a component display logic tree, and generates display configuration files. These configuration files then serve as the driving force for assembling the underlying code implementation blocks of the components, enabling dynamic generation of functional display pages. This forms a complete dynamic configuration development process for payment business management pages. This solution transforms complex business requirements into a configurable component relationship model, allowing the payment management system to flexibly adjust page functionality according to different business scenarios, quickly generating display pages that meet requirements without rewriting code. This development model, which automatically standardizes component structures, significantly simplifies the page development process in payment business management scenarios, lowers the technical threshold and maintenance costs, and improves the system's adaptability and scalability. It enables developers to more easily handle changing business needs, achieving efficient development and flexible adjustment of functional display pages for payment business management scenarios. [Attached Image Description]

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

[0053] Figure 1 A flowchart illustrating a method for dynamic component configuration in a payment management system according to an embodiment of this application is shown;

[0054] Figure 2 A flowchart illustrating a method for dynamic component configuration in a payment management system according to another embodiment of this application is shown;

[0055] Figure 3 A flowchart of a method for dynamic component configuration for a payment management system according to another embodiment of this application is shown;

[0056] Figure 4 A block diagram of a computer device according to one embodiment of this application is shown;

[0057] Figure 5 A block diagram of a computer device according to another embodiment of this application is shown.

Detailed Implementation Methods

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] Figure 1 A flowchart of a method for dynamically configuring components in a payment management system according to an embodiment of this application is shown.

[0060] like Figure 1 As shown, a method for dynamic component configuration in a payment management system according to an embodiment of this application includes:

[0061] Step 102: Obtain the display association information of the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business.

[0062] In insurance business scenarios, payment management scenarios include, but are not limited to, premium payment record inquiry, policy renewal payment reminder, claims payment tracking, refund of surrender amount processing, installment payment plan management, agent commission settlement, group policy batch deduction, and payment anomaly warning processing.

[0063] In healthcare scenarios, payment management scenarios include, but are not limited to, outpatient registration fee payment, inpatient deposit payment, examination and testing item fees, drug cost settlement, medical insurance reimbursement difference payment, special medical service payment, remote consultation fee collection, and medical installment repayment processing.

[0064] Obtaining display-related information for payment business management scenarios aims to provide a basis for subsequent component configuration by collecting display requirement characteristics related to payment business. Specifically, display-related information mainly includes core features such as functional characteristics, data attributes, and interaction rules that need to be displayed in the payment business scenario. Functional characteristics refer to the various operational functions that the payment page needs to support. For example, premium calculation functions in insurance business or medical insurance settlement functions in medical business are typical functional characteristics. Data attributes reflect the display requirements of payment-related data. For example, insurance business needs to display data fields such as policy number and policyholder information, while medical business needs to display data content such as treatment items and cost details. Interaction rules define the logical relationship between user operations and system responses. For example, renewal payments in insurance business require verification of policy validity first, while medical insurance payments require identity authentication first. This display-related information together constitutes the complete display requirements of the payment business management scenario, providing a detailed basis for subsequent component configuration.

[0065] Displaying related information serves as the basic input for system configuration, comprehensively describing the interface display characteristics required for payment business management. By deeply exploring the display needs of payment business, it provides a precise basis for system configuration, ensuring that the functions of the subsequently generated pages are highly matched with business requirements.

[0066] Step 104: Based on the display association information, determine the component display logic tree, which is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0067] The displayed information serves as a carrier of business requirements, describing the functional characteristics and interaction rules that need to be displayed in the payment scenario, such as premium inquiry requirements in insurance business and expense settlement requirements in medical business. The component display logic tree organizes retrieval, editing, and data display components through a tree structure, clearly reflecting the hierarchy and calling relationships between components. For example, the retrieval component is associated as the root node and the data display component as the leaf node. This transforms business requirements into an executable component relationship model, providing a standardized component organization method for the payment management system, ensuring the rationality and maintainability of the page's functional structure, and laying the foundation for the generation of configuration files during subsequent development.

[0068] Step 106: Based on the component display logic tree, determine the display configuration file for the payment business management scenario. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0069] The component display logic tree defines the relationships between components, such as the calling order of the retrieval component and the data display component. The display configuration file is generated based on the component display logic tree and specifies the calling logic of each component's code implementation block; for example, executing the date retrieval before loading the table display. Thus, this structured data, the component display logic tree, can be flexibly transformed into executable configuration instructions, achieving a standardized conversion from business logic to technical solutions. This allows the payment management system to precisely control the component calling order and parameter passing through the configuration file, providing a clear execution basis for dynamic page generation.

[0070] Step 108: By reading the display configuration file, dynamically call the code implementation blocks of each component in the component display logic tree to generate the functional display page of the payment business management scenario.

[0071] The display configuration file serves as the foundation for generating the functional display pages for the aforementioned payment business management scenario, defining specific characteristics of the display pages such as component layout and invocation order. Code implementation blocks are pre-defined functional modules; for example, the search logic for date retrieval is encapsulated as a code implementation block. When execution is required, the code implementation block can be invoked, thus achieving dynamic instantiation. Therefore, by using the display configuration file as the driving basis for assembling the underlying code implementation blocks of the components, zero-code dynamic generation of payment business pages is achieved. This enables the payment management system to quickly respond to changes in the needs of different business scenarios, significantly reducing the development and maintenance costs of functional pages.

[0072] In summary, this technical solution acquires the display association information of the payment business management scenario, constructs a component display logic tree, and generates a display configuration file. Ultimately, the display configuration file serves as the driving basis for assembling the underlying code implementation blocks of the components, enabling the dynamic generation of functional display pages. This forms a complete dynamic configuration development process for payment business management pages. This solution transforms complex business requirements into a configurable component relationship model, allowing the payment management system to flexibly adjust page functionality according to different business scenarios, quickly generating display pages that meet requirements without rewriting code. Through this development model that automatically standardizes component structures, the development process of pages in the payment business management scenario is significantly simplified, reducing the technical threshold and maintenance costs. Simultaneously, it improves the system's adaptability and scalability, enabling developers to more easily cope with changing business needs and achieve efficient development and flexible adjustment of functional display pages for the payment business management scenario.

[0073] In insurance business scenarios, taking premium payment record query as an example, firstly, the system obtains display association information including the features of the premium payment record query function, policy number and payment status data attributes, and identity verification interaction rules. Then, it constructs a component display logic tree with identity verification as the root node, premium payment record retrieval as the intermediate node, and premium payment detail display as the leaf node. It also generates a display configuration file that specifies that identity verification should be performed first, then record query, and finally detail display. Finally, it dynamically calls the code implementation blocks of each component corresponding to the functions of identity verification, premium payment record retrieval, and premium payment detail display to generate a complete functional page including an identity verification area, a query condition area, and a premium payment detail display area, realizing convenient query and management of premium payment records.

[0074] In the medical expense settlement query scenario, firstly, display association information is obtained, including the features of the expense detail query function, patient medical information and expense list data attributes, and medical insurance qualification verification interaction rules. Then, based on this display association information, a component display logic tree is constructed with identity verification as the root node, expense retrieval as the intermediate node, and detail display as the leaf node. A display configuration file is generated that specifies that medical insurance qualification should be verified first, then expense should be queried, and finally details should be displayed. By dynamically calling the code implementation blocks of each component corresponding to each function such as verifying medical insurance qualification, querying expenses, and displaying details, a functional page containing an identity verification area, a query condition area, and an expense detail display area is automatically generated. This realizes a one-stop medical expense query service from identity verification to expense query and result display, enabling the page to provide the function of conveniently querying detailed medical expense expenditures.

[0075] Figure 2 A flowchart of a method for dynamically configuring components in a payment management system according to another embodiment of this application is shown.

[0076] like Figure 2As shown, a method for dynamic component configuration in a payment management system according to another embodiment of this application includes:

[0077] Step 202: Obtain the display association information of the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business.

[0078] Step 204: Obtain the business processing flow of the payment business management scenario. The business processing flow includes multiple business processing steps and at least one sub-step under each business processing step.

[0079] The business processing flow clearly defines the specific steps and hierarchical relationships in the management of payment transactions. For example, medical expense inquiries require identity verification first, followed by expense retrieval, and finally, display of details. These steps and their sub-steps constitute the complete path of business execution, reflecting the logical sequence of actual business operations. By analyzing these steps, sub-steps, and their hierarchical relationships, the flow of business execution can be accurately grasped. This provides a clear business framework for subsequent component associations, ensuring consistency between technical implementation and business processes.

[0080] Step 206: According to the hierarchical relationship and function of the business processing flow, the functional components matching the function of each step are associated according to the hierarchical relationship to obtain the component display logic tree. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0081] The hierarchical relationship of the business processing steps reveals the order in which functions are called; for example, the authentication step must be executed before the fee retrieval step. Functional components, as modular units that implement specific business functions, such as authentication components and fee query components, are linked according to the step hierarchy to form a component display logic tree. This tree structure intuitively displays the calling relationships between components, transforming the business process into an executable component relationship model. It preserves the integrity of the business logic while providing a standardized organizational method for technical implementation, significantly improving the system's maintainability and scalability.

[0082] Step 208: Among the components of the component display logic tree, determine the first target component associated with each of the plurality of business processing steps and the sub-steps under the at least one business processing step.

[0083] The component display logic tree shows that each component corresponds to a different business function implementation; for example, the identity verification component corresponds to the identity verification steps. By identifying the first target component associated with each business processing step, the mapping relationship between business steps and technical components can be accurately established. This mapping process ensures that each business step has a corresponding technical implementation, completing a precise conversion from the business dimension to the technical dimension. This provides clear component positioning for subsequent parameter configuration and function implementation, ensuring that business requirements can be fully implemented in the technical implementation.

[0084] Step 210: Based on the displayed association information, determine the component configuration parameters for each of the first target components.

[0085] The displayed information includes detailed configuration requirements for each functional component. For example, the authentication component requires configuration parameters such as authentication methods and rules. Determining the configuration parameters for each primary target component enables general components to adapt to specific business scenario requirements. These parameters guide the component's performance in specific business scenarios. This achieves business scenario-based customization of general components, maintaining component reusability while meeting the personalized needs of different businesses, significantly improving component adaptability and configuration flexibility.

[0086] Step 212: Fill the component configuration parameters of each first target component into the component path corresponding to the component display logic tree to obtain the display configuration file for the payment business management scenario. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0087] Component configuration parameters contain specific settings for components in particular business scenarios. For example, a fee query component needs to be configured with query fields and display formats. Filling these parameters into the component path corresponding to the component's display logic tree generates a complete display configuration file. This configuration file records the specific calling logic and parameter settings of each component in the business scenario. This allows the component relationship model from the design phase to be transformed into an executable configuration scheme, achieving a smooth transition from design to implementation.

[0088] Step 214: By reading the display configuration file, dynamically call the code implementation blocks of each component in the component display logic tree to generate the functional display page of the payment business management scenario.

[0089] The configuration file details the calling order and parameter settings for each component; for example, the authentication component is called first, followed by the fee query component. The code implementation blocks, as pre-built functional modules, can be dynamically loaded and executed according to the requirements of the configuration file. By dynamically assembling the functional modules from the configuration file, zero-code generation of payment business pages is achieved, enabling the development system to quickly respond to business changes. Simultaneously, it significantly reduces the development and maintenance costs of functional pages, improving overall development efficiency and system flexibility.

[0090] In summary, this technical solution acquires the display-related information and business processing flow of payment business management scenarios, constructs a component display logic tree based on the hierarchical relationship of the business processing flow steps, and generates display configuration files. Ultimately, it achieves dynamic configuration and generation of functional display pages, forming a complete payment business management system development solution. This solution centers on the hierarchical relationship of the business processing flow steps, transforming complex business processes into standardized component call logic. By accurately parsing the hierarchical relationship of each business processing step and its sub-steps, it ensures a high degree of consistency between the technical implementation and the business process. This allows the payment management system to flexibly adjust page functions and interaction flows according to different business scenarios, while significantly simplifying the development process of the payment management system and reducing its maintenance costs. It also significantly improves the development, maintenance adaptability, and scalability of the payment management system, providing efficient and reliable technical support for payment business management.

[0091] Figure 3 A flowchart of a method for dynamically configuring components in a payment management system according to another embodiment of this application is shown.

[0092] like Figure 3 As shown, a method for dynamic component configuration in a payment management system according to another embodiment of this application includes:

[0093] Step 302: Obtain the display association information of the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business.

[0094] Step 304: According to the management function requirements of the payment business management scenario, extract multiple functional requirement items involved in displaying the associated information. Each functional requirement item includes a parent functional requirement item and a sub-functional requirement item located under the parent functional requirement item.

[0095] The management function requirements reflect the core functional requirements of payment business management, such as fee inquiry and payment frequency management. By extracting parent and child functional requirements, a hierarchical structure of functional requirements can be established. For example, fee inquiry can be the parent, and fee detail inquiry and fee statistics can be the child. This hierarchical decomposition makes complex business requirements clear and manageable, providing a structured functional framework for subsequent component association and ensuring that the technical implementation can fully cover business requirements.

[0096] Step 306: According to the requirement relationships of multiple functional requirement items, associate the functional components that match the parent and child functional requirement items respectively to obtain the component display logic tree. The component display logic tree is used to reflect the component relationships of the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0097] The relationships between functional requirements reveal the calling logic of functional modules; for example, the fee query function needs to be executed before the payment processing function. Functional components, as specific implementation units, such as the fee query component and the payment processing component, are combined according to the requirement relationships to form a component display logic tree. This component organization method based on functional requirements achieves a natural mapping from business functions to technical components, maintaining the integrity of business logic while providing flexible technical implementation solutions.

[0098] Step 308: In each component of the component display logic tree, determine the second target component associated with each of the functional requirement parent items and functional requirement child items within the plurality of functional requirement items.

[0099] Each component in the component display logic tree corresponds to a different functional implementation. For example, the fee query component corresponds to the fee query functional requirement. By identifying the second target component associated with the functional requirement, a precise correspondence between functional requirements and technical implementations can be established. This correspondence ensures that each functional requirement has corresponding technical support, completing the accurate positioning from functional requirements to technical implementation, and providing a clear target object for subsequent parameter configuration.

[0100] Step 310: Based on the displayed association information, determine the component configuration parameters for each of the second target components.

[0101] The displayed information includes detailed configuration requirements for each functional component. For example, the fee query component requires configuration of parameters such as query conditions and display format. For each secondary target component, its configuration parameters need to be determined to ensure that the general component meets specific functional requirements. These parameters guide how the component operates in specific functional scenarios, thereby achieving functional requirement-driven customized component configuration, significantly improving the applicability and flexibility of the components.

[0102] Step 312: Fill the component configuration parameters of each second target component into the component structure corresponding to the requirement association relationship to obtain the display configuration file for the payment business management scenario. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0103] Component configuration parameters define the operating rules of a component in a specific functional scenario. For example, a payment processing component needs to be configured with payment methods and amount limits. Filling these parameters into the component structure corresponding to the requirement relationships generates a complete presentation configuration file. This configuration file records the specific execution logic of each component in the functional scenario, completely transforming functional requirements into executable technical solutions and providing clear operational specifications for payment business management scenarios.

[0104] Step 314: By reading the display configuration file, dynamically call the code implementation blocks of each component in the component display logic tree to generate the functional display page of the payment business management scenario.

[0105] In summary, this technical solution constructs a hierarchical structure of functional requirements based on management functional needs. Following the relationship between requirements, it organizes functional components to form a component display logic tree. Finally, it generates a dynamically executable display configuration file to achieve flexible configuration of the functional display page. This solution uses functional requirements as the core organizational unit, constructing a highly modular and scalable component system through the hierarchical relationship between parent and child functional requirements. This allows the payment management system to easily add or adjust functional modules, such as expanding sub-functions like medical insurance reimbursement calculation without affecting existing functions. Simultaneously, it ensures coordinated operation between various functional modules. In conclusion, this configuration method based on functional requirement relationships significantly improves the system's functional scalability and adaptability, enabling developers to quickly respond to changing business functional needs, significantly reducing the development cost of functional iteration, and providing highly flexible and sustainable technical support for payment business management.

[0106] It's important to emphasize that the functional requirement relationships focus on the logical dependencies between functional modules, reflecting the system's functional architecture. For example, in a healthcare payment scenario, the expense query function and the payment function have a parent-child relationship. This relationship primarily reflects the data flow and call logic between functions. This allows for the construction of a component-based organizational structure at the functional level, enabling flexible responses to functional expansion and adjustments. This design is particularly suitable for business scenarios requiring frequent addition of new functional modules. Through this relationship approach, the system can easily add new functional modules without altering the core processes, such as adding a medical insurance reimbursement calculation function as a sub-item of the payment function.

[0107] The hierarchical relationship of business processing steps emphasizes the chronological order and operational steps of the business process, reflecting the actual operational procedures of the business. For example, identity verification must be completed before a fee inquiry can be made. This ensures the standardization and completeness of the business process, and is particularly suitable for business scenarios with strict requirements on the order of operations. This step-based component organization method can enforce business rules and avoid business anomalies caused by missing steps, such as preventing the direct inquiry of fee information without verification.

[0108] In summary, functional requirement association is a horizontal combination of functions, emphasizing the completeness and scalability of functions; while business process steps are a vertical sequence of operations, emphasizing the standardization and enforceability of steps. In terms of technical implementation, functional requirement association enables the system to have better functional scalability, while business process steps ensure the compliance of business operations. In practical applications, the component organization method that emphasizes functional association or step sequence can be selected according to business characteristics, or a combination of both can be used to achieve the best results.

[0109] It should be added that, in any of the above embodiments, the step of dynamically calling the code implementation blocks of each component in the component display logic tree by reading the display configuration file includes: responding to the reading operation of the display configuration file, dynamically generating a hook function to replace the original page generation method based on the display configuration file; and dynamically calling the code implementation blocks of each component in the component display logic tree through the hook function according to the component path or component structure displayed in the display configuration file, so as to generate the functional display page of the payment business management scenario through the hook function.

[0110] The configuration file serves as a development guide, detailing execution rules such as component call order and parameter settings. For example, it specifies that the authentication component should be called first, followed by the fee query component. The component path or structure clarifies the organization of functional modules; for instance, a tree structure organizes the retrieval and display components. Building upon this, hook functions, as a dynamic interception mechanism, can replace the original page generation method, enabling flexible scheduling of the code implementation blocks of each component. By dynamically generating hook functions and executing component calls according to the configuration, runtime dynamic assembly of payment business pages is achieved. This allows the system to change page functionality and layout simply by adjusting the configuration file without modifying the source code, significantly improving system flexibility and maintainability. Simultaneously, it ensures a high degree of consistency between the functional display page and business requirements, providing an efficient and reliable page generation mechanism for payment business management.

[0111] In detail, firstly, hook functions, as a dynamic interception mechanism, take over the original page generation process, enabling fine-grained control over component calls and allowing for real-time adjustments to component combinations based on changing business needs. Secondly, this dynamic generation mechanism gives the system runtime adaptability, responding to configuration changes without recompilation, significantly shortening the feature iteration cycle. Finally, hook functions, as a unified call entry point, standardize the interaction protocol between components, ensuring the standardization of component calls while reducing the coupling between functional modules. This technical solution transforms fixed call logic into a configurable interception mechanism, giving the payment business management system flexibility and maintainability, while also ensuring system stability and performance, providing reliable technical support for dynamic page generation in complex business scenarios.

[0112] In one possible design, the calling steps can be executed in the order of the component path. The hook function instantiates and executes the code implementation blocks corresponding to each component in sequence according to the component calling path defined in the display configuration file, such as the linear path of "identity verification → fee query → payment processing". This ensures that the components are loaded and executed in a predetermined order, thereby generating a functional display page that conforms to the business process.

[0113] In another possible design, calls can be executed according to the component structure hierarchy. The tree-like component structure defined in the display configuration file can be parsed and displayed through hook functions. For example, the hierarchical relationship can be based on the retrieval component as the root node, the editing component as the middle node, and the display component as the leaf node. The code implementation blocks of each level component can be dynamically called using a depth-first or breadth-first traversal strategy to realize the parent-child relationship calls and parameter passing between components, and finally generate a complete functional display page.

[0114] This application embodiment also provides a component dynamic configuration device for a payment management system, including:

[0115] The display association information acquisition unit is used to acquire display association information of the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business.

[0116] The logic tree construction unit is used to determine the component display logic tree based on the display association information. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0117] The display configuration file determination unit is used to determine the display configuration file for the payment business management scenario based on the component display logic tree. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0118] The scenario dynamic development unit is used to dynamically call the code implementation blocks of each component in the component display logic tree by reading the display configuration file, so as to generate the functional display page of the payment business management scenario.

[0119] Optionally, in one embodiment of this application, the logic tree construction unit includes:

[0120] A business processing flow acquisition unit is used to acquire the business processing flow of the payment business management scenario. The business processing flow includes multiple business processing steps and at least one sub-step under each business processing step.

[0121] The step hierarchy and component association unit is used to associate functional components that match the step functions according to the step hierarchy relationship and step functions of the business processing flow, so as to obtain the component display logic tree.

[0122] Optionally, in one embodiment of this application, the display configuration file determination unit includes:

[0123] The first component association unit is used to determine, in each component of the component display logic tree, the first target component associated with each of the plurality of business processing steps and the sub-steps under the at least one business processing step.

[0124] The first configuration parameter setting unit is used to determine the component configuration parameters of each first target component based on the display association information;

[0125] The first configuration file generation unit is used to fill the component configuration parameters of each first target component into the component path corresponding to the component display logic tree to obtain the display configuration file of the payment business management scenario.

[0126] Optionally, in one embodiment of this application, the logic tree construction unit includes:

[0127] The functional requirement item extraction unit is used to extract multiple functional requirement items involved in the display of related information according to the management functional requirements of the payment business management scenario. Each functional requirement item includes a functional requirement parent item and a functional requirement sub-item located under the functional requirement parent item.

[0128] The functional requirement and component association unit is used to associate the functional components that match the parent and child functional requirements according to the requirement association relationship of multiple functional requirement items, so as to obtain the component display logic tree.

[0129] Optionally, in one embodiment of this application, the display configuration file determination unit includes:

[0130] The second component association unit is used to determine, in each component of the component display logic tree, the second target component associated with each of the functional requirement parent item and the functional requirement child item within the plurality of functional requirement items;

[0131] The second configuration parameter setting unit is used to determine the component configuration parameters of each second target component based on the display association information;

[0132] The second configuration file generation unit is used to fill the component configuration parameters of each second target component into the component structure corresponding to the demand association relationship, so as to obtain the display configuration file of the payment business management scenario.

[0133] Optionally, in one embodiment of this application, the scene dynamic development unit includes:

[0134] The hook function construction unit is used to respond to the read operation of the display configuration file and dynamically generate a hook function to replace the original page generation method based on the display configuration file;

[0135] The hook function application unit is used to dynamically call the code implementation blocks of each component in the component display logic tree according to the component path or component structure displayed in the display configuration file, so as to generate the functional display page of the payment business management scenario through the hook function.

[0136] The device uses the solution described in any one of the above embodiments, and therefore has all the above-mentioned technical effects, which will not be repeated here.

[0137] In another embodiment, this application provides a computer device, which may be a server, and its internal structure diagram may be as follows. Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it can implement the methods described in any of the above embodiments.

[0138] In one embodiment, this application also provides a computer device, which can be a client, and its internal structure diagram can be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it can implement the methods described in any of the above embodiments.

[0139] Any of the computer devices described in the embodiments of this application exist in various forms, including but not limited to:

[0140] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include smartphones, multimedia phones, feature phones, and low-end phones.

[0141] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, etc.

[0142] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes: audio and video players, handheld game consoles, e-books, as well as smart toys, wearable devices, and portable car navigation devices.

[0143] (4) Server: A device that provides computing services. The components of a server include a processor, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0144] (5) Other electronic devices with data interaction functions.

[0145] Additionally, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which are used to perform the following steps:

[0146] Obtain display association information for payment business management scenarios, wherein the display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with payment business and payment management business;

[0147] Based on the display association information, a component display logic tree is determined. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component.

[0148] Based on the component display logic tree, a display configuration file for the payment business management scenario is determined. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree.

[0149] By reading the display configuration file, the code implementation blocks of each component in the component display logic tree are dynamically called to generate the functional display page of the payment business management scenario.

[0150] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0151] The technical solution of this application has been described in detail above with reference to the accompanying drawings. This technical solution transforms complex business requirements into a configurable component relationship model, enabling the payment management system to flexibly adjust page functions according to different business scenarios. It allows for the rapid generation of display pages that meet specific needs without the need for repetitive coding. This development model, which automatically standardizes the component structure, significantly simplifies the page development process in payment business management scenarios, lowers the technical threshold for development and maintenance costs, and enhances the system's adaptability and scalability. This allows developers to more easily cope with changing business needs and achieve efficient development and flexible adjustment of functional display pages for payment business management scenarios.

[0152] It should be understood that although the terms "first," "second," etc., may be used to describe target components in the embodiments of this application, these target components should not be limited to these terms. These terms are only used to distinguish target components from each other. For example, without departing from the scope of the embodiments of this application, a first target component may also be referred to as a second target component, and similarly, a second target component may also be referred to as a first target component.

[0153] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0154] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0156] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0157] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0158] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for dynamic component configuration in a payment management system, characterized in that, include: Obtain display association information for payment business management scenarios, wherein the display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with payment business and payment management business; Based on the display association information, a component display logic tree is determined. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component. Based on the component display logic tree, a display configuration file for the payment business management scenario is determined. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree. By reading the display configuration file, the code implementation blocks of each component in the component display logic tree are dynamically called to generate the functional display page of the payment business management scenario.

2. The method according to claim 1, characterized in that, The step of determining the component display logic tree based on the display association information includes: Obtain the business processing flow of the payment business management scenario, wherein the business processing flow includes multiple business processing steps and at least one sub-step under each business processing step; According to the hierarchical relationship and function of the business processing flow, the functional components that match the function of the step are associated according to the hierarchical relationship of the step to obtain the component display logic tree.

3. The method according to claim 2, characterized in that, The step of determining the display configuration file for the payment business management scenario based on the component display logic tree includes: In the components of the component display logic tree, determine the first target component associated with each of the plurality of business processing steps and the sub-steps under the at least one business processing step; Based on the displayed association information, the component configuration parameters for each of the first target components are determined; The component configuration parameters of each first target component are filled into the component path corresponding to the component display logic tree to obtain the display configuration file of the payment business management scenario.

4. The method according to claim 1, characterized in that, The step of determining the component display logic tree based on the display association information includes: According to the management function requirements of the payment business management scenario, extract multiple functional requirement items involved in displaying the related information. Each functional requirement item includes a parent functional requirement item and a sub-functional requirement item located under the parent functional requirement item. Based on the requirement relationships of multiple functional requirement items, the functional components that match the parent and child functional requirement items are associated to obtain the component display logic tree.

5. The method according to claim 4, characterized in that, The step of determining the display configuration file for the payment business management scenario based on the component display logic tree includes: In each component of the component display logic tree, determine the second target component associated with each of the functional requirement parent items and the functional requirement child items within the plurality of functional requirement items; Based on the displayed association information, the component configuration parameters for each of the second target components are determined; The component configuration parameters of each second target component are filled into the component structure corresponding to the demand association relationship to obtain the display configuration file of the payment business management scenario.

6. The method according to any one of claims 1 to 5, characterized in that, The step of dynamically calling the code implementation blocks of each component in the component display logic tree by reading the display configuration file includes: In response to the read operation of the display configuration file, a hook function that replaces the original page generation method is dynamically generated based on the display configuration file; According to the component path or component structure displayed in the configuration file, the code implementation blocks of each component in the component display logic tree are dynamically called through the hook function to generate the functional display page of the payment business management scenario.

7. A component dynamic configuration device for a payment management system, characterized in that, include: The display association information acquisition unit is used to acquire display association information for the payment business management scenario. The display association information is used to reflect the characteristics of the display content required by the payment business management scenario and associated with the payment business and payment management business. The logic tree construction unit is used to determine the component display logic tree based on the display association information. The component display logic tree is used to reflect the component association relationship between the retrieval function component, the retrieval result editing function component, and the retrieval result data display component. The display configuration file determination unit is used to determine the display configuration file for the payment business management scenario based on the component display logic tree. The display configuration file is used to reflect the calling logic of the code implementation blocks corresponding to each component under the component association relationship defined by the component display logic tree. The scenario dynamic development unit is used to dynamically call the code implementation blocks of each component in the component display logic tree by reading the display configuration file, so as to generate the functional display page of the payment business management scenario.

8. The apparatus according to claim 7, characterized in that, The logic tree construction unit includes: A business processing flow acquisition unit is used to acquire the business processing flow of the payment business management scenario. The business processing flow includes multiple business processing steps and at least one sub-step under each business processing step. The step hierarchy and component association unit is used to associate functional components that match the step functions according to the step hierarchy relationship and step functions of the business processing flow, so as to obtain the component display logic tree.

9. A computer device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, the instructions being configured to cause the processor to perform the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions configured to perform the method as described in any one of claims 1 to 6.

Images