Insurance application page generation method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a method and device for generating an insurance application page, electronic equipment and a storage medium, which belong to the technical field of computers and are applied to the field of financial technology. The method comprises: in response to an insurance application business request of an insurance application object, constructing a page context object according to the insurance application business request, and determining an insurance application business process according to the page context object; obtaining an insurance application page template according to the insurance application business request, and mapping a business node of the insurance application business process to a template slot of the insurance application page template; obtaining an insurance application business rule according to the business node, determining a page element according to the insurance application business rule, obtaining a page component of the page element and a component configuration of the page component; determining a page layout structure of the page component according to a slot attribute of the template slot and the component configuration; and performing page rendering on the page component according to the page layout structure and the component configuration to obtain an insurance application page of the business node. The embodiments of the present application can improve the flexibility of generating an insurance application page.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the field of financial technology, and particularly to a method, apparatus, electronic device, and storage medium for generating insurance application pages. Background Technology

[0002] In the insurance industry, insurance transactions are primarily conducted online through application pages. Traditional application pages often employ static or simple dynamic pages, with forms, buttons, and other page elements hard-coded into the page using static or semi-static methods, resulting in high coupling between page elements. This page design makes it difficult to dynamically adjust the application page according to the needs of the application process, leading to low flexibility in application page generation. Therefore, improving the flexibility of application page generation has become an urgent problem to be solved. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, electronic device, and storage medium for generating insurance application pages, aiming to improve the flexibility of insurance application page generation.

[0004] To achieve the above objectives, a first aspect of this application proposes a method for generating an insurance application page, the method comprising: In response to an insurance application request from an insured party, a page context object is constructed based on the insurance application request, and an insurance application process is determined based on the page context object; wherein, the insurance application process includes business nodes; The insurance application page template is obtained according to the insurance application request, and the business node is mapped to the template slot of the insurance application page template; wherein, the template slot has a slot attribute; Obtain the insurance business rules based on the business nodes, determine the page elements based on the insurance business rules, and obtain the page components of the page elements and the component configuration of the page components. Based on the slot attributes and the component configuration, determine the page layout structure of the page component in the template slot; According to the page layout structure and component configuration, the page components are rendered to obtain the insurance application page of the business node.

[0005] In some embodiments, constructing a page context object based on the insurance application request includes: Extract the insurance product identifier, insurance channel identifier, and the object identifier of the insured from the insurance application request; Obtain the insured product data based on the insured product identifier; Obtain channel configuration data based on the insurance channel identifier; Obtain the object profile data of the insured object based on the object identifier; The page context object is determined based on the insured product data, the channel configuration data, and the object profile data.

[0006] In some embodiments, obtaining the object profile data of the insured object based on the object identifier includes: Obtain the insurance data of the insured object based on the object identifier; A risk assessment is performed on the insurance data to obtain the risk assessment data of the insured. The object profile data is constructed based on the risk assessment data.

[0007] In some embodiments, determining the page layout structure of the page component in the template slot based on the slot attribute and the component configuration includes: The page position of the page component is determined based on the slot attribute and the component configuration. The component dependencies between the page components are determined based on the component configuration. The page layout structure is determined based on the page position and the component dependencies.

[0008] In some embodiments, rendering the page components according to the page layout structure and the component configuration to obtain the insurance application page of the business node includes: Based on the component configuration, the page component is mounted to the page layout structure to obtain the reference component; Obtain the page rendering stage of the reference component and the additional rendering rules of the reference component in the page rendering stage; During the page rendering stage, the reference component is rendered according to the component configuration and the additional rendering rules to obtain the insurance application page.

[0009] In some embodiments, mounting the page component to the page layout structure according to the component configuration to obtain a reference component includes: The page components are categorized according to their configurations to obtain their component categories. The page components are filtered according to the component categories to obtain initial components; Determine the layout area of ​​the initial component in the page layout structure; The initial component is attached to the layout area to obtain the reference component.

[0010] In some embodiments, after rendering the page components according to the page layout structure and the component configuration to obtain the insurance application page of the business node, the method further includes: Triggered by a component operation on the page component, a component state change event of the page component is generated; Update the component state of the page component according to the component state change event, and save the component state to the preset storage space; In response to the breakpoint of the business node, the component state is read from the preset storage space, and the page component is rendered according to the read component state to obtain the rendered component; The insurance application page is updated according to the rendering component.

