Standardized processing method for public employment services based on workflow configuration

Abstract

The application belongs to the technical field of computer software data processing, and particularly relates to a public employment service standardization processing method based on a work flow configuration. The method acquires public employment service matter configuration data and standard data elements, splits the matter configuration data into multiple handling nodes, and binds input data elements, output data elements, trigger conditions, pre-depending conditions and mutual exclusion conditions for the handling nodes; generates a matter constraint graph according to the handling nodes, the standard data elements and the binding relationship, and performs topology, repeated collection, condition coverage and rule reference consistency checking on the matter constraint graph; after the checking, compiles the matter constraint graph into a work flow description file containing node execution sequences, field mapping relationships and rule indexes, and creates a standardization processing process instance according to the work flow description file. The application can locate configuration defects before the process is published, reduce process running interruption and field mapping errors, and improve the consistency and traceability of the public employment service matter configuration.

Description

Technical Field

[0001] This invention belongs to the field of computer software data processing technology, specifically relating to a standardized processing method for public employment services based on workflow configuration. Background Technology

[0002] Public employment services typically include employment registration, unemployment registration, employment assistance, job placement, vocational training registration, and subsidy application. Existing public employment service systems mostly use workflow configuration to handle these matters. This involves administrators creating workflow templates based on the service name, setting up processing nodes such as acceptance, review, correction, completion, and archiving, and configuring form fields, flow conditions, processing time limits, role permissions, and result status for each node. During workflow execution, the workflow engine creates workflow instances according to the pre-configured node sequence, receives business data such as basic personnel information, employment status information, training information, and subsidy information according to form fields, and then determines whether to proceed to the next node based on configured rules. While this method reduces the number of hard-coded workflows, its configuration content is usually scattered across workflow templates, form templates, rule tables, and interface mapping tables, lacking a unified constraint expression structure.

[0003] In similar conventional technical solutions, different public employment service items typically maintain separate process configurations. Form fields are defined independently for each item, validation rules are configured using rule tables or scripts, node flow relationships are stored in the process design page or configuration table, and external data sources are implemented through interface field mapping. When an item is adjusted, configuration personnel need to modify process nodes, field mappings, rule references, and exception branches separately. To reuse similar items, some systems create general node templates or copy existing process templates and then modify fields and conditions, but the copied configuration lacks calculable dependencies with the original configuration. Before releasing the configuration, the system usually only performs basic checks such as field non-empty, format validity, and node connectivity, making it difficult to uniformly validate node dependencies, condition mutual exclusion, duplicate field collection, and rule reference integrity.

[0004] The core technical problem with the aforementioned conventional approach lies in the lack of a unified constraint model for public employment service workflow configuration that can simultaneously express processing nodes, standard data elements, triggering conditions, prerequisite dependencies, and mutual exclusion conditions. This makes it difficult to verify and compile the configuration content as a whole before release. Because node relationships, field relationships, and rule relationships are stored in a scattered manner, the system cannot identify defects such as circular dependencies, duplicate data collection, condition coverage conflicts, and invalid rule indexes during the configuration phase. Problems can only be discovered after the workflow instance has run, through exception logs or manual feedback. This issue can lead to inconsistent execution paths for similar tasks under different configuration versions, causing workflow instance interruptions, incorrect field mappings, or accidental entry into abnormal branches. Summary of the Invention

[0005] The purpose of this invention is to provide a standardized processing method for public employment services based on workflow configuration, which can solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A standardized processing method for public employment services based on workflow configuration includes: acquiring item configuration data and standard data elements for public employment service items; splitting the item configuration data into multiple processing nodes, and binding input data elements, output data elements, triggering conditions, prerequisite dependencies, and mutual exclusion conditions to the processing nodes; generating an item constraint graph based on the processing nodes, the standard data elements, and their binding relationships; performing configuration consistency verification on the item constraint graph; after passing the verification, compiling the item constraint graph into a workflow description file containing node execution order, field mapping relationships, and rule indexes; and creating a standardized processing flow instance for public employment services based on the workflow description file.

[0007] Preferably, obtaining the standard data elements includes: normalizing the original fields according to the field source, field type, scope of application, and processing steps of the public employment service item; assigning standard data element codes to the normalized fields; establishing associations between the standard data element codes and field names, value ranges, required attributes, validation expressions, source identifiers, and output mapping relationships; establishing same-source reference relationships for fields with the same semantics but different field names; and writing the same-source reference relationships into the standard data element library.

[0008] Preferably, generating the event constraint graph includes: converting the processing node, the input data element, and the output data element into graph nodes respectively; forming sequential edges based on the prerequisite dependencies, conditional edges based on the triggering conditions, exclusionary edges based on the mutual exclusion conditions, and data reference edges based on the field mapping relationships; writing constraint type, constraint source, and constraint priority to each graph edge, and storing the event constraint graph hierarchically according to the event code, version identifier, and node identifier.

[0009] Preferably, the configuration consistency verification of the constraint graph includes: performing topological sorting on the constraint graph to determine the set of processing nodes with loops; performing duplicate collection verification on input data elements with the same standard data element code; performing logical coverage verification on the triggering condition and the mutual exclusion condition; performing referential integrity verification on the verification expression pointed to by the rule index; and generating configuration defect records for graph nodes, graph edges, constraint types, and configuration sources that fail the verification.

[0010] Preferably, compiling the matter constraint diagram into a workflow description file includes: extracting the execution entry point, execution exit point, and abnormal branch entry point of the processing node according to the node execution order; generating a bidirectional mapping table between standard data elements and matter form fields according to the field mapping relationship; generating a verification rule call sequence according to the rule index; and encapsulating the execution entry point, the execution exit point, the abnormal branch entry point, the bidirectional mapping table, and the verification rule call sequence into a workflow description file with a version signature.

[0011] Preferably, processing the source reference relationship includes: obtaining candidate fields from different public employment service items that point to the same person, the same employment status, or the same processing result; generating a field merging score based on field name similarity, value domain inclusion relationship, verification expression consistency, and historical mapping relationship; when multiple candidate fields belong to the same standard data element code, retaining the item source and conversion expression of each candidate field; when there is a value domain conflict among candidate fields, writing the conflicting field into the data element set to be confirmed, and prohibiting the conflicting field from participating in the compilation of the workflow description file.

[0012] Preferably, after storing the constraint graph in layers, the method further includes: establishing a layered graph structure based on the item code, establishing a layered graph structure based on the processing node, and establishing a layered graph structure based on the standard data element code; establishing a cross-layered index between the layered graph structure, the node layered graph structure, and the field layered graph structure; and when any standard data element, processing node, or constraint condition changes, locating the affected graph nodes and edges based on the cross-layered index and generating an incremental verification task.

[0013] Preferably, after generating the configuration defect record, the method further includes: determining the defect category according to the constraint type in the configuration defect record; extracting the shortest closed path for loop defects, extracting the processing node corresponding to the duplicate field for duplicate acquisition defects, extracting the trigger condition interval that is not covered or is repeatedly covered for logical coverage defects, and extracting the failure rule index for referential integrity defects; and writing the defect category, the shortest closed path, the processing node, the trigger condition interval, and the failure rule index into the configuration repair list.

[0014] Preferably, processing the set of data elements to be confirmed includes: generating conflict fingerprints according to the source of the conflicting field, the difference in the value range, and the difference in the transformation expression; grouping conflicting fields with the same conflict fingerprint into the same conflict group; generating candidate standard data element codes, candidate value ranges, and candidate transformation expressions for the conflict group; and updating the standard data element library and re-triggering the incremental verification task related to the conflicting field when receiving the confirmed candidate standard data element codes, candidate value ranges, and candidate transformation expressions.

[0015] Preferably, processing the configuration repair list includes: matching a preset repair template according to the defect category; converting the shortest closed path into a dependency disconnection candidate, converting the processing node corresponding to the duplicate field into a field reuse candidate, converting the trigger condition interval into a condition rearrangement candidate, and converting the failure rule index into a rule rebinding candidate; sorting each candidate according to the constraint priority in the matter constraint diagram, and writing the sorted candidates into the workflow configuration version to be released.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention associates the configuration data of public employment service items with standard data elements, converting processing nodes and their input data elements, output data elements, triggering conditions, prerequisite dependencies, and mutual exclusion conditions into a task constraint graph. The task constraint graph is then validated for configuration consistency, and after successful validation, it is compiled into a workflow description file containing node execution order, field mapping relationships, and rule indexes. Through this process, scattered process nodes, form fields, and rule references are transformed into a computable graph structure. The system can check for loops, duplicate data collection, condition coverage, and reference integrity before process release, reducing the likelihood of configuration defects being exposed during runtime. After establishing a clear binding relationship between processing nodes and standard data elements, differences in name, source, and output mapping of the same field in different items can be uniformly processed through standard data element encoding, reducing the probability of duplicate field collection and inconsistent field mapping. The workflow description file includes node execution order, a bidirectional mapping table, a validation rule call sequence, and a version signature, ensuring that process instances are executed according to the same configuration result, preventing different flow paths for the same item due to scattered configurations.

