Travel saas tenant entering link-oriented self-inspection method and travel saas tenant entering link-oriented self-inspection system

Abstract

The invention discloses a self-inspection method and system for a travel saas tenant entering link. The invention relates to the technical field of saas travel systems. According to input tenant basic information, entity data possibly related to a tenant are identified and extracted from the knowledge graph module, and the entity data comprise predefined entity templates such as a transport capacity company settlement rule, a pricing configuration item, a driver and vehicle binding check item and the like; the requirements of tenants are greatly different, and the traditional scheme is difficult to find balance between personalized configuration and standardized verification, so that the customization cost is high and the verification logic is disordered. According to the method, tenant configuration is abstracted into entities (such as pricing rules and driver binding rules) and relationships (such as including and dependency), and standardized expression is achieved. A verification rule is automatically generated according to tenant configuration, for example, the tenant A needs to price according to mileage, the system automatically associates the mileage pricing rule for verification, and hard coding is not needed.

Description

Technical Field

[0001] The present invention relates to the technical field of SaaS travel systems, specifically to the technical direction of tenant inspection, and especially to a self-inspection method and system for a travel SaaS tenant entry link. Background Art

[0002] Software as a Service (SaaS) is a cloud computing-based software delivery model that provides standardized software services to enterprises of different sizes via the Internet. In the SaaS model, service providers are responsible for the development, deployment, maintenance, and upgrades of the software, while users (tenants) use it on demand through subscriptions, without having to bear the high upfront costs and ongoing maintenance burdens required for traditional software deployment. In the field of travel services, SaaS travel systems, as a typical application scenario, support multi-tenant architecture, that is, a single system instance can serve multiple independent tenants (such as travel service providers, regional operators, etc.) at the same time. Each tenant can independently configure according to their own business needs (such as city coverage, service categories, pricing strategies, etc.) to achieve personalized service delivery.

[0003] For the quality assurance team of the SaaS travel system, ensuring the integrity and effectiveness of tenant city configurations is fundamental to ensuring the stable operation of the system. Specifically, they must assess whether the tenant has completed all necessary configuration items (such as city availability, service category definition, and operating rules) in accordance with business requirements; whether the tenant configuration complies with system logical constraints (such as price range rationality and service time conflict detection) and business rules (such as policy compliance and category relevance); and whether the system can correctly provide the expected functions (such as order matching, route planning, and fee calculation) based on the tenant configuration.

[0004] As the scale of tenants expands (e.g., covering hundreds of cities, hundreds of thousands of drivers and users), the traditional manual verification of city configurations has been replaced by automated inspection technology for tenant check-in links in SaaS travel systems. This technology aims to rapidly verify tenant city configurations through automation, improving labor efficiency and reducing verification costs. However, current technical practices have the following technical issues:

[0005] (1) The contradiction between personalized configuration and standardized verification: Traditional To C travel platforms are user-centric and lack support for complex configuration scenarios of SaaS tenants. When a new tenant joins, a set of automated city configuration check scripts must be redeveloped on the platform and customized for the tenant's personalized configuration. This method results in some common configurations between different tenants (such as basic category rules), but the verification logic needs to be rewritten. Moreover, when the categories opened in a city change, the check scripts of all tenants need to be modified synchronously, which lacks reusability.

[0006] (2) Insufficient dynamism and scalability of verification logic: Dynamic changes in travel service categories (such as express, private cars, and ride-sharing, etc.) (such as the launch of new categories and adjustments to category rules) require verification logic to be highly scalable. However, traditional scripted verification methods strongly bind verification logic to specific category rules. Category changes require modification of verification scripts. There is a lack of unified abstraction and configurable expression of category rules, making verification logic difficult to reuse.

[0007] (3) Multi-tenant verification efficiency and consistency: In a multi-tenant scenario, city configuration verification must be supported for hundreds of tenants simultaneously, and traditional serial verification methods are inefficient. In addition, configuration differences between different tenants (such as category combinations and pricing strategies) may complicate verification logic branches and affect the accuracy of verification results.

[0008] To this end, the present invention proposes a self-inspection method and system for the travel SaaS tenant entry link. Summary of the Invention

[0009] In view of this, the present invention aims to provide a self-inspection method and system for the onboarding link of travel SaaS tenants to solve or alleviate the technical problems existing in the prior art, namely, the contradiction between personalized configuration and standardized verification, the lack of dynamic and scalability of verification logic, and the efficiency and consistency of multi-tenant verification, and to provide at least a beneficial option for this purpose. The technical solution of the present invention is implemented as follows:

[0010] First, a self-inspection method and system for the onboarding link of travel SaaS tenants:

[0011] (1) Overview:

[0012] The present invention aims to solve the problem of tenant city configuration information management and automatic verification under the SaaS model. The core idea is to construct an ontology-based knowledge graph and reasoning rule system. First, through entity recognition and data extraction, the entity data related to the new tenant is obtained from the knowledge graph. Then, according to the predefined relationship type, the entity data is mapped to construct a triple structure to clearly express the relationship between the configuration items. The inference engine module then combines the rule set to perform logical reasoning on the triple data to generate a configuration item check set for the new tenant. During the configuration item detection execution phase, the knowledge graph is called to verify the integrity and validity of the configuration items, and a detection report is automatically generated for operators to review and focus on failed items. Finally, the new tenant configuration information and detection results are stored and updated in the knowledge graph module to provide data support for subsequent tenant access and configuration verification, thereby realizing automated and efficient management of tenant city configuration information.

[0013] (2) Technical solution:

[0014] When the user enters the new tenant access instruction and related basic configuration information (such as tenant name, region, basic business requirements, etc.) through the system interface, the system activates the entire tenant city configuration information management and automatic verification process after receiving the instruction.

[0015] 2.1 Step S1, entity recognition and data extraction:

[0016] Based on the input tenant basic information, entity data that may be related to the tenant is identified and extracted from the knowledge graph module, including predefined entity templates such as transportation company settlement rules, pricing configuration items, and driver and vehicle binding inspection items.

[0017] 2.1.1 Step S100, input data preprocessing:

[0018] Check whether the entered tenant basic information (such as tenant ID, name, industry attributes, etc.) conforms to the predefined format, and mark or complete missing fields (such as matching industry classification by tenant name).

[0019] Based on the basic information of tenants, tenant portrait labels (such as "logistics industry", "city distribution", "long-distance freight") are generated for subsequent entity matching priority sorting.

[0020] 2.1.2 Step S101, Knowledge Graph Entity Template Matching

[0021] Load the following entity templates from the knowledge graph module:

[0022] 1) Shipping company settlement rules: including fee calculation method (such as mileage / weight), settlement cycle and abnormal fee handling rules.

[0023] 2) Pricing configuration items: including basic freight rates, tiered pricing rules, and nighttime / peak hour surcharge strategies.