[0011] To achieve the above objectives, a second aspect of this application provides an insurance application page generation apparatus, the apparatus comprising: The request receiving module is used to respond to the insurance application request of the insured object, construct a page context object, and determine the insurance application process based on the page context object; wherein, the insurance application process includes business nodes; The mapping module is used to obtain the insurance application page template and map the business node to the template slot of the insurance application page template; wherein, the template slot has a slot attribute; The acquisition module is used to acquire insurance business rules based on the business node, determine page elements based on the insurance business rules, and acquire page components of the page elements and component configurations of the page components. The determining module is used to determine the page layout structure of the page component in the template slot based on the slot attributes and the component configuration; The rendering module is used to render the page components according to the page layout structure and the component configuration to obtain the insurance application page of the business node.

[0012] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0013] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0014] The insurance application page generation method, device, electronic device, and computer-readable storage medium proposed in this application improve the flexibility of page generation by dynamically generating an insurance application page based on the insurance application request of the insured object. To achieve dynamic orchestration of business logic, a page context object is constructed based on the insurance application request, and the business nodes of the insurance application process are determined based on the page context object, thereby upgrading the insurance application process from a static page stack to a dynamic state machine. To adapt the insurance application page to business requirements, an insurance application page template is obtained based on the insurance application request, and business nodes are mapped to template slots in the insurance application page template. Since insurance application rules change frequently, to facilitate flexible page adjustments, the insurance application rules are decoupled from the page. The insurance application rules are obtained based on the business nodes, and page elements are determined based on the insurance application rules. The page components of the page elements and their component configurations are obtained. By designing page elements in a component-based manner, the reuse, dynamic loading, and rapid updating of page elements can be achieved, thereby improving the design and maintenance efficiency of the insurance application page. To generate refined pages, the page layout structure of page components in the template slots is determined based on the slot attributes and component configuration. The page components are then rendered according to the page layout structure and component configuration to obtain the insurance application page for the business node. This enables the generation of insurance application pages that meet business needs in a rapidly changing insurance business environment, improving the flexibility of insurance application page generation. Attached Figure Description

[0015] Figure 1 This is a flowchart of the insurance application page generation method provided in the embodiments of this application; Figure 2 yes Figure 1 The flowchart of step S110 in the middle; Figure 3 yes Figure 2 The flowchart of step S240 in the text; Figure 4 yes Figure 1 The flowchart of step S140 in the middle; Figure 5 yes Figure 1 The flowchart of step S150 in the middle; Figure 6 yes Figure 5 The flowchart of step S510 in the text; Figure 7 This is another flowchart of the insurance application page generation method provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the insurance application page generation device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0016] 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.

[0017] It should be noted that 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 may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] In the insurance industry, insurance transactions are primarily conducted online through application pages. These transactions involve areas such as financial compliance, user conversion, risk control, and fund security, making the design and management of application pages a complex and critical aspect. Traditional application pages often employ static or simple dynamic pages, with forms, buttons, and prompts hard-coded into the page using static or semi-static methods. This results in high coupling between page elements, making element reuse difficult. When application requirements change, the entire page needs to be updated or modified, increasing maintenance costs and error risks. This makes it difficult for application pages to dynamically adjust to changing needs, resulting in low flexibility in application page generation. Therefore, improving the flexibility of application page generation has become a pressing issue.

[0020] Based on this, embodiments of this application provide a method for generating an insurance application page, an apparatus for generating an insurance application page, an electronic device, and a computer-readable storage medium, aiming to improve the flexibility of insurance application page generation.

[0021] The insurance application page generation method, insurance application page generation device, electronic device, and computer-readable storage medium provided in this application embodiment are specifically described through the following embodiments. First, the insurance application page generation method in this application embodiment is described.

[0022] The insurance application page generation method provided in this application relates to the field of computer technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the insurance application page generation method, but is not limited to the above forms.

[0023] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0024] Figure 1 This is an optional flowchart of the insurance application page generation method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S110 to S150.

