Northbound interface multi-version control method, device, equipment and readable storage medium

Abstract

This application relates to a method, apparatus, device, and readable storage medium for controlling multiple versions of a northbound interface. The method includes parsing multiple versions of standard specification data corresponding to NMS using a script to generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body exhibit reflective properties. Each metadata element includes a field name and the structural relationship between fields. The method further involves filtering out target metadata corresponding to the target version of the standard specification sent by the user from the multiple metadata elements. Based on the target field names in the target metadata, the method performs POD (Programmable Item) reflection access on the data body to obtain the target field descriptions corresponding to the target field names. Finally, the method generates target specification data based on the target metadata and target field descriptions. Based on the target specification data, the method updates the specification data in the NMS standard specification model, enabling the northbound interface to adapt to the target version of the standard specification. This improves the accuracy and efficiency of source code parsing and shortens the development cycle.

Description

Technical Field

[0001] This application relates to the field of gateway northbound interface technology, and in particular to a method, apparatus, device and readable storage medium for controlling multiple versions of a northbound interface. Background Technology

[0002] Currently, in the entire network management system usage process, the northbound interface is the intermediary between the vendor's own system and the NMS (Network Management System). It occupies a higher layer than the user's application, so changes in customer needs are directly reflected at the northbound interface level. Vendors typically provide an OMC (Operation and Maintenance Center) system and its associated northbound interface for upgrades in various cities across the country. However, nowadays, different cities, and even provinces after centralized management, use different standards and specifications for northbound interface management based on their own circumstances. This necessitates that the northbound interface support multiple customer-specified standards and specifications (i.e., multiple versions) based on the same OMC system, and can quickly respond to new standards and specifications to update requirements to support the entire application.

[0003] In related technologies, the common practice for northbound interfaces to support multiple versions is to adapt the corresponding specification model for each version of the standard specification. Therefore, for a new version of the specification, a new specification model is directly adapted, that is, the new features are supported through development and coding adaptation at various levels. However, since northbound interfaces are at the application layer, the specifications they follow are updated frequently, and each time new features need to be supported, resulting in a large development cost and a long development cycle. In addition, due to the large number of interface types, network resource types, and complex packet entry characteristics, implementation through manual analysis and adaptation is often prone to errors. Summary of the Invention

[0004] This application provides a method, apparatus, device, and readable storage medium for northbound interface multi-version control, in order to solve the problems of long development cycle and easy error in the implementation of northbound interface multi-version control in related technologies.

[0005] Firstly, a method for multi-version control of northbound interfaces is provided, including the following steps:

[0006] The script parses the standard specification data of multiple versions corresponding to the Network Management System (NMS) to generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in its corresponding standard specification.

[0007] When the target version standard specification is received from the user side, the target metadata is filtered out from multiple metadata, and the data body is accessed by POD reflection based on the target field name in the target metadata to obtain the target field description corresponding to the target field name.

[0008] Target specification data is generated based on target metadata and target field descriptions. The specification data in the NMS standard specification model is then updated based on the target specification data to ensure that the northbound interface is compatible with the target version of the standard specification.

[0009] In some embodiments, the step of parsing multiple versions of standard specification data corresponding to the Network Management System (NMS) using scripts to generate a data body and multiple metadata, including:

[0010] The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification.

[0011] The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification;

[0012] Perform a union operation on all field information to generate a data body;

[0013] Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

[0014] In some embodiments, prior to the step of performing POD reflection initialization processing on the data volume, the method further includes:

[0015] A cross-service communication file is constructed based on the data body, and the cross-service communication file supports cross-language compilation;

[0016] The steps for performing POD reflection initialization processing on the data volume include:

[0017] The cross-service communication files are compiled according to the target compilation language to generate target source code corresponding to the target compilation language;

[0018] The target source code is executed by a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body.

[0019] In some embodiments, the step of executing the target source code through a compiler corresponding to the target compiled language to achieve POD reflection initialization processing of the data body includes:

[0020] When the compiler corresponding to the target compilation language executes the target source code, the relational macros in the compiler create a Map reflection collection;

