CN116303060A

CN116303060A - ESB call request processing method, device, system, equipment and storage medium

Info

Publication number: CN116303060A
Application number: CN202310307238.8A
Authority: CN
Inventors: 彭欢; 袁永生
Original assignee: Ping An Technology Shenzhen Co Ltd
Current assignee: Ping An Technology Shenzhen Co Ltd
Priority date: 2023-03-27
Filing date: 2023-03-27
Publication date: 2023-06-23

Abstract

The application discloses a method, a device, a system, equipment and a storage medium for processing an ESB call request, wherein by receiving an ESB request message sent by an ESB interface caller system, marking information is obtained from a database according to a service name and a service scene carried in the ESB request message, and a characteristic value of the ESB request message is generated, so that a preset test rule is called, and whether an ESB system returns a specified response message or an analogue interface call timeout or normally forwards the ESB system is judged, and the ESB interface caller system, the ESB system or the ESB interface provider system does not need to make any change, so that the scene test for testing and calling the ESB interface is met, the technical problem that the ESB system or an external association system is required to cooperate to complete, and other systems can be influenced to call the interface when the ESB system cooperates to perform the abnormal scene test is solved.

Description

ESB call request processing method, device, system, equipment and storage medium

Technical Field

The present disclosure relates to the technical field of financial science and technology, and in particular, to a method, an apparatus, a system, a device, and a storage medium for processing an ESB call request.

Background

To improve program robustness, various scenarios such as call success, call failure, call timeout, etc. that may occur in an interface call must be tested when an external system interface is called through an ESB service inside the system. In particular to interface call of fund safety, aiming at various special error codes returned by calling interfaces, the interface call needs to be covered one by one during test, and the problem of fund safety caused by program problems is avoided.

In the prior art, when various calling interface abnormal scenes are tested, an associated system or an ESB system is required to be found to be matched with program or configuration modification so as to test the various calling interface abnormal scenes.

The existing scheme for testing and calling ESB interfaces has the following defects:

1. depending on the ESB system or external association system, the cooperation of the ESB system or external association system is required to complete.

2. When the associated system or the ESB system is matched for carrying out abnormal scene test, other systems can be influenced to call the interface, and the interface needs to be coordinated with all interface calling parties, so that the coordination difficulty is high.

Disclosure of Invention

The application provides a method, a device, a system, equipment and a storage medium for processing an ESB call request, which solve the technical problem that the ESB system or an external association system is matched to complete the test call of an ESB interface, and the ESB system is matched to perform abnormal scene test to influence other systems to call the interface.

In view of this, a first aspect of the present application provides an ESB system call request processing method, the method including:

s1, receiving an ESB request message sent by an ESB interface calling party system, wherein the ESB request message carries a service name and a service scene;

s2, acquiring all marking information of a corresponding interface from a database according to the service name and the service scene, and sequencing all marking information according to a preset priority;

s3, sequentially obtaining each field value in the ESB request message from a database according to the field names of the preset request messages configured in the marking information ordered according to the preset priority, and forming the characteristic value of the ESB request message;

s4, acquiring a preset test rule from a database according to the characteristic value;

and S5, judging whether to simulate a return response message or simulate interface call overtime or forward the ESB request message to an ESB system according to the preset test rule.

Optionally, the step S5 further includes:

if the response message is simulated, obtaining field names and corresponding field values of all preset simulation sequences according to the preset test rule corresponding rule codes;

combining field values in the preset simulation sequence through a freemaker template file to obtain a simulation response message of the ESB request message;

and returning the simulation response message to the ESB interface calling party system.

Optionally, the method further comprises:

and acquiring a preset monitoring port of the ESB system from the preset configuration file, and initializing a ServerBootstrap object.

Optionally, the method further comprises:

and initializing a database connection pool through a preset configuration file.

A second aspect of the present application provides an ESB system call request processing apparatus, the apparatus comprising:

the receiving unit is used for receiving an ESB request message sent by the ESB interface calling party system, wherein the ESB request message carries a service name and a service scene;

the first processing unit is used for acquiring all the marking information of the corresponding interface from the database according to the service name and the service scene, and sequencing all the marking information according to a preset priority;

