ISO message generation method and system, storage medium and computer program product

Abstract

The invention discloses an ISO message generation method and system, a storage medium and a computer program product, and relates to the technical field of data processing, and the method comprises the steps: responding to an ISO message generation request, and obtaining a target message type according to the message generation request; querying the message structure definition table to obtain target message structure definition information corresponding to the target message type; in response to the message content submission request, an input message is obtained according to the message content submission request, an ISO message is generated based on the input message, the input message comprises a message element path, a message element name and a message element value, and the message element value is a value corresponding to the message element name input in the message production interface; the message making interface is a front-end display interface rendered according to the target message structure definition information. According to the method and the device, generation of all ISO messages can be met through a set of multiplexed front and back end logics, so that the development cost is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to an ISO message generation method and system, a storage medium and a computer program product. BACKGROUND

[0002] SWIFT ISO20022 (hereinafter referred to as SWIFT ISO) is a set of financial message standards jointly formulated and maintained by the International Organization for Standardization (ISO) and the Society for Worldwide Interbank Financial Telecommunication (SWIFT), an international financial institution. It is used to realize the standardized transmission of various business information between financial institutions, such as fund transfer, payment instruction, account report, etc. The message format has a clear structure, including message header, body and message trailer, etc. The body part describes the specific business content in detail, such as transaction amount, transaction party information, business type, etc. Its standardized characteristics enable different financial institutions to exchange information efficiently and accurately, ensuring the smooth progress of financial transactions.

[0003] Currently, for the generation of SWIFT ISO messages, a specific scene front-end and back-end processing logic is usually developed for each business scene message. The front-end develops a page according to the specific scene logic to collect user input related business data; the back-end receives these data according to the specified message interface, and maps the data to the corresponding message field, and then assembles the required SWIFT ISO message format for processing.

[0004] However, this SWIFT ISO message generation method requires the development of independent front-end and back-end logic for each business scene message, which results in a large amount of time and manpower cost in the development process, and high development cost. SUMMARY

[0005] The main purpose of the present application is to provide an ISO message generation method, system, storage medium and computer program product, which aims to solve the technical problem of high development cost caused by the need to develop independent front-end and back-end logic for each business scene message in the current ISO message generation method.

[0006] To achieve the above purpose, the present application provides an ISO message generation method, which comprises the following steps: In response to an ISO message generation request, a target message type is obtained according to the message generation request; obtaining target message structure definition information corresponding to the target message type from a message structure definition table, wherein the message structure definition table stores message structure definition information corresponding to different message types; in response to a message content submission request, obtaining an input message according to the message content submission request, and generating an ISO message based on the input message, wherein the input message includes a message element path, a message element name, and a message element value, the message element value is a value corresponding to the message element name input in a message production interface, and the message production interface is a front-end display interface rendered according to the target message structure definition information.

[0007] In an embodiment, the step of obtaining target message structure definition information corresponding to the target message type from a message structure definition table includes: obtaining an ISO message standard document and a pre-constructed message structure definition model, wherein the message structure definition model includes a message element information model, a message body XML element structure definition information model, a message body XML element field type definition table model, and a message body XML element code parameter table model; parsing the ISO message standard document to obtain ISO message standard content, and mapping and writing the ISO message standard content into the message structure definition model to obtain a message structure definition table, wherein the message structure definition table includes a message element information table, a message body XML element structure definition information table, a message body XML element field type definition table, and a message body XML element code parameter table; storing the message structure definition table, so as to perform the step of obtaining target message structure definition information corresponding to the target message type from the message structure definition table based on the stored message structure definition table.

[0008] In an embodiment, the message element information model includes one or more of an element information ID, an element information type, an element information identifier, a service type, an extension type, an English name, an XML message path, an XML element name, and description information; the message body XML element structure definition information model includes one or more of an element information ID, a definition data type, a message identifier, a parent element path, a path type, an element name, an element type, an element description, a parent element name, an element order, an element group number, an element content type, an element field type name, a mandatory type, whether repeatable, a maximum number of repetitions, a repetition control expression, and a default value; The message body XML element field type definition table model includes one or more of the following fields: primary key, field type name, type-specific message identifier name, field domain table type, mandatory type, field length, verification regular expression, drop-down list type name, and field data type; The message body XML element code parameter table model includes one or more of the following fields: drop-down list type name, parameter order, parameter value, and parameter translation.

[0009] In an embodiment, after the step of obtaining the target message structure definition information corresponding to the target message type by the query message structure definition table, the method further includes: obtaining a predefined front-end message structure model, wherein the front-end message structure model includes an element field model, an element field domain model, and a drop-down list data model, the element field model is used to represent field position information of an XML element, the element field domain model is used to represent field type control information of an XML element, and the drop-down list data model is used to identify drop-down parameter list information of an XML element selector type; configuring the front-end message structure model based on the target message structure definition information to obtain front-end message structure information; parsing the front-end message structure information to generate a structure tree, and producing and rendering a message production interface according to the hierarchical relationship of the structure tree.

[0010] In an embodiment, the step of generating an ISO message based on the input message includes: performing legality detection on the input message to obtain a detection result; if the detection result indicates that the input message is legal, assembling the input message into an application message body in XML format; combining a pre-configured communication message header and an application message header with the application message body to generate an ISO message.

[0011] In an embodiment, after the step of generating an ISO message based on the input message, the method further includes: in response to a message modification request, obtaining a cached historical XML message according to the message modification request; parsing the structure of the historical XML message to generate a message tree, and obtaining or determining a structure tree corresponding to the target message structure definition information; converting the structure of the message tree to be consistent with the structure tree to obtain a converted message tree; In response to the modification content submission request, a modification input message is obtained according to the modification content submission request, wherein the modification input message comprises a message element path, a message element name, and a modified message element value, the modified message element value is a value corresponding to the message element name input in a message production echo interface, and the message production echo interface is a front-end display interface echoed according to the converted message tree. An ISO message after modification is generated based on the modification input message.