[0024] 3) Driver and vehicle binding inspection items: including driver qualification requirements (such as driver's license type, years of experience) and vehicle compliance inspection (such as vehicle type, annual inspection status).

[0025] 2.1.3 Step S102: Dynamically adjust entity matching rules based on tenant profile tags:

[0026] If the tenant belongs to the "Logistics Industry", priority will be given to matching entities with "Vehicle Binding Inspection Items";

[0027] If the tenant is involved in "long-distance freight", the cross-regional fee rules in the "Transportation Company Settlement Rules" will be matched first.

[0028] 2.1.4 Step S103, entity data extraction:

[0029] Extract entity data matching the tenant from the knowledge graph and form a structured output (such as JSON format).

[0030] 2.2 Step S2, relationship mapping and triple construction:

[0031] According to predefined relationship types, including containment relationship, value relationship, dependency relationship and configuration relationship, the extracted entity data is mapped to construct a triple structure.

[0032] For example, "Tenant A" and "Provincial Transport Company Settlement Rules" are connected through the "include" relationship to form a triple of "Tenant A-include-Provincial Transport Company Settlement Rules".

[0033] 2.2.1 Step S200: Define parsing rules for each relationship type based on the entity template and business rules:

[0034] Containment relationship: automatically identified through entity hierarchical structure (such as JSON nesting);

[0035] Value relationship: matching entity attributes with predefined fields (e.g., "base_price" corresponds to "base freight rate");

[0036] Dependency: inferred based on business logic (e.g., "Vehicle Binding Check Item" depends on "Driver Qualification" and "Vehicle Compliance" entities);

[0037] Configuration relationship: establish an association through a configuration item identifier (such as "pricing configuration item ID");

[0038] 2.2.2 Step S201: Entity Data Mapping:

[0039] The settlement rules of the transport company are mapped to an inclusion relationship (e.g., including the "Fee Calculation Method" sub-entity);

[0040] Pricing configuration items are mapped to value relationships (such as the "basic freight rate" attribute value);

[0041] The driver and vehicle binding check items are mapped as dependencies (depending on "driver qualifications" and "vehicle compliance");

[0042] 2.2.3 Step S202: Dynamically adjust mapping rules based on tenant profiles:

[0043] If the tenant belongs to "city distribution", the "regional price increase" value relationship will be added to the "pricing configuration item";

[0044] If the tenant is involved in "long-distance freight", the "transportation company settlement rules" will be added with the inclusion of "cross-regional costs";

[0045] 2.2.3 Step S202, triple construction

[0046] The standard triple format (subject-verb-object) is used to represent the relationship: (entity 1, relationship type, entity 2 / attribute value); example:

[0047] (Transportation company settlement rules, including relationships and fee calculation methods);

[0048] (pricing configuration item, value relationship, basic freight rate: 50);

[0049] (driver and vehicle binding check items, dependencies, driver qualifications);

[0050] Automatically generate triples based on mapping rules:

[0051] Containment relationship: recursively parse the entity nested structure and generate nested triples;

[0052] Value relationship: directly extract entity attribute values and generate key-value pair triples;

[0053] Dependency: Generate multi-entity association triples based on business logic inference;

[0054] Configuration relationship: Generate configuration triples through configuration item identifiers.

[0055] 2.3 Step S3, Application of Inference Rules and Generation of Configuration Check Sets:

[0056] The inference engine module receives the constructed triple data, combines the inference rules in the rule set module (including single-city configuration check set rules and tenant-level configuration dependency rules), performs logical reasoning, and generates a configuration item check set for the new tenant.

[0057] 2.3.1 Step S300: Load the following two types of inference rules from the rule set module:

[0058] Single-city configuration check set rules: Configuration check items defined based on city characteristics (such as traffic regulations and road restrictions) (e.g., "vehicles must meet China V emission standards");

[0059] Tenant-level configuration dependency rules: Configuration dependencies defined based on tenant business scenarios (such as industry attributes and service scope) (e.g., "Logistics industry tenants must configure the 'cross-region fee' rule");

[0060] 2.3.2 Step S301: Parse the rule set into a logical expression executable by the inference engine:

[0061] Converted into conditional judgments based on city attributes (for example, if city == "Beijing" then inspection item = "National V Emission Standard"); tenant-level rules converted into dependencies based on tenant profiles (for example, if tenant industry == "Logistics" then dependency item = "Cross-regional Expenses").

[0062] 2.3.3 Step S302: Triple Data Preprocessing

[0063] Convert the triple into a key-value pair (e.g., {"entity":"shipping company settlement rules","relationship":"inclusion relationship","target":"cost calculation method"}); extract the attribute value in the value relationship (e.g., {"basic freight rate":50});

[0064] 2.3.4 Step S303, Single City Configuration Check Set Reasoning:

[0065] Based on the tenant's city, apply single-city rules to generate configuration check items:

[0066] City attribute matching: extract city information from triples (e.g. {"city":"Shanghai"});

[0067] Rule matching: Find matching city rules (e.g. "Shanghai" corresponds to "National VI Emission Standard");

[0068] Inspection item generation: Generate inspection item triples (such as (configuration inspection set, inclusion relationship, National VI emission standard)).

[0069] 2.3.5 Step S304: Tenant-level configuration dependency reasoning:

[0070] Based on the tenant profile, tenant-level rules are applied to generate configuration dependencies:

[0071] Tenant profile matching: extract tenant industry attributes from triples (e.g., {"industry":"logistics"});

[0072] Rule matching: Find matching tenant-level rules (e.g., "logistics industry" depends on "cross-region fees");

[0073] Dependency generation: Generates dependency triples (such as (pricing configuration item, dependency, cross-regional cost)).

[0074] 2.3.6 Step S305, configuration check set construction:

[0075] Combine the inference-generated check items and dependencies into a configuration check set:

[0076] Inspection item classification: Classified by inspection type (such as "Compliance Check" and "Dependency Check").

[0077] Prioritization of check items: Sort by business importance (e.g., "compliance check" takes precedence over "dependency check").

[0078] 2.4 Step S4, configuration item detection execution:

[0079] The test calls the knowledge graph module to verify the integrity and validity of the configuration items. A test report is automatically generated, listing the test results of each configuration item, including both successful and failed items.

[0080] Operations personnel can view the inspection report through the system interface, focusing on items that failed the inspection for subsequent processing.

[0081] 2.4.1 Step S400, calling the knowledge graph module:

[0082] Load tenant-related configuration item data from a knowledge graph database (such as Neo4j or RDF storage), including:

[0083] Configuration item entities: such as "basic freight rate" and "cross-region fee rules";

[0084] Configuration item attributes: such as "value", "effective time", and "dependency";

[0085] Configuration item relationships: such as "inclusion relationship", "dependency relationship", and "configuration relationship";

[0086] Load configuration item detection rules from the rule set module, including:

[0087] Integrity rules: Check whether configuration items are missing (e.g., "all tenants must configure a basic freight rate");

[0088] Validity rules: Check whether the value of the configuration item complies with business logic (such as "the base freight rate must be a positive number");

[0089] Dependency rules: Check whether the dependency relationships of configuration items are met (for example, "Cross-region fee rules" depend on "Basic freight rates" being configured);

[0090] 2.4.2 Step S401: traverse the configuration item entities in the knowledge graph to check whether there are any missing items:

[0091] Mandatory item check: Determine which configuration items are mandatory based on the rule set, and mark them as "failed" if they are missing;

[0092] Dynamic mandatory field check: Dynamically adjust mandatory fields based on tenant profiles (e.g., "logistics industry tenants" must configure "cross-region fee rules");

[0093] Record missing configuration items in the test report, including:

[0094] Configuration item name, missing reason (e.g., "Required item missing"), and recommended action (e.g., "Please configure basic freight rate");

[0095] 2.4.3 Step S402: Verify whether the value of the configuration item complies with the business logic:

[0096] Value range check: "Basic Freight Rate" must be greater than 0.

[0097] Format check: The "Effective Time" must conform to the date format.

[0098] Enumeration value check: "Charge unit" must be "km" or "ton".

[0099] 2.4.4 Step S403, dependency validity check:

[0100] Pre-dependency check: For example, "cross-region fee rules" must depend on the "basic freight rate" being configured;

[0101] Circular dependency check: Ensure that there are no circular dependencies between configuration items;

[0102] 2.4.5 Step S404: Record the invalid configuration items in the test report, including:

[0103] Configuration item name, invalid reason (e.g., "Base freight rate is negative"), and recommended action (e.g., "Please correct the base freight rate to a positive number");

[0104] Generate a structured test report, including:

[0105] Detection overview: detection time, tenant information, and detection rule version.

[0106] Test results include:

[0107] Successful Items: Lists all configuration items that have passed the test.

[0108] Failed Items: Lists all configuration items that failed the test, including missing items and invalid items.

[0109] Statistics: number of successful items, number of failed items, and detection pass rate.

[0110] 2.5 Step S5, configuration information storage and update:

[0111] The configuration information of the new tenant and its detection results are stored in the knowledge graph module, and the tenant set data is updated to provide data support for subsequent tenant access and configuration verification.

[0112] (3) Mechanisms for resolving technical issues:

[0113] 3.1 Mechanism and principle for resolving the contradiction between personalized configuration and standardized verification:

[0114] An ontology-based knowledge graph was constructed, abstracting tenant city configuration information into entities and relationships. This provides the foundation for flexible expression of personalized configurations and standardized verification. Entities such as transportation company settlement rules and pricing configuration items, as well as standardized relationships such as include and value relationships, were defined to ensure the expression of personalized configurations within a standardized framework. Based on tenant-specific configuration information, inference rules were used to dynamically generate configuration check sets that meet their business needs, effectively integrating personalized configuration with standardized verification.

[0115] 3.2 Solution mechanism and principle for insufficient dynamic and scalability of verification logic:

[0116] The solution incorporates a rule set module to store and manage inference rules, enabling dynamic updates and expansion of verification logic. The inference engine module performs logical inference based on input tenant configuration information and rule sets, generating configuration check sets and ensuring the dynamic and flexible nature of verification logic.

[0117] 3.3 Multi-tenant verification efficiency and consistency solution mechanism and principle:

[0118] The knowledge graph module stores configuration information for all tenants, enabling centralized management and sharing of configuration information and improving verification efficiency. All tenants use the same inference rules for configuration checks, ensuring consistent verification results. The system automatically performs configuration item checks and generates test reports, reducing manual intervention and improving verification efficiency.

[0119] Secondly, the self-inspection system for the onboarding link of travel SaaS tenants:

[0120] The system is used to implement the self-inspection method for the travel SaaS tenant onboarding link described above, which includes:

[0121] (1) Data layer, including:

[0122] A knowledge graph module that stores tenant configuration information, rule sets, and inference rules, and supports CRUD operations and graph queries;

[0123] A rule set module that manages validation rules and supports addition, deletion, modification, and version control of rules;

[0124] (2) Logical layer, including:

[0125] An inference engine module that performs logical reasoning based on tenant configuration and rule sets to generate configuration check sets;

[0126] A configuration item check module that executes specific configuration item verification logic and returns a success or failure result;

[0127] (3) Application layer:

[0128] Provides an interface for adding, deleting, modifying, and checking tenant configurations, and a tenant management module that supports visual interface operations;

[0129] Generate and display configuration verification results, and support verification report module that exports reports;

[0130] A monitoring and alarm module that monitors tenant configuration status in real time and triggers alarms when anomalies occur.

[0131] Compared with the prior art, the present invention has the following beneficial effects:

[0132] 1. Unification of personalized configuration and standardized verification: Tenant needs vary greatly, and traditional solutions find it difficult to find a balance between personalized configuration and standardized verification, resulting in high customization costs and confusing verification logic. The present invention abstracts tenant configurations into entities (such as "pricing rules" and "driver binding rules") and relationships (such as "inclusion" and "dependency") to achieve standardized expression. Verification rules are automatically generated based on tenant configurations. For example, if tenant A needs to "price by mileage", the system automatically associates the "mileage pricing rules" for verification without the need for hard coding.

[0133] 2. Dynamic and scalable verification logic: When business rules change frequently, traditional solutions require code modifications and have poor scalability. This invention splits the verification logic into independent rules (such as "driver binding check" and "vehicle compliance check"), which can be updated independently. When adding new rules, you only need to add new rules to the rule set, and the inference engine will automatically adapt. The response time for business rule updates is shortened from "days" to "minutes", supporting rapid iteration.

[0134] Multi-tenant Verification Efficiency and Consistency: Traditional solutions in multi-tenant environments repeatedly execute verification logic, resulting in low efficiency and inconsistent results. This solution, through knowledge graph sharing, stores all tenant configurations in a unified knowledge graph, avoiding duplicate queries. All tenants use the same set of inference rules, ensuring consistent verification results. The system automatically performs verification and generates reports, reducing manual intervention. BRIEF DESCRIPTION OF THE DRAWINGS

[0135] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0136] Figure 1 Schematic diagram of the method flow of the present invention;

[0137] Figure 2 It is a schematic diagram of the system block diagram of the present invention;

[0138] Figure 3 This is a schematic diagram of the knowledge graph module of the present invention;

[0139] Figure 4 It is a configuration diagram of the present invention;

[0140] Figure 5 Schematic diagram of the inference engine module of the present invention. DETAILED DESCRIPTION

[0141] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0142] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0143] Explanation of relevant terms:

[0144] (1) Basic tenant information: Basic information of the newly added tenant, such as name, region, business requirements, etc.

[0145] (2) Shipping company settlement rules: the rules and standards used by shipping companies for fee settlement.

[0146] (3) Pricing configuration items: configuration parameters and settings related to price calculation.

[0147] (4) Driver and vehicle binding check item: a check condition used to verify whether the driver and vehicle are correctly bound.

[0148] (5) Containment relationship: It indicates that one entity contains another entity.

[0149] (6) Value relationship: represents the value correspondence between entities.

[0150] (7) Dependency: A relationship in which one entity depends on another entity.

[0151] (8) Configuration relationship: represents the configuration association relationship between entities.

[0152] (9) Inference rules: rules used to derive new conclusions based on known information.

[0153] (10) Logical reasoning: the process of logical judgment and deduction based on the rules of reasoning.

[0154] (11) Configuration item check set: a set of verification items for tenant configuration items.

[0155] (12) Successful items: Items that pass verification in the configuration item check.

[0156] (13) Failed item: An item that fails verification during configuration item checking.

[0157] (14) Inclusion relationship (Has-A): Indicates the composition structure between entities (e.g. “Transportation company settlement rules” includes “cost calculation method”).

[0158] (15) Value-Of: represents the attribute value of an entity (e.g. the “basic freight rate” of the “pricing configuration item” is 50).

[0159] (16) Dependencies: Depends-On: Indicates the logical dependencies between entities (e.g., “driver and vehicle binding check item” depends on “driver qualification” and “vehicle compliance”).

[0160] (17) Configured-By relationship: indicates that the entity is generated by a specific configuration item (e.g., “tiered pricing rules” are generated by “pricing configuration items”).

[0161] Example 1: Figure 1 As shown, this embodiment discloses an example of using the self-inspection method for the travel SaaS tenant entry link in an online car-hailing operation and maintenance platform.

[0162] A SaaS system for an online ride-hailing platform provides customized travel services to multiple tenants (such as logistics companies and travel service providers). To ensure configuration compliance after tenants move in, a self-inspection method is used to automatically verify tenant configurations.

[0163] In this embodiment, regarding step S1: entity identification and data extraction:

[0164] Specifically, step S100: input data preprocessing:

[0165] Input: basic tenant information (such as tenant ID, name, industry attributes, etc.).

[0166] Format check: Validates the tenant ID format (e.g., UUID) and flags missing fields.

[0167] Industry classification completion: Match industry classification by tenant name (such as "XX Logistics" → "Logistics Industry").

[0168] Tenant portrait generation: add labels to tenants (such as "logistics industry" and "city distribution").

[0169] Output: Format tenant basic information and tenant portrait labels.

[0170] Specifically, step S101: knowledge graph entity template matching:

[0171] Knowledge graph entity template:

[0172] Shipping company settlement rules: cost calculation method (by mileage / weight), settlement cycle, and abnormal cost handling rules.

[0173] Pricing configuration items: basic freight rate, tiered pricing rules, and night / peak hour price increase strategies.

[0174] Driver and vehicle binding inspection items: driver qualification requirements (driver's license type, years of experience), vehicle compliance inspection (vehicle type, annual inspection status).

[0175] Action: Load the above template from the knowledge graph.

[0176] Specifically, step S102: Dynamically adjust entity matching rules: If the tenant belongs to the "logistics industry", prioritize matching the "vehicle binding inspection item". If the tenant involves "long-distance freight", prioritize matching the cross-regional fee rules in the "transportation company settlement rules".

[0177] Exemplary:

[0178] Tenant A (XX Logistics) → Prioritize matching of "Vehicle Binding Inspection Items".

[0179] Tenant B (XX Long-Distance Freight) → Prioritize matching the "Transportation Company Settlement Rules".

[0180] Step S103: Entity data extraction

[0181] Operation: Extract matching entity data from the knowledge graph and generate JSON format output.

[0182] Sample output:

[0183]

[0184] In this embodiment, regarding step S2: relationship mapping and triple construction:

[0185] Specifically, step S200: define relationship parsing rules:

[0186] Containment relationships: Automatically identified through entity hierarchical structures (such as JSON nesting).

[0187] Value relationship: matches entity attributes with predefined fields (such as "base_price" corresponds to "base freight rate").

[0188] Dependency: Inferred based on business logic (e.g., “Vehicle Binding Check Item” depends on “Driver Qualification” and “Vehicle Compliance”).

[0189] Configuration relationship: Establish an association through a configuration item identifier (such as "pricing configuration item ID").

[0190] Specifically, step S201: entity data mapping:

[0191] Transport company settlement rules → include relationship (including the "cost calculation method" sub-entity).

[0192] Pricing configuration item → value relationship (such as the "basic freight rate" attribute value).

[0193] Driver and vehicle binding check items → Dependency (depends on "Driver Qualification" and "Vehicle Compliance").

[0194] Specifically, step S202: dynamically adjust the mapping rules:

[0195] If the tenant belongs to "City Distribution", the "Regional Surcharge" value relationship will be added to the "Pricing Configuration Item".

[0196] If the tenant is involved in "long-distance freight", the "transportation company settlement rules" will add the "cross-regional costs" inclusion relationship.

[0197] Specifically, step S203: triple construction:

[0198] (Transportation company settlement rules, including relationships and fee calculation methods);

[0199] (pricing configuration item, value relationship, basic freight rate: 50);

[0200] (driver and vehicle binding check items, dependencies, driver qualifications);

[0201] In this embodiment, regarding step S3: application of inference rules and generation of configuration check set:

[0202] Specifically, step S300: loading inference rules:

[0203] Single-city configuration check set rules: Configuration check items (such as "vehicles must comply with the National V emission standards") defined based on city characteristics (such as traffic regulations and road restrictions).

[0204] Tenant-level configuration dependency rules: Configuration dependencies defined based on tenant business scenarios (such as industry attributes and service scope) (e.g., "Logistics industry tenants must configure the 'cross-region fee' rule").

[0205] Specifically, step S301: rule analysis:

[0206] Single-city rule: if city == "Beijing" then check item = "National V Emission Standard";

[0207] Tenant-level rule: if tenant industry == "Logistics" then dependency = "Cross-region Fees";

[0208] Specifically, step S302: triplet data preprocessing: converting the triplet into a key-value pair format, and extracting the attribute value in the value relationship.

[0209] Specifically, step S303: single city configuration check set reasoning:

[0210] Assume that the tenant's city is "Shanghai" → generate the inspection item "National VI Emission Standard".

[0211] Specifically, step S304: tenant-level configuration dependency reasoning:

[0212] The tenant industry is "Logistics" → the dependency "Cross-region Fees" is generated.

[0213] Specifically, step S305: configuration check set construction:

[0214]

[0215] In this embodiment, regarding step S4: configuration item detection execution

[0216] Specifically, step S400: knowledge graph module call: loading configuration item data and detection rules from the knowledge graph.

[0217] Specifically, step S401: Integrity Verification: If the tenant has not configured "Basic Freight Rate" → mark as "Failed". If the tenant in the logistics industry has not configured "Cross-Region Fee Rules" → mark as "Failed".

[0218] Specifically, step S402: validity verification:

[0219] Value range check: "Basic Freight Rate" is a negative number → mark as "Failed".

[0220] Format check: The format of "Effective Time" is incorrect → Mark as "Failed".

[0221] Specifically, step S403: dependency validity check:

[0222] "Cross-region fee rules" depend on "base freight rate" not being configured → marked as "failed".

[0223] Specifically, step S404: generating a test report:

[0224]

[0225]

[0226] In this embodiment, regarding step S5: configuration information storage and update, the configuration information and detection results of the new tenant are stored in the knowledge graph, and the tenant set data is updated.

[0227] In this example, the entities and relationships in the knowledge graph provide a standardized representation for personalized configurations, enabling configuration information from different tenants to be managed and verified within the same framework. Inference rules dynamically derive the required configuration checks based on the tenant's specific configuration information, ensuring targeted and effective verification.

[0228] For example, consider two tenants, A and B. A requires specific pricing rules, while B requires a different set of rules. Using the knowledge graph, we can define these two sets of rules as entities and associate them with tenants A and B through relationships. Inference rules dynamically generate corresponding configuration check sets based on the tenants' specific needs, unifying personalized configuration with standardized verification.

[0229] In this embodiment, validation logic is no longer hard-coded into the system; instead, it is defined and managed through rule sets. As business requirements change, the validation logic can be dynamically adjusted simply by updating the rule set. The independent design of the rule set module and the inference engine module allows for easy addition of new validation rules and logic, improving system scalability.

[0230] For example, suppose a business requirement changes and a new configuration check item needs to be added. In this case, we simply add the corresponding inference rule to the rule set, and the inference engine module can generate a configuration check set containing the new check item based on the new rule, realizing the dynamic update and expansion of the verification logic.

[0231] In this embodiment, centralized knowledge graph management enables the system to quickly access and retrieve tenant configuration information, reducing data search and comparison time during the verification process. Unified inference rules ensure that all tenants perform configuration checks under the same verification standards, avoiding inconsistent verification results due to rule differences. Automated detection and reporting processes reduce manual operation time and error rates, improving verification efficiency and accuracy.

[0232] For example, if multiple tenants access the system simultaneously, the system quickly retrieves each tenant's configuration information through the knowledge graph and performs configuration checks using unified inference rules. After the check is complete, the system automatically generates a report, allowing operators to easily review the verification results for each tenant, achieving efficient and consistent multi-tenant verification.

[0233] Example 2: Figures 2 to 5 As shown, this embodiment further provides a self-inspection system for the onboarding link of travel SaaS tenants based on the first embodiment:

[0234] The system is used to implement the self-inspection method for the travel SaaS tenant onboarding link described above, which includes:

[0235] (1) Data layer, including:

[0236] A knowledge graph module that stores tenant configuration information, rule sets, and inference rules, and supports CRUD operations and graph queries;

[0237] A rule set module that manages validation rules and supports addition, deletion, modification, and version control of rules;

[0238] (2) Logical layer, including:

[0239] An inference engine module that performs logical reasoning based on tenant configuration and rule sets to generate configuration check sets;

[0240] A configuration item check module that executes specific configuration item verification logic and returns a success or failure result;

[0241] (3) Application layer:

[0242] Provides an interface for adding, deleting, modifying, and checking tenant configurations, and a tenant management module that supports visual interface operations;

[0243] Generate and display configuration verification results, and support verification report module that exports reports;

[0244] A monitoring and alarm module that monitors tenant configuration status in real time and triggers alarms when anomalies occur.

[0245] (4) How to use the system:

[0246] P1. The inference engine obtains tenant configuration information from the knowledge graph through a graph query interface (such as Cypher query language).

[0247] Example: Query the pricing rule association relationship of tenant A.

[0248] P2, the inference engine loads the rule set through the rule engine interface and performs logical reasoning.

[0249] Example: Load the "Driver Binding Check" rule to verify the binding relationship between the driver and the vehicle.

[0250] P3,the inference engine passes the generated configuration check set to the,verification report module to generate a visual report.

[0251] Example: Displays the pricing rule verification results for tenant A.

[0252] P4. The configuration item check module feeds back the verification results to the monitoring and alarm module in real time, triggering an alarm.

[0253] Example: When the compliance check of tenant B's vehicle fails, an alarm notification is triggered.

[0254] P5. The tenant management module writes tenant configuration information into the knowledge graph through the data synchronization interface.

[0255] Example: When adding tenant C, synchronize its configuration information to the knowledge graph.

[0256] P6. The verification report module provides a report download link, and the tenant management module obtains the report through the report interface.

[0257] Example: Tenant D downloads its pricing rule verification report.

[0258] (5) Data flow:

[0259] Tenant configuration data: Tenant management module → Knowledge graph module → Inference engine module → Configuration item check module → Verification report module.

[0260] Rule data: rule set module → inference engine module → configuration item check module.

[0261] (6) Control flow:

[0262] Verification process: The tenant management module triggers the verification request → the inference engine module loads the rule set and tenant configuration → performs logical reasoning → the configuration item check module performs verification → the verification report module generates a report.

[0263] Alarm process: The configuration item inspection module detects an anomaly → the monitoring alarm module triggers an alarm → the tenant management module is notified.

[0264] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0265] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0266] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A self-inspection method for the onboarding link of travel SaaS tenants, characterized in that: The following steps are included: S1, based on the input tenant basic information, identify and extract entity data that may be related to the tenant from the knowledge graph module; S2, maps the extracted entity data according to the predefined relationship types; S3, the inference engine module receives the constructed triple data and performs logical reasoning based on the inference rules in the rule set module; S4, the detection calls the knowledge graph module to verify the integrity and validity of the configuration items; automatically generates a test report, listing the test results of each configuration item, including successful items and failed items.

