TWM647873U - Delivery definition conversion system for non-physical security transaction message - Google Patents

Abstract

This new model provides a delivery definition conversion system for non-physical ticket transaction information, which includes a transmission module, a definition building module and a conversion processing module for building a plurality of field definition data arranged in sequence. Each field definition data includes a field code, an actual length, a type and a group, and the actual length is the sum of integer digits, decimal point sign and decimal point digits; use these columns in order The bit definition data starts from the first character of the message and calculates the first format transaction message of plain text and uses the actual length to calculate and intercept the message content to form the corresponding field data; parse each field data and obtain the content as @ When @ is set, the field data is set to a first-level data; when the content is ##, the field data is set to a second-level data; the above-mentioned relevant data is compiled and the message is converted into a second-format transaction message of XML. It is a message transmission and delivery workstation installed between at least one participating party's server system and a Taiwan Toll Insurance System to convert a plurality of transaction messages in the first format transmitted between the two systems into a plurality of the second format. Transaction information to achieve efficient and highly accurate information communication effects.

Description

Delivery definition conversion system for non-physical ticket transaction messages

This new model is related to the transaction message delivery system of Taiwan's ticket collective insurance, especially a delivery definition conversion system for non-physical ticket transaction messages.

In order to promote the dematerialization of short-term notes and the centralized settlement and delivery system, the competent authority has approved the implementation and operation of the Taiwan Note Insurance System to coordinate the centralized custody of short-term notes and provide financing by connecting with the central bank's co-funded system. The settlement and delivery mechanism for both securities and securities is based on this to achieve the goal of building a safe and efficient settlement and delivery environment and promoting the sound development of the money market. To this end, CHEP participants such as securities companies, bill companies, and banks have successively purchased and built corresponding server systems to meet the demand for integrated services in this market. However, with the increase in market service demand or changes in the ticket trading system, Taiwan's ticket collective insurance system has continuously upgraded the specifications of software and hardware facilities and adopted more optimized message formats. The security and speed of transactions have also led to the dilemma that the server systems of participants may not be able to keep up with the times.

For example, the message format of the Taiwan Chit-Packet Insurance System adopts the commonly used XML format. However, many participating server systems still use plain text message format to transmit transaction messages, resulting in frequent errors between the two systems due to different message formats. The participant's server system was unable to query relevant data immediately after sending the transaction message, which raised doubts about the security of the physical ticket transaction. Furthermore, after transaction messages in different formats are encrypted by the hardware encryption mechanism, it is easier for participants to There was a problem that messages could not be read or were incorrect between the server system and the Taiwan Bill Insurance System, resulting in non-real-time and inefficient transmission of transaction messages.

In view of this, how to provide a non-physical ticket transaction message delivery system that can easily ensure the consistency of the transmission of encrypted message formats without the need to update or replace the hardware equipment, so as to improve the above-mentioned shortcomings of the conventional technology? , which is the subject that this novel wants to explore.

In view of the above problems, the purpose of this new model is to provide a delivery definition conversion system for incorporeal bill transaction information to integrate and convert the insubstantial bill management system, clearing and delivery bank system and Taiwan Bill Insurance Company from participating units. The format of the ticket transaction message of the system, etc., and provides the correct encrypted message format between the participating units and the Taiwan Ticket Collection Insurance System through the system software computing mechanism to transmit the transaction message, allowing either party to still search for the message after the message is sent. To achieve the establishment of an immediate and efficient settlement and delivery environment.

In order to achieve the above purpose, the present invention discloses a delivery definition conversion system for non-physical ticket transaction messages, which is a message delivery workstation set up between at least one participant server system and a Taiwan Note Collection Insurance System to transmit the delivery definition. A plurality of first-format transaction messages between the two systems are respectively converted into a plurality of second-format transaction messages, and the first-format transaction message is plain text format data, and the second-format transaction message is XML format data, which includes a a transmission module, a definition building module and a conversion processing module. The transmission module is connected by telecommunications to the participant's server system and the Taiwan Token Insurance System for receiving the first format transaction messages from the participant's server system. The definition creation module is connected to the transmission module via telecommunications and is used to create multiple field definition data, and the field definition data are arranged in sequence. Each field definition data includes a field code, an actual Length, type and group, The actual length is the sum of integer digits, decimal point sign, and decimal point digits. The conversion processing module is electrically connected to the transmission module and the definition building module. The conversion processing module sequentially uses the field definition data to calculate each first format transaction message starting from the first character of the message. Use the actual length to calculate and intercept the message content to form a corresponding field data, and parse the field data and set the field data as a first-level data when the obtained content is @@; the obtained content is ## The field data is set as a second-level data, in which the field data is set with the field code, the type and the group corresponding to the actual length; then, the conversion processing module collects these The field data and the corresponding field code, the type, the group, and the first-level data or the second-level data are used to convert the corresponding first-format transaction message into a second-level data. After formatting the transaction information, it is sent to the Taiwan Bill Insurance System through the transmission module.