[0021] The macro definition in the compiler registers the field names and field descriptions with mapping relationships in the data body of the target source code to the Map reflection collection, so that the POD reflection macro in the compiler can realize reflection access to the corresponding field description based on the field name.

[0022] In some embodiments, after the step of constructing a cross-service communication file based on the data body, the method further includes:

[0023] When new standard specification data to be processed is detected, the cross-service communication file is incrementally defined based on the new standard specification data to be processed, thus forming a new cross-service communication file.

[0024] In some embodiments, prior to the step of parsing the data of multiple versions of the standard specification corresponding to the Network Management System (NMS) via script, the method further includes:

[0025] Obtain original standard specification data for multiple versions corresponding to NMS;

[0026] Each original standard specification data is converted into a target format standard specification data based on a preset conversion protocol. The preset conversion protocol is determined based on the protocol format that the script can parse.

[0027] Secondly, a multi-version control device for a northbound interface is provided, including:

[0028] The first processing unit is used to parse the data to be processed from multiple versions of the standard specification data corresponding to the Network Management System (NMS) through a script, and generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in the corresponding standard specification.

[0029] The second processing unit is used to filter out target metadata from multiple metadata when it receives the target version standard specification sent by the user side, and perform POD reflection access on the data body based on the target field name in the target metadata to obtain the target field description corresponding to the target field name.

[0030] The third processing unit is used to generate target specification data based on target metadata and target field descriptions, and update the specification data in the NMS standard specification model based on the target specification data so that the northbound interface can adapt to the target version of the standard specification.

[0031] In some embodiments, the first processing unit is specifically used for:

[0032] The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification.

[0033] The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification;

[0034] Perform a union operation on all field information to generate a data body;

[0035] Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

[0036] Thirdly, a northbound interface multi-version control device is provided, comprising: a memory and a processor, wherein the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the aforementioned northbound interface multi-version control method.

[0037] Fourthly, a computer-readable storage medium is provided, the computer storage medium storing computer instructions, which, when executed by a computer, cause the computer to execute the aforementioned northbound interface multi-version control method.

[0038] The beneficial effects of the technical solution provided in this application include: effectively improving the accuracy and efficiency of source code parsing and shortening the development cycle.

[0039] This application provides a method, apparatus, device, and readable storage medium for controlling multiple versions of a northbound interface. The method includes parsing multiple versions of standard specification data corresponding to a Network Management System (NMS) using a script to generate a data body and multiple metadata. Each field name and its corresponding field description in the data body exhibits reflective properties. Each metadata element includes the field name and structural relationship between fields in its corresponding standard specification. When a target version standard specification is received from the user side, the target metadata is selected from the multiple metadata elements. Based on the target field name in the target metadata, the data body is accessed via POD reflection to obtain the target field description corresponding to the target field name. Target specification data is generated based on the target metadata and target field description. The specification data in the NMS standard specification model is updated based on the target specification data to ensure the northbound interface adapts to the target version standard specification. This application automates the parsing of multiple versions of standard specifications using scripts, eliminating the need for manual analysis and adaptation to avoid errors and effectively improve the accuracy and efficiency of source code parsing. Furthermore, by separating standard specifications into data bodies and metadata, and dynamically binding the data bodies and metadata through POD reflection to generate target specification data, and then updating the specification data in the NMS standard specification model based on the target specification data, the northbound interface can self-adapt to the target version of the standard specification without needing to redevelop a specification model for each version, effectively reducing development workload and shortening the development cycle. Attached Figure Description

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

[0041] Figure 1 A flowchart illustrating a northbound interface multi-version control method provided in an embodiment of this application;

[0042] Figure 2 A schematic diagram illustrating the specific process of the northbound interface multi-version control method provided in this application embodiment;

[0043] Figure 3 A schematic diagram illustrating the data construction process provided in the embodiments of this application;

[0044] Figure 4 A schematic diagram illustrating multi-version dynamic binding provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram of the structure of a northbound interface multi-version control device provided in an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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 embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] This application provides a method, apparatus, device, and readable storage medium for northbound interface multi-version control, which can solve the problems of long development cycle and easy error in the implementation of northbound interface multi-version control in related technologies.

