A Visual Editing Method and Apparatus Based on LDAP Schema Specification

Abstract

This application discloses a visual editing method and apparatus based on LDAP schema specifications, relating to the field of visual editing technology. It defines and modifies attribute value constraint rules in the LDAP schema specification within a graphical interface, generating an enhanced schema file. Based on the data information in the enhanced schema file, a general schema file is generated. The enhanced schema file is used to perform static and dynamic validation on user-provided business data. Upon successful validation, the LDAP data editing interface is invoked, and an internal mechanism calls the general schema specification reflected in the general schema file to validate the business data again. Upon successful second validation, the business data is stored in the LDAP server. This solves the problem that traditional LDAP schemas can only define static constraints, failing to meet the constraint specifications required by users in their business scenarios.

Description

Technical Field

[0001] This application relates to the field of visual editing technology, and in particular to a visual editing method and apparatus based on the LDAP schema specification. Background Technology

[0002] LDAP (Lightweight Directory Access Protocol) is a standard protocol for accessing and managing distributed directory information, widely used in authentication, user management, and other fields. The LDAP schema specification defines the attribute value constraints rules for entries in the directory.

[0003] Traditional LDAP schema specifications cannot support complex constraints, such as regular expression constraints on usernames. As a general-purpose directory access tool, LDAP cannot meet the specific business-specific constraints required by users, often necessitating separate schema validation settings outside the LDAP system. The general nature of LDAP limits the constraint capabilities of LDAP editing tools, and corresponding visual editing tools do not consider the specific business-specific constraints of users.

[0004] Therefore, the traditional LDAP schema can only define static constraints, which cannot meet the constraint specifications of users in business scenarios. Summary of the Invention

[0005] In this embodiment of the application, a visual editing method based on the LDAP schema specification is provided, which solves the problem that the traditional LDAP schema can only define static constraints and cannot meet the constraint specifications of users in business scenarios.

[0006] In a first aspect, embodiments of this application provide a visual editing method based on LDAP schema specifications. This method includes: defining and modifying attribute value constraint rules in the LDAP schema specifications within a graphical interface to generate an enhanced schema file; generating a general schema file based on the data information in the enhanced schema file; wherein the enhanced schema file is stored in the business service, and the general schema file is stored in the LDAP system; performing static and dynamic validation on user-provided business data using the enhanced schema file; upon successful validation, calling the LDAP data editing interface and using an internal mechanism to call the general schema specifications reflected in the general schema file to validate the business data again; if validation fails, returning the error reason based on the error message configured in the enhanced schema file; and storing the business data in the LDAP server after successful validation again.

[0007] In one possible implementation, defining and modifying attribute value constraint rules in the LDAP schema specification within the graphical interface to generate an enhanced schema file includes: configuring the UI-Schema based on user-defined JSON Schema data, mapping attributes in the JSON Schema data to corresponding elements in the graphical interface to define and modify attribute value constraint rules in the LDAP schema specification within the graphical interface; integrating a JSON Schema Editor tool to generate an enhanced schema file based on user-defined JSON Schema data and UI-Schema information; extracting data from the enhanced schema file, converting the extracted data into ldif file data related to the LDAP system, thus realizing the conversion from the visual definition in the graphical interface to the actual storage format of the LDAP system.

[0008] In one possible implementation, generating a generic schema file based on the data information in the enhanced schema file includes: parsing the enhanced schema file stored in the business service to identify content in the enhanced schema file that conforms to the LDAP standard; wherein, the content conforming to the LDAP standard includes data structure and basic constraint rule information; removing validation rules for extended data in the enhanced schema file, including regular expression validation rules, dynamic data format validation rules, and custom validation method configurations; organizing the content in the enhanced schema file that conforms to the LDAP standard according to the data structure requirements of the LDAP system, determining the specific structure of the generic schema file according to the format and specifications required by the LDAP system, and generating the generic schema file; and transmitting the generated generic schema file to the LDAP system through a preset transmission protocol to complete the storage operation.

[0009] In one possible implementation, static validation involves extracting information from the business data, including field types, constraint rules, and custom validation configurations; based on the information in the business data, a JSON Schema validation tool is used to perform field-by-field validation on the business data, including type checking, length checking, and regular expression validation.

