Call record charging method and device, electronic equipment and storage medium

Abstract

This application relates to the field of business support, providing a call detail record (CDR) billing method, apparatus, electronic device, and storage medium. It includes: obtaining CDRs to be processed from a data source or middleware based on an integrated mode component, wherein the middleware includes one or more of message queues, databases, and file systems; and performing streaming processing on the CDRs to be processed to obtain target CDRs. This application interfaces with various middleware such as data sources, message queues, databases, and file systems through an integrated mode component, enabling the acquisition and streaming processing of CDRs to be processed from data sources or middleware. Because it interfaces with multiple external middleware, the streaming billing mode is not limited by message queues, avoiding message loss in the message queue due to power outages in the data center, thus improving processing performance and consequently increasing CDR billing efficiency.

Description

Technical Field

[0001] This application relates to the field of business support, specifically to a call detail record (CDR) billing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Billing and pricing are a crucial and indispensable part of a carrier's business support system. The accuracy and performance of call detail record (CDR) billing and pricing directly affect the robustness and stability of a business support system. In particular, the billing performance of offline CDRs is related to the risk control of high outstanding charges. Currently, CDR billing systems are basically complete billing systems developed by individual integrators, typically employing a streaming billing model. This means that the collection program collects offline CDR files from a remote location and processes them into messages in a message queue (MQ). Subsequent billing processes consume messages from the MQ's topic queue and write them to the topic queue of the next process, until the final billing process ends and the data is stored in a database or file.

[0003] However, current streaming billing relies on a message queue (MQ), which stores messages in memory. If the data center loses power, these messages are lost. In actual production environments, message loss may be unacceptable for certain core billing functions. In such cases, choosing a synchronous persistence solution for real-time disk flushing would actually worsen processing performance, leading to low call detail record (CDR) billing efficiency. Summary of the Invention

[0004] This application provides a call detail record (CDR) billing method, apparatus, electronic device, and storage medium to solve the problem that current streaming billing relies on a message queue (MQ) as its core, which leads to message loss in the message queue when the data center loses power, resulting in low CDR billing efficiency.

[0005] In a first aspect, embodiments of this application provide a call detail record (CDR) billing method, including:

[0006] The component in the integrated mode obtains the call detail records to be processed from the data source or middleware, wherein the middleware includes one or more of message queues, databases, and file systems;

[0007] The call detail records (CDRs) to be processed are streamed to obtain the target CDR.

[0008] In one embodiment, the step of performing streaming processing on the call detail record (CDR) to be processed to obtain the target CDR includes:

[0009] The call detail records (CDRs) to be processed are converted into data to obtain the CDR message body;

[0010] The call detail record (CDR) message body is transmitted to the message node through the message pipeline;

[0011] The target call detail record (CDR) is obtained by consuming the CDR message body based on the message node.

[0012] In one embodiment, the consumption includes one or more of the following: collection, decoding, analysis, and billing.

[0013] In one embodiment, consuming the call detail record (CDR) message body based on the message node to obtain the target CDR includes:

[0014] Billing is performed on the call detail record (CDR) message body based on the message node to obtain the target CDR.

[0015] In one embodiment, the step of consuming the call detail record (CDR) message body based on the message node to obtain the target CDR further includes:

[0016] Based on the message node, the call detail record (CDR) message body is collected, decoded, analyzed, and billed to obtain the target CDR.

[0017] In one embodiment, the step of performing data transformation on the call detail record (CDR) to be processed to obtain the CDR message body includes:

[0018] The call detail record (CDR) to be processed is formatted to obtain the CDR message body.

[0019] Secondly, embodiments of this application provide a call detail record (CDR) billing device, comprising:

[0020] The acquisition module is used to acquire pending call detail records (CDRs) from a data source or middleware based on an integrated mode component. The middleware includes one or more of message queues, databases, and file systems.

[0021] The streaming processing module is used to stream process the call detail records (CDRs) to be processed to obtain the target CDR.

[0022] In one embodiment, the streaming processing module is further configured to:

[0023] The call detail records (CDRs) to be processed are converted into data to obtain the CDR message body;

[0024] The call detail record (CDR) message body is transmitted to the message node through the message pipeline;

[0025] The target call detail record (CDR) is obtained by consuming the CDR message body based on the message node.

[0026] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the call detail record (CDR) billing method described in the first or second aspect.

