Dynamic file transfer scheduling and server messaging

According to some embodiments, first and second schedule patterns are determined. For example, a graphical user interface might be used to indicate the times, days, and/or weeks when information is to be transferred. A first transfer of information may be scheduled between remote devices in accordance with the first schedule pattern, and a second transfer may be scheduled in accordance with the second schedule pattern. Moreover, a third transfer of information between remote devices may be automatically scheduled in accordance with both the first and second schedule patterns.

BACKGROUND

An enterprise may need to periodically transfer information between remote devices. For example, a server in a human resources department may store electronic records associated with employees, including salary, work hour, and vacation information. In this case, the records may need to be sent from the human resources department to a payroll department on a weekly basis. Note that the number of records associated with such transfers may be relatively large (e.g., an enterprise may need to transfer thousands of electronic records each week).

Moreover, different types of transfers may need to occur according to different schedules. For example, payroll information might need to be transferred between two remote devices on a weekly basis while sales information should be transferred between two different devices at the close of each business day. Managing such schedules for many different types of transfers can be a time consuming and error prone process. Consider, for example, an enterprise that needs to transfer information from a device in the United States to a device in Japan on business days only when it is not a national holiday in either country. A list of appropriate days could be manually created, but such an approach may be impractical—especially when there are a relatively large number of different types of jobs (each needing to comply with different complex scheduling requirements). Moreover, if a new national holiday was introduced in Japan, each previously constructed schedule would need to be reviewed to determine if changes were required.

Also note that these periodic transfers of information may include data that is especially important to an enterprise (e.g., customer requests or billing information), and a transfer that fails to execute properly for any reason may cause undesirable delays and other complications for the enterprise.

SUMMARY OF THE INVENTION

According to some embodiments, first and second schedule patterns are determined. A first transfer of information between remote devices may then be scheduled in accordance with the first schedule pattern, and a second transfer may be scheduled in accordance with the second schedule pattern. Moreover, third transfer of information between remote devices may be scheduled in accordance with both the first and second schedule patterns.

Other embodiments include: means for determining a first schedule pattern; means for determining a second schedule pattern; means for automatically scheduling a first transfer of information between remote devices in accordance with the first schedule pattern; means for automatically scheduling a second transfer of information between remote devices in accordance with the second schedule pattern; and means for automatically scheduling a third transfer of information between remote devices in accordance with both the first and second schedule patterns.

In some embodiments, a communication device associated with an automated remote access file transfer system, platform, or engine exchanges information with remote devices. The information may be exchanged, for example, via public and/or proprietary communication networks.

A technical effect of some embodiments of the invention is an automated remote access file transfer. With this and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.

DETAILED DESCRIPTION

FIG. 1is block diagram of remote access file transfer system100according to some embodiments of the present invention. The system100may, for example, facilitate an automated transfer of “files” between remote devices. As used herein, the term “files” may refer to electronic representations of information. By way of examples only, files might be associated with an insurance policy, event, or claim, payroll information, billing information, sales information, human resource information, medical information, or a legal proceeding (e.g., associated with a civil, criminal, or arbitration proceeding). Additionally note that the word “file” as used herein can refer to various types and formats of information, including text documents, spreadsheets, photographs, video images, and/or audio recordings. Moreover, as used herein the term “automated” indicates that at least some part of a step associated with a process or service is performed with little or no human intervention. In addition, the phrase “remote device” might refer to any apparatus or process that transmits or receives files in accordance with embodiments described herein. By way of examples only, a remote device may be associated with an enterprise server or a database farm.

The system100includes an automation scheduling process110(e.g., executing at a server). The automation scheduling process110may, according to some embodiments, arrange for the transfer of information, such as batches of files, between remote devices. For example, the automation scheduling process110might arrange for documents meeting a pre-determined criteria to be transferred from an enterprise accounting system to an enterprise payroll system each business day at 6:00 PM.