[0010] In one possible implementation, dynamic validation includes extracting configuration information for dynamic validation from the enhanced schema file; parsing the extracted configuration information to obtain the call path; wherein the call path includes the service name responsible for validation; locating the corresponding service instance in the backend service environment based on the parsed service name; taking the business data to be validated and the field information to be validated as parameters, initiating a call through the service call mechanism, passing the parameters to the service instance, and executing the dynamic validation logic.

[0011] One possible implementation also includes: defining an HTTP interface specification to add commands for validating LDAP entry formats and providing an API interface; defining a standard plug-in interface specification to provide a plug-in mechanism to support the integration of third-party tools with the LDAP system.

[0012] Secondly, embodiments of this application provide a visual editing device based on the LDAP schema specification. The device includes: a definition module for defining and modifying attribute value constraint rules in the LDAP schema specification within a graphical interface, generating an enhanced schema file; a generation module for generating a generic schema file based on data information in the enhanced schema file; wherein the enhanced schema file is stored in the business service, and the generic schema file is stored in the LDAP system; a verification module for performing static and dynamic verification on user-provided business data using the enhanced schema file; upon successful verification, calling the LDAP data editing interface and using an internal mechanism to call the generic schema specification reflected in the generic schema file to verify the business data again; if verification fails, returning the error reason based on the error message configured in the enhanced schema file; and storing the business data in the LDAP server after successful verification again.

[0013] Thirdly, embodiments of this application provide a visual editing server based on the LDAP schema specification, including a memory and a processor; the memory is used to store computer-executable instructions; the processor is used to execute the computer-executable instructions to implement the method described in the first aspect or any possible implementation of the first aspect.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing executable instructions, which, when executed by a computer, enable the method described in the first aspect or any possible implementation thereof.

[0015] One or more technical solutions provided in this application embodiment have at least the following technical effects: This application embodiment provides a visual editing method based on LDAP schema specifications. This method defines and modifies attribute value constraint rules in the LDAP schema specifications in a graphical interface, generating an enhanced schema file. Business personnel do not need to master the underlying LDAP syntax and can complete complex constraint configurations through visual operations. Based on the data information in the enhanced schema file, a general schema file is generated; wherein, the enhanced schema file is stored in the business service, and the general schema file is stored in the LDAP system. The enhanced schema file is stored independently, and all businesses share a single general schema file, avoiding redundant configuration. The enhanced schema file performs static and dynamic validation on the business data provided by the user. After successful validation, the LDAP data editing interface is called, and the general schema specification reflected in the general schema file is called through an internal mechanism to validate the business data again. After successful validation again, the business data is stored in the LDAP server. This application uses a dual validation mechanism to intercept logical errors at the business layer and ensure protocol compliance at the LDAP layer, achieving high-reliability data writing and high-performance and stable system operation. It solves the problem that the traditional LDAP schema can only define static constraints and cannot meet the constraint specifications of users in business scenarios. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a visual editing method based on the LDAP schema specification provided in this application embodiment;

[0018] Figure 2 A schematic diagram of a visual editing device based on the LDAP schema specification provided in an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of a visual editing server based on the LDAP schema specification, provided as an embodiment of this application. Detailed Implementation

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

[0021] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0022] This application provides a visual editing method based on the LDAP schema specification, such as... Figure 1 As shown, the method includes steps S101 to S106. Wherein, Figure 1 This is merely one execution order shown in the embodiments of this application and does not represent the only execution order of a visual editing method based on the LDAP schema specification. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0023] S101: Define and modify attribute value constraint rules in the LDAP schema specification in a graphical interface to generate enhanced schema files.

[0024] Define and modify attribute value constraint rules in the LDAP schema specification in a graphical interface to generate an enhanced schema file, including the following:

[0025] Configure the UI-Schema based on user-defined JSON Schema data, mapping attributes in the JSON Schema data to corresponding elements in the graphical interface, so as to define and modify attribute value constraint rules in the LDAP schema specification in the graphical interface.

[0026] Specifically, UI-Schema is a technical specification for defining and describing the structure of a user interface. By mapping attributes in JSON Schema data to corresponding elements in a graphical interface, it allows users to intuitively define and modify attribute value constraints in the LDAP schema specification within the graphical interface. For example, a string type field defined in JSON Schema can be mapped to a text input box in the graphical interface by configuring UI-Schema, with the corresponding code being "ui:widget":"text". For enumeration type fields, they can be mapped to dropdown selection boxes, with the corresponding code being "ui:widget":"select".