[0025] Step S110: In response to the insurance application request from the insured, construct a page context object based on the insurance application request, and determine the insurance application process based on the page context object; wherein, the insurance application process includes business nodes; Step S120: Obtain the insurance application page template according to the insurance application business request, and map the business node to the template slot of the insurance application page template; wherein, the template slot has a slot attribute; Step S130: Obtain the insurance business rules according to the business nodes, determine the page elements according to the insurance business rules, and obtain the page components of the page elements and the component configuration of the page components. Step S140: Determine the page layout structure of the page components in the template slots based on the slot attributes and component configurations; Step S150: Render the page components according to the page layout structure and component configuration to obtain the insurance application page for the business node.

[0026] Steps S110 to S150 as shown in the embodiments of this application construct the insurance application page by adopting an architecture design of templates, rule mapping, and page element componentization. This allows the insurance application page to be dynamically adjusted according to business needs, avoiding problems such as poor scalability, high maintenance costs, and cumbersome and error-prone page modifications caused by hard coding.

[0027] In step S110 of some embodiments, the insurance application request is an instruction that triggers the generation of the insurance application page, used to indicate the insurance application needs of the insured object. It includes all necessary input parameters generated by the insurance application page, such as the insurance product identifier, the insurance channel identifier, and the insured object's object identifier. The insurance product identifier is a product ID, used to uniquely identify the insurance product the insured object wants to apply for; the insured object is the user conducting the insurance business. The insurance channel identifier is a channel ID, used to uniquely identify the insured object's application entry point, such as an insurance business platform or a mini-program. The object identifier is a user ID, used to uniquely identify the insured object.

[0028] Traditional insurance application pages employ a static design, resulting in a high degree of coupling between page elements and page structure. Modifying one page element often necessitates simultaneous adjustments to multiple related pages, making it difficult to adapt to frequent changes in insurance application requirements. For example, when an insurance institution adds a new insurance product, the entire set of application pages related to that product must be redesigned and developed, leading to long development cycles and low efficiency. To achieve dynamic generation of application pages, applicants can send an application request to the insurance business platform through a specific application portal. Upon receiving the request, the platform retrieves key business data such as user information (age, occupation, health status, etc.) and product information (product name, product type, premium calculation rules) based on the request. This data is then encapsulated into standardized objects to obtain a page context object, which is a structured data encapsulation built upon the key business data. The page context object is then input into a rule matching engine for condition matching and logical calculations, resulting in a process template that matches the application request. This process template defines the insurance application process, thus determining the process that meets the business requirements. The insurance application process is a series of ordered steps designed to complete the insurance application process. The insurance application process includes at least one business node, and when there are multiple business nodes, there is a business execution order between the business nodes.

[0029] For example, in a scenario where an insurance application request instructs the insured to apply for insurance, if the rule matching engine determines that the product type is accident insurance and the insured is under 18 years old based on the page context object, the matched insurance application process is as follows: identity verification → personal information filling → guardian information filling → health declaration → premium calculation → payment → policy generation. Identity verification and personal information filling are business nodes.

[0030] In a scenario where an insurance application request instructs the insured to inquire about their personal insurance policy, if the rule matching engine determines, based on the page context, that the insured is a logged-in, verified user and the inquiry channel is an application provided by an insurance institution, the matched insurance application process will be: identity verification → insurance list query → policy details display → download or share the electronic policy. Identity verification and insurance list query are the business nodes.

[0031] Please see Figure 2 In some embodiments, step S110 may include, but is not limited to, steps S210 to S250: Step S210: Extract the product identifier, channel identifier, and object identifier of the insured from the insurance application request; Step S220: Obtain the insured product data based on the insured product identifier; Step S230: Obtain channel configuration data based on the insurance channel identifier; Step S240: Obtain the object profile data of the insured object based on the object identifier; Step S250: Determine the page context object based on the insured product data, channel configuration data, and object profile data.

[0032] In step S210 of some embodiments, the insurance application request includes all the necessary input parameters required for page generation. In order to construct the page context object, the product ID, channel ID and user ID are extracted from the insurance application request to obtain the insurance product identifier, the insurance channel identifier and the object identifier of the insured object.

[0033] In step S220 of some embodiments, based on the insured product identifier, the interface is called to query the full data of the insurance product indicated by the insured product identifier, such as the product coverage scope, premium calculation method, etc., to obtain the insured product data.

[0034] In step S230 of some embodiments, based on the insurance channel identifier, the interface is called to query the exclusive configuration information of the insurance channel indicated by the insurance channel identifier, such as the page display method, business processing permissions, and handling fee ratio, to obtain the channel configuration data.

[0035] In step S240 of some embodiments, based on the object identifier, an interface is called to query the user profile of the insured object to obtain object profile data. The object profile data is used to characterize the structured user features of the insured object, which may include user attribute features, risk features, behavioral preferences, etc.

[0036] In step S250 of some embodiments, a page context object is constructed by combining key data such as insured product data, channel configuration data, and object profile data.

[0037] Through the above steps S210 to S250, a page context object can be constructed, which is used to realize the dynamic rendering of the insurance application page and the execution of business logic.

[0038] Please see Figure 3 In some embodiments, step S240 may include, but is not limited to, steps S310 to S330: Step S310: Obtain the insurance data of the insured object based on the object identifier; Step S320: Perform a risk assessment on the insurance data to obtain the risk assessment data of the insured; Step S330: Construct object profile data based on risk assessment data.

[0039] In step S310 of some embodiments, the interface is called based on the object identifier to query the insured object's historical insurance records, claims records, and other data related to the insurance business, thereby obtaining the insurance data. If the insured object has no insurance data, an empty dataset is returned, and the object profile data is assumed to be the first-time insured object, generating an insurance business process that satisfies the first-time insurance business logic.

[0040] In step S320 of some embodiments, the insurance application data is input into a risk assessment model for risk assessment to obtain risk assessment data for the insured. The risk assessment data can be presented as a risk score or a risk level. The risk assessment model can be a regression model or a classification model. A regression model outputs a risk score based on the insurance application data, while a classification model outputs a risk level based on the insurance application data. Risk levels include high risk, medium risk, and low risk.

[0041] In step S330 of some embodiments, risk assessment data is used as object profile data. To achieve a comprehensive portrayal of the insured, basic user information can be extracted from the insurance data, and a behavioral analysis model can be used to analyze the insurance data to obtain the insured's insurance preferences. The behavioral analysis model can be selected according to the actual situation; for example, a sequence analysis model, clustering model, etc., can be used. Insurance preferences are used to indicate the insured's insurance behavior patterns, such as product preferences, channel preferences, price preferences, etc. Risk assessment data, basic user information, and insurance preferences are used as object profile data.

[0042] Steps S310 to S330 above construct user profiles based on insurance data to drive the dynamic generation of personalized insurance application pages.

[0043] In step S120 of some embodiments, considering that there are many types of insurance products, different insurance channels, and different user business needs, a fixed page cannot meet all scenarios. In this embodiment, page templates are pre-configured to quickly adapt to the personalized insurance needs of different products, different channels, and different users.

[0044] Specifically, key parameters of the insurance application request are extracted, such as the insurance product identifier, insurance channel identifier, insured object identifier, and business type, to obtain the business request parameters. The rule matching engine then uses these parameters to obtain the insurance application page template and adaptively matches a template that meets the insurance application requirements. The insurance application page template has template slots, which are dedicated placeholder areas reserved within the template to hold business node content. These slots have slot attributes, which are the specific rules and attribute parameters configured for each slot to determine the display format, data requirements, and interaction logic of the content within the slot. Slot attributes may include data types (such as text, number, date, single selection, multiple selection, uploaded attachments, etc.), mandatory field validation rules, content length limits, format specifications (such as contact information format, bank card number format), display permissions (such as show only, editable, hidden), interaction logic (such as click-to-redirect, pop-up prompts, linked validation), business-related fields, and compliance display requirements.

[0045] Based on the order of business execution, the business nodes are mapped to the corresponding template slots on the insurance application page template, from first to last. For example, if the business nodes in the insurance application process are product display → health declaration → premium calculation → payment confirmation, then the product display node, health declaration node, premium calculation node, and payment confirmation node are mapped to slot 1, slot 2, slot 3, and slot 4 respectively, according to the order of business execution.

