CN117573926A - Message format dynamic conversion method based on enterprise service bus - Google Patents

Abstract

A message format dynamic conversion method based on an enterprise service bus, comprising: establishing a standard SpringBoot system frame; constructing an enterprise service bus by using Apache Camel and SpringBoot; acquiring a user request and a target Webservice URL through a RESTful API; acquiring corresponding WebService URL and parameter information from a database according to the mapper URL-mapping; the conversion of JSON and XML is realized by using an XSstream library: and dynamically acquiring the target URL according to the URL submitted by the user to carry out route forwarding.

Description

Message format dynamic conversion method based on enterprise service bus

Technical Field

The present disclosure relates to the field of information technologies, and in particular, to a method for implementing dynamic conversion of a message format based on an enterprise service bus.

Background

In recent years, as business continues to evolve, the complexity of enterprise systems has increased. Integration and information exchange between systems is a challenging task due to the complexity and heterogeneity of the different systems. More specifically, this places serious limitations on the flexibility and efficiency of data exchange, as the message formats and exchange protocols may vary from system to system.

To address this problem, enterprise service buses have begun to be widely used. An enterprise service bus provides an information middleware from a source system to a target system that can handle connection, routing, translation, and management messages. The enterprise service bus provides these functions in the form of services, by means of which flexible integration between complex systems can be achieved by means of Service Oriented Architecture (SOA). However, message format conversion remains an important challenge. In current implementations, the conversion of the message format typically requires predefined mapping rules or hard-coded solutions, which have limited adaptability to the new format, and do not have good flexibility and scalability. Furthermore, most existing solutions require advanced technical skills and in-depth understanding of the source and target systems, which makes modification of the message format or addition of new message types extremely difficult and time consuming. In summary, existing message conversion solutions still suffer from a number of drawbacks in terms of flexibility, efficiency, and ease of use, especially for large-scale, complex, and rapidly changing modern enterprise systems. Thus, there is a need for a new solution, especially an enterprise service bus based solution, that enables convenient and efficient message format conversion.

Disclosure of Invention

In order to improve flexibility and expandability of message format conversion of an enterprise service bus, the application provides a message format dynamic conversion method based on the enterprise service bus.

In order to achieve the above objective, an embodiment of the present application provides a method for dynamically converting a message format based on an enterprise service bus, including:

s1: establishing a standard SpringBoot system frame;

s2: constructing an enterprise service bus by using Apache Camel and SpringBoot;

s3: the method for acquiring the user request and the target Webservice URL through the RESTful API specifically comprises the following steps: writing a Controller class Controller by using a SpringBoot framework, and annotating a specific URL mode and an HTTP method in the Controller by using @ PostMapping to define a RESTful API; the RESTful API is used for receiving a user request and determining a target WebService URL through URL-mapping after receiving the user request; wherein the user request includes the requested data and header information;

s4: acquiring corresponding WebService URL and parameter information from a database according to the mapper URL-mapping;

the database stores a target WebService URL capable of being configured dynamically and corresponding parameter information; each record represents a specific WebService interface and contains the URL called by the record and the parameter information required by the record; the database supports dynamic operation, and can add, delete, modify and query WebService URL and parameter information according to actual requirements;

when the URL-mapping user and the user request sent through the API are received, determining relevant WebService URLs and parameter information stored in a database from the user request by using preset mapping logic;

s5: the conversion of JSON and XML is realized by using an XSstream library: the method comprises the steps of adding related dependent packets in a maven form in an XSstream library to use an XSstream class library, and converting JSON parameters requested by a user into an XML format by using the XSstream; firstly converting JSON parameters into Java objects, and then converting the Java objects into XML by XStream, wherein the conversion process mainly comprises four steps: creating an XStream instance, registering a converter, setting an alias, and then calling a toXML () method to convert a Java object into XML; and then calling a step S4, and after acquiring the request parameters and the request parameters of the target WebService URL according to the RESTful API of the request by using a URL-mapping function module, using a toXML () method to realize dynamic conversion of the request parameters and the target parameters.