the second processing unit is used for sequentially acquiring each field value in the ESB request message from a database according to the field names of the preset request message configured in the marking information ordered according to the preset priority, and forming the characteristic value of the request message;

the third processing unit is used for acquiring a preset test rule from the database according to the characteristic value;

and the response judging unit is used for judging whether to simulate the response message returned or simulate the interface call overtime or forward the ESB request message to an ESB system according to the preset test rule.

Optionally, the method further comprises:

the fourth processing unit is used for acquiring field names and corresponding field values of all preset simulation sequences according to the preset test rule corresponding rule codes if the simulation returns a response message;

the simulation response message processing unit is used for combining field values in the preset simulation sequence through a framemaker template file to obtain a simulation response message of the ESB request message;

and the sending unit is used for returning the simulation response message to the ESB interface calling party system.

A third aspect of the present application provides an ESB system call request processing system, the system comprising: the ESB system call request processing device provided in the second aspect of the application comprises an ESB interface caller system, a database and an ESB system;

and the ESB system call request processing device is respectively connected with the ESB interface caller system, the database and the ESB system.

Optionally, the ESB system call request processing device monitors an ESB request message of the ESB interface caller system based on a preset monitoring port.

A fourth aspect of the present application provides an ESB system call request processing apparatus, the apparatus comprising a processor and a memory:

the memory is used for storing program codes and transmitting the program codes to the processor;

the processor is configured to execute the steps of the method for processing an ESB system call request according to the first aspect described above according to the instructions in the program code.

A fifth aspect of the present application provides a computer-readable storage medium storing program code for executing the steps of the ESB system call request processing method described in the first aspect.

From the above technical solutions, the embodiments of the present application have the following advantages:

according to the ESB call request processing method, device, system, equipment and storage medium, through receiving an ESB request message sent by an ESB interface calling party system, marking information is obtained from a database according to a service name and a service scene carried in the ESB request message, and a characteristic value of the ESB request message is generated, so that a preset test rule is called, whether an ESB system returns a specified response message or an analog interface call timeout or normally forwards the ESB system is judged, any change is not required by the ESB interface calling party system, the ESB system or the ESB interface provider system, the abnormal scene test of the ESB interface is met, the technical problem that the ESB system or an external association system is required to be matched for completing the test call of the ESB interface, and other systems can be influenced when the ESB system is matched for carrying out the abnormal scene test is solved.

Drawings

FIG. 1 is a flow chart of a method for processing an ESB system call request according to an embodiment of the present application;

FIG. 2 is a schematic structural diagram of an ESB system call request processing device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an ESB system call request processing system according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an ESB system call request processing device in an embodiment of the present application.

Detailed Description

In order to make the present application solution better understood by those skilled in the art, the following description will clearly and completely describe the technical solution in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

The application designs a method, a device, a system, equipment and a storage medium for processing an ESB call request, which solve the technical problem that the ESB call interface can be completed only by matching an ESB system or an external association system, and the ESB system can influence other systems to call the interface when being matched for testing abnormal scenes.

For ease of understanding, referring to fig. 1, fig. 1 is a flowchart of a method for processing an ESB system call request in an embodiment of the present application, as shown in fig. 1, specifically:

it should be noted that, similar to the ESB system, the ESB request message sent by the ESB interface caller system is received by defining a preset listening port, for example, a TCP listening port or an HTTP listening port. The service name and service scene in the message can be obtained by analyzing the ESB request message.

S2, acquiring all marking information of the corresponding interface from a database according to the service name and the service scene, and sequencing all marking information according to a preset priority;

it should be noted that, based on the service name and the service scenario, all the tag information configured by the corresponding interface may be obtained from the database, and the tag information is ordered according to the preset priority.

It will be appreciated that the ESB interfaces with different functions have fixed service names and service scenes, for example, accounting, and some want to configure the baffle rules according to the payment account number in the request interface, and some want to configure the baffle rules according to the collection account number in the request interface, so that a plurality of baffle rules of the tag information can be configured for the same ESB interface.