The automation scheduling process110may access information in one or more databases120. The databases120may include, for example, scheduling information. According to some embodiments, the databases120include “scheduling patterns,” such as sets of rules or instructions associated with schedules for a automated file transfer. For example, the databases120might include information indicating that a particular file (or files) should be transferred from a first device to a second device: on the 15thof every month, every Thursday, every January 1st, every 10thweek during a year, etc. Note that the scheduling information might also indicate a time of day when the information should be transferred (e.g., every Monday at 1:00 PM). As other examples, the databases120might include information about when information should not be transferred: on a weekend, on a U.S. federal holiday, etc.

The automation scheduling process110might access the databases120via a communication network. These devices (and any of the other devices described herein) could be associated with, for example, a server, a Personal Computer (PC), a mobile or laptop computer, or any other appropriate storage and/or communication device to exchange information via a web site and/or a communication network. As used herein, devices (including those associated with the automation scheduling process110, the databases120, and any other device described herein) may exchange information via any communication network, such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (IP) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.

The databases120are also accessible via a Graphical User Interface (GUI)130. The GUI130might be used, for example, to dynamically display existing schedule patterns to a user (e.g., along with files that are associated with those patterns), to receive new schedule pattern definitions from a user, and/or to associate one or more schedule patterns with particular files, types of files, and/or remote devices. One example of a GUI130is described herein with respect toFIG. 3.

Although a single automation scheduling process110, database120, and GUI130are shown inFIG. 1, any number of such systems may be included. Moreover, various devices described herein might be combined according to embodiments of the present invention. For example, in some embodiments, the automation scheduling process110, database120, and/or GUI130might be co-located and/or may comprise a single apparatus.

FIG. 2illustrates a method that might be performed, for example, by some or all of the elements of the system100described with respect toFIG. 1according to some embodiments. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, or any combination of these approaches. For example, a storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.

A first schedule pattern is determined at202, and a second schedule pattern is determined at204. The schedule patterns might be determined, for example, by retrieving pre-stored pattern information from a database. Note that a schedule pattern might be associated with a time of day (e.g. including a time zone of a device to send or receive information), a day of week, a day of month, and/or a week of year. Moreover a schedule pattern might be associated with holiday information and/or country information (e.g., listing Japanese national holidays). Also note that a schedule pattern might indicate when information should be transferred or be an exception indicating when information should not be transferred.

The patterns determined at202and204might be received via a GUI. For example,FIG. 3illustrates a scheduling pattern display300in accordance with some embodiments of the invention. In this case, a user has defined the schedule pattern as being run on the 27thand 28thof each month (as illustrated by the boxes with check marks inFIG. 3). Note that, according to some embodiments, a schedule pattern might be designated as “public” (e.g., shared by multiple users) or “private” (e.g. available to specific users).

At206, a first transfer of information is automatically scheduled between remote devices in accordance with the first schedule pattern. For example, it might be automatically arranged for a batch of records to be transmitted from a sales department device to a billing department device each Friday at 6:00 PM Eastern Standard Time (EST). Similarly, at208, a second transfer of information is automatically scheduled between remote devices in accordance with the second schedule pattern. For example, it might be automatically arranged for claim documents that meet a pre-determined criteria (e.g., are more than 90 days old and are stored at a particular location) to be transferred on the first day of every month.

According to some embodiments, a third transfer of information between remote devices is automatically scheduled at210in accordance with both the first and second schedule patterns. That is, the rules associated with the two schedule patterns may be combined via a conditional combination. For example, two (or more) schedule patterns might be combined in accordance with a conditional rule and/or one or more Boolean logic operations (e.g., an AND operation, OR operation, and/or any other type of combination). Note that more than two schedule patterns might be combined. For example, a particular job might be defined as being: (i) run every business day, except holidays, at 8:00 AM, (ii) run every weekend day and holiday at 6:00 AM, and (iii) run on the last day of every month (including holidays) at 11:59 PM.

Once the schedules are assigned, the system may automatically transfer information at212in accordance with at least one of the automatic schedules. For example, the system might arrange for all files named *.doc to be copied from a particular folder at a first server into a remotely located database at 3:00 AM each business day.