2. The self-inspection method according to claim 1, characterized in that: In S1, the entity data includes the transportation company's settlement rules, pricing configuration items, and driver and vehicle binding check items.

3. The self-inspection method according to claim 2, wherein: In said S1, it includes: S100: Check whether the input tenant basic information conforms to the predefined format, mark or complete missing fields; generate tenant profile tags based on the tenant basic information; S101, load the following entity template from the knowledge graph module: Shipping company settlement rules: including fee calculation method, settlement cycle and abnormal fee handling rules; Pricing configuration items: including basic freight rates, tiered pricing rules, and nighttime / peak hour price increase strategies; Driver and vehicle binding inspection items: including driver qualification requirements and vehicle compliance inspection; S102: If the tenant belongs to the logistics industry, priority is given to matching entities with inspection items bound to the vehicle; if the tenant belongs to long-distance freight, priority is given to matching cross-regional fee rules in the transportation company's settlement rules; S103, extract entity data matching the tenant from the knowledge graph to form a structured output.

4. The self-inspection method according to claim 1, wherein: In S2, the relationship types include inclusion relationship, value relationship, dependency relationship and configuration relationship.

5. The self-inspection method according to claim 4, characterized in that: In said S2, it includes: S200: Define parsing rules for each relationship type based on the entity template and business rules: Containment relationship: automatically identified through entity hierarchy; Value relationship: matching entity attributes with predefined fields; Dependency: inferred based on business logic; Configuration relationship: establish association through configuration item identifier; S201: The settlement rules of the transport company are mapped as inclusion relationships; the pricing configuration items are mapped as value relationships; and the driver and vehicle binding check items are mapped as dependency relationships. In step S202, if the tenant is a "city delivery" tenant, the "regional markup" value relationship is added to the "pricing configuration item"; if the tenant is a "long-distance freight" tenant, the "cross-region fee" inclusion relationship is added to the "transportation company settlement rules"; S202, using the standard triple format, automatically generates triples according to the mapping rules: Containment relationship: recursively parse the entity nested structure and generate nested triples; Value relationship: directly extract entity attribute values and generate key-value pair triples; Dependency: Generate multi-entity association triples based on business logic inference; Configuration relationship: Generate configuration triples through configuration item identifiers.