[0027] Fourthly, embodiments of this application provide a storage medium, which is a computer-readable storage medium including a computer program. When the computer program is executed by a processor, it implements the steps of the call detail record (CDR) billing method described in the first or second aspect.

[0028] The call detail record (CDR) billing method, apparatus, electronic device, and storage medium provided in this application embodiment interface with various middleware such as data sources, message queues, databases, and file systems through an integrated mode component. It can obtain CDRs to be processed from the data source or middleware and perform streaming processing. Because it interfaces with multiple external middleware, the streaming billing mode is not limited by the message queue, avoiding the loss of messages in the message queue due to power failure in the data center, which can improve processing performance and thus improve CDR billing efficiency. Attached Figure Description

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

[0030] Figure 1 This is one of the flowcharts illustrating the call detail record (CDR) billing method provided in the embodiments of this application;

[0031] Figure 2 This is the second flowchart illustrating the call detail record (CDR) billing method provided in the embodiments of this application;

[0032] Figure 3 This is one of the scenario diagrams illustrating the call detail record (CDR) billing method provided in the embodiments of this application;

[0033] Figure 4 This is a second scenario illustration of the call detail record (CDR) billing method provided in the embodiments of this application;

[0034] Figure 5 This is a functional module diagram of an embodiment of the call detail record (CDR) billing device of this application;

[0035] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. 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.

[0037] Currently, the basic billing process for most offline call detail records (CDRs) of telecom operators is as follows: CDRs are collected from remote locations (such as SFTP, FTP, filesystem, etc.) and stored locally; after decoding and processing, they are placed into middleware (such as databases, message queues, file systems, and some in-memory databases such as MongoDB, Redis, MDB, etc.) for subsequent billing processing; CDRs are retrieved from the middleware for billing batching and aggregation, and finally stored in the database. MDB is a relational database, MongoDB is a database based on distributed file storage, and Redis (Remote Dictionary Server) is an open-source, ANSI C-language-written, network-enabled, in-memory or persistent log-structured key-value database that provides APIs for multiple languages.

[0038] Currently, call detail record (CDR) billing systems are mostly self-developed billing systems by individual integrators, typically employing a streaming billing model. This involves the collection program gathering offline CDR files from a remote location and processing them into message queues (MQ). Subsequent billing processes consume messages from the MQ's topic queues and write them to the next process's topic queue until the final billing process concludes, at which point the data is stored in a database or file. Compared to the more primitive method of storing intermediate CDRs in files, this billing scheme reduces disk I / O in the billing process. CDRs are only written to disk once at the beginning (for backup) and once at the end (for final billing), with all other intermediate processes running within the MQ middleware (i.e., in memory), reducing I / O overhead and improving billing performance.

[0039] Current streaming billing relies on a message queue (MQ), which stores messages in memory. A power outage in the data center results in message loss. Therefore, the system's message queue must be equipped with a corresponding persistence solution, typically an asynchronous one, to minimize the impact of power outages while maintaining streaming billing processing performance. Depending on the persistence solution, machine performance, and processing speed, data loss can occur in the range of 0.001s to 0.1s.

[0040] However, in actual production operations, message loss may not be tolerable for certain core billing functions. In such cases, choosing a synchronous persistence solution with real-time disk flushing can actually worsen performance because it requires processing both in-memory and I / O data simultaneously. Furthermore, some provincial branches or edge businesses may lack the expertise or hardware to maintain high-performance, highly reliable message queues (MQ), necessitating the use of more suitable middleware such as MySQL or file systems instead of streaming computing frameworks. Since the billing system is tied to the MQ's billing model, the system must be rebuilt, resulting in significant engineering costs.

[0041] This results in current streaming billing having problems such as the need to use MQ queues, excessive coupling between the application system and middleware, and inability to handle data loss during power outages.

[0042] The following describes in detail the call detail record (CDR) billing method, apparatus, electronic device, and storage medium provided by the present invention with reference to embodiments.

[0043] Figure 1 This is one of the flowcharts illustrating the call detail record (CDR) billing method provided in this application. (Refer to...) Figure 1 This application provides a call detail record (CDR) billing method, which may include:

[0044] Step S100: Obtain the call detail records to be processed from the data source or middleware based on the integrated mode component. The middleware includes one or more of message queues, databases, and file systems.