S6: and dynamically acquiring the target URL according to the URL submitted by the user to carry out route forwarding.

Wherein, the step S6 includes: and using Apache camera to realize dynamic route forwarding.

The step S6 specifically includes:

s61: defining a Controller for guiding the URL submitted by the user to a dynamic route;

obtaining an originalUrl from a request header of a user request through an annotation @ RequestHeader ("originalUrl") of the Controller, and sending the originalUrl to a dynamic route together with the requested data;

s62: using Apache Camel to carry out dynamic route to create a new RouteBuilder class; the method specifically comprises the following steps:

opening an Apache Camel route, and starting to monitor a request from a specific URL by the Apache Camel; in the routing Context, one or more Processing Components are configured to process the received specific URL request; when a request of a specific URL is received, the Apache Camel route sends the request to a corresponding Processing Component for processing according to a routing rule configured by the Apache Camel route; after processing is complete, processing Component generates a response, which the Apache Camel route sends back to the original request.

The beneficial effects of the technical scheme of the application are as follows: according to the technical scheme, the functions of dynamically acquiring URL information configured in a database, target WebService URL and parameter information in a system according to RESTful URL requested by a user and converting parameters from JSON to XML through XSstream by format conversion of the parameters are realized by using technologies such as Apache camera, springBoot and XSstream.

Drawings

Fig. 1 is a schematic structural diagram of an embodiment of the present application.

Detailed Description

In order to make the technical problems, technical solutions and advantages to be solved by the present application more apparent, the following detailed description will be given with reference to the accompanying drawings and the specific embodiments.

The technical problem to be solved by the application is as follows: how to improve the flexibility and scalability of message format conversion for enterprise service buses.

In order to achieve the above objective, an embodiment of the present application provides a method for dynamically converting a message format based on an enterprise service bus, which uses technologies such as Apache camera, springBoot, XStream, etc. to achieve the function of dynamically acquiring URL information configured in a database and target WebService URL and parameter information in a system according to a RESTful URL requested by a user, and converting parameters from JSON to XML through XStream through format conversion of parameters.

The message format dynamic conversion method based on the enterprise service bus, provided by the embodiment of the application, comprises the following steps:

s1: establishing a standard SpringBoot system frame;

s2: an enterprise service bus is constructed by using Apache Camel and SpringBoot: apache Camel provides a lightweight framework that is integrated into Spring Boot and can easily create and run enterprise integration schemas. The apche camera routing rule engine is a rule-based routing and media engine, various routing and integration operations are completed through Java DSL rules, and a routing rule is defined by rewriting a config method in a program in a way of realizing a RouteBuilder class. The Camel route may be loaded into the Spring Boot application so that the application may use the powerful functions of Apache Camel, including message routing, translation, exception handling and testing. In addition, the Spring Boot also provides an automatic configuration characteristic, and can start and run services more quickly and efficiently.

S3: user request and target Webservice URL are obtained through RESTful API: a Spring Boot framework is used for writing a Controller class (Controller) and annotating a specific URL mode and an HTTP method to define a RESTful API, and through the API, a user request comprising requested data and header information can be conveniently received. The system will determine the target WebService URL by URL-mapping when receiving the request.

S4: the target WebService URL and parameter information are dynamically configured through a database: each WebService URL and corresponding parameter information are stored in the database. The information is dynamically configurable, and can be added, deleted and checked according to actual requirements. When a user sends a request through an API, the system acquires the corresponding WebService URL and parameter information from the database according to the URL-mapping. This step mainly involves two functional modules, a database storage module and a URL-mapping module.

The database storage module: the method is mainly used for storing the URL of the WebService and related parameter information. Each record represents a specific WebService interface, including the URL it calls and the parameter information it needs. In addition, the storage module supports dynamic operation, namely operations such as adding, deleting, modifying, inquiring and the like to the WebService URL and parameter information according to actual requirements.

URL-mapping module: when the system receives the request sent by the user through the API, the module is used as a mapper to find out related WebService URLs and parameter information stored in the database according to the request content by using preset mapping logic.