[0017] 2. This invention also uses layered storage (item layer, node layer, and field layer) and cross-layer indexing to locate the scope of changes to standard data elements, processing nodes, and constraints, and generates incremental verification tasks. For value domain conflicts occurring during field merging, conflict fingerprints, conflict groups, candidate standard data element codes, candidate value domains, and candidate transformation expressions are used to prevent conflicting fields from participating in workflow description file compilation before confirmation. For defect records formed by configuration consistency verification, the shortest closed path, processing nodes corresponding to duplicate fields, uncovered or repeatedly covered trigger condition intervals, and failure rule indexes are extracted according to constraint type and written into the configuration repair list. Through the above configuration defect location and repair candidate generation methods, configuration personnel can modify specific graph nodes, graph edges, fields, or rules, avoiding repeated checks of the entire process. The workflow configuration version to be released saves candidate repair items according to constraint priority, ensuring that subsequent configuration adjustments retain the constraints of the item. Figure 1 The basis for handling this matter. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of the standardized processing method for public employment services based on workflow configuration of the present invention; Figure 2 This is a flowchart of the standard data element normalization and homogeneous field conflict handling process of the present invention. Figure 3 This is a flowchart illustrating the process of generating and configuring the constraint diagram for consistency verification in this invention. Figure 4 Flowcharts were created for compiling workflow description files and creating process instances for this invention; Figure 5 A flowchart is provided for the configuration defect repair, cross-layer index incremental verification, and release version of this invention. Figure 6 This is a field merging score distribution chart for the present invention; Figure 7 This is an overlapping diagram of the triggering condition intervals of the present invention; Figure 8 This is a trend chart of version signatures for this invention. Detailed Implementation

[0019] refer to Figure 1In one embodiment, a standardized processing method for public employment services based on workflow configuration is used to convert the decentralized configuration of public employment service items into verifiable, compileable, and executable workflow description files. Public employment service items may include employment registration, unemployment registration, employment assistance, job placement, vocational training registration, subsidy application, and service result archiving. The processing object is not the management content of the above-mentioned items themselves, but rather the process configuration data, field configuration data, rule configuration data, and mapping configuration data of the items in the computer system. The method receives item configuration data and standard data elements. The item configuration data includes item code, item name, processing stage, node name, node entry conditions, node exit conditions, abnormal branch conditions, field source, field purpose, rule reference identifier, and result status identifier. Standard data elements include field specifications in public employment services that can be reused by different items, such as personnel identification, employment status, unemployment registration status, training registration status, subsidy application status, service result code, processing time, and handling agency code. During processing, the configuration data for each item is broken down into multiple processing nodes, and each node is bound to input data elements, output data elements, triggering conditions, prerequisite dependencies, and mutual exclusion conditions. After the binding relationships are established, the execution flow is not generated directly. Instead, an item constraint graph is first constructed. This graph represents processing nodes, standard data elements, and constraint relationships in a unified graph structure, and configuration consistency is then verified through this graph structure. Once the verification passes, the item constraint graph is compiled into a workflow description file, and the workflow engine creates a standardized public employment service processing flow instance based on this description file.

[0020] In this embodiment, the working principle is as follows: the configuration content, originally scattered across process configuration tables, form configuration tables, rule configuration tables, and interface mapping tables, is converted into a unified constraint graph. Processing nodes serve as process execution units, standard data elements as field reference units, and triggering conditions, prerequisite dependencies, mutual exclusion conditions, and field mapping relationships as constraint edges. Because the graph nodes and edges have a unified data structure, the system can perform computational validation of the configuration before publishing the process, rather than waiting for the process instance to run and then discovering errors through exception logs. If the constraint graph contains circular dependencies, topological sorting cannot be completed; if the same standard data element is repeatedly collected by multiple nodes, there are duplicate input references in the field layer constraints; if triggering conditions overlap or have blank intervals, the value range of the condition edges cannot form a complete and non-conflicting path; if the rule index points to a non-existent validation expression, the reference integrity validation fails. Through the above processing, the standardized processing flow of public employment service items can be generated in the form of a computable configuration file, avoiding implicit configuration differences caused by manually copying process templates.

[0021] refer to Figure 2In this embodiment, the item configuration data can be obtained from the configuration interface, configuration file, or database configuration table. To avoid the same field appearing with different names in different items, the system performs normalization processing when reading the field configuration. Normalization processing not only compares field names but also considers field source, field type, item scope, and processing stage. Field source indicates that the field comes from basic personnel information, employment status information, training records, subsidy records, or service result records; field type indicates that the field is text, date, enumeration, numeric, or Boolean; item scope indicates that the field is applicable to items such as employment registration, unemployment registration, employment assistance, training registration, or subsidy application; processing stage indicates the field's usage position in acceptance, qualification verification, material correction, review, completion, or archiving. After normalization, standard data element codes are assigned to the fields, and these codes are associated with the field name, value range, required attributes, validation expression, source identifier, and output mapping relationship. For fields with the same semantics but different names, a same-source reference relationship is established, preserving the original field name, item, and conversion expression to prevent the loss of original configuration semantics after fields are forcibly merged.

[0022] Table 1 shows one organization method of the standard data metadata library in this embodiment, which is used to illustrate the data content saved after field normalization.

[0023] Table 1. Organization of the Standard Data Metabase Field Name Save the original field names and normalized names in the item configuration. The original field and the standard field form a reference relationship. Used for field homology identification Field type Record text, date, enumeration, numeric or boolean values. Form field type labels Used to validate expression matching Range Record the set of possible values ​​or range of values Forming value boundary description Used for condition coverage verification Source identification Record fields are derived from personnel, employment status, training, subsidies, or outcome data. Formation Source Classification Used for duplicate data collection verification Output mapping Record the conversion relationship between standard data elements and form fields or result fields. Forming a mapping expression For compiling workflow description files Validate expression Record field validity, required fields, and association rules Forming a rule index object Used for referential integrity verification In a preferred embodiment, field homology identification employs a merge score calculation method. The merge score is jointly determined by field name similarity, value domain inclusion relationship, validation expression consistency, and historical mapping relationship. Field name similarity can be obtained by the ratio of the number of identical tokens after word segmentation to the total number of tokens; value domain inclusion relationship can be obtained by the intersection and union relationship between two value sets; validation expression consistency can be determined by whether the expression type, comparison operator, and referenced field are consistent; historical mapping relationship can be determined by whether the same mapping record exists in the published configuration. The calculation formula is as follows:

[0024] in, This represents the merge score of the candidate fields. , , , These represent the weights for field name similarity, value range inclusion relationship, validation expression consistency, and historical mapping relationship, respectively. This indicates the similarity value for the field names. This indicates that the range of values ​​includes the range of values. This indicates that the expression being checked takes consistent values. This represents the historical mapping relationship values. The sum of all weights is 1, and each value is between 0 and 1. For example, if a candidate field has a name similarity of 0.8, a value range inclusion relationship of 0.6, a validation expression consistency of 1, a historical mapping relationship of 0.7, and weights of 0.35, 0.25, 0.25, and 0.15 respectively, then the merge score is 0.35 × 0.8 + 0.25 × 0.6 + 0.25 × 1 + 0.15 × 0.7 = 0.785. When the merge score meets the preset merge conditions, the candidate field can be bound to the same standard data element encoding; if the merge conditions are not met, it is retained as an independent standard data element or enters the set of data elements to be confirmed.

[0025] In this embodiment, the design basis for the merge score is as follows: field name similarity reflects the consistency of fields at the semantic level; value domain inclusion relationship reflects the compatibility of fields at the data instance level; validation expression consistency reflects the identity of fields at the rule constraint level; and historical mapping relationship reflects the merging reliability of fields in previous configurations. These four dimensions comprehensively judge whether candidate fields should be merged into the same standard data element from four levels: naming semantics, data instance, rule constraint, and historical experience, avoiding incorrect or missed merging due to relying on only a single dimension. The weights ω1, ω2, ω3, and ω4 for each dimension are determined based on statistical practices in public employment service field governance: field name is the primary basis for configuration personnel to identify field semantics, and is assigned the highest weight of 0.35; validation expression consistency directly affects the reuse efficiency of rule indexes, and is assigned a weight of 0.25; value domain inclusion relationship affects the data compatibility after field merging, and is assigned a weight of 0.25; and historical mapping relationship reflects the actual merging results of published configurations and serves as an auxiliary reference, assigned a weight of 0.15. The sum of all weights is 1.

[0026] Let's take the merging of the "Employment Status" field in a public employment service system as an example. In employment registration, this field is defined in numerical enumeration form as: 0 - Unemployed, 1 - Employed, 2 - Flexible Employment; in unemployment registration, this field is defined in text enumeration form as: Unemployed, Employed; in subsidy application, this field is defined in numerical form as: 0 - Unemployed, 1 - Employed, 2 - Flexible Employment. The system obtains three candidate fields and calculates their merging scores as follows: The name similarity between candidate field A (employment registration - employment status) and candidate field B (unemployment registration - employment status) is 0.85, the value range inclusion relationship is 0.67 (the proportion of the intersection {unemployed, employed} to the union {unemployed, employed, flexible employment}), the consistency of the validation expression is 1 (both are enumeration validations), the historical mapping relationship is 0.8 (there have been previous merging records), and the merging score is 0.35×0.85+0.25×0.67+0.25×1+0.15×0.8=0.8325, which reaches the preset merging threshold of 0.75. Therefore, the two are merged into the same standard data element encoding. Candidate field A and candidate field C (subsidy application - employment status) have a name similarity of 0.90, but their value domain inclusion relationship is only 0.40 (the ratio of the intersection {employed, flexible employment} to the union {unemployed, employed, flexible employment, waiting for employment, employed}). The merging score is 0.35×0.90+0.25×0.40+0.25×1+0.15×0.7=0.755, which is slightly higher than the threshold but still low. Furthermore, there is a value domain conflict (the semantics of "unemployed" in candidate field A and "waiting for employment" in candidate field C are similar but the encoding is different). Therefore, candidate field C is added to the set of data elements to be confirmed, pending manual confirmation before a decision is made on whether to merge it. Through the above merging score calculation, the system can automatically identify and merge semantically identical fields from different items into the same standard data element, while isolating fields with value domain conflicts to the set of data elements to be confirmed, avoiding incorrect merging that could lead to field mapping errors during process instance execution.

[0027] refer to Figure 6 The field merging score distribution expresses the credibility of whether candidate field groups can be merged into the same standard data element. The horizontal axis is the candidate field group, with each scale representing a candidate field group; the vertical axis is the merging score, and the value is calculated by formula (1). The higher the bar, the more consistent the field name, value range, expression, and historical mapping are; if it is below the threshold, it means that manual confirmation is still required. Its function is to transform field governance from subjective judgment to quantifiable sorting, helping configuration personnel to prioritize the handling of fields with large discrepancies. It is used to determine whether multiple business form fields should be bound to the same standard data element, avoiding the repeated collection of synonymous fields.

[0028] Furthermore, when determining conflicts in field value ranges, set overlap calculation can be used. For enumerated fields, the value range is represented by the set of enumerated values; for numeric fields, the value range is first converted into discrete interval identifiers before performing set calculations. The calculation formula is as follows:

[0029] in, Representation field With fields The degree of overlap of the value ranges, Representation field The set of possible values, Representation field The set of possible values, This represents the intersection operation. The vertical bar represents the union operation, and the vertical bar indicates the number of elements in the set. For example, a field... The set of values ​​is {0, 1, 2}, and the field... The set of values ​​is {1, 2, 3, 4}. The intersection contains two elements {1, 2}, and the union contains five elements {0, 1, 2, 3, 4}. Therefore, the overlap of the value ranges is 2 ÷ 5 = 0.4. If two field names are similar but their value ranges have low overlap, they are not directly merged into the same standard data element. Instead, conflicting field records are generated, which are then confirmed by the subsequent conflict group handling mechanism.

[0030] In this embodiment, the breakdown of processing nodes is based on the processing steps of a matter, but is not limited by page layout. A processing node includes at least a node identifier, node name, node type, entry conditions, exit conditions, a set of input data elements, a set of output data elements, a set of preceding nodes, a set of mutually exclusive nodes, and an abnormal branch entry point. The acceptance node typically receives the applicant's basic data and the matter application data; the qualification verification node receives verification data such as employment status, unemployment registration status, or training records; the material correction node receives the missing material identifier and correction status; the review node receives the verification conclusions output by the preceding nodes; the result generation node outputs the processing result code and result generation time; and the archiving node outputs the archiving status and archiving batch. After node breakdown, each processing node does not directly store form fields, but instead stores standard data element codes. The matter form fields correspond to the standard data elements through field mapping relationships. This processing method decouples nodes from the page, allowing the form display fields to be replaced during process compilation without changing the processing node definition.

[0031] refer to Figure 3In this embodiment, the generation of the event constraint graph is accomplished using graph nodes and graph edges. Processing nodes, input data elements, and output data elements are converted into graph nodes. Prerequisite dependencies are converted into sequential edges, indicating that a certain processing node must be entered after the output of another processing node; trigger conditions are converted into conditional edges, indicating that the corresponding branch is entered after a certain data element value condition is met; mutual exclusion conditions are converted into exclusion edges, indicating that two nodes or two branches cannot be executed simultaneously in the same process instance; field mapping relationships are converted into data reference edges, indicating that there is a conversion relationship between standard data elements and event form fields and result fields. Each graph edge is written with constraint type, constraint source, and constraint priority. The constraint source records whether the constraint comes from event rules, field rules, node configurations, or interface mappings; the constraint priority determines the verification order when multiple constraints conflict. The event constraint graph is stored hierarchically according to event code, version identifier, and node identifier, facilitating subsequent incremental verification and version compilation.

[0032] In a preferred embodiment, constraint priority is not filled in separately by the configuration personnel, but is calculated and generated based on the constraint source, constraint strength, and reuse scope. The constraint source indicates that the constraint originates from an event rule, field rule, or mapping rule; the constraint strength indicates whether the constraint is mandatory, conditionally mandatory, or suggestive; and the reuse scope indicates how many events or nodes reference the constraint. The calculation formula is as follows:

[0033] in, Represents graph edges Constraint priority , , These represent the source weight, intensity weight, and reuse weight, respectively. Indicates the constraint source level value. Indicates the constraint strength level value. This represents the reuse scope level value. For example, if the source weight is 0.5, the strength weight is 0.3, and the reuse weight is 0.2; and a certain pre-dependent edge has a source level value of 3, a strength level value of 2, and a reuse scope level value of 1, then the constraint priority of this graph edge is 0.5×3 + 0.3×2 + 0.2×1 = 2.3. Constraint priority is used for conflict resolution and remediation candidate ranking, and does not replace the mandatory rules themselves.

[0034] In this embodiment, the constraint priority is designed based on the following: The constraint source level reflects the authority of the constraint—constraints originating from event-level mandatory rules should take precedence over constraints originating from field-level suggested rules, and constraints originating from node configurations should take precedence over constraints originating from interface mappings; the constraint strength level reflects the enforceability of the constraint—mandatory constraints (the process cannot be executed if violated) should take precedence over conditional mandatory constraints (cannot be violated under specific conditions) and warning constraints (only provide a warning); the reuse scope level reflects the breadth of the constraint's impact—constraints referenced by multiple events or nodes should take precedence over constraints referenced by only a single node. These three dimensions comprehensively determine the constraint processing priority from the perspectives of constraint authority, enforceability, and impact scope, enabling the system to distinguish between primary and secondary constraints when sorting constraint conflicts and repair candidates. The weights of each dimension are determined according to the priority principles for constraint conflict handling in workflow configuration management: source weight 0.5, because the constraint source directly determines the constraint's specification level, which is the most important priority factor; strength weight 0.3, because the enforceability directly affects whether the process can be executed; reuse weight 0.2, because the impact scope reflects the cost of modifying the constraint.

[0035] Let's take the constraint priority calculation of a certain employment registration item as an example. This item's constraint graph contains three edges: Edge E1 is a temporal edge, originating from the item-level node flow configuration (source level value is 3), with a constraint strength of mandatory (strength level value is 3), and is only referenced in the current version of the current item (reuse scope level value is 1), with a constraint priority of 0.5×3+0.3×3+0.2×1=2.6; Edge E2 is a data reference edge, originating from the field-level mapping configuration (source level value is 2), with a constraint strength of conditional mandatory (strength level value is 2), and is referenced by 3 similar items (reuse scope level value is 2), with a constraint priority of 0.5×2+0.3×2+0.2×2=2.0; Edge E3 is a rule reference edge, originating from the interface mapping configuration (source level value is 1), with a constraint strength of hint (strength level value is 1), and is only referenced in the current item (reuse scope level value is 1), with a constraint priority of 0.5×1+0.3×1+0.2×1=1.0. When constraint conflicts occur, the system processes them in descending order of priority: first, the timing requirements of edge E1 (2.6) are satisfied; second, the field mapping requirements of edge E2 (2.0) are satisfied; and finally, the rule hints of edge E3 (1.0) are considered. Through this constraint priority calculation, the system can process multiple constraints simultaneously acting on the same graph node or edge in an orderly manner according to their authority, enforceability, and scope of influence, preventing low-priority constraints from interfering with the normal execution of high-priority constraints.