[0045] It should be noted that the execution subject of the call detail record (CDR) billing method provided in this application embodiment can be a computer device, such as a mobile phone, tablet computer, laptop computer, handheld computer, vehicle electronic device, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0046] It should be noted that the computer equipment may include an integrated mode component and a billing system, and the integrated mode component can be applied to the billing system. The billing system may include a data acquisition program or application, a decoding program or application, an analysis program or application, a billing program or application, etc. Therefore, the integrated mode component can be applied to the data acquisition program or application, the decoding program or application, the analysis program or application, the billing program or application, etc., respectively.

[0047] In this embodiment, the integration pattern component can be a Spring Integration component, which can be abbreviated as SI component. Spring Integration is a powerful EIP (Enterprise Integration Patterns) that provides a convenient event-driven messaging framework for message passing between systems.

[0048] It's worth noting that Spring Integration primarily consists of a Message body, a Message Channel, and a Message Endpoint. A Message comprises a header and a payload. The header stores transmission parameters, while the payload stores the actual data to be transmitted. The Message Channel handles data transmission. The Message Endpoint consumes call detail records (CDRs).

[0049] In this embodiment, the Spring Integration component can interface with a data source and / or middleware to retrieve call detail records (CDRs) and perform corresponding processing. The data source can be an external data system, such as a base station or customer data system. The middleware can include one or more of message queues, databases, and file systems; for example, it can be a message queue, a database, and a file system, or a combination of both. In this embodiment, the interface can be configured according to actual needs. Furthermore, the database can be MySQL, Redis, MongoDB, etc.

[0050] Call detail records (CDRs) pending processing are CDRs that have not yet been billed. These can be initial CDRs, partially billed CDRs, or CDRs that have been collected and decoded, etc.

[0051] Specifically, in this embodiment, the integration mode component can be used to connect with the data source or middleware to obtain unprocessed call detail records (CDRs) from the data source as CDRs to be processed, or intermediate CDRs can be obtained from the message queue / table / key of the middleware as CDRs to be processed, so as to process or further process the CDRs to be processed, and finally complete the billing of the CDR.

[0052] By integrating various middleware through integrated mode components, the streaming billing mode is not limited by message queues, avoiding the loss of messages in the message queue due to power outages in the data center. This can improve processing performance and thus improve call detail record (CDR) billing efficiency.

[0053] Step S200: Perform streaming processing on the call detail records to be processed to obtain the target call detail records.

[0054] This embodiment can convert the call detail records (CDRs) to be processed into an internal message body after acquisition, and then perform streaming processing with message nodes through a message channel. Streaming processing assumes that the potential value of the data lies in its freshness, requiring rapid processing to obtain results. In this approach, data arrives as a stream. During the continuous arrival of data, because the stream carries a large amount of data, only a small portion of the stream data is stored in limited memory.

[0055] It should be noted that the target call detail record (CDR) can be the final billed CDR, or it can be an intermediate CDR such as the CDR after data collection, the CDR after decoding, or the CDR after analysis.

[0056] It should be noted that if the target call detail record (CDR) is the CDR after billing is completed, the target CDR can be stored locally, for example, in a database used to store the final CDR.

[0057] If the target call detail record (CDR) is an intermediate CDR, it can be stored in the middleware as a message queue / table / key, so that further processing can be performed based on the CDR in the middleware until billing is finally completed, and the billed CDR can be stored on the ground.

[0058] By converting pending call detail records (CDRs) into internal message bodies and processing them in a streaming manner through message channels and message nodes, CDRs are also processed in a streaming manner within the billing process. This ensures that there are no interruptions in the CDR processing and improves processing efficiency.

[0059] The call detail record (CDR) billing method provided in this application integrates a mode component with various middleware such as data sources, message queues, databases, and file systems. It can obtain CDRs to be processed from the data source or middleware and consume them. Because it integrates with multiple external middleware, the streaming billing mode is not limited by the message queue, avoiding the loss of messages in the message queue due to power outages in the data center. This can improve processing performance and thus improve CDR billing efficiency.

[0060] Figure 2 This is the second flowchart illustrating the call detail record (CDR) billing method provided in this application. (Refer to...) Figure 2 In one embodiment, streaming processing is performed on the call detail record (CDR) to be processed to obtain the target CDR, including:

[0061] Step S201: Perform data transformation on the call detail records to be processed to obtain the call detail record message body;