[0046] In step S130 of some embodiments, the high coupling between page elements in a traditional page leads to significant time and human resources being required for page updates and maintenance. To enable the insurance application page to flexibly adapt to dynamic changes in insurance application needs, this application embodiment employs a front-end framework to componentize page elements such as forms, buttons, prompts, and validation rules. Each page element is designed as an independent component, with a clearly defined function and interface, supporting dynamic loading and reuse, and enabling rapid adaptation to changes in insurance application needs. Componentization allows page elements to be reused multiple times, reducing repetitive development work. Simultaneously, each component can be developed and tested independently, reducing development complexity and significantly improving development efficiency. Furthermore, the insurance application process is divided into multiple steps. Through step decomposition and dynamic arrangement of step-by-step components, flexible configuration and progressive guidance of the insurance application process can be achieved, reducing user operational complexity.

[0047] Different business nodes have different business rules. To ensure the smooth operation of the insurance application process, each business node needs a unique page format that conforms to its business rules. Insurance application business rules can be obtained based on the business node. These rules restrict the flow of the business node's process, data validation rules, and page display logic. They are the pre-defined business logic, validation conditions, access control, display strategies, and process jump constraints for each business node in the insurance application process. Insurance application business rules can be customized according to actual needs. For example, insurance application business rules can be set as follows: Rule 1: For individuals over 50 years of age, display the extended health declaration form; Rule 2: If the insured amount exceeds 1 million, a manual underwriting process will be triggered; Rule 3: If the underwriting conclusion is an additional charge, display the additional charge explanation component; Rule 4: If there are abnormalities in the health declaration, the supplementary declaration component will be displayed.

[0048] The page elements that need to be loaded for each business node are determined based on the constraints defined in the insurance business rules. For example, if the insurance business rule requires the insured to be between 18 and 60 years old, then the page elements would include an age input box and an age validation prompt. The page components corresponding to the page elements and their component configurations are obtained. Component configurations are the configuration information for the page components, which may include style parameters, content parameters, validation parameters, and interaction parameters. Style parameters define the visual appearance of the component, such as its width and height, font color, and border style. Content parameters define the data information displayed by the component, such as input box type, option list, and default fill content. Validation parameters define the validity rules for the data information, such as data format validation, length limits, numerical ranges, and mandatory field validation. Interaction parameters define the response behavior of the component, such as show / hide conditions, linkage trigger conditions, jump logic, operation permissions, and prompt messages.

[0049] To ensure that the display format, arrangement, and interactive areas of page components match the template slots, this application embodiment combines the slot attributes of the template slots and the component configuration of the page components to determine the page layout structure of the page components in the template slots, so as to obtain a page structure with reasonable, orderly, and uniform component display, and to meet the differentiated layout requirements under different business scenarios.

[0050] Please see Figure 4 In some embodiments, step S140 may include, but is not limited to, steps S410 to S430: Step S410: Determine the page position of the page component based on the slot attributes and component configuration; Step S420: Determine the component dependencies between page components based on the component configuration; Step S430: Determine the page layout structure based on page position and component dependencies.

[0051] In step S410 of some embodiments, the component configuration and slot attributes are compared. If the component configuration meets the constraints defined by the slot attributes, the placement position of the page component in the template slot is determined according to the matching result, and the page position is obtained.

