TWI484424B - Dynamic Management System of Telecommunication Fixed Network Resource Adjustment Process - Google Patents

Description

Telecom fixed network resource scheduling process dynamic management system

The invention relates to a resource management process dynamic management system, in particular to a binding system integrated according to the SOA <Service Oriented Architecture> service oriented architecture technology theory.

With the development of the enterprise, dynamic and agile system requirements have become the key. The system is imported by SOA, and the enterprise can change the business process at any time, and the whole system can still operate normally. The methods, techniques, and problems faced by previous process control systems are described below:

1. The system development method used in the previous process control system is a tightly coupled process software package, which is actually a big black box. Often, due to changes in the process business requirements, the system calls between the program components. There may even be a dependency relationship between the process stations, and the relationship of the business processes should not actually exist in the program logic, causing the process to become more dynamic, and most of the programs must be modified.

2. The previous process control system only proposed the process control method on a single system. However, as the business grows larger and there are many services that need to be supported across the various systems, the process management of the single system development is bound to be insufficient. There are many situations in which information is inconsistent with other systems, and the immediate update and integration of information is an urgent task.

3. The information formats of the prior art are not standardized, and as the demand for cross-system services increases, often when interfacing with other systems, often due to differences in the transmission data format, it must be re-developed, resulting in the program components not only need to deal with complex processes. The problem must also deal with the problem of data format conversion.

In summary, according to the existing management system, when faced with the need for new business, new service or integration of new and old products, the management of the process must be based on the degree of change of the business scope, and the corresponding management process Or even re-writing a new process, the internal information system data transmission and communication are often required within the enterprise, which is undoubtedly the need for programmers to customize the system for different businesses, resulting in the cost of development manpower.

Based on the above problems, the above-mentioned shortcomings derived from the conventional methods are improved and innovated. After years of painstaking research, the company successfully developed and completed the “Telecom-based fixed-line resource allocation process dynamic management system”, making resources The scheduling process is smoother and shortens the overall network supply schedule.

The object of the present invention is to propose a dynamic management system for the telecommunication fixed network resource allocation process, which provides flexible process control, completely separates the launched business service from the technical module, and at the same time can respectively display the respective presentation modes, that is, let the process The logic is independent of the program, enabling the system to flexibly adjust as the business needs change, improving the timeliness and speed of optimal network resource allocation.

The second object of the present invention is to provide an SOA service-oriented process management system for resource allocation, and to encapsulate the program in an object-oriented manner, so that basic program components are independently released through modularization. Service components, and these service components can be replaced at any time.

The dynamic management system for the telecom fixed-line resource allocation process that achieves the above-mentioned invention aims to establish a service bus based on SOA technology, emphasizing that the loosely coupled service interface is to make components do not depend on each other, and can replace these services at any time. Component; with the dynamic scheduling module, process management module and resource configuration query module developed by the system, construct a system architecture of complete resource allocation process management.

The present invention provides a dynamic management system for a telecom fixed network resource allocation process. For the implementation manner, please refer to the following illustration.

The invention establishes a dynamic network management system for standard network resource allocation. When the business process of the enterprise changes, the system can immediately reflect, and the management process can be changed at any time, and the entire flow control can still operate normally. The implementation method based on the theory of SOA is first to analyze the system, which parts are part of the basic function and which parts belong to the change function; the part of the basic function first defines the module and establishes a module with basic functions. This group of modules are basic logic services, and there will be no major changes. The requirements of the variable function modules will be adjusted frequently. It is necessary to judge the execution of the next stage according to the process return results. The result of the return is used to call the service that should be called later. Therefore, the separation of the basic service module and the change module is the key first step of the system.

Please refer to FIG. 1 , which is an integrated architecture diagram of a dynamic management system for a telecom fixed network resource allocation process according to the present invention. The second part of the total is the resource binding process manager 10 and the service bus 108. Finally, any external system 109 to be transferred is connected through the service sink 108 row.

The resource ordering process manager 10 is the core function of the system, and is responsible for establishing, controlling, executing, and monitoring changes of all processes. The resource ordering process manager 10 controls the results of different service backhauls and affects which services need to be executed subsequently. That is, the part of the change module mentioned in the previous summary. If the internal network business process is changed, it is only necessary to modify the resource ordering process manager 10.

The service modules on the service bus 108 are basically the analyzed basic modules. The execution of these basic modules is usually simple and rarely changed. It is only responsible for one thing, and the basic module is new. The addition method only needs to be added to the service bus 108, or it needs to be modified and only needs to be replaced; for the change module, the management is a group of basic modules on the bus, and the communication between them is A call interface, and the basic module is to let the change module assemble it into the flow control.

The design of the system architecture is actually a loosely coupled state. The spirit of the system construction is to replace modules and update modules at any time, and can be arbitrarily adjusted according to changes in external requirements to establish a complete and unified system. Architecture.

Resource Provisioning Process Manager 10:

The resource ordering process manager 10 is divided into three modules, which are a dynamic scheduling module 100, a process management module 101, and a resource configuration query module 102, which will be respectively introduced below.

1. Dynamic scheduling module 100:

The main task performed by the dynamic scheduling module 100 is to accept the work of "joining the import service 103" on the service bus 108. The joint order import service 103 is a basic service module, which is specifically responsible for connecting the external system 109 to receive the work of the joint order data. The data entered into the module stage via the joint order import service 103 is the processed and unified format information. The joint order information contains all the network service information that customers need to apply for or change. According to the applied project, the necessary ordering process for various circuit services is generated. The work of this module is to establish complex network application requirements. A set of business rules <Rule>, this rule logic is managed by the database, and the program that manages the rules is packaged into components. When there is a need to modify the rules in the future, it is only necessary to update and replace the data in the data table, without Change the program.

Please refer to Table 1 for the business rules of the dynamic scheduling module 100. The services that need to perform resource allocation for all the application items are divided into three categories: querying the bureau name information service 104 and the office routing protocol service 105. The external line is defined by the ordering service 106. Different application items will have different services to be executed. In addition, for each application item, the execution serial number of the service is defined, and the number is the priority. The rule is based on this rule. Identify the application on a single, dynamically initialize the entire resource-binding process, and determine the order of execution.

It is important to analyze the customer's order to be applied, and it will determine how to initiate the process and drive the routing of the entire process in the future. The business rules managed by this module are as described in this section, and the basic nodes of the path required for the subscription are managed as a data table. The following describes the management method of this module data sheet, please refer to Figure 2 and Figure 3.

● Service category 201 mainly records business types, such as FTTB optical generation service, FTTB peer-to-peer service, etc., and the service transaction item is a one-to-many relationship.

● Service Transaction Project 202 mainly records which application transactions will be applied to each business service. For example, the FTTB Optical Generation Service will need to rent, disassemble, release, and address. More relationships.

● Service Information 203 is a process for defining the required actions for each application transaction. For example, if you want to apply for renting, you need to first query the information of the end office, adjust the routing of the central office, and adjust the service of the external line.

The service flow 301 records the flow control master file that should be generated after each joint order is analyzed, such as recording the process status, the leased line number, the joint order number, etc., and the service detail flow 302 is one. The relationship to many.

The service detail process 302 is a detail file belonging to the record process, which is based on the path process defined by the service information in the service information 203, and finally initializes the storage result of the resource bookbinding process, for example, the rent application application initializes the query end office. Information, ordering the central office routing, adjusting the various process stations of the external line, calling the basic module service on the bus according to the station of the path, and recording the execution time, return time and return result of each station. .Wait.

2. Process Management Module 101:

The main task of the process management module 101 is to manage the process control of resource allocation, that is, to execute a process station, receive a process station, analyze the data of the return result, re-execute, interrupt the process, and end the process, etc. Events managed by this module.