[0062] After obtaining the call detail records (CDRs) to be processed, it is necessary to perform data conversion on the CDRs to be processed, transforming them into an internal message body to obtain a CDR message body containing the CDR information.

[0063] The call detail record (CDR) message body consists of two parts: a header and a payload. The header stores attribute parameters from the CDR to be processed, while the payload stores the specific data from the CDR to be processed.

[0064] Further, the call detail records (CDRs) to be processed are transformed to obtain the CDR message body, including:

[0065] Step S2011: Convert the format of the call detail record (CDR) to be processed to obtain the CDR message body.

[0066] In this embodiment, the SI component can be pre-configured with various format conversion rules. Each format conversion rule is used to convert the format of data output from different data sources or middleware, so that the converted call detail record data can be transmitted to the message node for processing through the message channel.

[0067] Therefore, in this embodiment, the format of the call detail record (CDR) to be processed can be determined, and the format conversion rule corresponding to the format of the CDR to be processed can be found from a variety of format conversion rules. The CDR to be processed is converted into a message body according to the found format conversion rule, and can be defined as the CDR message body.

[0068] Step S202: Transmit the call detail record (CDR) message body to the message node through the message pipeline;

[0069] In this embodiment, a MessageChannel can be used to implement streaming processing within the billing system. After data transformation is completed, the call detail record (CDR) message body can be stored through the MessageChannel. Since message nodes can monitor the MessageChannel, when a CDR message body is detected in the MessageChannel, the message node can retrieve the CDR message body from the MessageChannel and consume it.

[0070] Step S203: Consume the message body of the call detail record (CDR) based on the message node to obtain the target CDR.

[0071] When the pending call detail record (CDR) message body is obtained, the message node can consume the CDR message body through transaction control, thereby obtaining the processed CDR as the target CDR after consumption.

[0072] Understandably, when the target CDR is an intermediate CDR, it can be stored in the middleware as a message queue / table / key. This allows for subsequent retrieval of the intermediate CDR from the middleware for further processing, until the entire billing process is completed and the data is stored. When the target CDR is the final CDR after billing is completed, it can be stored directly on the middleware.

[0073] In this embodiment, consumption includes one or more of the following: collection, decoding, analysis, and billing. For example, it can be collection, decoding, analysis, or billing; it can be collection, decoding, analysis, and billing; it can also be collection and decoding, decoding and analysis, analysis and billing, etc. The list is not exhaustive here.

[0074] Furthermore, by consuming the message body of the call detail record (CDR) from the message node, the target CDR is obtained, including:

[0075] Step A involves collecting, decoding, analyzing, and billing the message body of the call detail record (CDR) from the message node to obtain the target CDR.

[0076] In this embodiment, the message node can be pre-configured with rules for data collection, data decoding, call detail record (CDR) data analysis, and CDR billing. Therefore, after the message node obtains the CDR message body, it can collect data from the CDR message body according to the pre-configured data collection rules, decode the collected CDR data using the data decoding rules, further analyze the decoded CDR data using the CDR data analysis rules, and bill the analyzed CDRs using the CDR billing rules, thus completing the CDR billing process. The final billed CDRs can then be stored on the network.

[0077] Furthermore, consuming the message body of the call detail record (CDR) at the message node to obtain the target CDR also includes:

[0078] Step B involves collecting data based on the message body of the call detail record (CDR) from the message node to obtain the target CDR.

[0079] In this embodiment, since the message node can be pre-configured with rules for data collection, after the message node obtains the call detail record (CDR) message body obtained and transformed from the data source, it can collect data from the CDR message body according to the pre-configured data collection rules, and store the collected intermediate CDR as the target CDR in the middleware. This facilitates further processing of the intermediate CDR in the middleware until the billing process of the CDR is completed, and the final billed CDR is then stored.

[0080] Furthermore, consuming the message body of the call detail record (CDR) at the message node to obtain the target CDR also includes:

[0081] Step C: Decode the message body of the call detail record (CDR) based on the message node to obtain the target CDR.

[0082] In this embodiment, since the message node can be pre-configured with rules for data decoding, after the message node obtains the call detail record (CDR) message body obtained and converted from the middleware, it can decode the CDR message body according to the pre-configured data decoding rules and store the decoded intermediate CDR as the target CDR in the middleware. This facilitates further processing of the intermediate CDR in the middleware until the billing process of the CDR is completed, and the final billed CDR is then stored.

[0083] Step C: Analyze the message body of the call detail record (CDR) at the message node to obtain the target CDR.

[0084] In this embodiment, since the message node can be pre-configured with rules for call detail record (CDR) data analysis, after the message node receives the CDR message body obtained and transformed from the middleware, it can perform data analysis on the CDR message body according to the pre-configured CDR data analysis rules, and store the analyzed intermediate CDR as the target CDR in the middleware. This facilitates further processing of the intermediate CDR in the middleware until the CDR billing process is completed, and the final billed CDR is then stored.

[0085] Furthermore, consuming the message body of the call detail record (CDR) at the message node to obtain the target CDR also includes:

[0086] Step D: Billing is performed based on the message body of the call detail record (CDR) at the message node to obtain the target CDR.

[0087] In this embodiment, the message node can be pre-configured with rules for billing call detail records (CDRs). Therefore, after the message node obtains the CDR message body from the intermediate CDR obtained and transformed from the middleware, it can bill the CDR message body according to the pre-configured CDR billing rules, and store the final CDR after billing as the target CDR.

[0088] It should be noted that the billing rules in this embodiment may also include multiple step-by-step billing rules, such as free resource deduction rules, batch price deduction rules, and overall deduction rules. The billing procedure may also include a free resource deduction procedure, a batch price deduction procedure, and an overall deduction procedure.

[0089] For example, in this implementation, after the message node obtains the call detail record (CDR) message body obtained and transformed from the middleware, the free resource deduction procedure can deduct free resources from the CDR message body according to the preset free resource deduction rules, and store the intermediate CDR after free resource deduction as the target CDR in the middleware.

[0090] The batch pricing deduction process further obtains the call detail records (CDRs) after deducting free resources from the middleware as CDRs to be processed. After transforming the CDRs to be processed, they are stored in the message channel. The message node obtains the transformed CDR message body and further deducts the batch pricing from the single message body according to the batch pricing deduction rules. The intermediate CDRs after batch pricing deduction are then stored in the middleware as the target CDRs.

[0091] The overall deduction process further obtains the batch-deducted call detail records (CDRs) from the middleware as CDRs to be processed. After the CDRs to be processed are transformed, they are stored in the message channel. The message node obtains the transformed CDR message body and further deducts the individual message body according to the overall deduction rules. The intermediate CDRs after overall deduction are then stored as the target CDRs.

[0092] In one embodiment of this application, reference is made to Figure 3 , Figure 3 This is one of the scenario diagrams illustrating the call detail record (CDR) billing method provided in the embodiments of this application. Figure 3 In the first billing application, the SI component can obtain billing call detail records (CDRs) as pending CDRs from various upstream middlewares through monitoring and polling. After converting the pending CDRs into Messages, they are stored in MessageChannels. The MessageEndpoint then performs billing processing on the Messages in the MessageChannels, such as deducting free resources. Finally, the processed CDRs are stored in various downstream middlewares.

[0093] The SI component in the second billing application can obtain billing call detail records (CDRs) as pending CDRs from various downstream middleware through monitoring and polling. These pending CDRs are then converted into Messages and stored in MessageChannels. Billing processing, such as batch pricing deductions, is then performed on the Messages in the MessageChannels via MessageEndpoints. The processed CDRs are then stored in various downstream middleware. These upstream and downstream middleware can be message queues, databases, file systems, etc.

[0094] In one embodiment of this application, reference is made to Figure 4 , Figure 4 This is a second schematic diagram illustrating a scenario for the call detail record (CDR) billing method provided in this application. Figure 4In the data acquisition process, the SI component can obtain billing call detail records (CDRs) as pending CDRs from a remote data source. After converting these CDRs into CDR message bodies, they are stored in a message channel (MessageChannel). The message bodies in the message channel are then collected via message nodes (MessageEndpoint). The collected CDRs are then stored in any middleware such as MQ, MySQL, Redis, MongoDB, or filesystems in the form of a queue / table / key.

[0095] Furthermore, the SI component in the decoding program can obtain billing call detail records (CDRs) as pending CDRs from various middleware, convert them into CDR message bodies, store them in the message channel, and decode the CDR message bodies in the message channel through message nodes. The decoded CDRs are then stored in any middleware such as MQ, MySQL, Redis, MongoDB, or FS in the form of queues / tables / keys.