[0052] In step S420 of some embodiments, the component configuration defines the dependencies between components. The dependencies between business components are obtained from the component configuration to obtain component dependencies. Component dependencies include data dependencies, explicit / implicit dependencies, validation dependencies, linkage dependencies, and sequence dependencies. Data dependencies refer to the association between business components in business content; for example, the data of component A is the input of component B. For instance, the insured amount data determined by the insured amount selection component is the input of the premium calculation component. Explicit / implicit dependencies mean that the display or hidden state of one business component depends on the value or operation result of another business component. For example, the value of component A controls whether component B is displayed or hidden. For instance, when the user selects "No" in the "Do you have social security?" component, the "Social Security Information Entry" component is hidden; when "Yes" is selected, the "Social Security Information Entry" component is displayed for filling in. Validation dependencies mean that the validation rules, whether submission is allowed, and whether a field is mandatory for one business component depend on the data result of another business component. For example, component B can only operate after component A passes validation. For example, after passing the health declaration, the payment button is activated. Linkage dependency refers to a change in one business component triggering a reset or update of data, options, or display results in another business component. For example, a change in component A triggers a reset or update in component B. For example, a change in age triggers a reset of the coverage amount tier. Sequential dependency refers to a situation where the display order of components, the order of operations, or the order of process jumps are subject to sequential constraints. For example, component B can only be accessed after component A is completed. For example, the policyholder's information must be completed before the insured's information can be accessed.

[0053] In step S430 of some embodiments, the page positions of each page component in the template slot and the component dependencies between each page component are used as the page layout structure.

[0054] Through steps S410 to S430, a personalized page layout structure that meets business needs can be generated, thereby satisfying the differentiated layout requirements under different business scenarios.

[0055] Please see Figure 5 In some embodiments, step S150 may include, but is not limited to, steps S510 to S530: Step S510: Mount the page component to the page layout structure according to the component configuration to obtain the reference component; Step S520: Obtain the page rendering stage of the reference component and the additional rendering rules of the reference component in the page rendering stage; Step S530: During the page rendering stage, the reference component is rendered according to the component configuration and additional rendering rules to obtain the insurance application page.

[0056] In step S510 of some embodiments, a layout area is determined based on the page position in the page layout structure. The component mounting order is determined based on the component dependencies between page components in the page layout structure. The component mounting order is as follows: dependent preceding components are mounted first, followed by dependent components. According to the component mounting order and component configuration, page components are mounted to the layout area in the page layout structure to obtain reference components.

[0057] In step S520 of some embodiments, to optimize page generation performance, ensure component rendering accuracy, and improve user experience, it is necessary to define the page rendering stage of the reference component and obtain the additional rendering rules for the reference component in the page rendering stage. The page rendering stage indicates the order in which page components are rendered on the page. For example, a product page has three rendering stages: skeleton rendering (stage 1), core content rendering (stage 2), and secondary content rendering (stage 3). The navigation bar is rendered in stage 1, the product list is rendered in stage 2, and recommended products are rendered in stage 3. Additional rendering rules are constraints added to the reference component beyond the basic rendering logic, which can optimize page performance. Additional rendering rules can be empty or set according to actual conditions. For example, additional rendering rules can be set as follows: Rule 1: Encrypt sensitive data such as ID card numbers; Rule 2: Employ content security strategies to prevent malicious attacks; Rule 3: Use acceleration techniques to speed up the loading of static resources; Rule 4: Use layout techniques such as flexbox layout and grid layout to achieve multi-device adaptation of the page.

[0058] In step S530 of some embodiments, based on the front-end framework, during the page rendering stage, the reference component is rendered into an interactive front-end page according to the component configuration and additional rendering rules, thereby forming a complete insurance application page.

[0059] Steps S510 to S530 above, by introducing a rendering stage and additional rendering rules, can effectively improve page rendering performance.

[0060] Please see Figure 6 In some embodiments, step S510 may include, but is not limited to, steps S610 to S640: Step S610: Classify the page components according to the component configuration to obtain the component category of the page components; Step S620: Filter page components according to component category to obtain initial components; Step S630: Determine the layout area of ​​the initial component in the page layout structure; Step S640: Mount the initial component to the layout area to obtain the reference component.

[0061] In step S610 of some embodiments, the business type of the page component is defined in the component configuration, which can distinguish whether the page component is a critical component or a non-critical component. The page component is classified according to the business type defined in the component configuration to obtain the component category of the page component. The component category is either a critical component or a non-critical component.

[0062] In step S620 of some embodiments, network fluctuations and resource loading failures may occur during page generation, and browser bandwidth resources are limited. To improve page rendering performance, this application embodiment prioritizes loading critical components and delays loading non-critical components, allocating page loading resources preferentially to critical components to avoid page lag. After the critical components are loaded, users can immediately see the core functions, such as filling in information and viewing premiums. Even if non-critical components have not yet been loaded, it does not affect the core business process, thus improving the user experience. Specifically, page components classified as critical components are used as initial components.