Referring to FIG. 4 , the process management module 101 of the present invention includes a process management engine 401 and other functional sub-components, wherein the process management engine includes an execution rule algorithm 402 for determining whether the process can be executed. Analyze the results of the return data to assist in determining the next step.

The process management module 101 has activities such as query flow, update data, execution flow, process return, and end process. The definition of an activity is to describe the execution of a step, build process components through understanding activities, and then string together process components. The trigger point of this module is that when the dynamic scheduling module initializes a new process, it will trigger the event of this phase. The process management engine controls the steps of the process, and its role is a control center, which is responsible for directing the activity. The internal "execution rule algorithm 402" is the connection between the control activities. The focus of this module is to establish a generalized dynamic process management. Regardless of how the process routing is different, the execution steps can apply the same template.

The process management engine 401 performs the steps as illustrated in FIG.

(1) When the process is initialized, the process management engine 401 is driven, and the execution rule algorithm 402 queries the initial process list, finds out which process stations should be executed, updates the data, and then executes the process.

(2) In the activity of executing the process, the variable value given by the execution rule algorithm 402 at this time, for example, the first process station executes the first service, and the second process station executes the second service...., The execution process activity determines the basic service on the call service bus 108 by the variable value.

(3) After executing the process, it will wait for the external system 109 to reply. When the executed process returns, it will be received by the process return activity, and the execution rule algorithm 402 will be re-executed, and the result of the summary return will be analyzed. This will cause the process to be interrupted, the return result will be updated, and the process will be ended; if the analysis result is correct and the judgment can be continued, the return result will be updated and the next stage process station will be executed.

(4) Until the execution of the rule algorithm 402 has completed all the process stations, and all the process stations have returned successfully, the process ends and the results are returned to the upstream system.

The actual business process of applying the process management module 101 to resource setting is as follows:

(1) When a FTTB peer-to-peer service is rented from the front-end system for the customer, the process is initialized by the dynamic scheduling module 100, and the state flow management module 100 is started.

(2) The execution rule list 402 of the process management module 101 queries the initialization process list, and concludes that the process station is "query office name information service 104", "office route routing service 105", and "outbound line subscription service". 106".

(3) The execution rule algorithm 402 determines that the "inquiry bureau name information service 104" needs to be executed first, so updating the execution time of the process station and the like, and issuing the execution flow, the instructions will be directed to the "inquiry bureau name" on the execution service bus 108. Information Service 104".

(4) After the "Inquiry Bureau Information Service 104" process station returns, it is re-executed by the execution rule algorithm 402 to determine whether the return office name information is sufficient to adjust the central office and the external line. If the result is established, the office name information is updated and executed. The "office route routing service 105" on the service bus 108.

(5) After the return of the process data of the "office routing service 105", the analysis of the return result is successful. If the central office is successfully scheduled, the "external line-by-order service 106" is successfully executed; If you need to wait for the construction of the project, the equipment cannot be installed, the customer has not paid the deposit, etc., the problem will be interrupted, and the problem of the upstream system will be reported.

(6) Finally, if the "outside line is ordered by the ordering service 106" is successful, the information such as the number of core lines, the name of the line point, etc. will be updated, and the process ends.

3. Resource configuration query module 102:

There are many information systems within the enterprise, but they all operate independently. There is no integration between them. Each has its own independent database. Some of the information is also duplicated. The most important issue is that the information is not The latest, so the situation of inconsistent data often occurs, if the need to synchronize the data, it must consume a lot of time and manpower development of the information system. The main task of this module is to capture and integrate the required information into each system to form a share for the system platform and users to check and monitor the latest process status. Its main functions are as follows:

(1) In the "execution rule algorithm 402", it is necessary to obtain the relevant data from the external system 109, and obtain the circuit binding status data through the resource configuration inquiry service 102 on the service bus 108, including: exchange, core position, wiring Status...etc., to other systems to get the latest information at any time.