[0096] Furthermore, the SI component in the analysis program can obtain billing call detail records (CDRs) as pending CDRs from various middleware, convert them into CDR message bodies, store them in the message channel, and analyze the CDR message bodies in the message channel through message nodes. The analyzed CDRs are then stored in any middleware such as MQ, MySQL, Redis, MongoDB, or FS in the form of queues / tables / keys.

[0097] Furthermore, the SI component in the first billing procedure can obtain billing call detail records (CDRs) as pending CDRs from various middleware, convert them into CDR message bodies, store them in the message channel, and perform billing on the CDR message bodies in the message channel through message nodes, such as deducting free resources. The CDRs after deducting free resources are stored in any middleware such as MQ, MySQL, Redis, MongoDB, or FS in the form of queues / tables / keys.

[0098] Furthermore, the SI component in the second billing procedure can obtain billing call detail records (CDRs) as pending CDRs from various middleware, convert them into CDR message bodies, store them in the message channel, and perform billing on the CDR message bodies in the message channel through message nodes, such as batch price deduction. The CDRs with batch price deductions are then stored in any middleware such as MQ, MySQL, Redis, MongoDB, or FS in the form of queues / tables / keys.

[0099] Furthermore, the SI component in the third billing procedure can obtain billing call detail records (CDRs) as pending CDRs from various middleware components. After converting these pending CDRs into CDR message bodies, it stores them in the message channel. Billing is then performed on the CDR message bodies in the message channel through message nodes, for example, by deducting the entire amount. The CDRs with the total deduction are then stored on the local storage.

[0100] This embodiment transforms the call detail records (CDRs) to be processed into an internal message body and performs streaming processing through message channels and message nodes. This allows CDRs to be processed in a streaming manner within the billing process, thereby preventing interruptions during the CDR processing and improving processing efficiency.

[0101] This embodiment can solve the problems of current streaming billing requiring the use of MQ queues, excessive coupling between application systems and middleware, and inability to handle data loss during power outages.

[0102] In the billing process, after connecting to external middleware, all messages are converted into internal messages. Regardless of whether the external middleware is an MQ queue, the messages are processed internally in a producer-consumer pattern to achieve internal streaming processing and improve billing efficiency.

[0103] This removes the limitations of existing streaming billing in terms of middleware selection, allowing integration with various external middleware. The streaming billing model is not restricted by message queues (MQ). Simultaneously, within the billing process, call detail records (CDRs) are also processed in a streaming manner, ensuring uninterrupted processing and improving efficiency.

[0104] Furthermore, this application also provides a call detail record (CDR) billing device.

[0105] Reference Figure 5 , Figure 5 This is a schematic diagram of the functional modules of an embodiment of the call detail record (CDR) billing device of this application.

[0106] The call detail record (CDR) billing device includes:

[0107] The acquisition module 100 is used to acquire pending call detail records (CDRs) from a data source or middleware based on an integrated mode component. The middleware includes one or more of message queues, databases, and file systems.

[0108] The streaming processing module 200 is used to stream process the call detail records to be processed to obtain the target call detail records.

[0109] The call detail record (CDR) billing device provided in this application embodiment interfaces with various middleware such as data sources, message queues, databases, and file systems through an integrated mode component. It can obtain CDRs to be processed from the data source or middleware and consume them. Because it interfaces with multiple external middleware, the streaming billing mode is not limited by the message queue, avoiding the loss of messages in the message queue due to power failure in the data center. This can improve processing performance and thus improve CDR billing efficiency.

[0110] In one embodiment, the streaming processing module 200 is specifically used for:

[0111] The call detail records (CDRs) to be processed are converted into data to obtain the CDR message body;

[0112] The call detail record (CDR) message body is transmitted to the message node through the message pipeline;

[0113] The target call detail record (CDR) is obtained by consuming the CDR message body based on the message node.

[0114] In one embodiment, the streaming processing module 200 includes a conversion unit (not shown), the conversion unit being used for:

[0115] The call detail record (CDR) to be processed is formatted to obtain the CDR message body.

[0116] In one embodiment, the streaming processing module 200 further includes a first consumption unit (not shown in the figure), the first consumption unit being used for:

[0117] Billing is performed on the call detail record (CDR) message body based on the message node to obtain the target CDR.