[0036] Table 2 shows the commonly used representations of graph edges in the constraint diagram. A unified representation of graph edges allows node relationships, field relationships, and rule relationships to be read during the same validation process.

[0037] Table 2. Common ways to represent edges in a constraint diagram. Timing edge Pre-processing nodes Subsequent processing steps Node flow configuration Does circular dependency exist? Conditional edge Standard data elements or processing nodes Branch processing nodes Trigger condition configuration Does it have blank or duplicate values? Repulsive edge Processing nodes or branches Mutually exclusive processing nodes or branches Mutual exclusion configuration Are there mutually exclusive nodes that can be reached simultaneously? Data reference edge Standard data element Form fields or result fields Field mapping configuration Are there duplicate data collections or missing mappings? Rule reference edge Processing nodes or standard data elements Validate expression Rule configuration Does an index of failure rules exist? In this embodiment, the consistency verification is configured around the event constraint graph. The system performs topological sorting on the event constraint graph, reads the in-degree of all processing nodes, adds nodes with an in-degree of 0 to the processable set, removes nodes from the processable set, deletes their output temporal edges, and updates the in-degree of subsequent nodes. If all reachable nodes are processed, there is no closed loop in the temporal relationship; if there are still unprocessed nodes and their remaining in-degree is greater than 0, the unprocessed nodes form a candidate set for closed loops. For field duplicate collection verification, the system reads the set of input nodes corresponding to each standard data element code. If the same standard data element is collected by multiple acceptance-type nodes in the same path of the same event, and subsequent nodes do not use field reuse to reference previous outputs, a duplicate collection defect record is generated. For logical coverage verification, the system converts the triggering condition into an interval, set, or Boolean expression, and compares whether there is overlap and blankness in the conditions within the same branch group. For rule reference integrity verification, the system searches for the verification expression according to the rule index. If the index does not exist, the expression is empty, the standard data element referenced by the expression does not exist, or the expression type does not match the field type, a reference integrity defect record is generated.

[0038] The candidate set of closed loops after topological sorting can be represented by the following formula:

