CN103164389A - Method and system for processing user-defined format plane ticket files - Google Patents

Abstract

The invention discloses a method and system for processing flat bill files in a self-defined format. The processing method includes: respectively abstracting the format definition of the bill file from the format information of the bill file provided by different operators, and using the format Define the configuration file to store the format definition of the bill file of the corresponding operator; abstract the rule definition of the node verification from the rule information of the bill node verification provided by different operators, and use the rule definition configuration file to store the corresponding operation The rule definition of the node verification of the supplier; create the corresponding bill file object according to the obtained current bill file, and load the format definition and rule definition, then call the format definition and rule definition, and provide the current bill file The file object sets the format and check rules, and encodes, decodes, and checks the current bill file object. The technical proposal of the present invention has high versatility, good expansibility, good performance and good reusability.

Description

A method and system for processing flat bill files in a custom format

technical field

The invention relates to the field of mobile communication, in particular to a method for processing flat bill files in a self-defined format.

Background technique

Mobile communication roaming billing is usually based on the GSMA standard TAP bill file to implement data clearing, and finally achieve the purpose of financial settlement. At present, the billing bill files of most operators in the world conform to the TAP standard. In this way, when the clearing center implements bill clearing, it only needs to implement corresponding encoding, decoding and proofreading based on several corresponding TAP file versions (such as TAP310 and TAP311). It can deal with any operator's billing file that meets the TAP bill standard.

However, some operators still have some bill files that do not conform to the TAP standard. These bill files are usually in flat text format, such as CSV format, fixed-length split format, and there are cases where bill files contain file header nodes and tail nodes. , each individual node may also contain sub-attributes, and multiple formats may be mixed in a file, and the number of nodes and verification methods are different. That is to say, a non-standard planar CDR file of an operator is completely customized in format and verification rules. Such a complicated situation has brought great pressure to the clearing center.

Faced with this situation, the commonly used processing method is to implement the corresponding encoding, decoding and verification schemes according to each custom format bill file. This is also the easiest to understand scheme, but this scheme brings to the clearing center High cost, because it is not easy to implement a codec and verification scheme, and this scheme is not universal, and can only be applied to the corresponding bill file.

Another processing method is to convert the self-defined format bill file into a standard TAP file, and then implement the clearing. The reason why this solution is feasible is that no matter what format the bill file is in, it is necessary to describe the basic information of the call, so most nodes have functional similarities with the TAP standard. However, this solution still has significant shortcomings. First, there are usually large differences between the non-standard bill file and the TAP bill file, which makes it difficult for some nodes to match during the conversion; secondly, the conversion is performed first and then the Clearing needs to pay conversion costs, which reduces the system processing capacity; finally, it is necessary to implement a corresponding conversion scheme for each type of custom bill file, which does not have reusability.

Both of the two common solutions mentioned above can solve the problem of encoding, decoding and verification of the custom-format flat bill file, but at the same time, they have inevitable and important defects. First of all, the cost is high, and especially for the emergence of new custom format bills, it is completely necessary to implement a new codec and verification mechanism, or implement a new conversion rule. In the long run, there needs to be a solution that can not only cope with the encoding, decoding and verification of the existing self-defined format flat bill files, but also only need to pay a small cost when a new custom format bill file appears The codec and verification of the new file can be completed.

The present invention is such a scheme, and the technical problem to be solved by this scheme is that, for the high cost of encoding, decoding and verification of the existing self-defined format flat bill file, especially in the face of the emergence of the new format flat bill file and the system expansion In order to solve the problem of lack of compatibility, a new scheme for encoding, decoding and verification of flat call list files in a custom format is provided. This solution mainly provides a set of reusable, easy-to-extend, high-efficiency, and thus cost-reducing custom-format flat bill file encoding, decoding and verification through the abstract file format and verification rules, and through the format definition and verification rule definition. method.

Contents of the invention

The technical problem to be solved by the present invention is to provide a method for processing flat call list files in a self-defined format with good scalability in view of the above-mentioned defects in the prior art.

The technical solution adopted by the present invention to solve its technical problems is: construct a kind of processing method of self-defined format plane bill file, comprising:

S10. Abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the operator's identification to store the format definition of the bill file of the corresponding operator;

S20. Abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the operator's identification to store the corresponding operator's node verification rule definition;