[0118] In one embodiment, the streaming processing module 200 further includes a second consumption unit (not shown), the second consumption unit being used for:

[0119] Based on the message node, the call detail record (CDR) message body is collected, decoded, analyzed, and billed to obtain the target CDR.

[0120] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call a computer program in the memory 830 to execute steps of the call detail record (CDR) billing method, such as:

[0121] The component in the integrated mode obtains the call detail records to be processed from the data source or middleware, wherein the middleware includes one or more of message queues, databases, and file systems;

[0122] The call detail records (CDRs) to be processed are streamed to obtain the target CDR.

[0123] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] On the other hand, embodiments of this application also provide a storage medium, which is a computer-readable storage medium storing a computer program. The computer program is used to cause a processor to execute the steps of the methods provided in the above embodiments, including, for example:

[0125] The component in the integrated mode obtains the call detail records to be processed from the data source or middleware, wherein the middleware includes one or more of message queues, databases, and file systems;

[0126] The call detail records (CDRs) to be processed are streamed to obtain the target CDR.

[0127] The computer-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic storage (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical storage (e.g., CD, DVD, BD, HVD), and semiconductor storage (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0128] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method of charging for a telephone bill, characterized by, include: The integrated mode component obtains the call detail records to be processed from the data source or middleware. The middleware includes one or more of message queues, databases, and file systems. The integrated mode component includes message body, message channel, and message node. The pending call detail records (CDRs) are stream-processed to obtain the target CDRs, including: The call detail record (CDR) to be processed is transformed to obtain a CDR message body. The CDR message body includes a header and a payload. The header is used to store the attribute parameters in the CDR to be processed, and the payload is used to store the specific data in the CDR to be processed. The call detail record (CDR) message body is transmitted to the message node through the message channel. When the message node detects that the CDR message body exists in the message channel, it retrieves the CDR message body from the message channel and consumes it. The target call detail record (CDR) is obtained by consuming the CDR message body based on the message node. If the target call detail record (CDR) is an intermediate CDR, the target CDR is stored in various downstream middleware in the form of a message queue, table, or key, so that the integration mode component can obtain the billing CDR from the various downstream middleware as the CDR to be processed through monitoring and polling.

2. The method of claim 1, wherein the billing message is a CDR. 2 The consumption includes one or more of the following: collection, decoding, analysis, and billing.

3. The method of claim 2, wherein the step of generating a billing record comprises the step of: The step of consuming the call detail record (CDR) message body based on the message node to obtain the target CDR includes: ​ Billing is performed on the call detail record (CDR) message body based on the message node to obtain the target CDR.

4. The method of claim 2, wherein the step of generating a billing record comprises the step of: The step of consuming the call detail record (CDR) message body based on the message node to obtain the target CDR further includes: ​ Based on the message node, the call detail record (CDR) message body is collected, decoded, analyzed, and billed to obtain the target CDR.

5. The call detail record (CDR) billing method according to claim 1, characterized in that, The step of performing data transformation on the call detail records (CDRs) to obtain the CDR message body includes: The call detail record (CDR) to be processed is formatted to obtain the CDR message body.

6. A call billing apparatus characterized by comprising: include: The acquisition module is used to acquire pending call detail records (CDRs) from a data source or middleware based on an integrated mode component. The middleware includes one or more of message queues, databases, and file systems. A streaming processing module is used to stream process the call detail records (CDRs) to be processed to obtain the target CDRs; The streaming processing module is also used for: The call detail record (CDR) to be processed is transformed to obtain a CDR message body. The CDR message body includes a header and a payload. The header is used to store the attribute parameters in the CDR to be processed, and the payload is used to store the specific data in the CDR to be processed. The call detail record (CDR) message body is transmitted to the message node through the message channel. When the message node detects that the CDR message body exists in the message channel, it retrieves the CDR message body from the message channel and consumes it. The target call detail record (CDR) is obtained by consuming the CDR message body based on the message node. If the target call detail record (CDR) is an intermediate CDR, the target CDR is stored in various downstream middleware in the form of a message queue, table, or key, so that the integration mode component can obtain the billing CDR from the various downstream middleware as the CDR to be processed through monitoring and polling.

7. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the call detail record (CDR) billing method according to any one of claims 1 to 5.

8. A storage medium, which is a computer-readable storage medium, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the call detail record (CDR) billing method according to any one of claims 1 to 5.

Images