Bulletin component system based on government purchase integrated micro-service architecture

Abstract

The invention relates to an announcement component system based on government purchase integrated micro-service architecture, the main body of the announcement component system is an integrated announcement component system, and the announcement component system comprises a system management module, an announcement service module and a third-party receiving module; the system management module is provided with a plurality of business subsystems, the third-party receiving module is provided with a plurality of web portals, and each business subsystem can perform data transmission with any web portal in the third-party receiving module; each business subsystem is connected with the announcement service module through the same data encryption mode and transmits announcement business data; and the announcement service module is used as a unified interface layer to flexibly process announcement service data of the service subsystem and push the announcement service data to a corresponding web portal. Through the unified interface layer design and the same data encryption mode, announcement pushing implementation modes of different service systems are flexibly configured, the expandability and maintainability of the system are improved, the docking process of the service system and a third-party portal is simplified, and the development cost and the communication cost are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of system architecture design and framework development, and in particular to an announcement component system based on a government procurement integrated microservice architecture. Background Art

[0002] At present, most companies need announcement push services. The implementation method is generally that each subsystem develops its own announcement push system to each portal website. In this mode, there are usually problems such as inconsistent interfaces, complex data conversion, and difficulty in connecting business systems with third-party portals among the various announcement push systems within the company. The shortcomings and their causes are analyzed as follows:

[0003] 1. Large workload and high repetitiveness: When each business subsystem develops its own announcement push function, it means that each system needs to repeat similar function design and development, which undoubtedly increases the overall workload.

[0004] 2. Low scalability: Independent push systems often lack unified design and specifications, making integration and expansion between systems difficult. When it is necessary to add new push channels or modify push logic, changes may need to be made in multiple systems, which reduces the scalability of the system.

[0005] 3. High maintenance cost: Due to the existence of multiple independent push systems, maintenance personnel need to be familiar with different code bases and technology stacks, which increases the complexity and cost of maintenance; when problems occur, they need to check each system one by one, which is inefficient.

[0006] 4. Inconsistent interfaces: Different subsystems may adopt different interface standards and protocols, leading to difficulties in communication between systems. Inconsistent interfaces may also lead to inconsistent data formats, increasing the complexity of data conversion and the possibility of errors.

[0007] 5. Complex data conversion: Due to the inconsistency of interfaces and data formats, data may need to be complexly converted and processed during the push process; this not only increases the complexity of the system and the possibility of errors, but also reduces push efficiency.

[0008] 6. Difficulty in connecting business systems with third-party portals: When a business system needs to connect with a third-party portal, the connection process may become complicated and difficult due to the inconsistency of interfaces and data formats; this may lead to inefficient connection or even failure of successful connection.

[0009] 7. Increased security risks: Developing push functions on its own for each subsystem may mean that each system needs to handle security issues such as authentication, authorization, and encryption separately; this increases the security risks of the system and may lead to problems such as data leakage or unauthorized access. Summary of the invention

[0010] The purpose of the present invention is to provide an announcement component system based on an integrated microservice architecture for government procurement, which can utilize a unified interface layer design to simplify the docking process between the business system and the third-party portal website, flexibly configure the announcement push implementation methods of different business systems, and improve the scalability and maintainability of the system.

[0011] The present invention is implemented through the following technical solutions: an announcement component system based on the government procurement integrated microservice architecture, the main body of which is an integrated announcement component system, which includes a system management module, an announcement service module and a third-party receiving module connected in sequence;

[0012] The system management module is provided with a plurality of business subsystems, and the third-party receiving module is provided with a plurality of portal websites, and each business subsystem can transmit data with any portal website in the third-party receiving module through the announcement service module;

[0013] Each business subsystem is connected to the announcement service module through the same data encryption mode and transmits announcement business data; the announcement service module can flexibly process the announcement business data of the business subsystem as a unified interface layer and push it to the corresponding portal website.

[0014] Compared with the previous technology, the beneficial effects of the present invention are:

[0015] 1. The present invention, through a unified interface layer design and the same data encryption mode, can flexibly configure the announcement push implementation methods of different business systems, improve the scalability and maintainability of the system, simplify the docking process between the business system and the third-party portal, and reduce development costs and communication costs.

[0016] 2. Through the customized field mapping relationship configuration of the not i ce service block, the announcement data of each business system can be accurately converted into the field values ​​required by the corresponding portal website, improving the accuracy and efficiency of data conversion.

[0017] 3. The system's automatic retry mechanism ensures that push can be automatically retried when push fails, improving the reliability and stability of push. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a module block diagram of the present invention. DETAILED DESCRIPTION

[0019] The present invention is described in detail below in conjunction with the accompanying drawings, but the protection content of the present invention is not limited to the following:

[0020] like Figure 1As shown, an announcement component system based on the government procurement integrated microservice architecture, the main body of which is an integrated announcement component system, which includes a system management module, an announcement service module and a third-party receiving module connected in sequence;

[0021] The system management module is provided with a plurality of business subsystems, and the third-party receiving module is provided with a plurality of portal websites, and each business subsystem can transmit data with any portal website in the third-party receiving module through the announcement service module;

[0022] Each business subsystem is connected to the announcement service module through the same data encryption mode and transmits announcement business data; the announcement service module can flexibly process the announcement business data of the business subsystem as a unified interface layer and push it to the corresponding portal website.

[0023] Furthermore, the announcement service module can realize the accurate sending of announcement business data, ensuring that only the portal website designated as the recipient under the configured area can receive the announcement information. When an organization or enterprise has multiple business areas (i.e., multiple business subsystems), and each business area has different information receiving requirements. It is necessary to ensure that the announcement information can be accurately conveyed to the portal website of a specific recipient to avoid information leakage or unnecessary interference. The maintenance personnel / managers of the system management module can add, delete or modify the recipient configuration (i.e., the configuration of the portal website) for the business subsystem at any time, and only the configured portal website can receive the announcement issued for the business area.

[0024] For example, if the area code of portal A is 150601, when it is necessary to send announcement business data to portal A, the maintenance personnel / management personnel of the system management module can add or modify the relevant configuration of the receiving portal A and the area code 150601 in the configuration page of the portal in advance, so that the announcement business data of business subsystem A can be sent to portal A. The ability to flexibly configure the announcement push implementation methods of different business systems improves the scalability and maintainability of the system, simplifies the docking process between the business system and the third-party portal, and reduces the development cost and communication cost.

[0025] The business subsystems include a procurement execution system, an electronic transaction system, an electronic marketplace system, a supervision and management system, etc. Each of the above business subsystems is used to generate, store and manage user accounts and announcement business data under the same project;

[0026] The announced business data includes procurement project information, procurement demand information, procurement document information, project transaction information, registered supplier information, procurement contract information, procurement management information, etc.

[0027] Each business subsystem uses the same data encapsulation format, and the announcement business data of each business subsystem is encrypted in DES-ECB mode, which is also accompanied by a data Sha256 signature code.

[0028] Furthermore, in addition to being encrypted in DES-ECB mode and accompanied by a data Sha256 signature code, the announcement business data also carries a valid token obtained from the authentication center in the request header to ensure the security of data transmission through the interface.

[0029] Furthermore, the different needs of different portals are reflected in the following points:

[0030] ①The development language used may be different;

[0031] ② The fields and enumerations that need to be defined in the announcement data may be inconsistent;

[0032] ③ Different methods of data transmission: for example, China Government Procurement Network adopts Web Service for transmission; the Public Resource Trading Center adopts the data reporting tool provided by the Public Resource Trading Center for reporting and transmission; the transmission fields defined by China Government Procurement Network are also different from those of the Resource Trading Center.

[0033] The announcement service module includes a notification service block and a data service block which are connected to each other; the notification service block is connected to each business subsystem, and the data service block is connected to each portal website;

[0034] The notification service block can decrypt the announcement service data according to the DES-ECB mode, convert the attribute name of the announcement service data according to the preset data mapping rule, and then send it to the data service block;

[0035] The data service block can determine the designated data sending method and recipient address and send the announcement service data according to the interface type of the announcement service data and the information of the recipient.

[0036] Furthermore, the data service will obtain the corresponding XML template and generate complete XML data in combination with the requirements of the corresponding portal website, and then call the webserv i ce interface to send the XML data to the recipient address. This operation involves network requests, identity authentication, data encryption and other operations.

[0037] If the webserv i ce interface call is successful and the receiver returns a successful response, the entire process is considered to be successfully completed, which is the "asynchronous interface returns successfully" in the figure. If any errors or exceptions are encountered during the sending process, the data service will handle the error and record the error information for subsequent investigation, which is the "return receiving status" in the figure.

[0038] Furthermore, the preset mapping rules can be implemented by manual mapping, naming convention rules or mapping configuration files.

[0039] Furthermore, the mapping configuration function is mainly used to solve the problem of inconsistent field names between the business subsystem and the portal website. Through mapping configuration, the correspondence and conversion between different field names can be achieved to ensure that data can be correctly transmitted from the business subsystem to the portal website. For unmatched fields, a mapping relationship between the business subsystem field and the portal website field is established. According to the mapping relationship, configure specific mapping rules, including field name conversion, data type conversion, etc. During the data transmission process, the mapping rules are applied to convert the data of the business subsystem to meet the field name requirements of the portal website.

[0040] Furthermore, the data service block will also adjust the field format and convert the message format of the received data, and finally push the message to the recipient address using a specified sending method.

[0041] The designated sending method of the data includes HTTP request, SOAP request or FTP upload.

[0042] The recipient address includes the URL address and IP address of the portal website, and also includes the user's email address.

[0043] Specifically, the specified sending method refers to the process of determining how to build and call the interface based on the specific recipient and announcement type. Since different recipients may provide different interfaces for different types of announcements, the sender needs to dynamically splice the different parts of the interface address according to the type of announcement and the requirements of the recipient to form a complete interface address. The sender first identifies the type of announcement to be sent and the corresponding recipient. According to the type of announcement and the requirements of the recipient, determine the appropriate specified sending method. According to the specified sending method, the sender will splice the different parts of the interface address. These parts may include the base URL, API version, resource path, query parameters, etc.

[0044] For example, the base URL might be https: / / api.example.com, the API version might be / v1, the resource path might be / notices, and the query parameters might include an announcement type identifier (such as type=announcement). The data service block dynamically constructs the complete interface address based on this information:

[0045] https: / / ap i.exampl e.com / v1 / not i ces? type=announcement

[0046] Furthermore, corresponding to the specified sending method, the data has a specified receiving method, which defines how the announcement business data is sent to the portal website, including the interface type, address, calling method, etc. During the data transmission process between the business subsystem and the portal website, the data service block can select the appropriate receiving method according to the interface exposed by the portal website to ensure that the data can be correctly received and processed. The portal website may provide different types of interfaces, such as RESTful interface, SOAP interface, etc.

[0047] The data service block provides the ability to select the appropriate calling method based on the interface type of the portal. The data service block needs to know the interface address of the portal so that the data can be sent to the correct location. The interface address may be in the form of a URL, an IP address plus a port number, etc. The data service block needs to send data according to the specified sending method defined by the portal, and also needs to organize the data according to the data format required by the portal, such as JSON, XML, and other data formats.

[0048] Furthermore, the not i ce service block transmits the data to the data service block through an internal API call or a message queue data transmission method. According to business needs, the not i ce service may also clean, filter, encrypt, etc. the data. The not i ce service block can add additional parameters to the data, including timestamps, sequence numbers, or verification information.

[0049] Furthermore, the data service block sends a request to the server through the network, and the request contains the data or instructions to be processed. The network request usually uses HTTP or HTTPS protocol to establish a connection between the data service block and the recipient to ensure that data can be transmitted between the two, and then through the identity authentication mechanism agreed upon between the data service block and the recipient, such as client authentication, IP authorization, etc., to ensure that only authorized users or systems can access. This enables the business subsystem to encrypt the transmitted data when calling the service of the announcement service module to protect the data from being eavesdropped.

[0050] Furthermore, the present invention also has an automatic retry mechanism. The automatic retry mechanism means that when executing a certain operation, if a temporary failure occurs (such as network fluctuations, service response timeout, etc.), the system will automatically retry to execute the operation according to a preset strategy until the operation is successful or the upper limit of the number of retries is reached. For example: the retry logic is directly implemented in the code for announcement release, update or notification push.

[0051] The announcement service module also includes a log configuration block for recording service records of the announcement service module.

[0052] Furthermore, the log configuration block is implemented using aop, which records the original data sent by each business subsystem, the sending time, the corresponding recipient and the sending result;

[0053] The log configuration block also includes a resend function, which can record the content sent by the data service block to the recipient, the result returned by the recipient, and the error information.

[0054] The business subsystem can also generate announcement business data to be sent according to trigger conditions, and the trigger conditions include:

[0055] ① After completing the data entry of the announcement business, the user completes the conditions for data disclosure, supplements the information for data disclosure, and clicks to send the trigger conditions;

[0056] ② System users directly enter announcement data in the background to complete the triggering conditions;

[0057] ③ Resend the data that failed to be sent / needs to be adjusted to complete the trigger conditions.

[0058] Although the present invention is illustrated and described by specific embodiments and their alternatives, it should be understood that various changes and modifications can be implemented without departing from the spirit and scope of the present invention. Therefore, it should be understood that the present invention is not limited in any sense except by the limitations of the attached claims and their equivalents.

Claims

1. An announcement component system based on a government procurement integrated microservice architecture, characterized by: The main body is an integrated announcement component system, which includes a system management module, an announcement service module and a third-party receiving module connected in sequence; The system management module is provided with a plurality of business subsystems, and the third-party receiving module is provided with a plurality of portal websites, and each business subsystem can transmit data with any portal website in the third-party receiving module through the announcement service module; Each business subsystem is connected to the announcement service module through the same data encryption mode and transmits announcement business data; the announcement service module can serve as a unified interface layer to flexibly process the announcement business data of the business subsystem and push it to the corresponding portal website.

2. According to claim 1, a notice component system based on a government procurement integrated microservice architecture is characterized by: The business subsystem includes a procurement execution system, an electronic transaction system, an electronic marketplace system, and a supervision and management system. Each of the above business subsystems is used to generate, store, and manage user accounts and announcement business data under the same project; The announcement business data includes procurement project information, procurement demand information, procurement document information, project transaction information, registered supplier information, procurement contract information and procurement management information.

3. The announcement component system based on the government procurement integrated microservice architecture according to claim 1 is characterized by: Each business subsystem uses the same data encapsulation format, and the announcement business data of each business subsystem is encrypted in DES-ECB mode, which is also accompanied by a data Sha256 signature code.

4. The announcement component system based on the government procurement integrated microservice architecture according to claim 3 is characterized by: The announcement service module includes a notice service block and a data service block which are connected to each other; the notice service block is connected to each business subsystem, and the data service block is connected to each portal website; The notice service block can decrypt the notice service data according to the DES-ECB mode, convert the attribute name of the notice service data according to the preset data mapping rule, and then send it to the data service block; The data service block can determine the designated data sending method and recipient address and send the announcement service data according to the interface type of the announcement service data and the information of the recipient.

5. According to claim 4, a notice component system based on a government procurement integrated microservice architecture is characterized by: The designated sending method of the data includes HTTP request, SOAP request or FTP upload.

6. The announcement component system based on the government procurement integrated microservice architecture according to claim 4 is characterized by: The recipient address includes the URL address and IP address of the portal website, and also includes the user's email address.

7. The announcement component system based on the government procurement integrated microservice architecture according to claim 1 is characterized by: The announcement service module also includes a log configuration block for recording service records of the announcement service module.

Images