[0039] in, Describes the closed-loop candidate set. This represents the processing node in the constraint diagram. This indicates that the nodes are processed after the topology sorting is completed. The remaining in-degrees, This represents the set of processing nodes in a constraint diagram, with vertical lines indicating the filtering relationship between sets that satisfy subsequent conditions. For example, a constraint diagram containing processing nodes... , , , After the topological sort is completed, and The remaining in-degree is 0. and If the remaining in-degree is 1, then the candidate set for closed loops is { , The system then backtracks along the remaining time-series edges to extract the shortest closed path containing the aforementioned nodes and writes it into the configuration defect record.

[0040] The degree of overlap between triggering conditions can be calculated using the following formula:

[0041] in, Indicates triggering conditions With triggering conditions The degree of overlap between intervals, and These represent the triggering conditions. The lower and upper bounds of the corresponding intervals, and These represent the triggering conditions. The lower and upper bounds of the corresponding intervals, This indicates the operation of taking the larger value. This indicates that the smaller value is taken during the operation. For example, triggering conditions... The corresponding interval is [0, 5], trigger condition The corresponding interval is [3, 8]. The overlap length of the two intervals is 5 minus 3, resulting in 2. If the length of both intervals is 5, then the interval overlap is 2 ÷ 5 = 0.4. If overlap is not allowed within the same branch group, then this result corresponds to a duplicate coverage defect. If the union of multiple triggering conditions cannot cover the complete value range required by the item configuration, then it corresponds to an uncovered defect.

[0042] refer to Figure 7 The overlapping of trigger condition intervals expresses the degree of overlap between adjacent trigger condition intervals. The horizontal axis represents adjacent interval pairs, with each point representing a pair of adjacent intervals; the vertical axis represents the degree of overlap, calculated by formula (5) as the proportion of the overlap length to the shorter interval. A value of 0 indicates that the two intervals do not intersect; the higher the value, the easier it is for the branch conditions to be hit simultaneously. This diagram is used to check whether the condition configurations are mutually exclusive and continuous, avoiding the same instance from entering multiple conflicting branches. It assists configuration personnel in splitting, merging, or supplementing the trigger condition range to make business branches mutually exclusive and continuous.

[0043] Furthermore, when generating configuration defect records, the system saves the defect category, defect node, defect graph edge, constraint type, configuration source, discovery time, relevant standard data element codes, and relevant rule indexes. For loop defects, the system not only records closed-loop candidate nodes but also extracts the shortest closed path along the remaining time-series edges. The extraction of the shortest closed path starts from any closed-loop candidate node, visits subsequent nodes along the outgoing edges, until the starting node is revisited; if multiple paths exist, the path with fewer nodes is selected, and if the number of nodes is the same, the path with the lower sum of constraint priorities is selected as the repair candidate. For duplicate acquisition defects, the system records all processing nodes corresponding to the duplicate fields and determines whether there are reusable pre-output data elements. For logical coverage defects, the system records the trigger condition intervals that are not covered or are repeatedly covered and saves the branch group to which they belong. For referential integrity defects, the system records the failure rule index, referencing node, and referencing field. The above information is written into the configuration repair list, providing a definite data source for the subsequent generation of repair candidates.

[0044] refer to Figure 4 In this embodiment, the event constraint graph, after configuration consistency verification, is compiled into a workflow description file. During compilation, the system extracts the execution entry point, execution exit point, and abnormal branch entry point of each processing node according to the node execution order. The execution entry point indicates the entry position of a node that can be called by the workflow engine; the execution exit point indicates the status output after the node is completed; and the abnormal branch entry point indicates the entry position of abnormal paths such as material correction, manual review, delayed processing, or termination processing. The system generates a bidirectional mapping table between standard data elements and event form fields according to field mapping relationships. The bidirectional mapping table includes standard data element codes, form field identifiers, conversion expressions, default value handling methods, null value handling methods, and output field identifiers. The system generates a verification rule call sequence according to the rule index, and the call sequence is arranged according to the node order and rule priority. After compilation, the execution entry point, execution exit point, abnormal branch entry point, bidirectional mapping table, and verification rule call sequence are encapsulated into a workflow description file, and a version signature is generated. When the workflow engine creates a process instance, it only reads the published workflow description file and does not directly read uncompiled configuration items.

[0045] Version signatures can be generated using a deterministic digest calculation method, used to identify whether various configuration versions in the workflow description file have changed. The calculation formula is as follows:

[0046] in, Indicates the first Version signature of a workflow description file Indicates the configuration version number of the item. Indicates the node template version number. This indicates that the field maps to the version number. Indicates the version number of the verification rule. Indicates the external interface adaptation version number. to Represents a fixed summary coefficient. This represents the modulo operation. This represents the modulo cardinality. For example, if the fixed digest coefficients are 31, 37, 41, 43, and 47 respectively, the item configuration version number is 12, the node template version number is 8, the field mapping version number is 5, the validation rule version number is 4, the external interface adaptation version number is 2, and the modulo cardinality is 1000003, then the version signature is... (31×12+37×8+41×5+43×4+47×2)=1139. After the version signature is written to the workflow description file, process instances can be bound to the same version at creation time to prevent different configuration versions from being mixed during runtime.

[0047] In this embodiment, the version signature design is based on the following: the item configuration version number reflects the change status of the item-level process configuration; the node template version number reflects the change status of the processing node definition; the field mapping version number reflects the change status of the mapping relationship between standard data elements and form fields; the validation rule version number reflects the change status of the rule expression; and the external interface adaptation version number reflects the change status of the data exchange adaptation configuration with external systems. These five dimensions cover the five core components of the workflow description file. Any change in any part will result in a deterministic change in the version signature, thus ensuring that the version signature can uniquely identify the complete configuration status of the workflow description file. A prime number coefficient (31, 37, 41, 43, 47) is used to reduce the probability of different version number combinations producing the same signature; the modulo base is a relatively large prime number of 1000003, which makes the signature value distribution range wider and further reduces the collision probability.

[0048] Let's take the version evolution of a public employment service item as an example. When this item was initially released, the item configuration version number was 1, the node template version number was 1, the field mapping version number was 1, the validation rule version number was 1, the external interface adaptation version number was 1, and the version signature was (31×1+37×1+41×1+43×1+47×1)mod1000003=199. Subsequently, the configuration personnel adjusted the field mapping, raising the field mapping version number to 2, while keeping other version numbers unchanged. The new version signature was (31×1+37×1+41×2+43×1+47×1)mod1000003=240, clearly indicating the change in configuration version from 199 to 240. After another rule adjustment, the validation rule version number was increased to 2, while other version numbers remained unchanged (the field mapping version number remained 2). The new version signature is (31×1+37×1+41×2+43×2+47×1)mod1000003=283. If an adjustment simultaneously involves three dimensions—item configuration, node template, and external interface adaptation—and the item configuration version number is increased to 2, the node template version number is increased to 2, and the external interface adaptation version number is increased to 2, while the field mapping and validation rule version numbers remain unchanged (2 and 2 respectively), then the version signature is (31×2+37×2+41×2+43×2+47×2)mod1000003=398. Because the version signature produces a calculable deterministic response to any change in any of the five dimensions, the system can quickly determine whether the configurations are completely identical by comparing the version signatures of two workflow description files, without needing to compare the configuration content item by item. When a process instance is created, it is bound to the signature of the current version. Even if the configuration changes during runtime, the created instance will still execute according to the bound version, avoiding inconsistent execution paths caused by configuration changes in the running process. Through the above version signature calculation, the system provides a lightweight version identification mechanism for workflow description files, supporting rapid comparison of configuration versions, version binding of process instances, and traceability verification of historical configurations.

[0049] refer to Figure 8 The version signature trend expresses the trend of the configuration version summary value changing with the version number. The horizontal axis is the version number, representing the version iteration order; the vertical axis is the signature value, which is calculated by weighting and moduloing the items, nodes, field mappings, rules, and adapted versions using formula (6). A stable curve indicates that the version composition has changed little, while a jump in the curve indicates that the configuration content has been significantly adjusted. This graph is used to support release tracing, runtime instance binding, and version rollback judgment. It is used to show the impact of version changes on the determinism of executable description files, supporting instance tracing and release reconciliation.

[0050] In a preferred embodiment, the same-source reference relationship is further processed. The system obtains candidate fields from different public employment service items that point to the same person, the same employment status, or the same processing result. Candidate fields can come from the personnel identity field in employment registration items, the personnel identification field in unemployment registration items, the applicant identification field in subsidy application items, or fields representing employment status, registration results, or review conclusions in different items. The system generates a field merging score based on field name similarity, value domain inclusion relationship, validation expression consistency, and historical mapping relationship. When multiple candidate fields belong to the same standard data element code, the system still retains the item source and transformation expression of each candidate field. For example, if one item uses an employment status field with 0 representing unemployed and 1 representing employed, and another item uses a personnel employment status field with unemployed and employed as enumeration values, both can belong to the same standard data element code, but the enumeration transformation expression needs to be retained. If there is a value domain conflict among candidate fields, for example, one field contains a flexible employment value, and another field does not contain the corresponding value, the conflicting field is written into the data element set to be confirmed and does not participate in the compilation of the workflow description file before confirmation. This process prevents conflicting fields from being incorrectly merged and entering the process execution path.

[0051] Furthermore, conflicting fields in the set of data elements to be confirmed are merged according to their conflict fingerprints. Conflict fingerprints are generated from the source of the event, differences in value ranges, and differences in transformation expressions. The source of the event is used to determine whether the conflict originates from the same type of public employment service event; differences in value ranges are used to determine whether the conflict is concentrated in newly added enumerated values, differences in the meaning of enumerated values, or differences in numerical ranges; differences in transformation expressions are used to determine whether there are differences in the direction of field transformation, differences in default values, or differences in handling null values. Conflicting fields with the same conflict fingerprint are merged into the same conflict group. For each conflict group, the system generates candidate standard data element codes, candidate value ranges, and candidate transformation expressions. After configuration confirmation, the system writes the confirmed candidate standard data element codes, candidate value ranges, and candidate transformation expressions into the standard data element library and re-triggers the incremental verification task related to the conflicting field. If the confirmation result indicates that the conflicting field should be split into multiple standard data elements, the system retains the original field mapping relationship and establishes transformation restrictions for different standard data elements to prevent incorrect cross-event references.

[0052] In this embodiment, the event constraint graph adopts a hierarchical storage structure. The event layer graph structure uses the event code as an index to store the reuse relationships, version relationships, and release status between events. The node layer graph structure uses the processing node as an index to store the node's entry conditions, exit conditions, abnormal branch entry points, prerequisite dependencies, and mutual exclusion relationships. The field layer graph structure uses the standard data element code as an index to store the field's source, value range, validation expression, output mapping, and same-source reference relationship. A cross-layer index is established between the event layer, node layer, and field layer. The cross-layer index records which processing nodes reference a certain standard data element, which event versions a certain processing node belongs to, and which fields or nodes call a certain rule expression. When any standard data element, processing node, or constraint condition changes, the system locates the affected graph nodes and edges based on the cross-layer index and generates an incremental validation task. The incremental validation task only performs topology validation, duplicate collection validation, logical coverage validation, and reference integrity validation on the affected area, without reprocessing the event constraint graph unrelated to the change.

[0053] The affected area can be calculated using reachable paths. The calculation formula is as follows:

[0054] in, This represents the set of areas affected by the change. This represents the set of graph nodes or edges that have changed. This indicates the affected processing node, standard data element, or rule reference object. This indicates that there exists a change object in the event constraint diagram. To object reachable path, This indicates the existence of an operation. For example, if the set of changed objects includes the standard data element "employment status," and the event constraint graph contains data reference edges from the employment status to the qualification verification node, and also temporal edges from the qualification verification node to the audit node, then both the qualification verification node and the audit node belong to the set of changes' impact scope. If there is no reachable path between the archive node and the data element, then the incremental verification task will not be initiated. This method ensures that the verification scope after a configuration change is determined by graph relationships, rather than by manual selection.

[0055] Table 3 shows the correspondence between tiered storage and incremental verification, illustrating how changed objects are mapped to verification tasks.

[0056] Table 3. Correspondence between Tiered Storage and Incremental Verification Standard data element The processing node and rule expression that reference this data element Repeated data collection, field mapping, rule referencing Fields affect records Processing nodes Version of the item and adjacent time series edges Topological sorting, mutual exclusion nodes, and abnormal branch entry points Node impact record Triggering conditions Belonging to branch group and associated standard data element Condition coverage, condition overlap, blank interval Conditional Influence Records Validate expression The node and field that call this expression Reference integrity, field type matching Rules affect records Field mapping relationship Corresponding standard data elements and output fields Bidirectional mapping, null value handling, and transformation expressions Mapping effect records refer to Figure 5In a preferred embodiment, after generating the configuration repair list, the system matches a preset repair template according to the defect category. The repair template does not directly modify the configuration, but rather generates repair candidates to be confirmed. For loop defects, the system converts the shortest closed path into dependency disconnection candidates, which include disconnectable temporal edges, preceding nodes after disconnection, subsequent nodes after disconnection, and disconnection criteria. For duplicate data collection defects, the system converts the processing nodes corresponding to duplicate fields into field reuse candidates, which include preceding output data elements, subsequent reference nodes, and replaceable input fields. For condition coverage defects, the system converts trigger condition intervals into condition rearrangement candidates, which include intervals that need to be split, intervals that need to be merged, and intervals that need to be supplemented. For referential integrity defects, the system converts invalid rule indexes into rule rebinding candidates, which include candidate validation expressions, applicable field types, and applicable processing nodes. All candidates are sorted according to the constraint priority in the event constraint diagram and written into the workflow configuration version to be released. The version to be released does not change the released version before confirmation; after confirmation, the event constraint diagram is regenerated and consistency checks are performed.

[0057] The order of repair candidates can be calculated using the following formula:

[0058] in, Indicates the first The ranking score of the repair candidates , , , These represent the constraint priority weight, impact scope weight, defect category weight, and change cost weight, respectively. This indicates the constraint priority value of the candidate item involving graph edges. This indicates the level of influence of the candidate options. Indicates the defect category level value. This represents the change cost level value. For example, if a dependency disconnection candidate has a constraint priority value of 5, an impact scope level value of 3, a defect category level value of 2, and a change cost level value of 1, with weights of 0.4, 0.25, 0.2, and 0.15 respectively, then the ranking score is 0.4×5 + 0.25×3 + 0.2×2 + 0.15×1 = 3.3. The ranking score is used for candidate arrangement; however, mandatory rules and data element constraints must still be met during configuration confirmation.

[0059] In this embodiment, the ranking score is designed based on the following criteria: the constraint priority value h_j reflects the importance of the constraints on the graph edges involved in the repair candidate; the impact range level value reflects the number of nodes or fields affected by the repair operation; the defect category level value g_j reflects the severity of the defect being repaired (loop defects are the most severe, followed by referential integrity defects, then duplicate collection defects, and logical coverage defects are relatively minor); and the change cost level value reflects the workload required to implement the repair (disconnecting dependent edges has the lowest cost, adjusting field mappings has a medium cost, rearranging trigger conditions has a high cost, and rebinding rule indexes has the highest cost). These four dimensions comprehensively evaluate the priority of repair candidates from the perspectives of constraint importance, impact range, defect severity, and implementation cost, enabling configuration personnel to prioritize candidates with high impact and low cost when confirming repair solutions. The weights for each dimension are determined based on the priority principles in configuration repair practices: constraint priority weight 0.40, because constraint importance is the primary factor determining repair priority; impact scope weight 0.25, because repairs with a wide impact should be prioritized to avoid cascading defects; defect category weight 0.20, because the severity of defects directly affects whether the process can operate normally; change cost weight 0.15, because implementation costs affect repair efficiency and serve as a secondary reference factor.

[0060] The following example illustrates the repair of a configuration defect in an employment registration item. During configuration consistency verification, the system detected three defects and generated three repair candidates: Candidate H1 is a dependency disconnection candidate, used to repair loop defects (involving graph edge constraint priority value of 5, impact range level value of 2, defect category level value of 3—loop defects are the most severe, change cost level value of 1—disconnecting dependency edges has the lowest cost), with a ranking score of 0.4×5+0.25×2+0.2×3+0.15×1=3.25; Candidate H2 is a field reuse candidate, used to repair duplicate data collection defects (involving graph edge constraint priority value of 3, impact range level value of 4—involving field reuse across 4 processing nodes, defect category level value of...). 2—Duplicate data collection defect severity is moderate, change cost level is 2—field mapping adjustment cost is moderate), ranking score is 0.4×3+0.25×4+0.2×2+0.15×2=2.90; Candidate H3 is a rule rebinding candidate, used to repair referential integrity defects (involving graph edge constraint priority value is 4, impact range level is 1—only affects a single node, defect category level is 2—referential integrity defect severity is moderate, change cost level is 3—rule rebinding requires re-validation of expressions, cost is high), ranking score is 0.4×4+0.25×1+0.2×2+0.15×3=2.70. The system arranges candidates from high to low ranking score: H1 (3.25) is displayed first, H2 (2.90) second, and H3 (2.70) third. Configuration personnel confirm the repair plan one by one in this order, prioritizing the most serious problem of loop defects. By calculating the sorting scores as described above, the system can provide configuration personnel with orderly repair suggestions, improve configuration repair efficiency, and avoid repeated repair work due to improper repair order.