[0012] In addition, to achieve the above object, the application further provides an ISO message generation system, which comprises a front-end client device and a back-end service device. The back-end service device is configured to, in response to an ISO message generation request, obtain a target message type according to the message generation request, and query a message structure definition table to obtain target message structure definition information corresponding to the target message type, wherein the message structure definition table stores message structure definition information corresponding to different message types. The front-end client device is configured to produce and render a message production interface according to the target message structure definition information. The back-end service device is further configured to, in response to a message content submission request, obtain an input message according to the message content submission request, and generate an ISO message according to the input message, wherein the input message comprises a message element path, a message element name, and a message element value, and the message element value is a value corresponding to the message element name input in the message production interface.

[0013] In an embodiment, the front-end client device is further configured to: convert the ISO message into a print message in a preset print format, or generate a print message in a preset print format according to the input message; display the print message in a pop-up window.

[0014] In addition, to achieve the above object, the application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the ISO message generation method.

[0015] The application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the ISO message generation method.

[0016] The one or more technical solutions provided by the application have at least the following technical effects: The embodiment of the present application effectively reduces the development cost by introducing a message structure definition table and a dynamic rendering configuration interface. Specifically, the target message type is obtained by responding to a message generation request, and the corresponding message structure definition information is obtained by querying the pre-stored message structure definition table, thereby avoiding the repeated development work of separately designing the front-end and back-end logic for each message type. The message structure definition table centrally manages the structure information of different message types, so that the change or addition of message structure only needs to update the table, without modifying the code, thereby significantly reducing the development and maintenance workload. Further, the message production interface is dynamically rendered according to the target message structure definition information, which is used as a front-end display interface for user to input message element values. This makes the front-end interface no longer dependent on the hard coding of specific business scenarios, but automatically adapts to different message types through general configuration, greatly simplifying the front-end development process. Meanwhile, the input message includes message element path, name and value, and the back-end processing logic can uniformly process these structured data, directly mapping and assembling into ISO message format, without writing customized data mapping code for each message type. This design realizes the generalization and modularization of front-end and back-end logic, and can meet the generation of all ISO messages through a set of reusable front-end and back-end logic, and can quickly adapt to the demand of new message types, and can be extended through configuration rather than coding, thereby reducing the development cost. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0019] Figure 1 A flowchart of a first embodiment of the ISO message generation method of the present application; Figure 2 An ISO message structure diagram; Figure 3 A schematic diagram of the nesting relationship of the front-end message structure model involved in an embodiment of the ISO message generation method of the present application; Figure 4 A schematic diagram of the front-end message structure information involved in an embodiment of the ISO message generation method of the present application; Figure 5 A schematic diagram of the node model hierarchical relationship involved in an embodiment of the ISO message generation method of the present application; Figure 6A schematic diagram of a message making interface related to an embodiment of the ISO message generation method of the present application; Figure 7 A schematic diagram of an ISO message generation flow related to an embodiment of the ISO message generation method of the present application; Figure 8 A schematic diagram of ISO message making and ISO message filling flow related to an embodiment of the ISO message generation method of the present application; Figure 9 A schematic diagram of ISO message submission processing and ISO message modification flow related to an embodiment of the ISO message generation method of the present application.

[0020] The object, features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0021] In order to make the above-mentioned objects, features and advantages of the present application more apparent and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0022] The making of SWIFT ISO message based on configuration is an innovative scheme, and the current situation of similar technical solutions is as follows: For each business scenario message, the front-end and back-end processing logic of the specific scene is developed, the front-end develops the page according to the specific scene logic, and the back-end receives the data according to the specified message interface and maps it to the corresponding message field and assembles the required message format processing. The defects of this scheme are: 1. Large development workload and high cost, each message needs to develop a set of front-end and back-end logic; 2. Late demand changes, system modification needs to be maintained separately for each message scene, the cost of continuous iteration is high, and there is much repeated work; 3. The front-end and back-end functions may involve different periods, different teams and technology stack implementations, the technical implementation is complex and not unified, the logic scalability and flexibility are not strong, and the overall maintenance cost of the system is high; 4. The business system may need to process the specific verification of SWIFT ISO message format, the format assembly of the original text and the text, which increases the development threshold of the business system.

[0023] Based on this, the main solution of the present application is: in response to an ISO message generation request, obtaining a target message type according to the message generation request; querying a message structure definition table to obtain target message structure definition information corresponding to the target message type, wherein the message structure definition table stores message structure definition information corresponding to different message types; in response to a message content submission request, obtaining an input message according to the message content submission request, and generating an ISO message based on the input message, wherein the input message includes a message element path, a message element name, and a message element value, the message element value is a value corresponding to the message element name input in a message production interface, and the message production interface is a front-end display interface rendered according to the target message structure definition information.

[0024] The present application obtains a target message type in response to a message generation request, and queries a pre-stored message structure definition table to obtain corresponding message structure definition information, thereby avoiding repeated development work of separately designing front-end and back-end logic for each message type. The message structure definition table centrally manages the structure information of different message types, so that changes or additions of message structures only need to update the table, without modifying the code, thereby significantly reducing the development and maintenance workload. Further, the message production interface is dynamically rendered according to the target message structure definition information, and is used as a front-end display interface for user input of message element values, which makes the front-end interface no longer dependent on hard coding of specific business scenarios, but automatically adapts to different message types through general configuration, greatly simplifying the front-end development process. Meanwhile, the input message includes a message element path, a name, and a value, and the back-end processing logic can uniformly process these structured data, directly mapping and assembling into an ISO message format, without writing customized data mapping code for each message type. This design realizes the generalization and modularization of front-end and back-end logic, and can meet the generation of all ISO messages through a set of reusable front-end and back-end logic, and can quickly adapt to the needs of new message types, and can be extended through configuration rather than coding, thereby reducing development costs.

[0025] Based on this, the present application proposes an ISO message generation method of the first embodiment, in which, as shown in Figure 1 The ISO message generation method includes steps S10-S30: Step S10, in response to an ISO message generation request, obtaining a target message type according to the message generation request; The SWIFT ISO message refers to a SWIFT ISO20022 standard message, which is the latest generation of communication message standard promoted by SWIFT organization worldwide, and the message content organization mode is mainly based on XML structure, referring to Figure 2As shown, the ISO message standard mainly includes the contents of the Header communication message header, AppHeader application message header, and Body application message body 3 parts. The content structure of the Header communication message header and the AppHeader application message header is relatively fixed, and the message production and organization are relatively easy to implement in technology, and can be processed according to the fixed model and assignment logic requirements. The content in the Body application message is related to the message type, and the structures corresponding to different message types are not the same. Therefore, the embodiments of the present application mainly aim at the production (or generation) of the message content in the Body.

[0026] In actual application, a user can initiate an ISO message generation request through a front-end interface. The request includes information of a target message type, for example, a specific SWIFT message type code such as “pacs.009.001.08” or “pacs.009.001.08_COV”. After receiving the request, the back-end service device parses the request content and extracts the target message type.

[0027] In step S20, target message structure definition information corresponding to the target message type is obtained by querying a message structure definition table. The message structure definition table stores message structure definition information corresponding to different message types. After determining the target message type, the back-end service device queries a pre-stored “message structure definition table”. The definition table, as a core configuration database, stores the structure blueprint of all supported message types. The structure definition information describes the standard format of the corresponding message type, which usually includes but is not limited to: the path (position in the message tree structure), name, data type, whether to fill in, length limit, and format rule of all possible fields (message elements) in the message. The “target message structure definition information” exactly matching the “target message type” obtained is retrieved from the table as a query key, providing data support for subsequent interface rendering and message assembly.

[0028] In step S30, in response to a message content submission request, an input message is obtained according to the message content submission request, and an ISO message is generated based on the input message. The input message includes a message element path, a message element name, and a message element value. The message element value is the value corresponding to the message element name input in the message production interface. The message production interface is a front-end display interface rendered according to the target message structure definition information.

[0029] This step can be further divided into three sub-processes: First, interface rendering and data entry: the front-end client device uses the obtained "target message structure definition information" to drive the front-end to dynamically render a dedicated "message production interface", i.e. the target configuration interface. This interface is a form generated in real time according to the field path, name and rules of the target message structure definition information, and each form item corresponds to a message element. The user inputs or selects specific "message element values" in each form item according to business needs in this interface.

[0030] Second, structured data submission: when the user completes the form and submits it, a "message content submission request" is triggered. The front-end encapsulates the original form data into a structured "input message" object. This object clearly organizes the data, including the "message element path" (used to locate the element position), "message element name" and corresponding user input "message element value" of each field.

[0031] Finally, message assembly and generation: after the backend receives this structured "input message", it fills in the corresponding values according to the pre-set "message element path" and "message element value" in it, combined with the relevant message format standard (such as SWIFT ISO 20022), like filling in the blanks, accurately filling each value into the corresponding position of the message template, generating the application message body part, and finally assembling it with the communication message header and application message header into a complete format, standard-compliant ISO message, thus completing the generation of the ISO message.

[0032] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the subsequent will not be repeated. On this basis, the step of obtaining the target message structure definition information corresponding to the target message type from the query message structure definition table includes: Step A10, obtaining ISO message standard documents and pre-constructed message structure definition models, wherein the message structure definition models include message element information models, message body XML element structure definition information models, message body XML element field type definition table models, and message body XML element code parameter table models; Obtain authoritative ISO message standard documents (such as XSD or PDF documents officially published by SWIFT or ISO 20022), which define the format specifications of various messages in machine-readable or human-readable form. At the same time, a set of structured "message structure definition models" is pre-installed in the backend service device. This model is a logical data model designed to deconstruct and transform the complex specifications in the standard documents into structured data that can be managed and used by the system.

[0033] The message meta information model is used to define the overall metadata of the message type. Specifically, the message meta information model can include one or more fields shown in Table 1, and in this embodiment, all the fields shown in Table 1 are included.

[0034]

[0035] Table 1 The message body XML element structure definition information model is used to describe the structure of the message body. Specifically, the message body XML element structure definition information model can include one or more fields shown in Table 2, and in this embodiment, all the fields shown in Table 2 are included.

[0036]

[0037] Table 2 The message body XML element field type definition table model is used to define the type constraint of each data field in the message. Specifically, the message body XML element field type definition table model can include one or more fields shown in Table 3, and in this embodiment, all the fields shown in Table 3 are included.

[0038]

[0039] Table 3 The message body XML element code parameter table model is used to define the drop-down parameter code value and other information of the SEL selector, i.e., the drop-down list type field. Specifically, the message body XML element code parameter table model can include one or more fields shown in Table 4, and in this embodiment, all the fields shown in Table 4 are included.

[0040]

[0041] Table 4 In step A20, the ISO message standard document is parsed to obtain the ISO message standard content, and the ISO message standard content is mapped and written into the message structure definition model to obtain a message structure definition table. The message structure definition table includes a message meta information table, a message body XML element structure definition information table, a message body XML element field type definition table, and a message body XML element code parameter table. The ISO message standard document obtained is parsed by a parsing program to extract all standard content about message structure, field, data type, and code set. Subsequently, the backend service device fills the extracted standardized content into the pre-constructed message structure definition model according to the semantics. The result of this mapping process is to generate a specific message structure definition table that can be stored by a database and queried by a program. Specifically, the message structure definition table includes: Message meta-information table: stores the basic information of all supported message types.

[0042] Message body XML element structure definition information table: stores the path and structure relationship of elements under each message type.

[0043] Message body XML element field type definition table: stores the specific data type and format constraints of each field.

[0044] Message body XML element code parameter table: stores the legal value set of each code type field.

[0045] For example, the message meta-information table constructed in a specific application scenario can be understood by the content shown in Table 5 below. It is worth noting that the message structure definition table in this embodiment is essentially a set of interrelated structured data tables, including message meta-information table, message body XML element structure definition information table, message body XML element field type definition table, and message body XML element code parameter table. These data tables are logically homogeneous, that is, they are organized in a row and column relationship model, and their table structure presentation is similar to the example shown in Table 5 below. To avoid unnecessary repetition, only Table 5 is shown as a representative, and the remaining tables are not described in detail.

[0046]

[0047] Table 5 Step A30, store the message structure definition table, and based on the stored message structure definition table, perform the step of querying the message structure definition table to obtain the target message structure definition information corresponding to the target message type.

[0048] The generated message structure definition table is stored in the backend service device for subsequent querying and using. When the target message structure definition information corresponding to the target message type needs to be queried, it can be directly obtained from the stored message structure definition table. This process ensures the accuracy and consistency of the message structure definition information, and also improves the maintainability. In this way, the backend service device can quickly respond to message generation requests, dynamically generate messages conforming to the SWIFT ISO standard, and greatly reduce the development cost and maintenance difficulty.

[0049] Based on the first embodiment and / or the second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as the above-mentioned first embodiment and second embodiment can be referred to the above introduction, and will not be described in detail. On this basis, after the step of querying the message structure definition table to obtain the target message structure definition information corresponding to the target message type, the method further comprises: Step B10: Obtain a predefined front-end message structure model, wherein the front-end message structure model includes an element field model, an element field domain model, and a drop-down list data model. The element field model is used to represent the field position information of XML elements, the element field domain model is used to represent the field type control information of XML elements, and the drop-down list data model is used to identify the drop-down parameter list information of XML element selector types. This front-end message structure model is a fundamental framework for building front-end user interfaces. It comprises three key parts: the element field model, the element field domain model, and the dropdown list data model. The element field model represents the field location information of XML elements, that is, the specific location and path of each field in the XML structure. The element field domain model represents the field type control information of XML elements. The dropdown list data model identifies the dropdown parameter list information of XML element selector types; when a field is a selector, it provides a list of selectable parameters. These models together constitute a complete description of the front-end message structure, providing the necessary information for subsequent interface generation.

[0050] Specifically, the element field model may include one or more fields as shown in Table 6 below.

[0051]

[0052] Table 6 The element field domain model may include one or more fields as shown in Table 7 below.

[0053]

[0054] Table 7 The dropdown list data model may include one or more fields as shown in Table 8 below.

[0055]

[0056] Table 8 It should be noted that the relationship between these three models is as follows: an element field may contain a child element field model, the child element field model is the same as the element field model, an element field may contain an element field domain model, and the field types contained in the element field domain model may be dropdown list data models. For example, in one application scenario, refer to... Figure 3As shown, the ISO message definition structure can be nested using the three models, and the entire structure starts with a "ROOT root business element", which contains "element field A" and "element field D". Element field A includes element field a1 and element field a2. The element field model of element field a1 nests the field domain information of the field, i.e., the field domain model. The element field model of element field a2 nests the field domain information of the field. Element field A also has a "sub-element field information", which contains two element fields: element field B, which has a sub-field domain information below; and element field C, which has two sub-element field information below: element field c1, which has a sub-field domain information below; and element field c2, which has a sub-field domain information below. Element field D has a "sub-element field information" below, which is "empty".

[0057] Step B20, configuring the front-end message structure model based on the target message structure definition information to obtain front-end message structure information; The target message structure definition information obtained by the query is used as configuration data source to perform instantiation configuration on the obtained general front-end message structure model. Specifically, the message element path, data type, code parameter, etc. in the back-end definition are mapped and filled into the element field model, element field domain model and drop-down list data model of the front end, respectively. This configuration process generates a specific front-end message structure information object customized for the current target message type, which describes all the data and rules required for rendering the final interface. As an example, part of the front-end message structure information obtained by the configuration in an application scenario is as shown in the following table. Figure 4

[0058] Step B30, parsing the front-end message structure information to generate a structure tree, and making and rendering a message making interface according to the hierarchical relationship of the structure tree.

[0059] The front-end client device parses the generated front-end message structure information. The parsing engine constructs a structure tree according to the field position, type and association relationship defined therein, and the tree structure reflects the hierarchical and subordinate relationship between message elements.

[0060] Specifically, the element field model in the message structure can be split into paragraphs and paragraph contents, and the field domain model in the message structure can be split into fields, field contents and sub-fields, each sub-field corresponding to an actual input control. The structure tree can be obtained by splitting the nodes into paragraphs, paragraph contents, fields, field contents and sub-fields, and organizing the split nodes according to the hierarchical relationship between them. The relationship between these paragraphs, paragraph contents, fields, field contents, sub-fields and each sub-field corresponding to an actual input control can be represented as follows: Figure 5 ​The tree structure shown, all nodes are under a node, each node is described as follows: Root node: responsible for parsing the message structure and the original content of the message, is the root component of all the above components. The root node provides a method registration method to all sub-components. After the sub-component is loaded, register the related methods in the root node, including the value method, the value setting method, the focus method, the verification method, etc. Paragraph node: contains paragraph content node, controls whether the paragraph content is repeatable and the deletion of repeated sessions, whether to enable, whether to fold; Paragraph content node: contains repeatable paragraph node and field node, controls the mode switching of multi-mode paragraph; Field node: contains field content node, controls whether the field domain is repeatable and the deletion of repeated sessions; Field content node: contains sub-field node and field node, controls the type display of the field domain; Sub-field node: controls the field type of the sub-field; Actual input control: controls the actual display control type, there are the following forms of input control: amount input control, date input control, ordinary input control, long text control, time input control, and drop-down selection control.