[0063] In step S630 of some embodiments, the layout area is determined based on the page position of the initial component in the page layout structure.

[0064] In step S640 of some embodiments, the component mounting order is determined based on the component dependencies between the initial components in the page layout structure. The initial components are then mounted to the layout area according to the component mounting order and the component configuration of the initial components, resulting in a reference component.

[0065] Steps S610 to S640 above improve the user experience by prioritizing the loading of key components, thus avoiding page lag caused by simultaneous rendering and calculation of components.

[0066] Please see Figure 7 In some embodiments, after step S150, the insurance application page generation method may also include, but is not limited to, steps S710 to S740: Step S710 is triggered by a component operation on a page component, generating a component state change event for the page component; Step S720: Update the component state of the page component according to the component state change event, and save the component state to the preset storage space; Step S730: In response to the breakpoint of the business node, read the component state from the preset storage space, and render the page component according to the read component state to obtain the rendered component. Step S740: Update the insurance application page according to the rendering component.

[0067] In step S710 of some embodiments, a component state change event is generated by a component operation on a page component in the insurance application page, such as inputting information, selecting an insurance type, or clicking a button. It should be noted that user-initiated operations such as input, selection, and clicking, or passive operations such as page loading and rule validation, can all trigger state changes. The component state change event is used to indicate a change in the internal state of a business component and serves as a notification mechanism for state changes, notifying other components or logic to update synchronously. For example, if the insurance amount is modified on the insurance application page, the form component will trigger an amount change event, and the premium calculation component will recalculate the premium based on the amount change event.

[0068] In step S720 of some embodiments, the local state of the page component is updated according to the component state change event, and the local state is synchronized to the global state manager, triggering derived state calculations, such as recalculating premiums or matching underwriting rules. It should be noted that when the state of a page component changes, other states that depend on that state are triggered to perform update operations; the updated state is the derived state. The component state, including the local state and the derived state, is saved to a preset storage space. This component state is a global state, and the preset storage space can be a backend database, frontend local memory, etc.

[0069] In step S730 of some embodiments, in response to the breakpoint of the business node, such as the business node being interrupted due to the user exiting the page, closing the browser, timeout without operation, network interruption, etc., when the user re-enters the insurance page, the component state containing the local state and the derived state is read from the preset storage space, and the relevant page components are rendered according to the read component state to obtain the rendered component.

[0070] In step S740 of some embodiments, the insurance application page is updated according to the rendering component to obtain the insurance application page after the breakpoint resumes.

[0071] Through steps S710 to S740 above, the insurance application page can be restored after the business node is interrupted without any additional operations, thus ensuring the integrity of the page data.

[0072] Please see Figure 8 This application also provides an insurance application page generation device, which can implement the above-described insurance application page generation method. The insurance application page generation device includes: The request receiving module 810 is used to respond to the insurance application request of the insured object, construct a page context object, and determine the insurance application process based on the page context object; wherein, the insurance application process includes business nodes; The mapping module 820 is used to obtain the insurance application page template and map the business nodes to the template slots of the insurance application page template; wherein, the template slots have slot attributes; The acquisition module 830 is used to acquire insurance business rules based on business nodes, determine page elements based on insurance business rules, acquire page components of page elements, and acquire component configurations of page components. Module 840 is used to determine the page layout structure of page components in template slots based on slot attributes and component configurations. The rendering module 850 is used to render page components according to the page layout structure and component configuration to obtain the insurance application page of the business node.

[0073] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described insurance application page generation method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0074] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 910 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 920 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 920 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 920 and is called and executed by the processor 910 using the insurance page generation method of the embodiments of this application. The input / output interface 930 is used to implement information input and output; The communication interface 940 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 950 transmits information between various components of the device (e.g., processor 910, memory 920, input / output interface 930, and communication interface 940); The processor 910, memory 920, input / output interface 930 and communication interface 940 are connected to each other within the device via bus 950.

[0075] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described insurance application page generation method.