[0061] In this embodiment, the creation process of the workflow description file is separated from the process instance creation process. After the workflow description file is published, the process instance creation reads the item code and version signature to determine the corresponding node execution order, field mapping relationship, and rule call sequence. When the process instance enters the acceptance node, the system converts the item form fields into standard data elements according to the two-way mapping table; when it enters the qualification verification node, the system reads the required standard data elements and executes the verification expression according to the rule call sequence; when it enters the review node, the system reads the output data elements of the preceding node and the abnormal branch status; when it enters the result generation node, the system converts the standard data elements into item result fields; when it enters the archiving node, the system saves the processing trajectory, version signature, and field mapping summary. Since the process instance is bound to the compiled description file, unpublished configuration modifications will not affect running process instances. If a new version configuration is published, subsequent newly created instances will read the new version description file, and existing instances will continue to execute according to the bound version. This approach ensures that the same instance uses consistent node, field, and rule configurations throughout its lifecycle.

[0062] In a preferred embodiment, the rule expression is stored in a structured format instead of as an unparseable string. The structured rule includes a rule identifier, rule type, reference standard data element encoding, comparison operators, comparison objects, null value handling methods, and failure branch entry points. The rule type can be a required field validation, enumeration validation, range validation, correlation validation, or result validation. Comparison operators include equal to, not equal to, greater than, less than, contain, belong to, not belong to, and exist. Comparison objects can be fixed values, value sets, other standard data elements, or node output values. The null value handling method determines whether to enter a correction branch, a manual review entry point, or directly determine failure when a field is null. The failure branch entry point determines the abnormal branch the process enters after a rule failure. When compiling the rule call sequence, the system reads rules according to the node execution order, then arranges rules within the same node according to constraint priority, with mandatory rules taking precedence over prompt rules, and field validity rules taking precedence over result generation rules. This structured processing enables the reference integrity validation to identify field references and node references in the rule expression.

[0063] In a preferred embodiment, a bidirectional mapping table is used to handle the conversion between standard data elements and form fields and result fields. After receiving the original fields on the acceptance page, the system looks up the standard data element code based on the form field identifier, and then generates the standard data element value according to the conversion expression. When generating the result, the system looks up the result field identifier based on the standard data element code, and generates the result field according to the output conversion expression. If the input field is empty, the system determines whether to retain the empty value, use the default value, enter the correction branch, or trigger the manual review entry according to the empty value handling method. If the field types do not match, for example, if the form field is text and the standard data element is a date, the system performs a format conversion according to the conversion expression; if the conversion fails, a mapping defect record is generated. The bidirectional mapping table also stores a summary relationship between the original field values ​​and the converted field values ​​for subsequent traceability. Through this processing, when the form structure changes, only the field mapping relationship needs to be updated and the workflow description file recompiled; the processing node still reads data through standard data elements.

[0064] In this embodiment, abnormal branch entry points are treated as a type of exit point for processing nodes, rather than manual processing markers detached from the flowchart. Abnormal branch entry points include material correction entry points, manual review entry points, delayed processing entry points, and termination processing entry points. The material correction entry point is bound to missing material data elements and correction description data elements; the manual review entry point is bound to the reason for review, the field to be reviewed, and the review conclusion data elements; the delayed processing entry point is bound to the external data waiting flag and retry status data elements; and the termination processing entry point is bound to the termination reason and termination result code. Abnormal branch entry points are also written into the event constraint graph and participate in mutual exclusion conditions and prerequisite dependency checks. For example, there is an exclusion edge between the termination processing entry point and the result generation node to prevent the same instance from simultaneously forming a termination state and a normal completion state; there is a timing edge between the material correction entry point and the review node to prevent the review process from starting before the materials are corrected. This processing ensures that abnormal branches no longer rely on runtime ad-hoc judgments but are incorporated into unified constraints during the compilation phase.

[0065] In a preferred embodiment, when repairing configuration defect records, the system maintains the correspondence between the original configuration version, repair candidates, and the version to be released. The version to be released includes an item code, parent version signature, repair candidate identifier, change graph nodes, change graph edges, and change descriptions. After confirming a repair candidate, the system does not directly overwrite the original configuration but generates a new version item constraint graph based on the parent version. The new version item constraint graph re-executes topology sorting, duplicate data collection verification, logical coverage verification, and reference integrity verification. If the verification fails, the new version remains in the pending release state, and a new configuration defect record is generated; if the verification passes, the system compiles a new workflow description file and generates a new version signature. Released versions are retained in the version repository, historical process instances continue to execute according to the original version, and new process instances can select the currently released version. This approach makes the configuration repair process traceable and avoids introducing new hidden defects when repairing one defect.

[0066] In a preferred embodiment, when similar nodes exist among public employment service items, the system can merge nodes based on a standard node template. The object of node merging is not a running process instance, but rather processing nodes with the same input data elements, output data elements, and constraint relationships during the configuration phase. For example, both employment registration and unemployment registration items may have a personnel basic information verification node, which references standard data elements such as personnel identification, name, document type, and contact information, and outputs a personnel basic information verification conclusion. The system compares the input data element set, output data element set, trigger condition type, and rule call sequence of candidate nodes. If the merging conditions are met, the candidate nodes are bound to the same standard node template, while preserving the differences in item source and abnormal branches. When the standard node template is updated, the system locates the item constraint graph referencing the template through cross-layer indexing and generates an incremental verification task. After node template merging, the rule configuration and field references of similar nodes remain consistent, while preserving the differentiated branches required for different items.