S30. Create the corresponding bill file object according to the acquired current bill file, and load the format definition and rules from the corresponding format definition configuration file and the corresponding rule definition configuration file according to the operator of the current bill file definition, and then call the format definition and rule definition, and set the format and verification rules for the current bill file object, and perform encoding, decoding and verification on the current bill file object.

In the processing method of the self-defined format plane bill file of the present invention, in step S10, abstract the format definition of the bill file from the format information of the bill file provided by the operator, and use the identification of the operator The relevant format definition configuration file is used to store the format definition steps of the bill file of the corresponding operator, specifically including:

S11. Obtain the bill file provided by the operator;

S12. Decomposing the bill file into multiple semantic units;

S13. Determine whether each semantic unit is built in the pre-stored semantic unit system one by one, if so, then proceed to step S14; if not, then define a new semantic unit, then perform step S14;

S14. Determine whether the value-taking method of each node is built in the pre-stored value-taking method system one by one, if so, proceed to step S15; if not, define a new value-taking method;

S15. Analyze the node attributes, and judge whether the node has sub-attributes, if not, then perform step S16; if so, analyze the value-taking method of the sub-attributes, and then perform step S16;

S16. Combining the analyzed semantic unit, value acquisition method, and node attribute to determine the format definition;

S17. Use the format definition configuration file related to the operator's identifier to store the format definition of the bill file of the corresponding operator.

In the processing method of the self-defined format plane call list file of the present invention, in the step S20, the rule definition of node verification is abstracted from the rule information of node verification provided by the operator, and used with the operator The step of storing the corresponding operator's node verification rule definition configuration file in the rule definition configuration file related to the operator's identity includes:

S21. Decomposing the semantic unit into multiple nodes;

S22. Analyze the verification attribute of each node, and judge whether the verification attribute is built in the pre-stored verification attribute system, if so, execute step S23; if not, define a new verification attribute, and then execute Step S23;

S23. Combining the analyzed verification attributes to determine a rule definition for node verification;

S24. Use the rule definition configuration file related to the operator's identifier to store the corresponding operator's node verification rule definition.

In the processing method of the self-defined format planar call list file of the present invention, the verification attributes pre-stored in the verification attribute system include: node name, existence attribute, existence condition, data type, data length, effective value , There are attribute error codes and illegal value error codes.

The present invention also constructs a processing system of a self-defined format plane call list file, including:

The format definition module is used to abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the identity of the operator to store the bill file of the corresponding operator format definition;

The rule definition module is used to abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the identity of the operator to store the corresponding operator's Rule definition for node verification;

A processing module, configured to create a corresponding bill file object according to the acquired current bill file, and load the format from the corresponding format definition configuration file and the corresponding rule definition configuration file according to the operator of the current bill file definition and rule definition, and then call the format definition and rule definition, and set the format and verification rules for the current bill file object, and perform encoding, decoding and verification on the current bill file object.

In the processing system of the self-defined format plane call list file of the present invention, the format definition module includes:

an acquisition unit, configured to acquire the bill file provided by the operator;

The first decomposing unit is used to decompose the bill file into multiple semantic units;

The first judging unit is used to judge whether each semantic unit is built in the pre-stored semantic unit system one by one;

The first definition unit is used to define a new semantic unit when judging that the semantic unit is not built into the pre-stored semantic unit system;

The second judging unit is used to judge one by one whether the value-taking method of each node is built in the pre-stored value-taking method system;

The second definition unit is used to define a new value-taking method when it is judged that the value-taking method of the node is not built into the pre-stored value-taking method system;

The third judging unit is used for analyzing node attributes and judging whether the node has sub-attributes;

The analysis unit is used to analyze the value method of the sub-attribute when judging that the node has a sub-attribute;

A format determination unit is used to combine the analyzed semantic unit, value acquisition method, and node attributes to determine the format definition;

The first storage unit is configured to use the format definition configuration file related to the operator's identifier to store the format definition of the bill file of the corresponding operator.

In the processing system of the self-defined format flat call list file of the present invention, the rule definition module includes:

The second decomposing unit is used to decompose the semantic unit into multiple nodes;

The fourth judging unit is used to analyze the verification attribute of each node, and judge whether the verification attribute is built in the pre-stored verification attribute system;

The third definition unit is used to define a new check attribute when it is judged that the check attribute is not built into the pre-stored check attribute system;

a rule determination unit, configured to combine the analyzed verification attributes to determine a rule definition for node verification;

The second storage unit is configured to use the rule definition configuration file related to the identifier of the operator to store the rule definition for node verification of the corresponding operator.

In the processing system of the self-defined format planar call list file of the present invention, the verification attributes pre-stored in the verification attribute system include: node name, existence attribute, existence condition, data type, data length, effective value , There are attribute error codes and illegal value error codes.

Implement the technical scheme of the present invention, by abstracting the format of the planar call list file of self-defined format and the rule of node verification, make it componentized, configurable, so the versatility is high, for the non-special call list file, only It is necessary to use simple format definition and rule definition, and then call the format definition and rule definition of the corresponding operator to complete the codec and verification; secondly, the scalability is good, even if there is a new format or checkpoint, only the corresponding Deriving and implementing new formats and checkpoints does not require too much cost; again, the performance is good, because there is no similar conversion work compared to the existing solutions for directly operating bill files. It improves the system processing capability; finally, it is reusable, and each format and rule can be deposited as an infrastructure, and finally has a large number of components. When processing new types of bill files, these components can be easily assembled. Efficiently done.

Description of drawings

The present invention will be further described below in conjunction with accompanying drawing and embodiment, in the accompanying drawing:

Fig. 1 is the flow chart of embodiment one of the processing method embodiment of self-defined format planar bill file of the present invention;

Fig. 2 is the flowchart of the preferred embodiment of step S10 in Fig. 1;

Fig. 3 is the flowchart of the preferred embodiment of step S20 in Fig. 1;

Fig. 4 is a structure diagram of a self-defined plane bill file;

Fig. 5 is a relation diagram of codec classes of the present invention;

Fig. 6 is the relation diagram of bill format class of the present invention;

Fig. 7 is a relational diagram of verification rules of the present invention;

Fig. 8 is a semantic unit class relationship diagram of the present invention;

Fig. 9 is a relation diagram between bill file and other work classes of the present invention;

Fig. 10 is the internal structure diagram of the bill format (Schema) object of the present invention;

Fig. 11 is a diagram of the internal structure of the verification rule object of the present invention;

Fig. 12 is the logic diagram of embodiment one of the processing system of the self-defined format planar bill file of the present invention;

Fig. 13 is a logic diagram of a preferred embodiment of the format definition module in Fig. 12;

FIG. 14 is a logic diagram of a preferred embodiment of the rule definition module in FIG. 12 .

Detailed ways

The first thing to explain is that the standard TAP bill file stores the roaming detailed bill information after ASN encoding into binary, and the non-TAP bill file usually adopts a flat file format in order to reduce complexity. It is different, or because of the addition of some personalized information, or because of the reprocessing of the dialogue record file, these non-standard flat record file formats and checkpoints are various.

For non-standard flat CDR files, the basic format usually has the following types:

1) Symbol-separated type. Such as comma-separated files, also known as CSV format, or slash-separated, such as AAA/BBB/CCC similar format bill records, the data field between each two separators is called a node;

2) Fixed-length split type. Get node value by length. If there is ABCDEFG, it is stipulated that the starting position of the first node is 1, the length is 2, the starting position of the second node is 3, and the length is 5. Then the value of the first node is AB, and the second node The value of CDEFG;

In fact, the complexity of the non-standard planar CDR format is mainly reflected in the following aspects:

1) There is additional information in the bill file. For example, some operators’ bills contain header file-level information or tail audit information, or contain multiple additional information. For additional information, the amount of information and verification methods are also different;

2) The same bill adopts mixed formats. The additional information at the beginning and end of a bill file and the bill may be in different formats, for example, the format of the additional information is a fixed-length split type, and the detailed bill record is a symbol-separated type;

3) The definition of the detailed single node is inconsistent. In the bill file, a voice bill and a GPRS bill, due to the difference in the information to be described, the number of nodes and semantics are usually inconsistent;

4) The node also has sub-attributes. The nodes in the CDR file may also consist of multiple sub-attributes, and some sub-attributes may also be optional attributes;

There are many other features in the format of the non-standard planar bill, and more new features will appear as time goes by.

When the clearing center processes bills, the primary operation is to analyze the information of each node describing a detailed bill, such as IMSI (International Mobile Subscriber Identity, International Mobile Subscriber Identity), call start time, duration, etc. This process is called decoding. Similarly, the process of organizing these node information and outputting them to a file in a certain format is called encoding. When encoding and decoding the bill file, the format of the bill file must be known for sure.

To clearly describe a detailed list record, some nodes in the detailed list must exist, some nodes are optional, and some appear conditionally. At the same time, since each node has its own independent meaning, its value range is also required to meet certain constraints. How to judge whether a detailed list is valid, and whether each node is valid, is done through verification. Different nodes have different verification rules. For a specific node, the possible verification points include existence, data type, length, effective value, etc. There are also interdependence between some nodes. The verification result needs to be clearly displayed, such as the node does not exist, the value field is invalid, etc.

The patent of the present invention provides the following processing scheme for the planar bill file with the above-mentioned complex features. As shown in Figure 1, in the flow chart of embodiment one of the processing method embodiment 1 of the self-defined format plane bill file of the present invention, the processing method includes:

S10. Abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the operator's identification to store the format definition of the bill file of the corresponding operator;

S20. Abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the operator's identification to store the corresponding operator's node verification rule definition;

S30. Create the corresponding bill file object according to the acquired current bill file, and load the format definition and rules from the corresponding format definition configuration file and the corresponding rule definition configuration file according to the operator of the current bill file definition, and then call the format definition and rule definition, and set the format and verification rules for the current bill file object, and perform encoding, decoding and verification on the current bill file object.

Fig. 2 is the flow chart of the preferred embodiment of step S10 in Fig. 1, and step S10 includes steps S11～S20, it should be noted that steps S11～S20 only show the format definition step of a bill file of an operator, it should be understood that, The steps for defining the format of the bill file of other operators are similar and will not be repeated here. Steps S11-S20 are specifically described below:

S11. Obtain the bill file provided by the operator;

S12. Decomposing the bill file into multiple semantic units;

S13. Determine whether each semantic unit is built in the pre-stored semantic unit system one by one, if so, then perform step S14; if not, then perform step S18;

S18. Define a new semantic unit, and then perform step S14;

S14. Determine whether the value-taking method of each node is built in the pre-stored value-taking method system one by one, if so, then proceed to step S15; if not, then perform step S19;

S19. Define a new value acquisition method;

S15. Analyze the node attributes, and judge whether the node has sub-attributes, if not, then perform step S16; if so, then perform step S20;

S20. Analyzing the value-taking mode of the sub-attribute, and then performing step S16;

S16. Combining the analyzed semantic unit, value acquisition method, and node attribute to determine the format definition;

S17. Use the format definition configuration file related to the operator's identifier to store the format definition of the bill file of the corresponding operator.

Fig. 3 is a flow chart of a preferred embodiment of step S20 in Fig. 1, step S20 includes steps S21-S25, it should be noted that steps S21-S25 only show the rule definition steps of one operator's node verification, it should be understood , the rule definition steps for node verification of other operators are similar to it and will not be repeated here. Steps S21-S25 are specifically described below:

S21. Decomposing the semantic unit into multiple nodes;

S22. Analyze the verification attribute of each node, and judge whether the verification attribute is built in the pre-stored verification attribute system, if so, execute step S23; if not, execute step S25;

S25. Define a new verification attribute, and then perform step S23;

S23. Combining the analyzed verification attributes to determine a rule definition for node verification;

S24. Use the rule definition configuration file related to the operator's identifier to store the corresponding operator's node verification rule definition.

The following describes in detail the processing method of the flat CDR file in the custom format:

1) The format definition of the abstract bill file, using the configuration file to define the bill format.

Although the format of the call list file is ever-changing, the most basic value format is the symbol-separated type and the fixed-length segmented type mentioned above. A complex bill file usually means that different semantic units adopt different value formats, and the bill file contains multiple semantic units. If these features are separated, the format of a bill file can be described by the following features:

话单文件是否存在附加信息？都有哪些附加信息？

Is there additional information in the CDR file? What additional information is there?

Is the value method of the additional information symbol-separated, fixed-length-separated, or other undefined special value methods?

详单格式有几种类型？其格式分别是什么？是符号分隔型还是定长分割型，还是其它特殊取值方式？

How many types of detailed list formats are there? What are its formats? Is it a symbol-separated type, a fixed-length split type, or other special values?

各节点有子属性吗？子属性是符号分隔型还是定长分割型，还是其它特殊取值方式？

Does each node have sub-properties? Is the sub-attribute symbol-separated, fixed-length-separated, or other special values?

This patent solution divides the format definition of the call list file into three factors after analyzing the above features, and in conjunction with the format of the call list file described in Figure 4, the specific description is as follows:

● Semantic unit. The semantic unit represents a specific information unit in the CDR, where the semantic unit is at a higher level and does not involve specific node information. Semantic units in the bill file include head node (HEADER), tail node (TRAILER), detailed list (CDR) and so on. This scheme defines the basic semantic unit, and it is agreed that as long as the semantic unit definition appears, it means that the semantic unit exists, otherwise it means that it does not exist. If the semantic unit system required by the user is not built into the pre-stored semantic unit system, a new semantic unit can also be defined.

●Value method. The value method indicates how to obtain the value of a node from a record, including DELIMITED and FIXEDLENGTH. For the symbol-separated type, you only need to define the delimiter, such as DELIMITED (,) for comma separation; for the fixed-length delimited type, you need to define the length of each node, such as FIXEDLENGTH (1, 5, 9) for the first node length 1, the second node length 5, and so on. Of course, users can also expand the definition of new value methods.

● Node attributes. The node attribute mainly indicates whether the node has sub-attributes, and if it has sub-attributes, it is also necessary to define the value method of the sub-attributes (SUBFMT). For the sake of simplicity, it is agreed that as long as the syntax unit has a SUBFMT definition, it means that it has sub-attributes.

For the above three factors, this solution configures these factors to achieve the purpose of using these factor units to configure the bill file format, so as to decompose the complex format and finally unify it. A typical CDR format configuration is as follows:

[HEADER]

FMT=DELIMITED(,)

SUBFMT=FIXLENGTH(3,5,9)

[CDR]

FMT=FIXEDLENGTH(2, 4, 6, 4, 5, 8, 8)

SUBFMT=DELIMITED(/)

[TRAILER]

FMT=FIXLENGTH(3,5)

2) Abstract node verification rules, use configuration files to define node verification rules.

With the format definition of the CDR, the information in it can be parsed into each semantic unit, and then each node can be parsed out, that is, the decoding process. As for whether the corresponding node exists and whether the value range of the node is correct, it depends on the verification to complete the analysis. To provide the verification of the node, you need to know the detailed characteristics of the node. In this scheme, its characteristics are represented by attributes, and each attribute is abstracted as follows :

●Node name (NAME)

Existence attribute (EXIST_TYPE, refer to the TAP standard, take the value M/C/O, respectively represent Mandatory/Conditional/Optional, if it is type C, you must specify the existence condition)

●Existence condition (EXIST_CONDITION, is a function name, when the function call returns successfully, the node must exist)

●Data type (DATA_TYPE, divided into string, number, datetime)

●Data length (DATA_LENGTH, when the data type is string, the specified data length is optional)

●Valid values (LEGAL_VALUE, the corresponding interval value and enumeration type value are listed here, the interval is represented by "-", the enumeration value is separated by comma, empty means no limit)

●Exist attribute error code (EXIST_ERR_CODE, node does not exist error code)

●Illegal value error code (VALUE_ERR_CODE, illegal value error code) Using the above node attributes, you can basically determine the verification rules of a node. If the above defined attributes cannot satisfy the verification of some nodes, users can define new ones by themselves Attributes.

To complete the definition of verification rules for a bill file, it is first necessary to define the nodes and order contained in each semantic unit of the bill file, where the semantic units need to be consistent with the semantic units in the format definition; and then define each Validation rules for nodes. In fact, it is common to combine format definitions and rule definitions in the same configuration file. A typical bill file verification rule is defined as follows:

[HEADER]

NODE=1, 2, 3

[CDR]

NODE=4, 5, 6, 7

[TRAIIER]

NODE=8,9

[1]

NAME=MSC_TYPE

EXIST_TYPE=M

DATA_TYPE=NUMBER

LEGAL_VALUE=1-5, 11, 12, 13

EXIST_ERROR_CODE = 10

FORMAT_ERROR_CODE = 20

VALUE_ERROR_CODE=30

EXIST_CONDITION=

[2]

TAG_NAME=CDR_ID

EXIST_TYPE=C

DATA_TYPE=STRING

DATA_LENGTH=16

EXIST_ERROR_CODE=11

FORMAT_ERROR_CODE = 21

VALUE_ERROR_CODE=31