[0048] See Figure 1 and Figure 2 As shown in the figure, this application embodiment provides a method for multi-version control of a northbound interface, including the following steps:

[0049] Step S10: The script parses the data of multiple versions of the standard specification to be processed corresponding to the Network Management System (NMS) to generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in the corresponding standard specification.

[0050] As an example, currently, NMS systems in different cities or provinces use different standard specifications for northbound interface management based on their own circumstances. Therefore, for a given northbound interface, in order to simultaneously connect with NMS systems in different cities or provinces, it needs to adapt to different versions of the standard specification. For example, the NMS system in city A uses standard specification version X, the NMS system in city B uses standard specification version Y, and the NMS system in city C uses standard specification version Z. That is, the multiple versions of the standard specification corresponding to the NMS system include X, Y, and Z. Therefore, in order to connect with the NMS systems in cities A, B, and C, northbound interface D needs to self-adapt to standard specification versions X, Y, and Z. It should be noted that the northbound interface referred to in this embodiment is general and does not specify a particular type of northbound interface; it can be horizontally extended to multiple types of northbound interfaces.

[0051] To enable northbound interfaces to adapt to different versions of standard specifications, it is necessary to analyze and adapt each version of the standard specifications. This embodiment uses a scripting approach to parse the standard specifications of each version. Specifically, the script parses the standard requirements of each version, thereby obtaining an intermediate proxy model (i.e., Multi-version, Value). Specifically, the script parses the standard specification data to be processed for each version of the standard specification to extract header and file-related information. This standard specification data includes basic information about the standard specification (i.e., the version number, name, format, and the version number of the northbound interface supported by the standard specification) and resource descriptions (including but not limited to field names, types, quantities, and order). Therefore, by parsing the standard specification data using a scripting language, a data body supporting all network standard specifications and the metadata corresponding to each standard specification can be generated.

[0052] For example, metadata includes, but is not limited to, the version number, name, format, resource description, version numbers of the northbound interfaces supported by the standard specification, and the structural relationships between different resource fields. The metadata corresponding to different versions of the standard specification is stored in an intermediate proxy model. That is, the Multi-version in the intermediate proxy model corresponds to different versions of the standard specification, while the Value corresponds to the resource description and the structural relationships between different resource fields. For instance, if Multi-version includes standard specifications X, Y, and Z, then the Value for X includes the resource description for X and the structural relationships between different resource fields; the Value for Y includes the resource description for Y and the structural relationships between different resource fields; and the Value for Z includes the resource description for Z and the structural relationships between different resource fields.

[0053] The data body contains the field name and description for each resource in each standard specification. It also incorporates reflection features for each field name and its corresponding description, allowing reflection access to the field description via the field name. For example, standard specification X includes a field named Key1 with the description "describe1" and a field named Key2 with the description "describe2". Standard specification Y includes a field named Key1 with the description "describe1" and a field named Key3 with the description "describe3". Standard specification Z includes a field named Key3 with the description "describe3" and a field named Key4 with the description "describe4". The data body will then store information including field names such as Key1 with the description "describe1", Key2 with the description "describe2", Key3 with the description "describe3", and Key4 with the description "describe4". The corresponding field description can be accessed via reflection using the field name; for example, accessing "describe1" via reflection using Key1.

[0054] Furthermore, before the step of parsing the data of multiple versions of the standard specifications corresponding to the Network Management System (NMS) using a script, the following steps are also included:

[0055] Obtain original standard specification data for multiple versions corresponding to NMS;

[0056] Each original standard specification data is converted into a target format standard specification data based on a preset conversion protocol. The preset conversion protocol is determined based on the protocol format that the script can parse.