[0067] In this embodiment, after the standardized processing flow instance for public employment services is created, the execution trajectory can also be used to verify the configuration. The process instance records the node entry time, node exit time, input standard data element summary, output standard data element summary, rule call result, branch selection result, and abnormal branch status at each processing node. The execution trajectory does not change the published workflow description file, but can serve as a data source for subsequent configuration verification. For example, if the same matter frequently enters the material correction entry in a large number of instances, and the correction reason all points to the same standard data element, then the required attributes, field sources, and null value handling methods of that standard data element can be checked during the configuration phase to ensure consistency. If a rule index continuously returns field type mismatches during execution, a rule rebinding candidate can be added to the configuration repair list. The execution trajectory and the matter constraint diagram are associated through version signatures. The system only uses the execution trajectory under the same version for configuration analysis of that version, avoiding data mixing between different versions. This processing is used to improve the configuration closed loop, but does not replace the consistency verification before release.

[0068] In a preferred embodiment, condition coverage verification can handle three types of triggering conditions: enumeration, numerical, and Boolean. Enumeration triggering conditions use set operations to determine if there are duplicate or missing enumeration values; numerical triggering conditions use interval operations to determine if there are overlapping or blank intervals; Boolean triggering conditions use a set of truth values ​​to determine if both true and false conditions are covered. For compound conditions, the system decomposes the compound condition into standard data elements, comparison operators, and comparison objects, and then converts them into computable expressions. If two compound conditions reference the same standard data element and their comparison objects intersect, then duplicate coverage verification is performed; if the union of multiple compound conditions cannot cover the complete value range, then blank interval verification is performed. The verification result is written to the configuration defect record, and the branch group to which the triggering condition belongs is recorded. A branch group refers to multiple subsequent nodes output from the same processing node and determined by the same standard data element or the same rule result. By limiting the branch group, the system avoids misjudging conditions with the same field in different processing stages as conflicts.

[0069] In a preferred embodiment, duplicate data collection verification is performed on a process path-by-path basis. The system generates a set of reachable paths based on the event constraint graph. Each path consists of processing nodes such as acceptance nodes, qualification verification nodes, review nodes, result generation nodes, and archiving nodes. For each path, the system reads the set of input data elements for each processing node. If the same standard data element is marked as manually collected at multiple nodes in the path, and subsequent nodes do not reference the output data elements of preceding nodes, it is determined as duplicate collection. If the same standard data element is collected in one node and used as system verification input in another node, it is not determined as duplicate collection; if a field is collected in different mutually exclusive paths, it is also not determined as duplicate collection. This processing determines duplicate collection based on graph paths and mutual exclusion relationships, rather than simply counting the number of times a field appears. The configuration defect record stores the processing node, path identifier, and reusable output data elements corresponding to duplicate fields, facilitating the generation of field reuse candidates.

[0070] In a preferred embodiment, the reference integrity check includes rule index integrity, field reference integrity, and mapping expression integrity. Rule index integrity is used to determine whether the rules referenced in the rule call sequence exist and whether the rule version is consistent with the workflow description file version. Field reference integrity is used to determine whether the standard data elements referenced by the rule expression exist and whether the field type meets the comparison operator requirements. Mapping expression integrity is used to determine whether there is a bidirectional mapping between standard data elements and form fields or result fields, whether the transformation expression has input and output ends, and whether the null value handling method is clear. If a rule expression references a non-existent standard data element, the system writes the standard data element encoding, rule identifier, and reference node into the defect record; if a mapping expression lacks an output field, the system writes the corresponding standard data element, item form field, and output field identifier into the defect record. This process ensures that every reference in the compiled workflow description file can be parsed.

[0071] In this embodiment, the workflow configuration version to be released is used to store repair candidates and candidate configuration changes, and does not directly participate in the creation of workflow instances. The version to be released can contain multiple candidates, but each candidate is associated with a configuration defect record. Dependency disconnection candidates are used to handle loop defects, field reuse candidates are used to handle duplicate data collection defects, condition rearrangement candidates are used to handle condition coverage defects, and rule rebinding candidates are used to handle referential integrity defects. The system ranks the candidates according to their ranking scores and marks those involving mandatory constraints as requiring priority confirmation. After configuration confirmation, the system modifies the event constraint graph based on the confirmation results and re-executes the verification. If there are conflicts between multiple candidates, for example, one candidate requires disconnecting a certain time-series edge, and another candidate requires establishing a field reuse relationship based on that time-series edge, the system generates a conflict prompt based on the constraint priority in the event constraint graph and the referential relationships between the candidates, and requires a reselection of the candidate combination. This process makes the repair process controlled by the constraint graph, reducing the arbitrariness of configuration modifications.

[0072] In a preferred embodiment, a release link is established between the standard data metadata library, the event constraint diagram, and the workflow description file. The standard data metadata library stores field specifications, the event constraint diagram stores configuration constraints, and the workflow description file stores executable configurations. In the release link, each configuration release records the standard data metadata version, the event constraint diagram version, and the workflow description file version. If the standard data metadata library changes, the system generates a set of affected event constraint diagrams through cross-layer indexing; if the event constraint diagram passes incremental and full validation, the workflow description file is recompiled; if the workflow description file generates a new version signature, the release link records the correspondence between the parent version and the new version. When a process instance is created, it is only bound to the workflow description file version, but the corresponding standard data metadata version and event constraint diagram version can be traced through the release link. This process maintains the association between configuration versions, field versions, and execution versions, facilitating consistency verification between historical instances and ongoing instances.

[0073] In a preferred embodiment, the configuration import process for public employment service items is also standardized. During configuration import, the system reads the item code, node list, field list, and rule list from the external configuration file or configuration table. The system first performs standard data element matching on the field list, then performs processing node splitting and node type identification on the node list, and finally generates rule reference edges based on the rule list. If a node in the imported configuration lacks prerequisite dependencies, the system marks it as an orphan node; if a field in the imported configuration cannot match standard data elements, the system writes it into the set of data elements to be confirmed; if a rule in the imported configuration cannot be parsed into a structured rule, the system writes it into the invalid rule index record. After import, the system generates a constraint graph for unpublished items and performs consistency verification. This process ensures that externally imported configurations undergo the same constraint graph verification process before entering the workflow engine, avoiding different verification standards from different configuration sources.

[0074] In this embodiment, configuration data storage can be implemented using relational tables, graph databases, or document databases, but the logical structure remains consistent regardless of the underlying storage method. The standard data element library uses the standard data element code as the primary key to store field specifications and source references; the item constraint graph uses the item code and version identifier as the primary key to store graph nodes and edges; the workflow description file uses the item code and version signature as the primary key to store executable process configurations; the configuration defect record uses the defect identifier as the primary key to store defect category, location object, and configuration source; the configuration repair list uses the repair list identifier as the primary key to store repair candidates and versions to be released. When implementing with relational tables, graph nodes and edges can be stored as node tables and edge tables, respectively; when implementing with a graph database, processing nodes, standard data elements, and rule expressions can be stored as node objects; when implementing with a document database, constraint graphs of the same item version can be stored as structured documents. The above storage methods do not change the processing logic of the method.

[0075] In a preferred embodiment, the workflow description file is stored as a structured file, which includes basic item information, node execution order, node entry and exit definitions, abnormal branch definitions, a standard data element reference table, a bidirectional mapping table, a rule call sequence, a mutual exclusion condition table, and a version signature. The node execution order is generated by the topology sorting result; the node entry and exit definitions are generated by the processing node configuration; the abnormal branch definitions are generated by the abnormal branch entry; the standard data element reference table is generated by the input and output data elements of each node; the bidirectional mapping table is generated by field mapping relationships; the rule call sequence is generated by the rule index and constraint priority; the mutual exclusion condition table is generated by the exclusion edges; and the version signature is generated by version digest calculation. When the workflow engine reads the structured file, it does not need to parse the original configuration table again, but directly creates the process state machine according to the node execution order and executes node processing according to the field mapping relationships and rule call sequence. This process reduces the dependence on scattered configuration items during the runtime phase.

[0076] In this embodiment, the validation of the event constraint diagram can be triggered when the configuration is saved, before the configuration is published, and during version migration. When the configuration is saved, a partial validation is performed, checking only the directly related objects of the modified nodes, fields, or rules. Before the configuration is published, a full validation is performed, covering the entire event constraint diagram. During version migration, a difference validation is performed, determining the scope of impact based on the changed objects between the parent and new versions. The results of partial validation are used to promptly detect configuration errors, the results of full validation are used to determine whether a workflow description file can be generated, and the results of difference validation are used to determine the migration relationship between historical and new versions. Each validation outputs a configuration defect record, but the defect record contains different triggering sources. This process ensures that configuration validation is performed throughout the entire process from editing to publishing, and maintains consistency in defect location information.