[0061] Further, the text input control and verification rules of the actual control can be controlled, the value, value setting, focus, and verification methods are registered to the root node, and the XML path of the field domain is used as the unique key to distinguish the methods of different field domains.

[0062] Subsequently, by using the front-end UI framework (such as Vue, React, etc.), the hierarchical relationship of this structure tree can be recursively traversed, and according to the field domain model (such as text box, drop-down box) and drop-down list data model corresponding to each node, the corresponding form controls can be dynamically made. Finally, these controls are rendered into the message making interface visible and operable by the user in the browser according to the predetermined level and layout, that is, the target configuration interface. For example, in an application scenario, the rendered message making interface local content is as shown in Figure 6 .

[0063] It should be noted that when the user completes the configuration in the message production interface, i.e., the production is completed, the root node can call the checksum value method of all child field nodes. If the check fails, the user will be prompted with error information, and the focus method of the error node will be called to focus the form on the specified error node. If the check passes, the message element path, message element name, and message element value are obtained, which are assembled into an input message and submitted to the backend service device. For example, in an application scenario, part of the input message content is as follows, and the input message is in JSON format, wherein xpath represents the message element path, nodeName represents the message element name, and nodeValue represents the message element value, which is usually the value input by the user in the message production interface: { "xpath" : " / FIToFICstmrCdtTrf / GrpHdr / MsgId", "nodeName" : "MsgId", "nodeValue" : "ASW0006ZI00005P" }, { "xpath" : " / FIToFICstmrCdtTrf / GrpHdr / CreDtTm", "nodeName" : "CreDtTm", "nodeValue" : "2024-10-15T10:58:11+08:00" }, { "xpath" : " / FIToFICstmrCdtTrf / GrpHdr / NbOfTxs", "nodeName" : "NbOfTxs", "nodeValue" : "1" }。

[0064] In a possible implementation, the step of generating an ISO message based on the input message comprises: Step C10, performing legality detection on the input message to obtain a detection result; According to the obtained target message structure definition information, the received input message is subjected to legitimacy detection. The detection content can include but is not limited to: element path detection (such as whether the message element path exists), data format verification (such as whether the date format is YYYY-MM-DD and the number format is correct), length verification (such as whether the field value exceeds the maximum length limit), code value legitimacy verification (such as whether the input currency code exists in the pre-defined code parameter table), and mandatory field integrity verification (such as whether all marked mandatory message elements have provided valid values). Finally, the backend service device generates a detection result, which explicitly indicates whether the current input message passes all checks.

[0065] Step C20, if the detection result indicates that the input message is legitimate, the input message is assembled into an XML format application message body; After confirming that the input message passes all legitimacy detection, the backend service device starts the message assembly process. The assembly process converts the structured input message data into a format-strict XML document according to the standard XML Schema definition of the message. According to the message element path (for example, Doc:CdtTrfTxInf / Amt / InstdAmt) carried by each data item in the input message, the backend service device accurately fills the message element value of the data item into the corresponding node position of the generated XML document tree, and supplements the necessary XML tags and namespace declarations, finally building a complete, standard and ISO 20022 standard-compliant XML format application message body.

[0066] Further, the input message can also be assembled into a print format according to actual needs to facilitate manual reading and printing of archives.

[0067] For example, in an application scenario, the generation process of the application message body can be as follows Figure 7As shown, first, the structured field data input, i.e. the input message, is acquired, and then an ISO Document document is created as a container for the generated message. Subsequently, the ISO message definition without field domains is queried to obtain the skeleton structure of the message; and the XPATH path (i.e. the message element path) of the input field is checked to see whether it exists in the definition, ensuring the data is mappable, and if the XPATH path of the input field exists, all node information (i.e. message elements) is generated according to the input XPATH path into the XML document, and the relative order between nodes is rearranged according to the definition, thereby ensuring that the generated XML document conforms to the ISO standard in structure. Next is the format conversion and checking link: the built XML document is converted into XML original data without indentation and line breaks to meet the format requirements of the SWIFT network transmission. Then, the XML message schema or the official SWIFT tool is called to check the legality of the message. Finally, the print format is assembled according to the requirements to generate the final ISO message that can be sent, archived or displayed.