[0057] In this exemplary embodiment, multiple versions of original standard specification data are entered. Then, according to a preset conversion protocol, each version of the original standard specification data is converted into standard specification data to be processed in a protocol format that the script can parse. The different versions of the standard specification data to be processed can be organized into an xls file (the xls file is only an example; other file formats can be generated according to actual needs), and uploaded to the corresponding internal model storage repository for specification management. This allows the script to parse the different versions of the standard specification data to be processed using this xls file. The preset conversion protocol can be determined by the requirements engineer based on the protocol format that the script can parse. For example, the converted standard specification data to be processed allows the script to retrieve necessary information from the standard specification (such as the version number).

[0058] Furthermore, the process involves parsing multiple versions of standard specification data corresponding to the Network Management System (NMS) using scripts to generate a data body and multiple metadata, including:

[0059] The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification.

[0060] The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification;

[0061] Perform a union operation on all field information to generate a data body;

[0062] Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

[0063] Exemplary, see Figure 3As shown in this embodiment, when it is necessary to retrieve and parse standard specification data corresponding to different versions of standard specifications, the system first connects to the internal model storage repository to obtain an xls file. Then, a preset script retrieves each piece of standard specification data to be processed in the xls file to achieve protocol verification and constraint checks on the standard specification data to be processed. If the protocol verification and constraint checks fail, an error message is reported, and the standard specification data to be processed is corrected. If they pass, the data parameters are checked. If the data parameter checks fail, an error message is also reported. If the data parameters pass the checks, the meta information of multiple versions can be polled to parse the header and file-related information to form metadata. At the same time, the body of multiple versions is parsed to form a data body, which is then stored. Therefore, this embodiment provides basic checks on standard specifications through script parsing, improving the accuracy when modifying complex standard specifications.

[0064] To enable cross-service communication for the northbound interface, this embodiment generates metadata slice files based on metadata and data body slice files based on the data body, thereby completing the parsing of standard specifications. The slice files in this embodiment support cross-language compilation, which improves interface adaptability. This allows different northbound interfaces to ignore language influences when using this framework. Therefore, the slice files can be converted into corresponding source code according to the compiler's compilation language requirements; that is, source code in the corresponding language can be generated from the slice files. For example, slice2cpp can generate CPP source code, and slice2java can generate Java source code, automating model adaptation and eliminating manual coding.

[0065] Specifically, the filenames of the xls files containing different versions of standard specification data to be processed are edited according to the agreed-upon method and uploaded. The metadata script automatically reads the filename of the standard specification corresponding to each piece of standard specification data to be processed from the xls file, and records the number of files and basic information such as the version information and file format of each standard specification, thereby constructing preliminary metadata information. At the same time, the filenames of the standard specifications are parsed to obtain the version number of the northbound interface supported by the standard specification. If the parsing fails, a message can be pushed to the requirements engineer so that the requirements engineer can correct the standard specification data to be processed. Then, the resource descriptions in the standard specification data to be processed are parsed by the metadata script.

[0066] For example, by accessing a standard specification file (e.g., A-V1.xlsx) through a scripting language, file version V1 can be obtained, and internal protocols such as table field descriptions, field attributes, and field constraints can be read to form metadata and generate a metadata slice file. The metadata slice file constructs modules based on version numbers, classes based on resource object types, and class members based on resource description keys. Furthermore, in this embodiment, metadata refers to the standard model description defined by NMS, which includes the version number of the standard specification and the version numbers of the supported northbound interfaces, resource names, the number of resource fields, resource field types, and field order. Except for the version number supported by the standard specification, which needs to be obtained by parsing the standard specification name, all other information can be obtained from the specific content of the standard specification.

[0067] Furthermore, a fixed data body script is needed to parse the data from multiple versions of the standard specifications to be processed, obtaining the field information corresponding to each standard specification. This allows for the collection of standard specification model data from all currently supported versions. A union operation is then performed to generate a data body object, and a corresponding data body slice file is generated. The data body slice file constructs modules based on version numbers, classes based on resource object types, and class members based on resource description keys. For example, first, the resource abbreviation is read as the class name NE; then, each field of each resource type in the standard specification is obtained, the field type Type is parsed, and the type definition as shown above is generated; and the field name is used as the name key of the type data member, resulting in the data body as follows:

[0068] StructNE

[0069] {

[0070] Type1 Key1;

[0071] Type2 Key2;

[0072] Type3 Key3; ...

[0074] }