For example, in an ESB request message for accounting, the marking information is configured to hit the payment account and the collection account at the same time, if the marking information of the payment account has higher priority, the processing is preferentially performed according to the marking information of the payment account, otherwise, the processing is performed according to the marking information of the collection account.

S3, sequentially obtaining each field value in the ESB request message from the database according to the field names of the preset request message configured in the mark information ordered according to the preset priority, and forming the characteristic value of the ESB request message;

it should be noted that, taking an actual ESB request packet as an example, the actual ESB request packet is:

if the marked information of the ESB request message is the payment account configuration feature, the feature is "// service/BODY/OUT_ACCT_NO", and the feature value is "15000113910334";

if the signature information of ESB request message is the payment account number and transaction amount, it is characterized by "// service/BODY/OUT_ACCT_NO|// service/BODY/AMT", and the characteristic value is "15000113910334|10.00".

Therefore, after the ESB request message is matched with a plurality of mark information, the feature values of the ESB request message are required to be formed by sequentially combining the feature values corresponding to the mark information.

S4, acquiring a preset test rule from the database according to the characteristic value;

it should be noted that one ESB interface corresponds to a plurality of tag information, and one tag information may correspond to a plurality of preset test rules. Then the combined characteristic value, i.e. the combined plurality of tag information, corresponds to a predetermined test rule in the database.

S5, judging whether to simulate the response message, or simulate the interface to call overtime, or forward the ESB request message to the ESB system according to the preset test rule.

It should be noted that, by analyzing the preset test rule, it is determined that the interface call of the present ESB request message is a simulated return response message, or the simulated interface call is overtime, or the normal execution call in the ESB system is directly forwarded and then returned.

If the response message is simulated, obtaining all field names and corresponding field values of the preset simulation sequence according to the corresponding rule codes of the preset test rule;

combining field values in a preset simulation sequence through a freemaker template file to obtain a simulation response message of the ESB request message;

and returning a simulation response message to the ESB interface caller system.

Further, the method further comprises the following steps:

It should be noted that, the ServerBootstrap object is provided by a netty framework, so as to improve the support of the maximum number of request connections and the processing efficiency of request connection measurement.

Further, the method further comprises the following steps:

It should be noted that, initializing the database connection pool may improve the access efficiency of the database.

It will be appreciated that the presence of the configuration file allows the listening port and the database environment to be switched by adding or modifying a different configuration file.

Referring to fig. 2, fig. 2 is a schematic structural diagram of an ESB system call request processing apparatus in the embodiment of the present application, as shown in fig. 2, specifically:

a receiving unit 201, configured to receive an ESB request packet sent by an ESB interface caller system, where the ESB request packet carries a service name and a service scenario;

the first processing unit 202 is configured to obtain all the tag information of the corresponding interface from the database according to the service name and the service scene, and sort all the tag information according to a preset priority;

a second processing unit 203, configured to sequentially obtain each field value in the ESB request packet from the database according to the field names of the preset request packet configured in the tag information ordered according to the preset priority, so as to form a feature value of the request packet;

a third processing unit 204, configured to obtain a preset test rule from the database according to the feature value;

the response determining unit 205 is configured to determine whether to simulate the response message, simulate the interface call timeout, or forward the ESB request message to the ESB system according to a preset test rule.

Further, the method further comprises the following steps:

the fourth processing unit 206 is configured to obtain field names and corresponding field values of all preset simulation sequences according to the corresponding rule codes of the preset test rules if the response message is simulated;

a simulated response message processing unit 207, configured to combine field values in a preset simulation sequence through a framemaker template file to obtain a simulated response message of the ESB request message;

and a sending unit 208, configured to return an analog response message to the ESB interface caller system.

Referring to fig. 3, fig. 3 is a schematic structural diagram of an ESB system call request processing system in the embodiment of the present application, as shown in fig. 3, specifically:

the embodiment of the application provides an ESB system call request processing device 301, an ESB interface caller system 302, a database 303, and an ESB system 304;

the ESB system call request processing device 301 is connected to an ESB interface caller system 302, a database 303, and an ESB system 304, respectively.

Further, the ESB system call request processing device 301 listens for an ESB request message of the ESB interface caller system 302 based on a preset listening port.

The embodiment of the present application further provides another ESB system call request processing device, as shown in fig. 4, for convenience of explanation, only the portion related to the embodiment of the present application is shown, and specific technical details are not disclosed, please refer to the method portion of the embodiment of the present application. The terminal can be any terminal equipment including a mobile phone, a tablet personal computer, a personal digital assistant (English full name: personal Digital Assistant, english abbreviation: PDA), a Sales terminal (English full name: point of Sales, english abbreviation: POS), a vehicle-mounted computer and the like, taking the mobile phone as an example of the terminal:

fig. 4 is a block diagram showing a part of a structure of a mobile phone related to a terminal provided in an embodiment of the present application. Referring to fig. 4, the mobile phone includes: radio Frequency (RF) circuit 1010, memory 1020, input unit 1030, display unit 1040, sensor 1050, audio circuit 1060, wireless fidelity (wireless fidelity, wiFi) module 1070, processor 1080, and power source 1090. Those skilled in the art will appreciate that the handset configuration shown in fig. 4 is not limiting of the handset and may include more or fewer components than shown, or may combine certain components, or may be arranged in a different arrangement of components.

The following describes the components of the mobile phone in detail with reference to fig. 4:

the RF circuit 1010 may be used for receiving and transmitting signals during a message or a call, and particularly, after receiving downlink information of a base station, the signal is processed by the processor 1080; in addition, the data of the design uplink is sent to the base station. Generally, RF circuitry 1010 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (English full name: low Noise Amplifier, english abbreviation: LNA), a duplexer, and the like. In addition, the RF circuitry 1010 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to global system for mobile communications (english: global System of Mobile communication, english: GSM), general packet radio service (english: general Packet Radio Service, GPRS), code division multiple access (english: code Division Multiple Access, english: CDMA), wideband code division multiple access (english: wideband Code Division Multiple Access, english: WCDMA), long term evolution (english: long Term Evolution, english: LTE), email, short message service (english: short Messaging Service, SMS), and the like.

The memory 1020 may be used to store software programs and modules that the processor 1080 performs various functional applications and data processing of the handset by executing the software programs and modules stored in the memory 1020. The memory 1020 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required for at least one function, and the like; the storage data area may store data (such as audio data, phonebook, etc.) created according to the use of the handset, etc. In addition, memory 1020 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state memory device.