(2) This module provides the function of querying data by the system, which allows the user to directly query the status of the current ordering line from the system, without having to separately query from each system to achieve the advantages of resource integration.

Service Bus 108:

The service bus 108 established by the system is currently managed by the Oracle AqualLogic Service Bus software. In the SOA architecture, the essence of the service bus 108 is that it can centrally manage various transport protocols and also provide a message processing proxy for heterogeneous information systems.

At this stage, the service modules required for resource allocation are defined. These service modules unify the conversion of message routing <Message Routing> and message format <Message Format>, and convert all external non-uniform messages into internal requirements. Uniform format, through the architecture of the service bus 108 SOA, the external heterogeneous information system only needs to be connected with the bus bar to formulate an acceptable message format. For the internal resource ordering process manager, it is not necessary to know which external systems are in contact with it. You need to deal with the format of the converted message, as long as you focus on the work that your module should handle.

If there is a change in the module on the service bus 108, the basic module can be replaced at any time. If it is necessary to add a new module, it will not affect the execution of the entire system. Before establishing a basic service module, you must confirm the following business requirements:

● Need to get the joint information (such as new rental, change, dismantling, cancellation....);

● It is necessary to query the end office information name as the supply requirement to other systems;

● It is necessary to assign a terminal binding system to make a subscription port of the device;

● Need to assign an external client to adjust the system to the actual site line;

● It is necessary to query the resource configuration data of the subscription to analyze and judge the subscription information and reply to the upstream system.

According to the above business needs, the basic modules that need to be developed are as follows:

● The joint order import service 103: the resource ordering manager 10 can receive the joint order information for processing;

● Querying the name information service 104: The resource ordering manager 10 can query the name of the end office information at any time through the interface;

The central office routing protocol service 105: the resource binding manager 10 assigns the central office routing and binding system to perform device binding;

● The external line is ordered by the ordering service 106: the resource ordering manager 10 assigns an outside line ordering system for external line ordering;

Resource configuration query service 107: The resource subscription manager 10 needs to go to the subscription system to obtain the resource configuration status.

After the above service modules are established, they are added to the service bus 108 for the resource ordering process manager 10 to call, and all the service modules can be updated as needed, so that the business process and the basic service module of the system are Both are in a loosely coupled state.

The basic modules used on the service bus 108, the input transport protocols that are supported by the external system 109 are:

●Email

●File

●Http

●Web Service

●JMS

The outgoing protocol that supports input currently uses only Web Services to unify the message format.

The "telecom fixed network resource scheduling process dynamic management system" provided by the present invention has the following advantages when compared with other conventional technologies:

1. The present invention analyzes the system using the SOA theoretical basis, and establishes a basic module and a variable module, so that the basic modules are assembled into the flow control of the variable module one by one. System development uses the object abstraction <Abstraction> and reuse <Reuse> method to build a flexible <Flexibility> system. Compared with other conventional technologies, in the face of new service requirements, the update module can be replaced at any time, and the new component can be quickly developed and designed through the object abstraction architecture.

2. The present invention encapsulates the external component interface through the service bus 108 in an SOA theory, enabling acceptance of multiple transport protocols. Compared with other conventional technologies, it provides multiple transmission protocols for external heterogeneous systems and converts the data into a uniform format that can be processed by the internal system, so that the correction of the interface format does not affect the internal system.

3. The present invention establishes business rules for complex network application and binding process, and manages the data in the database form. Compared with other conventional technologies, if it is necessary to change the business rules in the future, it is not necessary to modify the program, and directly change the process rules of the data table. Reduce the manpower and time of software development, and then make the system quickly adjust as business needs change.

4. The present invention provides an SOA integration solution, which solves the communication difficulties of the internal and external systems due to the use of different IT technologies, and the upstream and downstream system information is integrated by the present invention.