[0027] It integrates a JSON Schema Editor tool to generate enhanced schema files based on user-defined JSON schema data and UI-Schema information. A schema file is a configuration file used to define data structures, constraints, and semantic specifications.

[0028] Specifically, a JSON Schema Editor is a tool for editing and validating JSON Schema data. By integrating this tool, users can directly edit JSON Schema data within a graphical interface and view and validate the editing results in real time. The JSON Schema Editor is embedded into the graphical interface as the primary tool for users to edit JSON Schema data. For example, it can be integrated using open-source JSON Schema Editor libraries such as React JSON Schema Form.

[0029] The editing process is as follows: The user opens the JSON Schema Editor tool in the graphical interface. Based on the UI-Schema configuration information, the tool generates corresponding form controls. The user enters or modifies attribute value constraint rules in the form controls, and the tool verifies the validity of the input data in real time. After editing, the user saves the JSON Schema data, and the tool generates an enhanced Schema file. The enhanced Schema file is stored in JSON format (a lightweight data interchange format).

[0030] Specifically, the enhanced schema file not only includes the basic attribute value constraint rules in the LDAP schema specification, but also extends to more complex constraints (such as regular expression validation, data format validation, etc.) to meet the specific business needs of users.

[0031] Data is extracted from the enhanced schema file and converted into ldif file data related to the LDAP system, realizing the conversion from the visual definition of the graphical interface to the actual storage format of the LDAP system.

[0032] Specifically, an ldif file is a file in ldif format, which is a text-based directory service data exchange format.

[0033] Furthermore, JSON parsing tools (such as Jackson, Gson, etc.) can be used to parse the enhanced schema file and extract the data that needs to be transformed.

[0034] S102: Generate a generic schema file based on the data information in the enhanced schema file. The enhanced schema file is stored in the business service, while the generic schema file is stored in the LDAP system.

[0035] Specifically, the core objective of S102 is to convert the enhanced schema files stored in business services into a generic schema file (LDIF format) that conforms to the requirements of the LDAP system, and then complete the transmission and storage. The enhanced schema files contain complex business constraint rules (such as regular expression validation, dynamic validation, etc.), while the generic schema files only retain the basic constraint rules of the LDAP standard, ensuring compatibility with the native LDAP schema.

[0036] Based on the data information in the enhanced schema file, a general schema file is generated, including the following content.

[0037] The enhanced schema file stored in the business service is parsed to identify content that conforms to the LDAP standard. This LDAP-compliant content includes data structure and basic constraint rule information.

[0038] Specifically, content conforming to the LDAP standard includes a data structure that can be of type objectClass and attribute field names such as cn and sn. Basic constraint rule information can be of type string and require fields.

[0039] Remove validation rules for augmented data in the enhanced schema file, including regular expression validation rules, dynamic data format validation rules, and custom validation method configurations.

[0040] Specifically, custom validation method configurations can include custom error messages.

[0041] The content of the enhanced schema file that conforms to the LDAP standard is organized according to the data structure requirements of the LDAP system. Based on the format and specifications required by the LDAP system, the specific structure of the general schema file is determined, and a general schema file is generated.

[0042] Specifically, the LDAP system requires the ldif format (a text-based directory service data exchange format). The specifications required by the LDAP system are as follows: Object class definition: Declare entry types using the objectClasses field. Attribute type definition: Define field constraints (such as syntax, single-value / multi-value) using the attributeTypes field. DN (Distinguished Name) generation: Construct the DN path based on fields such as partition, parentId, and id in the enhanced schema.

[0043] The generated generic schema file is transmitted to the LDAP system via a preset transmission protocol to complete the storage operation.

[0044] Specifically, a generic schema file can be uploaded to an LDAP server via LDAP protocols (such as the ldapadd command) or file transfer protocols (such as SFTP).

[0045] S103: Perform static and dynamic validation on user-provided business data through enhanced schema files.

[0046] S104: After successful verification, the LDAP data editing interface is called, and the business data is verified again by calling the general schema specification reflected in the general schema file through the internal mechanism.

