WO1998056024A1 - Translation of messages to and from secure swift format - Google Patents

Translation of messages to and from secure swift format Download PDF

Info

Publication number
WO1998056024A1
WO1998056024A1 PCT/US1998/010930 US9810930W WO9856024A1 WO 1998056024 A1 WO1998056024 A1 WO 1998056024A1 US 9810930 W US9810930 W US 9810930W WO 9856024 A1 WO9856024 A1 WO 9856024A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
format
messages
network
agent server
Prior art date
Application number
PCT/US1998/010930
Other languages
French (fr)
Inventor
David M. Jacobs
Bin Li
Xuren Lin
Ju Zhang
Original Assignee
Crossmar, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Crossmar, Inc. filed Critical Crossmar, Inc.
Priority to AU80545/98A priority Critical patent/AU8054598A/en
Publication of WO1998056024A1 publication Critical patent/WO1998056024A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression

Definitions

  • the present invention relates to systems and methods for facilitating electronic message transmission among different computer networks and application programs on the networks.
  • the systems and methods are particularly advantageous for use in the transmission of electronic messages among financial institution networks and application programs and the Society for Worldwide Interbank Financial
  • WIFT Telecommunication
  • SWIFT Worldwide Interbank Financial Telecommunications
  • SWIFT messages are widely utilized in the international securities area as a form of communication between brokers, clearing agents, financial institutions and other security transaction participants.
  • One advantageous method for trading securities is described in US patent application serial number 08/700,836, filed August 21, 1996, entitled Method and Apparatus for Trading Securities Electronically, the disclosure of which is hereby incorporated by reference.
  • One embodiment of the methods described in this application includes the steps of: transmitting an order message from an originating broker workstation to a host computer in SWIFT format, the order message being directed to an executing broker to buy or sell securities; and then transmitting a SWIFT format confirmation message from the executing broker to confirm the transaction.
  • SWIFT messages are extensively utilized in international securities transactions, the SWIFT message format is not generally utilized for message traffic on financial institutions internal servers.
  • many application programs, utilized in the financial services area are not capable of generating SWIFT messages. Therefore it would be advantageous to have methods for translating messages which are not in SWIFT format to SWIFT format. It would also be advantageous to provide application programs with the capability of generating SWIFT format messages through the use of a local set of functions.
  • SWIFT network The need to interface with international networks such as the SWIFT network, and to send and receive electronic messages, such as SWIFT messages, to such networks may present additional problems for financial institution networks in the routing and handling of message traffic.
  • SWIFT messages electronic messages
  • the present invention provides systems and methods that facilitate the handling of electronic messages (also referred to herein simply as "messages") by different computer networks and application programs.
  • the present invention is particularly advantageous for use in worldwide financial institution computer networks and for use with application programs which access those networks.
  • the systems and methods of the present invention may be utilized to facilitate the communication of electronic messages, which are entered in a first messaging format utilized by a financial institution's network, to and from the Society for Worldwide Interbank Financial Telecommunication network which requires a defined format, referred to herein as "SWIFT", which may differ from the messaging format utilized by the financial institution.
  • the present invention provides a message exchange system.
  • the message exchange system includes, as components, a message agent server; and a series of functions, collectively referred to herein as a "message format library", for applications which send and receive messages.
  • the message agent server and message format library may be utilized together in an integrated system for the handling and transfer of electronic messages among discrete computer networks.
  • the message agent server and the message format library may also be utilized independently.
  • the message agent server of the present invention may perform one or more of the following functions, routing messages, queuing messages; storing messages; receiving messages; logging messages; triggering applications which send and receive messages and validating the format of messages.
  • the message agent server of the present invention will include all of the foregoing functions.
  • the message agent server may include the message format library of the present invention. In this type of embodiment the message agent server may perform additional functions relating to the translation of messages.
  • the message agent server may have the capabilities to receive, store, queue, validate and route messages.
  • the message agent server of the present invention may be connected to applications and other servers through TCP/IP connections.
  • the routing functions of the message agent server may be utilized to messages created by an application to other applications on the same network, or through an interface out to different networks such as the SWIFT network.
  • the message agent server may also be utilized to receive incoming messages from different networks and route the incoming messages to an application program.
  • the message format library feature of the present invention includes message agents for translating messages from a first format to another format such as the SWIFT format.
  • the message format library may be advantageously utilized to take data elements from an application program and create electronic messages for sending to another party.
  • the message format library may also be advantageously utilized to parse incoming messages and recover data elements relevant to a particular application program.
  • the message agent server and message format library are utilized by application programs through local or remote function calls.
  • the message agent server is utilized by application programs to send and receive messages.
  • the message format library may also be utilized by application programs, independently of the message agent server, to translate and manipulate messages received, and obtain data elements from the messages for processing within their own application's domain.
  • the message format library may also be utilized by application programs to create electronic messages from data elements within the application program.
  • the services of the message agent server component of the present invention are performed without direct user involvement, although embodiments of the message agent server may include means for a network administrator to review message logs retained by the message agent server.
  • the services of the message format library component of the present invention may be accessed through a remote or local procedure call by an application program.
  • the message format library may be accessed as part of a data entry system which includes a graphical user interface (GUI) for prompting input by the user of the application program.
  • GUI graphical user interface
  • the present invention also includes methods for the handling of messages utilizing the systems of the present invention.
  • application program or “program” is utilized to describe a computer program for accomplishing or effecting a particular function or functions, the computer program comprising a detailed and explicit set of directions
  • code for accomplishing the function(s).
  • an application program could be written for accomplishing the global securities trading functions described above and in US patent application serial number 08/700,836 referred to above.
  • Other examples of application programs utilized by financial institutions include programs for foreign exchange and money market trade confirmation matching for trades between corporations and their counterpart banks; programs for electronically distributing exchange rates; and portfolio management programs.
  • the systems and methods of the present invention are applicable to other application programs such as word processing programs, electronic mail programs, scheduling programs and the like.
  • Figure 1 is a block diagram illustrating a potential relationship among the message agent server, application programs, a gateway and the SWIFT network.
  • Figure 2 depicts the message flow of a message originated by an application program for transmittal to the SWIFT network.
  • the embodiment of the system of the present invention depicted in Figure 2 includes a message format library.
  • Figure 3 depicts the message flow of an incoming message, for example a message originated on the SWIFT network.
  • Figure 4 depicts an overview of the functional components of an embodiment of a message agent server of the present invention which is linked via communication links to application programs and to an interface to an external network.
  • Figure 5 depicts the layered architecture of a possible embodiment of a message format service.
  • Figure 6 is a schematic of an embodiment of an application interface for use between a message agent server and application programs.
  • Figure 7 illustrates the architectural design of an embodiment of a message queue for use in a message agent server of the present invention.
  • Figure 8 depicts an embodiment of a message agent server architecture wherein the interface to a SWIFT network is provided by an X.25 interface.
  • Figure 9 depicts an embodiment of a state diagram for an outbound X.25 link server.
  • Figure 10 depicts an embodiment of a state diagram for an inbound X.25 link server.
  • Figure 11 depicts an alternative embodiment of a computing environment utilizing the system of the present invention.
  • Figure 12 depicts a data access model for a message agent server of the present invention.
  • Figure 13 is a representation of a graphical user interface for a message agent server system administration utility provided by an administration function of the system of the present invention.
  • Figure 14 is a representation of a graphical user interface for monitoring provided by an administration function of the system of the present invention.
  • Figure 15 is a representation of a graphical user interface for error display provided by an administration function of the system of the present invention.
  • Figure 16 is a representation of a graphical user interface for event details provided by an administration function of the system of the present invention.
  • Figure 17 is a representation of a graphical user interface for message services provided by an administration function of the system of the present invention.
  • Figure 18 is a representation of a graphical user interface for queued messages provided by an administration function of the system of the present invention.
  • Figure 19 is a representation of a graphical user interface for queued error messages provided by an administration function of the system of the present invention.
  • Figure 20 is a representation of a graphical user interface for an event search provided by an administration function of the system of the present invention.
  • Figure 21 is a representation of a graphical user interface for message statistics provided by an administration function of the system of the present invention.
  • Figure 22 is a representation of a graphical user interface for delayed/failed message statistics provided by an administration function of the system of the present invention.
  • Figure 23 is a representation of a graphical user interface for advanced message statistics provided by an administration function of the system of the present invention.
  • Figure 24 is a representation of a graphical user interface for FTS profiles provided by an administration function of the system of the present invention.
  • Figure 25 is a representation of a graphical user interface for inbound profiles provided by an administration function of the system of the present invention.
  • Figure 26 is a representation of a graphical user interface for inbound profile details provided by an administration function of the system of the present invention.
  • Figure 27 provides a graphic overview of an embodiment of a message format library of the present invention.
  • Figure 28 illustrates a tree built on a concatenation expression utilized in a message format library of the present invention.
  • Figure 29 illustrates a tree built on a parentheses pair expression utilized in a message format library of the present invention.
  • Figure 30 illustrates a tree built on an option pair expression utilized in a message format library of the present invention.
  • Figure 31 illustrates a tree built on a variable assignment expression utilized in a message format library of the present invention.
  • the present invention includes a message agent server and a message format library which may be utilized in an integrated message exchange system for handling the exchange of messages among applications and computer networks.
  • a method for transferring electronic messages in a network comprising: generating an electronic message at the first terminal in the first format; transmitting the electronic message from the first terminal to the message agent server; the message agent server automatically translating the electronic message from the first format to the secure network format; and transmitting the translated electronic message from the message agent server to the second terminal.
  • the method may further comprise: generating a second electronic message at the second terminal in the secure network format; transmitting the electronic message from the second terminal via the secure network to the message agent server; the message agent server automatically translating the electronic message from the secure network format to the first format; and transmitting the translated second message from the message agent server to the first terminal.
  • the first terminal, second terminal and/or server may comprise a computer, for example a personal computer.
  • the step of generating the electronic message at the first terminal in the first format may be performed using a software application such that the first format includes data formatted using the software application.
  • Examples of secure networks include financial networks wherein the secure network format, for example, is a SWIFT compatible format.
  • the method may be advantageously utilized wherein the first message includes a plurality of first message elements and the translated electronic message includes a plurality of secure network message elements, and the message agent server automatically parsing the message, such that the plurality of message elements correspond to the plurality of secure network message elements.
  • the method may include validating the electronic message or translated electronic message.
  • the second terminal may be disconnectable from the secure network and and transmitting the translated electronic message may include connecting the second terminal to the secure network, the server automatically storing the translated message; the server automatically transmitting an alert message to the second terminal; and the second terminal retrieving the translated message.
  • the present invention includes a method for transferring electronic messages between a first terminal, a message agent server and a first network comprising; generating an electronic message addressed to the first network on the first terminal; sending the message from the first terminal to the message agent server; interpreting the message so as to determine the address of the electronic message; and routing the message to the first network from the message agent server.
  • the method may further comprise queuing the electronic message in the message agent server before it is routed to the first network.
  • the step of routing may be delayed until the first network comes on-line such that the message will remain queued until the first network comes on-line.
  • the present invention also includes a system for transferring electronic messages in a network, the network including a message agent server, a first terminal for communicating electronic messages in a first format, and a secure network, the secure network further connectable to at least a second terminal for communicating electronic messages in a secure network format, the system comprising: means for generating an electronic message at the first terminal in the first format; means for transmitting the electronic message from the first terminal to the message agent server; means for automatically translating the electronic message from the first format to the secure network format; and means for transmitting the translated electronic message from the message agent server to the second terminal.
  • the present invention includes a system for transferring messages comprising: a message agent server comprised of: at least one queue; a processor which is used to at least determine the destination address of one of the messages and a plurality of communications links used to carry the messages; a first terminal; a first network coupling the first terminal to a first subplurality of communications links; and a second network coupled to a second subplurality of communications links.
  • the first terminal may be a server and may hold one of a plurality of application programs, for example a securities exchange program.
  • the second network may be a world-wide network used to transfer financial messages.
  • the queue may be used to store and transfer messages in a particular order destined for the first terminal and/or for the second network. Message transfer may be controlled for example by an MQ application.
  • the present invention provides a message agent server used for transferring messages between a first terminal and a network
  • the message agent server comprising: communications links coupling the message agent server to the first terminal and the network; a processor; a buffer for temporarily holding a message received via the communications links; wherein the processor operates under the control of an interpreting procedure so the processor determines the destination address of the message while the message is in the buffer; a first queue associated with the first terminal; a second queue associated with the network; where the message is transferred from the buffer to the appropriate queue based on the determination made by the processor under the control of the interpreting procedure.
  • the present invention provides a system comprising a message agent server coupled to a first network, the network including a first terminal, and coupled to a second network where the second network includes at least one terminal where the system is further comprised of: communications links coupling the message agent server to the first network and coupling the message agent server to the second network; where the message agent server is further comprised of a processor; message receiving means for receiving messages transmitted to the message agent server from the first and second networks via the communications links; means for interpreting the received messages which includes reading the address of the destination of the message; queuing means for storing the received messages and for forwarding the messages to the communications links when told to do so; routing means for routing the messages to the appropriate destination based upon the determination of the means for interpreting.
  • the means for interpreting the message may include means for validating the message format and/or means for translating the message from a message format to a second message format, for example using a message format library.
  • the queuing means may comprise a database and may include at least one of the message archive, retrieval, and retransmission capabilities.
  • the system of claim may further include means for monitoring message traffic and message agent server performance by an administrator.
  • the present invention provides a method for transferring electronic messages among a plurality of participants wherein the participants include a first terminal and a first network and the method uses a message agent server where the method comprises: preparing an electronic message on the first terminal addressed to the first network; sending the message to the message agent server; interpreting the message to determine at least the message addressee; storing the message in a message queue assigned to the message addressee; triggering the first network to connect to the message agent server; and routing the message to the remote network after the remote network connects to the message agent server.
  • the step of interpreting the message may include validating the format of the message.
  • the method may further include monitoring message traffic.
  • a message agent server for communication of messages among a plurality of participants in a computing environment, the participants including the message agent server; a remote application residing on a first computer; and a remote network residing on a second computer, the participants being connectable by a physical network
  • the message agent server comprising: a communications device for establishing a communications link; a processor, coupled to the communications device; memory; message receiving means for receiving incoming messages; means for interpreting the messages; queuing means for queuing and storing received messages; and routing means for routing the message to the message addressee.
  • the means for interpreting the messages comprises means for determining the addressee of the message.
  • the means for interpreting the messages includes means for validating the message format, for example utilizing the message format library.
  • the queuing means preferably comprises a database for queuing and storing messages.
  • the message agent server further comprises means for monitoring message traffic and message agent server performance by an administrator. The monitoring means may also use the database utilized by the queuing means.
  • the message agent server may additionally include a failover of the message agent server components so that a failure in part of the message agent server does not prevent other portions of the message agent server from running.
  • the failover provision may preferably include a provision for redundant communication links to application programs or the network; redundant processors (CPUs) and redundant processes for receiving, queuing, routing, validating and other handling of messages.
  • a message format utility which is used to maintain the various message formats and other meta data with a graphical user interface (GUI).
  • GUI graphical user interface
  • the message agent server may further include a message archive, retrieval, and re-transmission capability.
  • the message agent server may be constructed utilizing conventional computer hardware. Suitable processor hardware includes an Intel Pentium Pro processor or its equivalent.
  • the computer operating system may be Microsoft NT or its equivalent.
  • the message agent server of the present invention may take advantage of increased processor speed and more robust operating systems as each becomes available in the future.
  • the computing environment which includes the message agent server may comprise discrete computing platforms linked through TCP/IP connections. In this type of environment the communication devices may comprise modems or the equivalent.
  • the message agent server may also be utilized as an integral part of a local area or wide area network to handle message traffic among nodes on the network.
  • a method for transferring electronic messages among a plurality of participants in a computing environment comprises: preparing an electronic message in the remote application on a first computer, the message being addressed to the remote network residing on the second computer; sending the message to the message agent server; interpreting the message to determine at least the message addressee; storing the message in a message queue assigned to the message addressee; triggering the remote network to connect to the message agent server; and routing the message to the remote network after the remote network connects to the message agent server.
  • interpreting the message further comprises validating the format of the message, for example utilizing the message format library.
  • the method of the present invention further comprises: monitoring message traffic on the message agent server.
  • the methods of the present invention may be performed on conventional computer hardware such as the hardware discussed above.
  • Figure 1 provides an overview of a computing environment which includes the message agent server of the present invention.
  • a computing environment 2 may include a message agent server 10, having communication links 20, to application programs 12, 14 and 16.
  • Communication links 20 may be direct network links, for example through an ethernet link, or dial-up links, using telecommunication links.
  • the communication links are preferably TCP/IP links.
  • Application programs 12, 14 and 16 may be the same or different and may reside on a single computer or a plurality of computers.
  • the application programs will generally be message based, i.e. utilized for generating electronic messages for a particular purpose, although the present invention may be utilized with other types of application programs.
  • An example of an application program utilized in the financial services industry is the Global Clear program for the routing of orders and the confirmation of cross-border security trading, described above and in US patent application serial number 08/700,836.
  • Other application programs utilized by the financial services industry include: programs for providing an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties; programs for matching confirmations of foreign exchange and money market trades between corporate customers and bank traders; programs for monitoring and controlling the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products; and programs for handling payment orders. Details of these application programs are set forth below.
  • the message agent server provides messaging and queuing capabilities for application programs.
  • the message agent server is particularly advantageous for use with application programs that send and receive SWIFT messages.
  • the application programs include programs utilized by the financial services industry such as the following: programs for providing an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties, referred to herein as FX Options Confirmation Matching; programs for matching confirmations of foreign exchange and money market trades between corporate customers and bank traders, referred to herein as FX Match; programs for monitoring and controlling the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products referred to herein as CCMP; programs for cross border routing and confirmation matching, referred to herein as Global Clear, and programs for handling payment orders.
  • programs for providing an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties referred to herein as FX Options Confirmation Matching
  • the FX Options Confirmation Matching application will provide an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties.
  • banks will transmit FX options confirmations (MT305 message format) to a message agent server over the SWIFT network, sometime after trading with a corporation using existing trading methods.
  • the message agent server will safely queue the message, perform basic validation of the SWIFT format and header contents and return a positive or negative acknowledgment to the interface with the SWIFT network.
  • the FX Options system application program will have "subscribed to receive" messages addressed to it from message agent server when they are received from the SWIFT network. For each MT305 message it receives from message agent server, the FX Options system application program will invoke the message parsing service of message agent server, or the message format library, to break the message into its constituent fields, and store them in its database. The FX Options system application program will transmit the MT305 messages to the appropriate users, who will be provided with a graphical user interface (GUI) application which will be used to view and "affirm" the MT305 messages, as well print basic reports of the status of FX options confirmations and affirmation activities.
  • GUI graphical user interface
  • the GUI application Upon affirming the confirmations, the GUI application transmits them to the FX Options system application program, where they are stored in the database and sent to message agent server for delivery to the counter-party banks.
  • the GUI application Upon affirming the confirmations, the GUI application transmits them to the FX Options system application program, where they are stored in the database and sent to message agent server for delivery to the counter-party banks.
  • Bank users will also be provided with a GUI application to view the status of FX options confirmations and print basic reports of the status of FX options confirmations and affirmation activities.
  • GlobalClear is a product for the routing of orders and the confirmation of cross-border security trading and is described in detail in US patent application serial number 08/700,836. referred to above.
  • Messages of SWIFT MT500 series are sent to a GlobalClear server through GlobalClear application program client software direct link, file transfer and a SWIFT NETWORK INTERFACE. The messages are delivered through the same channels. The following SWIFT messages are handled: MT502; MT513; MT514; MT515; MT517; MT518; MT52x; and MT53x.
  • FX-Match matches confirmations of foreign exchange and money market trades between corporate customers and bank traders. It also enables on-line confirmation, monitoring of transaction status, storing historical information and provision of various reports. Co orate customers enter information through a dial-up terminal or upload a file of FX and money market trade confirmations. Banks send information to FX-Match through the SWIFT NETWORK INTERFACE and file transfer. The file transfer may be performed using DECNET when originated internally from CITIBANK, and KERMIT and other similar terminal protocols are used by external clients.
  • FX-Match The message flow in FX-Match is simple and straightforward. Banks and corporate clients send MT300 and MT32x messages into FX-Match. FX Match matches them and sends confirmation messages. Corporate clients can also match the trades through direct online access to a terminal. Accepting a trade by a corporate client causes a confirmation message to be sent to the counter-party bank via a SWIFT
  • a cancel message for a MT300 message is a MT300 with field 22 containing the value "CANCEL".
  • CANCEL the value of money market trades confirmations
  • Banks currently send three types of messages: MT300; MT320 and MT324.
  • Other types of messages may also be utilized including: MT301 ; MT304; MT305.
  • CCMP is a platform which allows various bank businesses to monitor and control the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products.
  • Product Processors send files daily containing all liability transactions to CCMP.
  • CCMP nets the impact of the transactions on each participant's collateral after being marked to market.
  • CCMP reports on these results to collateral monitoring units, customers, and risk and custody systems.
  • the customer can either initiate a message through a bank's internal network to SECORE (Global Custody System) or via SWIFT. A copy of the message is sent to CCMP when SECORE receives it. After processing the collateral for acceptability, SECORE sends to CCMP a nightly position report of participants for reconciliation purposes.
  • SECORE Global Custody System
  • CCMP handles the following SWIFT messages: MT520; MT521; MT522; MT523; MT530; MT531; MT532; MT533; MT592; MT100; MT900; and MT910.
  • Other application programs may utilize ISITC (Industry Standardization for Institutional Trade Communication)and FIX (Financial Information/Institution Exchange) message formats as well as the foregoing SWIFT message formats.
  • message agent server 10 is linked through communication links 20 to the SWIFT network 30.
  • message agent server is linked through communication links to a gateway which in turn is linked to the SWIFT network and/or other networks.
  • an electronic message is generated by an application program for transmission to the SWIFT network.
  • the message is transferred via communication links to the message agent server.
  • the message format allows the message agent server to identify the message as a SWIFT message and the message agent server stores the message in a SWIFT queue for transmission to the SWIFT network.
  • After generation of a communication link to the SWIFT network the message is transferred to the SWIFT network.
  • the generation of the communication link may be facilitated by the message agent server triggering the generation of the link.
  • Figure 2 depicts the flow of an outgoing message generated by an application program in an embodiment of the present invention.
  • an application program 12 when an application program 12 sends an outgoing message for delivery to the SWIFT network it first prepares all the necessary variables and fields in a data entry step at a workstation 42.
  • the data is converted in a remote or local message formatting procedure, 44 to form a SWIFT message.
  • the message format library of the present invention is utilized in the formatting.
  • the message is then passed to message agent server 10, through a communication link.
  • the message agent server program is constantly listening for application programs on a communications link.
  • the message format Upon receipt of the message, the message format is validated, 46 and then the message is passed to a message queue 48.
  • An interface program, 50 fetches the message from the queue and sends it through a communication link to the SWIFT network 30.
  • the interface function may be incorporated within the message agent server.
  • the interface may be separate from the message agent server and be reachable by the message agent server through a communications link.
  • the interface may form part of another computer network which is linked to the SWIFT network.
  • FIG. 3 depicts the flow of an incoming message, for example a message from the SWIFT network according to an embodiment of the present invention.
  • An incoming message from the SWIFT network, 30 is first received by interface 50, which may be incorporated within, or separate from, the message agent server. The message flows through the interface to the message agent server 10. The message is validated 46 and then passed to a queue 48 for delivery to an application.
  • An application program 12 fetches the message from the queue via a communications link. The application issues a block reading for messages destined for it through a remote procedure call interface. The remote procedure either returns a message immediately or block-wait for the next arriving message. The message is then parsed and translated 44 from the SWIFT format for display in the application format.
  • the translation may be accomplished by the message format library of the present invention. After translation, the message data is displayed at a workstation 42 for reading by a user. In alternative embodiments of the present invention the message translation may occur at the message agent server before the message is passed to the application program.
  • Messages may also be passed by the message agent server between and among different application programs.
  • the system comprises two tiers.
  • the first is the application program which takes user input and may reside on a client workstation.
  • the second tier is the message agent server which controls and manages the data and business logic.
  • Embodiments of the message agent server of the present invention may perform a variety of services including one or more of the following services.
  • the message agent server may provide a link to the SWIFT network, permitting application programs to receive/send SWIFT formatted messages.
  • the message agent server may provide transactional integrity of messages received by application programs for transmission to a SWIFT NETWORK INTERFACE and for messages received from the SWIFT NETWORK INTERFACE bound for application programs.
  • An application program may use the message format library for formatting a collection of fields into SWIFT formatted messages.
  • the message agent server may validate SWIFT messages upon receipt from, and prior to transmission to, the SWIFT network.
  • the message agent server may provide SWIFT meta data for use by application programs to apply more meaningful names to SWIFT message data fields.
  • This service may be used by an application program's graphical user interface for presenting the contents of a SWIFT message on a screen, using common language for the screen's field labels, e.g., "Transaction Reference Number” instead of the SWIFT field label, ":20:”
  • the message agent server may include failover of the message agent server components so that a failure in part of message agent server does not stop all of message agent server from running. This includes provision for redundant links to the SWIFT NETWORK INTERFACE, redundant processors (CPUs) and processes.
  • the processes include the MQ-Network interface, MQ Series Engine and queues and the application-MQ interface RPC Server).
  • the message agent server may include a system administration utility which is used to administer and monitor the processes and message queues.
  • the message agent server and/or message format library may include a message format utility which is used to maintain the various message formats and other meta data with a graphical user interface (GUI).
  • GUI graphical user interface
  • the message agent server may include a message archive, retrieval, and retransmission capability.
  • the message agent server database on the client application program (PC) and the server may be synchronized at certain intervals.
  • the message agent server may support the SWIFT 97 message format.
  • the message agent server may include a set of functions as remote procedure calls that application programs, for example the GlobalClear application program, may invoke to perform matching operations. These matching operations may include: matching one or more fields of messages of the same type, for example as with MT300; and/or matching one or more fields of messages of different types, for example as with GlobalClear's MT502 (order) and MT518 (execution).
  • the message agent server may include a set of functions as remote procedure calls for performing reconcilitaion operations.
  • message translation capabilities may also be included as part of the message agent server and/or message format library to translate a SWIFT message into another industry protocol message format.
  • the message agent server may be utilized to handle file transmission and telex or fax transmissions.
  • FIG 4 depicts an overview of the functional components of an embodiment of a message agent server 10 of the present invention which is linked via communication links to application programs 12, 14 and 16 and to an interface 50 to an external network.
  • a message agent server may include the following components.
  • a MQ (message queue)- Application Interface 100 which provides the interface between the persistent message queues 110 and the applications.
  • the message agent server does not allow application programs 12, 14 and 16 to access the queues directly.
  • the MQ- Application Interface serves as the broker between application programs and the message agent server message queues.
  • the MQ Application Interface allows application programs 12, 14 and 16 to send and receive messages using remote procedure calls.
  • the application program interface between the application programs and the message agent server is described in detail with reference to Figure 5 and in general in the following paragraphs.
  • Suitable technologies for implementing the remote procedure calls include the Entera TCP RPC (remote procedure call) middleware which runs on a Windows NT Server platform.
  • the message agent server may also provide its services to older legacy applications running on VAX/VMS using either Entera DCE or TCP RPC, or a socket based message passing API and middle-ware.
  • the remote procedure call for example the Entera RPC, may be used as the standard interface between the message agent server and application programs.
  • the message agent server provides services as RPC calls in application programs such as, send-message and get-message that are implemented as RPC's by the message agent server.
  • the MQ -Application Interface provides a non-polling mechanism to notify application programs of the receipt of messages after an application is on-line.
  • the application program may ask to receive all messages being held on its queue(s). Individual application programs will implement this capability in the manner best suited for their particular function.
  • Authentication may be utilized between the application programs and message agent server. When the application program signs up to use a queue everyday, an authentication & security scheme may pass a security ticket to be used implicitly in subsequent RPC calls.
  • Application programs may be designed and implemented with many different remote procedure calls (RPC's) for accessing the message agent server.
  • RPC remote procedure calls
  • Send Message When an application program has a message to send out (e.g., to SWIFT) this RPC is called so that the MQ - Application Interface can safely queue the message for transmission to the target process.
  • this RPC is called so that the MQ - Application Interface can safely queue the message for transmission to the target process.
  • the application program receives a message by calling this RPC.
  • Get Message Status An application program may inquire as to the status of a message to determine for example, if an outbound message has been sent and received by its target process.
  • Re-Queue Message The message agent server Monitor and Administration application, discussed below, will allow an operator to move messages from an error state to a queue to be transmitted, after an investigation and/or repair of the message.
  • the message queues will comprise a queue for each application program: inbound messages. In addition there will be one generalized queue for inbound and outbound problem messages. Additional queues may be defined per client (such as for priority queues) and for general use.
  • the means by which message agent server determines which queues to place messages may be based on:
  • Application ID Applications which use the message queues include the application programs and the interface application. Additional applications may be added and may be connected to the message agent server and use additional message queues. In addition, program applications may be able to send and receive messages with each other using the message agent server. Each application will have an Application ID, which is stored in a message agent server database. It is the responsibility of the application, not the MQ Application
  • a message agent server Translation Service API/RPC using the message format library, will be provided to determine an application ID from the message and map it to a queue name.
  • the message agent server may include a facility for an application to assign priorities to messages, e.g., high, medium, low and urgent.
  • the message queuing system is configured such that messages handed to it by applications are not lost by the message agent server. Once a message is handed to it by an application program, the message agent server may guarantee that the message is safely stored and that the message, once transmitted to its target, is guaranteed to have been transmitted and received. This means that messages should not be de-queued until acknowledgment of receipt has been made.
  • Asynchronous Message Delivery Messages received by the message agent server for target application programs which are not on-line at the time of receipt are safely queued for delivery when the application program comes on-line.
  • Message Logging All activities of queuing, de-queuing and requeuing, receipt and transmission of messages are logged in the message agent server in a database.
  • the log may contain the following information:
  • the message agent server 10 further includes MQ (message queue) - Network Interface 120.
  • MQ messages queue
  • the MQ - Network Interface is the component which provides the interface between the persistent message queues and interface 50 to an external network such as the SWIFT network.
  • the MQ - Network Interface is the component which provides the interface between the persistent message queues and interface 50 to an external network such as the SWIFT network.
  • the MQ - Network Interface is the component which provides the interface between the persistent message queues and interface 50 to an external network such as the SWIFT network.
  • the MQ - Network Interface will be configured to support the network and communications protocol utilized by interface 50.
  • the MQ - Network Interface also implements the queue processing of messages to be transmitted to SWIFT NETWORK INTERFACE , referred to as outbound messages, and those messages transmitted from SWIFT NETWORK INTERFACE to CrossMar client applications, referred to as inbound messages.
  • Message agent server 10 also includes Message Queuing System 130, for handling delivery of messages to and from the message queues 110.
  • the message queuing system will interface with the MQ-Application Interface 100 and the MQ- Network Interface 120 and transfer messages back and forth from the message queues to these interfaces.
  • the message queuing system may also interact with a message agent server monitor and administration system 140.
  • the message queuing system may utilize existing commercially available computer software to perform its functions.
  • a preferred product for use as the message queuing system is the IBM MQSeries product.
  • the MQ Series is a standard for message-oriented middleware, and the product is supported on a variety of platforms including VAX/VMS, Windows NT and HP-UX.
  • a message format library 140 which comprises a meta-data service 142; format service 144; parser service 146; and translation service 148.
  • the message format library and the services it provides are described in detail in a following section, and covered generally in the next several paragraphs.
  • the message agent server preferably includes access to message formatting services and information.
  • the information on format may be extended to provide metadata service to application programs as a remote procedure call (RPC) or local procedure call through an application programming interface (API).
  • RPC remote procedure call
  • API application programming interface
  • the meta-data shown as 149 in Figure 4, may comprise a number of parts including the following: representation of SWIFT message formats; code tables for certain fields, e.g., currency and country code, valid BIC id, etc. and application specific interface captions on fields.
  • GUI graphical user interface
  • a generally optional field can be mandatory optional or absent (not present in interface) for a specific application; a caption used on a GUI interface for each message, block and field; a code table used for the field values; client GUI display preference for each field such as radio box, jumbo box, or list box; and read only protection.
  • Application programs 12, 14 and 16 may include features and characteristics which differ. To anticipate uneven formats and uneven format migration in the future, the message agent server provides format conversion, through message format service
  • the message agent server can continue the service even when data source, such as the application program and the data consumer, such as the SWIFT network, do not migrate formats at exactly the same time.
  • the message agent server parses messages, using parser service 146, into array of tagged fields and may be designed to pass messages to and from applications in the following format: typedef struct ⁇ small tag; ptr, string] char *field_value; ⁇ Mas field; typedef Mas_field Mas_message[].
  • typedef struct ⁇ small tag
  • ptr string
  • char *field_value ⁇ Mas field
  • the message agent server supports the existing byte string message passing in the applications.
  • the message agent server may also include a message translation service 148.
  • the translation service may be designed utilizing the procedures described below with reference to the message format library.
  • the message agent server may include a database to store message format information.
  • Message format may be represented in generic relational database format. It may be implemented in SYBASE and or other relational databases.
  • the format service design can be ported to any relational database easily.
  • the layered architecture of a possible embodiment is illustrated in Figure 5.
  • the embodiment depicted in Figure 5 includes application program 12, which is a client on network with the network server referred to as application program server 15.
  • Application program 12 accesses application program server 15 through a remote procedure call.
  • application program server 15 accesses the message agent server 30 through a remote procedure call.
  • Message agent server remote procedure calls may provide message parsing and formatting services to application programs linked to the message agent server.
  • Application programs may also copy the message agent server format functionality to a local database 19, for example a Microsoft Access database.
  • application programs may call local functions (through local procedure calls (LPC's) to parse and format messages when off-line.
  • LPC's local procedure calls
  • These local functions may be implemented in a dynamic link library provided to the application programs linked to the message agent server.
  • the message agent server format service may access the format representation in the SYBASE database 35 through an RPC scheme set up by Entera or the representation in Microsoft Access database.
  • the Microsoft Access database may be synchronized to the SYBASE database manually.
  • Messages in each message type have the same header format, field structure and field format.
  • a group of message types sharing the same header format and code tables form a message application version.
  • the messages may be identified by their application version id, which is an integer, and their message id, which is an integer too.
  • the format representation may comprise as many as 17 tables as follows.
  • Table MAS_MSG_VERSIONS records the related dates of a message version and the overall format of messages in a version.
  • SWIFT 1, SWIFT 1 1, SWIFT 96 are version examples.
  • Table MAS_MESSAGES contains a list of all messages for each version. MT 100, MT300, etc., are messages, Table MAS GEN BLOCK lists all the blocks. Table: MAS_GEN_FORMAT; MAS_B_GEN_FORMAT
  • Table MAS_GEN_FORMAT and MAS_B_GEN_FORMAT contain a list of all fields for each message and other general attributes specified i message format standard documents.
  • MAS B GEN FORMAT is for fields in blocks.
  • This table contains all the applications and map application id to message version.
  • Table MAS_MESSAGE_TITLE contains a list of messages for each application ID.
  • Table MAS_BLOCK_TITLE gives every block a title.
  • Table MAS_APP_FIELD and MAS_B_APP_FIELD contain application specific information on fields. It also contains field format. We place field format in application specific data because different application might use different code tables while code table reference is specified in field formats
  • Table MAS CODE TABLES Instead of setting up multiple code tables, one table may be utilized to implement all code tables for the ease of implementation.
  • a table may also be utilized to represent the matching relationship useful in security trade confirmation.
  • Table MAS_MATCH contains the rules about which fields in one message should be matched to which fields in another message. Translation rules are represented in this table.
  • the format expression for messages is based on the regular expression of Norm Chomsky.
  • a convention similar to the convention utilized by the UNIX operating system and other operating systems may be utilized wherein: any literal character is prefixed with escape symbol 'V; 'a' represents any character which can be used in a field;
  • 'c' represents alphabetic characters
  • 'n' represents any digit or
  • V represents new line
  • Capital letters A, B, C, D, E, F, G and H are used for standard SWIFT formats on these format options;
  • ⁇ code_table_name> means any value from the table, ⁇ code_table_name length> includes the length of the string when the string length is fixed; '(',')'are used to group items into one item;
  • prefixing a number repeats the item by up to as many times; prefixing a number then 'x' repeats the item on up to as many lines; ' * ' , instead of a number, represents arbitrary number;
  • '+' instead of a number, represents arbitrary positive number; postfixing a number means exact number; postfixing 'x' then a number means exact as many lines; and number,'* 'or '+'on optional sub-expression, 'r' ⁇ o>or literal string is not applied to express repetition.
  • the message agent server 10 may also include a Message Agent Server (MAS) monitor and administration process 150 which includes a user interface.
  • MAS Message Agent Server
  • the administrative functions performed by the MAS Monitor and Administration Process include: Starting and stopping the MQ - Application
  • the MAS Monitor and Administration Process will preferably interact with a MAS
  • FIG. 6 is a schematic of an embodiment of an application interface for use between the message agent server and the application programs. As shown in Figure 6, an application program 12 may interface with a message agent server 10 through a remote procedure call (RPC).
  • RPC remote procedure call
  • the primary interface the message agent server provides for the application programs may be based on RPC of DCE [] style.
  • An RPC server framework with RPC stubs may be prepared with the stubs programmed in the framework to perform the functions advertised for the RPCs. These functions are covered above.
  • the RPC server is constantly running to answer RPC calls. A thread is spawned for every RPC call.
  • Working in the DCE/RPC paradigm data elements are passed to and from MAS as arrays of strings.
  • the application interface interacts with the message queing system 130 through client function calls and semaphores.
  • the application interface interacts with a message agent server format library 120, through library function calls.
  • the message agent server format library 120 may interact with a message format library database 162 to retrieve informatin relating to message formats.
  • the message agent server handles all all RPC calls synchronously. Asynchronous processing in the application programs may be achieved by spawning threads in the applications.
  • MasGetErrors Whenever a message agent server RPC function succeeds, it returns a positive value. Otherwise, it returns a negative value which is the reference number for the errors encountered in the call.
  • the application can call the MasGetErrors furnction to retrieve all the errors as another array of character strings.
  • the message agent server format functions MasParseData and MasFormatData are also provided as dynamic link library (DLL) functions together with the MasGetErrors function.
  • the message agent server format functions may include necessary functions for passing SWIFT or other types of messages.
  • Each application program identifies itself with one or more application identifiers (Aid) each of which corresponds to a unique header format and a set of messages in specific field format.
  • the message agent server format functions are described below. Similar functions are also described in detail below with reference to the message format library.
  • the MasParseData function is utilized to parse a message.
  • a typical format for the function is as follows:
  • MasParseData Format long MasParseData ( [in] char Aid[],
  • This routine takes a formatted SWIFT message as input, and breaks it apart into the header fields, and other fields tags and values. It returns an error status if it is unable to parse the data correctly.
  • This routine is passed the Application Id in Aid, and a formatted swift message in MessageText. It pulls apart the message and breaks each of the header fields into Magld, FromBic, ToBic, GenTime, RecvTime, Priority,, and MUR. The fields are loaded into arrays FieldNumber, FormatTag, and FieldContent, with the number of fields placed into NumFields. An empty string in an output variable indicates that this optional variable is missing.
  • the Application Id is used to identify the format version. First the version format is loaded if it is not already in the memory. The function passes the header to get the message id and use it to locate, or load when not already in memory, the message body format. When a failure occurs, it will attempt to look for the next good field and resume parsing while registering an error.
  • the MasFormatData routine may be used as a local procedure call by an application program to validate and construct a SWIFT message. Message construction is done either by the client or the message is received over the SWIFT network. Formatting checks are preferably performed at the message agent server.. The function checks for mandatory fields, and verifies the values of all of the fields, including size. If an error is detected in parsing, the return value of the function is the Error Reference number that can be used to find the text errors corresponding to this message with a call to
  • the first parameter, Aid specifies the application Id that is requesting the function.
  • the routine takes input parameters of all of the fields that comprise the SWIFT header (Parameters 2 to 6).
  • the three arrays of string are the specific fields of the swift message.
  • FieldNumber and FormatTag together form the field tag (i.e., 7 1 a).
  • the corresponding array position in FieldContent is the value of that field.
  • MessageText is the returned formatted Swift message including header, trailer and fields.
  • NumFields contains the number of fields that passed into the routine.
  • An empty string in input header variables indicates the optional variable is absent.
  • message agent server may be constructed to perform limited field sorting and thereby sort fields not in repeatable blocks, rather fields can be passed in random order except that the fields in repeatable blocks have to follow their order in their correspondent blocks.
  • the Appld and Msgld are used to identify the format version and body format which is loaded if it is not already in the memory.
  • the variables are used to form the header and the fields to form the body. When a failure occurs, it will attempt to look for the next good field and resume formatting while registering an error.
  • the MasSendMsg routine will take a SWIFT message passed into it, and send the mesage out to the SWIFT network. It is passed in as a dynamically allocated string in Message. Appld is a constant pertaining to the application that is sending the messages.
  • MUR The format of MUR is "yyyymmddXXXnnnn" where: yyyy is the year, and mm is the month, and dd is the date, and
  • XXX is the application code (FXM, FXO, FXS, FXL, etc.), and nnnnn is the sequence number.
  • Another RPC function SentMsgStatus can be called with the parameter MUR to check the status of a sent message.
  • the Appld can potentially trigger a translation before the message is queued.
  • the MasSendMsg funtion calls MQPUT to place the message on a designated outgoing queue. It also puts the MUR and the status of a message in the status queue for all outgoing messages (QL_OUT_STATUS). It returns successfully after all the actions finish successfully.
  • the MasReceiveMsg function is utilized by application programs to request a message addressed to the receiver identified by the Appld (Aid). It returns the first message in corresponding queue or the first to arrive in Message, i.e., the messaging mechanism is synchronous.
  • the applications use other means to achieve asynchronous messaging.
  • the MasReciveMsg function first attempts to decrement a semaphore guarding the corresponding receiving queue. After it passes the semaphore, it uses MQGET to retrieve the message and pass it back to the caller through the output variable. It will also put a new status of the message in the status queue for all incoming messages (QL_IN_STATUS).
  • the message agent server may include utility functions such as the utility functions described below.
  • This SentMsgStatus routine takes the unique reference number, MUR. of a message previously sent by SendSwift and returns the status of the message in the output variable Status.
  • a typical format for the function is as follows: Format: long SentMsgStatus (
  • the SentMsgStatus routine will use the MUR as a key to retrieve the latest status of the sent message from the status queue for all outgoing messages (QL_OUT_STATUS).
  • the RecentMsg Status function takes an application id (Aid) and returns all new message statuses since the last time this routine was called with the same application id. The function also returns the MUR of each corresponding message for each new status.
  • RecentMsgStatus routine Every time the RecentMsgStatus routine is called, it gets the time stamp (format: yyyvmmdd) of the last call of the routine with the passed-in application id and the sequence number of the last retrieved message from an initiation file
  • the MasGetErrors function is utilized to obtain ErrorReference numbers created during parsing or formatting of a message. If the parse or format functions return an error value, the number returned is the ErrorReference number. When this number is returned, the message agent server looks up the number and returns an array of strings that describes the errors that were encountered in the original call as text strings, with field number and format tag in the beginning of each line if necessary. Up to 32 errors may be returned at a time. The errors are returned in the variable ErrorDetail.
  • a typical format for this function is as follows: long MasGetErrors
  • FIG. 7 illustrates the architectural design of a message queue for use in a message agent server of the present invention.
  • the message queue is described with reference to IBM's MQSeries message queueing engine, however the message agent server of the present invention may utilize other message queueing services to perform similar functions.
  • the queues identified and described are examples of the types of queues which may be utilized.
  • the system is further described with reference to a SWIFT NETWORK INTERFACE which utilizes an X.25 type link.
  • the message agent server may provides messaging and queuing capabilities for financial service industry application programs such as the FX Options application program, the FX Match application program and the FXM ST (Foreign Exchange Statement Requests) application program. These applications receive and send SWIFT messages through the message agent server which in turn communicates with a SWIFT NETWORK INTERFACE via an X.25 link.
  • the message agent server may utilize IBM's MQSeries to facilitate sending messages to and receiving messages from the SWIFT NETWORK INTERFACE.
  • the overall design is depicted in Figure 7.
  • the computing environment includes the FXM ST application program, 212, the FX Match application program 214 and the FX Option application program 216.
  • the programs are linked through remote procedure calls (RPC's) to an MQ Series Server, 220. [Need description of remaining components 231- of Figure 7. These components are described in greater detail in the following paragraphs.
  • the MQSeries allows Windows NT applications use message queuing to participate in message driven processing. Applications can communicate across different platforms by using the appropriate message queuing software products. For example, Windows NT and MVS/ESA applications can communicate through MQSeries for Windows NT and MQSeries for MVS/ESA respectively. The applications are shielded from the mechanics of the underlying communications.
  • MQSeries products implement a common application programming interface (message queue interface or MQI) whatever platform the applications are run on. This makes it easier to port applications from one platform to another.
  • MQI message queue interface
  • the exchange of messages between the sending and receiving programs is asynchronous.
  • the sending and receiving applications are time- independent so that the sender can continue processing without having to wait for the receiver to acknowledge the receipt of the message.
  • the target application does not even have to be running when the message is sent; it can retrieve the message after it is started.
  • messages can automatically start an application using a mechanism known as triggering. If necessary, the applications can be stopped when the message or messages have been processed.
  • a queue manager manages the resources associated with it, in particular the queues that it owns. It provides queuing services to applications for Message Queuing Inter-face (MQI) calls and commands to create, modify, display, and delete MQSeries objects.
  • MQI Message Queuing Inter-face
  • the message agent server queue manager (MASQM) may be created with the following attributes:
  • Dead letter queue SYSTEM.DEAD.LETTER.QUEUE
  • the environment may be created with users defined specifically for MQSeries administration tasks. This user should have the allmqi permission assigned to their id or should be in the mqm group.
  • MQI message queue inquiry
  • QL_ERROR_MAS Error Queue used by the X25/MQSeries process and the MQSeries/RPC Server process.
  • QI INOUT MAS Initiation queue used to trigger an incoming or outgoing message event.
  • QI ERROR MAS Initiation queue used to trigger an error event
  • the MQSC script to create these queues is as follows.
  • MQI channels connect an MQI client to a queue manager on a server machine.
  • the MQSC script to create these queues is as follows.
  • a triggering function may be implemented to trigger a call to a queue when a message is waiting for delivery or transmission.
  • the triggering processes may be implemented in a batch file utilizing the following protocol.
  • Step 1 Start the listener for MASQM to use TCP/IP and to listen on Port 1414 (default port).
  • Step 2 Start the trigger monitor to wait in the initiation queue for a trigger message.
  • Command runmqtrm. /m MASQM /q QI_INOUT_MAS
  • the output from all of these processes may be sent by using normal output redirection methods.
  • the appropriate trigger will fire and the program incsem.exe will be invoked.
  • the program will parse the trigger message and increase the appropriate semaphore so the message agent server server will be signaled.
  • the message agent server will then connect to the appropriate queue manager, open the appropriate queue, and read all of the messages until the queue is empty. At this point the program will return and wait for the next trigger to fire.
  • the protocol for troubleshooting the triggering function may include the following items. Checking the local queue definition to ensure that the NOTRIGGER parameter is not set, and that the PROCESS and INITQ fields have the correct values. Checking to ensure that the INITQ and PROCESS objects exists.
  • the commands are: runmqsc ⁇ QueueManager> dis q(initQueueName) dis pro(processName) all
  • the output from the display process command may be viewed to ensure that the path to the triggered program is correct, and that the program is there.
  • the state of the trigger monitor may also be reviewed to ensure that the trigger monitor in running, and connected to the correct initiation queue for the appropriate Queue Manager.
  • the process may be alter to turn DEBUG on and send a message and the result reviewed.
  • the trigger system may also be troubleshot may using the trigger type of FIRST and making sure the queue is empty before A user start the trigger monitor (see runmqtrm command).
  • a trigger type of DEPTH may also be utilized. When the DEPTH triggers fires, the queue manager will set the NOTRIGGER attribute. It is the responsibility of the triggered application to issue the MQSET call to reset the
  • the message agent server may include security features.
  • Security in MQSeries for Windows NT uses the users and groups that are created in the "User Manager Facility" from the Windows NT "Administrative Tools" icon. If a user Id belongs to the "mqm” (IBM MQSeries Administration Group) A user will have all of the authorities to all resources. There are situations, such as production environments that the more secure features of MQSeries will need to be in place, to ensure protection of system resources as well as protection of data.
  • the command used to establish specific permissions against MQSeries objects is setmqaut.
  • a user must be in the mqm group to use this command.
  • the parameters that follow this command are listed below. setmqaut /in Queue Manager Name (Queue Manager Name that owns the object) /n Object Name (Name of the Queue or Process. Not needed if the Object
  • dspmqaut /m Queue Manager Name (Queue Manager Name that owns the object)
  • Entity binli has the following authorizations for object QL OUT CTSW: get browse put inq set crt dlt chg dsp passid passall setid setall clr Queue Manager permissions may be implemented and are preferably controlled with careful consideration. All processes that will be issuing MQI interface calls, are preferably started using a functional ID or GROUP for that process. This ID or GROUP will need the ability to issue an MQCONN call, to connect to the Queue Manager. The command to enable this connection is shown below: setmqaut /in queue.manager. I /t qmgr /p binli +connect This command would allow a process started with the binli userld access to connect to the Queue Manager.
  • Queue Manager The other permissions on the Queue Manager should be assigned to an entirely different group, that will be used for administrative purposes. Especially chg (Change), crt (Create), dlt (Delete) and any of the all* authorities. Queues are the facility used to store data. Whether persistent or non-persistent, the data is preferably protected from intrusion, or accidental access. Each application that is running on a given platform, can be limited to the objects it can use and what functions it can perform on these objects.
  • a process is an event specified to occur when the trigger criteria for a local queue has been satisfied
  • the commands for setting and revoking these permissions follow the same conventions as Queue Managers and Queues.
  • the message agent server MQ/Series server may be installed and deployed on a computer platform utilizing the following steps: Step 1. Action: install MQSeries in C: ⁇ mqm Explanation: C: ⁇ mqm is the recommended directory
  • Step 2 Copy C: ⁇ masq from a development machine Explanation: including all subdirectories Step 3.
  • genBatch creates all the NT batch files used in the steps below. While running, A user is asked to specify root directory for the following:
  • Step 6 Action: run C: ⁇ rnasq ⁇ commands ⁇ crtdefob.bat Command: runmqsc ⁇ C: ⁇ mqm ⁇ mqsc ⁇ amqscoma.tst > C: ⁇ mqm ⁇ mqsc ⁇ defobj.out
  • Step 7 Action: run C: ⁇ masq ⁇ commands ⁇ crtmasob.bat Command: runmqsc ⁇ C: ⁇ masq ⁇ objects ⁇ masqm ⁇ masqmobj.in > C: ⁇ masq ⁇ obj ects ⁇ masqm ⁇ masqmobj. out
  • Step 10 create shortcuts to stmasqm.bat and stmasqml.bat and put them in the startup folder Explanation: so they will be automatically started on NT restart
  • a message agent server of the present invention will include methods for handling errors, including message delivery errors, message format errors and the like.
  • a possible means for error handling is set forth in the following paragraphs.
  • All message agent server errors may be put in a local queue QL ERROR MAS.
  • a trigger may then be fired every time a message is put on this queue.
  • a trigger program GetError.exe will in turn be invoked to get the error message and post an entry in the NT event log (viewable from NT event viewer).
  • the GetError process is triggered for every message that arrives on the QL_ERROR_MAS queue.
  • the message agent server may be configured with three categories of errors, namely MAS NFO, MAS_WARN, and MAS ERROR. These categories are defined in the following script used by NT event log.
  • the message agent server may include functionality for handling different types of errors depending on the needs of the application programs and network interface.
  • the message agent server includes a network interface to allow messages to be passed to an external network such as the SWIFT network.
  • the interface or gateway to the SWIFT network may be included within the functionality of the message agent server as a local function, ie residing on the same server (computer hardware).
  • the message agent server may interact with the interface or gateway through a communications link.
  • Figure 8 depicts an embodiment of a message agent server architecture wherein the interface to a SWIFT network is provided by an X.25 interface.
  • a computing environment may include the FX Options application program 216 and the GlobalClear application program 218 which each link to message agent server 10, through a remote procedure call to the application interface
  • the application interface 100 is linked to message queue manager 130, which manages the message queues 110.
  • a message queue network interface 120 is provided to interface between the message agent server and the X.25 network 45 which includes a SWIFT NETWORK INTERFACE 50.
  • the message agent server is also linked to a message format library 145.
  • the application programs, application interface, message queue manager, message queues and message format library are described in preceding sections. The following paragraphs describe a possible embodiment of a SWIFT NETWORK INTERFACE utilizing an X.25 network connection.
  • the message queue network interface Connection Module is one of the integrated components of Message Agent Server (MAS). This module may utilizes EiconCard technology to provide X.25 interface thus enabling applications to exchange messages with an X.25 network through message agent server.
  • the interface may also handle message security, exception handling/recovery, and much more.
  • the X.25 Interface Between message agent server and SWIFT NETWORK INTERFACE may be implemeneted as follows.
  • the application level protocol between the message agent server and the SWIFT NETWORK INTERFACE may follow the CMX's X.25 interface standard, which provides a message transfer mechanism between CMX system and a remote DTE like message agent server through X.25 network.
  • the 'interface between message agent server and CMX operates on Switched Virtual Circuit (SVC).
  • SVC Switched Virtual Circuit
  • SWIFT NETWORK INTERFACE The SWIFT NETWORK INTERFACE will send "ack” or "nak” back to the message agent server over the same channel. This channel is the SEND ONLY channel for message agent server.
  • Another circuit is to allow the message agent server to receive message from the SWIFT NETWORK INTERFACE.
  • the message agent server will send ack or nak back to the SWIFT NETWORK INTERFACE over the same channel. This channel is the RECEIVE ONLY channel for message agent server.
  • These two channels may use the same DTE address pair between the message agent server and the SWIFT NETWORK INTERFACE. During normal operations, the two channels will generally not interfere with each other.
  • the CMX protocol also states that the SENDER is responsible to establish the network connection and to retry the connection if the link is disconnected.
  • Initialize event queue for logging system events When the message queue network interface starts, it may take the following initialization steps: Initialize event queue for logging system events.
  • the X.25 server module spawns two link threads, 121 and 123: one manages the inbound channel, the other takes care of outbound channel..
  • the server module terminates after both link threads are terminated.
  • mapping table For mapping among applications, queues, and semaphores. This mapping table must be persistent.
  • MQ Manager Message Queuing System
  • MQ Manager Message Queuing System
  • SWIFT NETWORK INTERFACE If the MQ Manager or message agent server RPC Server is not started, the above initialization steps will fall, and the link thread will terminate itself If everything works fine, the link thread will begin its normal operation.
  • link thread There are a certain number of protocol stages that the link thread runs into. At each stage the link thread should call certain application 'interface functions based on what application the handling message belongs to.
  • link thread When link thread wants to shutdown itself, it does the following: Close the VC connection to SWIFT NETWORK INTERFACE , For each application the thread interacts with, close semaphores and all queues, but don't touch the messages. Close the error queue, and disconnect from message agent server queue manager. Unload the mapping table among applications, queues, and semaphores. Make persistent change if changes are needed.
  • the Message Queuing System may utilize a set of queues configured by MQSeries.
  • Queue Manager For each message flow direction, Queue Manager provides a status queue to report message transfer status.
  • the status messages in these queues has the following format: yyyymmddXXXNNNNnnnnnS
  • Possible values for the status code are: P(ending), S(uccess), and F(ail).
  • the Message Queue Network Interface module When the Message Queue Network Interface module gets the message from QL_OUT_CTSW, it will transfer it out to the X.25 network. Based on the result of transfer, it will put a status message back to the outbound status queue QL_OUT_STATUS with the message reference number and the status code.
  • the status code is either S or F.
  • the Message Queuing System gets the status message and process it.
  • the Message Queue Network Interface module When the Message Queue Network Interface module get a message from X.25 network, it will put it onto appropriate queue based on the application it belongs to. It will also construct a status message and put it onto the inbound status queue QL IN STATUS with the message reference number and the status code. The status code is P for pending status.
  • the Message Queuing System gets the application message. After the message is transferred to application, the Message Queuing System will update the status of the status message.
  • modules including an Outbound Service Module and an Inbound Service Module. These modules may be part of the message queue network interface.
  • the Outbound Service Module is responsible for sending application messages out to X.25 network over the SEND CHANNEL. Basically this module is in one of the following three states: 1. CALL State When the Outbound Service Module starts, it's in this state by default. The
  • the sender can start sending messages. For every message directed to SWIFT NETWORK INTERFACE, it may follow this procedure: Get message from the Output Queue (QL_OUT_CRSW) but do not remove it from the queue. Send message to SWIFT NETWORK INTERFACE .
  • the sender will generate a 16-bit CCITT CRC checksum for the message, append the two byte checksum to the end of the message.
  • the SENDER will segment the whole message with checksuM into one or more X.25 data packets. The packet size is determined at CALL time following X.25 protocol standard. The last packet of the message will not have the
  • the SENDER After sending a message, the SENDER will wait for the acknowledgment from the RECEIVER. The SENDER will increment the sequence number and remove the current message from the Output Queue of the Queue Manager only if a good acknowledgment is received.
  • the SENDER will log event to the Event Queue for whatever happened.
  • the outbound X.25 link server may manage the link with a finite state system.
  • the state diagram is shown in Figure 9.
  • To Be Connected State, 301 This is the initial state. The circuit is disconnected. When link server is in this state, it's about to issue a call request to SWIFT NETWORK INTERFACE . After x25call() is issued, it goes to Pending Connect State.
  • Pending Connect State 303: A call request was issued, the link server waits for the result. If result is OK, it goes to Connected State, otherwise, it goes to Fall
  • Fail Connect State 305: System is in this state if the pending call request failed or timed-out, and the circuit is not up. It waits on this state for a certain period of time. After the timeout period, it goes to To Be Connected State and try to connect again.
  • Connected State, 307 This is the idle state for normal operation cycle. Circuit is up, the link server is waiting for new message from applications. There is no message exchange activity going on the circuit. If message comes, it'll send it with x25send() and go to Pending Send State.
  • Pending Send State 309: A message was sent out, the link server waits for the result. If result is OK, it goes to Wait Reply State, otherwise, it goes to Fail Send State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending call with x25cancel(), and go to Fail Send State.
  • Wait Reply State 313 : A message was successfully sent out.
  • the link server issues x25recv() for the reply message from SWIFT NETWORK INTERFACE , then go to Pending Reply State.
  • Pending Reply State 315: The link server waits for the result of getting reply message from SWIFT NETWORK INTERFACE . If result is OK, it goes to Process Reply State, otherwise, it goes to Fall Reply State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending call with x25cancel(), and go to Fail Reply State. Fall Reply State, 317: The link server failed to receive the reply message from
  • SWIFT NETWORK INTERFACE It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly because of the problem found in the last message we sent to them, or for some other reasons.
  • the result of the last x25recv() call tells us if the circuit is up or down. If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x25call() there.
  • Process Reply State 319: In this state the link server examines the reply message it Just got from SWIFT NETWORK INTERFACE related to the last message sending. If the reply message indicates that the message sending is OK, the link server will do the appropriate processing like increment the sequence number, and go to Connected State, where it's ready to send the next message. If the reply message indicates there is a non-fatal protocol problem, the link server will back out the last message sending, make appropriate correction, and go to Connected State to resend the message. If problem is fatal, the link server will go to Clear State and hang-up the circuit there. Reset State, 321 : The X.25 circuit is up, but there is a problem that the circuit must be cleared and reestablished. So the link server will hang-up the circuit, then go to To Be Connected State to reissue x25call().
  • the link thread does the following: Make semaphore not signaled.
  • Reply message is "00 - ACCEPTED".
  • Outbound link server takes action 0: Increment SWIFT NETWORK INTERFACE outbound sequence number, so next message will use a higher number. The number used after 9999 must be 000 1.
  • Reply message indicates that outbound link server should take action I or 2. This is generally an application error, so link server should reply to application with a nak message. Remove the message from the queue bound to the semaphore. Insert an nak message to the reply queue back to application. The nak message contains application sequence number.
  • MQ Series will signal the reply semaphore.
  • the content of the nak message is important. It should provide enough info ⁇ nation for the application to correct the message. At least it must have severity code, error type code, and error message. Action 2 is more severe. It means the problem is at system level, not message level. The application probably should be terminated to avoid further damage and then investigate the error.
  • the outbound link server does not increment SWIFT NETWORK INTERFACE outbound sequence number, so next message will use the same number.
  • the link server must log the message transfer result.
  • link server If for some reason, link server get triggered, but unable to get the new message, it won't be able to send that message out. Instead it goes back to wait for the new semaphore triggering event. It's possible that message is sent out, but link server fail to give sent status back to application. If this happens, when the link server got Ack/Nak from SWIFT NETWORK INTERFACE later, it destroys the original message from the message queue, but won't be able to update message status again. So application don't know the correct status of this message. In other words, it is preferably that a message and its status must be synchronized at all time.
  • the Inbound Service Module takes care of the RECEIVE CHANNEL. Basically it's in one of three states: 1. LISTEN State: When the Inbound Service Module starts, it's in this states by default. It listens to incoming call request from the specified remote SWIFT NETWORK INTERFACE DTE. For security purposes, this RECEIVER will check and verify the incoming DTE, only calls from predefined SWIFT NETWORK INTERFACE DTE are accepted. 2. WAIT-MSG State: The RECEIVER will continuously receive data packets until detecting a packet without a M(ore) flag. During the process, it assembles the message by concatenating received packet data.
  • the last two bytes is the 16-bit CCITT CRC checksum of the whole message.
  • the real message is two bytes short from what received. So the RECEIVER will recalculate the checksum and verify with the received checksum. If the checksums don't match, the RECEIVER will send the nak message to SWIFT NETWORK INTERFACE with the error code "30 - INVALID CHKSUM" as data.
  • the inbound X.25 link server may manage the link with a finite state system.
  • the state diagram is shown in Figure 10. The states defined in Figure 10 are described below.
  • Pending Connect State 403 : A listen was issued, the link server waits for an incoming call from CITIS WITCH. If a call comes in, and the circuit setup OK, it goes to Connected State. If the listen failed, it goes to Fall Connect State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending listen with x25cancel(), and go to Fail Connect State.
  • Fail Connect State 405: System is in this state if the pending listen failed or timed-out, and the circuit is not up. It waits on this state for a certain period of time. After the time-out period, it goes to To Be Connected State and try to listen again.
  • Connected State 407: This is the starting point for normal operation cycle. Circuit is up, the link server issues x25recv() on the circuit to wait for new message from SWIFT NETWORK INTERFACE . Then it goes to Pending Receive State.
  • Pending Receive State 409: If message comes, the x25recv() will return OK, and the link server goes to Wait Reply State to prepare for the reply message to SWIFT NETWORK INTERFACE . If the x25recv() call failed, it goes to Fail Receive State. If no message from SWIFT NETWORK INTERFACE , the link server will stay in this state.
  • Fail Receive State 411 : The last receiving message call failed. It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly due to the problem found during the last message exchange, or for some other reasons.
  • the result of the x.25recv() call tells us if the circuit is up or down. If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x251isten() there.
  • Wait Reply State 413: A message was successfully received.
  • the link server processes the message, sends to application. Based on its result, the link server prepares the reply message and sends it back to SWIFT NETWORK INTERFACE with x25send(), then it goes to Pending Reply State.
  • Pending Reply State 415: The link server waits for the result of sending reply message to SWIFT NETWORK INTERFACE . If result is OK, it goes to Connected State and deals with next message. Otherwise, it goes to Fail Reply State. If the reply sending process has no result after time-out period, link server will cancel the pending send with x25cancel(), and go to Fail Reply State.
  • Fail Reply State 417: The link server failed to send the reply message to SWIFT NETWORK INTERFACE. It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly because of the problem found in the last message we sent to them, or for some other reasons.
  • the result of the last x25send() call tells us if the circuit is up or down, If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x251 lstenf) there.
  • Reset State 419: The X.25 circuit is up, but there is a problem that the circuit must be cleared and reestablished. So the link server will hang-up the circuit with x_25hangup(), then go to To Be Connected State to reissue x251isten(), Shutdown State, 421 : The circuit is disconnected and there is no reason for the link server to stay alive. This usually happens when severe errors happened to the circuit, or after user closed the circuit.
  • a typical message processing scenario may look as follows. For inbound link, after the X.25 connection is up, the link is at connected state, with no message exchange activities active. The link thread is at its initial state:
  • x25recv() it issues x25recv() to wait for a message from SWIFT NETWORK INTERFACE . If the x25recv() failed: Reset the inbound circuit. If the VC is already closed, issue another x251isten() to reconnect it. The goal is to go back to the initial connected state, then try to receive another message.
  • the link server performs the message checking steps. If it encounters any error during the following checking, the link server takes actions by itself and sends CMX level reply message back to SWIFT
  • the link server It is not required that the link server notify the applications about these errors. If the message is correct, the link server will do this: Add application sequence number to the message.
  • the link server whether its ack or nak, the link server must reset the inbound circuit to its initial connected state and wait for new messages coming from SWIFT NETWORK INTERFACE .
  • the message received from the SWIFT NETWORK INTERFACE may be either a real transaction message from SWIFT or the Nak message from SWAN or
  • SWIFT mostly due to message format problems. If it's a Nak from SWAN or SWIFT, the link server will put the Nak message onto Error Queue instead of normal application message queues. If it fail to put it onto Error Queue, the link server will reply "27 - UNDELIVERABLE MESSAGE" back to SWIFT NETWORK INTERFACE .
  • the link server fails to parse the incoming message from the SWIFT NETWORK INTERFACE, or fall to put it into application message queue due to MQ problems, it'll send a "27 UNDELIVERABLE MESSAGE" back.
  • the SWIFT NETWORK INTERFACE will shutdown the circuit, then try to connect again.
  • the link server can not get the status message indicating that the message has been delivered to its application system. This may because that message queueing service is down, or message agent server RPC server program is not up. If this happened, the link server is unable to send reply back to the SWIFT NETWORK INTERFACE . The CMX protocol may hang up in this dead lock. Sometimes the link server may fail to send reply back to the SWIFT NETWORK INTERFACE because circuit is already down for some reason, most probably the SWIFT NETWORK INTERFACE cleared it. In this case the link server will listen again, but after reestablished the cuicuit it won't resend the reply. Instead it'll wait for the next incoming message, most likely is the previous one with PDE. If this is the case, it should discard the new message and reply "00 - ACCEPTED".
  • the message agent server is constructed so as to provide synchronization between the message agent server RPC server (MQ-Application Interface) and the X.25 server (Message Queue Network Interface). Synchronization is desirable to achieve the following goals: no message from the message agent server
  • RPC server to the X.25 server is lost; no message from the message agent server RPC server to the X.25 server is lost; no message is sent more than once from the message agent server RPC server to the X.25 server; no message is sent more than once from the X.25 server to the message agent server RPC server. Synchronization may be accomplished in a variety of manners. One technique is described below.
  • the message agent server RPC server and the X.25 server communicate through semaphores, namely SEM OUT CTSW, SEM_IN_FXO, SEM_IN_FXM, and SEM_IN_STM.
  • the message agent server RPC server has to make sure that the value of the semaphore SEM OUT CTSW always equals to the number of messages in the queue QL_OUT_CTSW.
  • the X.25 server has to make sure that the value of SEM_IN_FXO (SEM_IN_FXM, SEM_IN_STM, respectively) always equals to the number of messages in the queue QL_IN_FXO (QL_IN_FXM, QL_IN_STM, respectively).
  • MAS QM is up. So send all messages *in QL_OUT_CTSW, then wait. Failed: MAS QM is down. No way to retrieve any message. So quit.
  • MAS RPC Server is up. Semaphore must be initialized to the message count. Then it connects to message agent server QM.
  • MAS QM is up. So send all messages in QL_OUT_CTSW, then wait. Failed: MAS QM is down. No way to retrieve any message. So quit.
  • Inbound Service Open SEM_ERROR_MAS_all semaphores for application queues.
  • MAS RPC Server is up. Semaphore must already be initialized to the message count. Now connects to MAS QM. Succeeded: MAS QM is up. So start operation.
  • Semaphore must be initialized to the message count. Then it connects to message agent server QM.
  • FIG. 11 An alternative embodiment of a computing environment utilizing the system of the present invention is depicted in Figure 11.
  • the depicted embodiment includes 4 servers, a message agent server (MAS), 600 for interfacing with application programs 601 ; an X.25 Server, 602, utilized for access to the SWIFT network, 603; an administrative server, 604 which provides a human interface to the system, through graphical user interface 605; and a File Tranfer Server (FTS), 608 for communicating with other customers, 609.
  • the MAS, X.25 and Administrative servers have access to the message queue, 610 which is preferably an IBM MQ Series.
  • the FTS server's access to the message queue is through the MAS server.
  • the X.25 server is responsible for communicating with a SWIFT network gateway and ultimately the SWIFT network through an X.25 protocol.
  • This protocol maps a logical connection to a station ID as a means of identification and the sequence number as a means of synchronization. Each side needs to keep track of its sequence number, only messages with the same expected sequence number are accepted. Details relating to the X.25 protocol and message traffic to and from the SWIFT network are set forth in the preceding sections.
  • the FTSIN server is responsible for processing files received from customers.
  • FTSIN file transfer facility
  • the FTSOUT server is responsible for processing files or messages to customers.
  • An application can use Connec Direct to transfer files to the FTSOUT server.
  • FTSOUT will reformat the file according to the customer specification and leave the file in a specific directory to be downloaded by the customer.
  • An application can also use the messaging infrastructure to send messages to FTSOUT and FTSOUT will treat the message as a file from the application.
  • GUI The Administrator Graphical User Interface
  • an administrator is able to monitor the health of the system and to control and manage the system components. It also provides facilities to query the messaging metrics, and the event database.
  • the administrative server is an interface between the Administrator clients and the messaging infrastructure. This server allows an administrator to start and to stop a system component, to examine the message queues and to move messages from one queue to another queue.
  • Figure 12 depicts a MAS data access model.
  • An Event Log Server, 620 may be responsible for recording all events in a local machine and to upload the events at a regular interval to a common database, 630. Even if the database is not available or slow, the server still writes the events to a local log file as a backup and also to provide a consistent level of performance.
  • the event log server is also programmed to purge the database and the local log files after a defined retention period.
  • the MAS may further include a database access server, 622.
  • the database server provides a common interface to the database, 630.
  • a MAS process may use this server to access the database.
  • the database amy the MAS events, the sequence numbers, the daily volume counts, the metrics information and the FTS customer profile.
  • the database may be constructed in the manner described above with reference to other embodiments of the present invention.
  • MAS may use DCE security for user authentication. Only users belonging to authorized groups can gain access to MAS services. Following is the convention to enforce DCE security.
  • the principal who starts a server will have the name defaulted to %host%/%service% where %host% is the machine name and %service% is the service name.
  • a server principal should belong to the group "MASServers.”
  • a human MAS client should belong to the group “MASUsers.”
  • a machine MAS client should belong to the group “MASCallers.”
  • a MAS service is generally authorized for the groups “MASServers,” “MASCallers” and “MASUsers.”
  • MAS servers may also be subject to strict NT security.
  • MAS servers run under an NT account "MAS Services.” This account has full permission to access files under the MAS root directory.
  • Message queue objects are protected by MQ authorization. Only authorized clients can gain access to an MQ object.
  • a special NT group "MQClients" is defined for this purpose. An NT user can access MQ queues if the user belongs to the "MQClients” group. For this reason, the NT "MASServices" account also belongs to the "MQClients” group to allow MAS servers to access MQ queues.
  • an embodiment of the system of the present invention may include an administrative interface to allow an administrator (i.e. a human) to monitor, control, manage and investigate the message agent server system.
  • the administrative client may be use ActiveX controls installed as follows. To ensure proper operation of the client program, ActiveX controls need to be installed in the client machine. The following ActiveX OCX files should be included: i. Graph32.OCX ii. Grid32.OCX iii. MSCal.OCX iv. Tabctl32.OCX
  • GUI may utilize the following operational procedures to monitor, control, manage and investigate the MAS system.
  • the system will be configured so that a product administrator must use a suitable data encryption program, such as Smartgate, and DCE authorization to login to MAS.
  • the MASGUI program will display a menu screen, Figure 13, from which the administrator can select:
  • the MAS system may be monitored utilizing a system monitor screen.
  • the system monitor screen, Figure 14 displays the current status of all MAS servers on all machines, the number of messages on application queues, the current sequence number of each Citiswitch link and the daily traffic volume on the link.
  • a product administrator may immediately examine its contents and acknowledge that the alert has been handled. If the alert relates to a bad message, the administrator may extract the message from the error queue and inform the sender about the problem.
  • the X.25 inbound server On the inbound direction from Citiswitch to MAS, the X.25 inbound server will adjust its sequence number to match the expected number from Citiswitch. An alert is generated to alarm the condition but the server still continues to run.
  • the X.25 outbound server will adjust its sequence number to the next higher number or to the next lower number depending on the Citiswitch error code. However, this adjustment is subject to a gap, which is configured to 3, to limit the number of retries. If the sequence gap is larger than this configured parameter, the server will terminate. An administrator should then request
  • the administrator may control the message agent server system as follows.
  • Figure 17 select the services tab, choose the machine and take "All Services” option. Hit the "Stop” button to shutdown all MAS services on that machine.
  • an administrator can either select the service form the services tab or double click on an active service in the monitor screen. This will stop a single service.
  • the MASEvtLog service is a critical component that other services depend on. None shut down the MASEvtLog service.
  • an administrator can either select the service from the services tab in the GUI or double click on an inactive service in the monitor screen.
  • a system reboot generally will start all service configured on a machine. From the GUI, an administrator can select the services tab, choose the machine and take “All Services” option. Hit the "Start” button to start all MAS services on that machine.
  • the administrator may manage the message queues as follows.
  • Message queues may be browsed as follows. On the monitor screen, double click on a queue to start another window. In this window an administrator can select an option to browse, to delete or to move the message. The message text, the message ID and the queuing time as displayed on the window, Figure 18. A message on an application queue can only be moved to the error queue. Error queues may be handled as follows. On the monitor screen, double click on the QL MAS ERROR queue to open another window. Select the browse option to get the first message on the error queue. The reject reason is displayed at the bottom of the message, Figure 19. An administrator should inform the sender why the message was rejected, a note of explanation should be entered before the message can be deleted from the error queue.
  • the administrator may also perform research and investigations on the functioning of the message agent server.
  • Event searching may be performed as follows. On the monitor screen, select the events tab to open a new window, Figure 20, in which an administrator can enter parameters for querying the events database.
  • the event and its parameters are fully described in Appendix C:MAS Events.
  • the administrator may also perform metrics queuries.
  • Message volume statistics may be searched as follows.
  • the message volume statistics screen, Figure 21 allows an administrator display the hourly or the daily traffic profile within a certain period for the inbound direction from Citiswitch or the outbound direction Citiswitch.
  • the data can be displayed in the form of a table, a line chart, a two-dimensional chart or a three-dimensional chart.
  • the chart amy also be printed from a printer.
  • the message direction is relative to MAS system. Inbound means the message flows from Citiswitch to MAS. Outbound means the message flows from MAS to Citiswitch.
  • Timeline The message volume statistics can be shown hourly or daily. For example, if you want to see daily message statistics from 05/01/98 to 05/10/98. The time interval 0 starts from 05/01/98 and end at time interval 10 which is 05/10/98. The same idea applies to statistics data shown hourly.
  • Starting Date The starting date begins from the midnight of your specified date, e.g., 05/01/98 means 05/01/98 00:00:00.
  • Ending Date The ending date ends at the midnight of the next day of your specified date, e.g., 05/01/98 means 05/01/98 23:59:59.
  • Failed Messages and Message Delay Statistics may be displayed as failed message statistics, Figure 22, over a certain period categorized by application or by failure reason.
  • the message delay time is the difference between the dequeuing time and the queuing time of a message.
  • the message delay window provides the worst delay time and the delay time of total percentage messages according to normal distribution model.
  • Downtime statistics may be displayed as the down time statistics of MAS services and their respective components over a certain period of time.
  • the entry is based on host name, service name, and component name (only for external component).
  • the service downtime shows the total downtime of a particular service on a particular host. i.e. If the same service is running in two different hosts, and when they go down, two separate entries will be recorded in the table.
  • the component downtime shows the total downtime of a particular component on a particular host with the same service name.
  • Advanced message statistics provides the message statistics from different views, Figure 23 : by message types, by BIC codes or by GCN codes.
  • the administrator may also monitor FTS customer profiles.
  • the Profile Selection Screen allows for selection of the profiles to view/update, Figure 24.
  • the "Inbound Profiles" Screen is accessible through the "Inbound Profiles” button on the profile selection screen.
  • the inbound profiles dialog box, Figure 25, displays a list with all inbound profile records in the database.
  • the "Cust. ID,” “Pattern #” and “Pattern” fields are displayed, as shown in the sample below.
  • a description of the buttons (and their use) found in this screen is as follows:
  • New is used to add a new inbound profile record in the database.
  • New Pattern is used to add a new pattern.
  • Delete is used to remove the selected entry from the database. Multiple entries can be selected use the Ctrl key; a range of contiguous records can be selected with the Shift key.
  • Close is used to dismiss the dialog box and return to the previous screen.
  • Cust ID is an (up to) 11 -character identification string assigned to this customer. It is a case-sensitive field. A subdirectory having the same name is created off the root of the client directory defined by the environment variable FTS_CLN_ROOT.
  • Pattern # is a sequence number assigned to each pattern defined for the "Cust
  • Pattern is the actual string used for pattern matching with a file name.
  • the only wild characters allowed are '*' (any string, including the empty string), and '?' (any single character). Limited to 64 characters.
  • Translate id is the numeric identifier of the translation method used to process the records (using MFL calls) in files matching the pattern string above. If this field is
  • Parse id is the numeric identifier of the parsing method to use to process the records (using MFL calls) in files matching the pattern string. Not used currently. Format id is the numeric identifier of the formatting method to use to process the records (using MFL calls) in files matching the pattern string.
  • Start record is a special string marking the start of a record in the file. It's used together with the "End record” string below to isolate individual records in the file.
  • End record is a special string marking the end of a record in the file. It's used together with the "Start record” string above to isolate individual records in the file. Special characters (carriage-return (CR), line-feed (LF)) are entered in a C-like fashion (CR: ' ⁇ r,' LF: ' ⁇ n'). Both "Start record” and “End record” strings are limited to 1 1 characters. For example, the '-' character alone on a line will be entered as "- ⁇ r ⁇ n" in any of these two fields.
  • Destination specifies the final destination of the record(s) in the file. There are two mutually exclusive options, displayed as radio buttons:
  • File the records are assembled in a file that is placed in the directory specified in the "Dest. directory” field (limited to 255 characters).
  • the string in the "Dest. extension” field (at most 3 characters), if not empty, is appended to the file name before placing it in the directory.
  • MAS the records in the file are queued up to MAS for delivery to the final destination.
  • the target application ID is specified in the "Dest. id" field. It is either a numeric identifier (a single digit) or a 5-character string.
  • Each record in the file is sent as a single MAS message.
  • Previous Pattern is used to display details about the previous record (in the "Pattern #” order) of "Cust. ID” in the database. An error message is displayed if there is no previous record to display.
  • Next Pattern is used to display details about the next record (in the "Pattern #” order) of "Cust. ID” in the database. An error message is displayed if there is no next record to display.
  • Insert is used to add a new record to the database. It is enabled only if any of the "Cust. ID” and "Pattern #” fields is modified.
  • Update is used to save the changes in the current record to the database. It is enabled if any field but "Cust. ID” and "Pattern #" is modified.
  • Delete is used to remove the current record from the database (and from the list in the "Inbound profiles” screen). This action dismisses the dialog box and returns to the "Inbound profiles” screen.
  • the present invention also provides a message format library which may be separate from the message agent server.
  • a message format library may include one or more of the following functions: means for parsing messages; means for translating messages; and means for validating message formats.
  • the means for validating may utilize the means for parsing such that the message is divided into its components by the means for parsing so the means for validating reads the components and compares them to a database of allowed components.
  • the means for translating may utilize the means for parsing such that the message is divided into its components by the means for parsing so the means for translating may translate the components into a different forma based upon a database of acceptable different format components.
  • the means for parsing may derive a destination address within a message and/or a source address within a message.
  • the translating means may translate messages in a first format into a second format and translate messages in the second format into the first format.
  • the present invention provides a message format library comprising: means for parsing messages; means for formatting messages into defined message formats; means for translating messages from one message format to another message format.
  • the capabilities of the message format library are provided through a set of application programming interfaces which are accesible to applications as a static library or dynamic link library.
  • the message format library further comprises a user interface in GUI (graphical user interface) format which prompts a user to enter message data.
  • GUI graphical user interface
  • the user interface may also be part of the static library or dynamic link library.
  • the message format library is particularly advantageous for parsing, formatting and translating structured financial messages, including SWIFT messages, ISITC messages, fixed-length and comma/tab-delimited messages; and messages needing to be formatted as structured financial messages.
  • Figure 27 provides a graphic overview of an embodiment of a message format library of the present invention.
  • a message format library 500 may receive and send messages from application programs or networks 502.
  • the message formal library will support a variety of different message types, such as the message types represented in the type library 504.
  • the messages may be broken down into components and fields such as those represented in the translation, matching and reconciliation engine 506.
  • the message format library will have access to databases 508 including message format and business logic data.
  • the message format library preferably uses Norm Chomsky's regular expression to represent message formats. Messages are broken into components and sub-components and their regular expression representations are stored in a relational database. The format of a certain message type is retrieved from the MFL database to build a finite automation, which is used to parse and format messages of that particular message type. After a message is parsed, it can then be translated to another message (or messages) of a different message type (or different message types). These functionalities are abstracted into a set of application programming interfaces (APIs) wrapped in a static C library and a dynamic linked library (DLL). These libraries and the MFL format database (the meta-data) constitute the Message Format Library.
  • APIs application programming interfaces
  • DLL dynamic linked library
  • the MFL C interface is implemented both as a static library and a dynamic link library.
  • the following interface functions are provided in both.
  • MessageParse accepts a formatted message and parses it into its constituent fields and variables
  • MessageHeaderParse accepts a formatted message and parses only its header
  • MessageFormat accepts a list of fields and variables and formats a message
  • MessageHeaderFormat creates a formatted message header
  • GetMFLErrors retrieves errors generated by any of the above function. LoadMessage Pre-load message formatting information for a specific message type from database to avoid spontaneous loading. This function improves run-time performance.
  • LoadMessageGroup Pre-load messages formatting information for a group of message types from database.
  • LoadMatch Pre-load match rules from database include translation rules.
  • FreeMFLString frees a character string returned by a MFL DLL function call
  • FreeMFLStringArray frees a character string array returned by a MFL DLL function call
  • FreeMFLInt Array frees an integer array returned by a MFL DLL function call.
  • the Message Format Library is available both as a static library and a dynamic link library. If you are using the library in the Windows environment, it's recommended that you use the DLL instead of the static library.
  • the header include file for both the DLL and the static library is named mfl.h.
  • the 32-bit DLL using ODBC database access is called mflacc.dll and the 16-bit DLL mflaccl6.dll.
  • the 32-bit DLL using Sybase dblib data access is called mflsyb.dll.
  • the import libraries for the 32-bit DLL are mflacc.lib and mflsyb.lib, respectively.
  • the file userpass.txt When implemented on a Windows NT platform the file userpass.txt contains information needed to access the MFL database (including database server name, database name, application name, and encrypted username and password).
  • this file may be changed with the program mflencpt.exe as follows: mflencpt server_name db_name app name user name password output file Use the data source name in place of the server name if ODBC is used to access MFL database. Notice that the output file has to be "userpass.txt" to work with this version of the format library.
  • MFL functions may be made available on a VAX platform as a static library.
  • the userpass.txt file is not necessary on VAX.
  • a user needs to setup your environment variables correctly by logging on to the ITS environment with the following command:
  • a user may also need to set the environment variable USER to be MAS_TST.
  • Each AppID corresponds to a unique header format.
  • the enum MsgType can be one of the following: SWIFT; SWIFT SORT; REPORT.
  • SWIFT is usually used for this version of the DLL. If SWIFT_SORT is passed in a formatting function, MFL performs limited field sorting ⁇ it sorts fields in non-repeatable blocks. Fields can be passed in random order except that the fields in repeatable blocks have to follow their order in their corresponding blocks. Empty string in an output variable indicates that this optional variable is missing.
  • SWIFT For any SWIFT message, the order of elements in the parameter variables depends upon whether the message is tagged incoming or outgoing. Any message sent to SWIFT should contain I as the first letter after the colon in the block 2 of the message, whereas any message coming from SWIFT will contain O as the first letter,
  • SWIFT address differs from the 11 character ISO BIC code and branch code by an additional logical terminal code, which should be inserted in the 9th position of the BIC code.
  • the logical terminal code for all messages sent to SWIFT should be X, i.e., for all messages tagged I in block 2, the 9th character of the SWIFT address should be X. Note also that the sender and receiver addresses are reversed for incoming and outgoing messages.
  • an MFL function Whenever an MFL function succeeds, it returns a positive value. Otherwise, it returns a negative value, which is the reference number for the errors encountered in the call.
  • An application can call GetMFLErrors to retrieve these errors. When a failure occurs, the parsing functions will look for the next good field and resume parsing while registering an error. The formatting and translation functions work in this best-effort fashion as well.
  • All MFL functions allocate space needed for the returned parameters. Therefore, it's not necessary for the calling program to allocate memory for the parameters beforehand. However, to prevent memory leaks, the program should free parameters returned by MFL functions at suitable times.
  • the MFL may include the following parsing functions. MessageParsef); MasMsgParse(); MessageHeaderParse()
  • the MessageParse() specifications may be as follows: long MessageParse (
  • the MasMsgParse() specifications may be as follows: long MasMsgParse ( [in] char* Aid,
  • the MessageHeaderParse() specifications may be as follows: long MessageHeader Parse ( [in] int Aid,
  • MessageParse() take a formatted swift message as input, and breaks it apart into the header variables and message body field tags and values. It returns an error status if it is unable to parse the data correctly.
  • MessageHeaderParse() takes a formatted SWIFT or CITIDEX message as input, and parses only the header of the message, returning the values Msgld, FromBic, ToBic, GenTime, RecvTime, Priority, MUR as a character string array in the parameter variables.
  • the MFL may perform the following formatting functions: MessageFormat(); MasMsgFormatO; and MessageHeaderFormat().
  • the MessageFormatO specifications may be as follows: long MessageFormat (
  • the MasMsgFormatO specifications may be as follows: long MasMsgFormat (RPC version of formatting interface)
  • the MessageHeaderFormat() specifications may be as follows: long MessageHeaderFormat ( [in] int Aid, [in] enum MsgType,
  • MessageFormat() re use d to validate and construct a swift message. All formatting checks are performed here. The function checks for mandatory fields, and verifies the values of all of the fields, including size. If an error is detected in formatting, the return value of the function is the Error Reference number that can be used to find the text errors corresponding to this message with a call to GetErrors().
  • the first parameter, Aid specifies the application Id that is requesting the function
  • Msgld specifies the message id of the SWIFT message. The value of MsgType for all current messages should be SWIFT.
  • the next string array, variables should contain the values FromBic, ToBic, Priority, and MUR in that order.
  • the three arrays of string are the specific fields of the SWIFT message.
  • FieldNumber and FormatTag together form the field tag (i.e.. 71a).
  • the corresponding array position in FieldContent is the value of that field.
  • MessageText is the returned formatted Swift message including header, trailer and fields.
  • FieldCount contains the number of fields that are passed into the routine.
  • MessageHeaderFormatO takes the parameters Aid, Msgld, MsgType, and variables as input, and returns the formatted message in the parameter MessageText.
  • the MFL may include a MakeCommonReference() function.
  • the MakeCommonReferenceO specifications may be as follows: long MakeCommonReference ( [in] char* Aid, [in] char* fromBic,
  • Translation functions provided by the MFL include the following: MessageTranslateOneToOne(); and MessageTranslateOneToMany().
  • the MessageTranslateOneToOne() specification may be as follows: long MessageTranslateOneToOne ( int tid, char **variables, char *from Text, char ** to Text)
  • the MessageTranslateOneToMany() specification may be as follows: long MessageTranslateOneToMany ( int tid, char ** variables, char *fromText, char ***toText, int * successCount, int * failureCount)
  • Both MessageTranslateOneToOne and MessageTranslateOneToMany load a set of translation criteria defined in the MAS MATCH table and use them to translate a message (from Text) into another message or any array of messages (toText).
  • the parameter variables, an array of strings also may be used to specify values of parameters defined for the output text. If you do not wish to specify any parameters, simply pass in NULL.
  • MessageTranslateOneToMany In addition to toText, MessageTranslateOneToMany also returns the number of output messages generated in successCount. Correctly formatted messages are saved in the string array toText. MessageTranslateOneToMany will return the number of successCount if the failureCount is 0. If the failureCount is greater than 0, the function will return an error reference number. Note that even if the function returned an error reference, some of the block may have been formatted correctly. The application should decide on the appropriate error handling strategy in this case.
  • the translation process may include the following three steps: 1. Parse the source message into an array of fields and an array of variables;
  • Both the source message format and the target message format have to be defined in the MFL meta-data, i.e., the messages that can be translated from and into are those whose formats are defined in the MFL meta-data.
  • SWIFT MT571 message can be a source or target message because MT571 format is defined in MFL meta-data.
  • a comma-delimited message format may be defined "(AccountID, SecuritylD, ValueDate, Quantity, Price, CrossCurrency)" in MFL meta-data, then a message in this format can be a source or a target message in a MFL translation function.
  • MFL translation functions support these translation capabilities: Structural field and variable mapping, e.g., from MT571 field 35H to field Quantity. Any field or variable defined in the source message format can be mapped to any field or variable defined in the target message format. One field in a source message can be translated into many fields in the target message and vice- versa.
  • Value transformation e.g., from "USD" in a MT571 field 33B to "1" for field CrossCurrency. Value transformation can make use of mapping tables provided by applications and stored in MFL database.
  • Target fields and variables can get different values based on contents, existence, or absence of source fields and variables. Default values can be stored in the target message(s) if it is not composed from the source message.
  • Operations that can be performed on numeric data include quality test, inequality tests, and range test.
  • Operations that can be performed on string data include variable-length sub-string extraction and comparison, acronym extraction and comparison, and word reordering. More sophisticated operations on numeric and string data can be performed by calling exit functions.
  • Translation rule definitions may be established as follows. Each mapping in a translation is defined as a translation rule in MFL metadata. A group of these rules constitute a full translation. Each group of translation rules is identified by a translation id. Translation rules are stored in the table MAS MATCH.
  • the MFL translation function does the following: validate that the source field or variable is a six-digit number; make the first two characters of the target field or variable "20" and then append whatever from the source field or variable at the end. This is actually a rule to translate a date with a two- digit year to the same date with the four-digit year.
  • the MFL may further include the following pre-loading functions: LoadMessage(); LoadMessageGroupO and LoadMatchO-
  • LoadMessage() may be as follows: int LoadMessage (
  • the LoadMessageGroupO specifications may be as follows: int LoadMessageGroup ( [in] int Aid)
  • the LoadMatch() specifications may be as follows: int MasMsgFormat (
  • LoadMessage(), LoadMessageGroupO, and LoadMatch() are used to pre-load message format information from database at application initialization phase. It avoids loading format information when processing message (load-on-demand). Preloading technique improves system run-time performance.
  • LoadMessage(), LoadMessageGroupO, and LoadMatch() are backward compatible. MFL functions can still load format information whenever necessary.
  • the first parameter, Aid specifies the application Id, and Msgld specifies the message id of the SWIFT message.
  • the Matchid is the ID in the MAS MATCH table.
  • the return error code can be used to call GetMFLErrors().
  • the MFL may include a GetMFLErrors() error functions.
  • the GetMFLErrors() specifications may be as follows: long GetMFLErrors (
  • the MFL further includes dynamic link library (DLL) functions such as the following:
  • DLL dynamic link library
  • FreeMFLStringO FreeMFL String Array ();
  • FreeMFLInt ArrayO Dlllmport long FreeMFL String ( char* str);
  • the FreeMFL String ArrayO specification may be as follows:
  • Dlllmport long FreeMFL String Array ( char** sarray, int count);
  • the FreeMFLIntArrayO specification may be as follows: Dlllmport long FreeMFLIntArray ( int* iarray, int count);
  • FreeMFLStringO frees a single string allocated by the DLL.
  • FreeMFLStringArrayO FreeMFLIntArrayO, respectively
  • freeMFLStringArrayO frees an array of strings (integers) allocated by the DLL (count is the number of elements of the array).
  • the MFL uses regular expressions extensively in meta-data definition, message parsing, formatting and translation. Preferably the regular expressions follow the following rules.
  • escape symbol ' ⁇ .' 'a' represents any character which can be used in a field, including alphanumeric characters and others, but cannot be any of these five characters: ⁇ n - : ⁇ ⁇ 0.
  • 'c' represents alphabetic characters, namely A-Z or a-z.
  • V represents new line.
  • Capital letters A, B, C, D, E, F, G, and H are used for standard SWIFT formats on these format options.
  • ⁇ code_table_name> means any value from the table
  • ⁇ code_table_name length> includes the length of the string when the string length is fixed.
  • '(',')' are used to group items into one item.
  • '[' » ']' group one or a number of items into an optional item.
  • Prefixing a number repeats the item by up to as many times. Prefixing a number then 'x' repeats the item on up to as many lines. '*,' instead of a number, represents arbitrary number. '+,' instead of a number, represents arbitrary positive number.
  • Suffixing a number means exact number. Suffixing 'x' then a number means exact as many lines. Do not apply number, '*' or '+' on optional sub-expression, 'r,' ⁇ o > or literal string to express repetition.
  • the following table provides examples of basic elements.
  • the regular expression uses capital letters A through H to represent standard SWIFT formats as listed in the following table.
  • Each regular expression has its value type.
  • the table below provides a list of legal value types. These value flags reflect to the rules somewhat.
  • RE "SO [SI
  • the tree built on this is shown in Figure 30.
  • the om_flag on the middle Or node is set to 'O,' which means optional.
  • the tree built on this expression is shown in Figure 31.
  • Any structured message can be represented in the MFL format database.
  • most formats are related to SWIFT I or II, or SWIFT messages wrapped by GRN envelope.
  • MFL format database which is referred to as meta-data, may include tables. In the embodiment described herein there are 21 tables in the MFL format database.
  • MAS SYSTEM is for database version information. The other 20 tables are described below. Information on supported versions:
  • Version number is assigned by MFL for different versions of SWIFT messages. It can be utilized for other purposes. For instance, different formats, such as CHIPS or
  • Version date is the official date when it is adopted as standard.
  • the effective date is the date when it is adopted in CrossMar applications. See the next section for a list of some message versions currently in the MFL format database.
  • Each message consists of an envelope and a message body.
  • " «BODY»” denotes the body of the message and everything else is the envelope of the message.
  • This table lists all variables defined in the envelope and body of each message version.
  • SWIFT messages For SWIFT messages, message numbers are the same as assigned by SWIFT. For example, the message number of SWIFT MT100 is 100.
  • enforce_order is 'Y, the fields in a message body have to be in their positions defined in MAS_GEN_FORMAT and MASJB GEN FORMAT (see below.
  • General message format :
  • Position is an index. It is useful for mutually exclusive fields: when two fields share one index, only one can be present.
  • Block means a collection of fields. When field block field is of value 'B,' the record represents a block. Repeat means that this field can repeat up to as many times (0 means arbitrary times).
  • Field id and format flag correspond to the tag number in SWIFT specifications.
  • Block number is assigned in sequence. It is preferably unique across board.
  • MAS_APP_FIELD message_number integer(4) field number integer(3), app id integer(3), format flag char(l), position integer, subfield exist char(l) value in ('Y,”N'), field_format char(128),
  • MAS_B_APP_ SUBFIELD block number int, field_number int, app id int, format_flag char(l), subfield_tag varchar(16), field format varchar(128),
  • mapping tables used in translation and matching A list of all mapping tables used in translation and matching:
  • the foregoing tables are utilized by the message format library in the translation, parsing, formatting, reconciliation and validating of messages.
  • the message format library may be incorporated with the architecture of the system of the present invention in different ways.
  • the message format library may be linked as a local function call to application programs utilizing the system.
  • the message format library may be linked as a remote function call be present on the message agent server.
  • the message format library of the present invention is a distinct and separate invention which is capable of operating independently of the message agent server described herein.

Abstract

The present invention facilitates handling of electronic messages between different computer networks and application programs by providing a message agent server system and a message format library system. The message agent server system (10) routes messages from application programs to external networks and external messaging systems. The message format library system includes message functions for formatting, translating, validating, reconciling, and/or parsing. In a financial services environment, the present invention facilitates communication of electronic messages by converting messages from a format used by a financial institution's network to the SWIFT (Society for Worldwide Interbank Financial Telecommunication) format.

Description

TRANSLATION OF MESSAGES TO AND FROM SECURE SWIFT FORMAT
Field of the Invention:
The present invention relates to systems and methods for facilitating electronic message transmission among different computer networks and application programs on the networks. The systems and methods are particularly advantageous for use in the transmission of electronic messages among financial institution networks and application programs and the Society for Worldwide Interbank Financial
Telecommunication (SWIFT) network .
Background:
The use of electronic messaging in the financial services industry continues to intensify. For example, due to evolution in the securities market, there is an ever increasing movement of funds into and out of international securities. This movement of funds is effected by electronic messages.
Systems exist that permit securities traders to communicate eletronically with each other. The Society for Worldwide Interbank Financial Telecommunications (SWIFT) has developed standards for electronic messages routed over their financial network. Messages which meet the SWIFT standards are referred to herein as SWIFT messages. The use of SWIFT messages enables financial institutions to receive and process messages in a reliable and efficient manner.
SWIFT messages are widely utilized in the international securities area as a form of communication between brokers, clearing agents, financial institutions and other security transaction participants. One advantageous method for trading securities is described in US patent application serial number 08/700,836, filed August 21, 1996, entitled Method and Apparatus for Trading Securities Electronically, the disclosure of which is hereby incorporated by reference. One embodiment of the methods described in this application includes the steps of: transmitting an order message from an originating broker workstation to a host computer in SWIFT format, the order message being directed to an executing broker to buy or sell securities; and then transmitting a SWIFT format confirmation message from the executing broker to confirm the transaction.
Although SWIFT messages are extensively utilized in international securities transactions, the SWIFT message format is not generally utilized for message traffic on financial institutions internal servers. In addition, many application programs, utilized in the financial services area, are not capable of generating SWIFT messages. Therefore it would be advantageous to have methods for translating messages which are not in SWIFT format to SWIFT format. It would also be advantageous to provide application programs with the capability of generating SWIFT format messages through the use of a local set of functions.
The need to interface with international networks such as the SWIFT network, and to send and receive electronic messages, such as SWIFT messages, to such networks may present additional problems for financial institution networks in the routing and handling of message traffic. Thus, it would be advantageous to have a system for the routing of messages which includes the capability to receive messages, store messages, queue messages, validate the format of messages and route messages.
The foregoing advantages are acheived by the systems and methods of the present invention.
Summary of the Invention:
The present invention provides systems and methods that facilitate the handling of electronic messages (also referred to herein simply as "messages") by different computer networks and application programs. The present invention is particularly advantageous for use in worldwide financial institution computer networks and for use with application programs which access those networks. In a financial services environment the systems and methods of the present invention may be utilized to facilitate the communication of electronic messages, which are entered in a first messaging format utilized by a financial institution's network, to and from the Society for Worldwide Interbank Financial Telecommunication network which requires a defined format, referred to herein as "SWIFT", which may differ from the messaging format utilized by the financial institution. In one aspect, the present invention provides a message exchange system. The message exchange system includes, as components, a message agent server; and a series of functions, collectively referred to herein as a "message format library", for applications which send and receive messages. The message agent server and message format library may be utilized together in an integrated system for the handling and transfer of electronic messages among discrete computer networks. The message agent server and the message format library may also be utilized independently.
The message agent server of the present invention may perform one or more of the following functions, routing messages, queuing messages; storing messages; receiving messages; logging messages; triggering applications which send and receive messages and validating the format of messages. Preferably the message agent server of the present invention will include all of the foregoing functions. In addition, the message agent server may include the message format library of the present invention. In this type of embodiment the message agent server may perform additional functions relating to the translation of messages.
An advantage of an embodiment of the message agent server of the present invention is that the message agent server may have the capabilities to receive, store, queue, validate and route messages. The message agent server of the present invention may be connected to applications and other servers through TCP/IP connections. The routing functions of the message agent server may be utilized to messages created by an application to other applications on the same network, or through an interface out to different networks such as the SWIFT network. The message agent server may also be utilized to receive incoming messages from different networks and route the incoming messages to an application program.
The message format library feature of the present invention includes message agents for translating messages from a first format to another format such as the SWIFT format. The message format library may be advantageously utilized to take data elements from an application program and create electronic messages for sending to another party. The message format library may also be advantageously utilized to parse incoming messages and recover data elements relevant to a particular application program.
The message agent server and message format library are utilized by application programs through local or remote function calls. In this regard, the message agent server is utilized by application programs to send and receive messages. The message format library may also be utilized by application programs, independently of the message agent server, to translate and manipulate messages received, and obtain data elements from the messages for processing within their own application's domain. As indicated above, the message format library may also be utilized by application programs to create electronic messages from data elements within the application program.
The services of the message agent server component of the present invention are performed without direct user involvement, although embodiments of the message agent server may include means for a network administrator to review message logs retained by the message agent server.
The services of the message format library component of the present invention may be accessed through a remote or local procedure call by an application program. The message format library may be accessed as part of a data entry system which includes a graphical user interface (GUI) for prompting input by the user of the application program.
The present invention also includes methods for the handling of messages utilizing the systems of the present invention.
The invention is described in the following sections with reference to particular types of messages which are utilized in conjuction with providing financial services. However, as will be understood by those of ordinary skill in the art, the concepts described herein apply to "message(s)" and/or "electronic message(s)" as used in a broad sense to comprise any type of message content; namely, the encapsulation of any data objects, including but not limited to: text, graphics, data, digitized voice or image, or the like; together with delivery, utilization and identification information that is needed to produce at the origin, and each final destination, those activities specified by the encapsulated content. In a preferred embodiment described below, the present invention is utilized in message oriented data transmission.
As used herein the terminology "application program" or "program" is utilized to describe a computer program for accomplishing or effecting a particular function or functions, the computer program comprising a detailed and explicit set of directions
(code) for accomplishing the function(s). For example, an application program could be written for accomplishing the global securities trading functions described above and in US patent application serial number 08/700,836 referred to above. Other examples of application programs utilized by financial institutions include programs for foreign exchange and money market trade confirmation matching for trades between corporations and their counterpart banks; programs for electronically distributing exchange rates; and portfolio management programs. In a broad context the systems and methods of the present invention are applicable to other application programs such as word processing programs, electronic mail programs, scheduling programs and the like.
In the detailed description of the invention reference is made to procedure calls and in particular to a remote procedure call (RPC) or a local procedure call (LPC). In many of the embodiments described below the system architecture is such that remote procedure calls (RPC's) are utilized by application programs and/or other system components. As will be understood by those of ordinary skill in the art, the present invention is not limited to the system architecture described in the embodiments below and in other forms of system architecture local procedure calls may be utilized. Other terms are also utilized in manners consistent with their usage by those of ordinary skill in the art. The systems and methods of the present invention are described in more detail below with reference to the following figures.
Brief Description of the Drawings:
Figure 1 is a block diagram illustrating a potential relationship among the message agent server, application programs, a gateway and the SWIFT network. Figure 2 depicts the message flow of a message originated by an application program for transmittal to the SWIFT network. The embodiment of the system of the present invention depicted in Figure 2 includes a message format library.
Figure 3 depicts the message flow of an incoming message, for example a message originated on the SWIFT network.
Figure 4 depicts an overview of the functional components of an embodiment of a message agent server of the present invention which is linked via communication links to application programs and to an interface to an external network.
Figure 5 depicts the layered architecture of a possible embodiment of a message format service.
Figure 6 is a schematic of an embodiment of an application interface for use between a message agent server and application programs.
Figure 7 illustrates the architectural design of an embodiment of a message queue for use in a message agent server of the present invention. Figure 8 depicts an embodiment of a message agent server architecture wherein the interface to a SWIFT network is provided by an X.25 interface.
Figure 9 depicts an embodiment of a state diagram for an outbound X.25 link server.
Figure 10 depicts an embodiment of a state diagram for an inbound X.25 link server.
Figure 11 depicts an alternative embodiment of a computing environment utilizing the system of the present invention.
Figure 12 depicts a data access model for a message agent server of the present invention. Figure 13 is a representation of a graphical user interface for a message agent server system administration utility provided by an administration function of the system of the present invention.
Figure 14 is a representation of a graphical user interface for monitoring provided by an administration function of the system of the present invention. Figure 15 is a representation of a graphical user interface for error display provided by an administration function of the system of the present invention. Figure 16 is a representation of a graphical user interface for event details provided by an administration function of the system of the present invention.
Figure 17 is a representation of a graphical user interface for message services provided by an administration function of the system of the present invention. Figure 18 is a representation of a graphical user interface for queued messages provided by an administration function of the system of the present invention.
Figure 19 is a representation of a graphical user interface for queued error messages provided by an administration function of the system of the present invention. Figure 20 is a representation of a graphical user interface for an event search provided by an administration function of the system of the present invention.
Figure 21 is a representation of a graphical user interface for message statistics provided by an administration function of the system of the present invention.
Figure 22 is a representation of a graphical user interface for delayed/failed message statistics provided by an administration function of the system of the present invention.
Figure 23 is a representation of a graphical user interface for advanced message statistics provided by an administration function of the system of the present invention. Figure 24 is a representation of a graphical user interface for FTS profiles provided by an administration function of the system of the present invention.
Figure 25 is a representation of a graphical user interface for inbound profiles provided by an administration function of the system of the present invention.
Figure 26 is a representation of a graphical user interface for inbound profile details provided by an administration function of the system of the present invention.
Figure 27 provides a graphic overview of an embodiment of a message format library of the present invention.
Figure 28 illustrates a tree built on a concatenation expression utilized in a message format library of the present invention. Figure 29 illustrates a tree built on a parentheses pair expression utilized in a message format library of the present invention. Figure 30 illustrates a tree built on an option pair expression utilized in a message format library of the present invention.
Figure 31 illustrates a tree built on a variable assignment expression utilized in a message format library of the present invention.
Detailed Description of the Invention:
As set forth above, the present invention includes a message agent server and a message format library which may be utilized in an integrated message exchange system for handling the exchange of messages among applications and computer networks.
According to the present invention a method for transferring electronic messages in a network, the network including a message agent server, a first terminal for communicating electronic messages in a first format, and a secure network, the secure network further connectable to at least a second terminal for communicating electronic messages in a secure network format, comprises: generating an electronic message at the first terminal in the first format; transmitting the electronic message from the first terminal to the message agent server; the message agent server automatically translating the electronic message from the first format to the secure network format; and transmitting the translated electronic message from the message agent server to the second terminal. The method may further comprise: generating a second electronic message at the second terminal in the secure network format; transmitting the electronic message from the second terminal via the secure network to the message agent server; the message agent server automatically translating the electronic message from the secure network format to the first format; and transmitting the translated second message from the message agent server to the first terminal.
The first terminal, second terminal and/or server may comprise a computer, for example a personal computer. The step of generating the electronic message at the first terminal in the first format may be performed using a software application such that the first format includes data formatted using the software application.
Examples of secure networks include financial networks wherein the secure network format, for example, is a SWIFT compatible format. The method may be advantageously utilized wherein the first message includes a plurality of first message elements and the translated electronic message includes a plurality of secure network message elements, and the message agent server automatically parsing the message, such that the plurality of message elements correspond to the plurality of secure network message elements. In addition the method may include validating the electronic message or translated electronic message.
In embodiments of the method the second terminal may be disconnectable from the secure network and and transmitting the translated electronic message may include connecting the second terminal to the secure network, the server automatically storing the translated message; the server automatically transmitting an alert message to the second terminal; and the second terminal retrieving the translated message.
In another aspect the present invention includes a method for transferring electronic messages between a first terminal, a message agent server and a first network comprising; generating an electronic message addressed to the first network on the first terminal; sending the message from the first terminal to the message agent server; interpreting the message so as to determine the address of the electronic message; and routing the message to the first network from the message agent server. The method may further comprise queuing the electronic message in the message agent server before it is routed to the first network. In addition, the step of routing may be delayed until the first network comes on-line such that the message will remain queued until the first network comes on-line.
The present invention also includes a system for transferring electronic messages in a network, the network including a message agent server, a first terminal for communicating electronic messages in a first format, and a secure network, the secure network further connectable to at least a second terminal for communicating electronic messages in a secure network format, the system comprising: means for generating an electronic message at the first terminal in the first format; means for transmitting the electronic message from the first terminal to the message agent server; means for automatically translating the electronic message from the first format to the secure network format; and means for transmitting the translated electronic message from the message agent server to the second terminal. In another aspect, the present invention includes a system for transferring messages comprising: a message agent server comprised of: at least one queue; a processor which is used to at least determine the destination address of one of the messages and a plurality of communications links used to carry the messages; a first terminal; a first network coupling the first terminal to a first subplurality of communications links; and a second network coupled to a second subplurality of communications links. The first terminal, may be a server and may hold one of a plurality of application programs, for example a securities exchange program. The second network may be a world-wide network used to transfer financial messages. The queue may be used to store and transfer messages in a particular order destined for the first terminal and/or for the second network. Message transfer may be controlled for example by an MQ application.
In another aspect the present invention provides a message agent server used for transferring messages between a first terminal and a network the message agent server comprising: communications links coupling the message agent server to the first terminal and the network; a processor; a buffer for temporarily holding a message received via the communications links; wherein the processor operates under the control of an interpreting procedure so the processor determines the destination address of the message while the message is in the buffer; a first queue associated with the first terminal; a second queue associated with the network; where the message is transferred from the buffer to the appropriate queue based on the determination made by the processor under the control of the interpreting procedure.
In a further aspect the present invention provides a system comprising a message agent server coupled to a first network, the network including a first terminal, and coupled to a second network where the second network includes at least one terminal where the system is further comprised of: communications links coupling the message agent server to the first network and coupling the message agent server to the second network; where the message agent server is further comprised of a processor; message receiving means for receiving messages transmitted to the message agent server from the first and second networks via the communications links; means for interpreting the received messages which includes reading the address of the destination of the message; queuing means for storing the received messages and for forwarding the messages to the communications links when told to do so; routing means for routing the messages to the appropriate destination based upon the determination of the means for interpreting. The means for interpreting the message may include means for validating the message format and/or means for translating the message from a message format to a second message format, for example using a message format library. The queuing means may comprise a database and may include at least one of the message archive, retrieval, and retransmission capabilities. The system of claim may further include means for monitoring message traffic and message agent server performance by an administrator.
In a further aspect, the present invention provides a method for transferring electronic messages among a plurality of participants wherein the participants include a first terminal and a first network and the method uses a message agent server where the method comprises: preparing an electronic message on the first terminal addressed to the first network; sending the message to the message agent server; interpreting the message to determine at least the message addressee; storing the message in a message queue assigned to the message addressee; triggering the first network to connect to the message agent server; and routing the message to the remote network after the remote network connects to the message agent server. The step of interpreting the message may include validating the format of the message. In addition the method may further include monitoring message traffic.
In another aspect, according to the present invention, a message agent server for communication of messages among a plurality of participants in a computing environment, the participants including the message agent server; a remote application residing on a first computer; and a remote network residing on a second computer, the participants being connectable by a physical network the message agent server comprising: a communications device for establishing a communications link; a processor, coupled to the communications device; memory; message receiving means for receiving incoming messages; means for interpreting the messages; queuing means for queuing and storing received messages; and routing means for routing the message to the message addressee. The means for interpreting the messages comprises means for determining the addressee of the message. In a preferred embodiment of the message agent server of the present invention the means for interpreting the messages includes means for validating the message format, for example utilizing the message format library. The queuing means preferably comprises a database for queuing and storing messages. In a preferred embodiment the message agent server further comprises means for monitoring message traffic and message agent server performance by an administrator. The monitoring means may also use the database utilized by the queuing means.
The message agent server may additionally include a failover of the message agent server components so that a failure in part of the message agent server does not prevent other portions of the message agent server from running. The failover provision may preferably include a provision for redundant communication links to application programs or the network; redundant processors (CPUs) and redundant processes for receiving, queuing, routing, validating and other handling of messages. A message format utility which is used to maintain the various message formats and other meta data with a graphical user interface (GUI). The message agent server may further include a message archive, retrieval, and re-transmission capability.
The message agent server may be constructed utilizing conventional computer hardware. Suitable processor hardware includes an Intel Pentium Pro processor or its equivalent. The computer operating system may be Microsoft NT or its equivalent. As will be understood by those of ordinary skill in the art, the message agent server of the present invention may take advantage of increased processor speed and more robust operating systems as each becomes available in the future. The computing environment which includes the message agent server may comprise discrete computing platforms linked through TCP/IP connections. In this type of environment the communication devices may comprise modems or the equivalent. The message agent server may also be utilized as an integral part of a local area or wide area network to handle message traffic among nodes on the network. In a further aspect, according to the present invention, a method for transferring electronic messages among a plurality of participants in a computing environment, the participants including a message agent server; a remote application residing on a first computer; and a remote network residing on a second computer comprises: preparing an electronic message in the remote application on a first computer, the message being addressed to the remote network residing on the second computer; sending the message to the message agent server; interpreting the message to determine at least the message addressee; storing the message in a message queue assigned to the message addressee; triggering the remote network to connect to the message agent server; and routing the message to the remote network after the remote network connects to the message agent server. Preferably interpreting the message further comprises validating the format of the message, for example utilizing the message format library. In a preferred embodiment the method of the present invention further comprises: monitoring message traffic on the message agent server.
The methods of the present invention may be performed on conventional computer hardware such as the hardware discussed above.
Further details regarding the message agent server and methods for transferring electronic messages of the present invention are set forth below in the discussion of the appended Figures.
Figure 1 provides an overview of a computing environment which includes the message agent server of the present invention. As shown in Figure 1, a computing environment 2, may include a message agent server 10, having communication links 20, to application programs 12, 14 and 16. Communication links 20 may be direct network links, for example through an ethernet link, or dial-up links, using telecommunication links. The communication links are preferably TCP/IP links.
Application programs 12, 14 and 16 may be the same or different and may reside on a single computer or a plurality of computers. The application programs will generally be message based, i.e. utilized for generating electronic messages for a particular purpose, although the present invention may be utilized with other types of application programs. An example of an application program utilized in the financial services industry is the Global Clear program for the routing of orders and the confirmation of cross-border security trading, described above and in US patent application serial number 08/700,836. Other application programs utilized by the financial services industry include: programs for providing an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties; programs for matching confirmations of foreign exchange and money market trades between corporate customers and bank traders; programs for monitoring and controlling the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products; and programs for handling payment orders. Details of these application programs are set forth below.
As discussed above, the message agent server provides messaging and queuing capabilities for application programs. The message agent server is particularly advantageous for use with application programs that send and receive SWIFT messages. The application programs include programs utilized by the financial services industry such as the following: programs for providing an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties, referred to herein as FX Options Confirmation Matching; programs for matching confirmations of foreign exchange and money market trades between corporate customers and bank traders, referred to herein as FX Match; programs for monitoring and controlling the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products referred to herein as CCMP; programs for cross border routing and confirmation matching, referred to herein as Global Clear, and programs for handling payment orders. Further details relating to these application programs and the types of messages sent and received by each are set forth in the following paragraphs. Following the application program descriptions is a description of another embodiment of a system of the present invention described with reference to these particular application programs. The FX Options Confirmation Matching application will provide an electronic mechanism for matching confirmations for FX options trades between corporations/fund managers and their bank counter-parties. In an embodiment of the service, banks will transmit FX options confirmations (MT305 message format) to a message agent server over the SWIFT network, sometime after trading with a corporation using existing trading methods. The message agent server will safely queue the message, perform basic validation of the SWIFT format and header contents and return a positive or negative acknowledgment to the interface with the SWIFT network. Meanwhile, the FX Options system application program will have "subscribed to receive" messages addressed to it from message agent server when they are received from the SWIFT network. For each MT305 message it receives from message agent server, the FX Options system application program will invoke the message parsing service of message agent server, or the message format library, to break the message into its constituent fields, and store them in its database. The FX Options system application program will transmit the MT305 messages to the appropriate users, who will be provided with a graphical user interface (GUI) application which will be used to view and "affirm" the MT305 messages, as well print basic reports of the status of FX options confirmations and affirmation activities.
Upon affirming the confirmations, the GUI application transmits them to the FX Options system application program, where they are stored in the database and sent to message agent server for delivery to the counter-party banks. Bank users will also be provided with a GUI application to view the status of FX options confirmations and print basic reports of the status of FX options confirmations and affirmation activities.
GlobalClear is a product for the routing of orders and the confirmation of cross-border security trading and is described in detail in US patent application serial number 08/700,836. referred to above. Messages of SWIFT MT500 series are sent to a GlobalClear server through GlobalClear application program client software direct link, file transfer and a SWIFT NETWORK INTERFACE. The messages are delivered through the same channels. The following SWIFT messages are handled: MT502; MT513; MT514; MT515; MT517; MT518; MT52x; and MT53x.
FX-Match matches confirmations of foreign exchange and money market trades between corporate customers and bank traders. It also enables on-line confirmation, monitoring of transaction status, storing historical information and provision of various reports. Co orate customers enter information through a dial-up terminal or upload a file of FX and money market trade confirmations. Banks send information to FX-Match through the SWIFT NETWORK INTERFACE and file transfer. The file transfer may be performed using DECNET when originated internally from CITIBANK, and KERMIT and other similar terminal protocols are used by external clients.
The message flow in FX-Match is simple and straightforward. Banks and corporate clients send MT300 and MT32x messages into FX-Match. FX Match matches them and sends confirmation messages. Corporate clients can also match the trades through direct online access to a terminal. Accepting a trade by a corporate client causes a confirmation message to be sent to the counter-party bank via a SWIFT
NETWORK INTERFACE. Banks may send trade cancellation confirmations by sending a cancel message through a SWIFT NETWORK INTERFACE. Corporate clients report canceled trades online, causing FX-Match to send a trade cancellation confirmation message to the counter-party bank through a SWIFT NETWORK INTERFACE.
A cancel message for a MT300 message is a MT300 with field 22 containing the value "CANCEL". The same is true for cancellations of money market trades confirmations, e.g., MT32x. Banks currently send three types of messages: MT300; MT320 and MT324. Other types of messages may also be utilized including: MT301 ; MT304; MT305.
CCMP is a platform which allows various bank businesses to monitor and control the valuation of collateral assets pledged by clients to secure transactions which include multiple traded and non-traded products. Product Processors send files daily containing all liability transactions to CCMP. CCMP nets the impact of the transactions on each participant's collateral after being marked to market. CCMP then reports on these results to collateral monitoring units, customers, and risk and custody systems. In the case of a margin call, the customer can either initiate a message through a bank's internal network to SECORE (Global Custody System) or via SWIFT. A copy of the message is sent to CCMP when SECORE receives it. After processing the collateral for acceptability, SECORE sends to CCMP a nightly position report of participants for reconciliation purposes. CCMP handles the following SWIFT messages: MT520; MT521; MT522; MT523; MT530; MT531; MT532; MT533; MT592; MT100; MT900; and MT910. Other application programs may utilize ISITC (Industry Standardization for Institutional Trade Communication)and FIX (Financial Information/Institution Exchange) message formats as well as the foregoing SWIFT message formats.
In the embodiment depicted in Figure 1 message agent server 10 is linked through communication links 20 to the SWIFT network 30. In other embodiments of the present invention, described in detail below, message agent server is linked through communication links to a gateway which in turn is linked to the SWIFT network and/or other networks.
In one possible use of the embodiment depicted in Figure 1 an electronic message is generated by an application program for transmission to the SWIFT network. The message is transferred via communication links to the message agent server. The message format allows the message agent server to identify the message as a SWIFT message and the message agent server stores the message in a SWIFT queue for transmission to the SWIFT network. After generation of a communication link to the SWIFT network the message is transferred to the SWIFT network. The generation of the communication link may be facilitated by the message agent server triggering the generation of the link. Figure 2 depicts the flow of an outgoing message generated by an application program in an embodiment of the present invention. As shown in Figure 2, when an application program 12 sends an outgoing message for delivery to the SWIFT network it first prepares all the necessary variables and fields in a data entry step at a workstation 42. The data is converted in a remote or local message formatting procedure, 44 to form a SWIFT message. Preferably the message format library of the present invention is utilized in the formatting. The message is then passed to message agent server 10, through a communication link. Preferably the message agent server program is constantly listening for application programs on a communications link. Upon receipt of the message, the message format is validated, 46 and then the message is passed to a message queue 48. An interface program, 50 fetches the message from the queue and sends it through a communication link to the SWIFT network 30. As noted above, the interface function may be incorporated within the message agent server. Alternatively, as shown in Figure 2, the interface may be separate from the message agent server and be reachable by the message agent server through a communications link. For example, the interface may form part of another computer network which is linked to the SWIFT network.
Figure 3 depicts the flow of an incoming message, for example a message from the SWIFT network according to an embodiment of the present invention. An incoming message from the SWIFT network, 30 is first received by interface 50, which may be incorporated within, or separate from, the message agent server. The message flows through the interface to the message agent server 10. The message is validated 46 and then passed to a queue 48 for delivery to an application. An application program 12 fetches the message from the queue via a communications link. The application issues a block reading for messages destined for it through a remote procedure call interface. The remote procedure either returns a message immediately or block-wait for the next arriving message. The message is then parsed and translated 44 from the SWIFT format for display in the application format. The translation may be accomplished by the message format library of the present invention. After translation, the message data is displayed at a workstation 42 for reading by a user. In alternative embodiments of the present invention the message translation may occur at the message agent server before the message is passed to the application program.
Messages may also be passed by the message agent server between and among different application programs.
In the embodiments shown in Figures 2 and 3, the system comprises two tiers. The first is the application program which takes user input and may reside on a client workstation. The second tier is the message agent server which controls and manages the data and business logic.
Embodiments of the message agent server of the present invention may perform a variety of services including one or more of the following services. The message agent server may provide a link to the SWIFT network, permitting application programs to receive/send SWIFT formatted messages. The message agent server may provide transactional integrity of messages received by application programs for transmission to a SWIFT NETWORK INTERFACE and for messages received from the SWIFT NETWORK INTERFACE bound for application programs.
An application program may use the message format library for formatting a collection of fields into SWIFT formatted messages.
The message agent server may validate SWIFT messages upon receipt from, and prior to transmission to, the SWIFT network.
The message agent server may provide SWIFT meta data for use by application programs to apply more meaningful names to SWIFT message data fields. This service may be used by an application program's graphical user interface for presenting the contents of a SWIFT message on a screen, using common language for the screen's field labels, e.g., "Transaction Reference Number" instead of the SWIFT field label, ":20:"
The message agent server may include failover of the message agent server components so that a failure in part of message agent server does not stop all of message agent server from running. This includes provision for redundant links to the SWIFT NETWORK INTERFACE, redundant processors (CPUs) and processes. The processes include the MQ-Network interface, MQ Series Engine and queues and the application-MQ interface RPC Server). The message agent server may include a system administration utility which is used to administer and monitor the processes and message queues.
The message agent server and/or message format library may include a message format utility which is used to maintain the various message formats and other meta data with a graphical user interface (GUI). The message agent server may include a message archive, retrieval, and retransmission capability.
To support on-line/off-line use of the message agent server format libraries, the message agent server database on the client application program (PC) and the server may be synchronized at certain intervals. The message agent server may support the SWIFT 97 message format.
The message agent server may include a set of functions as remote procedure calls that application programs, for example the GlobalClear application program, may invoke to perform matching operations. These matching operations may include: matching one or more fields of messages of the same type, for example as with MT300; and/or matching one or more fields of messages of different types, for example as with GlobalClear's MT502 (order) and MT518 (execution). The message agent server may include a set of functions as remote procedure calls for performing reconcilitaion operations.
Further message translation capabilities may also be included as part of the message agent server and/or message format library to translate a SWIFT message into another industry protocol message format. Conceptually the message agent server may be utilized to handle file transmission and telex or fax transmissions.
The foregoing description and Figures 1 , 2 and 3 are meant to provide a general overview of the role of the message agent server in a computing environment. The following paragraphs and Figures 4-12 provide a more detailed description of the features of the message agent server of the present invention.
Figure 4 depicts an overview of the functional components of an embodiment of a message agent server 10 of the present invention which is linked via communication links to application programs 12, 14 and 16 and to an interface 50 to an external network. As shown in Figure 4, a message agent server may include the following components.
A MQ (message queue)- Application Interface 100 which provides the interface between the persistent message queues 110 and the applications. In the embodiment depicted in Figure 4 the message agent server does not allow application programs 12, 14 and 16 to access the queues directly. The MQ- Application Interface serves as the broker between application programs and the message agent server message queues.
The MQ Application Interface allows application programs 12, 14 and 16 to send and receive messages using remote procedure calls. The application program interface between the application programs and the message agent server is described in detail with reference to Figure 5 and in general in the following paragraphs.
Suitable technologies for implementing the remote procedure calls include the Entera TCP RPC (remote procedure call) middleware which runs on a Windows NT Server platform. The message agent server may also provide its services to older legacy applications running on VAX/VMS using either Entera DCE or TCP RPC, or a socket based message passing API and middle-ware.
The remote procedure call, for example the Entera RPC, may be used as the standard interface between the message agent server and application programs. The message agent server provides services as RPC calls in application programs such as, send-message and get-message that are implemented as RPC's by the message agent server. The MQ -Application Interface provides a non-polling mechanism to notify application programs of the receipt of messages after an application is on-line. At application startup time, the application program may ask to receive all messages being held on its queue(s). Individual application programs will implement this capability in the manner best suited for their particular function. Authentication may be utilized between the application programs and message agent server. When the application program signs up to use a queue everyday, an authentication & security scheme may pass a security ticket to be used implicitly in subsequent RPC calls.
Application programs may be designed and implemented with many different remote procedure calls (RPC's) for accessing the message agent server. Preferably, the following remote procedure calls are provided.
Send Message: When an application program has a message to send out (e.g., to SWIFT) this RPC is called so that the MQ - Application Interface can safely queue the message for transmission to the target process.
Get Message: At startup and when it receives notifications from the MQ -
Application Interface, the application program receives a message by calling this RPC.
Get Message Status: An application program may inquire as to the status of a message to determine for example, if an outbound message has been sent and received by its target process. Re-Queue Message: The message agent server Monitor and Administration application, discussed below, will allow an operator to move messages from an error state to a queue to be transmitted, after an investigation and/or repair of the message.
Message Queues & Message Address Resolution: The message queues will comprise a queue for each application program: inbound messages. In addition there will be one generalized queue for inbound and outbound problem messages. Additional queues may be defined per client (such as for priority queues) and for general use.
The means by which message agent server determines which queues to place messages may be based on:
Application ID: Applications which use the message queues include the application programs and the interface application. Additional applications may be added and may be connected to the message agent server and use additional message queues. In addition, program applications may be able to send and receive messages with each other using the message agent server. Each application will have an Application ID, which is stored in a message agent server database. It is the responsibility of the application, not the MQ Application
Interface, to provide information in the message to indicate its identity. A message agent server Translation Service API/RPC, using the message format library, will be provided to determine an application ID from the message and map it to a queue name.
Priority: Although the initial implementation of message agent server will process messages of equal priority, the message agent server may include a facility for an application to assign priorities to messages, e.g., high, medium, low and urgent.
Guaranteed Message Delivery: The message queuing system is configured such that messages handed to it by applications are not lost by the message agent server. Once a message is handed to it by an application program, the message agent server may guarantee that the message is safely stored and that the message, once transmitted to its target, is guaranteed to have been transmitted and received. This means that messages should not be de-queued until acknowledgment of receipt has been made.
Asynchronous Message Delivery: Messages received by the message agent server for target application programs which are not on-line at the time of receipt are safely queued for delivery when the application program comes on-line.
Message Logging: All activities of queuing, de-queuing and requeuing, receipt and transmission of messages are logged in the message agent server in a database. The log may contain the following information:
DateTime of activity (YYYYMMDD-HH:MM:SS:CC) Activity
Application ID of Sender Application ID of Target
Message Contents. Referring to Figure 4 the message agent server 10 further includes MQ (message queue) - Network Interface 120. The MQ - Network Interface is the component which provides the interface between the persistent message queues and interface 50 to an external network such as the SWIFT network. The MQ - Network
Interface will be configured to support the network and communications protocol utilized by interface 50. The MQ - Network Interface also implements the queue processing of messages to be transmitted to SWIFT NETWORK INTERFACE , referred to as outbound messages, and those messages transmitted from SWIFT NETWORK INTERFACE to CrossMar client applications, referred to as inbound messages. Message agent server 10 also includes Message Queuing System 130, for handling delivery of messages to and from the message queues 110. The message queuing system will interface with the MQ-Application Interface 100 and the MQ- Network Interface 120 and transfer messages back and forth from the message queues to these interfaces. The message queuing system may also interact with a message agent server monitor and administration system 140.
The message queuing system may utilize existing commercially available computer software to perform its functions. A preferred product for use as the message queuing system is the IBM MQSeries product. The MQ Series is a standard for message-oriented middleware, and the product is supported on a variety of platforms including VAX/VMS, Windows NT and HP-UX.
Also shown in Figure 4 is a message format library 140 which comprises a meta-data service 142; format service 144; parser service 146; and translation service 148. The message format library and the services it provides are described in detail in a following section, and covered generally in the next several paragraphs.
A basis for message handling as described above is the knowledge of message format. Knowledge of the message format is also relevant to message format validation. Therefore, the message agent server preferably includes access to message formatting services and information. The information on format may be extended to provide metadata service to application programs as a remote procedure call (RPC) or local procedure call through an application programming interface (API).
The meta-data, shown as 149 in Figure 4, may comprise a number of parts including the following: representation of SWIFT message formats; code tables for certain fields, e.g., currency and country code, valid BIC id, etc. and application specific interface captions on fields. Using this information a graphical user interface (GUI) for application programs can be designed so that its appearance can be controlled dynamically from a centralized meta-data database.
For each message, the following information is maintained: mandatory and optional fields; ordering and repeating of fields; and field format. Application program specific requirements of formatted messages may also be supported in the meta-data database. This includes, but is not limited to the following aspects: a generally optional field can be mandatory optional or absent (not present in interface) for a specific application; a caption used on a GUI interface for each message, block and field; a code table used for the field values; client GUI display preference for each field such as radio box, jumbo box, or list box; and read only protection.
Application programs 12, 14 and 16 may include features and characteristics which differ. To anticipate uneven formats and uneven format migration in the future, the message agent server provides format conversion, through message format service
144 so that the message agent server can continue the service even when data source, such as the application program and the data consumer, such as the SWIFT network, do not migrate formats at exactly the same time.
The message agent server parses messages, using parser service 146, into array of tagged fields and may be designed to pass messages to and from applications in the following format: typedef struct { small tag; ptr, string] char *field_value; } Mas field; typedef Mas_field Mas_message[]. As the industry trend is to have messages of various sources standardized to follow SWIFT messages, it is practical for message agent server to provide a message as a collection of fields labeled according to SWIFT labels. Preferably the message agent server supports the existing byte string message passing in the applications. The message agent server may also include a message translation service 148. The translation service may be designed utilizing the procedures described below with reference to the message format library.
As set forth above, the message agent server may include a database to store message format information. Message format may be represented in generic relational database format. It may be implemented in SYBASE and or other relational databases. The format service design can be ported to any relational database easily. The layered architecture of a possible embodiment is illustrated in Figure 5.
The embodiment depicted in Figure 5 includes application program 12, which is a client on network with the network server referred to as application program server 15. Application program 12 accesses application program server 15 through a remote procedure call. Similarly, application program server 15 accesses the message agent server 30 through a remote procedure call.
Message agent server remote procedure calls (RPC's) may provide message parsing and formatting services to application programs linked to the message agent server. Application programs may also copy the message agent server format functionality to a local database 19, for example a Microsoft Access database. In this way, application programs may call local functions (through local procedure calls (LPC's) to parse and format messages when off-line. These local functions may be implemented in a dynamic link library provided to the application programs linked to the message agent server.
The message agent server format service may access the format representation in the SYBASE database 35 through an RPC scheme set up by Entera or the representation in Microsoft Access database. The Microsoft Access database may be synchronized to the SYBASE database manually.
Messages in each message type have the same header format, field structure and field format. A group of message types sharing the same header format and code tables form a message application version. The messages may be identified by their application version id, which is an integer, and their message id, which is an integer too.
By way of example, the format representation may comprise as many as 17 tables as follows. Table: MAS MSG ERSIONS
Table MAS_MSG_VERSIONS records the related dates of a message version and the overall format of messages in a version. SWIFT 1, SWIFT 1 1, SWIFT 96 are version examples. Table: MAS_MSG_VARIABLES
This table lists all variables and names them.
Table: MAS_MESSAGES; MAS_GEN_BLOCK
Table MAS_MESSAGES contains a list of all messages for each version. MT 100, MT300, etc., are messages, Table MAS GEN BLOCK lists all the blocks. Table: MAS_GEN_FORMAT; MAS_B_GEN_FORMAT
Table MAS_GEN_FORMAT and MAS_B_GEN_FORMAT contain a list of all fields for each message and other general attributes specified i message format standard documents.
The notion block is used to denote any set of consecutive fields. This is for the purpose of handling repeating and optional sequence. MAS B GEN FORMAT is for fields in blocks.
Every application is assigned one or more application Ids (Aid's). All the following tables are for application specific format, hence contain the application ID as part of the reference keys. Table: MAS _APPLICATION
This table contains all the applications and map application id to message version.
Table: MAS_MESSAGE_TITLE; MAS_BLOCK_TITLE
Table MAS_MESSAGE_TITLE contains a list of messages for each application ID. Table MAS_BLOCK_TITLE gives every block a title.
Table: MAS_APP_FIELD; MAS B APP FIELD
Table MAS_APP_FIELD and MAS_B_APP_FIELD contain application specific information on fields. It also contains field format. We place field format in application specific data because different application might use different code tables while code table reference is specified in field formats
Table: MAS CODE TABLES Instead of setting up multiple code tables, one table may be utilized to implement all code tables for the ease of implementation.
The following four tables implement cross-field constraints i messages.
Table: MASJRULE CLAUSE This table implement propositions on individual fields. The following operators are used
E: Exists, A: Absent,
M: Matches an expression, X: Number within error,
0: Number bigger in a range, C: Number smaller in a range.
Table: MAS_RULE_COMBINE This table combines basic clauses with logical operators into composite clauses. A large set of logical operators may be utilized so as to save the number of intermediate composite clauses. The following operators are used:
A: And,
B: Both true or both false, C: Left false and right true,
D: Both false, M: Exclusive or, N: Negation.
Table: MAS_RULE Table MAS-RULE contains all the cross-field rules.
A table may also be utilized to represent the matching relationship useful in security trade confirmation.
Table: MAS_MATCH_TITLE A list of individual sets of match rules. Table: MAS MATCH
Table MAS_MATCH contains the rules about which fields in one message should be matched to which fields in another message. Translation rules are represented in this table.
As explained in more detail below with reference to the message format library, in an embodiment of the present invention the format expression for messages is based on the regular expression of Norm Chomsky. A convention, similar to the convention utilized by the UNIX operating system and other operating systems may be utilized wherein: any literal character is prefixed with escape symbol 'V; 'a' represents any character which can be used in a field;
'c' represents alphabetic characters;
'n' represents any digit or;
'd' represents any digit;
V represents new line; Capital letters A, B, C, D, E, F, G and H are used for standard SWIFT formats on these format options;
<code_table_name> means any value from the table, <code_table_name length> includes the length of the string when the string length is fixed; '(',')'are used to group items into one item;
'[',']' group one or a number of items into an optional item;
prefixing a number repeats the item by up to as many times; prefixing a number then 'x' repeats the item on up to as many lines; ' * ' , instead of a number, represents arbitrary number;
'+', instead of a number, represents arbitrary positive number; postfixing a number means exact number; postfixing 'x' then a number means exact as many lines; and number,'* 'or '+'on optional sub-expression, 'r' <o>or literal string is not applied to express repetition.
Referring again to Figure 4, the message agent server 10 may also include a Message Agent Server (MAS) monitor and administration process 150 which includes a user interface. The administrative functions performed by the MAS Monitor and Administration Process include: Starting and stopping the MQ - Application
Setup and management of queues; monitoring of communication links; examining the status of queues; the quering and summarizing of messages according to criteria entered interactively; management of user accounts and access rights; examination of individual messages; examination of service quality statistics such as maximum and average queue lengths, delays or exceptions counts; operator intervention for exception handling; and configuration tasks. The MAS Monitor and Administration Process will preferably interact with a MAS
Activity and Log Tables database 160. This database will include and store details relating to the services being performed by the message agent server. Further details regarding the administration process and user interface, and the database 160 are set forth below with reference to Figures . Figure 6 is a schematic of an embodiment of an application interface for use between the message agent server and the application programs. As shown in Figure 6, an application program 12 may interface with a message agent server 10 through a remote procedure call (RPC).
The primary interface the message agent server provides for the application programs may be based on RPC of DCE [] style. An RPC server framework with RPC stubs may be prepared with the stubs programmed in the framework to perform the functions advertised for the RPCs. These functions are covered above. The RPC server is constantly running to answer RPC calls. A thread is spawned for every RPC call. Working in the DCE/RPC paradigm, data elements are passed to and from MAS as arrays of strings.
The application interface interacts with the message queing system 130 through client function calls and semaphores. The application interface interacts with a message agent server format library 120, through library function calls. The message agent server format library 120 may interact with a message format library database 162 to retrieve informatin relating to message formats. Preferably the message agent server handles all all RPC calls synchronously. Asynchronous processing in the application programs may be achieved by spawning threads in the applications.
The following functions are provided by the message agent server application interface:
MasParseData,
MasFormatData,
MasSendMsg,
MasReceiveMsg, SentMsgStatus,
RecentMsgStatus,
MasGetErrors. Whenever a message agent server RPC function succeeds, it returns a positive value. Otherwise, it returns a negative value which is the reference number for the errors encountered in the call. The application can call the MasGetErrors furnction to retrieve all the errors as another array of character strings.
The message agent server format functions MasParseData and MasFormatData are also provided as dynamic link library (DLL) functions together with the MasGetErrors function. The message agent server format functions may include necessary functions for passing SWIFT or other types of messages. Each application program identifies itself with one or more application identifiers (Aid) each of which corresponds to a unique header format and a set of messages in specific field format.
The message agent server format functions are described below. Similar functions are also described in detail below with reference to the message format library.
The MasParseData function is utilized to parse a message. A typical format for the function is as follows:
MasParseData Format: long MasParseData ( [in] char Aid[],
[in] char MessageText[],
[out] char Msgld[],
[out] char From.Bic[],
[out] char ToBic[], [out] char GenTime[], [out] char RecvTimef],
[out] char Priority [],
[out] char MURfJ,
[out] char FieldNumber[][],
[out] char FormatTag[][],
[out] char FieldCaption[][],
[out] char FieldContent[][])
Remote and Local
This routine takes a formatted SWIFT message as input, and breaks it apart into the header fields, and other fields tags and values. It returns an error status if it is unable to parse the data correctly.
This routine is passed the Application Id in Aid, and a formatted swift message in MessageText. It pulls apart the message and breaks each of the header fields into Magld, FromBic, ToBic, GenTime, RecvTime, Priority,, and MUR. The fields are loaded into arrays FieldNumber, FormatTag, and FieldContent, with the number of fields placed into NumFields. An empty string in an output variable indicates that this optional variable is missing.
The Application Id is used to identify the format version. First the version format is loaded if it is not already in the memory. The function passes the header to get the message id and use it to locate, or load when not already in memory, the message body format. When a failure occurs, it will attempt to look for the next good field and resume parsing while registering an error. The MasFormatData routine may be used as a local procedure call by an application program to validate and construct a SWIFT message. Message construction is done either by the client or the message is received over the SWIFT network. Formatting checks are preferably performed at the message agent server.. The function checks for mandatory fields, and verifies the values of all of the fields, including size. If an error is detected in parsing, the return value of the function is the Error Reference number that can be used to find the text errors corresponding to this message with a call to
MasGetErrors.
A typical format for the function is as follows: long MasFormatData
[in] char Aid[], [in] char Msgld[],
[in] char FromBic [],
[in] char ToBicβ, [in] char priority[],
[in] char MURΓJ
[in] char NumFields,
[in] char FieldNumberf] [NumFields],
[in] char FormatTag[] [NumFields],
[in] char FieldContent[] [NumFields],
[out] char MessageText J)
Remote and Local
The first parameter, Aid specifies the application Id that is requesting the function.
The routine takes input parameters of all of the fields that comprise the SWIFT header (Parameters 2 to 6). The three arrays of string are the specific fields of the swift message. FieldNumber and FormatTag together form the field tag (i.e., 7 1 a). The corresponding array position in FieldContent is the value of that field. MessageText is the returned formatted Swift message including header, trailer and fields. NumFields contains the number of fields that passed into the routine. An empty string in input header variables indicates the optional variable is absent.
Although field order is significant for SWIFT, message agent server may be constructed to perform limited field sorting and thereby sort fields not in repeatable blocks, rather fields can be passed in random order except that the fields in repeatable blocks have to follow their order in their correspondent blocks.
The Appld and Msgld are used to identify the format version and body format which is loaded if it is not already in the memory. The variables are used to form the header and the fields to form the body. When a failure occurs, it will attempt to look for the next good field and resume formatting while registering an error.
The message agent server transmission functions are described in the following paragraphs.
The MasSendMsg routine will take a SWIFT message passed into it, and send the mesage out to the SWIFT network. It is passed in as a dynamically allocated string in Message. Appld is a constant pertaining to the application that is sending the messages.
A typical format for the function is as follows: long MasSendMsg (
[in] char Message[], [in] char Appld[],
[out] char MURfJ) Remote Only Each SWIFT message may be given a unique (across all products) message identifier for transmission over the network. This identifier is returned in the variable MUR.
The format of MUR is "yyyymmddXXXnnnnn" where: yyyy is the year, and mm is the month, and dd is the date, and
XXX is the application code (FXM, FXO, FXS, FXL, etc.), and nnnnn is the sequence number.
Another RPC function SentMsgStatus can be called with the parameter MUR to check the status of a sent message.
The Appld can potentially trigger a translation before the message is queued.
The MasSendMsg funtion calls MQPUT to place the message on a designated outgoing queue. It also puts the MUR and the status of a message in the status queue for all outgoing messages (QL_OUT_STATUS). It returns successfully after all the actions finish successfully.
The MasReceiveMsg function is utilized by application programs to request a message addressed to the receiver identified by the Appld (Aid). It returns the first message in corresponding queue or the first to arrive in Message, i.e., the messaging mechanism is synchronous. The applications use other means to achieve asynchronous messaging.
A typical format for the function is as follows: long MasReceiveMsg ( [in] char AppIdQ,
[out] char Message[]) Remote Only.
The MasReciveMsg function first attempts to decrement a semaphore guarding the corresponding receiving queue. After it passes the semaphore, it uses MQGET to retrieve the message and pass it back to the caller through the output variable. It will also put a new status of the message in the status queue for all incoming messages (QL_IN_STATUS).
The message agent server may include utility functions such as the utility functions described below. This SentMsgStatus routine takes the unique reference number, MUR. of a message previously sent by SendSwift and returns the status of the message in the output variable Status.
A typical format for the function is as follows: Format: long SentMsgStatus (
[in] char MUR[], [out] char Statusf]) Remote Only.
The SentMsgStatus routine will use the MUR as a key to retrieve the latest status of the sent message from the status queue for all outgoing messages (QL_OUT_STATUS).
The RecentMsg Status function takes an application id (Aid) and returns all new message statuses since the last time this routine was called with the same application id. The function also returns the MUR of each corresponding message for each new status.
A typical format for the function is as follows: long RecentMsgStatus ( [in] char Aid, [out] char MUR[][],
[out] char Status[][]) Remote only
Every time the RecentMsgStatus routine is called, it gets the time stamp (format: yyyvmmdd) of the last call of the routine with the passed-in application id and the sequence number of the last retrieved message from an initiation file
(mas.ini). Upon returning, it updates this information in the initiation file.
The MasGetErrors function is utilized to obtain ErrorReference numbers created during parsing or formatting of a message. If the parse or format functions return an error value, the number returned is the ErrorReference number. When this number is returned, the message agent server looks up the number and returns an array of strings that describes the errors that were encountered in the original call as text strings, with field number and format tag in the beginning of each line if necessary. Up to 32 errors may be returned at a time. The errors are returned in the variable ErrorDetail. A typical format for this function is as follows: long MasGetErrors
[in] char ErrorReference [] [out] char ErrorDetail[][]) Remote and Local
Errors are placed in a circular buffer where MasGetErrors searches according to the ErrorReference number. After some time, depending on the buffer size and number of failed messages, the search is ended. Figure 7 illustrates the architectural design of a message queue for use in a message agent server of the present invention. The message queue is described with reference to IBM's MQSeries message queueing engine, however the message agent server of the present invention may utilize other message queueing services to perform similar functions. The queues identified and described are examples of the types of queues which may be utilized. The system is further described with reference to a SWIFT NETWORK INTERFACE which utilizes an X.25 type link. These description are provided by way of an example of an embodiment of a system of the present invention. As will be understood by those of ordinary skill in the art, further embodiments, and different functionality may be included in the message agent server, or the computing environment which includes the message agent server without departing from the present invention.
The message agent server may provides messaging and queuing capabilities for financial service industry application programs such as the FX Options application program, the FX Match application program and the FXM ST (Foreign Exchange Statement Requests) application program. These applications receive and send SWIFT messages through the message agent server which in turn communicates with a SWIFT NETWORK INTERFACE via an X.25 link. The message agent server may utilize IBM's MQSeries to facilitate sending messages to and receiving messages from the SWIFT NETWORK INTERFACE. The overall design is depicted in Figure 7. The computing environment includes the FXM ST application program, 212, the FX Match application program 214 and the FX Option application program 216. The programs are linked through remote procedure calls (RPC's) to an MQ Series Server, 220. [Need description of remaining components 231- of Figure 7. These components are described in greater detail in the following paragraphs.
The MQSeries allows Windows NT applications use message queuing to participate in message driven processing. Applications can communicate across different platforms by using the appropriate message queuing software products. For example, Windows NT and MVS/ESA applications can communicate through MQSeries for Windows NT and MQSeries for MVS/ESA respectively. The applications are shielded from the mechanics of the underlying communications.
MQSeries products implement a common application programming interface (message queue interface or MQI) whatever platform the applications are run on. This makes it easier to port applications from one platform to another.
With message queuing, the exchange of messages between the sending and receiving programs is asynchronous. This means that the sending and receiving applications are time- independent so that the sender can continue processing without having to wait for the receiver to acknowledge the receipt of the message. In fact, the target application does not even have to be running when the message is sent; it can retrieve the message after it is started.
On arriving on a queue, messages can automatically start an application using a mechanism known as triggering. If necessary, the applications can be stopped when the message or messages have been processed.
A queue manager manages the resources associated with it, in particular the queues that it owns. It provides queuing services to applications for Message Queuing Inter-face (MQI) calls and commands to create, modify, display, and delete MQSeries objects. The message agent server queue manager (MASQM) may be created with the following attributes:
Default Queue Manager: YES
Dead letter queue: SYSTEM.DEAD.LETTER.QUEUE
Logging: CIRCULAR Log file size: 1024K
Log path: C:\MQM\LOG.
(This log will preferably reside on a different drive from the queues.)
Primary logs: 5 Secondary logs: 2 The MQSeries command to create this Queue Manager is: crtmqm /q /u SYSTEM.DEAD.LETTER.QUEUE /Ic /If 1024 /Id C:\mqm\log /lp 5 /Is
2 MASQM This will create a queue manager that is the default queue manager for the particular machine, uses the queue SYSTEM.DEAD. LETTER. QUEUE for any undeliverable messages, uses circular logging, has 5 primary log files that are 4MB in size, and 2 secondary log files, all of which are located in C:\mqm\log.
The environment may be created with users defined specifically for MQSeries administration tasks. This user should have the allmqi permission assigned to their id or should be in the mqm group.
All of the processes that will be issuing MQI (message queue inquiry) calls should be started using user ids that are functional in nature so specific permissions on objects can be assigned accordingly. Examples of queues and their purposes are listed below.
Queue Name Purpose
QL IN FXOPT Incoming Foreign Exchange Option Requests.
QL IN FXMAT Incoming Foreign Exchange Match
Requests. QL_IN_FXSTM Incoming Foreign Exchange Statement
Requests. QL OUT CTSW Outgoing data back to SWIFT NETWORK INTERFACE .
QL_IN_STATUS Status queue for all incoming messages. QL_OUT_STATUS Status queue for all outgoing messages.
QL_OUT_STATUS_P Pointers of status queue for all outgoing messages. QL_ERROR_MAS Error Queue used by the X25/MQSeries process and the MQSeries/RPC Server process. QI INOUT MAS Initiation queue used to trigger an incoming or outgoing message event. QI ERROR MAS Initiation queue used to trigger an error event
The attributes of these queues are described in the following MQSC scripts to create them. DEFINE QLOCAL('QL_IN_FXSTIM') REPLACE +
DESCR('Foreign Exchange Statement Queue') +
PUT(ENABLED) +
DEFPRTY(O) + DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(25000) +
SHARE + DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+
USAGE(NORMAL) +
TRIGGER + TRIGTYPE(EVERY) +
TRIGDPTH(1) +
TRIGMPRI(O) +
TRIGDATAO +
PROCESS('QP_IN_FXSTM') + INITQ('QI_INOUT_MAS') +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(")+
SCOPE(QMGR) + QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) QSVCINT(6000) +
QSVCIEV(NONE)
DEFINE QLOCAL('QL_IN_FXOPT') REPLACE +
DESCR('Foreign Exchange Option Queue') + PUT(ENABLED) +
DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) + MAXMSGL(6000) +
SHARE+
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO + USAGE(NORMAL) +
TRIGGER +
TRIGTYPE(EVERY) +
TRIGDPTH(1) + TRIGMPRI(O) +
TRIGDATA(") +
PROCESSCQP - I - FXOPT') +
INITQCQI NOUT - MASI) + R-ETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(")+
SCOPE(QMGR) +
QDEPTHHI(80) + QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(6000) + QSVCIEV(NONE)
DEFINE QLOCAL('QLJN FXMAT') REPLACE
DESCR('Foreign Exchange Match Queue') +
PUT(ENABLED) + DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(6000) + SHARE +
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+
USAGE(NORMAL) + TRIGGER +
TRIGTYPE(EVERY) +
TRIGDPTH(l) +
TRIGMPRI(O) +
TRIGDATAO + PROCESS('QP_IN_FXMAT') +
INITQ('QI_INOUT_MASI) +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(")+ SCOPE(QMGR) +
QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) + QDPLOEV(DISABLED) +
QSVCINT(6000) +
QSVCIEV(NONE) DEFINE QLOCAL('QL_OUT_CTSW) REPLACE +
DESCRCOutgoing queue back to SWIFT NETWORK INTERFACE ') +
PUT(ENABLED) +
DEFPRTY(O) + DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(όOOO) +
SHARE + DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+
USAGE(NORMAL) +
TRIGGER + TRIGTYPE(EVERY) +
TRIGDPTH(I) +
TRIGMPRI(O) +
TRIGDATA(") +
PROCESSCQP OUT - CTSW) + INITQ('QI_OUT_MAS') +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(")+
SCOPE(QMGR) + QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) + QSVCINT(6000) +
QSVCIEV(NONE)
DEFINE QLOCAL('QL N STATUS') REPLACE +
DESCR('Status queue for all incoming messages') + PUT(ENABLED) +
DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) + MAXMSGL(32) +
SHARE+
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+ USAGE(NORMAL) +
TRIGGER +
TRIGTYPE(DEPTH) +
TRIGDPTH(5000) + TRIGMPRI(O) +
TRIGDATAO +
PROCESS('QP_IN_STATUS') +
INITQ('QI_INOUT_MAS') + RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAMEO +
SCOPE(QMGR) +
QDEPTHHI(80) + QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(6000) + QSVCIEV(NONE)
DEFINE QLOCALCQL OUT - STATUS-) REPLACE +
DESCR(Status queue for all outgoing messages') +
PUT(ENABLED) + DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(32) + SHARE +
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+
USAGE(NORMAL) + TRIGGER +
TRIGTYPE(DEPTH) +
TRIGDPTH(5000) +
TRIGMPRI(O) +
TRIGDATA(") + PROCESS('QP_OUT_STATUS')
INITQ('QI_INOUT_MAS') +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(") + SCOPE(QMGR) +
QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) + QDPLOEV(DISABLED) +
QSVCINT(όOOO) +
QSVCIEV(NONE) DEFINE QLOCAL('QL_ERROR - MAS') REPLACE +
DESCR('Local Error Queue') +
PUT(ENABLED) +
DEFPRTY(O) + DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(250) +
SHARE + DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO+
USAGE(NORMAL) +
TRIGGER + TRIGTYPE(EVERY) +
TRIGDPTH(I) +
TRIGMPRI(O) +
TRIGDATAO +
PROCESS('QP_ERROR_MAS') + INITQCQI ERROR MAS') +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAME(") +
SCOPE(QMGR) + QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) + QSVCINT(6000) +
QSVCIEV(NONE)
DEFINE QLOCALCQI NOUT MAS') REPLACE +
DESCR('Initiation queue for incoming and outgoing message events') + PUT(ENABLED) +
DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) + MAXMSGL(6000) +
SHARE +
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO + USAGE(NORMAL) +
NOTRIGGER +
TRIGTYPE(FIRST) +
TRIGDPTH(l) + TRIGMPRI(O) +
TRIGDATAO +
PROCESSC) +
INITQO + RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAMEO +
SCOPE(QMGR) +
QDEPTHHI(80) + QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(999999999) + QSVCIEV(NONE)
DEFINE QLOCAL(*QI_ERROR_MAS') REPLACE +
DESCR('Initiation queue for ERROR events') +
PUT(ENABLED) + DEFPRTY(O) +
DEFPSIST(YES) +
GET(ENABLED) +
MAXDEPTH(5000) +
MAXMSGL(6000) + SHARE +
DEFSOPT(SHARED) +
MSGDLVSQ(FIFO) +
NOHARDENBO +
USAGE(NORMAL) + NOTRIGGER +
TRIGTYPE(FIRST) +
TRIGDPTH(l) +
TRIGMPRI(O) +
TRIGDATAC') + PROCESSC) +
INITQO +
RETINTVL(999999999) +
BOTHRESH(O) +
BOQNAMEO + SCOPE(QMGR) +
QDEPTHHI(80) +
QDEPTHLO(20) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) + QDPLOEV(DISABLED) +
QSVCINT(999999999) +
QSVCIEV(NONE) The foregoing scripts are provided by way of example. Alternative scripts may be utilized to achieve similar results.
The processes and their attributes are listed below.
Process name Function QPJN FXSTM Triggered when an FXMatch Statement message arrives.
QP N FXOPT Triggered when a FX Option message arrives.
QP N FXMAT Triggered when a FX Match message arrives.
QP OOUT CTSW Triggered when a messages is to be sent back to the SWIFT Network Interface
QP ERROR MAS Triggered when an error event occurs.
The MQSC script to create these queues is as follows.
DEFINE PROCESSCQP - IN FXSTM') REPLACE +
DESCR('This process will be triggered for FXSTM activity') + APPLTYPE(WINDOWSNT) + APPLICID('c:\masq\programs\incsem\lncsem.exe') + USERDATA('DEBUG= 1 ') +
ENVRDATAO
DEFINE PROCESSCQP N FXOPT') REPLACE +
DESCR(This process will be triggered for FXOPT activity') + APPLTYPE(WINDOWSNT) +
APPLICID('c:\masq\programs\incsem\incsem.exe') +
USERDATA('DEBUG=1*) +
ENVRDATAO
DEFINE PROCESSCQP IN FXMAT') REPLACE +
DESCR('This process will be triggered for FARHAT activity') +
APPLTYPE(WINDOWSNT) +
APPLICID('c:\masq\programs\incsem\incsem.exe') +
USERDATA('DEBUG=1') ENVRDATA(")
DEFINE PROCESS('QP_ERROR_MAS') REPLACE +
DESCR(This process will be triggered for ERROR activity') +
APPLTYPE(WINDOWSNT) +
APPLICID('c:\masq\programs\geterror\geterror.exe') + USERDATA('DEBUG=1') +
ENVRDATAO
DEFINE PROCESS('QP_OUT_CTSW) REPLACE +
DESCR('This process will be triggered for outgoing activity') + APPLTYPE(WINDOWSNT) + APPLICID('c:\masq\programs\incsem\incsem.exe') +
USERDATA('DEBUG=1') +
ENVRDATA(") The foregoing scripts are provided by way of example. Alternative scripts may be utilized to achieve similar results.
MQI channels connect an MQI client to a queue manager on a server machine.
It is for the transfer of MQI calls and responses only and it is bi-directional. A channel definition exists for each end of the link.
The channels and their attributes are listed below.
Channel Name Purpose
QC X25SVR MASQM Server Connection to X25 Server (an
MQSeries Client) QC X25SVR MASQM Client Connection from X25 Server (an
MQSeries Client)
The MQSC script to create these queues is as follows.
DEFINE CHANNEL('QC_X25SVR*) +
CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
MCAUSERO +
DESCRCMASQM Server Connection to X25 Server (an MQ Client)*)
DEFINE CHANNEL(QC - X25SVR')+
CHLTYPE(CLNTCONN) +
TRPTYPE(TCP) +
CONN AME(I 92.193.83.149) + QMNAME(MASQM) +
DESCRCMASQM Client Connection from X25 Server (an MQ Client)')
As described above, a triggering function may be implemented to trigger a call to a queue when a message is waiting for delivery or transmission. The triggering processes may be implemented in a batch file utilizing the following protocol.
Step 1 : Start the listener for MASQM to use TCP/IP and to listen on Port 1414 (default port). Command: start runmqlsr /t tcp /p 1414 /in MASQM The preceding "start" causes the MS-DOS shell to spawn another shell to run the actually command so that commands may continue to be issued in the same MS-DOS shell.
Step 2: Start the trigger monitor to wait in the initiation queue for a trigger message. Command: runmqtrm. /m MASQM /q QI_INOUT_MAS
The output from all of these processes may be sent by using normal output redirection methods.
After these processes are running, when a message is sent to QL_IN_FXMAT, QL IN
FXOPT, QL N FXSTM, or OL OUT CTSW, the appropriate trigger will fire and the program incsem.exe will be invoked. The program will parse the trigger message and increase the appropriate semaphore so the message agent server server will be signaled. The message agent server will then connect to the appropriate queue manager, open the appropriate queue, and read all of the messages until the queue is empty. At this point the program will return and wait for the next trigger to fire. The protocol for troubleshooting the triggering function may include the following items. Checking the local queue definition to ensure that the NOTRIGGER parameter is not set, and that the PROCESS and INITQ fields have the correct values. Checking to ensure that the INITQ and PROCESS objects exists. The commands are: runmqsc <QueueManager> dis q(initQueueName) dis pro(processName) all The output from the display process command may be viewed to ensure that the path to the triggered program is correct, and that the program is there. The state of the trigger monitor may also be reviewed to ensure that the trigger monitor in running, and connected to the correct initiation queue for the appropriate Queue Manager.
If the notion of DEBUG has beent coded and passed to the triggered program, the process may be alter to turn DEBUG on and send a message and the result reviewed. The command to alter the process is: runmqsc alter process(processName) userdata('DEBUG=l'). The trigger system may also be troubleshot may using the trigger type of FIRST and making sure the queue is empty before A user start the trigger monitor (see runmqtrm command). A trigger type of DEPTH may also be utilized. When the DEPTH triggers fires, the queue manager will set the NOTRIGGER attribute. It is the responsibility of the triggered application to issue the MQSET call to reset the
TRIGGER attribute.
The message agent server may include security features. Security in MQSeries for Windows NT uses the users and groups that are created in the "User Manager Facility" from the Windows NT "Administrative Tools" icon. If a user Id belongs to the "mqm" (IBM MQSeries Administration Group) A user will have all of the authorities to all resources. There are situations, such as production environments that the more secure features of MQSeries will need to be in place, to ensure protection of system resources as well as protection of data.
The command used to establish specific permissions against MQSeries objects is setmqaut. A user must be in the mqm group to use this command. The parameters that follow this command are listed below. setmqaut /in Queue Manager Name (Queue Manager Name that owns the object) /n Object Name (Name of the Queue or Process. Not needed if the Object
Type is qmgr)
/t Object Type (queue or q, process or prcs, qmgr, must be lower case)
/p Principal Name (Name of the principal (ID) to which the authorizations are to be granted. A user can enter more than one, but each must be prefixed by the /p flag)
/g Group Name (Name of the group (ID) to which the authorizations are to be granted. A user can enter more than one, but each must be prefixed by the /g flag) Authorizations are listed in the table below. To add an authority, prefix it with a '+', to remove one prefix it with a.
Authority Queue Process Q> Manager all X X X alladm X X X allmqi X X altusr X browse X chg X clr X connect X crt X X X dlt X X X dsp X X X put X inq X get X passall X passid X sseett Xx X x setall X x setid X x x
Example: setmqaut /in queue. manager. 1 /n QL_IN_FXMAT /t queue /p binli +put These permissions will allow the userld binli the ability to issue the MQPUT or
MQPUT I call on the object QLJN FXMAT.
Once authorities have been assign to the appropriate groups, they can be displayed using the dspmqaut command. The parameters that follow this command are listed below. dspmqaut /m Queue Manager Name (Queue Manager Name that owns the object)
/n Object Name (Name of the Queue or Process. Not needed if the Object Type is qmgr)
/t Object Type (queue or q, process or prcs, qmgr, must be lower case) /p Principal Name (Name of the principal (ID) to which the authorizations are to be granted. A user can enter more than one, but each must be prefixed by the /p flag)
/g Group Name (Name of the group (ID) to which the authorizations are to be granted. A user can enter more than one, but each must be prefixed by the /g flag) Example: dspmqaut /in MASQM /n QL_OUT_CTSW It queue /p binli
Output from the display command above is shown below.
Entity binli has the following authorizations for object QL OUT CTSW: get browse put inq set crt dlt chg dsp passid passall setid setall clr Queue Manager permissions may be implemented and are preferably controlled with careful consideration. All processes that will be issuing MQI interface calls, are preferably started using a functional ID or GROUP for that process. This ID or GROUP will need the ability to issue an MQCONN call, to connect to the Queue Manager. The command to enable this connection is shown below: setmqaut /in queue.manager. I /t qmgr /p binli +connect This command would allow a process started with the binli userld access to connect to the Queue Manager.
The other permissions on the Queue Manager should be assigned to an entirely different group, that will be used for administrative purposes. Especially chg (Change), crt (Create), dlt (Delete) and any of the all* authorities. Queues are the facility used to store data. Whether persistent or non-persistent, the data is preferably protected from intrusion, or accidental access. Each application that is running on a given platform, can be limited to the objects it can use and what functions it can perform on these objects.
A process is an event specified to occur when the trigger criteria for a local queue has been satisfied The commands for setting and revoking these permissions follow the same conventions as Queue Managers and Queues.
The message agent server MQ/Series server may be installed and deployed on a computer platform utilizing the following steps: Step 1. Action: install MQSeries in C:\mqm Explanation: C:\mqm is the recommended directory
Step 2. Action: copy C:\masq from a development machine Explanation: including all subdirectories Step 3. Action: run C:\masq\commands\genBatch.exe
Explanation: genBatch creates all the NT batch files used in the steps below. While running, A user is asked to specify root directory for the following:
MQ Series root directory [C:\mqm]: X:\mqm MAS Queue Manager root directory [C:\masq]: X:\masq X is the drive letter that installer specified. All batch file are generated *in X:\masq\commands\. Step 4. Action: run C: \masq\commands\crtmasqm. bat
Command: crtmqrn /q /u SYSTEM.DEAD.LETTER. QUEUE /lc /If 1024 Ad
C:\mqm\log /Ip 5 /Is 2 MASQM Explanation: queue manager MASQM is created Step 5. Action: run C: \masq\commands\stmasqm. bat Command: strmqm Explanation: queue manager MASQM is started
Step 6, Action: run C:\rnasq\commands\crtdefob.bat Command: runmqsc < C:\mqm\mqsc\amqscoma.tst > C:\mqm\mqsc\defobj.out
Explanation: default and system objects (default channel definitions, etc.) are created
Step 7. Action: run C:\masq\commands\crtmasob.bat Command: runmqsc < C:\masq\objects\masqm\masqmobj.in > C: \masq\obj ects\masqm\masqmobj. out
Explanation: creates all the MASQM objects (queues, processes, channels) Step 8. Action: copy C:\mqm\qmgrs\masqm\@ipcc\amqclchl. tab to C:\mqm
Explanation: the client channel definition file needs to be in DefaultPrefix directory defined in C:\mqm\mqs.ini, otherwise, environment variables MQCHLLIB and MQCHLTAB have to be set (another alternative is to use the MQSERVER environment variable which overrides the other two) Step 9. Action: run C:\masq\commands\stmasqml.bat
Command : start runmqlsr It tcp /p 1414 /m MASQM Explanation: starts a listener on MASQM
Step 10. Action: create shortcuts to stmasqm.bat and stmasqml.bat and put them in the startup folder Explanation: so they will be automatically started on NT restart
Preferably a message agent server of the present invention will include methods for handling errors, including message delivery errors, message format errors and the like. A possible means for error handling is set forth in the following paragraphs.
All message agent server errors may be put in a local queue QL ERROR MAS. A trigger may then be fired every time a message is put on this queue. A trigger program GetError.exe will in turn be invoked to get the error message and post an entry in the NT event log (viewable from NT event viewer). Preferably the GetError process is triggered for every message that arrives on the QL_ERROR_MAS queue.
By way of example, the message agent server may be configured with three categories of errors, namely MAS NFO, MAS_WARN, and MAS ERROR. These categories are defined in the following script used by NT event log.
MessageIdTypedef=WORD MessageId=Oxl SymbolicName=MAS_INFO Language=English
Category #1
Messageld=0x2
Symbol icName=MAS_WARN Language=English
Category #2
Messageld=0x3
Symbol icName=MAS_ERROR Language=English
Category #3
MessageIdTypedef=DWORD
MessageId=0xl00 Severity=Informational
Facility=Application
SymbolicName=INFO_ONE
Language=English
This is an informational message.
Messageld=0x200
S everity = Warning
Facility-Application
SymbolicName=WARN-ON-E Language=English
This is a warning message.
Messageld=0x3000 Severity-Error Facility=Application SymbolicName=ERROR-ONE Language=English This is an error message.
These errors are provided by way of example. The message agent server may include functionality for handling different types of errors depending on the needs of the application programs and network interface. As described above, the message agent server includes a network interface to allow messages to be passed to an external network such as the SWIFT network. The interface or gateway to the SWIFT network may be included within the functionality of the message agent server as a local function, ie residing on the same server (computer hardware). Alternatively, the the message agent server may interact with the interface or gateway through a communications link.
Figure 8 depicts an embodiment of a message agent server architecture wherein the interface to a SWIFT network is provided by an X.25 interface. As shown in Figure 8, a computing environment may include the FX Options application program 216 and the GlobalClear application program 218 which each link to message agent server 10, through a remote procedure call to the application interface
100. The application interface 100 is linked to message queue manager 130, which manages the message queues 110. A message queue network interface 120 is provided to interface between the message agent server and the X.25 network 45 which includes a SWIFT NETWORK INTERFACE 50. The message agent server is also linked to a message format library 145. The application programs, application interface, message queue manager, message queues and message format library are described in preceding sections. The following paragraphs describe a possible embodiment of a SWIFT NETWORK INTERFACE utilizing an X.25 network connection. The message queue network interface Connection Module is one of the integrated components of Message Agent Server (MAS). This module may utilizes EiconCard technology to provide X.25 interface thus enabling applications to exchange messages with an X.25 network through message agent server. The interface may also handle message security, exception handling/recovery, and much more.
The X.25 Interface Between message agent server and SWIFT NETWORK INTERFACE may be implemeneted as follows. The application level protocol between the message agent server and the SWIFT NETWORK INTERFACE may follow the CMX's X.25 interface standard, which provides a message transfer mechanism between CMX system and a remote DTE like message agent server through X.25 network. Alternatively the 'interface between message agent server and CMX operates on Switched Virtual Circuit (SVC). By way of overview, in a CMX protocol, a circuit is established to enable message transfer in single direction, either SEND ONLY or RECEIVE ONLY. Based on this assumption, two virtual circuits must be established to provide basic message transfer capability between message agent server and the SWIFT NETWORK INTERFACE. One circuit is to allow the message agent server to send messages to the
SWIFT NETWORK INTERFACE. The SWIFT NETWORK INTERFACE will send "ack" or "nak" back to the message agent server over the same channel. This channel is the SEND ONLY channel for message agent server.
Another circuit is to allow the message agent server to receive message from the SWIFT NETWORK INTERFACE. The message agent server will send ack or nak back to the SWIFT NETWORK INTERFACE over the same channel. This channel is the RECEIVE ONLY channel for message agent server.
These two channels may use the same DTE address pair between the message agent server and the SWIFT NETWORK INTERFACE. During normal operations, the two channels will generally not interfere with each other.
The CMX protocol also states that the SENDER is responsible to establish the network connection and to retry the connection if the link is disconnected.
When the message queue network interface starts, it may take the following initialization steps: Initialize event queue for logging system events.
Make sure EiconCard has started and is running on the machine this module runs on. Test which applications are running. Initialize application classes and various structure array.
If any of above steps fail, this module will report exception and stop itself.
After the initialization steps pass smoothly, the X.25 server module spawns two link threads, 121 and 123: one manages the inbound channel, the other takes care of outbound channel.. The server module terminates after both link threads are terminated.
Each thread takes its own initialization steps: Check which applications it need to deal with. Initialize an array of application handles.
Load the table about mapping among applications, queues, and semaphores. This mapping table must be persistent.
Make connection to message agent server Message Queuing System (MQ Manager) and open the error queue. It requires that MQ Manager be running already. For each application the thread deals with, it opens semaphores. If the semaphores for the application are not there, it will create them. Note that the message agent server MQ-application interface RPC Server also create the semaphores, so if the RPC Server is running, the link thread just needs to open the semaphores. Make connection to SWIFT NETWORK INTERFACE . If the MQ Manager or message agent server RPC Server is not started, the above initialization steps will fall, and the link thread will terminate itself If everything works fine, the link thread will begin its normal operation.
There are a certain number of protocol stages that the link thread runs into. At each stage the link thread should call certain application 'interface functions based on what application the handling message belongs to.
When link thread wants to shutdown itself, it does the following: Close the VC connection to SWIFT NETWORK INTERFACE , For each application the thread interacts with, close semaphores and all queues, but don't touch the messages. Close the error queue, and disconnect from message agent server queue manager. Unload the mapping table among applications, queues, and semaphores. Make persistent change if changes are needed.
During initializations, if anything fails the X.25 server or its threads just terminate themselves. As set forth above, the Message Queuing System may utilize a set of queues configured by MQSeries.
For each message flow direction, Queue Manager provides a status queue to report message transfer status. The status messages in these queues has the following format: yyyymmddXXXNNNNnnnnnnS
Format code Explanation Example yyyymmdd date of message transfer 19970110
XXX message incoming source FXO, SWT
NNNN SWIFT session number 0392 nnrLnrin SWIFT sequence number 174038
S status code P, S, F
Possible values for the status code are: P(ending), S(uccess), and F(ail).
Implementation of the message functionality may be accomplished as follows. For an outbound message: The Message Queuing System puts outgoing message onto queue
QL_OUT_CTSW.
When the Message Queue Network Interface module gets the message from QL_OUT_CTSW, it will transfer it out to the X.25 network. Based on the result of transfer, it will put a status message back to the outbound status queue QL_OUT_STATUS with the message reference number and the status code. The status code is either S or F. The Message Queuing System gets the status message and process it.
For an inbound message: When the Message Queue Network Interface module get a message from X.25 network, it will put it onto appropriate queue based on the application it belongs to. It will also construct a status message and put it onto the inbound status queue QL IN STATUS with the message reference number and the status code. The status code is P for pending status. The Message Queuing System gets the application message. After the message is transferred to application, the Message Queuing System will update the status of the status message.
The foregoing functionality may be accomplished through the use of modules including an Outbound Service Module and an Inbound Service Module. These modules may be part of the message queue network interface.
The Outbound Service Module is responsible for sending application messages out to X.25 network over the SEND CHANNEL. Basically this module is in one of the following three states: 1. CALL State When the Outbound Service Module starts, it's in this state by default. The
SENDER will make a call request to connect to the remote SWIFT NETWORK INTERFACE DTE. The connection is expected to stay up until the system shutdown. If the call request fails, the sender will retry the connection at regular interval until the call is successfully accepted by the remote RECEIVER. 2. SEND MSG State
Once the call is established, the sender can start sending messages. For every message directed to SWIFT NETWORK INTERFACE, it may follow this procedure: Get message from the Output Queue (QL_OUT_CRSW) but do not remove it from the queue. Send message to SWIFT NETWORK INTERFACE .
To ensure message integrity, the sender will generate a 16-bit CCITT CRC checksum for the message, append the two byte checksum to the end of the message. During transmission, the SENDER will segment the whole message with checksuM into one or more X.25 data packets. The packet size is determined at CALL time following X.25 protocol standard. The last packet of the message will not have the
M(ore) flag asserted. There is no need to define either a Start Of Message (SOM) or an End Of Message (EOM) character sequence. 3. WAIT ACK State
After sending a message, the SENDER will wait for the acknowledgment from the RECEIVER. The SENDER will increment the sequence number and remove the current message from the Output Queue of the Queue Manager only if a good acknowledgment is received.
Depending on the error code in the acknowledgment note from the SWIFT NETWORK INTERFACE, the SENDER will log event to the Event Queue for whatever happened.
The outbound X.25 link server may manage the link with a finite state system. The state diagram is shown in Figure 9.
The states defined in this diagram are described below. To Be Connected State, 301 : This is the initial state. The circuit is disconnected. When link server is in this state, it's about to issue a call request to SWIFT NETWORK INTERFACE . After x25call() is issued, it goes to Pending Connect State.
Pending Connect State, 303: A call request was issued, the link server waits for the result. If result is OK, it goes to Connected State, otherwise, it goes to Fall
Connect State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending call with x25cancel() and go to Fall Connect State.
Fail Connect State, 305: System is in this state if the pending call request failed or timed-out, and the circuit is not up. It waits on this state for a certain period of time. After the timeout period, it goes to To Be Connected State and try to connect again.
Connected State, 307: This is the idle state for normal operation cycle. Circuit is up, the link server is waiting for new message from applications. There is no message exchange activity going on the circuit. If message comes, it'll send it with x25send() and go to Pending Send State.
Pending Send State, 309: A message was sent out, the link server waits for the result. If result is OK, it goes to Wait Reply State, otherwise, it goes to Fail Send State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending call with x25cancel(), and go to Fail Send State.
Fail Send State, 311 : The last message sending request failed. It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly due to the problem found during the last message exchange, or for some other reasons. The result of the last x25send() call tells us if the circuit is up or down. If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue
X25call() there.
Wait Reply State, 313 : A message was successfully sent out. The link server issues x25recv() for the reply message from SWIFT NETWORK INTERFACE , then go to Pending Reply State. Pending Reply State, 315: The link server waits for the result of getting reply message from SWIFT NETWORK INTERFACE . If result is OK, it goes to Process Reply State, otherwise, it goes to Fall Reply State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending call with x25cancel(), and go to Fail Reply State. Fall Reply State, 317: The link server failed to receive the reply message from
SWIFT NETWORK INTERFACE . It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly because of the problem found in the last message we sent to them, or for some other reasons. The result of the last x25recv() call tells us if the circuit is up or down. If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x25call() there.
Process Reply State, 319: In this state the link server examines the reply message it Just got from SWIFT NETWORK INTERFACE related to the last message sending. If the reply message indicates that the message sending is OK, the link server will do the appropriate processing like increment the sequence number, and go to Connected State, where it's ready to send the next message. If the reply message indicates there is a non-fatal protocol problem, the link server will back out the last message sending, make appropriate correction, and go to Connected State to resend the message. If problem is fatal, the link server will go to Clear State and hang-up the circuit there. Reset State, 321 : The X.25 circuit is up, but there is a problem that the circuit must be cleared and reestablished. So the link server will hang-up the circuit, then go to To Be Connected State to reissue x25call().
Clear State, 323: Severe problem has occurred and the link server should terminate. So it will clear the X.25 circuit with x25hangup() call, then go to Shutdown
State.
Shutdown State, 325: The circuit is disconnected and there is no reason for the link server to stay alive. This usually happens when severe errors happened to the circuit, or after user closed the circuit. Message processing may proceed as follows. For outbound link, after the X.25 connection is up, the link is at connected state, with nomessage exchange activities active. The link thread is at its initial state:
It waits for ANY semaphore to signal. It knows which semaphores to look at.
Once a semaphore is received, the link thread does the following: Make semaphore not signaled.
Retrieve but do not destroy the first message from the queue bound to the semaphore. It reads the message, and remember the application outbound sequence number.
Check source and destination code on the message. If not recognized, nak the message with the right application number. Signal the reply semaphore.
Put GCN code and SWIFT NETWORK INTERFACE outbound sequence number onto the message.
Append CRC-CCITT checksum of the whole message to the end.
Then send the message with x25send(). At this point, if the x25send() fails, or it fail to receive a CMX level reply message from the network the outbound link server treats the message sending as having failed and will execute the following procedure:
Release the semaphore, increment it by 1 so it's back to signaled state so that the environment is configured like the outbound message has never been touched. Reset the outbound circuit, which means close it and reconnect. If the connection is already closed, issue a x25call() to reconnect it. Log this event. If a CMX level reply message comes in, based on what it is, the outbound link server will respond like this:
1. Reply message is "00 - ACCEPTED". Outbound link server takes action 0: Increment SWIFT NETWORK INTERFACE outbound sequence number, so next message will use a higher number. The number used after 9999 must be 000 1. Remove the message from the queue bound to the semaphore. Insert an ack message to the reply queue back to application. The ack message contains application sequence number. MQ Series will signal the reply semaphore. 2. Reply message indicates that outbound link server should take action I or 2. This is generally an application error, so link server should reply to application with a nak message. Remove the message from the queue bound to the semaphore. Insert an nak message to the reply queue back to application. The nak message contains application sequence number. MQ Series will signal the reply semaphore. The content of the nak message is important. It should provide enough infoπnation for the application to correct the message. At least it must have severity code, error type code, and error message. Action 2 is more severe. It means the problem is at system level, not message level. The application probably should be terminated to avoid further damage and then investigate the error. The outbound link server does not increment SWIFT NETWORK INTERFACE outbound sequence number, so next message will use the same number.
3. Reply message indicates that outbound link server should take action 3. This is an operational error, the link server should make correction and resend the message instead of replying to application with a nak message. Release the semaphore, increment it by 1 so it's back to signaled state so that the environment is configured like the outbound message has never been touched. Take appropriate actions, e.g. If it's "32 - LOW SEQUENCE NUMBER", the link server must increment its SWIFT NETWORK INTERFACE sequence number. If it's " 13 - NO SEQUENCE NUMBER", the link server must check the reason. If it's "30 INVALID CHKSUM", the link server must change the CRC polynomial and regenerate its CRC table. Revert back to initial connected state and wait for semaphore. 4. Reply message indicates that an unlikely error has occurred on the message. This usually means it's a system or X.25 problem, not with the message. The link server should keep the message in unsent status, then terminate the system and investigate the error. Release the semaphore, increment it by 1 so it's back to signaled state so that the environment is configured like the outbound message has never been touched. The application should be terminated to avoid further damage and then investigate the error.
The following table provides a brief summary of the foregoing discussion:
Figure imgf000064_0001
In any event, it is preferable that the link server must log the message transfer result.
Once back to the connected state with no message exchange activity, it's time for the outbound link server to check external event to see if operator wants to close it. If it does, it'll follow the procedure described above in the general section to do so.
Exceptions to the foregoing message tranfer actions are generally caused by an MQ Series problem. If the Message Queuing System does not function normally the X.25 link server will have trouble working on its way.
The major interaction points between X.25 outbound link server and message queue are listed below:
Startup point: connect to message queuing system (MQ Manager), open semaphore. This is described above. Wait for new message from application: If MQ Manager's trigger monitor is down at this time and a new message comes in, link server keeps waiting, but unable to get the message. IF MQ itself is down, link server keeps waiting. When MQ back up again, link server is still unable to get the message because it's not triggered by semaphore. Preferably the trigger monitor is synchronized with new messages in the queue.
If for some reason, link server get triggered, but unable to get the new message, it won't be able to send that message out. Instead it goes back to wait for the new semaphore triggering event. It's possible that message is sent out, but link server fail to give sent status back to application. If this happens, when the link server got Ack/Nak from SWIFT NETWORK INTERFACE later, it destroys the original message from the message queue, but won't be able to update message status again. So application don't know the correct status of this message. In other words, it is preferably that a message and its status must be synchronized at all time.
All related operations must be bound together as atomic operation. The Inbound Service Module takes care of the RECEIVE CHANNEL. Basically it's in one of three states: 1. LISTEN State: When the Inbound Service Module starts, it's in this states by default. It listens to incoming call request from the specified remote SWIFT NETWORK INTERFACE DTE. For security purposes, this RECEIVER will check and verify the incoming DTE, only calls from predefined SWIFT NETWORK INTERFACE DTE are accepted. 2. WAIT-MSG State: The RECEIVER will continuously receive data packets until detecting a packet without a M(ore) flag. During the process, it assembles the message by concatenating received packet data. After the whole message is concatenated together, the last two bytes is the 16-bit CCITT CRC checksum of the whole message. The real message is two bytes short from what received. So the RECEIVER will recalculate the checksum and verify with the received checksum. If the checksums don't match, the RECEIVER will send the nak message to SWIFT NETWORK INTERFACE with the error code "30 - INVALID CHKSUM" as data.
If the checksum is good, it's removed from the tail of the message, and the RECEIVER goes to SEND ACK state. 3. SEND ACK state: The RECEIVER does the following to process the message:
The real message without checksum is queued to the Input Queue of the Queue Manager. If this step failed, the RECEIVER must safestore the message and shut itself down. Send Ack Nak back to SWIFT NETWORK INTERFACE based on the processing result of step 1.
Log event to the Event Queue.
The inbound X.25 link server may manage the link with a finite state system. The state diagram is shown in Figure 10. The states defined in Figure 10 are described below.
To Be Connected State, 401 : This is the initial state. The circuit is disconnected. When link server is in this state, it's about to issue a listen from SWIFT NETWORK INTERFACE . After x251isten() is issued, it goes to Pending Connect State. Pending Connect State, 403 : A listen was issued, the link server waits for an incoming call from CITIS WITCH. If a call comes in, and the circuit setup OK, it goes to Connected State. If the listen failed, it goes to Fall Connect State. If no result from SWIFT NETWORK INTERFACE after time-out period, link server will cancel the pending listen with x25cancel(), and go to Fail Connect State. Fail Connect State, 405: System is in this state if the pending listen failed or timed-out, and the circuit is not up. It waits on this state for a certain period of time. After the time-out period, it goes to To Be Connected State and try to listen again. Connected State, 407: This is the starting point for normal operation cycle. Circuit is up, the link server issues x25recv() on the circuit to wait for new message from SWIFT NETWORK INTERFACE . Then it goes to Pending Receive State.
Pending Receive State, 409: If message comes, the x25recv() will return OK, and the link server goes to Wait Reply State to prepare for the reply message to SWIFT NETWORK INTERFACE . If the x25recv() call failed, it goes to Fail Receive State. If no message from SWIFT NETWORK INTERFACE , the link server will stay in this state.
Fail Receive State, 411 : The last receiving message call failed. It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly due to the problem found during the last message exchange, or for some other reasons. The result of the x.25recv() call tells us if the circuit is up or down. If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x251isten() there.
Wait Reply State, 413: A message was successfully received. The link server processes the message, sends to application. Based on its result, the link server prepares the reply message and sends it back to SWIFT NETWORK INTERFACE with x25send(), then it goes to Pending Reply State.
Pending Reply State, 415: The link server waits for the result of sending reply message to SWIFT NETWORK INTERFACE . If result is OK, it goes to Connected State and deals with next message. Otherwise, it goes to Fail Reply State. If the reply sending process has no result after time-out period, link server will cancel the pending send with x25cancel(), and go to Fail Reply State.
Fail Reply State, 417: The link server failed to send the reply message to SWIFT NETWORK INTERFACE. It usually happens because SWIFT NETWORK INTERFACE has already cleared the circuit unexpectedly because of the problem found in the last message we sent to them, or for some other reasons. The result of the last x25send() call tells us if the circuit is up or down, If the circuit is still up, the link server should go to Reset State and clear the circuit with x25hangup() there, then reestablish the X.25 session. If the circuit is already down, the link server should go to To Be Connected State immediately and reissue x251 lstenf) there.
Reset State, 419: The X.25 circuit is up, but there is a problem that the circuit must be cleared and reestablished. So the link server will hang-up the circuit with x_25hangup(), then go to To Be Connected State to reissue x251isten(), Shutdown State, 421 : The circuit is disconnected and there is no reason for the link server to stay alive. This usually happens when severe errors happened to the circuit, or after user closed the circuit.
By way of example, a typical message processing scenario may look as follows. For inbound link, after the X.25 connection is up, the link is at connected state, with no message exchange activities active. The link thread is at its initial state:
It issues x25recv() to wait for a message from SWIFT NETWORK INTERFACE . If the x25recv() failed: Reset the inbound circuit. If the VC is already closed, issue another x251isten() to reconnect it. The goal is to go back to the initial connected state, then try to receive another message.
Once a message is successfully received, the link server performs the message checking steps. If it encounters any error during the following checking, the link server takes actions by itself and sends CMX level reply message back to SWIFT
NETWORK INTERFACE .
Check CRC-CCITT checksum of the received message. If wrong, reply "30 - INVALID CHKSUM". Then strip the checksum from the message.
Check GCN code, and the incoming SWIFT NETWORK INTERFACE sequence number. If not expected, reply " 13 - NO SEQUENCE NUMBER" or "32 -
LOW SEQUENCE NUMBER". Then strip the first line from the message.
Check source address code. If it's not SWIFT NETWORK INTERFACE , reply error messages " 19 INVALID ORIGINATOR".
Check destination address code. If the link server doesn't know where to queue this message, it replies " 14 - INVALID ADDRESS".
Check message format. Various format errors may arise. Construct reply message accordingly.
It is not required that the link server notify the applications about these errors. If the message is correct, the link server will do this: Add application sequence number to the message.
Send the message directly to the appropriate application queue. No semaphores are involved. Send reply message "00 - ACCEPTED" back to SWIFT NETWORK INTERFACE . If the reply is sent back successfully, increment SWIFT NETWORK INTERFACE inbound sequence number.
Increment application inbound sequence number. In case the link server fails to send any reply message back to SWIFT NETWORK
INTERFACE, whether its ack or nak, the link server must reset the inbound circuit to its initial connected state and wait for new messages coming from SWIFT NETWORK INTERFACE .
Most failures in the inbound message process will result from problems with the MQ Series engine. The major interaction points between X.25 inbound link server and the message queue are listed below:
Startup point: connect to MQ Manager, open semaphore. This is described above.
The message received from the SWIFT NETWORK INTERFACE may be either a real transaction message from SWIFT or the Nak message from SWAN or
SWIFT, mostly due to message format problems. If it's a Nak from SWAN or SWIFT, the link server will put the Nak message onto Error Queue instead of normal application message queues. If it fail to put it onto Error Queue, the link server will reply "27 - UNDELIVERABLE MESSAGE" back to SWIFT NETWORK INTERFACE .
If the link server fails to parse the incoming message from the SWIFT NETWORK INTERFACE, or fall to put it into application message queue due to MQ problems, it'll send a "27 UNDELIVERABLE MESSAGE" back. The SWIFT NETWORK INTERFACE will shutdown the circuit, then try to connect again. When the link server finds the circuit is down when it tries to get the next message, it'll listen again to setup connection, then receive the next message.
Sometimes after the link server sent a message to application, it can not get the status message indicating that the message has been delivered to its application system. This may because that message queueing service is down, or message agent server RPC server program is not up. If this happened, the link server is unable to send reply back to the SWIFT NETWORK INTERFACE . The CMX protocol may hang up in this dead lock. Sometimes the link server may fail to send reply back to the SWIFT NETWORK INTERFACE because circuit is already down for some reason, most probably the SWIFT NETWORK INTERFACE cleared it. In this case the link server will listen again, but after reestablished the cuicuit it won't resend the reply. Instead it'll wait for the next incoming message, most likely is the previous one with PDE. If this is the case, it should discard the new message and reply "00 - ACCEPTED".
Preferably the message agent server is constructed so as to provide synchronization between the message agent server RPC server (MQ-Application Interface) and the X.25 server (Message Queue Network Interface). Synchronization is desirable to achieve the following goals: no message from the message agent server
RPC server to the X.25 server is lost; no message from the message agent server RPC server to the X.25 server is lost; no message is sent more than once from the message agent server RPC server to the X.25 server; no message is sent more than once from the X.25 server to the message agent server RPC server. Synchronization may be accomplished in a variety of manners. One technique is described below.
The message agent server RPC server and the X.25 server communicate through semaphores, namely SEM OUT CTSW, SEM_IN_FXO, SEM_IN_FXM, and SEM_IN_STM. The message agent server RPC server has to make sure that the value of the semaphore SEM OUT CTSW always equals to the number of messages in the queue QL_OUT_CTSW. The X.25 server has to make sure that the value of SEM_IN_FXO (SEM_IN_FXM, SEM_IN_STM, respectively) always equals to the number of messages in the queue QL_IN_FXO (QL_IN_FXM, QL_IN_STM, respectively). On a Windows NT platform, after a semaphore is created, it is persistent until all the processes that have accessed it are terminated, Therefore, after the message agent server RPC server creates SEM OUT CTSW, it will be persistent until both message agent server RPC server and the X.25 server are terminated. Same goes with SEM N FXO, SEM_IN_FXM, and SEM_IN_STM. The following table details possible failure scenarios and methods for recovering from the failures.
Figure imgf000071_0001
These failures, and recovery therefrom, are discussed in more detail below. When X.25 Server recovers it tries to open relevant semaphores and MAS QM.
Outbound Service: Open SEM_ERROR_MAS_SEM_OUT_CTSW.
Failed: MAS RPC Server is down. Unable to get new messages, but there may be old messages in the queue. So create these semaphores and initialize to the message count in the relevant queue.
Succeeded: MAS QM is up. So send all messages *in QL_OUT_CTSW, then wait. Failed: MAS QM is down. No way to retrieve any message. So quit.
Succeeded: MAS RPC Server is up. Semaphore must be initialized to the message count. Then it connects to message agent server QM.
Succeeded: MAS QM is up. So send all messages in QL_OUT_CTSW, then wait. Failed: MAS QM is down. No way to retrieve any message. So quit.
Inbound Service: Open SEM_ERROR_MAS_all semaphores for application queues.
Failed: MAS RPC Server is down, but we can still send messages to the queues. So create these semaphores and initialize to the message count in the relevant queue.
Succeeded: MAS QM is up. So start operation.
Failed: MAS QM is down. No way to send message over. So quit.
Succeeded: MAS RPC Server is up. Semaphore must already be initialized to the message count. Now connects to MAS QM. Succeeded: MAS QM is up. So start operation.
Failed: MAS QM is down. No way to send message over. So quit.
When message agent server RPC Server recovers, it tries to open SEM_ERROR_MAS and SEM_OUT_CTSW.
Failed: X.25 Server is down. Although the messages can't be sent to the SWIFT NETWORK INTERFACE, this server should still send message to MQ. So create these semaphores and initialize to the message count in the relevant queue. Succeeded: MAS QM is up. So send all messages to QL OUT CTSW. then wait.
Failed: MAS QM is down. No way to send message. So quit.
Succeeded: X.25 Server is up. Semaphore must be initialized to the message count. Then it connects to message agent server QM.
Succeeded: MAS QM is up. So send all messages to QL_OUT CTSW, then wait.
Failed: MAS QM is down. No way to send message. So quit.
In the message agent server RPC Server, MasReceiveMsg Is called to retrieve messages from message agent server application queues. So it attempts to open
SEM ERROR MAS & all semaphores for application queues.
Failed: X.25 Server is down. Unable to get new messages, but there may be old messages in the queue. So create these semaphores and initialize to the message count in the relevant queue. Succeeded: MAS QM is up. So start operation.
Failed: MAS QM is down. No way to get message over. So quit.
Succeeded: X.25 Server is up. Semaphore must already be initialized to the message count. Now connects to MAS QM.
Succeeded: MAS QM is up. So start operation. Failed: MAS QM is down. No way to get message over. So quit.
One special situation may occur when a message agent server QM Triggrer Monitor dies and restarts, while the X.25 Server is always up so the semaphore is never deleted. Resynchronization may effected by restarting the servers.
An alternative embodiment of a computing environment utilizing the system of the present invention is depicted in Figure 11. The depicted embodiment includes 4 servers, a message agent server (MAS), 600 for interfacing with application programs 601 ; an X.25 Server, 602, utilized for access to the SWIFT network, 603; an administrative server, 604 which provides a human interface to the system, through graphical user interface 605; and a File Tranfer Server (FTS), 608 for communicating with other customers, 609. The MAS, X.25 and Administrative servers have access to the message queue, 610 which is preferably an IBM MQ Series. The FTS server's access to the message queue is through the MAS server.
The X.25 server is responsible for communicating with a SWIFT network gateway and ultimately the SWIFT network through an X.25 protocol. This protocol maps a logical connection to a station ID as a means of identification and the sequence number as a means of synchronization. Each side needs to keep track of its sequence number, only messages with the same expected sequence number are accepted. Details relating to the X.25 protocol and message traffic to and from the SWIFT network are set forth in the preceding sections. The FTSIN server is responsible for processing files received from customers.
Customers may use a file transfer facility called "Connec Direct" from Sterling Commerce, Inc. to send files to the server. Upon detecting the arrival of a file, FTSIN breaks the contents of the file into records, optionally reformats and submits the record to MAS as a message or writes the reformatted record to a file for delivery to an application.
The FTSOUT server is responsible for processing files or messages to customers. An application can use Connec Direct to transfer files to the FTSOUT server. FTSOUT will reformat the file according to the customer specification and leave the file in a specific directory to be downloaded by the customer. An application can also use the messaging infrastructure to send messages to FTSOUT and FTSOUT will treat the message as a file from the application.
The Administrator Graphical User Interface (GUI) provides the management tools for MAS. Through MAS GUI, an administrator is able to monitor the health of the system and to control and manage the system components. It also provides facilities to query the messaging metrics, and the event database.
The administrative server is an interface between the Administrator clients and the messaging infrastructure. This server allows an administrator to start and to stop a system component, to examine the message queues and to move messages from one queue to another queue. Figure 12 depicts a MAS data access model. An Event Log Server, 620 may be responsible for recording all events in a local machine and to upload the events at a regular interval to a common database, 630. Even if the database is not available or slow, the server still writes the events to a local log file as a backup and also to provide a consistent level of performance. The event log server is also programmed to purge the database and the local log files after a defined retention period.
The MAS may further include a database access server, 622. The database server provides a common interface to the database, 630. A MAS process may use this server to access the database. The database amy the MAS events, the sequence numbers, the daily volume counts, the metrics information and the FTS customer profile. The database may be constructed in the manner described above with reference to other embodiments of the present invention. MAS may use DCE security for user authentication. Only users belonging to authorized groups can gain access to MAS services. Following is the convention to enforce DCE security.
The principal who starts a server will have the name defaulted to %host%/%service% where %host% is the machine name and %service% is the service name.
A server principal should belong to the group "MASServers." A human MAS client should belong to the group "MASUsers." A machine MAS client should belong to the group "MASCallers." A MAS service is generally authorized for the groups "MASServers," "MASCallers" and "MASUsers."
In addition to DCE security, MAS servers may also be subject to strict NT security. MAS servers run under an NT account "MAS Services." This account has full permission to access files under the MAS root directory.
Message queue objects are protected by MQ authorization. Only authorized clients can gain access to an MQ object. A special NT group "MQClients" is defined for this purpose. An NT user can access MQ queues if the user belongs to the "MQClients" group. For this reason, the NT "MASServices" account also belongs to the "MQClients" group to allow MAS servers to access MQ queues.
As described above, an embodiment of the system of the present invention may include an administrative interface to allow an administrator (i.e. a human) to monitor, control, manage and investigate the message agent server system. The administrative client may be use ActiveX controls installed as follows. To ensure proper operation of the client program, ActiveX controls need to be installed in the client machine. The following ActiveX OCX files should be included: i. Graph32.OCX ii. Grid32.OCX iii. MSCal.OCX iv. Tabctl32.OCX
The Administrative Graphical Interface (GUI) may utilize the following operational procedures to monitor, control, manage and investigate the MAS system. Preferably the system will be configured so that a product administrator must use a suitable data encryption program, such as Smartgate, and DCE authorization to login to MAS.
After the user is authenticated, the MASGUI program will display a menu screen, Figure 13, from which the administrator can select:
Monitoring for system monitor. Services for service startup and shutdown.
Messages for message handling.
Events for event searching.
Functions for special functions such as changing password and purging status queue. Metrics for message statistics and
FTS for managing the FTS customer profile.
The MAS system may be monitored utilizing a system monitor screen. The system monitor screen, Figure 14, displays the current status of all MAS servers on all machines, the number of messages on application queues, the current sequence number of each Citiswitch link and the daily traffic volume on the link.
When an alert shows up on a system monitor, Figure 15, a product administrator may immediately examine its contents and acknowledge that the alert has been handled. If the alert relates to a bad message, the administrator may extract the message from the error queue and inform the sender about the problem. On the inbound direction from Citiswitch to MAS, the X.25 inbound server will adjust its sequence number to match the expected number from Citiswitch. An alert is generated to alarm the condition but the server still continues to run. On the outbound direction to Citiswitch, the X.25 outbound server will adjust its sequence number to the next higher number or to the next lower number depending on the Citiswitch error code. However, this adjustment is subject to a gap, which is configured to 3, to limit the number of retries. If the sequence gap is larger than this configured parameter, the server will terminate. An administrator should then request
Citiswitch to change its next expected sequence number to synchronize with that of X.25 server. Note that the monitor screen, Figure 16, shows the current sequence number, the next expected number is one higher than the current number. For example, if the monitor screen shows "1234" for the station GWS, an administrator should request Citiswitch to change its sequence number to " 1235."
The administrator may control the message agent server system as follows.
On the administrator GUI, Figure 17, select the services tab, choose the machine and take "All Services" option. Hit the "Stop" button to shutdown all MAS services on that machine. To shut down a single service, an administrator can either select the service form the services tab or double click on an active service in the monitor screen. This will stop a single service. The MASEvtLog service is a critical component that other services depend on. Never shut down the MASEvtLog service.
To start up a service, an administrator can either select the service from the services tab in the GUI or double click on an inactive service in the monitor screen.
This will start a single service.
A system reboot generally will start all service configured on a machine. From the GUI, an administrator can select the services tab, choose the machine and take "All Services" option. Hit the "Start" button to start all MAS services on that machine.
The administrator may manage the message queues as follows.
Message queues may be browsed as follows. On the monitor screen, double click on a queue to start another window. In this window an administrator can select an option to browse, to delete or to move the message. The message text, the message ID and the queuing time as displayed on the window, Figure 18. A message on an application queue can only be moved to the error queue. Error queues may be handled as follows. On the monitor screen, double click on the QL MAS ERROR queue to open another window. Select the browse option to get the first message on the error queue. The reject reason is displayed at the bottom of the message, Figure 19. An administrator should inform the sender why the message was rejected, a note of explanation should be entered before the message can be deleted from the error queue.
The administrator may also perform research and investigations on the functioning of the message agent server.
Event searching may be performed as follows. On the monitor screen, select the events tab to open a new window, Figure 20, in which an administrator can enter parameters for querying the events database. The event and its parameters are fully described in Appendix C:MAS Events. To execute the query in the most efficient way, as many search parameters must be specified as possible, particularly the time span parameter and the severity parameter. Note that the parameters are case sensitive.
The administrator may also perform metrics queuries.
Message volume statistics may be searched as follows. The message volume statistics screen, Figure 21 allows an administrator display the hourly or the daily traffic profile within a certain period for the inbound direction from Citiswitch or the outbound direction Citiswitch. The data can be displayed in the form of a table, a line chart, a two-dimensional chart or a three-dimensional chart. The chart amy also be printed from a printer.
Message Direction: The message direction is relative to MAS system. Inbound means the message flows from Citiswitch to MAS. Outbound means the message flows from MAS to Citiswitch.
Timeline: The message volume statistics can be shown hourly or daily. For example, if you want to see daily message statistics from 05/01/98 to 05/10/98. The time interval 0 starts from 05/01/98 and end at time interval 10 which is 05/10/98. The same idea applies to statistics data shown hourly. Starting Date: The starting date begins from the midnight of your specified date, e.g., 05/05/98 means 05/05/98 00:00:00. Ending Date: The ending date ends at the midnight of the next day of your specified date, e.g., 05/05/98 means 05/05/98 23:59:59.
Failed Messages and Message Delay Statistics may be displayed as failed message statistics, Figure 22, over a certain period categorized by application or by failure reason. The message delay time is the difference between the dequeuing time and the queuing time of a message. The message delay window provides the worst delay time and the delay time of total percentage messages according to normal distribution model. The formula used to calculate the value of the delay time is: P = Mean + (Z-Score * Standard Deviation). Detail of this formula may be found in any statistics book in the chapter of normal distribution.
Downtime statistics may be displayed as the down time statistics of MAS services and their respective components over a certain period of time. The entry is based on host name, service name, and component name (only for external component). The service downtime shows the total downtime of a particular service on a particular host. i.e. If the same service is running in two different hosts, and when they go down, two separate entries will be recorded in the table. The component downtime shows the total downtime of a particular component on a particular host with the same service name.
Advanced message statistics provides the message statistics from different views, Figure 23 : by message types, by BIC codes or by GCN codes.
The administrator may also monitor FTS customer profiles.
The Profile Selection Screen allows for selection of the profiles to view/update, Figure 24.
The "Inbound Profiles" Screen is accessible through the "Inbound Profiles" button on the profile selection screen. The inbound profiles dialog box, Figure 25, displays a list with all inbound profile records in the database. The "Cust. ID," "Pattern #" and "Pattern" fields are displayed, as shown in the sample below. A description of the buttons (and their use) found in this screen is as follows:
New is used to add a new inbound profile record in the database. New Pattern is used to add a new pattern. Delete: is used to remove the selected entry from the database. Multiple entries can be selected use the Ctrl key; a range of contiguous records can be selected with the Shift key.
Details is used to show details about the selected entry. Double clicking on an entry has the same effect. If multiple records are currently selected, then this button is disabled. A sample of the "Inbound profile details" screen is shown below.
Close is used to dismiss the dialog box and return to the previous screen.
The "Inbound Profile Details" Screen dialog box, Figure 26, displays all the fields in the selected inbound profile record: Cust ID is an (up to) 11 -character identification string assigned to this customer. It is a case-sensitive field. A subdirectory having the same name is created off the root of the client directory defined by the environment variable FTS_CLN_ROOT.
Pattern # is a sequence number assigned to each pattern defined for the "Cust
ID" above. The pair (Cust ID, Pattern #) uniquely identifies a pattern for "Cust ID" in the database. Pattern matching with a file name is attempted in the increasing order of "Pattern #": only the first match, if any, is reported.
Pattern is the actual string used for pattern matching with a file name. The only wild characters allowed are '*' (any string, including the empty string), and '?' (any single character). Limited to 64 characters.
Translate id is the numeric identifier of the translation method used to process the records (using MFL calls) in files matching the pattern string above. If this field is
0, then no parsing is performed (passthrough message). This is the only field currently used for message parsing with MFL.
Parse id is the numeric identifier of the parsing method to use to process the records (using MFL calls) in files matching the pattern string. Not used currently. Format id is the numeric identifier of the formatting method to use to process the records (using MFL calls) in files matching the pattern string.
Start record is a special string marking the start of a record in the file. It's used together with the "End record" string below to isolate individual records in the file.
End record is a special string marking the end of a record in the file. It's used together with the "Start record" string above to isolate individual records in the file. Special characters (carriage-return (CR), line-feed (LF)) are entered in a C-like fashion (CR: '\r,' LF: '\n'). Both "Start record" and "End record" strings are limited to 1 1 characters. For example, the '-' character alone on a line will be entered as "- \r\n" in any of these two fields.
Destination specifies the final destination of the record(s) in the file. There are two mutually exclusive options, displayed as radio buttons:
File: the records are assembled in a file that is placed in the directory specified in the "Dest. directory" field (limited to 255 characters). The string in the "Dest. extension" field (at most 3 characters), if not empty, is appended to the file name before placing it in the directory.
MAS: the records in the file are queued up to MAS for delivery to the final destination. The target application ID is specified in the "Dest. id" field. It is either a numeric identifier (a single digit) or a 5-character string. Each record in the file is sent as a single MAS message.
Several actions are available, identified by the buttons on the right-hand side: Previous Pattern is used to display details about the previous record (in the "Pattern #" order) of "Cust. ID" in the database. An error message is displayed if there is no previous record to display. Next Pattern is used to display details about the next record (in the "Pattern #" order) of "Cust. ID" in the database. An error message is displayed if there is no next record to display.
Insert is used to add a new record to the database. It is enabled only if any of the "Cust. ID" and "Pattern #" fields is modified.
Update is used to save the changes in the current record to the database. It is enabled if any field but "Cust. ID" and "Pattern #" is modified.
Delete is used to remove the current record from the database (and from the list in the "Inbound profiles" screen). This action dismisses the dialog box and returns to the "Inbound profiles" screen.
Exit is used to leave the dialog box without saving any changes. Control is passed to the "Inbound profiles" dialog box.
The foregoing administrative functions are provided by way of example. Additional administrative functions may be incorporated into the message agent server depending of the needs of the computing environment.
As discussed above, the present invention also provides a message format library which may be separate from the message agent server.
According to the present invention a message format library may include one or more of the following functions: means for parsing messages; means for translating messages; and means for validating message formats. The means for validating may utilize the means for parsing such that the message is divided into its components by the means for parsing so the means for validating reads the components and compares them to a database of allowed components. In similar fashion the means for translating may utilize the means for parsing such that the message is divided into its components by the means for parsing so the means for translating may translate the components into a different forma based upon a database of acceptable different format components. By way of example, the means for parsing may derive a destination address within a message and/or a source address within a message. The translating means may translate messages in a first format into a second format and translate messages in the second format into the first format.
In another aspect the present invention provides a message format library comprising: means for parsing messages; means for formatting messages into defined message formats; means for translating messages from one message format to another message format. The capabilities of the message format library are provided through a set of application programming interfaces which are accesible to applications as a static library or dynamic link library. In a preferred embodiment, the message format library further comprises a user interface in GUI (graphical user interface) format which prompts a user to enter message data. The user interface may also be part of the static library or dynamic link library. The message format library is particularly advantageous for parsing, formatting and translating structured financial messages, including SWIFT messages, ISITC messages, fixed-length and comma/tab-delimited messages; and messages needing to be formatted as structured financial messages.
Figure 27 provides a graphic overview of an embodiment of a message format library of the present invention. As shown in Figure 27, a message format library 500 may receive and send messages from application programs or networks 502. The message formal library will support a variety of different message types, such as the message types represented in the type library 504. The messages may be broken down into components and fields such as those represented in the translation, matching and reconciliation engine 506. The message format library will have access to databases 508 including message format and business logic data.
An embodiment of a message format library of the present invention is decribed in detail below. Additional embodiments may be constructed in similar fashion.
The message format library, or MFL, preferably uses Norm Chomsky's regular expression to represent message formats. Messages are broken into components and sub-components and their regular expression representations are stored in a relational database. The format of a certain message type is retrieved from the MFL database to build a finite automation, which is used to parse and format messages of that particular message type. After a message is parsed, it can then be translated to another message (or messages) of a different message type (or different message types). These functionalities are abstracted into a set of application programming interfaces (APIs) wrapped in a static C library and a dynamic linked library (DLL). These libraries and the MFL format database (the meta-data) constitute the Message Format Library.
The MFL C interface is implemented both as a static library and a dynamic link library. The following interface functions are provided in both.
MessageParse accepts a formatted message and parses it into its constituent fields and variables;
MessageHeaderParse accepts a formatted message and parses only its header;
MessageFormat accepts a list of fields and variables and formats a message;
MessageHeaderFormat creates a formatted message header;
MessageTranslateOneToOne translate one input message into another message according to a set of translation criteria;
MessageTranslateOneToMany translate one input message into an array of output messages;
MakeCommonReference creates field 22 (Common Reference) in a SWIFT message;
GetMFLErrors retrieves errors generated by any of the above function. LoadMessage Pre-load message formatting information for a specific message type from database to avoid spontaneous loading. This function improves run-time performance.
LoadMessageGroup Pre-load messages formatting information for a group of message types from database.
LoadMatch Pre-load match rules from database (include translation rules).
These functions are specific to the DLL:
FreeMFLString frees a character string returned by a MFL DLL function call;
FreeMFLStringArray frees a character string array returned by a MFL DLL function call;
FreeMFLInt Array frees an integer array returned by a MFL DLL function call.
The Message Format Library is available both as a static library and a dynamic link library. If you are using the library in the Windows environment, it's recommended that you use the DLL instead of the static library.
The header include file for both the DLL and the static library is named mfl.h. The 32-bit DLL using ODBC database access is called mflacc.dll and the 16-bit DLL mflaccl6.dll. The 32-bit DLL using Sybase dblib data access is called mflsyb.dll. There is no 16-bit DLL using Sybase. The import libraries for the 32-bit DLL are mflacc.lib and mflsyb.lib, respectively.
When implemented on a Windows NT platform the file userpass.txt contains information needed to access the MFL database (including database server name, database name, application name, and encrypted username and password). An environment variable MFLDBDIR has to be defined for the path of the file. For example, if MFLDBDIR=C:\MFL\MBD, then the file userpass.txt should be in the directory C:\MFL\MDB. The default userpass.txt that comes with the library is readily usable in most cases. However, this file may be changed with the program mflencpt.exe as follows: mflencpt server_name db_name app name user name password output file Use the data source name in place of the server name if ODBC is used to access MFL database. Notice that the output file has to be "userpass.txt" to work with this version of the format library.
MFL functions may be made available on a VAX platform as a static library. The userpass.txt file is not necessary on VAX. However, a user needs to setup your environment variables correctly by logging on to the ITS environment with the following command:
@itscom:its_login admin mas
A user may also need to set the environment variable USER to be MAS_TST.
This MFL interface functions are described in detail below with reference to SWIFT messages. The Appld is used to indicate a particular application of certain message types.
Each AppID corresponds to a unique header format.
The enum MsgType can be one of the following: SWIFT; SWIFT SORT; REPORT.
The value SWIFT is usually used for this version of the DLL. If SWIFT_SORT is passed in a formatting function, MFL performs limited field sorting ~ it sorts fields in non-repeatable blocks. Fields can be passed in random order except that the fields in repeatable blocks have to follow their order in their corresponding blocks. Empty string in an output variable indicates that this optional variable is missing.
For any SWIFT message, the order of elements in the parameter variables depends upon whether the message is tagged incoming or outgoing. Any message sent to SWIFT should contain I as the first letter after the colon in the block 2 of the message, whereas any message coming from SWIFT will contain O as the first letter,
12 characters, with the 9th character set to X. Note that incoming and outgoing is relative to SWIFT network, not the application processing the message.
Figure imgf000087_0001
A list of variable for outgoing messages is shown below.
Figure imgf000087_0002
* SWIFT address differs from the 11 character ISO BIC code and branch code by an additional logical terminal code, which should be inserted in the 9th position of the BIC code. The logical terminal code for all messages sent to SWIFT should be X, i.e., for all messages tagged I in block 2, the 9th character of the SWIFT address should be X. Note also that the sender and receiver addresses are reversed for incoming and outgoing messages.
** To format a message with 'O' tag in block 2, variables 3, 4, 9, and 10 must be passed in.
Whenever an MFL function succeeds, it returns a positive value. Otherwise, it returns a negative value, which is the reference number for the errors encountered in the call. An application can call GetMFLErrors to retrieve these errors. When a failure occurs, the parsing functions will look for the next good field and resume parsing while registering an error. The formatting and translation functions work in this best-effort fashion as well.
All MFL functions allocate space needed for the returned parameters. Therefore, it's not necessary for the calling program to allocate memory for the parameters beforehand. However, to prevent memory leaks, the program should free parameters returned by MFL functions at suitable times.
The MFL may include the following parsing functions. MessageParsef); MasMsgParse(); MessageHeaderParse()
The MessageParse() specifications may be as follows: long MessageParse (
[in] int Aid, [in] enum MsgType, [in] char* MessageText,
[out] int* Msgld, [out] char*** variables, [out] char* FieldCount, [out] int** FieldNumber, [out] char** FormatTag,
[out] char***FieldCaption, [out] char***FieldContent) The MasMsgParse() specifications (RPC version of parsing interface) may be as follows: long MasMsgParse ( [in] char* Aid,
[in] char* MessageText, [out] char** Msgld, [out] char** FromBic, [out] char** ToBic, [out] char** GenTime,
[out] char** RecvTime, [out] char** Priority, [out] char** MUR, [out] char*** FieldNumber, [out] char***FormatTag,
[out] char***FieldCaption, [out] char***FieldContent) The MessageHeaderParse() specifications may be as follows: long MessageHeader Parse ( [in] int Aid,
[in] enum MsgType, [in] char* MessageText, [out] int* Msgld, [out] char*** variables) MessageParse() take a formatted swift message as input, and breaks it apart into the header variables and message body field tags and values. It returns an error status if it is unable to parse the data correctly.
The fields are loaded into arrays FieldNumber, FormatTag, and FieldContent, with the number of fields placed into FieldCount. MessageHeaderParse() takes a formatted SWIFT or CITIDEX message as input, and parses only the header of the message, returning the values Msgld, FromBic, ToBic, GenTime, RecvTime, Priority, MUR as a character string array in the parameter variables.
The MFL may perform the following formatting functions: MessageFormat(); MasMsgFormatO; and MessageHeaderFormat(). The MessageFormatO specifications may be as follows: long MessageFormat (
[in] int Aid,
[in] enum MsgType, [in] int Msgld, [in] char** variables, [in] int FieldCount, [in] int* FieldNumber, [in] char* FormatTag, [in] char** FieldContent, [out] int* txt_length; [out] char** MessageText)
The MasMsgFormatO specifications (RPC version of formatting interface) may be as follows: long MasMsgFormat (
[in] char* Aid,
[in] char* Msgld,
[in] char* FromBic,
[in] char* ToBic,
[in] char* priority,
[in] char* MUR,
[in] char* FieldNumber,
[in] char** FormatTag,
[in] char** FieldContent,
[out] char** MessageText) The MessageHeaderFormat() specifications may be as follows: long MessageHeaderFormat ( [in] int Aid, [in] enum MsgType,
[in] int Msgld, [in] char** variables, [out] int* txt length; [out] char** MessageText) MessageFormat() re used to validate and construct a swift message. All formatting checks are performed here. The function checks for mandatory fields, and verifies the values of all of the fields, including size. If an error is detected in formatting, the return value of the function is the Error Reference number that can be used to find the text errors corresponding to this message with a call to GetErrors(). The first parameter, Aid specifies the application Id that is requesting the function, and Msgld specifies the message id of the SWIFT message. The value of MsgType for all current messages should be SWIFT. The next string array, variables, should contain the values FromBic, ToBic, Priority, and MUR in that order.
The three arrays of string are the specific fields of the SWIFT message. FieldNumber and FormatTag together form the field tag (i.e.. 71a). The corresponding array position in FieldContent is the value of that field. MessageText is the returned formatted Swift message including header, trailer and fields. FieldCount contains the number of fields that are passed into the routine.
MessageHeaderFormatO takes the parameters Aid, Msgld, MsgType, and variables as input, and returns the formatted message in the parameter MessageText.
In addition the MFL may include a MakeCommonReference() function. The MakeCommonReferenceO specifications may be as follows: long MakeCommonReference ( [in] char* Aid, [in] char* fromBic,
[in] char* toBic, [in] char* price, [out] char** commonRef) MakeCommonReference() function takes the parameters application id, fromBic, toBic, and the value of field 36, and builds the common reference field according to SWIFT specifications. The returned value, commonRef, should be used as the value of field 22 (22C) in a subsequent call to MessageFormat (or MasFormat).
Translation functions provided by the MFL include the following: MessageTranslateOneToOne(); and MessageTranslateOneToMany(). The MessageTranslateOneToOne() specification may be as follows: long MessageTranslateOneToOne ( int tid, char **variables, char *from Text, char ** to Text) The MessageTranslateOneToMany() specification may be as follows: long MessageTranslateOneToMany ( int tid, char ** variables, char *fromText, char ***toText, int * successCount, int * failureCount) Both MessageTranslateOneToOne and MessageTranslateOneToMany load a set of translation criteria defined in the MAS MATCH table and use them to translate a message (from Text) into another message or any array of messages (toText). The parameter variables, an array of strings, also may be used to specify values of parameters defined for the output text. If you do not wish to specify any parameters, simply pass in NULL.
In addition to toText, MessageTranslateOneToMany also returns the number of output messages generated in successCount. Correctly formatted messages are saved in the string array toText. MessageTranslateOneToMany will return the number of successCount if the failureCount is 0. If the failureCount is greater than 0, the function will return an error reference number. Note that even if the function returned an error reference, some of the block may have been formatted correctly. The application should decide on the appropriate error handling strategy in this case. The translation process may include the following three steps: 1. Parse the source message into an array of fields and an array of variables;
2. Translate these two arrays into another couple of field array and variable array;
3. Use the new array of fields and the new array of variables to format the target message(s).
Both the source message format and the target message format have to be defined in the MFL meta-data, i.e., the messages that can be translated from and into are those whose formats are defined in the MFL meta-data.
For example, a SWIFT MT571 message can be a source or target message because MT571 format is defined in MFL meta-data.
A comma-delimited message format may be defined "(AccountID, SecuritylD, ValueDate, Quantity, Price, CrossCurrency)" in MFL meta-data, then a message in this format can be a source or a target message in a MFL translation function. MFL translation functions support these translation capabilities: Structural field and variable mapping, e.g., from MT571 field 35H to field Quantity. Any field or variable defined in the source message format can be mapped to any field or variable defined in the target message format. One field in a source message can be translated into many fields in the target message and vice- versa. Value transformation, e.g., from "USD" in a MT571 field 33B to "1" for field CrossCurrency. Value transformation can make use of mapping tables provided by applications and stored in MFL database.
Both structural field and variable mapping and value transformation can be conditional. Target fields and variables can get different values based on contents, existence, or absence of source fields and variables. Default values can be stored in the target message(s) if it is not composed from the source message. Operations that can be performed on numeric data include quality test, inequality tests, and range test. Operations that can be performed on string data include variable-length sub-string extraction and comparison, acronym extraction and comparison, and word reordering. More sophisticated operations on numeric and string data can be performed by calling exit functions.
Translation rule definitions may be established as follows. Each mapping in a translation is defined as a translation rule in MFL metadata. A group of these rules constitute a full translation. Each group of translation rules is identified by a translation id. Translation rules are stored in the table MAS MATCH.
For example, there may be a rule in MAS_MATCH defined for certain source and target message types that looks like this: {n6 1 } :\2\0{n6<!=l>} . When processing this particular rule, the MFL translation function does the following: validate that the source field or variable is a six-digit number; make the first two characters of the target field or variable "20" and then append whatever from the source field or variable at the end. This is actually a rule to translate a date with a two- digit year to the same date with the four-digit year. To make this correct, there is a condition linked to this rule that says "Apply this rule only if the number interpreted from the first two digit of the source field or variable is between 00 and 49." There is, of course, another rule which insert the number "19" in front of the original date if this condition is no satisfied.
The MFL may further include the following pre-loading functions: LoadMessage(); LoadMessageGroupO and LoadMatchO-
The LoadMessage() specifications may be as follows: int LoadMessage (
[in] int Aid, [in] int Msgld) The LoadMessageGroupO specifications may be as follows: int LoadMessageGroup ( [in] int Aid) The LoadMatch() specifications may be as follows: int MasMsgFormat (
[in] int Matchid) LoadMessage(), LoadMessageGroupO, and LoadMatch() are used to pre-load message format information from database at application initialization phase. It avoids loading format information when processing message (load-on-demand). Preloading technique improves system run-time performance.
LoadMessage(), LoadMessageGroupO, and LoadMatch() are backward compatible. MFL functions can still load format information whenever necessary. The first parameter, Aid, specifies the application Id, and Msgld specifies the message id of the SWIFT message. The Matchid is the ID in the MAS MATCH table. The return error code can be used to call GetMFLErrors().
In addition, the MFL may include a GetMFLErrors() error functions. The GetMFLErrors() specifications may be as follows: long GetMFLErrors (
[in] long ErrorReference [out] char***ErrorDetail) If the parse or format functions return an error value, the number returned is the ErrorReference number. When this number, multiplied by -1, is passed into GetMFLErrors(), MFL looks up the number and returns an array of strings that describes the errors that were encountered in the original call.
Preferably the MFL further includes dynamic link library (DLL) functions such as the following:
FreeMFLStringO; FreeMFL String Array (); and
FreeMFLInt ArrayO . The FreeMFLStringO specification may be as follows: Dlllmport long FreeMFL String ( char* str); The FreeMFL String ArrayO specification may be as follows:
Dlllmport long FreeMFL String Array ( char** sarray, int count); The FreeMFLIntArrayO specification may be as follows: Dlllmport long FreeMFLIntArray ( int* iarray, int count);
FreeMFLStringO frees a single string allocated by the DLL. FreeMFLStringArrayO (FreeMFLIntArrayO, respectively) frees an array of strings (integers) allocated by the DLL (count is the number of elements of the array). The MFL uses regular expressions extensively in meta-data definition, message parsing, formatting and translation. Preferably the regular expressions follow the following rules.
Any literal character is prefixed with escape symbol '\.' 'a' represents any character which can be used in a field, including alphanumeric characters and others, but cannot be any of these five characters: \n - : } \0.
'c' represents alphabetic characters, namely A-Z or a-z. 'n' represents any digit (0-9), space, '-,' or ',.' 'd' represents any digit, namely, 0-9. V represents new line. Capital letters A, B, C, D, E, F, G, and H are used for standard SWIFT formats on these format options.
<code_table_name> means any value from the table, <code_table_name length> includes the length of the string when the string length is fixed. '(',')' are used to group items into one item. '['»']' group one or a number of items into an optional item.
' I ' means "or."
Prefixing a number repeats the item by up to as many times. Prefixing a number then 'x' repeats the item on up to as many lines. '*,' instead of a number, represents arbitrary number. '+,' instead of a number, represents arbitrary positive number.
Suffixing a number means exact number. Suffixing 'x' then a number means exact as many lines. Do not apply number, '*' or '+' on optional sub-expression, 'r,' < o > or literal string to express repetition. The following table provides examples of basic elements.
Figure imgf000097_0001
The regular expression uses capital letters A through H to represent standard SWIFT formats as listed in the following table.
Figure imgf000097_0002
The MFL applies these shortcut letters only at the beginning of each regular expression format in database. So an RE like this: "C20d," will be translated to "V34a20d" before being used to parse the incoming messages. MFL format library functions follow these steps to parse and to format messages:
Retrieve all format information for the message from the database.
Build a finite automation (simplified as a tree representation) based on the format information.
Use this finite automation to parse and to format the message.
Each regular expression has its value type. The table below provides a list of legal value types. These value flags reflect to the rules somewhat.
Figure imgf000098_0001
Examples of regular expression (RE) and their corresponding tree are described below and in Figures 28-31.
Concatenation is denoted by Intermediate node, whereas alternative is denoted by Or node,e.g., RE = "SI S2 | S3 S4 | S5 | S6 S7 S8" where Sn are single element sub-expressions. A tree built on this expression is depicted in Figure 28. The tree depicted in Figure 28 shows that concatenation takes precedence over alternative, and alternative is right associated. So the preceding RE is interpreted as: (SI S2) | ((S3
S4) I (S5 I (S6 S7 S8))).
The following sections describe various types of single element RE's and their corresponding trees. A Parentheses pair is denoted by Intermediate node, e.g., RE = "SO (SI | S2) S3," where Sn are single element sub-expressions. The tree built on this expression is shown in Figure 29.
An Option pair is denoted by om_flag on the node, which represents the optional part, e.g., RE = "SO [SI | S2] S3," where Sn are single element subexpressions. The tree built on this is shown in Figure 30. The om_flag on the middle Or node is set to 'O,' which means optional.
Variable assignment on any part of the RE is denoted by var_map_type, varjnum, and var scope on the node representing the assigned part, e.g., RE = "SO {S1S2 num} S3," where Sn are single element sub-expressions. The tree built on this expression is shown in Figure 31.
The flags on the middle intermediate node (not root I node) is set to following values for different types of variable assignment. If there is no optional part "<!=name_," only var um is set. { S1S2 [<!= [_]] num } var_num = num. var_map_type = 'E,' var scope = '_' ?
1 : 0
{ S1S2 [<!, [_]} num } var num = num. var_map_type = 'D,' var scope = '_' ? 1 : 0
{ S1S2 [Xlname [_]] num} var_num = num, var_map_type = 'T,' tab_map.name = name, var_scope = '_' ? 1 : 0
Any structured message can be represented in the MFL format database. Currently, most formats are related to SWIFT I or II, or SWIFT messages wrapped by GRN envelope.
MFL format database, which is referred to as meta-data, may include tables. In the embodiment described herein there are 21 tables in the MFL format database.
MAS SYSTEM is for database version information. The other 20 tables are described below. Information on supported versions:
MAS_MSG_VERSIONS message_version integer, version_name char(32), version date datetime, effective date datetime, flags char(16), message_format varchar(255), message_formatl varchar(255), comments text
Version number is assigned by MFL for different versions of SWIFT messages. It can be utilized for other purposes. For instance, different formats, such as CHIPS or
FedWire, can be considered as versions in the database. Version date is the official date when it is adopted as standard. The effective date is the date when it is adopted in CrossMar applications. See the next section for a list of some message versions currently in the MFL format database.
Each message consists of an envelope and a message body. In the version format for any given message, "«BODY»" denotes the body of the message and everything else is the envelope of the message.
A list of defined variables
MAS_MSG_VARIABLES message version integer, var_number integer, var name varchar(32), comments varchar(255)
This table lists all variables defined in the envelope and body of each message version.
A list of supported messages:
MAS_MESSAGES message version integer, message_number integer, message name char(32), enforce order char(l) value in (%' 'N') default 'Y, comments text
For SWIFT messages, message numbers are the same as assigned by SWIFT. For example, the message number of SWIFT MT100 is 100. When enforce_order is 'Y, the fields in a message body have to be in their positions defined in MAS_GEN_FORMAT and MASJB GEN FORMAT (see below. General message format:
MAS_GEN_FORMAT message_version integer, message number integer, position integer, id integer, name char(32), format_flag char(l), field_block char(l) value in ('B,' 'F') default 'F,'
M_O char(l) value in ('M,"O'), repeat integer default 1 , comments text
Position is an index. It is useful for mutually exclusive fields: when two fields share one index, only one can be present. Block means a collection of fields. When field block field is of value 'B,' the record represents a block. Repeat means that this field can repeat up to as many times (0 means arbitrary times). Field id and format flag correspond to the tag number in SWIFT specifications.
A list of blocks:
MAS GEN BLOCK block id integer, block name char(32), enforce order char(l), comments text
Block number is assigned in sequence. It is preferably unique across board.
General block format:
MAS B GEN FORMAT block_id integer, position integer, id integer, name varchar(32), format_flag char(l), field block char(l),
M O char(l) value in ('M: 'O'), repeat integer default 1 , comments varchar(255)
Same as MAS GEN FORMAT except that everything is for blocks. Application specific information:
MAS APPLICATION app id int, message_version int, sample_flag char(l), app_date datetime, effective_date datetime, comments text
This is a list of mapping from application id's to version numbers.
MAS MESSAGE TITLE message_number integer(4), app id integer(3), message version integer(3), caption char(64), comments text
MAS_BLOCK TITLE blockjd integer(4). app id integer(3): caption char(64), comments text
Field formats for all fields not in any block:
MAS_APP_FIELD message_number integer(4), field number integer(3), app id integer(3), format flag char(l), position integer, subfield exist char(l) value in ('Y,"N'), field_format char(128),
M O char(l) value in ('M,"O'), caption char(64), read_only char(l) value in ('R,' 'A') default 'A,' app flags char(3), indx_field char(l), comments text
Field formats for all block fields: MAS_B_APP_FIELD block_number integer(4), field_number integer(3), app_id integer(3), format_flag char(l), position integer, field_format char(128),
M_O char(l) value in ('M,"O'), caption char(64), code table char(32), read only char(l) value in ('R,' 'A') default 'A,' disp_pref char(l)
Formats for subfields in a non-block fields:
MAS APP SUBFIELD message number integer(4), field_number integer(3), app_id integer(3), format flag char(l), subfield tag char(16), field_format char(128), M O char(l) value in ('M,' 'O'), caption char(64), read only char(l) value in ('R,' 'A') default 'A,' app flags char(3), comments text
Formats for subfields in a block field:
MAS_B_APP_ SUBFIELD block number int, field_number int, app id int, format_flag char(l), subfield_tag varchar(16), field format varchar(128),
M_O char(l), caption varchar(64), read_only char(l), app_flags char(3), comments text A list of all codes used in MFL format database:
MAS_CODE_TABLES table_name varchar(32), code varchar(16), description varchar(64), comments varchar(128)
A list of combined or base rule clause identifiers for cross-field validation rules and translation related rules:
MAS_RULE app id int not null, message_number int not null, condition 1 int not null, condition2 int not null, err code varchar(8) not null, comments varchar(255) null
A list of binary combinations of base rule clauses:
MAS RULE COMBINE clause ref int not null, operator char(l) not null, component 1 int not null, component2 int not null
A list of base rule clauses:
MAS RULE CLAUSE clause ref int not null, block id int not null, field block char(l) not null, field number int not null, format flag char(l) null, position int not null, operator char(l) not null, reg exp varchar(128) null, comments varchar(255) null
A list of translation and matching identifiers and their applications: MAS MATCH TITLE match_id int not null, matchjname varchar(32) not null, match_type char(l) not null, app_idl int not null, message blockl char(l) not null, message_idl int not null, app_id2 int not null, message_block2 char(l) not null, message_id2 int not null, condition int not null, threshold float not null, comments varchar(255) null
A list of all the translation and matching rules:
MAS MATCH match id int not null, field_varl char(l) not null, field_numberl int not null, format_flagl char(l) null, position 1 int not null, condition 1 int not null, match operator char(l) not null, match rule varchar(255) null, field_var2 char(l) not null, field_number2 int not null, format_flag2 char(l) null, position2 int not null, condition2 int not null, weight float not null, comments varchar(255) null
A list of all mapping tables used in translation and matching:
MAS_MATCH_TABLES table_name varchar(32) not null, from code varchar(32) not null, to code varchar(32) not null, comments varchar(128) null
The foregoing tables are utilized by the message format library in the translation, parsing, formatting, reconciliation and validating of messages. As described in detail above, the message format library may be incorporated with the architecture of the system of the present invention in different ways. The message format library may be linked as a local function call to application programs utilizing the system. Alternatively, the message format library may be linked as a remote function call be present on the message agent server. It should also be understood that the message format library of the present invention is a distinct and separate invention which is capable of operating independently of the message agent server described herein.
Embodiments of the present invention have been described above to illustrate the features and advantages of the present invention. It will be appreciated that these examples are merely illustrative of the invention. Variations and modifications will be apparent to those skilled in the art.

Claims

Claims L A method for transferring electronic messages in a network, the network including a message agent server, a first terminal for communicating electronic messages in a first format, and a secure network, the secure network further connectable to at least a second terminal for communicating electronic messages in a secure network format, comprising: generating an electronic message at the first terminal in the first format; transmitting the electronic message from the first terminal to the message agent server; the message agent server automatically translating the electronic message from the first format to the secure network format; and transmitting the translated electronic message from the message agent server to the second terminal.
2. The method of claim 1 further comprising: generating a second electronic message at the second terminal in the secure network format; transmitting the electronic message from the second terminal via the secure network to the message agent server; the message agent server automatically translating the electronic message from the secure network format to the first format; and transmitting the translated second message from the message agent server to the first terminal.
3. The method of claim 1 wherein the first terminal comprises a computer.
4. The method of claim 1 wherein the server comprises a computer.
5. The method of claim 1 wherein the second terminal comprises a computer.
6. The method of claim 3 wherein the computer is a personal computer.
7. The method of claim 1 wherein generating the electronic message at the first terminal in the first format further comprises using a software application such that the first format includes data formatted using the software application.
8. The method of claim 1 wherein the secure network comprises a financial network.
9. The method of claim 1 wherein the secure network format is a SWIFT compatible format.
10. The method of claim 1 wherein the first message includes a plurality of first message elements and the translated electronic message includes a plurality of secure network message elements, further comprising the message agent server automatically parsing the message, such that the plurality of message elements correspond to the plurality of secure network message elements.
11. The method of claim 1 further comprising validating the electronic message.
12. The method of claim 1 further comprising validating the translated electronic message.
13. The method of claim 1 wherein the second terminal is disconnectable from the secure network and wherein transmitting the translated electronic message further comprises connecting the second terminal to the secure network, the server automatically storing the translated message; the server automatically transmitting an alert message to the second terminal; and the second terminal retrieving the translated message.
14. A method for transferring electronic messages between a first terminal, a message agent server and a first network comprising; generating an electronic message addressed to the first network on the first terminal; sending the message from the first terminal to the message agent server; interpreting the message so as to determine the address of the electronic message; routing the message to the first network from the message agent server.
15. The method of transferring electronic messages of claim 14 further comprising: queuing the electronic message in the message agent server before it is routed to the first network.
16. The method of transferring electronic messages of claim 15 wherein the step of routing is delayed until the first network comes on-line such that the message will remain queued until the first network comes on-line.
17. A system for transferring electronic messages in a network, the network including a message agent server, a first terminal for communicating electronic messages in a first format, and a secure network, the secure network further connectable to at least a second terminal for communicating electronic messages in a secure network format, comprising: means for generating an electronic message at the first terminal in the first format; means for transmitting the electronic message from the first terminal to the message agent server; means for automatically translating the electronic message from the first format to the secure network format; and means for transmitting the translated electronic message from the message agent server to the second terminal.
18. A system for transferring messages comprising: a message agent server comprised of; at least one queue; a processor which is used to at least determine the destination address of one of the messages; and a plurality of communications links used to carry the messages; a first terminal; a first network coupling the first terminal to a first subplurality of communications links; a second network coupled to a second subplurality of communications links.
19. The system of claim 18 where the first terminal holds one of a plurality of application programs.
20. The system of claim 19 where one of the plurality of application programs is a securities exchange program.
21. The system of claim 18 where the second network is a world-wide network used to transfer financial messages.
22. The system of claim 18 where the first terminal is a server.
23. The system of claim 18 where the queue is used to store and transfer messages in a particular order destined for the first terminal.
24. The system of claim 18 where the queue is used to store and transfer messages in a particular order destined for the second network.
25. The system of claim 18 where the message agent server utilizes an MQ application which is used to control the message transfer to and from the first terminal.
26. A message agent server used for transferring messages between a first terminal and a network comprising; communications links coupling the message agent server to the first terminal and the network; a processor; a buffer for temporarily holding a message received via the communications links; wherein the processor operates under the control of an interpreting procedure so the processor determines the destination address of the message while the message is in the buffer; a first queue associated with the first terminal; a second queue associated with the network; where the message is transferred from the buffer to the appropriate queue based on the determination made by the processor under the control of the interpreting procedure.
27. A system comprising a message agent server coupled to a first network, the network including a first terminal, and coupled to a second network where the second network includes at least one terminal where the system is further comprised of; communications links coupling the message agent server to the first network and coupling the message agent server to the second network; where the message agent server is further comprised of a processor; message receiving means for receiving messages transmitted to the message agent server from the first and second networks via the communications links; means for interpreting the received messages which includes reading the address of the destination of the message; queuing means for storing the received messages and for forwarding the messages to the communications links when told to do so; routing means for routing the messages to the appropriate destination based upon the determination of the means for interpreting.
28. The system of claim 27 wherein the means for interpreting the message includes means for validating the message format.
29. The system of claim 28 wherein the means for interpreting the message further comprise means for translating the message from a message format to a second message format.
30. The system of claim 29 wherein the means for translating comprise a message format library.
31. The system of claim 27 wherein the queuing means comprise a database.
32. The system of claim 31 wherein the queuing means further comprise at least one of the message archive, retrieval, and re-transmission capabilities.
33. The system of claim 27 further comprising means for monitoring message traffic and message agent server performance by an administrator.
34. A method for transferring electronic messages among a plurality of participants wherein the participants include a first terminal and a first network and the method uses a message agent server where the method comprises: preparing an electronic message on the first terminal addressed to the first network; sending the message to the message agent server; interpreting the message to determine at least the message addressee; storing the message in a message queue assigned to the message addressee; triggering the first network to connect to the message agent server; routing the message to the remote network after the remote network connects to the message agent server.
35. The method of claim 34 wherein interpreting the message further comprises validating the format of the message.
36. The method of claim 34 further comprising monitoring message traffic.
37. A message format library comprising: means for parsing messages; means for translating messages; and means for validating message formats.
38. The message format library of claim 37 wherein the means for validating uses the means for parsing such that the message is divided into its components by the means for parsing so the means for validating reads the components and compares them to a database of allowed components.
39. The message format library of claim 37 wherein the means for translating uses the means for parsing such that the message is divided into its components by the means for parsing so the means for translating may translate the components into a different forma based upon a database of acceptable different format components.
40. The message format library of claim 37 wherein a destination address within a message is derived by the means for parsing.
41. The message format library of claim 37 wherein a source address within a message is derived by the means for parsing.
42. The message format library of claim 37 wherein the means for translating messages translates messages in a first format into a second format and translates messages in the second format into the first format.
PCT/US1998/010930 1997-06-05 1998-06-05 Translation of messages to and from secure swift format WO1998056024A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU80545/98A AU8054598A (en) 1997-06-05 1998-06-05 Translation of messages to and from secure swift format

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5042297P 1997-06-05 1997-06-05
US60/050,422 1997-06-05

Publications (1)

Publication Number Publication Date
WO1998056024A1 true WO1998056024A1 (en) 1998-12-10

Family

ID=21965168

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/010930 WO1998056024A1 (en) 1997-06-05 1998-06-05 Translation of messages to and from secure swift format

Country Status (2)

Country Link
AU (1) AU8054598A (en)
WO (1) WO1998056024A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095135A2 (en) * 2000-06-05 2001-12-13 Contivo, Inc. Method and apparatus for automatically converting the format of an electronic message
EP1179793A1 (en) * 2000-08-09 2002-02-13 Indatex GmbH Portal for providers of financial services
EP1209572A1 (en) * 2000-03-29 2002-05-29 Seiko Epson Corporation Network security system
EP1214824A2 (en) * 1999-08-31 2002-06-19 Accenture LLP A system, method for fixed format stream communication in a communication services patterns environment
EP1421532A2 (en) * 2001-07-30 2004-05-26 Electronic Broking Services Limited Conversational dealing system
WO2005031571A1 (en) * 2003-09-29 2005-04-07 Sap Aktiengesellschaft Automatic registration and deregistration of message queues
WO2008031987A1 (en) * 2006-09-12 2008-03-20 France Telecom System comprising an electronic money chain, method implementing this system, web service and web services server
US7568222B2 (en) 2000-05-25 2009-07-28 Randle William M Standardized transmission and exchange of data with security and non-repudiation functions
US8468087B2 (en) 2004-10-28 2013-06-18 Depository Trust & Clearing Corporation Methods and systems for netting of payments and collateral
CN112596734A (en) * 2020-12-15 2021-04-02 五八同城信息技术有限公司 Static library generation method and device
US11025575B2 (en) 2018-06-12 2021-06-01 Oracle Financial Services Software Limited Message recognition system and method configurable to define new message formats

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5424938A (en) * 1992-10-13 1995-06-13 First Chicago Corporation Method and apparatus for providing access to a plurality of payment networks
US5710889A (en) * 1995-02-22 1998-01-20 Citibank, N.A. Interface device for electronically integrating global financial services
US5787402A (en) * 1996-05-15 1998-07-28 Crossmar, Inc. Method and system for performing automated financial transactions involving foreign currencies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5424938A (en) * 1992-10-13 1995-06-13 First Chicago Corporation Method and apparatus for providing access to a plurality of payment networks
US5710889A (en) * 1995-02-22 1998-01-20 Citibank, N.A. Interface device for electronically integrating global financial services
US5787402A (en) * 1996-05-15 1998-07-28 Crossmar, Inc. Method and system for performing automated financial transactions involving foreign currencies

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
STALLINGS W: "DATA AND COMPUTER COMMUNICATIONS", DATA AND COMPUTER COMMUNICATIONS, XX, XX, 1 January 1994 (1994-01-01), XX, pages 170/171 + 133 - 138, XP002913133 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1214824A2 (en) * 1999-08-31 2002-06-19 Accenture LLP A system, method for fixed format stream communication in a communication services patterns environment
EP1209572A4 (en) * 2000-03-29 2005-07-06 Seiko Epson Corp Network security system
EP1209572A1 (en) * 2000-03-29 2002-05-29 Seiko Epson Corporation Network security system
US7568222B2 (en) 2000-05-25 2009-07-28 Randle William M Standardized transmission and exchange of data with security and non-repudiation functions
US6757739B1 (en) 2000-06-05 2004-06-29 Contivo, Inc. Method and apparatus for automatically converting the format of an electronic message
WO2001095135A2 (en) * 2000-06-05 2001-12-13 Contivo, Inc. Method and apparatus for automatically converting the format of an electronic message
WO2001095135A3 (en) * 2000-06-05 2002-09-06 Contivo Inc Method and apparatus for automatically converting the format of an electronic message
EP1179793A1 (en) * 2000-08-09 2002-02-13 Indatex GmbH Portal for providers of financial services
EP1421532A2 (en) * 2001-07-30 2004-05-26 Electronic Broking Services Limited Conversational dealing system
EP1421532A4 (en) * 2001-07-30 2009-11-18 Ebs Group Ltd Conversational dealing system
WO2005031571A1 (en) * 2003-09-29 2005-04-07 Sap Aktiengesellschaft Automatic registration and deregistration of message queues
US8468087B2 (en) 2004-10-28 2013-06-18 Depository Trust & Clearing Corporation Methods and systems for netting of payments and collateral
WO2008031987A1 (en) * 2006-09-12 2008-03-20 France Telecom System comprising an electronic money chain, method implementing this system, web service and web services server
US11025575B2 (en) 2018-06-12 2021-06-01 Oracle Financial Services Software Limited Message recognition system and method configurable to define new message formats
CN112596734A (en) * 2020-12-15 2021-04-02 五八同城信息技术有限公司 Static library generation method and device

Also Published As

Publication number Publication date
AU8054598A (en) 1998-12-21

Similar Documents

Publication Publication Date Title
US7216142B2 (en) Network application program interface facilitating communication in a distributed network environment
JP3837291B2 (en) Application independent messaging system
US5826269A (en) Electronic mail interface for a network server
US10404641B2 (en) Internet e-mail bridge
US7032005B2 (en) System for handling information and information transfers in a computer network
US7739338B2 (en) System and method for encoding and verifying the identity of a sender of electronic mail and preventing unsolicited bulk email
US7260623B2 (en) Remote services system communication module
US7796640B2 (en) Data management system and method
US7340506B2 (en) Value-added network switching and object routing
CN101371237B (en) Performing message payload processing functions in a network element on behalf of an application
US7660861B2 (en) System and method for verifying the identity of a sender of electronic mail and preventing unsolicited bulk email
AU636152B2 (en) Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US6880016B1 (en) Method and apparatus for structured communication
US20020120697A1 (en) Multi-channel messaging system and method
US20030120593A1 (en) Method and system for delivering multiple services electronically to customers via a centralized portal architecture
US20030069922A1 (en) Network transaction portal to control multi-service provider transactions
US20030212738A1 (en) Remote services system message system to support redundancy of data flow
US8095599B2 (en) Mail-based web application and document delivery
WO2006004623A2 (en) Access and synchronization with enterprise applications using remote hosted solution
JP2003522342A (en) Integrated customer interface for web-based data management
WO1998056024A1 (en) Translation of messages to and from secure swift format
Crispin Interactive Mail Access Protocol: Version 2
WO2001026004A2 (en) Method and apparatus for interprocess messaging and its use for automatically generating transactional email
Team Middleware Architecture Report
Crispin RFC1176: Interactive Mail Access Protocol: Version 2

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 1999502590

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA