Strategic Thought

AIFG >

 Functionality

The Files Gateway product is designed to provide a mechanism by which files can be en-queued to and de-queued from WebSphere MQ queues mimicking File Transfer Protocol (FTP) transfer mechanisms.  The purpose of providing this as a product is:

• to enable a simple replacement of FTP with file transfer over WebSphere MQ, thus providing assured delivery functions of MQ to basic file transfer
• to provide the basis though which file transfer can then be integrated into a hub and spoke architecture.
• to enable applications such as WMQI and Mercator to communicate using WebSphere MQ with applications that require data to be delivered to them using a files interface.
• to provide a flexible architecture that is straightforward to extend to meet specific application protocols and tailoring to standard FTP transfer.

The MQ Gateway is a single threaded application but has high performance features built into minimise the latency when inbound messages are delivered to a local queue for dequeue to a file, and when data is delivered to a file for onward transmission via WebSphere MQ.

Technical Functionality that makes AIFG the  most configurable and adaptable tool:

The concept of the product is simple, and we have developed an impressive array of technical configuration options giving high levels of functionality, resiliency and error handling. For example:

• The ability to write a file to a fixed name or a dynamic name (with a sequence counter, a Message ID, a Correlation ID, or the current time or date included), or to name the file from a field within the MQMD or RFH2 message header.
• When saving a file to disk, having the option to either overwrite a file of the same name if it exists, or to wait until it is removed.
• The ability to block a queue which has had multiple errors (for example when a file cannot be written to disk because a file of the same name already exists) so that one failed queue does not slow the processing of all the other queues.
• The ability to shut itself down completely and then automatically restart in order to compensate for potential system errors. 
• The ability to reconfigure, start, stop and control the Gateway remotely via MQ messages, enabling full control of remote instances without having to have login privileges on each system.
• The ability to run multiple instances in parallel, sharing the internal configuration, control and logging queues. This gives fault tolerance and also potentially higher throughput.
• Detailed and highly configurable logging, logging errors and/or events to a file, the screen or to an MQ queue allowing integration with enterprise modelling tools such as IBM Tivoli.
• Provides full audit trail of all messages sent and received.
• A full GUI running alongside the MQ Explorer for configuring, controlling and monitoring any number of Gateway instances from a remote system. Simplifies management of the product and displays logging outputs and statistics in a graphical format.
• The ability to call an external script or application passing to it the filename of the file which is about to be processed by the Gateway. This functionality can be used to perform processing on a file before it is sent, or even decision making in deciding not to send a specific file for any reason. Also included is the ability to call a custom script whenever a file is successfully enqueued or dequeued, or whenever any operation fails.
• The ability to add custom fields into the RFH2 header of any message sent, allowing messages to be manipulates and routed within WebSphere Message Broker (or handled by another application which requires RFH2 headers).
• Multiple methods to ensure that a file is not sent before it has finished being written by the originating application (for example time-delays, lock files, OS file locking). Also there are multiple methods to ensure that a newly generated file is not picked up by a waiting application until the Gateway has finished writing it. 
• The ability to make a copy of all files sent into an archive directory, potentially with the time/date of the transfer or the Message ID of the sent message included within the archive filename. 

Advanced Features that truly set AIFG apart from the competition:

• The ability to add a custom header to a message so that it can be sent directly into SAP.
  
• The ability to wait until a group of outbound files are available before sending any of them. This can be combined with the scripting functions to perform complex functionality for example to combine multiple linked files into one single message before sending it.
  
• The ability to unzip files and send the contents (or some of the contents) as a message. Also the ability to zip a file while writing it to disk.
  
• The ability to get files from a remote FTP site rather than a local disk, ready to then be sent as a message. Also, conversely, the ability to dequeue a message and then place it as a file onto a remote FTP site.
  
• The ability to group incoming messages (for example those which have the same Message ID or Correlation ID) and to dequeue these all at once.
  
• Detailed statistics gathering – both data throughput and message counts are stored on an accessible MQ queue.
  
• Ability to specifically define any header field in the MQMD, RFH2, GMO and PMO structures when doing the relevant get or put operations.