5. The invention separates the business process from the basic module, and is in a loosely coupled state, and can add or update the module to the bus bar at any time to achieve the flexibility and the advantages of the component at any time.

The detailed description of the preferred embodiments of the present invention is intended to be limited to the scope of the invention, and is not intended to limit the scope of the invention. The patent scope of this case.

To sum up, this case is not only innovative in terms of technical thinking, but also has many of the above-mentioned functions that are not in the traditional methods of the past. It has fully complied with the statutory invention patent requirements of novelty and progressiveness, and applied for it according to law. Approved this invention patent application, in order to invent invention, to the sense of virtue.

10. . . Resource ordering process manager

100. . . Dynamic scheduling module

101. . . Process management module

102. . . Resource configuration query module

103. . . Joint import service

104. . . Enquiry for bureau name information services

105. . . Central office routing service

106. . . External line service

107. . . Resource configuration query service

108. . . Service bus

109. . . External system

201. . . Service type

202. . . Service transaction project

203. . . Service information

301. . . Service Process

302. . . Service detail process

401. . . Process management engine

402. . . Execution rule algorithm

Figure 1 is an integrated architecture diagram of resource scheduling dynamic process management.

Figure 2 Database Basement Correlation Diagram of the Basic Resource Allocation Process (ERD)

Figure 3 Initialization process database entity association diagram <ERD>

Figure 4 Schematic diagram of the process management module

Figure 5 process management engine execution step diagram

10. . . Resource ordering process manager

100. . . Dynamic scheduling module

101. . . Process management module

102. . . Resource configuration query module

103. . . Joint import service

104. . . Enquiry for bureau name information services

105. . . Central office routing service

106. . . External line service

107. . . Resource configuration query service

108. . . Service bus

109. . . External system

Claims (10)

A dynamic management system for a telecom fixed network resource setting process adopts a service oriented architecture, which comprises: a dynamic scheduling module, the dynamic scheduling module automatically generates a binding process according to the received data; a process management module The process management module is configured to control and execute the scheduling process; a resource configuration query module, the resource configuration query module is used to obtain external system resources; and a service bus bar is used to interface the External systems, and provide services and transport protocols, and data format conversion with external systems. For example, the dynamic management system for the telecommunication fixed-line resource allocation process described in the first application of the patent scope, wherein the dynamic scheduling module is used to receive the front-end customer contact list data, and establish a set of services for the network application requirements. Rules and simplify packaging into components. For example, the telecom fixed network resource scheduling process dynamic management system described in claim 1 is used to establish a generalized process management manner, which is divided into a query process, an update data, and an execution process. The process returns and ends the process. Regardless of the process path, the execution steps are applied to the same template without re-customizing the program. For example, the dynamic management system for the telecommunication fixed-line resource allocation process described in the first application of the patent scope, wherein the service bus is used to process the information format required for transmission, and the heterogeneous information is converted into a unified by the conversion tool. Message format. For example, the telecom fixed network resource allocation process dynamic management system described in claim 1 is characterized in that at least one service module is placed on the service bus, which includes: the following services, the joint import service, the query Module name information service, central office routing and ordering service, external line subscription service, resource configuration query service and other modules. For example, the telecom fixed network resource allocation process dynamic management system described in claim 5, wherein the joint order import service is a channel interface for receiving external joint order data for processing. For example, the telecom fixed network resource allocation process dynamic management system described in claim 5, wherein the query office name information service is a channel interface for inquiring to an external system to query the end office information name. For example, the telecom fixed network resource allocation process dynamic management system described in claim 5, wherein the central office route ordering service is a channel interface for assigning an external system for central office equipment binding. For example, the telecom fixed network resource allocation process dynamic management system described in claim 5, wherein the external line is a channel interface for assigning an external system for external line binding. For example, the telecom fixed network resource scheduling process dynamic management system described in claim 5, wherein the resource configuration query service is a channel interface for connecting an external system to obtain a resource configuration status.