[0047] S105: If the verification fails, return the reason for the error based on the error message configured in the enhanced Schema file.

[0048] S106: After successful verification, store the business data in the LDAP server.

[0049] The main fields of the general schema specification in this application are described below.

[0050] Field: partition, Data type: string, Field description: LDAP partition identifier, Type: Predefined immutable attribute.

[0051] Field: parent, Data type: string, Field description: DN of the parent of the current entry, Type: predefined immutable attribute.

[0052] Field: idKey, Data type: String, Field description: The unique identifier of the current entry, which together with the parent field forms the complete DN, Type: Predefined immutable attribute.

[0053] Field: id, Data type: string, Field description: Business primary key of the current entry, Type: Predefined attribute.

[0054] Field: objectClass, Data type: String array, Field description: Object class of LDAP entry, Type: Predefined immutable attribute.

[0055] It should be noted that if you need to add a new field, you can add it according to the above template and indicate whether it is a predefined field and its variability.

[0056] Static validation involves extracting information from business data, including field types, constraint rules, and custom validation configurations.

[0057] Based on the information in the business data, a JSON Schema validation tool is used to perform field-by-field validation on the business data, including type checking, length checking, and regular expression validation.

[0058] The following example, using the creation of a drone account, illustrates static validation. When an administrator submits drone account information (such as drone ID, name, model, etc.) in the business system, the system first triggers static validation to verify whether the data conforms to basic specifications before proceeding to the subsequent dynamic validation and data saving process.

[0059] The core of static validation is as follows: Extract information from the business data submitted by the administrator. Specifically, this could be: {"id":"D001","cn":"D001","displayName":"SkyRiderProX","dropeModel":"SRX-500"}. Use a JSON Schema validation tool to perform field-by-field validation on the business data. Verify that id is a string and that dropeModel (drone model field) is a string (or an enumerated value). Check if displayName (drone name field) exceeds the preset maximum length (e.g., no more than 50 characters). If the enhanced schema file defines regular expression rules for cn (here, the drone's unique identifier) ​​(e.g., only allowing alphanumeric characters and underscores), then verify if cn matches. Once static validation is successful, the dynamic validation process begins.

[0060] Dynamic validation involves extracting configuration information for dynamic validation from the enhanced schema file.

[0061] The extracted configuration information is parsed to obtain the call path. The call path includes the name of the service responsible for verification.

[0062] Based on the parsed service name, the corresponding service instance is located in the backend service environment.

[0063] The business data to be verified and the field information that needs to be verified are used as parameters. A call is initiated through the service call mechanism, and the parameters are passed to the service instance to execute the dynamic verification logic.

[0064] The following example, using drone account creation, illustrates static validation. Configuration information for dynamic validation is defined in a structured format (such as JSON or XML) in an extended field of the schema (e.g., `x-service-validator`). This field defines the rules for dynamic validation. The extracted configuration information, `x-service-validator`, is parsed to obtain the call path. Based on the `x-service-validator` field, the service's built-in RPC interface (a programming interface for calling service functions across a network or process) is retrieved. The RPC method is executed, making a dynamic call and returning the result. `x-service-validator` is an array type, allowing users to pass multiple validators. The system then performs a sequential validation; after each validator succeeds, a validation success message is returned.

[0065] Furthermore, after both static and dynamic validations succeed, the LDAP data editing interface is invoked. Through an internal mechanism, the general schema specification reflected in the common schema file is called to validate the business data again. The validation may include: whether required fields exist (e.g., cn, droneModel), and whether field values ​​conform to the format defined in the common schema file (e.g., droneModel must match a model regular expression). If validation fails, the error reason is returned based on the error message configured in the enhanced schema file.

[0066] Create an ldif file named drope.ldif with the following content.

[0067] "dn:cn=D001,ou=drone,dc=drop,dc=example,dc=com

[0068] objectClass:top

[0069] objectClass:organizationalUnit

[0070] objectClass:drope

[0071] cn:D001

[0072] displayName:SkyRider Pro X

[0073] droneModel:SRX-500.

[0074] Specifically, the dn field defines the full path of the entry in the LDAP directory (e.g., ou=drone indicates a drone organization unit). objectClass:drope indicates that it must be predefined in the generic schema file of the LDAP server.

[0075] Data is submitted via the OpenLDAP client command-line tool, and business data is stored in the LDAP server. Specifically: `ldapadd -xD"cn=admin,dc=drop,dc=example,dc=com" -w` <password>-f drone.ldif. Here, -x indicates using simple authentication. -D indicates binding to a Distinguished Name (DN), specifying the administrator account (e.g., cn=admin). -w <password>This is the administrator password. `-f drone.ldif` specifies the input file path.

[0076] This application also includes the following.

[0077] By defining an HTTP interface specification, a command to validate LDAP entry formats is added, providing an API interface.

[0078] Specifically, the HTTP / PP interface definition information is as follows. This new interface is used to validate the format of LDAP entries, and the request method is POST. The request path can be / api / v1 / ldap / validate. Parameters are transmitted via a JSON format request body, with the following field definitions.

[0079] Field name: adminDN, type: string, description: administrator DN (used for binding LDAP).

[0080] Field name: password, type: string, description: administrator password.

[0081] Field name: schemaDN, type: string, description: the DN of the target entry.

[0082] Field name: attributes, type: object, description: key-value pairs of attributes to be added.

[0083] Example request as follows: {"schemaDN":"dc=drope,dc=system,dc=config","attributes":{"cn":"D001","displayName":"SkyRider Pro X","droneModel":"SRX-500"}}.

[0084] Define standard plug-in interface specifications, provide a plug-in mechanism, and support the integration of third-party tools with the LDAP system.

[0085] Specifically, the standard plug-in interface specification is the SDK interface specification.

[0086] This application also provides a visual editing device 200 based on the LDAP schema specification, such as... Figure 2 As shown, the device includes: a definition module 201, a generation module 202, and a verification module 203.

[0087] The definition module 201 is used to define and modify attribute value constraint rules in the LDAP schema specification in a graphical interface, and generate an enhanced schema file.

[0088] The generation module 202 is used to generate a general schema file based on the data information in the enhanced schema file. The enhanced schema file is stored in the business service, while the general schema file is stored in the LDAP system.

[0089] The verification module 203 is used to perform static and dynamic verification of the business data provided by the user through the enhanced schema file. After successful verification, it calls the LDAP data editing interface and uses an internal mechanism to call the general schema specification reflected in the general schema file to verify the business data again. If the verification fails, it returns the error reason according to the error message configured in the enhanced schema file. After successful verification again, the business data is stored in the LDAP server.

[0090] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0091] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0092] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, for example, as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0093] like Figure 3 As shown, this application embodiment also provides a visual editing server based on the LDAP schema specification, including a memory 301 and a processor 302; the memory 301 is used to store computer-executable instructions; the processor 302 is used to execute the computer-executable instructions to implement the visual editing method based on the LDAP schema specification described above in this application embodiment.