[0068] For example, in an application scenario, the generated application message body is as follows: <document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.009.001.08"> <ficdttrf> <grphdr> <msgid>NOTPROVIDED< / msgid> <credttm> 2025-08-05T15:24:48+08:00< / credttm> <nboftxs> 1< / nboftxs> <sttlminf> <sttlmmtd>INDA< / sttlmmtd> <sttlmacct> <id> <othr> <id> 80015008023014< / id> < / othr> < / id> < / sttlmacct> < / sttlminf> < / grphdr> <cdttrftxinf> <amtid> <instrid>128RF2522112< / instrid> <endtoendid> 123456< / endtoendid> <uetr>e91bc3ba-07fe-4a8d-b969-cce333afa5e8< / uetr> < / amtid> <intrbksttlmamt ccy="USD"> 200< / intrbksttlmamt> <intrbksttlmdt> 2024-09-26< / intrbksttlmdt> <instgagt> <fininstnid> <bicfi>CMBCCNBSXXX< / bicfi> < / fininstnid> < / instgagt> <instgagt> <fininstnid> <bicfi>SZDBCNBSXXX< / bicfi> < / fininstnid> < / instgagt> <dbtr> <fininstnid> <bicfi>CMBCNBS050< / bicfi> < / fininstnid> < / dbtr> <cdtr> <fininstnid> <bicfi>SZDBCNBSXXX< / bicfi> < / fininstnid> < / cdtr> <rmtinf> <ustrd>NODEDUCT / BNF / BEING OUR 123456< / ustrd> < / rmtinf> < / cdttrftxinf> < / ficdttrf> < / document> The corresponding print format message is as follows: From FinancialInstitutionIdentification FinancialInstitutionIdentification BICFI: CMBCCNBSXXX CHINA MERCHANTS BANK HEAD OFFICE SHENZHEN To FinancialInstitutionIdentification FinancialInstitutionIdentification BICFI: SZDBCNBSXXX BANK OF CHINA HEAD OFFICE BEIJING MessageDefinitionIdentifier: pacs.009.001.08 BusinessService: swift.cbrplus.02 CreationDate: 05 / 08 / 2025 15:24:49 +08:00 Priority: NORM - Normal GroupHeader MessageIdentification: NOTPROVIDED CreationDateTime: 2025-08-05T15:24:49+08:00 NumberOfTransactions: 1 SettlementInformation SettlementMethod: INDA SettlementAccount Identification Other Identification: 80015008023014 CreditTransferTransactionInformation PaymentIdentification InstructionIdentification: 128RF2522112 EndToEndIdentification: 123456 UETR: e91bc3ba-07fe-4a8d-b969-cce333afa5e8 InterbankSettlementAmount: 200 Currency: USD InterbankSettlementDate: 2024-09-26 InstructingAgent FinancialInstitutionIdentification BICFI: CMBCCNBSXXX CHINA MERCHANTS BANK HEAD OFFICE SHENZHEN InstructedAgent Financial Institution Identification BIC FI: SZDBCNBSXXX BANK OF CHINA HEAD OFFICE BEIJING Step C30, combine the pre-configured communication message header and application message header with the application message body to generate an ISO message.

[0069] A complete ISO message is usually composed of three parts: Communication message header: a general header irrelevant to the specific business content, used for routing and control at the network transmission level, such as BIC code identifying the sender and the receiver, message priority, creation timestamp, etc., which can be pre-configured.

[0070] Application message header: a header generated according to the context, located within the communication message header, used for identification at the application level, such as defining the message type (e.g. pacs.009.001.08) and the message identifier, which can also be pre-configured.

[0071] Application message body: the generated XML document containing specific business data.

[0072] The backend service device will combine the above three parts according to the encapsulation specification required by the SWIFT network, finally generating an ISO message with complete structure, which can be directly used for sending or subsequent processing. This design decouples the generation logic of the message header from the message body, realizes the reuse of general components, and further reduces the development and maintenance cost.

[0073] Based on the first embodiment, the second embodiment and / or the third embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as the above-mentioned first embodiment, second embodiment and third embodiment can be referred to the above introduction, and the subsequent will not be described in detail. On this basis, after the step of generating an ISO message based on the input message, the method further comprises: Step D10, in response to the message modification request, obtaining the cached historical XML message according to the message modification request; When the user needs to modify the generated ISO message, the message modification request can be submitted through the front-end client device. After the backend service device receives the message modification request submitted by the front-end client device, the historical XML message copy of the message retained since the last generation is obtained from the cache, i.e. the application message body generated last time.

[0074] Step D20, parsing the structure of the historical XML message to generate a message tree, obtaining or determining the structure tree corresponding to the target message structure definition information; The obtained historical XML message is parsed into a DOM structure object, and the DOM object is converted into an N-ary tree, each node containing an XML path and a message field value, denoted as a message tree.

[0075] The generation method of the structure tree can refer to the above embodiment, which will not be repeated here.

[0076] Step D30, converting the structure of the message tree into the structure tree to obtain the converted message tree; Since the message standard may be updated, or there are version differences in the generation of historical messages, the message tree obtained by direct parsing may not be completely consistent with the current standard structure tree in node path, order or existence. The backend service device performs a structure conversion operation, taking the foregoing standard structure tree as a reference, to align the nodes, eliminate redundant nodes or supplement missing nodes of the message tree, to ensure that the converted message tree is consistent with the current standard definition in structure.

[0077] Step D40, in response to a modification content submission request, obtaining a modification input message according to the modification content submission request, wherein the modification input message includes a message element path, a message element name and a modified message element value, the modified message element value is the value corresponding to the message element name input in the message production echo interface, and the message production echo interface is a front-end display interface echoed according to the converted message tree; A message production echo interface is dynamically rendered using the converted message tree. This interface has the same logic as the configuration interface when it is initially generated, but its initial value is not blank, but the data of each node in the converted message tree is echoed in the corresponding form item, providing a visual editing environment for the user. After the user completes the modification and submits on the interface, the backend service device receives the modification content submission request and extracts the structured modification input message therefrom. The message has the same structure as the initial input message, including the message element path, the message element name and the modified message element value input by the user, and if not modified, the original message element value is still used.

[0078] Step D50, generating a modified ISO message based on the modification input message.

[0079] The obtained modification input message is used as a new data source to re-execute the message generation process, and finally a modified ISO message containing all the user's modification content is generated. This ensures that the modification operation and the initial generation operation share the same set of core logic, ensuring the consistency of the behavior and the maintainability of the system.

[0080] Exemplarily, in order to help understand the technical concept or technical principle of the ISO message generation method combined with the above-mentioned first embodiment, second embodiment and third embodiment, a specific embodiment is listed, in which, referring to Figures 8 to 9 As shown in the figure, the ISO message generation process includes ISO message making, ISO message filling, ISO message submission processing and ISO message modification stage.