[0077] In a preferred embodiment, a version migration map is used to handle the conversion of existing configuration items to a new version. The version migration map stores the standard data element codes of the old version, the standard data element codes of the new version, the processing node identifiers of the old and new versions, the rule indexes of the old and new versions, and migration conditions. If the new version only adds field mappings without changing the node execution order, the migration map records the default value processing method and applicable nodes for the added fields. If the new version changes the node prerequisites, the migration map records the migrateable and non-migrateable process states. If the new version changes the rule expressions, the migration map records the correspondence between the old and new rule results. After the migration map is generated, the system performs a consistency check on the new version's item constraint graph; migration is only allowed after the check passes. This process ensures that configuration version evolution is controlled by three types of mapping constraints: data elements, nodes, and rules.

[0078] In this embodiment, the execution results of the standardized processing method for public employment services include published workflow description files, creatable process instances, configuration defect records, configuration repair lists, workflow configuration versions to be published, and standard data element library update records. Published workflow description files are used by the workflow engine to create process instances; configuration defect records are used to locate configuration issues in graph nodes, edges, fields, or rules; the configuration repair list is used to save repair candidates; the workflow configuration versions to be published are used to save configuration changes before confirmation; and standard data element library update records are used to track the results of field merging, field splitting, and conflict field handling. All of the above results are derived from configuration data, standard data elements, and event constraint graphs, without relying on manual judgment of process paths during runtime. This method, through constraint graph modeling, configuration consistency verification, workflow description file compilation, and hierarchical index incremental verification, provides a calculable, verifiable, and traceable technical foundation for the process configuration of public employment service items.

Claims

1. A standardized processing method for public employment services based on workflow configuration, characterized in that: include: Obtain the item configuration data and standard data elements for public employment services; The configuration data for the matter is split into multiple processing nodes, and input data elements, output data elements, triggering conditions, prerequisite dependencies, and mutual exclusion conditions are bound to the processing nodes. A constraint diagram is generated based on the processing nodes, the standard data elements, and their binding relationships; Perform configuration consistency verification on the constraint graph of the aforementioned items; After the verification is passed, the constraint graph of the matter is compiled into a workflow description file containing the node execution order, field mapping relationship and rule index; Create a standardized processing flow instance for public employment services based on the workflow description file; Generating the event constraint graph includes: converting the processing node, the input data element, and the output data element into graph nodes respectively; forming sequential edges based on the prerequisite dependencies, conditional edges based on the triggering conditions, exclusionary edges based on the mutual exclusion conditions, and data reference edges based on the field mapping relationships; writing constraint type, constraint source, and constraint priority to each graph edge, and storing the event constraint graph hierarchically according to the event code, version identifier, and node identifier; the constraint priority is not filled in separately by the configuration personnel, but is calculated and generated based on the constraint source, constraint strength, and reuse scope; the constraint source indicates that the constraint comes from the event rule, field rule, or mapping rule; the constraint strength indicates whether the constraint is mandatory, conditionally mandatory, or suggestive; the reuse scope indicates how many events or nodes reference the constraint. The configuration consistency verification of the constraint graph includes: performing topological sorting on the constraint graph to determine the set of processing nodes with loops; performing duplicate collection verification on input data elements with the same standard data element code; performing logical coverage verification on the triggering conditions and the mutually exclusive conditions; performing referential integrity verification on the verification expression pointed to by the rule index; generating configuration defect records for graph nodes, graph edges, constraint types, and configuration sources that fail the verification; for field duplicate collection verification, the system reads the set of input nodes corresponding to each standard data element code. If the same standard data element is collected by multiple acceptance type nodes in the same path of the same matter, and subsequent nodes do not use field reuse to reference the previous output, a duplicate collection defect record is generated; for logical coverage verification, the system converts the triggering conditions into intervals, sets, or Boolean expressions, and compares whether there is overlap and blankness in the conditions within the same branch group; for rule referential integrity verification, the system searches for the verification expression according to the rule index. If the index does not exist, the expression is empty, the standard data element referenced by the expression does not exist, or the expression type does not match the field type, a referential integrity defect record is generated. Compiling the constraint diagram into a workflow description file includes: extracting the execution entry point, execution exit point, and abnormal branch entry point of the processing node according to the node execution order; generating a bidirectional mapping table between standard data elements and item form fields according to the field mapping relationship; generating a verification rule call sequence according to the rule index; and encapsulating the execution entry point, execution exit point, abnormal branch entry point, bidirectional mapping table, and verification rule call sequence into a workflow description file with a version signature. The version signature is designed based on the following: the item configuration version number reflects the change status of the item-level process configuration; the node template version number reflects the change status of the processing node definition; the field mapping version number reflects the change status of the mapping relationship between standard data elements and form fields; the verification rule version number reflects the change status of the rule expression; and the external interface adaptation version number reflects the change status of the data exchange adaptation configuration with external systems. The event constraint graph adopts a hierarchical storage structure. The event layer graph structure uses the event code as an index to store the reuse relationship, version relationship, and release status between events. The node layer graph structure uses the processing node as an index to store the entry condition, exit condition, abnormal branch entry, prerequisite dependency, and mutual exclusion relationship of the node. The field layer graph structure uses the standard data element code as an index to store the field source, value range, validation expression, output mapping, and same-source reference relationship. A cross-layer index is established between the event layer, node layer, and field layer. The cross-layer index records which processing nodes reference a certain standard data element, which event versions a certain processing node belongs to, and which fields or nodes call a certain rule expression. When any standard data element, processing node, or constraint condition changes, the system locates the affected graph nodes and edges based on the cross-layer index and generates an incremental validation task. The incremental validation task only performs topology validation, duplicate collection validation, logical coverage validation, and reference integrity validation on the affected scope, and does not reprocess the event constraint graph unrelated to the change.

2. The standardized processing method for public employment services based on workflow configuration according to claim 1, characterized in that, Obtaining the standard data elements includes: The original fields are normalized according to their source, type, scope of application, and processing steps in public employment services, and standard data element codes are assigned to the normalized fields. The standard data element encoding is associated with field names, value ranges, required attributes, validation expressions, source identifiers, and output mapping relationships. Establish a common-source reference relationship for fields with the same semantics but different field names, and write the common-source reference relationship into the standard data element database.

3. The standardized processing method for public employment services based on workflow configuration according to claim 2, characterized in that, Processing the aforementioned same-source reference relationship includes: Retrieve candidate fields from different public employment service items that point to the same person, the same employment status, or the same processing result; A field merging score is generated based on field name similarity, value range inclusion relationship, validation expression consistency, and historical mapping relationship. When multiple candidate fields belong to the same standard data element encoding, the item source and transformation expression of each candidate field are preserved; When a candidate field has a conflicting value range, the conflicting field is written into the set of data elements to be confirmed, and the conflicting field is prohibited from participating in the compilation of the workflow description file.

4. The standardized processing method for public employment services based on workflow configuration according to claim 1, characterized in that, After generating the configuration defect record, the following is also included: Determine the defect category based on the constraint type in the configuration defect record; For loop defects, extract the shortest closed path; for duplicate collection defects, extract the processing node corresponding to duplicate fields; for logical coverage defects, extract the trigger condition range that is not covered or is repeatedly covered; for referential integrity defects, extract the failure rule index. Write the defect category, the shortest closed path, the processing node, the trigger condition range, and the failure rule index into the configuration repair list.

5. The standardized processing method for public employment services based on workflow configuration according to claim 3, characterized in that, The processing of the set of data elements to be confirmed includes: Generate conflict fingerprints based on the source of the conflicting fields, differences in their value ranges, and differences in their transformation expressions; Group conflicting fields with the same conflicting fingerprint into the same conflict group; For the conflict group, generate candidate standard data element codes, candidate value ranges, and candidate transformation expressions; Upon receiving the confirmed candidate standard data element encoding, candidate value range, and candidate transformation expression, the standard data element library is updated, and the incremental verification task related to the conflicting field is re-triggered.

6. The standardized processing method for public employment services based on workflow configuration according to claim 4, characterized in that, Processing the configuration repair list includes: Match a preset repair template according to the defect category; The shortest closed path is converted into a dependency disconnection candidate, the processing node corresponding to the duplicate field is converted into a field reuse candidate, the trigger condition interval is converted into a condition rearrangement candidate, and the failure rule index is converted into a rule rebinding candidate. Sort the candidate items according to the constraint priority in the constraint diagram, and write the sorted candidate items into the workflow configuration version to be released.

Images