[0094] This application also provides a computer-readable storage medium storing executable instructions, which, when executed by a computer, enable the visualization editing method based on the LDAP schema specification described above in this application.

[0095] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in the embodiments of this application.

[0096] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations.

[0097] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of this application.< / password> < / password>

Claims

1. A method for visual editing based on LDAP schema specification, characterized in that, The application comprises the following steps: Defining and modifying attribute value constraint rules in the LDAP schema specification in a graphical interface, generating an enhanced Schema file; Based on the data information in the enhanced Schema file, a general Schema file is generated; the enhanced Schema file is stored in a business service, and the general Schema file is stored in an LDAP system; Providing static and dynamic checks on the business data provided by the user through the enhanced Schema file; After the check is successful, the data editing interface of the LDAP is called, and the general Schema specification embodied in the general Schema file is called through an internal mechanism to perform a check on the business data again; If the check fails, the error reason is returned according to the error prompt information configured in the enhanced Schema file; After the second check is successful, the business data is stored in the LDAP server; The definition and modification of the attribute value constraint rules in the LDAP schema specification in the graphical interface and the generation of the enhanced Schema file comprises the following steps: mapping the attributes in the JSON Schema data to the corresponding elements in the graphical interface according to the UI-Schema configured by the user to define and modify the attribute value constraint rules in the LDAP schema specification in the graphical interface; integrating the JSON Schema Editor tool, generating the enhanced Schema file based on the information of the user-defined JSON Schema data and the UI-Schema; extracting the data of the enhanced Schema file, converting the extracted data into ldif file data related to the LDAP system, and realizing the conversion from the visual definition of the graphical interface to the actual storage format of the LDAP system; The static check comprises the following steps: extracting the information in the business data, including the field type, the constraint rule and the custom check configuration; based on the information in the business data, using the JSON Schema verification tool to perform a field-by-field check on the business data, including type checking, length checking and regular checking; The dynamic check comprises the following steps: extracting the configuration information for dynamic check from the enhanced Schema file; analyzing the extracted configuration information to obtain a calling path; the calling path comprises the service name responsible for the check; according to the analyzed service name, finding and locating the corresponding service instance in the back-end service environment; taking the business data to be checked and the field information to be checked as parameters, initiating a call through the service calling mechanism, passing the parameters to the service instance, and executing the dynamic check logic.