[0081] Specifically, referring to Figure 8 As shown in the figure, the ISO message making stage specifically includes: the user enters the message making page through the user interface of the front-end client device, the message making page sends an ISO message generation request to the back-end service device, the back-end service device responds to the ISO message generation request, and acquires the required message structure definition information, i.e. the target message structure definition information, according to the target message type to query the ISO message definition table, i.e. the message structure definition table. The message making page in the front-end client device is rendered and initialized according to the acquired message structure definition information, and provides a visual message making interface, i.e. a target configuration interface, for the user.

[0082] Referring to Figure 8 As shown in the figure, the ISO message filling stage specifically includes: the user fills in the message content, i.e. the message element value, in the message making interface page, and when the user finishes inputting in a field, triggers a field defocus event, and performs field legality verification on the message content filled by the user to further verify the legality of the field content.

[0083] Referring to Figure 9 As shown in the figure, the ISO message submission processing stage includes: after the user completes the filling and verification of the message content, the user sends an ISO message making submission request, i.e. a message content submission request, to the back-end service device. The back-end service device responds to the request, queries the ISO message definition table to acquire the message structure definition information, performs structure verification and message content Schema verification, etc. If it is detected that the input message is legal, the input message is assembled into an ISO body format to obtain an application message body, and then combined with a communication message header and an application message header to obtain an ISO message. The ISO message, XML original text (i.e. the application message body) and the body format text content (i.e. the application message body in print format) are returned to the front-end client device for subsequent processing, such as caching the returned content, sending the ISO message, etc. Further, the front-end client device can display the ISO message print format to the user through a pop-up window.

[0084] Referring to Figure 9As shown, the ISO message modification stage includes: the message making page sends a message modification request to the backend service device, the backend service device responds to the message modification request, queries the ISO message definition table according to the target message type, and obtains the required message structure definition information. If the front-end client device does not have message content cache, it queries the service-end saved message content, and queries the saved ISO message original text and print format from the backend service device. Then, the front-end client device requests the backend service device to parse the ISO message into structured key-value pair information, the backend service device performs XML message parsing processing on the assembled ISO message to generate a message tree, and the front-end client device makes and renders a page based on the message tree and performs data echoing.

[0085] It should be noted that the above examples are only used to assist in understanding the present embodiment and do not constitute a limitation on the ISO message generation process of the present embodiment. More forms of simple transformation based on this technical concept are within the protection scope of the present application.

[0086] In addition, the present embodiment further proposes an ISO message generation system, which comprises a front-end client device and a backend service device. The backend service device is configured to respond to an ISO message generation request, obtain a target message type according to the message generation request, and query a message structure definition table to obtain target message structure definition information corresponding to the target message type, wherein the message structure definition table stores message structure definition information corresponding to different message types. The front-end client device is configured to make and render a message making interface according to the target message structure definition information. The backend service device is further configured to respond to a message content submission request, obtain an input message according to the message content submission request, and generate an ISO message according to the input message, wherein the input message comprises a message element path, a message element name, and a message element value, and the message element value is a value corresponding to the message element name input in the message making interface.

[0087] In a possible implementation, the front-end client device is further configured to: convert the ISO message into a print message in a preset print format, or generate a print message in a preset print format according to the input message; display the print message in a pop-up window.

[0088] The embodiment provides two feasible technical paths to realize the visual output of the message. The first path is based on the generated ISO message conforming to the SWIFT standard. The ISO message is converted from the standard XML format into a preset printing format (for example, a structured PDF document, a fixed format text file or an HTML page with clear layout) which is easier for human to read and archive through a preset format conversion engine. The second path is to directly use the previously collected structured input message data to generate a printing message with consistent format according to the same printing template rule. The two methods ensure that the required visual output result can be obtained flexibly in different business scenarios.

[0089] The front-end interaction logic can automatically trigger a browser pop-up window (or modal dialog box), and the printing message content generated in the foregoing steps is completely rendered and displayed in the window. In this way, the closed loop of user operation is realized, and the user can intuitively check and review the final content of the message in the current context without jumping to another page or starting an external program, thereby effectively improving the operation efficiency and user experience.

[0090] In addition, to achieve the above object, the embodiment of the present application further provides a readable storage medium having computer readable program instructions (i.e. computer programs) stored thereon, and the computer readable program instructions are used to execute the ISO message generation method in the above embodiment.

[0091] The computer readable storage medium provided by the embodiment of the present application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to: electrical wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0092] The computer readable storage medium described above can be included in the electronic device; or can exist independently of the electronic device.

[0093] The computer readable storage medium described above carries one or more programs, which when executed by the electronic device, cause the electronic device to perform the flow steps of any of the embodiments described above.

[0094] Computer program code for carrying out operations of the present application can be written in any of one or more programming languages or combinations of languages including object or visual programming languages such as Java, Smalltalk, C++ or conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0095] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in some cases, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.

[0096] The modules involved in the embodiments described in the present application can be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0097] The readable storage medium provided by the application is a computer readable storage medium, and the computer readable storage medium stores computer readable program instructions (namely, a computer program) for executing the ISO message generation method described above, and can solve the high development cost caused by the need to develop independent front-end and back-end logic for each service scenario message in the current ISO message generation mode. Compared with the prior art, the beneficial effects of the computer readable storage medium provided by the application are the same as those of the ISO message generation method provided by the above-mentioned embodiments, and will not be repeated here.

[0098] In addition, the embodiments of the application also provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the ISO message generation method described above.

[0099] The computer program product specific embodiments of the application are basically the same as the above-mentioned ISO message generation method, and will not be repeated here.