[0076] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0077] The insurance application page generation method, device, electronic device, and computer storage medium provided in this application embodiment construct the insurance application page by adopting an architecture design based on templates, rule mapping, and page element componentization. This allows for dynamic adjustment of the insurance application page according to business needs, avoiding problems such as poor scalability, high maintenance costs, and cumbersome and error-prone page modifications caused by hard coding.

[0078] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0079] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0080] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0082] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0083] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0084] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above 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.

[0085] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0086] 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 as a software functional unit.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0088] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for generating an insurance application page, characterized in that, The method includes: In response to an insurance application request from an insured party, a page context object is constructed based on the insurance application request, and an insurance application process is determined based on the page context object; wherein, the insurance application process includes business nodes; The insurance application page template is obtained according to the insurance application request, and the business node is mapped to the template slot of the insurance application page template; wherein, the template slot has a slot attribute; Obtain the insurance business rules based on the business nodes, determine the page elements based on the insurance business rules, and obtain the page components of the page elements and the component configuration of the page components. Based on the slot attributes and the component configuration, determine the page layout structure of the page component in the template slot; According to the page layout structure and component configuration, the page components are rendered to obtain the insurance application page of the business node.

2. The method according to claim 1, characterized in that, The step of constructing a page context object based on the insurance application request includes: Extract the insurance product identifier, insurance channel identifier, and the object identifier of the insured from the insurance application request; Obtain the insured product data based on the insured product identifier; Obtain channel configuration data based on the insurance channel identifier; Obtain the object profile data of the insured object based on the object identifier; The page context object is determined based on the insured product data, the channel configuration data, and the object profile data.

3. The method according to claim 2, characterized in that, The step of obtaining the object profile data of the insured object based on the object identifier includes: Obtain the insurance data of the insured object based on the object identifier; A risk assessment is performed on the insurance data to obtain the risk assessment data of the insured. The object profile data is constructed based on the risk assessment data.

4. The method according to claim 1, characterized in that, The step of determining the page layout structure of the page component in the template slot based on the slot attributes and the component configuration includes: The page position of the page component is determined based on the slot attribute and the component configuration. The component dependencies between the page components are determined based on the component configuration. The page layout structure is determined based on the page position and the component dependencies.

5. The method according to any one of claims 1 to 4, characterized in that, The step of rendering the page components according to the page layout structure and the component configuration to obtain the insurance application page of the business node includes: Based on the component configuration, the page component is mounted to the page layout structure to obtain the reference component; Obtain the page rendering stage of the reference component and the additional rendering rules of the reference component in the page rendering stage; During the page rendering stage, the reference component is rendered according to the component configuration and the additional rendering rules to obtain the insurance application page.

6. The method according to claim 5, characterized in that, The step of mounting the page component to the page layout structure according to the component configuration to obtain the reference component includes: The page components are categorized according to their configurations to obtain their component categories. The page components are filtered according to the component categories to obtain initial components; Determine the layout area of ​​the initial component in the page layout structure; The initial component is attached to the layout area to obtain the reference component.

7. The method according to any one of claims 1 to 4, characterized in that, After rendering the page components according to the page layout structure and component configuration to obtain the insurance application page of the business node, the method further includes: Triggered by a component operation on the page component, a component state change event of the page component is generated; Update the component state of the page component according to the component state change event, and save the component state to the preset storage space; In response to the breakpoint of the business node, the component state is read from the preset storage space, and the page component is rendered according to the read component state to obtain the rendered component; The insurance application page is updated according to the rendering component.

8. An insurance application page generation device, characterized in that, The device includes: The request receiving module is used to respond to the insurance application request of the insured object, construct a page context object, and determine the insurance application process based on the page context object; wherein, the insurance application process includes business nodes; The mapping module is used to obtain the insurance application page template and map the business node to the template slot of the insurance application page template; wherein, the template slot has a slot attribute; The acquisition module is used to acquire insurance business rules based on the business node, determine page elements based on the insurance business rules, and acquire page components of the page elements and component configurations of the page components. The determining module is used to determine the page layout structure of the page component in the template slot based on the slot attributes and the component configuration; The rendering module is used to render the page components according to the page layout structure and the component configuration to obtain the insurance application page of the business node.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images