[0075] Therefore, it can be seen that each version of the standard specification generates a corresponding metadata, while all the standard specifications supported by the entire network only generate a single data body. Thus, a single data body will have a mapping relationship with multiple metadata, that is, constructing metadata-data body to form multiple mappings, building a multi-version basic data structure for fixed script parsing, so that the complexity of the model can be fixed and parsed through scripts, thereby reducing the complexity of the standard specification version data description and reducing the model complexity brought about by continuous upgrades. Moreover, the data of all versions of the standard specification is controlled by metadata. At the same time, by separating the management of the data body and version information (i.e., metadata) to parse the standard specification of the northbound interface, the benefits of low coupling and independent control can be brought.

[0076] After completing the data construction, this embodiment will also use the concept of reflection and build a set of POD (Plain Old Data structure) object reflection implementation methods based on templates and macros to perform POD reflection initialization processing on the data body, so that metadata (i.e., northbound interface version information) can be bound to the data body through POD object reflection, that is, to build the reflection characteristics between the field names and their corresponding field descriptions in the data body.

[0077] Furthermore, prior to the step of performing POD reflection initialization processing on the data volume, the following steps are also included:

[0078] A cross-service communication file is constructed based on the data body, and the cross-service communication file supports cross-language compilation;

[0079] The steps for performing POD reflection initialization processing on the data volume include:

[0080] The cross-service communication files are compiled according to the target compilation language to generate target source code corresponding to the target compilation language;

[0081] The target source code is executed by a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body.

[0082] In this exemplary embodiment, after parsing multiple versions of standard specification data to be processed using a fixed data body script to obtain the data body and generate the corresponding data body slice file (i.e., cross-service communication file), the slice file is compiled according to the compiler's compilation language type to generate target source code with the same language type as the compiler (for example, if the compiler's compilation language is Java, the slice file is converted into Java source code). Then, the target source code is executed by the compiler, which includes the POD object reflection implementation method, to complete the POD reflection initialization processing of the data body.

[0083] Furthermore, the step of executing the target source code through a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body includes:

[0084] When the compiler corresponding to the target compilation language executes the target source code, the relational macros in the compiler create a Map reflection collection;

[0085] The macro definition in the compiler registers the field names and field descriptions with mapping relationships in the data body of the target source code to the Map reflection collection, so that the POD reflection macro in the compiler can realize reflection access to the corresponding field description based on the field name.

[0086] As an example, in this embodiment, the method for quickly constructing a POD object reflection implementation is general, meaning it can directly access data member type objects or has methods to access internal members. In this embodiment, the POD object refers to a data body object, which is automatically generated after collecting standard specification data through a script, and is defined in the slice file. This embodiment borrows the concept of reflection and uses macros, templates, and function binding techniques to construct simple reflection-based data for each object in the data body. Specifically, source code-level logic can be directly generated through the following fixed macro combinations: defining mapping relationships through DECLARE_STRING_FUNC_MAP, registering objects through REG_STRING_FIELD, and implementing reflection access through IMPL_OBJ_TYPE_BEGIN and IMPL_OBJ_TYPE_END; that is, traversing all objects in the data body using the above four function macros and directly generating .h or .CPP files.

[0087] Specifically, firstly, a mapping relationship storage is built for types that need to support simple reflection using relational macros (i.e., DECLARE_STRING_FUNC_MAP), generating a Map reflection collection (e.g., mapStringField2Value). This collection stores the mapping relationship between parameter names and methods for accessing those parameters. In other words, POD reflection needs to store information about fields and methods for accessing those fields; for example, the Map reflection collection stores Key1 and the method for accessing Key1. Then, object registration is performed using macro definitions (i.e., REG_STRING_FIELD), registering the field names and descriptions with mapping relationships within the target source code's data body to the Map reflection collection. Then, the registered objects in the Map reflection collection can be accessed using the reflection macros IMPL_OBJ_TYPE_BEGIN and IMPL_OBJ_TYPE_END. For example, registering Key1 and its corresponding describe1 to the Map reflection collection allows access to the value corresponding to Key1 (i.e., describe1) through Key1. It should be noted that each field object in the data body needs to be registered in the Map reflection collection.