According to some embodiments, jobs to be executed are placed in an execution queue, such as a First-In, First-Out (FIFO) queue. Moreover, multiple queues might be used in connection with a remote access file transfer system (e.g., a primary transfer queue and a lower-priority secondary transfer queue). In some cases, the system may determine if a first file associated with a scheduled transfer of information is ready (e.g., does the file currently exist in a particular location). If the first file is not ready, another file from a primary transfer queue might be worked on instead. Moreover, an indication of the first file (e.g., a job identifier) might be moved from the primary transfer queue to the secondary transfer queue. According to some embodiments, jobs to be executed may also be associated with a priority level indication (e.g., indicating a high, medium, or low priority that should be associated with a type of job), and the priority level indication may be used to schedule execution of jobs instead of, or in addition to, a primary transfer queue and/or a secondary transfer queue.

Thus, embodiments of the present invention may provide for multi-faceted scheduling of remote access file transfers without extensive code changes. For example, by simply changing a schedule pattern stored in a database (e.g., by a adding a new date to an exception schedule entitled “UK Bank Holidays”), multiple jobs may end up being automatically rescheduled as appropriate. Moreover, a single job can be efficiently associated with a schedule defined using several different pattern types.

According to some embodiments, one or more elements or steps are implemented by sending messages between devices and/or processes. Such an approach may, for example, facilitate efficient communication between a relative large number of processes (e.g., a message might be sent from a process to one or many destinations).FIG. 4is a messaging process flow400in accordance with an exemplary embodiment of the invention.

As illustrated inFIG. 4, a message files database410may be provided. The message files database410may, for example, contain a list of messages and associated destinations. The messages might be referenced using, for example, a Remote Access File Transfer Identifier (RAFT ID) and, according to some embodiments, a destination associated with a RAFT ID can be dynamically changed by editing the appropriate file in the database410.

The message files database410may provide information to other devices and/or processes, such as a log component422. The log component422may, for example, log information associated with a status of a transfer of information. According to some embodiments, the logged information includes a Trace Identifier (Trace ID) that can span multiple messages. The message files database410may also provide information to a console component424and/or an error service426(e.g., a service that can detect and/or respond to errors in a remote access file transfer system). Moreover, a view process440may let an administrator access and/or dynamically adjust information about the log component422, console component424, and/or error service via a display device442.

The message files database410may further provide information to a notify service432that helps inform users about the status of various remote access file transfer jobs. For example, a user might be notified when a job is successfully initiated or completed (or when a job cannot be completed for some reason). The notify service432may, for example, determine what type of message will be sent and how the message is to be handled.

According to some embodiments, information about where and when such notices should be sent are stored in a notification database434. For example, the notification database might store a name, email address, telephone number, priority indication, and/or list of several parties that are to be associated with a particular type of notification. Moreover, according to some embodiments information in the notification database434may be dynamically changed by a user via a GUI436. For example, the GUI436might let a user customize the destination (e.g. by listing one or more email addresses or groups of addresses), “subject line,” body, and/or attachments of a notification message using one or more notification templates.

Based on the information in the notification database434and the message files database410, a notify service432may transmit notification messages to one or more notification devices associated with a remote access file transfer via a notification generator438. The notification devices might include, for example, a Personal Digital Assistant (PDA), an email account, a wireless telephone, and/or any other appropriate device.

According to some embodiments, a remote access file transfer system initiates and executes the transfer of information between remote devices by sending messages and executing scripts.FIG. 5illustrates message exchanges500in accordance with an exemplary embodiment of the invention. In this case, messages may be sent from an automation scheduling process510to a plurality of script processes530via a plurality of process services520. A script process530may, for example, execute a number of actions associated with a particular job. According to some embodiments, a script process530may arrange for an encryption process to be executed in connection with an automated transfer of information (e.g. to encrypt and/or decrypt information associated with the job).

Thus, the automation scheduling process510may use messages to start many jobs which execute through many processes520,530(e.g. which in turn may also generate many additional messages). Information about the relatively large number of messages that are exchanged may be stored, for example, in combined or independent log files. To help a user sort and/or search for information in such logs, a Trace ID associated with a particular job may be included in each message.

According to some embodiments, the message exchanges500are performed via Microsoft Message Queue (MSMQ) provided by MICROSOFT CORPORATION®. Such an approach may, for example, let the remote access file transfer system communicate with applications running at different times across heterogeneous networks as well as systems that may be temporarily offline. Moreover, the messaging can provide guaranteed delivery, efficient routing, security, and priority-based implementations for asynchronous and/or synchronous systems. In addition, message persistence may be arranged, addressing can be dynamically implemented, and delivery to multiple instances (across multiple servers) can be provided. According to some embodiments, each message includes an originating server name (indicating a server where the message came from) and an originating process name (indicating a process where message came from). Similarly, each message may include a destination server and process name. Messages may also include a message and job identifier (RAFT ID), user identifier, acknowledgement information (for a receiver to acknowledge receipt), a message type (to categorize the message), a Trace ID (e.g., unique identifier that could span multiple messages), and message text.

To provide resilience and recovery abilities for a remote access file transfer system, a plurality of persistence copies may be stored in connection with information being transferred. For example,FIG. 6is a block diagram of a persistence process system600in accordance with some embodiments. In this example, a server610exchanges information with persistence copies620and a database farm630providing a highly available software architecture with automated failover and dynamic disaster recovery (e.g., by supporting multiple disaster recover designations through environment classifications).

The server610may include a persistence process612and one or more remote access file transfer .net processes614(e.g., a scheduling process, logging process, and/or messaging process). The persistence process612may arrange for information associated with job transfers to be stored in the multiple persistence copies620and the data may be stored in a number of different places (e.g., different physical and/or geographic locations). Note that adding more destinations may increase the level of resiliency associated with the system600. Moreover, the .net processes614may access information via the database farm630, which may represent the authoritative source of data including RAFT ID information and associated scheduling information. Note that if a connection between the server610and database farm630is lost, information may still be processed until the connection is re-established. For example, information may still be processed using data stored in a persistence layer (e.g., the copies620). Also note that if one of the copies620becomes unavailable for some reason, the system600may later bring that copy620up-to-date if it becomes available again.

Such an approach may provide resilience by allowing the system600to continue processing information even when a particular database is not available. Moreover, the approach may provide recovery abilities by letting the system600re-synchronize when an object is lost and later recovered.

FIG. 7illustrates a software architecture700in accordance with an exemplary embodiment of the present invention. The architecture700may be implemented so as to help ensure reliability and flexibility of file transfers across an enterprise. According to some embodiments, one or more components of the architecture700are implemented using Visual Studio .net from MICROSOFT CORPORATION®, C++, Visual Basic, and/or Structured Query Language (SQL) database protocols for configuration and logging. Such an approach may, for example, provide relatively easy access to information in a single location, allow for central management of data, and/or provide for efficient maintenance of the architecture700.

According to some embodiments, information is exchanged via a MSMQ message queue710to provide guaranteed message delivery, a scalable environment, workload distribution, intelligent error processing, relatively fast diagnosis, and/or enhanced system recovery. Note that the architecture may also be associated with other protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) and/or the MQ Series or similar message oriented middleware provided by IBM CORPORATION®.

Messages may be, for example, sent and/or received by an automation control process722. The automation control process722may, for example, schedule the execution of transfer jobs, monitor the execution and completion of transfer jobs, and/or provide the status of transfer jobs. The automation control process722may be resilient and manage memory recovery during a process failure or application fail over (e.g., by persisting job information and scheduling to alternative locations to improve availability). Moreover, the automation control process722may allow for flexible scheduling by letting multiple schedules be used to define each transmission and may also provide extended event driven automation for a remote access file transfer system.

A Messaging Queue (MQ) client server interface724may act as a connection point for remote client programs using the message queue710as the communication interface. The MQ client server interface724may also let an operator view job information (e.g., associated with a job execution status), initiate remote access file transfer automation, provide client message queue creation, and handle system parameter requests.

A notification component726may arrange for users to receive email and/or pager notifications associated with the status of an automated transfer of information. For example, the manager of a human resources department may receive an email confirming that employee payroll files have been successfully transferred to an accounting department. The notification component726may also provide production support alerts, customer alerts, and/or custom tailored emails (e.g., by dynamically creating the subject line and/or body of an email message).