S5: the conversion of JSON and XML is realized by using an XSstream library: XStream is a simple library that can be used to serialize Java objects into XML or deserialize XML into Java objects. In the invention, the relevant dependent package is added in a maven form to use an XSstream class library, and the XSstream is used for converting the JSON parameters requested by the user into an XML format so as to facilitate subsequent processing. Firstly, the JSON parameter needs to be converted into a Java object, then the Java object is converted into XML by XStream, and the conversion process mainly comprises four steps: creating an XStream instance, registering a transformer, setting an alias, and then calling a toXML () method to transform a Java object into XML. In step S4, after obtaining the request parameters and the request parameters of the target WebService URL according to the RESTful API of the request by the URL-mapping function module, a toXML () method is used to dynamically convert the request parameters and the target parameters.

S6: and dynamically acquiring the target URL according to the URL submitted by the user to carry out route forwarding.

Further, in the step S6, a specific process of implementing dynamic routing forwarding by using Apache camera is as follows:

s61: defining a Controller for URL-guided processing of user submissions to dynamic routing

The annotation @ RequestHeader ("originalUrl") is used in the Controller' S route method defined in step S3 to obtain the originalUrl from the request header and send it to the dynamic route along with the request body.

S62: dynamic routing using Apache camera to create a new RouteBuilder class

Opening an Apache Camel route, starting to monitor a request from a specific URL (uniform resource locator), configuring one or more Processing Components in a route Context, processing the received specific URL request by the Apache Camel route, sending the request to a corresponding Processing Component for processing according to a configured routing rule when the request of the specific URL is received by the Apache Camel route, generating a response by Processing Component after the processing is finished, and sending the response back to the original request by the Apache Camel route.

The technical scheme mainly aims at improving the flexibility and the expandability of the message format conversion of the enterprise service bus, and provides a message format dynamic conversion implementation method based on the enterprise service bus. The method mainly uses technologies such as Apache camera, springBoot and XSstream to realize the functions of dynamically acquiring URL information configured in a database, target WebService URL and parameter information in a system according to RESTful URL requested by a user and converting parameters from JSON to XML through format conversion of the parameters.

The main steps of the technical scheme include:

1. and constructing a standard system frame by utilizing SpringBoot.

2. And establishing an enterprise service bus by using Apache Camel and SpringBoot to realize message routing, conversion, exception handling and testing.

3. The user request and the target WebService URL are obtained through the RESTful API, the controller class definition API is written by using the Spring Boot framework, the request information is received, and the target WebService URL is determined through URL-mapping.

4. The URL and the parameter information are dynamically configured using a database. The database is used for storing the WebService URL and the corresponding parameters, and can be dynamically operated according to actual requirements. The system will obtain relevant information from the database according to the URL-mapping requested.

5. The conversion of JSON and XML is completed by using an XSstream library, and JSON parameters requested by a user can be converted into an XML format so as to be convenient to process.

6. And dynamically acquiring the target URL according to the URL submitted by the user and executing route forwarding. This step can implement dynamic route forwarding through Apache Camel.

According to the technical scheme, the technologies such as Apache camera, springBoot and XSstream are used, so that the URL and parameter information are dynamically obtained according to the RESTful URL requested by the user, the function of dynamic conversion of the parameter format is realized, and the flexibility and the expandability of message format conversion of an enterprise service bus are greatly improved.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer programs. When the computer program is loaded and executed on a computer, the flow or functions described in accordance with embodiments of the present application are fully or partially produced. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer program may be stored in or transmitted from one computer readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means from one website, computer, server, or data center. The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage medium such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that: the first, second, etc. numbers referred to in this application are merely for convenience of description and are not intended to limit the scope of the embodiments of the present application, but also to indicate the sequence.

At least one of the present application may also be described as one or more, and a plurality may be two, three, four or more, and the present application is not limited thereto. In the embodiment of the present application, for a technical feature, the technical features of the technical feature are distinguished by "first", "second", "third", "a", "B", "C", and "D", and the technical features described by "first", "second", "third", "a", "B", "C", and "D" are not in sequence or in order of magnitude.