[0088] Therefore, the POD reflection initialization process is implemented in the source code, and the object registration part can be automated. After the data body script automatically retrieves the data body, the compiler only needs to register the objects in the data body into the Map reflection collection. Thus, once the framework for POD reflection initialization is established, the source code mapping can also be automatically retrieved and generated by the script.

[0089] Step S20: When the target version standard specification sent by the user side is received, the target metadata is filtered out from multiple metadata, and the data body is accessed by POD reflection based on the target field name in the target metadata to obtain the target field description corresponding to the target field name.

[0090] In this exemplary embodiment, step S10 achieves independent modeling of the metadata and data body of the standard specification. For example, the standard specification has X, Y, and Z, and the metadata corresponding to X is E, the metadata corresponding to Y is F, and the metadata corresponding to Z is G. The data body K stores field names Key1 with the field description describe1, field names Key2 with the field description describe2, field names Key3 with the field description describe3, and field names Key4 with the field description describe4. When a user selects Y as the target version of the standard specification from X, Y, and Z, this embodiment will filter the metadata F from the intermediate proxy model based on the name and other basic information of Y as the target metadata corresponding to the target version of the standard specification, and perform reflection access on the data body K based on the field names in the target metadata to obtain the corresponding field descriptions.

[0091] For example, if the target metadata includes field names Key2 and Key4 and the structural relationships between the fields, then by performing reflection access on the data body through Key2 and Key4 respectively, we can obtain the target field description corresponding to Key2 as describe2 and the target field description corresponding to Key4 as describe4.

[0092] Step S30: Generate target specification data based on target metadata and target field descriptions, and update the specification data in the NMS standard specification model based on the target specification data so that the northbound interface is compatible with the target version standard specification.

[0093] In this exemplary embodiment, after obtaining the target field description, target specification data can be generated based on the Value stored in the intermediate proxy model. The existing specification data in the NMS standard specification model is then replaced with the target specification data (i.e., model data), enabling the northbound interface to adapt to the target version of the standard specification. Thus, this embodiment elevates version control to a higher-level metadata control layer. At the data level, the script automatically generates the metadata model and data body model. Dynamic binding between the metadata model and data body model is achieved through automatically constructed POD reflection, dynamically generating the standard specification data required by the NMS system. Furthermore, only the specification data of the general NMS standard specification model needs to be modified based on this standard specification data to enable the northbound interface to dynamically support multiple version switching, with each version model operating independently without interference. Therefore, after development is complete, support for new standard specifications requires no source code modifications, minimizing development workload and costs and effectively improving development efficiency.

[0094] For details, see Figure 4As shown, the user side issues a standard specification of version V1. The version control information of this standard specification is used to read the metadata corresponding to this version (i.e., return metadata), such as V1::ObjHeaderSeq. Then, the current version object mapping relationship is dynamically constructed, and the object keys in the data body are sequentially traversed through the metadata information V1::ObjHeaderSeq (i.e., getdatabymeta). The data objects are accessed through reflection, the metadata is bound to the data body, and NMS specification data is generated to return the standard model.

[0095] Furthermore, following the step of constructing a cross-service communication file based on the data body, the method further includes:

[0096] When new standard specification data to be processed is detected, the cross-service communication file is incrementally defined based on the new standard specification data to be processed, thus forming a new cross-service communication file.

[0097] As an example, due to the frequent iterations of application-level specifications, ensuring that the northbound interface supports both the latest specification model and backward compatibility often leads to a large amount of redundant coding logic. Therefore, to solve the compatibility problem, this embodiment uses incremental definitions through standard specification iterations between versions. That is, in cross-service communication files, data existing in previous versions is inherited in new versions. Only newly added or changed data needs to be incrementally defined to generate the modified model, without needing to create a completely new model, thus avoiding redundant coding logic. Therefore, this embodiment only requires minor development of the new data body for the development of new features, solving the problem of cascading changes in existing technologies, significantly improving development efficiency and reducing development costs.