[0100] It should be noted that in this paper, the terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or system including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or system. Without more limitations, the element defined by the sentence "includes a" does not exclude the presence of other identical elements in the process, method, article or system including the element.

[0101] The serial numbers of the above-mentioned embodiments of the application are only for description, not representing the advantages and disadvantages of the embodiments.

[0102] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and necessary general hardware platform, of course, it can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the application can be embodied in the form of software sensors, which are stored in a storage medium (such as ROM / RAM, magnetic disc, optical disc) and include a plurality of instructions for making a terminal device (which can be a mobile phone, computer, server or network device, etc.) execute the methods described in various embodiments of the application.

[0103] The above is only the preferred embodiment of the application, and does not limit the patent scope of the application, and any equivalent structure or equivalent process transformation using the content of the application specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the application.

Claims

1. An ISO message generation method, characterized by, The ISO message generation method comprises the following steps: In response to an ISO message generation request, obtaining a target message type according to the message generation request; Querying a message structure definition table to obtain target message structure definition information corresponding to the target message type, wherein the message structure definition table stores message structure definition information corresponding to different message types; In response to a message content submission request, obtaining an input message according to the message content submission request, and generating an ISO message based on the input message, wherein the input message includes a message element path, a message element name, and a message element value, the message element value is a value corresponding to the message element name input in a message production interface, and the message production interface is a front-end display interface rendered according to the target message structure definition information.

2. The ISO message generation method of claim 1, wherein, The step of querying the message structure definition table to obtain the target message structure definition information corresponding to the target message type comprises: Obtaining an ISO message standard document and a pre-constructed message structure definition model, wherein the message structure definition model includes a message element information model, a message body XML element structure definition information model, a message body XML element field type definition table model, and a message body XML element code parameter table model; Parsing the ISO message standard document to obtain ISO message standard content, and mapping and writing the ISO message standard content into the message structure definition model to obtain a message structure definition table, wherein the message structure definition table includes a message element information table, a message body XML element structure definition information table, a message body XML element field type definition table, and a message body XML element code parameter table; Storing the message structure definition table, so as to perform the step of querying the message structure definition table to obtain the target message structure definition information corresponding to the target message type based on the stored message structure definition table.

3. The ISO message generation method of claim 2, wherein, The message element information model includes one or more fields of meta-information ID, meta-information type, meta-information identifier, service type, extension type, English name, XML message path, XML element name, and description information; The message body XML element structure definition information model includes one or more fields of meta-information ID, definition data type, message identifier, parent element path, path type, element name, element type, element description, parent element name, element order, element grouping number, element content type, element field type name, mandatory type, whether repeatable, maximum number of repetitions, repetition control expression, and default value; The message body XML element field type definition table model includes one or more fields of primary key, field type name, type-specific message identifier, field domain form type, mandatory type, field length, verification regular expression, drop-down list type name, and field data type; The message body XML element code parameter table model includes one or more fields of drop-down list type name, parameter order, parameter value, and parameter translation.

4. The ISO message generation method of claim 1, wherein, After the step of querying the message structure definition table to obtain the target message structure definition information corresponding to the target message type, the method further comprises: obtaining a predefined front-end message structure model, wherein the front-end message structure model comprises an element field model, an element field domain model, and a drop-down list data model, the element field model is used to represent field position information of an XML element, the element field domain model is used to represent field type control information of the XML element, and the drop-down list data model is used to identify drop-down parameter list information of an XML element selector type; configuring the front-end message structure model based on the target message structure definition information to obtain front-end message structure information; parsing the front-end message structure information to generate a structure tree, and producing and rendering a message production interface according to a hierarchical relationship of the structure tree.

5. The ISO message generation method of claim 1, wherein, The step of generating an ISO message based on the input message comprises: performing legality detection on the input message to obtain a detection result; if the detection result indicates that the input message is legal, assembling the input message into an application message body in XML format; combining a pre-configured communication message header and an application message header with the application message body to generate an ISO message.

6. The ISO message generation method of claim 1, wherein, After the step of generating an ISO message based on the input message, the method further comprises: in response to a message modification request, obtaining a cached historical XML message according to the message modification request; parsing a structure of the historical XML message to generate a message tree, and obtaining or determining a structure tree corresponding to the target message structure definition information; converting a structure of the message tree to be consistent with the structure tree to obtain a converted message tree; in response to a modification content submission request, obtaining a modification input message according to the modification content submission request, wherein the modification input message comprises a message element path, a message element name, and a modified message element value, the modified message element value is a value corresponding to the message element name input in a message production echo interface, and the message production echo interface is a front-end display interface echoed according to the converted message tree; generating a modified ISO message based on the modification input message.

7. An ISO message generation system characterized by comprising: The ISO message generation system comprises a front-end client device and a back-end service device. The back-end service device is configured to, in response to an ISO message generation request, obtain a target message type according to the message generation request, and query a message structure definition table to obtain target message structure definition information corresponding to the target message type, wherein the message structure definition table stores message structure definition information corresponding to different message types. The front-end client device is configured to produce and render a message production interface according to the target message structure definition information. The back-end service device is further configured to, in response to a message content submission request, obtain an input message according to the message content submission request, and generate an ISO message based on the input message, wherein the input message comprises a message element path, a message element name, and a message element value, and the message element value is a value corresponding to the message element name input in the message production interface.

8. The ISO message generation system of claim 7, wherein, The front-end client device is further configured to: convert the ISO message into a print message in a preset print format, or generate a print message in a preset print format according to the input message; display the print message in a pop-up window.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores an ISO message generation program, and the ISO message generation program, when executed by a processor, implements the steps of the ISO message generation method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer program product comprises an ISO message generation program, and the ISO message generation program, when executed by a processor, implements the steps of the ISO message generation method according to any one of claims 1 to 6.

Images