The correspondence relationship shown in each table in the present application may be configured or predefined. The values of the information in each table are merely examples, and may be configured as other values, which are not limited in this application. In the case of the correspondence between the configuration information and each parameter, it is not necessarily required to configure all the correspondence shown in each table. For example, in the table in the present application, the correspondence shown by some rows may not be configured. For another example, appropriate morphing adjustments, e.g., splitting, merging, etc., may be made based on the tables described above. The names of the parameters indicated in the tables may be other names which are understood by the communication device, and the values or expressions of the parameters may be other values or expressions which are understood by the communication device. When the tables are implemented, other data structures may be used, for example, an array, a queue, a container, a stack, a linear table, a pointer, a linked list, a tree, a graph, a structure, a class, a heap, a hash table, or a hash table.

Predefined in this application may be understood as defining, predefining, storing, pre-negotiating, pre-configuring, curing, or pre-firing.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (3)

1. A method for dynamically converting a message format based on an enterprise service bus, comprising:

s1: establishing a standard SpringBoot system frame;

s2: constructing an enterprise service bus by using Apache Camel and SpringBoot;

s3: the method for acquiring the user request and the target Webservice URL through the RESTful API specifically comprises the following steps: writing a Controller class Controller by using a SpringBoot framework, and annotating a specific URL mode and an HTTP method in the Controller by using @ PostMapping to define a RESTful API; the RESTful API is used for receiving a user request and determining a target WebService URL through URL-mapping after receiving the user request; wherein the user request includes the requested data and header information;

s4: acquiring corresponding WebService URL and parameter information from a database according to the mapper URL-mapping;

the database stores a target WebService URL capable of being configured dynamically and corresponding parameter information; each record represents a specific WebService interface and contains the URL called by the record and the parameter information required by the record; the database supports dynamic operation, and can add, delete, modify and query WebService URL and parameter information according to actual requirements;

when the URL-mapping user and the user request sent through the API are received, determining relevant WebService URLs and parameter information stored in a database from the user request by using preset mapping logic;

s5: the conversion between JSON and XML is realized by using an XSstream library; the method comprises the steps of adding related dependent packets in a maven form in an XSstream library to use an XSstream class library, and converting JSON parameters requested by a user into an XML format by using the XSstream; firstly converting JSON parameters into Java objects, and then converting the Java objects into XML by XStream, wherein the conversion process mainly comprises four steps: creating an XStream instance, registering a converter, setting an alias, and then calling a toXML () method to convert a Java object into XML; then calling a step S4, and after acquiring request parameters and request parameters of a target WebService URL according to a request RESTful API through a URL-mapping function module, using a toXML () method to enable the request parameters and the target parameters to realize dynamic conversion;

s6: and dynamically acquiring the target URL according to the URL submitted by the user to carry out route forwarding.

2. The method for dynamically converting message formats based on enterprise service bus according to claim 1, wherein said step S6 comprises: and using Apache camera to realize dynamic route forwarding.

3. The method for dynamically converting message formats based on enterprise service bus according to claim 2, wherein said step S6 specifically comprises:

s61: defining a Controller for guiding the URL submitted by the user to a dynamic route;

obtaining an originalUrl from a request header of a user request through an annotation @ RequestHeader ("originalUrl") of the Controller, and sending the originalUrl to a dynamic route together with the requested data;

s62: using Apache Camel to carry out dynamic route to create a new RouteBuilder class; the method specifically comprises the following steps:

opening an Apache Camel route, and starting to monitor a request from a specific URL by the Apache Camel; in the routing Context, one or more Processing Components are configured to process the received specific URL request; when a request of a specific URL is received, the Apache Camel route sends the request to a corresponding Processing Component for processing according to a routing rule configured by the Apache Camel route; after processing is complete, processing Component generates a response, which the Apache Camel route sends back to the original request.