[0098] In summary, this embodiment manages version information (i.e., specification metadata) through data separation and dynamically binds version information to the data body via POD reflection to generate a standard specification model. This allows the northbound interface to quickly adapt to various corresponding standard specifications through scripting, thus providing greater flexibility in supporting the features of multiple interface versions. It also allows the application layer to quickly respond to changes in customer needs and rapidly update its own features. When new standard specifications arrive, the northbound interface can quickly respond and support them, effectively reducing source code modifications and ensuring the accuracy of standard specification details. Furthermore, this embodiment, based on scripting, ensures that no details are missed when parsing complex standard specifications, achieving a much higher accuracy rate than manual source code parsing. This improves the compatibility and accuracy of the northbound interface when supporting multiple specification versions, enabling the same OMC system to adapt well to NMS systems implementing different standards in different cities.

[0099] This application also provides a northbound interface multi-version control device, including:

[0100] The first processing unit is used to parse the data to be processed from multiple versions of the standard specification data corresponding to the Network Management System (NMS) through a script, and generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in the corresponding standard specification.

[0101] The second processing unit is used to filter out target metadata from multiple metadata when it receives the target version standard specification sent by the user side, and perform POD reflection access on the data body based on the target field name in the target metadata to obtain the target field description corresponding to the target field name.

[0102] The third processing unit is used to generate target specification data based on target metadata and target field descriptions, and update the specification data in the NMS standard specification model based on the target specification data so that the northbound interface can adapt to the target version of the standard specification.

[0103] Furthermore, the first processing unit is specifically used for:

[0104] The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification.

[0105] The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification;

[0106] Perform a union operation on all field information to generate a data body;

[0107] Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

[0108] Furthermore, the first processing unit is also used for:

[0109] A cross-service communication file is constructed based on the data body, and the cross-service communication file supports cross-language compilation;

[0110] The cross-service communication files are compiled according to the target compilation language to generate target source code corresponding to the target compilation language;

[0111] The target source code is executed by a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body.

[0112] Furthermore, the first processing unit is specifically used for:

[0113] When the compiler corresponding to the target compilation language executes the target source code, the relational macros in the compiler create a Map reflection collection;

[0114] The macro definition in the compiler registers the field names and field descriptions with mapping relationships in the data body of the target source code to the Map reflection collection, so that the POD reflection macro in the compiler can realize reflection access to the corresponding field description based on the field name.

[0115] Furthermore, the first processing unit is also used for:

[0116] When new standard specification data to be processed is detected, the cross-service communication file is incrementally defined based on the new standard specification data to be processed, thus forming a new cross-service communication file.

[0117] Furthermore, the first processing unit is also used for:

[0118] Obtain original standard specification data for multiple versions corresponding to NMS;

[0119] Each original standard specification data is converted into a target format standard specification data based on a preset conversion protocol. The preset conversion protocol is determined based on the protocol format that the script can parse.

[0120] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device and each unit described above can be referred to the corresponding process in the aforementioned northbound interface multi-version control method embodiment, and will not be repeated here.

[0121] The apparatus provided in the above embodiments can be implemented as a computer program, which can be used in, for example... Figure 5 The northbound interface shown is used to control the operation of multiple versions of the device.

[0122] This application also provides a northbound interface multi-version control device, including: a memory, a processor, and a network interface connected via a system bus. The memory stores at least one instruction, which is loaded and executed by the processor to implement all or part of the steps of the aforementioned northbound interface multi-version control method.

[0123] The network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0124] A processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor, or any conventional processor. The processor is the control center of a computer device, connecting all parts of the computer device through various interfaces and lines.

[0125] Memory can be used to store computer programs and / or modules. The processor implements various functions of the computer device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for at least one function (such as video playback, image playback, etc.), etc.; the data storage area can store data created based on the use of the mobile phone (such as video data, image data, etc.). Furthermore, memory can include high-speed random access memory (RAM), and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMedia Cards (SMC), Secure Digital (SD) cards, Flash Cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.

[0126] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements all or part of the steps of the aforementioned northbound interface multi-version control method.