6. The self-inspection method according to claim 1, wherein: Said S3 includes: S300, loading single-city configuration check set rules and tenant-level configuration dependency rules from the rule set module; S301: Convert to conditional judgment based on city attributes; convert tenant-level rules to dependencies based on tenant profiles; S302, converting the triple into a key-value pair format; extracting the attribute value in the value relationship; S303: Based on the tenant's city, apply the single-city rule to generate configuration check items: City attribute matching: extract city information from triples; Rule matching: Find matching city rules; Check item generation: Generate check item triples; S304: Based on the tenant profile, apply tenant-level rules to generate configuration dependencies: Tenant profile matching: extract tenant industry attributes from triples; Rule matching: Find matching tenant-level rules; Dependency generation: Generate dependency triples; S305: Integrate the check items and dependencies generated by reasoning into a configuration check set: Inspection item classification: classified by inspection type; Prioritization of inspection items: Sort by business importance.

7. The self-inspection method according to claim 1, characterized in that: In said S4, it includes: S400, loading tenant-related configuration item data from the knowledge graph database; S401, traverse the configuration item entities in the knowledge graph to check whether there are any missing items; S402, configuration item validity verification verifies whether the value of the configuration item conforms to the business logic; Generate structured inspection reports.

8. The self-inspection method according to claim 1, wherein: It also includes S5, configuration information storage and update: storing the new tenant's configuration information and its detection results in the knowledge graph module and updating the tenant set data.

9. A system for implementing the self-inspection method according to any one of claims 1 to 8, characterized in that: The system comprises: The data layer includes: A knowledge graph module that stores tenant configuration information, rule sets, and inference rules, and supports CRUD operations and graph queries; A rule set module that manages validation rules and supports addition, deletion, modification, and version control of rules; The logic layer includes: An inference engine module that performs logical reasoning based on tenant configuration and rule sets to generate configuration check sets; A configuration item check module that executes specific configuration item verification logic and returns a success or failure result; Application layer: Provides an interface for adding, deleting, modifying, and checking tenant configurations, and a tenant management module that supports visual interface operations; Generate and display configuration verification results, and support verification report module that exports reports; A monitoring and alarm module that monitors tenant configuration status in real time and triggers alarms when anomalies occur.

10. The system according to claim 9, characterized in that: The execution process of the system includes: P1, the inference engine obtains tenant configuration information from the knowledge graph through the graph query interface; P2, the inference engine loads the rule set through the rule engine interface and performs logical reasoning; P3,the inference engine passes the generated configuration check set to the verification,report module to generate a visual report; P4. The configuration item check module feeds back the verification results to the monitoring and alarm module in real time, triggering an alarm. P5. The tenant management module writes tenant configuration information into the knowledge graph through the data synchronization interface; P6. The verification report module provides a report download link, and the tenant management module obtains the report through the report interface.

Images