Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application. The presence of non-native company software tools, components, servers, etc. in the embodiments of the present application is merely an example and is not representative of actual use.
It should be noted that, if not in conflict, the features of the embodiments of the present application may be combined with each other, which are all within the protection scope of the present application. In addition, while the division of functional blocks is performed in a device diagram and the logic sequence is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the block division in a device diagram or the sequence in a flowchart.
Unless defined otherwise, 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 in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The term "and/or" as used in this specification includes any and all combinations of one or more of the associated listed items.
For the sake of understanding the present embodiment, first, a front-end page jump pre-verification method disclosed in the present embodiment is described in detail, referring to fig. 1, fig. 1 is a schematic operation environment of the front-end page jump pre-verification method provided in the present embodiment, and as shown in fig. 1, an execution body of the front-end page jump pre-verification method provided in the present embodiment is generally an electronic device with a certain computing capability, such as a computer device, and in some possible implementations, the front-end page jump pre-verification method may be implemented by a processor calling a computer readable instruction stored in a memory. The computer device in fig. 1 may be a server, and the server may be an independent server, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, a content delivery network (Content Delivery Network, CDN), and basic cloud computing services such as big data and an artificial intelligence platform, which it is understood that the number of computer devices in fig. 1 is merely illustrative, and any number of extensions may be performed according to actual requirements.
With reference to fig. 2, fig. 2 is a schematic diagram illustrating an execution flow of a front-end page skip pre-verification method according to an embodiment of the present application, as shown in fig. 2, including the following steps S1 to S6.
S1, uniformly intercepting a page jump request through a preset global route interception mechanism of a front end framework, and loading a corresponding route rule configuration file according to preset route configuration.
For example, the global navigation guard (beforeEach) of the front end framework (e.g., vue) is used for uniformly intercepting all page jumps, that is, after the jump request is triggered and before loading the target page, processing logic is inserted, the route configuration corresponding to the current jump path is matched according to a preset route configuration table, whether the route configuration is associated with a rule configuration file is judged, if yes, only a corresponding rule configuration JSON file (e.g.,/rules/transfer-valve. JSON) is introduced, performance loss caused by loading the rule file in full is avoided, and basic rule support is provided for subsequent verification. In a financial scene, for example, when a 'transfer page- & gt transaction confirmation page' of a bank H5 page jumps, a global navigation guard intercepts a request and matches a routing configuration of a transfer service, after detecting that a corresponding rule configuration JSON file exists, the file is introduced, wherein the file comprises core rules related to fund security, such as transfer amount format (for example, maximum two decimal places), payee account verification (for example, 19-bit deposit card account regularization) and the like, and in a medical scene, when a 'patient list page- & gt medical record detail page' of an electronic medical record system jumps, the global navigation guard intercepts the request and matches the routing configuration of a medical record, and a corresponding rule configuration JSON file is introduced, wherein the file comprises rules related to medical privacy protection, such as whether the data is encrypted by RSA encryption or not, doctor authority identification verification and the like, so that data leakage caused by unauthorized access or parameter tampering is prevented.
S2, according to the routing rule configuration file, obtaining the jump link parameter through the objective function, obtaining jump request association historical data from the cache, and generating jump upstream data by using the jump link parameter and the jump request association historical data.
For example, after the routing rule profile is loaded, the routing rule profile may be loaded via an objective function (e.g., getUrlParams) parse the query parameters in the current jump link (e.g.,? sessionStorage) extracts the history data (e.g., the temporary form value saved by the last operation of the user) associated with the current jump, and merges the two parts of data to generate jump upstream data. In the 'transfer confirmation page' skip of the financial scene, the objective function can analyze parameters such as transfer amount, payee ID and the like from the URL, acquire historical data such as default payee information, common remarks and the like set by a user last time from the cache, combine and generate complete transfer request data, and in the 'patient detail page' skip of the medical scene, acquire patient ID parameters from the URL, and extract historical data such as department information, search keywords and the like recently viewed by the user from the cache for generating a patient data request containing context information.
Through the steps S1 to S2, double basic guarantee of rule loading and data integration before jumping is realized, and accuracy and efficiency of front-end page jumping pre-verification are remarkably improved. On one hand, by means of a mechanism of global route interception and on-demand loading of rule files, the method avoids the damage of redundancy rules to front-end performance, ensures that special check rules can be loaded in different service scenes (such as fund transaction in the financial field and private data access in the medical field), provides rule support for scene and customization for follow-up check, and on the other hand, extracts real-time parameters through an objective function and generates jump upstream data by combining historical data in a cache, so that the real-time performance of the data is guaranteed, context information of user operation is also included, the check logic can cover multidimensional requirements of parameter integrity, service relevance and the like, check omission caused by data loss or isolation is reduced, and a data foundation is laid for follow-up accurate check. The rule and data collaborative preparation mechanism not only optimizes the utilization efficiency of front-end resources, but also improves the business adaptation capability of pre-verification, and provides preconditions for guaranteeing the safety and fluency of page skip.
S3, verifying the jump upstream data according to the unique page route identifier, the parameter key value, the parameter type and the logical relation among the parameters defined in the route rule configuration file.
For example, the check is performed on the upstream data of the hop according to the unique page route identifier, the parameter key value, the parameter type and the logical relationship among the parameters defined in the route rule configuration file. Before skipping of financial product purchasing page in financial scene, comprehensively checking the data such as product ID, purchasing amount and the like at the upstream of skipping according to the logic relation of product ID identification, amount parameter key value, numerical value type requirement and purchasing amount which is not lower than purchasing amount in the routing rule, and checking whether the upstream data meets the requirement according to the logic of department ID identification, visit person ID key value, character string type regulation and visit person age and department visit range matching in the routing rule aiming at skipping of reservation registering page in medical scene.
As an optional implementation manner, please continue to refer to fig. 3, fig. 3 is a schematic diagram of an execution flow of checking skip upstream data in the front-end page skip pre-checking method according to an embodiment of the present application, and as shown in fig. 3, the method may specifically include the following steps S31 to S34.
And S31, matching the corresponding parameter verification rule according to the unique page route identifier, and verifying the consistency and the integrity of the page level parameter through the matched parameter verification rule to obtain a first verification result.
The method comprises the steps of matching a parameter verification rule (such as an amount format rule of a transfer page) of a current page from a preloaded rule set based on a page route unique identification in a route rule configuration file, verifying consistency (such as whether a type is matched with Number or not) and integrity (such as whether a necessary parameter exists or not) of a page level parameter (such as amount= 100.00 in a URL), and generating a first verification result. For example, in a financial scenario transfer process, this step verifies whether the transfer amount is in legal digital format, whether the payee ID exists, etc., as a basis for compliance.
S32, preprocessing the jump link parameters and/or the cache data in a type conversion and format standardization mode to obtain preprocessed data.
The method comprises the steps of preprocessing jump link parameters and cache data, including decoding coded data (such as special characters coded by URI), converting numbers of character string types into numerical types, unifying date formats (such as YYYY-MM-DD) and the like, and generating format standardized preprocessed data. For example, the date of birth of a patient retrieved from the cache in a medical system may be in two formats 2023/01/01 and 2023-01-01, which are unified into a standard format to ensure accuracy of subsequent checks.
S33, dynamically loading a corresponding parameter check rule set based on the page route unique identification, and executing multi-dimensional check in the rule set by using the preprocessed data to obtain a second check result.
And dynamically loading a parameter verification rule set with finer granularity (such as a complex rule containing business logic) based on the unique page route identification, performing multidimensional verification by using the preprocessed standardized data, wherein the multidimensional verification comprises verification of logic relation among parameters (such as transfer amount cannot exceed account balance), business rule constraint (such as matching of medical authority and a patient department in a medical scene), and the like, generating a second verification result, and covering business logic errors which cannot be detected by single parameter verification.
S34, combining the first check result and the second check result to generate a target check result corresponding to the jump upstream data.
The first verification result (basic parameter compliance) and the second verification result (business logic constraint) are combined, and a final target verification result is generated through a preset result combining algorithm (such as logic and/or operation). For example, when the first check shows that the parameter format is correct but the second check finds that the amount exceeds the account balance, the combined result is that the check is not passed, so that two dimensions of validity of the check coverage parameter and service compliance are ensured, and a complete basis is provided for the follow-up jump decision.
Through the steps S31 to S34, a set of hierarchical progressive check logic is formed, so that the compliance of the parameter basic format is guaranteed, and complex logic constraint in a business scene is covered. Firstly, building a firm foundation through consistency and integrity verification of page-level parameters, then eliminating interference of data format differences on verification through preprocessing, then realizing multi-dimensional deep verification by means of a dynamic loading rule set, and finally ensuring comprehensiveness of a verification conclusion through result merging. The verification mode can accurately identify the problems of wrong amount format, excessive transfer and the like in a financial scene, can effectively intercept the conditions of non-compliance patient information, permission mismatch and the like in a medical scene, greatly reduces page abnormality or business risk caused by parameter problems, and improves the suitability of verification logic to different business scenes through dynamic rule loading.
And S4, when the verification of the skip upstream data is not passed, carrying out popup prompt if the current environment is a test environment, and reporting the skip upstream data, the current page route information and the verification result to a preset monitoring platform if the current environment is a production environment.
The test environment visually presents problems through popup windows, and the production environment reports focused data and ensures user experience, thereby meeting development and debugging requirements and ensuring stable operation of an online system. In the medical scene, the patient information page skip verification fails, the test environment popup is helpful for checking, and the production environment reports data and skips best friend good error prompt pages.
As an alternative embodiment, the above step S4 may specifically include the following steps S41 to S45.
S41, judging the current environment based on a preset environment identifier when the skip upstream data is not checked.
For example, after the skip upstream data is not checked, whether the current test environment or the production environment is distinguished by means of a preset environment identifier (for example, a NODE_ENV field in a configuration file), so that a judgment basis is provided for the subsequent targeted processing. For example, in a financial system, after identification and judgment, the test environment goes through a debugging process and the production environment goes through an alarming process, and the medical system determines whether to display detailed errors to a developer or only report data to a monitoring platform.
And S42, if the current environment is a test environment, displaying check diagnosis data through a preset front-end popup window assembly, wherein the check diagnosis data comprises parameter error information, check rule data and debugging auxiliary information.
If the system is in a test environment, the preset front-end popup window component is utilized to display verification diagnosis data comprising parameter error information (such as 'transfer amount format error' in a financial scene and 'patient ID missing' in a medical scene), verification rule data (corresponding to verification logic in a routing rule configuration file) and debugging auxiliary information (such as error occurrence time and related parameter snapshot), so that a developer can conveniently and rapidly locate the root of the problem. For example, when a financial H5 page is tested, the popup window can display that the specific transfer parameters do not accord with rules and corresponding check logics, and in the medical system test, the popup window presents error details and check basis of patient information parameters.
S43, when the error parameter displayed in the front-end popup window component is clicked, jumping to a logic code position of a check rule corresponding to the error parameter in the source code.
When the error parameter in the popup window is clicked in the test environment, the test program directly jumps to the logic code position of the check rule corresponding to the error parameter in the source code through the source code mapping relation (for example sourcemap), so that the time for manually searching the code by a developer is saved. The medical scene clicks the wrong patient ID parameter and rapidly locates the source code position of the check logic.
S44, if the current environment is a production environment, packaging the skip upstream data, the current page route information, the target page route information and the verification result into structured log data in a preset format.
If the system is in a production environment, jump upstream data (such as transfer related parameters of a financial scene, patient information parameters of a medical scene), current and target page route information, a verification result and the like are integrated into structured log data in a preset format (such as a JSON structure), so that data integrity and standardization are ensured, and analysis by a monitoring platform are facilitated. For example, the financial system encapsulates the related data of the transfer failure in a fixed format, and the medical system sorts the information of the patient page jump error into a standard log.
S45, sending the structured log data to a monitoring platform in an asynchronous non-blocking mode through a preset embedded point reporting interface, and redirecting the page to a preset error page matched with the current error type by using a preset callback function.
In the production environment, the structured log data is sent to the monitoring platform in an asynchronous non-blocking mode (without affecting other operations of the page) by means of a preset embedded point reporting interface, and meanwhile, the page is redirected to a preset error page matched with the error type (such as a 'transfer failure guide page' of a financial scene and an 'information loading error page' of a medical scene) by a preset callback function. Therefore, not only is the effective reporting of error data ensured, but also friendly error feedback and operation guidance are provided for users.
And S5, when the skip upstream data passes the verification, storing the skip upstream data into a preset temporary buffer memory, and executing the loading processing of the target page in the page skip request by using the temporary buffer memory.
After the skip upstream data passes the verification, the data are stored in a preset temporary buffer memory, and the temporary buffer memory is used for processing the loading matters of the target page in the page skip request, so that the process not only ensures the effective transfer of the data in the skip process, but also can promote the loading efficiency of the target page by depending on the buffer memory. For example, in a financial scene, the transfer information is checked and then stored in a temporary buffer memory, the auxiliary target confirmation page is quickly loaded, and in a medical scene, the patient information is checked and then stored in the temporary buffer memory, so that the target detail page can quickly call data.
As an alternative embodiment, the above step S5 may specifically include the following steps S51 to S55.
And S51, when the skip upstream data passes the verification, storing skip associated parameters in the skip upstream data into temporary cache data, and setting the expiration time of the temporary cache data according to the page type and the service characteristics.
For example, the expiration time of the financial high frequency transaction page may be set to be shorter, and the expiration time of the medical patient file page may be properly prolonged. For example, the association parameters of the financial transfer page are set to expire for 10 minutes according to the transaction business characteristics, and the association parameters of the medical patient list jump are set to expire for 30 minutes according to the file page type.
S52, encrypting and desensitizing the sensitive data of the preset type in the jump upstream data by a preset front-end encryption algorithm and combining a dynamic key generated during operation.
For example, in a financial scenario, sensitive data such as a bank card number and a transaction password are encrypted, and in a medical scenario, sensitive information such as a patient identification card number and a medical record number are encrypted. For example, the financial system encrypts the bank card number in the transfer data using the AES algorithm, and the medical system encrypts the patient's medical insurance information using the dynamic key.
And S53, in the route analysis stage of the target page, reading temporary cache data through a global post guard or an intra-component guard of the front end framework, and mounting the temporary cache data to the life cycle context of the target component through a context injector.
In step S53, the target component can conveniently acquire the required data at each stage of the life cycle. In the financial scene, the target transaction page reads the cached transfer data through the global post guard and injects the transfer data into the component context, and in the medical scene, the target diagnosis page acquires the cached patient information through the intra-component guard and mounts the patient information into the context.
And S54, executing initialization logic of the target page based on the temporary cache data, and executing a preset degradation strategy if the temporary cache data are failed to be read or the temporary cache data are detected to be outdated, wherein the degradation strategy comprises automatic retry, rollback to a default state or displaying a lightweight prompt.
For example, in a financial scene, if the cached payment information is not read, the acquisition is automatically retried, and in a medical scene, if the cached inspection data is out of date, the method returns to an initial page state.
And S55, after the loading of the target page is completed, clearing the temporary cache data so that the temporary cache data does not reside for a long time.
For example, in a financial scenario, the cached transfer data is cleared after the transaction confirmation page is loaded, and in a medical scenario, the cached patient information is deleted after the patient detail page is loaded.
Through the steps S4 to S5, when the verification fails, the test environment displays detailed diagnosis data through the popup window and supports quick positioning source codes, so that a developer can efficiently check the problem, and the production environment ensures traceability of errors and friendly guidance for users through structured log reporting and page redirection, such as transfer error reporting and page jumping of a financial scene and failure processing of patient information loading of a medical scene. After verification, by means of mechanisms such as encryption storage, reading on demand, expiration management and timely clearing of the temporary cache, safe transfer of sensitive data in the jumping process is guaranteed, loading efficiency of a target page is improved, meanwhile, resources occupied by long-term resident cache is avoided, and technical advantages are achieved in quick loading of financial transaction pages and safe transfer of medical file information.
S6, traversing the routing rule configuration file through the document generation script, extracting the verification rule and the page information based on the mapping relation, and generating a target jump rule document containing the routing path, the parameter list and the dependency relation according to a preset template.
The process of the step S6 realizes the automatic generation of the verification rule document, reduces the manual writing cost, and ensures the consistency of the document and the actual configuration. In a financial scenario, a rule document may be generated that includes transfer related page routes, parameters, and dependencies, and in a medical scenario, a rule document may be generated that patient information pages skip.
As an alternative embodiment, the above step S6 may specifically include the following steps S61 to S63.
S61, identifying a verification rule file path corresponding to each route by analyzing metadata identification in the route rule configuration file, and extracting only rule file contents related to the current document generation task.
For example, when a financial scene generates a transfer related document, analyzing metadata of route configuration, finding a check rule file path corresponding to the transfer page route, only extracting rule contents related to transfer business in the file, and when a medical scene generates a patient registration document, locating the check rule file of the registration page according to metadata identification, only extracting the rule contents related to registration, avoiding irrelevant information interference and improving document generation efficiency.
S62, based on the unique page route identification in the routing rule configuration file, associating the verification rule with the corresponding page, and organizing according to the page dimension to generate document fragments in a preset format, wherein each document fragment comprises page basic information, a parameter verification rule table and a parameter dependency graph.
Document fragments in a preset format (such as markdown fragments) are generated according to page dimension organization, and each fragment contains page basic information (such as page names and function descriptions), parameter verification rule tables (such as parameter key values, types and verification logic) and parameter dependency graphs (such as association relations among parameters). For example, in a financial scene, the verification rule of the transfer page is associated with the page to generate a document fragment containing the verification rule table of parameters such as transfer page information, amount and the like and the parameter dependency graph, and in a medical scene, the verification rule of the patient visit page is associated with the page to generate a document fragment containing the verification rule table of parameters such as the visit page information, patient ID and the like and the dependency graph.
S63, integrating the document fragments of each page dimension into a target jump rule document, and automatically generating a directory index of the target jump rule document, wherein the directory index supports retrieval according to the routing hierarchy, the parameter type and/or the complexity of the check rule.
Wherein the index supports retrieval at a routing level (e.g., primary routing, secondary routing), a parameter type (e.g., digital, string type), and/or a check rule complexity (e.g., simple check, complex logic check). In the medical scene, after integrating the document fragments of the relevant pages of the patient, maintenance personnel position the check rules of each visit page according to the patient information routing level by means of the catalogue or inquire the check requirement of the patient ID according to the parameter type, thereby providing unified technical reference for development teams.
Through the steps S61 to S63, the accurate, structured and integrated generation of the verification rule technical document is realized, the problems that the front end industry depends on the upstream and downstream appointed skip rule and the document is difficult to maintain are solved, a set of standard rule document system is formed, technical support is provided for the integrated scheme of verification, reporting and rule document, in the scenes with high requirements on rule accuracy such as finance and medical treatment, the development errors caused by unclear rule are effectively reduced, and the team cooperation efficiency is improved.
As a preferred implementation manner, please continue to refer to fig. 4, fig. 4 is a schematic execution flow chart of a repair suggestion for generating a check rule in the front-end page skip pre-check method provided in the embodiment of the present application, as shown in fig. 4, after the step S6, the following steps S71 to S74 may be further included.
S71, analyzing historical behavior data of the user through an integrated machine learning model, wherein the historical behavior data comprises a page jump path, stay time, operation frequency and a parameter input mode.
The integrated machine learning model is used for developing and analyzing historical behavior data of the user, wherein the data comprise a page jump path (such as a jump track from a front page to a transfer page to a confirmation page in a finance H5 application or a circulation path from a registration page to a consultation page in a medical system), a stay time (such as browsing time of the user on a financial product detail page and operation stay time of a medical appointment page), an operation frequency (such as the number of times that a certain user performs transfer operations per month and the frequency that a doctor views patient medical records), and a parameter input mode (such as a common format when the user inputs a bank card number and field filling habit when filling patient information). By analyzing the data, rules and characteristics of user behaviors are mined, and a data basis is provided for subsequent construction of a prediction model. For example, in a financial scene, the transfer path and the money input mode of the user are analyzed to know the transaction habit of the user, and in a medical scene, the path and the stay time of a doctor for browsing medical records are analyzed to master the operation preference of the doctor.
S72, generating a user behavior prediction model based on an analysis result of the machine learning model, wherein the prediction model dynamically adjusts a temporary cache strategy, preloads pages based on a context and checks rules, and optimizes parameter check rule loading sequences.
The model can realize various optimizations, such as dynamically adjusting a temporary caching strategy (for example, prolonging caching time for high-frequency transfer users in the financial field, setting a special caching mechanism for patient medical records frequently checked in a medical system), preloading a transaction confirmation page and a corresponding verification rule according to a context (for example, after a user inputs transfer amount in a financial H5 application, preloading a consultation page and a verification rule related to a department after selecting the department in the medical system by a doctor), optimizing a parameter verification rule loading sequence (for example, preferentially loading verification rules of key parameters such as transfer amount, payee account number and the like in a financial scene, and loading verification rules of core parameters such as patient ID, consultation type and the like in the medical scene).
And S73, when the page jumps, automatically matching the optimal verification rule in the history scene by using a user behavior prediction model and comparing the current operation context with the history mode, early warning about parameter deficiency or parameter type errors occurring in the history, and generating corresponding repair suggestions.
Wherein, for the parameter missing (for example, frequent remark information is missed during financial transfer, and the date of visit is forgotten to be filled during medical appointment) or parameter type error (for example, letters are input into the money column in financial scene by mistake, the age of the patient is input into a character string in medical scene), early warning is sent out in advance, and corresponding repair advice (for example, the form of remark information is prompted to be supplemented, and the age is suggested to be modified into a number) is generated. In a medical scenario, the operation context of a doctor is similar to a parameter missing scenario when medical record information is filled in a history, and the model early-warns a patient of allergy Shi Ziduan possibly missed and prompts supplement.
And S74, continuously acquiring new user behavior data by the machine learning model for online training, and updating the user behavior prediction model according to a preset period to adapt to the dynamically changed user behavior mode.
Wherein, because the user behavior pattern may change dynamically over time (e.g., the transfer habits of the financial user may change due to market changes, and the doctor's operating preferences may be adjusted with new medical procedures), the model is continually updated to adapt to these changes. For example, in a financial scene, a new transfer mode is changed to cause the behavior of a user, a model updates prediction logic by training new data, and after a medical system introduces new medical record filling standards, the model is updated according to new operation data of doctors, so that the prediction and optimization effects are always fitted with reality.
Through the steps S71 to S74, the intelligent optimization of the front-end page skip driven by the user behavior is realized, the prediction model is constructed and dynamically updated through analyzing the historical behavior data, the skip efficiency is improved, the common parameter problems of the history can be early warned and repair suggestions are given in advance, the misoperation is reduced, the model is continuously adapted to the changed user behavior mode, and the user experience and the system adaptability are effectively improved in financial and medical scenes.
As another preferred embodiment, after the above step S6, a verification rule optimization suggestion may also be generated, specifically including the following steps S81 to S84.
S81, after loading of the target page is completed, interaction data of a user and the page are collected through a preset buried point, wherein the interaction data comprise parameter input behaviors, page rolling behaviors and operation time sequence data.
After loading the target page, the interaction data of the user and the page are collected through a preset buried point, wherein the data comprise parameter input behaviors (such as the process of inputting transfer amount and passwords by the user in a financial scene, and filling in the diagnosis information of the patient by a doctor in a medical scene), page rolling behaviors (such as the rolling track of introducing the page to the financial product by the user and the rolling track of introducing the page to the electronic medical record by the patient) and operation time sequence data (such as the operation sequence and time interval of each step in the financial transfer and the operation time sequence of issuing an inspection sheet in the medical inquiry).
S82, generating a page thermodynamic diagram based on the interaction data, wherein the thermodynamic diagram visually displays the attention degree and the operation frequency of the user on each area of the page through the color gradient.
The method comprises the steps of generating a page thermodynamic diagram based on collected interaction data, wherein the thermodynamic diagram visually presents the attention degree and the operation frequency of a user to each area of the page by utilizing color gradients (for example, red represents high attention degree and blue represents low attention degree). For example, in the account transfer confirmation page of the financial APP, the thermodynamic diagram can display high attention of the user to the account transfer confirmation button and the account display area, and the prescription of the medical system can be provided, and the thermodynamic diagram can embody the high-frequency operation area of the doctor to the medicine selection area and the dosage input area.
S83, analyzing thermodynamic diagrams and interactive data, and identifying optimized content data of the check rule, wherein the optimized content data comprises a redundancy check rule, a check rule blind area and a parameter check priority.
The redundancy check rule refers to check that is frequently operated by a user but is seldom triggered (for example, too complicated format check of transfer notes in a financial scene is performed, and errors are seldom generated when the user inputs the transfer notes actually), the check rule blind area refers to an area where the user frequently operates but lacks corresponding check (for example, check item codes which are frequently input by doctors in medical scenes and are occasionally generated when format check is not set), and the parameter check priority refers to parameters which need to adjust the check sequence according to the operation frequency of the user (for example, the user inputs money first and then payees in financial transfer and can check money preferentially).
S84, automatically generating a verification rule optimization suggestion according to the optimized content data, and pushing the verification rule optimization suggestion to a developer through a preset notification mechanism.
According to the identified optimized content data, a verification rule optimization suggestion (such as simplifying verification rules of financial transfer notes, adding format verification for medical examination project codes, adjusting verification sequences of financial transfer parameters) is automatically generated, and the verification rules are pushed to developers through a preset notification mechanism (such as development platform message pushing and mail reminding), so that the verification rules are optimized in a targeted manner.
Through the steps S81 to S84, various interactive data of a user in financial, medical and other scenes are accurately captured, a solid foundation is provided for analysis, the generated thermodynamic diagram visually presents a focus of attention of the user, assistance is fast used for positioning key areas, redundant rules, rule blind areas and priority problems are identified through data analysis, an optimization suggestion is automatically generated and pushed for optimizing the indication direction, and a verification rule is pushed to continuously iterate.
As an example, in a bank H5 page transfer scenario in the financial domain, when a user initiates a "transfer page→transaction confirmation page" jump, the global navigation guard of the Vue framework intercepts the request, matches the transfer service routing configuration and loads the corresponding transfer-value. Then, parameters such as transfer amount, payee ID and the like in the URL are analyzed through getUrlParams functions, and the skip upstream data is generated by combining default payee information stored last time by the user in sessionStorage. And then carrying out multi-layer verification, checking the existence of the money format and the payee ID, converting the money type and the unified date format, loading a special rule set to verify whether the money is excessive, and if the money format is correct but the money is excessive after the result is combined, checking is not passed. When the verification is failed, the production environment packages error data into a JSON log asynchronous report monitoring platform and jumps to a transfer failure guide page, the test environment displays error details by a popup window and clicks error parameters to directly reach source codes, after the verification is passed, the AES algorithm is used for encrypting and storing sensitive data such as bank card numbers and the like into a temporary cache (expiration of 10 minutes is set), and a transaction confirmation page reads the cache data and clears after loading is completed. Meanwhile, related technical documents are automatically generated, early warning errors are early-warned and suggestions are given through analyzing user behaviors, and verification sequence is optimized based on thermodynamic diagrams.
As another example, in an electronic medical record system patient information viewing scenario in the medical field, when a doctor jumps from a patient list page to a medical record detail page, the global route interception mechanism matches a medical record viewing route, loads a media-record-value. Json, and includes rules such as patient ID encryption verification, doctor authority identification verification, and the like. Analyzing patient ID parameters in the URL, and generating jump upstream data by combining with the latest viewed department information of the traditional Chinese medicine. And then carrying out multi-layer verification, verifying the existence and format of the patient ID a priori, unifying the format of the date of birth of the patient in the cache, loading a special rule set to verify whether the authority of the doctor is matched with the department of the patient, and if the authority is not matched after the result is combined, not passing the verification. When the verification is failed, the production environment reports a log of ' authority mismatch ' and jumps to a page without access authority ', a test environment popup window displays error details and clicks a patient ID to directly check the authority source code, after the verification is passed, sensitive data such as a patient identification card number and the like are stored in a temporary cache (expiration is set for 30 minutes), and a medical record detail page reads the cache data and is cleared after the loading is completed. In addition, a medical record page routing rule document is automatically generated, high-frequency rules are preloaded through analyzing operation habits of doctors, and format verification rules are added to an examination item input area which is frequently operated by the doctors based on thermodynamic diagrams.
According to the front-end page jump pre-verification method provided by the embodiment of the application, the unified processing of jump requests is realized through the global route interception mechanism, and the verification rules are loaded according to the needs by combining the routing rule configuration file, so that the resource loss is reduced, and customized rule support is provided for different service scenes. In data processing, jump link parameters and cache history data are integrated to generate jump upstream data, and parameter format compliance and business logic constraint are covered through hierarchical progressive check logic, so that comprehensiveness and accuracy of check are ensured. And for the verification result, differential processing is adopted according to the environmental difference, the problem of quick positioning of an environment assistance developer is tested, and the production environment ensures user experience and data traceability. After verification, the page loading efficiency is improved while the security of the sensitive data is ensured by means of encryption storage, aging management and on-demand clearing of the temporary cache. In addition, through automatically generating technical documents and intelligent prediction and optimization based on user behaviors, a complete closed loop from rule making, verification execution to continuous iteration is formed, the problems that the front-end field depends on appointed skip rules, document maintenance is difficult and the like are effectively solved, fund transaction safety and flow smoothness are guaranteed in financial scenes, medical privacy is protected in medical scenes, system operation efficiency is improved, and front-end page skip safety, reliability and user experience are comprehensively improved.
Referring to fig. 5, fig. 5 is a schematic system structure diagram of a front-end page skip pre-verification device according to an embodiment of the present application, and as shown in fig. 5, the front-end page skip pre-verification device 50 includes a skip request interception module 51, a skip upstream data generation module 52, a skip upstream data verification module 53, a verification pass fail processing module 54, a verification pass processing module 55, and a skip rule document module 56.
The skip request intercepting module 51 is specifically configured to uniformly intercept the page skip request through a preset global route intercepting mechanism of the front end framework, and load a corresponding route rule configuration file according to a preset route configuration.
The upstream data generation module 52 is specifically configured to obtain, according to the routing rule configuration file, a jump link parameter through an objective function, obtain jump request association history data from a cache, and generate upstream data using the jump link parameter and the jump request association history data.
The upstream data verification module 53 is specifically configured to verify the upstream data according to the unique page route identifier, the parameter key value, the parameter type and the logical relationship between parameters defined in the routing rule configuration file.
The verification failure processing module 54 is specifically configured to, when the verification of the skip upstream data fails, perform popup prompt if the current environment is a test environment, and report the skip upstream data, the current page routing information and the verification result to a preset monitoring platform if the current environment is a production environment.
The verification passing processing module 55 is specifically configured to store the skip upstream data into a preset temporary buffer when the skip upstream data is verified, and execute the loading process of the target page in the page skip request by using the temporary buffer.
The skip rule document module 56 is specifically configured to traverse the routing rule configuration file through a document generation script, extract a verification rule and page information based on a mapping relationship, and generate a target skip rule document including a routing path, a parameter list and a dependency relationship according to a preset template.
As an optional implementation manner, the jump upstream data verification module 53 is further specifically configured to match a corresponding parameter verification rule according to the page route unique identifier, verify consistency and integrity of a page level parameter according to the matched parameter verification rule to obtain a first verification result, perform type conversion and format normalization preprocessing on the jump link parameter and/or cache data to obtain preprocessed data, dynamically load a corresponding parameter verification rule set based on the page route unique identifier, perform multidimensional verification in the rule set by using the preprocessed data to obtain a second verification result, and combine the first verification result and the second verification result to generate a target verification result corresponding to the jump upstream data.
As an optional implementation manner, the verification failing processing module 54 is further specifically configured to determine, when the skip upstream data is not verified, a current environment based on a preset environment identifier, display, if the current environment is a test environment, verification diagnostic data including parameter error information, verification rule data and debug auxiliary information through a preset front-end popup window component, skip to a logic code position of a verification rule corresponding to the error parameter in source code when an error parameter displayed in the front-end popup window component is clicked, encapsulate, if the current environment is a production environment, the skip upstream data, current page routing information, target page routing information and verification result into structured log data in a preset format, send the structured log data to a monitoring platform through a preset embedded point reporting interface in an asynchronous non-blocking manner, and redirect a page to a preset error page matching the current error type by using a preset callback function.
As an optional implementation manner, the verification passing processing module 55 is specifically configured to store a jump associated parameter in the jump upstream data to temporary cache data when the jump upstream data is verified, and set an expiration time of the temporary cache data according to a page type and a service characteristic, encrypt and desensitize sensitive data of a preset type in the jump upstream data by a preset front-end encryption algorithm in combination with a dynamic key generated during operation, read the temporary cache data through a global post guard of a front-end framework or a guard in a component in a route parsing stage of the target page, and mount the temporary cache data to a life cycle context of the target component through a context injector, execute initialization logic of the target page based on the temporary cache data, and if the temporary cache data fails to be read, or detects that the temporary cache data has expired, execute a preset degradation policy, where the degradation policy includes retrying, backing to a default state, or displaying a lightweight hint, and after the temporary cache data is completely loaded by the target page, make the temporary cache data not resident for a long term.
As an alternative implementation manner, the skip rule document module 56 is further specifically configured to identify a check rule document path corresponding to each route by parsing a metadata identifier in the route rule configuration file, and only extract rule document contents related to a current document generation task, associate a check rule with a corresponding page based on a page route unique identifier in the route rule configuration file, organize and generate document fragments in a preset format according to page dimensions, each document fragment including page basic information, a parameter check rule table and a parameter dependency graph, integrate the document fragments in each page dimension into the target skip rule document, and automatically generate a directory index of the target skip rule document, where the directory index supports searching according to a route hierarchy, a parameter type and/or a check rule complexity.
The front-end page skip pre-verification device 50 further includes a user behavior analysis module, specifically configured to analyze, through an integrated machine learning model, user historical behavior data, where the historical behavior data includes a page skip path, a residence time, an operation frequency, and a parameter input mode, generate, based on an analysis result of the machine learning model, a user behavior prediction model, where the prediction model dynamically adjusts a temporary caching policy, pre-loads a page based on a context, and optimizes a parameter verification rule loading order, and automatically matches, during page skip, an optimal verification rule in a historical scene by comparing a current operation context with the historical mode using the user behavior prediction model, pre-warn of a parameter deficiency or a parameter type error occurring in the historical scene, and generate a corresponding repair suggestion, where the machine learning model performs online training by continuously collecting new user behavior data, and updates the user behavior prediction model according to a preset period to adapt to the dynamically-changed user behavior mode.
As an optional implementation manner, the front-end page skip pre-verification device 50 further includes a verification rule optimization module, which is specifically configured to collect, after the target page is loaded, user-page interaction data through a preset buried point, where the interaction data includes parameter input behavior, page scrolling behavior and operation time sequence data, generate a page thermodynamic diagram based on the interaction data, where the thermodynamic diagram visually shows the attention degree and the operation frequency of the user to each area of the page through a color gradient, analyze the thermodynamic diagram and the interaction data, identify optimized content data of the verification rule, where the optimized content data includes a redundancy verification rule, a verification rule blind area and a parameter verification priority, automatically generate a verification rule optimization suggestion according to the optimized content data, and push the verification rule optimization suggestion to a developer through a preset notification mechanism.
It should be noted that, the front-end page jump pre-verification device can execute the front-end page jump pre-verification method provided by the embodiment of the application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details which are not described in detail in the embodiment of the front-end page jump pre-verification device can be seen in the front-end page jump pre-verification method provided by the embodiment of the application.
Fig. 6 is a schematic hardware structure of an electronic device for performing a front-end page skip pre-verification method according to an embodiment of the present application, as shown in fig. 6, the electronic device 600 includes:
One or more processors 610, and a memory 620, one processor 610 being illustrated in fig. 6.
The processor 610 and the memory 620 may be connected by a bus or otherwise, for example in fig. 6.
The memory 620 is used as a non-volatile computer readable storage medium for storing non-volatile software programs, non-volatile computer executable programs, and modules, such as program instructions/modules corresponding to the front-end page jump pre-calibration method in the embodiment of the present application. The processor 610 executes various functional applications of the server and data processing by running non-volatile software programs, instructions and modules stored in the memory 620, i.e., implements the front-end page skip pre-verification method of the method embodiment described above.
The memory 620 may include a storage program area that may store an operating system, an application program required for at least one function, and a storage data area that may store data created according to the use of the front-end page skip pre-verification device, etc. In addition, memory 620 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 620 may optionally include memory located remotely from processor 610, which may be connected to the front-end page skip pre-verification device 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.
The one or more modules are stored in the memory 620, and when executed by the one or more processors 610, perform the front-end page skip pre-verification method in any of the method embodiments described above, e.g., perform method steps S1 through S6 in fig. 2, method steps S31 through S34 in fig. 3, and method steps S71 through S74 in fig. 4 described above, to implement the functions of modules 51-56 in fig. 5.
The product can execute the method provided by the embodiment of the application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment may be found in the methods provided in the embodiments of the present application.
Embodiments of the present application provide a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, such as one processor 610 in fig. 6, to cause the one or more processors to perform the front-end page skip pre-verification method in any of the method embodiments described above, such as performing method steps S1 through S6 in fig. 2, method steps S31 through S34 in fig. 3, and method steps S71 through S74 in fig. 4, to implement the functions of modules 51-56 in fig. 5.
Embodiments of the present application provide a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by the electronic device, enable the electronic device to perform the front-end page jump pre-verification method in any of the method embodiments described above, e.g. performing the method steps S1 to S6 in fig. 2, the method steps S31 to S34 in fig. 3, the method steps S71 to S74 in fig. 4, implementing the functions of the modules 51-56 in fig. 5 described above.
The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus a general purpose hardware platform, or may be implemented by hardware. Those skilled in the art will appreciate that all or part of the processes implementing the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and where the program may include processes implementing the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random-access Memory (Random Access Memory, RAM), or the like.
It should finally be noted that the above embodiments are only intended to illustrate the technical solution of the present application and not to limit it, that the technical features of the above embodiments or of the different embodiments may be combined in any order, and that many other variations in the different aspects of the present application as described above exist, which are not provided in details for the sake of brevity, and that although the application has been described in the detailed description with reference to the foregoing embodiments, it should be understood by those skilled in the art that it may still make modifications to the technical solution described in the foregoing embodiments or equivalent to some of the technical features thereof, where these modifications or substitutions do not depart from the essence of the corresponding technical solution from the scope of the technical solution of the embodiments of the present application.