Among them, each field definition data consists of the field code, a defined length, the actual length, the type, a relationship (Ration), the group, a level, an Fdd default value (Fdd Default), It consists of ten definition data of a combination word and a field name, and each definition code in each field definition data is separated by ","; these field definition data are constructed and arranged in order to form def One of the format definition files. When the conversion processing module parses each field data and learns that the content is ^, it defines the field data as necessary data, which means that even if the field data is null, it still needs to be added to the second format transaction in XML format. In the message. Each first-format transaction message includes an attribute for the conversion processing module to parse and learn whether the field data is a necessary or unnecessary XML field based on the attribute. The participant's server system includes a non-physical ticket management system and a clearing and delivery bank system; the transmission module is equipped with an encryption and decryption component, and the encryption and decryption component stores a set of cross-domain AB codes. When the transmission module receives each When the first format transaction message is used, the encryption and decryption component uses the set of cross-domain AB codes to decrypt and output the message content to the conversion processing module. set; before the transmission module transmits each second format transaction message to the Taiwan Securities Insurance System, the encryption and decryption component uses the set of cross-domain AB codes to perform software program calculations to encrypt each second format transaction message.

To sum up, this new model stipulates the basis for converting plain text raw data (Raw Data) into XML format through the construction of these field definition data. Based on this, the conversion processing module can be fast and accurate. convert the first format transaction message into the second format transaction message, and further allow the participant's server system to still read and view the first format transaction message after sending it to the Taiwan Securities Insurance System The message data transmitted is different from the operational shortcomings of conventional participant systems that can only transmit transaction messages but cannot subsequently read the data, so as to achieve the effect of an instant and complete transaction message transmission model. Moreover, this new model eliminates the use of hardware devices to encrypt and decrypt transaction messages. Instead, it directly uses the computing mechanism of the system software to perform message encryption and decryption operations through the encryption and decryption component, thereby enabling the delivery definition conversion system to respond to the data. When service upgrades are required, it can instantly and continuously provide adaptive and correct encryption and decryption mechanisms without being restricted by the specifications of hardware components, thereby increasing the service life of the overall system and improving the practical economic benefits of the system.

S10~S15: Steps

S20~S25: steps

1: Delivery definition conversion system

10:Transmission module

100: Encryption and decryption components

1000: Cross-domain AB code

11: Define the build module

110:Definition file

1100:Field definition data

12:Conversion processing module

120:Property report

2:Participant server system

20: First format transaction message

3:Taiwan Voucher Insurance System

30: Second format transaction message

Figure 1 is a method flow chart of a preferred embodiment of the present invention.

Figure 2 is a system architecture diagram of a preferred embodiment of the present invention.

Figures 3A, 3B, and 3C are method flow charts of the second preferred embodiment of the present invention.

Figure 4 is a schematic diagram of the system architecture of the second preferred embodiment of the present invention.

Figure 5 is a schematic diagram of the definition file creation of the second preferred embodiment of the present invention.

Figure 6 is a schematic diagram of message format conversion in the second preferred embodiment of the present invention.

In order to enable those with ordinary knowledge in the field to clearly understand the contents of the present invention, the following description is accompanied by the drawings, please refer to them.

Please refer to Figures 1 and 2, which are respectively a method flow chart and a system architecture diagram of a preferred embodiment of the present invention. As shown in the figure, the delivery definition conversion method of the non-physical ticket transaction message is formed by respectively converting a plurality of first format transaction messages 20 transmitted between at least one participating party server system 2 and a Taiwan Note Insurance System 3 There are a plurality of second format transaction messages 30, and the first format transaction message 20 is plain text format data, and the second format transaction message 30 is XML format data. The delivery definition conversion method may include the following steps: Step S10: Create a plurality of field definition data arranged in sequence for parsing each first format transaction message, wherein each field definition data includes a field code , an actual length, a type and a group, and the actual length is the sum of integer digits, decimal point symbols and decimal point digits; Step S11, receive each of the first format transaction messages 20; Step S12, according to The program uses the field definition data to calculate each first format transaction message 20 starting from the first character of the message, and uses the actual length to calculate and intercept the message content to form a corresponding field data, and the field data is set There is the field code, the type and the group corresponding to the actual length. Moreover, in step S13, when each field data is parsed and the content is @@, the field data is set as a first-level data; when the content is ##, the field data is set as a second-level data. Step S14: Collect the field data and the corresponding field code, the type, the group, and the first-level data or the second-level data, and convert the corresponding first-level data accordingly. The format transaction message 20 is a transaction message 30 in the second format. Step S15: Send the second format transaction message 30 to the Taiwan Bill Insurance System 3.

As mentioned above, the delivery definition conversion system 1 that implements the delivery definition conversion method of the non-physical ticket transaction message is a message delivery system set up between at least one of the participating party's server systems 2 and the Taiwan Notes Insurance System 3 The workstation may be provided with a transmission module 10, a definition building module 11 and a conversion processing module 12 for respectively converting the first format transaction messages 20 transmitted between the two systems into the second The format transaction message 30 achieves the effect of improving the efficiency of message transmission and the accuracy of message processing between the two systems. The transmission module 10 is electrically connected to the participant server system 2, the Taiwan Voucher Insurance System 3, the definition building module 11 and the conversion processing module 12 for receiving the information from the participant server system 2. Wait for the first format transaction message 20. The definition building module 11 is connected to the conversion processing module 12 by telecommunications, and is used to create the field definition data, and the field definition data are arranged in sequence, and each field definition data can include a field code. , the actual length, the type and the group, the actual length is the sum of integer digits, decimal point sign and decimal point digits.

The conversion processing module 12 sequentially uses the field definition data to calculate each first format transaction message starting from the first character of the message, and uses the actual length to calculate and intercept the message content to form the corresponding field data. And parse each field data and set the field data as the first-level data when the content is @@; set the field data as the second-level data when the content is ##, where, the field data is The field code, the type and the group corresponding to the actual length are set. Then, the conversion processing module 12 collects the field data and the corresponding field code, the type, the group, and the first-level data or the second-level data, and converts them accordingly. After the corresponding first format transaction message 20 is a second format transaction message 30, it is transmitted to the Taiwan Bill Insurance System 3 through the transmission module 10.

Please refer to Figures 3A, 3B, 3C, and 4, which are respectively a method flow chart and a system architecture schematic diagram of the second preferred embodiment of the present invention. As shown in the figure, the delivery definition conversion system 1 that uses the delivery definition conversion method of the non-physical ticket transaction message to convert the message format is configured on at least one participating party server. A message transfer workstation between a service system 2, such as a non-physical bill management system, a clearing and delivery bank system, and a Taiwan bill collective insurance system 3, for parsing and definition transmission to the participant server system 2 and the Taiwan bill A plurality of first-format transaction messages 20 between the securities collective insurance systems 3 are converted into a plurality of second-format transaction messages 30 to achieve the purpose of improving the quality of message transmission between systems, and the first-format transaction message 20 is plain text. Format data, the second format transaction message 30 is XML format data. The delivery definition conversion system 1 is provided with a transmission module 10, a definition building module 11 and a conversion processing module 12. The transmission module 10 is connected to the participant server system 2 and the Taiwan Voucher Insurance System 3 via telecommunications. , the definition building module 11 and the conversion processing module 12, the definition building module 11 is connected to the conversion processing module 12 via telecommunications, and the transmission module 10 is provided with an encryption and decryption component 100, and the delivery definition conversion Methods can include the following steps:

Step S20, a system administrator uses the definition building module 11 to sequentially build a plurality of field definition data 1100 to form a def format definition file 110 for subsequent analysis of each first format transaction message 20. . The field definition data 1100 are arranged in sequence, and each field definition data 1100 consists of a field code, a defined length, an actual length, a type, a relationship (Ration), a group, and a hierarchy. , a Fdd default value (Fdd Default), a combination of words and a field name, etc. composed of ten definition codes. Among them, when the system administrator compiles the definition file 110, the definition codes in each field definition data 1100 are separated by ",", and the actual length is an integer number of digits, a decimal point symbol and a decimal point. The sum of digits.

Step S21, when the transmission module 10 receives the first format transaction messages 20 from the participant server system 2, step S210, the encryption and decryption component 100 uses a set of cross-domain AB codes 1000 in the memory to pair each of the third A format transaction message 20 is decrypted and the decrypted message content is output to the conversion processing module 12 . Step S22, after the conversion processing module 12 calls and imports the definition file 110 according to the path, the conversion processing module 12 sequentially uses the field definition data 1100 to calculate each first frame starting from the first character. Formula transaction message 20 is used to calculate and intercept the message content using each actual length to form a corresponding field data, and the field data is set with the field code, the type and the group corresponding to the actual length. In this embodiment, each first format transaction message 20 includes an attribute. Therefore, while the conversion processing module 12 intercepts and forms the field data, in step S220, the column is obtained based on the attribute analysis. The bit data is a necessary or unnecessary XML field, and forms an attribute report 120 for reference when subsequently converting the message format.