EXIST_CONDITION=VALCDRIDEXIST

3) Provide a codec and verification service framework, which can not only be compatible with known formats and verification rules, but also support new types of bills in the case of low-cost expansion, and process the obtained current bill files.

On the basis of abstracting the format definition and verification rules, this solution provides a codec and verification service framework. The framework is implemented in C++ language, which not only naturally supports predefined formats and verification rules, but also has flexible expansion capabilities. The service framework of this solution mainly includes the following work objects:

● codec (Codec). For the definition of two basic value methods, symbol-separated type and fixed-length separated type, implement them as DelimitCodec and FixedLengthCodec, combined with the codec class diagram shown in Figure 5, both of which are derived from the abstract base class Codec Come, with Decode () and Encode () methods.

● Bill format (Schema). This object is used to describe the semantic unit contained in the CDR and its format definition.

● format definition loader (SchemaLoader). Combined with the bill format class diagram shown in Figure 6, when the format of the bill is defined, the object is responsible for loading the format information from the format definition configuration file. After the loading is completed, the interface GetSchema() is provided to allow the user to obtain the bill format object .

● Check the rule unit (RuleUnit). The verification rule unit is a class of objects, and each verification entry in the rule definition, such as EXIST_TYPE or DATA_TYPE, corresponds to a verification rule unit object. This type of object is derived from the base class Rule, and provides the Validate() method to verify whether the rule entry passes the validation.

● Node verification rules (ValRule). This object defines the validation rules of a node, usually contains multiple validation rule units, and provides the Validate() method.

● Validation rule loader (RuleLoader). Combined with the verification rule class relationship diagram shown in Figure 7, when the node verification rules are defined, the object is responsible for loading the rule information from the verification rule file. After the loading is completed, the interface GetCompList() and GetCompRule() are provided for the user Get a list of nodes and their validation rules.

● Semantic unit (Component). Combined with the semantic unit class relationship diagram shown in Figure 8, a semantic unit is a general term for a class of objects, which are all derived from the abstract base class of Component, mainly including fields (Field), nodes (Node), records (Record) . Field represents a node without sub-properties, and Node represents a node with sub-properties. The semantic units defined above are all derived from the Record object, including the head node (Header), tail node (Trailer), and detail list (Cdr).

● bill file (CDFile). Combined with the relationship diagram between the call list file and other work classes shown in Figure 9, the call list file object is the final work object, and it uses the combination of the work objects mentioned above to complete the Encode (), Decode () and Validate of the dialogue list ().

In the case where the format definition file and verification rule definition file already exist, the core operation process of this service framework is as follows:

1. Create a format definition loader object, which obtains the semantic units existing in the current bill file from the format definition configuration file, the value acquisition method of each semantic unit, and whether the node has sub-attributes and the value acquisition method, Then these information are stored in the Schema object, as shown in Figure 10, the internal structure diagram of the Schema object, a Schema object includes all the format information of a class of bill files;

2. Create a verification rule loader object, combined with the internal structure diagram of the verification rule object shown in Figure 11, this object obtains the nodes contained in each semantic unit and the verification rules of each node from the rule definition configuration file, It stores each semantic unit, the nodes contained in each semantic unit, and the verification rules of each node.

3. Create a bill file object. When creating a bill file object, you must use the SetSchema() method and the SetRule() method to specify the format and verification rules, and you need to specify the bill file path. This object calls the format definition loader and verification rule loader to obtain the semantic units existing in the bill, the nodes contained in each semantic unit, and the verification rules of each node, by calling Decode(), Encode() and Validate( ) method to complete the codec and verification of the entire file.

Based on the above solution, we can implement the following processing steps when processing the custom format flat CDR file:

1. Define the file format. First analyze the semantic unit, and then analyze the value-taking method of each semantic unit, and at the same time confirm whether the node has sub-attributes and the value-taking method of the sub-attributes. Then define it in the configuration file. When a new semantic unit appears, the user can also customize the new semantic unit, and only needs to derive the semantic unit from the Record class during implementation and implement its corresponding interface. In the same way, when a new value method appears, it is only necessary to derive a new codec from the codec Codec.

2. Define the verification rules. According to the semantic units in the format definition, respectively determine the nodes contained in each semantic unit and their sequence, and then display the verification attributes of each node according to the business rules. If it is necessary to add a new constraint to a certain node, the user can also customize a new property, which only needs to be derived from the RuleUnit object and implement the corresponding interface during implementation.