The input unit 1030 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the handset. In particular, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also referred to as a touch screen, may collect touch operations thereon or thereabout by a user (e.g., operations of the user on the touch panel 1031 or thereabout using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a predetermined program. Alternatively, the touch panel 1031 may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch azimuth of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device and converts it into touch point coordinates, which are then sent to the processor 1080 and can receive commands from the processor 1080 and execute them. Further, the touch panel 1031 may be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. The input unit 1030 may include other input devices 1032 in addition to the touch panel 1031. In particular, other input devices 1032 may include, but are not limited to, one or more of a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a track ball, a mouse, a joystick, etc.

The display unit 1040 may be used to display information input by a user or information provided to the user and various menus of the mobile phone. The display unit 1040 may include a display panel 1041, and alternatively, the display panel 1041 may be configured in the form of a liquid crystal display (english full name: liquid Crystal Display, acronym: LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 1031 may overlay the display panel 1041, and when the touch panel 1031 detects a touch operation thereon or thereabout, the touch panel is transferred to the processor 1080 to determine a type of touch event, and then the processor 1080 provides a corresponding visual output on the display panel 1041 according to the type of touch event. Although in fig. 4, the touch panel 1031 and the display panel 1041 are two independent components for implementing the input and output functions of the mobile phone, in some embodiments, the touch panel 1031 and the display panel 1041 may be integrated to implement the input and output functions of the mobile phone.

The handset may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1041 according to the brightness of ambient light, and the proximity sensor may turn off the display panel 1041 and/or the backlight when the mobile phone moves to the ear. As one of the motion sensors, the accelerometer sensor can detect the acceleration in all directions (generally three axes), and can detect the gravity and direction when stationary, and can be used for applications of recognizing the gesture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometer and knocking), and the like; other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc. that may also be configured with the handset are not described in detail herein.

Audio circuitry 1060, a speaker 1061, and a microphone 1062 may provide an audio interface between a user and a cell phone. Audio circuit 1060 may transmit the received electrical signal after audio data conversion to speaker 1061 for conversion by speaker 1061 into an audio signal output; on the other hand, microphone 1062 converts the collected sound signals into electrical signals, which are received by audio circuit 1060 and converted into audio data, which are processed by audio data output processor 1080 for transmission to, for example, another cell phone via RF circuit 1010 or for output to memory 1020 for further processing.

WiFi belongs to a short-distance wireless transmission technology, and a mobile phone can help a user to send and receive emails, browse webpages, access streaming media and the like through a WiFi module 1070, so that wireless broadband Internet access is provided for the user. Although fig. 4 shows a WiFi module 1070, it is understood that it does not belong to the necessary constitution of the handset, and can be omitted entirely as required within the scope of not changing the essence of the invention.

Processor 1080 is the control center of the handset, connects the various parts of the entire handset using various interfaces and lines, and performs various functions and processes of the handset by running or executing software programs and/or modules stored in memory 1020, and invoking data stored in memory 1020, thereby performing overall monitoring of the handset. Optionally, processor 1080 may include one or more processing units; preferably, processor 1080 may integrate an application processor primarily handling operating systems, user interfaces, applications, etc., with a modem processor primarily handling wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 1080.

The handset further includes a power source 1090 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 1080 by a power management system, such as to provide for managing charging, discharging, and power consumption by the power management system.

Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which will not be described herein.

In the embodiment of the present application, the processor 1080 included in the terminal further has the following functions:

The embodiments of the present application also provide a computer readable storage medium for storing program code for executing any one of the methods for processing an ESB system call request described in the foregoing embodiments.

In the embodiment of the application, by receiving an ESB request message sent by an ESB interface caller system, acquiring tag information from a database according to a service name and a service scene carried in the ESB request message, and generating a characteristic value of the ESB request message, thereby invoking a preset test rule, judging that an analog ESB system returns a designated response message or an analog interface invocation timeout or normally forwards the ESB system, and meeting the scene test of an ESB interface abnormality without any change of the ESB interface caller system, the ESB system or the ESB interface provider system, the technical problem that the ESB system or an external association system is required to be matched for completing the test of the ESB interface, and other systems are affected to invoke the interface when the ESB system is matched for performing the abnormal scene test is solved.

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, which are not repeated herein.

The terms "first," "second," "third," "fourth," and the like in the description of the present application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be capable of operation in sequences other than those illustrated or described herein, for example. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be understood that in this application, "at least one" means one or more, and "a plurality" means two or more. "and/or" for describing the association relationship of the association object, the representation may have three relationships, for example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: u disk, mobile hard disk, read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk, etc.

The above embodiments are merely for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the corresponding technical solutions.

Claims

1. An ESB system call request processing method, comprising:

2. The ESB system call request processing method according to claim 1, wherein the step S5 further comprises:

3. The ESB system call request processing method of claim 1, further comprising:

4. The ESB system call request processing method of claim 1, further comprising:

5. An ESB system call request processing apparatus, comprising:

the second processing unit is used for sequentially acquiring each field value in the ESB request message from a database according to the field names of the preset request message configured in the marking information ordered according to the preset priority, and forming the characteristic value of the ESB request message;

6. The ESB system call request processing apparatus of claim 5, further comprising:

7. An ESB system call request processing system, comprising the ESB system call request processing apparatus according to any one of claims 5 or 6, an ESB interface caller system, a database, and an ESB system;

8. The ESB system call request processing system of claim 7, wherein the ESB system call request processing means listens for ESB request messages from the ESB interface caller system based on a preset listening port.

9. An ESB system call request processing apparatus, said apparatus comprising a processor and a memory:

the processor is configured to execute the ESB system call request processing method of any one of claims 1-4 according to instructions in the program code.

10. A computer-readable storage medium storing a program code for executing the ESB system call request processing method of any one of claims 1 to 4.