Further, in step S23, the conversion processing module 12 analyzes whether each field data contains specific characters. If so, in step S230, when the conversion processing module 12 analyzes and learns that the data content of each field is @@, it sets the field data as a first-level data; in step S231, it analyzes and learns that the data content of each field is When ##, the field data is set as a second-level data; in step S232, when the content of each field data is ^, the field data is defined as necessary data, which means that even if the field data is The null value still needs to be added to the second format transaction message 30 in XML format. Step S24, the conversion processing module 12 refers to the attribute report 120 to compile the field data and their corresponding field codes, the type, the group, and the first-level data or the second-level data. Data is used to convert the corresponding first format transaction message 20 into a second format transaction message 30 accordingly. Next, in step S25, when the transmission module 10 receives the second format transaction message 30, the encryption and decryption component 100 uses the set of cross-domain AB codes 1000 to perform software program calculations to encrypt the second format transaction message 30 for the purpose. The transmission module 10 transmits it to the Taiwan Voucher Insurance System 3 to complete the message delivery operation.

Among them, the modules described in the present invention are implemented through hardware or software supplemented by hardware, such as the definition essence of the transmission module 10, the definition building module 11 and the conversion processing module 12, etc. The above refers to the technical characteristics of the integration of various hardware devices such as CPU, microprocessor, memory or signal transmitter, supplemented by software programs.

However, the above are only preferred embodiments of the present invention and are not intended to limit the scope of implementation of the present invention; therefore, equal changes and modifications made without departing from the spirit and scope of the present invention should be included in Within the patent scope of this new model.

1: Delivery definition conversion system

10:Transmission module

11: Define the build module

12:Conversion processing module

2:Participant server system

20: First format transaction message

3:Taiwan Voucher Insurance System

30: Second format transaction message

Claims (5)

A delivery definition conversion system for non-physical ticket transaction messages, which is a message delivery workstation set up between at least one participant server system and a Taiwan Note Collection Insurance System, so as to transmit a plurality of first messages between the two systems. The format transaction messages are respectively converted into a plurality of second format transaction messages, and the first format transaction message is plain text format data, and the second format transaction message is XML format data, which includes: A transmission module that is connected by telecommunications to the participant's server system and the Taiwan Token Insurance System for receiving the first-format transaction messages from the participant's server system; A definition creation module is connected to the transmission module by telecommunications and is used to create multiple field definition data, and the field definition data are arranged in sequence. Each field definition data includes a field code, a field definition data, and a field definition data. The actual length, a type and a group, the actual length being the sum of the number of integer digits, the decimal point sign and the number of decimal points; and A conversion processing module is telecommunications connected to the transmission module and the definition building module. The conversion processing module sequentially uses the field definition data to calculate each first format transaction message starting from the first character of the message. , to use the actual length to calculate and intercept the message content to form a corresponding field data, and parse the field data and set the field data as a first-level data when the obtained content is @@; the obtained content is # When #, the field data is set as a second-level data, in which the field data is set with the field code, the type and the group corresponding to the actual length; then, the conversion processing module collects the The field data and the corresponding field code, the type, the group, and the first-level data or the second-level data are used to convert the corresponding first-format transaction message into a After the transaction message in the second format is sent to the Taiwan Bill Insurance System through the transmission module. The delivery definition conversion system for non-physical ticket transaction messages as described in request item 1, wherein each field definition data is composed of the field code, a defined length, the actual length, the type, a relationship, the It consists of ten definition data of a group, a level, a Fdd default value, a combination word and a field name, and each definition code in each field definition data is separated by '',"; The field definition data are arranged sequentially to form a definition file in def format. For example, in the delivery definition conversion system for non-physical ticket transaction messages described in request item 2, where the conversion processing module parses each field data and learns that the content is ^, it defines the field data as necessary data. This means that even if the field data is empty, it still needs to be added to the second format transaction message in XML format. The delivery definition conversion system for non-physical ticket transaction messages as described in request item 3, wherein each of the first format transaction messages includes an attribute for the conversion processing module to parse based on the attribute to obtain the field data as Required or optional XML fields. The delivery definition conversion system for non-physical ticket transaction messages as described in request item 4, wherein the participant server system includes a non-physical ticket management system and a clearing and delivery bank system; the transmission module is provided with an encryption and decryption component, the encryption and decryption component has a set of cross-domain AB codes in its memory. When the transmission module receives each transaction message in the first format, the encryption and decryption component uses the set of cross-domain AB codes to decrypt and output the message content to the conversion process. Module; before the transmission module transmits each second format transaction message to the Taiwan Securities Insurance System, the encryption and decryption component uses the set of cross-domain AB codes to perform software program calculations to encrypt each second format transaction message. .