An error service728may help provide error recovery for the software architecture700. For example, the error service728might reduce costly problem tickets by implementing error ticket logging (e.g., allowing for a central error ticket location and interface with corporate tools), error tracking management, persisting error tickets to files for disaster recovery, and/or persisting errors to backup queues for automatic recovery to database.

A message router730may allow for multiple instances of remote access file transfer .net processes on remote servers and/or route messages based on direct addressing for forwarding processes. The message router730may also return undeliverable messages and/or manage connectivity with multiple servers. According to some embodiments, a gateway may also be provided (e.g., to act as an interface to IBM's MQ Series message queues) Such a gateway might deliver data to message queues and/or servers using File Transfer Protocol (FTP) or to network access storage devices, provide event based delivery using file or message queue watchers, manage files or zip files (e.g., zip files that conform to a standard configuration such as a content descriptor file), and/or extract messages from message queues and deliver as files (either individually or concatenated).

A log process732may manage log messaging and tables and provide an automated archive capability (e.g., archiving based on the current month and/or year). The log process732may also provide access to transfer history information, let users view filtered real time execution of transfers, persist log messages to files for disaster recovery, and/or persist log messages to backup queues for automatic recovery to database.

A command center interface734may allow limited access to remote access file transfer .net functionality through a TCP/IP client. The command center interface734may also provide a secure interface into remote access file transfer .net processes, allowing a customer to either automate or manually initiate their transfer, and/or return status messages for the software architecture700.

A control process736may be responsible for startup and/or shutdown procedures associated with the software architecture700. The control process736may also monitor the stability of critical processes, provide auto-recovery of failed processes, and/or automatically arrange for inclusion of manually initiated processes. According to some embodiments, the control process736may be configurable to allow multiple instances of remote access file transfer .net processes on a single server. Note that control process736may be executed as a service or manually and can be configured for high availability and disaster recovery (e.g., to identify an alternate server and hardware resource for recovery, actively monitor an alternate server and hardware resource for instant failover, and/or to check for passive session inactivity before initiating failover).

A file watcher service738may provide a reliable method for delivering files to and from network shared storage. The file watcher service738may be event drive (e.g., not scheduled) and may initiate additional automation through a request service740. According to some embodiments, the file watcher service738may persist a state of delivery for auto recovery during server failure and/or application failover.

A request service740may provide for the reliable execution of scripts initiated from an event message. According to some embodiments, execution may be thread based and the request service740may manage execution by maintaining state information, queuing data, and monitoring maximum concurrent usage. Similarly, a process service742may be provided to support legacy scripts and may be processed based. The process service742might, for example, manage execution by maintaining state information, be initiated by command line or by automation control process through an action, and/or be tightly integrated with the automation control process722.

A file request service744may create files from event messages. The file request service744may, for example, use MQS gateway.request services for MQ message delivery (e.g., supporting open, write, and/or close request). The file request service744may also support header and trailer creation (e.g., either system or user defined) and use the request service740for delivery after the successful creation of a file.

FIG. 8is a block diagram of an automation control process apparatus800in accordance with some embodiments of the present invention. The apparatus800might, for example, comprise a platform or engine similar to the automation control process722illustrated inFIG. 7. The apparatus800comprises a processor810, such as one or more INTEL® Pentium® processors, coupled to a communication device820configured to communicate via a communication network (not shown inFIG. 8). The communication device820may be used to exchange messages, for example, with one or more remote devices.

The processor810is also in communication with an input device840. The input device840may comprise, for example, a keyboard, a mouse, or computer media reader. Such an input device840may be used, for example, to enter information about schedule patterns. The processor810is also in communication with an output device850. The output device850may comprise, for example, a display screen or printer. Such an output device850may be used, for example, to provide reports and/or display information associate with schedule patterns and/or jobs that have been (or are to be) performed by a remote access file transfer system.

The processor810is also in communication with a storage device830. The storage device830may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices.

The storage device830stores a program815for controlling the processor810. The processor810performs instructions of the program815, and thereby operates in accordance any embodiments of the present invention described herein. For example, the processor810may receive information indicating a first and second schedule pattern. The processor810may automatically schedule a first transfer of information (between remote devices) in accordance with the first schedule pattern and a second transfer in accordance with the second schedule pattern. Moreover, according to some embodiments, the processor810may automatically schedule a third transfer of information between remote devices in accordance with both the first and second schedule patterns. Note that the processor810or some other device may then initiate automated transfers of information in accordance with the schedules.

As used herein, information may be “received” by or “transmitted” to, for example: (i) the automation control process apparatus800from other devices; or (ii) a software application or module within the automation control process apparatus800from another software application, module, or any other source.

As shown inFIG. 8, the storage device830also stores: a schedule database900(described with respect toFIG. 9) and a log database1000(described with respect toFIG. 10). Examples of these databases that may be used in connection with the automation control process apparatus800will now be described in detail with respect toFIGS. 9 and 10.

The illustrations and accompanying descriptions of the databases presented herein are exemplary, and any number of other database arrangements could be employed besides those suggested by the figures. For example, a single remote access file transfer database with multiple tables might be employed. As other examples, customer configuration tables (including a file transfer identifier and associated schedule, customer information, and script process steps), a notification table860(including email or pager addresses along with a message subject header and text body), a schedule pattern database870(e.g., defining different types of job schedule patterns), an accounting table, and/or an error table might be associated with the apparatus800.

FIG. 9is a tabular view of a portion of an scheduled transfer database900in accordance with some embodiments of the present invention. The table includes entries identifying jobs associated with information to be transferred between remote devices. The table also defines fields902,904,906,908,910for each of the entries. The fields specify: a Remote Access File Transfer Identifier (RAFT ID)902, an origin identifier904, a destination identifier906, schedule information908, and a status910. The information in the database900may be created and updated based on information received from users and/or a remote access file transfer system.

The scheduled transfer identifier or RAFT ID902may be, for example, an alphanumeric code associated with a set of files that are scheduled to be automatically transferred between remote devices. The origin identifier904may represent where the files to be transferred are to be found and the destination identifier906may represent where the files should be sent. The origin and destination identifiers904,906might comprise, for example, physical locations, document names, network addresses, and/or any other information that can identify the appropriate storage areas. The scheduling information908indicates when the files should be transferred from the origin identifier904to the destination identifier906. The scheduling information908might include, for example, one or more times, dates, and/or years. The scheduling information908might also comprise references to one or more pre-determined scheduling patterns (e.g., defined by a user via a GUI and/or stored in the schedule pattern database870). For example, the scheduling information908might indicate that two patterns should be combined via a Boolean OR operation. The status910may indicate the current status of the job associated with the RAFT ID902(e.g., the job might be pending, in process, completed, or an error may have occurred).

Information about the status of a scheduled job might also be included in one or more log tables (e.g., tables that store jobs completed messages and steps completed messages, including transfer identifiers). For example,FIG. 10is a tabular view of a portion of a log database1000in accordance with some embodiments of the present invention. The table includes entries identifying messages and/or actions that have occurred in a remote access file transfer system. The table also defines fields1002,1004,1006,1008,1010for each of the entries. The fields specify: a message identifier1002, a Remote Access File Transfer Identifier (RAFT ID)1004, a trace identifier1006, a time1008, and a date1010. The information in the database1000may be created and updated automatically as messages are sent, processed, and/or received in connection a remote access file transfer system.

The message identifier1002may be, for example, an alphanumeric code associated with a message that has been processed (e.g., via the message queue710ofFIG. 7). The scheduled transfer identifier or RAFT ID1004may be, for example, an alphanumeric code associated with a set of files that are scheduled to be automatically transferred between remote devices. The RAFT ID1004may be based on, or associated with, for example the RAFT ID902stored in the scheduled transfer database900. The trace identifier1006may comprise, for example, a code that can be used to sort and/or search the message in the log database1000. Note that according to some embodiments, a single trace identifier1006may span multiple RAFT IDs1004and/or message identifiers1002. The time1008and date1010may indicate when the associated message was sent, received, and/or processed.

Thus, embodiments of the present invention may facilitate scheduling for a remote access file transfer system. Moreover, scheduling patterns can be defined as a schedule type (e.g., Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday may represent day schedule types) and types may be created to make new types or patterns (e.g., grouping the day type may create a new schedule type of Week). In addition, a schedule can have any number of patterns that define a type. For example, a schedule might indicate that a job should be automatically run Monday thru Friday at 10:00 AM and Tuesday at 1:00 PM. Note that a schedule pattern could indicate when a job should not be executed (e.g., that a job should not be run on Thursday Nov. 29, 2007). Schedule information might be associated with a private group (e.g., unique for a single job) or a public group (e.g., used for multiple jobs). In this way, complex job schedules can be efficiently created and managed (e.g., because scheduling types and not static and allow for new additions).

Moreover, embodiments may provide resiliency for the remote access file transfer system. For example, a persistence layer lets a memory object be defined and saved to multiple physical locations. Moreover, the copies in the persistence layer may be synchronized to ensure recoverability after system failure. Note that a scheduling database, providing an authoritative source for configurations and scheduling, may be farm based and/or network attached therefore availability of the database may be interrupted. According to some embodiments, such an interruption will not result in application failures and/or any failures that do occur may be recoverable. For example, all configurations and schedules may be persisted to reliable disk storage and used for execution. Changes made to the source may be automatically synchronized with the persisted files on disk. Any database failure may therefore cause little or no risk to production execution (e.g., any loss of persisted files would automatically be recreated to synchronize with the source database). As a result, the remote access file transfer system may be able to continue with operations with minimal interruption even when enterprise services are unavailable.

In addition, embodiments may be implemented using an open messaging architecture (allowing for communications across multiple application processes as well as client/user access). The dynamic integration of applications and clients may be provided without reconfiguration and an application may remain active while integrating new features as processes. Further, all messages may use the same or similar architecture (e.g., as in logging, transactions and commands), and message routing may be configurable, able to span across multiple systems, discover destination and return locations, and provide relatively unlimited origination and destination points. As a result, embodiments may provide the ability to enhance an application with little or no interruption and/or to grow horizontally while continuing to share same tools.

Note that embodiments of the present invention may be associated with systems other than a remote access file transfer system. For example,FIG. 11illustrates a messaging method according to some embodiments of the present invention. In this case, a job identifier (e.g., such as the RAFT ID described herein) may be associated with a job to be executed within an enterprise data processing system at1102. At1104, the job identifier may also be associated with a set of messages, each message having message content, an origination process identifier, and at least one destination process identifier.

At1106, a first job may be automatically initiated within the enterprise data processing system by transmitting a first message from a first origination process to a first destination process in accordance with a first job identifier, wherein at least one of the message content, origination process identifier, or destination process identifier may be dynamically changed to adjust job execution. Note that a message may be associated with, for example, an automation scheduling process, a process service, and/or a script process such as those described in connection with toFIG. 5. Moreover, a message may be associated with elements such as those described with respect toFIG. 7, including a message queue client server interface, a remote access file transfer request service, a file request service, a message queue client server interface, a notification service, a message queue gateway, an error service, a process service, a message router, a log process, a control process, a command center interface, a file watcher service, and/or a message queue.

Such an approach may, for example, provide for the efficient definition of new types of jobs to be executed and/or let a user dynamically change existing types of jobs (e.g., without needing to modify a substantial amount of code associated with the various processes of the enterprise system). According to some embodiments, log information associated with execution of the first job may also be stored, searched, and/or displayed to a user. Moreover, the log information may include a trace identifier (e.g., a Trace ID) associated with a plurality of messages or a plurality of processes.

Although specific hardware and data configurations have been described herein, not that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems). Moreover, although examples of specific types of file transfers have been used, embodiments of the present invention could be used with other types of electronic information. For example, data associated with a financial services enterprise (e.g., banking or trading information) might be handled in accordance with any of the embodiments described herein.

Applicants have discovered that embodiments described herein may be particularly useful in connection with highly complex file transfer arrangements. For example, embodiments may be beneficially applied with respect to the complicated schedules, and substantial amounts of information, often associated insurance and/or financial services information (e.g., tens of thousands of important files may need to be frequently moved or copied in accordance with a large number of international calendars).