3. Create a bill file object. After the above two steps are completed, you can create the bill file object CDFile, set the format Schema and verification rule Rule, and then call its corresponding method to complete encoding, decoding and verification. The typical workflow is as follows:

Fig. 12 is the logic diagram of embodiment one of the processing system of the self-defined format planar bill file of the present invention, and this processing system comprises format definition module 10, rule definition module 20 and processing module 30 connected in sequence, wherein, format definition module 10 uses The purpose is to abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the identity of the operator to store the format definition of the bill file of the corresponding operator; the rule The definition module 20 is used to abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the operator's identification to store the corresponding operator's node The rule definition of verification; processing module 30 is used for creating corresponding bill file object according to the current bill file obtained, and according to the operator of described current bill file, defines configuration file and corresponding rule from corresponding format respectively Load the format definition and rule definition in the definition configuration file, then call the format definition and rule definition, set the format and check rules for the current bill file object, and encode and decode the current bill file object and checksum.

Fig. 13 is a logic diagram of a preferred embodiment of the format definition module in Fig. 12, and the format definition module includes an acquisition unit 11, a first decomposing unit 12, a first judging unit 13, a first defining unit 14, a second judging unit 15, a first judging unit 15, A second definition unit 16 , a third judgment unit 17 , a sub-attribute analysis unit 18 , a format determination unit 19 and a first storage unit 20 . Wherein, the acquisition unit 11 is used to obtain the bill file provided by the operator; the first decomposition unit 12 is used to decompose the bill file into a plurality of semantic units; the first judging unit 13 is used to judge whether each semantic unit is built-in In the pre-stored semantic unit system; the first definition unit 14 is used to define a new semantic unit when judging that the phonetic unit is not built into the pre-stored semantic unit system; the second judging unit 15 is used to judge each Whether the value-taking method of the node is built in the pre-stored value-taking method system; the second definition unit 16 is used to define a new value-taking method when judging that the value-taking method of the node is not built in the pre-stored value-taking method system The third judging unit 17 is used to analyze the node attribute, and judges whether the node possesses the sub-attribute; the sub-attribute analyzing unit 18 is used to analyze the value-taking mode of the sub-attribute when judging that the node possesses the sub-attribute; the format determination unit 19 is used to use The analyzed semantic unit, value mode, and node attribute combination are used to determine the format definition; the first storage unit 20 is used to use the format definition configuration file related to the operator's identification to store the format definition of the corresponding operator's bill file

FIG. 14 is a logic diagram of a preferred embodiment of the rule definition module in FIG. 12 . The rule definition module includes: a second decomposition unit 21 , a fourth judgment unit 22 , a third definition unit 23 , a rule determination unit 24 and a second storage unit 25 . Wherein, the second decomposition unit 21 is used to decompose the semantic unit into a plurality of nodes; the fourth judging unit 22 is used to analyze the check attribute of each node, and judge whether the check attribute is built into the pre-stored check attribute In the system; the third definition unit 23 is used to define a new check attribute when it is judged that the check attribute is not built into the pre-stored check attribute system; the rule determination unit 24 is used to use the analyzed check attribute combined to determine the rule definition for node verification; the second storage unit 25 is used to use the rule definition configuration file related to the operator's identification to store the rule definition of the corresponding operator's bill file.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the scope of the claims of the present invention.

Claims (8)