[0127] The embodiments of this application can implement all or part of the aforementioned processes, or they can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various methods described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0128] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0129] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0130] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0131] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for multi-version control of a northbound interface, characterized in that, Includes the following steps: The script parses the standard specification data of multiple versions corresponding to the Network Management System (NMS) to generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in its corresponding standard specification. When the target version standard specification is received from the user side, the target metadata is filtered out from multiple metadata, and the data body is accessed by POD reflection based on the target field name in the target metadata to obtain the target field description corresponding to the target field name. Target specification data is generated based on target metadata and target field descriptions. The specification data in the NMS standard specification model is then updated based on the target specification data to ensure that the northbound interface is compatible with the target version of the standard specification. Specifically, the process involves parsing multiple versions of standard specification data corresponding to the Network Management System (NMS) using scripts to generate a data body and multiple metadata, including: The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification. The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification; Perform a union operation on all field information to generate a data body; Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

2. The northbound interface multi-version control method as described in claim 1, characterized in that, Before the step of performing POD reflection initialization processing on the data volume, the method further includes: A cross-service communication file is constructed based on the data body, and the cross-service communication file supports cross-language compilation; The steps for performing POD reflection initialization processing on the data volume include: The cross-service communication files are compiled according to the target compilation language to generate target source code corresponding to the target compilation language; The target source code is executed by a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body.

3. The northbound interface multi-version control method as described in claim 2, characterized in that, The step of executing the target source code through a compiler corresponding to the target compilation language to achieve POD reflection initialization processing of the data body includes: When the compiler corresponding to the target compilation language executes the target source code, the relational macros in the compiler create a Map reflection collection; The macro definition in the compiler registers the field names and field descriptions with mapping relationships in the data body of the target source code to the Map reflection collection, so that the POD reflection macro in the compiler can realize reflection access to the corresponding field description based on the field name.

4. The northbound interface multi-version control method as described in claim 2, characterized in that, Following the step of constructing a cross-service communication file based on the data body, the following is also included: When new standard specification data to be processed is detected, the cross-service communication file is incrementally defined based on the new standard specification data to be processed, thus forming a new cross-service communication file.

5. The northbound interface multi-version control method as described in claim 1, characterized in that, Before the step of parsing the data of multiple versions of the standard specifications corresponding to the Network Management System (NMS) using a script, the method further includes: Obtain original standard specification data for multiple versions corresponding to NMS; Each original standard specification data is converted into a target format standard specification data based on a preset conversion protocol. The preset conversion protocol is determined based on the protocol format that the script can parse.

6. A northbound interface multi-version control device, characterized in that, include: The first processing unit is used to parse the data to be processed from multiple versions of the standard specification data corresponding to the Network Management System (NMS) through a script, and generate a data body and multiple metadata. The field names and their corresponding field descriptions in the data body have reflection characteristics. Each metadata includes the field name and the structural relationship between the fields in the corresponding standard specification. The second processing unit is used to filter out target metadata from multiple metadata when it receives the target version standard specification sent by the user side, and perform POD reflection access on the data body based on the target field name in the target metadata to obtain the target field description corresponding to the target field name. The third processing unit is used to generate target specification data based on target metadata and target field descriptions, and update the specification data in the NMS standard specification model based on the target specification data so that the northbound interface can adapt to the target version of the standard specification. Specifically, the first processing unit is used for: The metadata script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and generates metadata corresponding to each standard specification. The data body script parses the data of multiple versions of the standard specification to be processed corresponding to NMS, and obtains the field information corresponding to each standard specification; Perform a union operation on all field information to generate a data body; Perform POD reflection initialization on the data body to build reflection properties between the field names and their corresponding field descriptions in the data body.

7. A northbound interface multi-version control device, characterized in that, include: A memory and a processor, wherein the memory stores at least one instruction, which is loaded and executed by the processor to implement the northbound interface multi-version control method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer storage medium stores computer instructions, which, when executed by the computer, cause the computer to perform the northbound interface multi-version control method as described in any one of claims 1 to 5.

Images