2. The method of claim 1, wherein, The generation of the general Schema file based on the data information in the enhanced Schema file comprises the following steps: Analyzing the enhanced Schema file stored in the business service to identify the content in the enhanced Schema file that conforms to the LDAP standard; the content that conforms to the LDAP standard comprises the data structure and the basic constraint rule information; The enhanced Schema file is used to check the extended data, including regular check rules, dynamic data format check rules and self-defined check method configurations; The contents of the enhanced Schema file conforming to the LDAP standard are arranged according to the data structure requirements of the LDAP system, and the specific structure of the general Schema file is determined according to the format and specifications required by the LDAP system, so as to generate the general Schema file; The generated general Schema file is transmitted to the LDAP system through a preset transmission protocol, and the storage operation is completed.

3. The method of claim 2, wherein the LDAP schema specification is visualized by: Further comprising: By defining the HTTP interface specification, adding a command for verifying the format of the LDAP entry, and providing an API interface; Defining a standard plug-in interface specification to provide a plug-in mechanism and support the integration of third-party tools and the LDAP system.

4. An apparatus for visual editing based on LDAP schema specification, characterized by, Comprising: Defining a module for defining and modifying attribute value constraint rules in the LDAP mode specification in a graphical interface, and generating an enhanced Schema file; A generation module for generating a general Schema file based on the data information in the enhanced Schema file; wherein the enhanced Schema file is stored in a business service, and the general Schema file is stored in an LDAP system; A check module for performing static and dynamic checks on the business data provided by a user through the enhanced Schema file; after the check is successful, the data editing interface of the LDAP is called, and the general Schema specification embodied in the general Schema file is called through an internal mechanism to perform a check on the business data again; if the check fails, the error reason is returned according to the error prompt information configured in the enhanced Schema file; after the second check is successful, the business data is stored in the LDAP server; The enhanced Schema file is generated by defining and modifying the attribute value constraint rules in the LDAP mode specification in a graphical interface, including: mapping the attributes in the JSON Schema data to the corresponding elements in the graphical interface according to the user-defined JSON Schema data configuration UI-Schema, to define and modify the attribute value constraint rules in the LDAP mode specification in the graphical interface; integrating a JSON Schema Editor tool, generating an enhanced Schema file based on the user-defined JSON Schema data and the information of the UI-Schema; extracting the enhanced Schema file, converting the extracted data into ldif file data related to the LDAP system, and realizing the conversion from the visual definition of the graphical interface to the actual storage format of the LDAP system; The static check includes extracting information in the business data, including field types, constraint rules and self-defined check configurations; based on the information in the business data, using a JSON Schema verification tool to perform field-by-field check on the business data, including type checking, length checking and regular checking; The dynamic verification comprises extracting configuration information for dynamic verification from an enhanced Schema file; parsing the extracted configuration information to obtain a calling path; wherein the calling path comprises a service name responsible for verification; according to the parsed service name, searching and locating to a corresponding service instance in a back-end service environment; taking the business data to be verified and the field information currently needing verification as parameters, initiating a call through a service calling mechanism, passing the parameters to the service instance, and executing dynamic verification logic.

5. A visual editing server based on LDAP schema specification, characterized by, comprising a memory and a processor; the memory is configured to store computer executable instructions; the processor is configured to execute the computer executable instructions to implement the method of any one of claims 1-3.

6. A computer readable storage medium characterized by, The computer readable storage medium stores executable instructions, and the computer executes the executable instructions to implement the method of any one of claims 1-3.

Images