1. A processing method of a self-defined format plane call list file, characterized in that, comprising: S10. Abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the operator's identification to store the format definition of the bill file of the corresponding operator; S20. Abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the operator's identification to store the corresponding operator's node verification rule definition; S30. Create the corresponding bill file object according to the acquired current bill file, and load the format definition and rules from the corresponding format definition configuration file and the corresponding rule definition configuration file according to the operator of the current bill file definition, and then call the format definition and rule definition, and set the format and verification rules for the current bill file object, and perform encoding, decoding and verification on the current bill file object. 2. the processing method of self-defined format plane bill file according to claim 1 is characterized in that, in step S10, abstracts the format definition of bill file from the format information of bill file that operator provides, and The steps of using the format definition configuration file related to the operator's identification to store the format definition of the corresponding operator's bill file specifically include: S11. Obtain the bill file provided by the operator; S12. Decomposing the bill file into multiple semantic units; S13. Determine whether each semantic unit is built in the pre-stored semantic unit system one by one, if so, then proceed to step S14; if not, then define a new semantic unit, then perform step S14; S14. Determine whether the value-taking method of each node is built in the pre-stored value-taking method system one by one, if so, proceed to step S15; if not, define a new value-taking method; S15. Analyze the node attributes, and judge whether the node has sub-attributes, if not, then perform step S16; if so, analyze the value-taking method of the sub-attributes, and then perform step S16; S16. Combining the analyzed semantic unit, value acquisition method, and node attribute to determine the format definition; S17. Use the format definition configuration file related to the operator's identifier to store the format definition of the bill file of the corresponding operator. 3. the processing method of self-defined format plane bill file according to claim 2, is characterized in that, in described step S20, abstracts the rule of node verification from the rule information of node verification that operator provides Define, and use the rule definition configuration file related to the operator's identification to store the corresponding operator's node check rule definition steps include: S21. Decomposing the semantic unit into multiple nodes; S22. Analyze the verification attribute of each node, and judge whether the verification attribute is built in the pre-stored verification attribute system, if so, execute step S23; if not, define a new verification attribute, and then execute Step S23; S23. Combining the analyzed verification attributes to determine a rule definition for node verification; S24. Use the rule definition configuration file related to the operator's identifier to store the corresponding operator's node verification rule definition. 4. the processing method of self-defining format plane bill file according to claim 3, is characterized in that, the verification attribute that is stored in the verification attribute system in advance comprises: node name, existence attribute, existence condition, data type, Data length, valid value, exist attribute error code, illegal value error code. 5. A processing system for a self-defined format plane call list file, characterized in that it comprises: The format definition module is used to abstract the format definition of the bill file from the format information of the bill file provided by different operators, and use the format definition configuration file related to the identity of the operator to store the bill file of the corresponding operator format definition; The rule definition module is used to abstract the rule definition of node verification from the rule information of bill node verification provided by different operators, and use the rule definition configuration file related to the identity of the operator to store the corresponding operator's Rule definition for node verification; A processing module, configured to create a corresponding bill file object according to the acquired current bill file, and load the format from the corresponding format definition configuration file and the corresponding rule definition configuration file according to the operator of the current bill file definition and rule definition, and then call the format definition and rule definition, and set the format and verification rules for the current bill file object, and perform encoding, decoding and verification on the current bill file object. 6. the processing system of self-defined format plane bill file according to claim 5, is characterized in that, described format definition module comprises: an acquisition unit, configured to acquire the bill file provided by the operator; The first decomposing unit is used to decompose the bill file into multiple semantic units; The first judging unit is used to judge whether each semantic unit is built in the pre-stored semantic unit system one by one; The first definition unit is used to define a new semantic unit when judging that the semantic unit is not built into the pre-stored semantic unit system; The second judging unit is used to judge one by one whether the value-taking method of each node is built in the pre-stored value-taking method system; The second definition unit is used to define a new value-taking method when it is judged that the value-taking method of the node is not built into the pre-stored value-taking method system; The third judging unit is used for analyzing node attributes and judging whether the node has sub-attributes; The sub-attribute analysis unit is used to analyze the value-taking mode of the sub-attribute when judging that the node has a sub-attribute; A format determination unit is used to combine the analyzed semantic unit, value acquisition method, and node attributes to determine the format definition; The first storage unit is configured to use the format definition configuration file related to the operator's identifier to store the format definition of the bill file of the corresponding operator. 7. the processing system of self-defined format plane bill file according to claim 6, is characterized in that, described rule definition module comprises: The second decomposing unit is used to decompose the semantic unit into multiple nodes; The fourth judging unit is used to analyze the verification attribute of each node, and judge whether the verification attribute is built in the pre-stored verification attribute system; The third definition unit is used to define a new check attribute when it is judged that the check attribute is not built into the pre-stored check attribute system; a rule determination unit, configured to combine the analyzed verification attributes to determine a rule definition for node verification; The second storage unit is configured to use the rule definition configuration file related to the identifier of the operator to store the rule definition for node verification of the corresponding operator. 8. the processing system of self-defining format plane bill file according to claim 7, it is characterized in that, the checking attribute stored in the checking attribute system in advance comprises: node name, existence attribute, existence condition, data type, Data length, valid value, exist attribute error code, illegal value error code.

Images