Abstract:
A system, method, and computer program product are disclosed for providing a single automation tool adapter for use with multiple different automation tools. Multiple different clients are monitored for automation requests. An automation request that is to be executed within one of the automation tools is received from one of the clients in an original format. A second format that is required by the automation tool is determined. The automation request is converted from the original format to the second format. The automation request is then submitted in the second format to the automation tool for processing. Automation requests are submitted to an automation tool in a format that is required by the automation tool.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Technical Field  
         [0002]     The present invention relates generally to the field of computer systems, and more specifically to a method, system, and computer program product for providing a single automation tool adapter for use with multiple different automation tools.  
         [0003]     2. Description of Related Art  
         [0004]     Many proprietary systems or devices accept programmatic input for making changes to the device. An automation tool is any application that interfaces with a system or device to enact a sequence of automated changes, via one of these programmatic interfaces. When such applications are not provided by the vendor, it is common practice to create scripts that call Command Line Interface (CLI) commands in a particular sequence to perform tasks (i.e. Create a VLAN in a Cisco Switch, Initiate a Copy Task on an IBM Storage device, etc.). There are no standards that govern these programmatic interfaces or automated tools.  
         [0005]     Many different automation tools may exist within a single environment. Each automation tool may have its own unique format that it requires for requests. Thus, a request sent to a first automation tool might be required to be in a first format while a request sent to a second automation tool might be required to be in a second, different, format.  
         [0006]     In order to use the many different automation tools, each object could be required to put its requests in the proper format required by the requested automation tool. This approach is not practical, however, in systems having even a few potential requesting objects and a few different automation tools, or in a system where rapid addition of new automation tools is required.  
         [0007]     One approach to automate the use of the many different automation tools is to provide a different, custom process for each automation tool. Thus, each automation tool would have an associated custom process. Each custom process would then receive requests from the various objects requesting the associated automation tool, convert the received request into the format required by its associated automation tool, and then forward the request to the tool.  
         [0008]     This automation approach is not efficient for systems having many different automation tools. In such a system, many different custom processes would be required. These custom processes would require a large development effort, as well as strong knowledge of the entire automation framework. An even larger management and maintenance effort is also required to continue to support all of these custom processes as the environment is updated.  
         [0009]     In addition, this automation approach would suffer from possible conflicts when two or more automation tools need to act on the same set of end devices. Thus, additional complex code is needed to serialize the use of the tools to avoid these possible conflicts.  
         [0010]     Therefore, a need exists for a method, system, and computer program product for providing a single automation tool adapter that can be used with multiple different automation tools.  
       SUMMARY OF THE INVENTION  
       [0011]     A system, method, and computer program product are disclosed for providing a single automation tool adapter for use with multiple different automation tools. Multiple different automation clients are monitored by the present invention for automation requests. An automation request for one of the automation tools is received from one of the clients in an original format. A second format that is required by the automation tool is determined. The automation request is converted from the original format to the second format. The automation request is then submitted in the second format to the automation tool for processing. A reply message from the automation tool is transformed into the format of the original request before being returned to the automation client. In this manner, automation requests are submitted to an automation tool in the format that is required by the automation tool.  
         [0012]     The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]     The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:  
         [0014]      FIG. 1  is a block diagram of a data processing system that may be utilized to implement the present invention in accordance with the present invention;  
         [0015]      FIG. 2  is a block diagram which illustrates a logical design and process flow of an automation tool adapter in accordance with the present invention;  
         [0016]      FIG. 3  illustrates a high level flow chart which depicts a queue listener process in accordance with the present invention;  
         [0017]      FIG. 4  depicts a high level flow chart which illustrates a verb dispatcher process in accordance with the present invention;  
         [0018]      FIG. 5  illustrates a high level flow chart which depicts an automation processor in accordance with the present invention; and  
         [0019]      FIG. 6  depicts a high level flow chart which illustrates a reply server process in accordance with the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0020]     A preferred embodiment of the present invention and its advantages are better understood by referring to the figures, like numerals being used for like and corresponding parts of the accompanying figures.  
         [0021]     Automation requests are received in messages in the present invention in the form of data payloads delivered via an asynchronous messaging system. The data payload of an automation request may be in one of several formats, such as an XML document or a set of name/value pair parameters. Information contained in the automation request is to be forwarded to an automation tool indicated by the request for processing.  
         [0022]     The particular automation tool and associated tool configuration parameters are determined by the workflow verb as found in the automation request. There is a configuration file where the automation tool is specified for each type of automation request that is received. Therefore, the automation client does not have to maintain working knowledge of the specific tool that is used for each type of automation request. This allows the automation client to focus on the logical automation operation is it trying to carry out, rather then the unrelated information about how to actually carry it out. The format of the information comprising an automation request is not necessarily the same format as that used and required by the automation tool.  
         [0023]     Automation request information may be transferred between multiple request formats, such as XML, name/value, and JavaBeans, as determined by the automation tool requirements. Additionally, automation request parameter names may be mapped to specific parameter names that are required by a particular automation tool.  
         [0024]     In order to facilitate the transformation of automation request information between formats, the present invention supports the mapping, also called translation, of individual data elements between request formats and automation tool formats. For example, an automation request may be received as an XML document and transformed into a flat file containing a set of name/value pairs before being presented to an automation tool for processing. Results received from an automation tool may similarly be transformed from a format supported by the automation tool to a format required by the requester.  
         [0025]     The present invention handles automation request information based on the format of the request, mapping specifications, and the format requirement of the automation tool. The following process is applied to each automation request: 
        (1) The contents of the automation request are extracted from the asynchronous message and the format of the automation request parameters is determined.     (2) The format requirement of the destination automation tool is determined from the contents of the automation request.     (3) The automation request parameters are extracted from the automation request. If a mapping for a specific parameter name is found in the automation tool&#39;s configuration file, it is mapped to that new parameter name. If a mapping is not found, a default transformation is applied.     (4) The resulting mapped automation request parameters are transformed into the format required by the automation tool and passed to the automation tool.     (5) Results received from an automation tool are mapped back to the format used by the requester of the original automation request in a similar manner.        
 
         [0031]     For example, if an automation request is received in an XML formation containing tags such as: 
        &lt;city&gt;
            &lt;machine&gt;
                &lt;IPAddress&gt;10.11.12.13&lt;/IPAddress&gt;   
                &lt;/machine&gt;   
            &lt;/city&gt;
 
 and the automation tool configuration file contains a mapping such as: 
    &lt;map name=“city_machine_IPAddress”&gt;
            &lt;parameterTag&gt;host.address&lt;/parameterTag&gt;   
            &lt;/map&gt;
 
 and the automation tool required a name/value format, then a parameter file would be produced for the automation tool containing the following line: 
    host.address=10.11.12.13        
 
         [0043]     If the automation tool instead required parameters in an XML format, then an XML document would be produced containing the following tags: 
        &lt;host&gt;
            &lt;address&gt;10.11.12.13&lt;/address&gt;    &lt;/host&gt;   
               
 
         [0047]     By providing automation request format and parameter naming transformation, the present invention effectively insulates both the automation requester and the automation tool from changes in each other. It is critical that this functionality be in place in order to ensure long-term support for automation tools with varying requirements and capabilities.  
         [0048]      FIG. 1  is a block diagram illustrating a data processing system that may be utilized to implement a server, client, object request broker, or any other computer system in accordance with the present invention. Data processing system  200  employs a peripheral component interconnect (PCI) local internal bus architecture. Although the depicted example employs an internal PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor  202  and main memory  204  are connected to PCI local bus  206  through PCI bridge  208 . PCI bridge  208  also may include an integrated memory controller and cache memory for processor  202 . Additional connections to PCI local bus  206  may be made through direct component interconnection or through add-in boards.  
         [0049]     In the depicted example, network card  210 , SCSI host bus adapter  212 , and expansion bus interface  214  are connected to PCI local bus  206  by direct component connection. In contrast, audio adapter  216 , graphics adapter  218 , and audio/video adapter  219  are connected to PCI local bus  206  by add-in boards inserted into expansion slots. Expansion bus interface  214  provides a connection for a keyboard and mouse adapter  220 , modem  222 , and additional memory  224 . Small computer system interface (SCSI) host bus adapter  212  provides a connection for hard disk drive  226 , tape drive  228 , and CD-ROM drive  230 . Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.  
         [0050]     Those of ordinary skill in the art will appreciate that the hardware in  FIG. 1  may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in  FIG. 1 .  
         [0051]     As another example, data processing system  200  may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system  200  comprises some type of network communication interface. As a further example, data processing system  200  may be a Personal Digital Assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.  
         [0052]      FIG. 2  is a block diagram which illustrates a logical design and process flow of an automation tool adapter  300  in accordance with the present invention. Automation tool adapter  300  includes a queue listener  302 , a verb dispatcher  304 , an automation processor  306 , and a workflow reply server  308 . Multiple different request queues  310  receive messages that include requests from a workflow engine  312  or an internal request tool  314 . Block  310  represents one or more queues. Each request queue  310  is associated with a distinct queue listener  302 .  
         [0053]     Configuration files  311  are processed at startup time. These files  311  are then available for use by queue listener  302 , verb dispatcher  304 , automation processor  306 , and workflow reply server  308  as described herein. The configuration file has stanzas for each known action verb that specifies which automation tool should be used when a request that includes that verb is received. In addition, the configuration file includes a specification of an expected format for each automation tool. This format is the format required by the particular automation tool for its received requests and is the format used by the tool for its replies. Thus, a request must be in this format before the request is sent to the tool. The tool will then process the request and provide a reply to the request in that same format.  
         [0054]     Each queue listener  302  waits on an associated request queue  310  for a message to arrive. If a queue receives a message that includes a request that needs to be processed by an automation tool, a queue listener  302  passes the request to verb dispatcher  304 . A more detailed description of the queue listener process is described below with reference to  FIG. 3 .  
         [0055]     Verb dispatcher  304  examines the request, determines the verb name that describes the request, creates an automation processor of the type required by the verb, and translates the parameters of the request to the format required by the automation tool. Verb dispatcher  304  then passes the translated parameters to the automation processor  306 . A more detailed description of the verb dispatcher process is described below with reference to  FIG. 4 .  
         [0056]     Automation processor  306  constructs an automation tool command using the translated parameters, and executes the automation tool command using automation tool  316 . Automation processor  306  provides any error messages to internal request reply queue  322 . A more detailed description of the automation processor process is described below with reference to  FIG. 5 .  
         [0057]     Automation tool  316  executes the command that it received from automation processor  306 . The parameters from the original request have been translated to a format required by automation tool  316 . After executing the command, automation tool  316  provides the results of the execution of the command to the workflow reply client  318  when then provides the results to the workflow reply server  308 .  
         [0058]     Workflow reply server  308  receives the results of the execution and translates the results into a format required by the original requester. Workflow reply server  308  provides any error messages to internal request reply queue  322 . A more detailed description of the workflow reply server process is described below with reference to  FIG. 6 .  
         [0059]     Workflow reply server  308  puts a workflow reply message to Reply queue  320 , containing the results of the execution of the original request in the format of the original request. The workflow reply message is then read from the Reply queue  320  to provide the results to the workflow engine  312 .  
         [0060]     A message identifier is included throughout the process described above in order to uniquely identify the particular request and to identify its requester. This message identifier is passed along with the request as described in more detail below.  
         [0061]      FIG. 3  illustrates a high level flow chart which depicts a queue listener process in accordance with the present invention. The process starts as depicted by block  400  and thereafter passes to block  402  which illustrates starting a queue listener for each queue to be monitored. Next, block  404  depicts a determination of whether or not the listener is to be stopped. If a determination is made that the listener is to be stopped, the process passes to block  406  which illustrates stopping the queue listener. Referring again to block  404 , if a determination is made that the queue listener is not to be stopped, the process passes to block  408  which depicts the queue listener checking a queue for messages. One or more queues may be provided in one or more computer systems, each with its own queue listener. The queue listener will check its queue for messages.  
         [0062]     The process then passes to block  410  which illustrates a determination of whether or not an automation message is present in the queue. If a determination is made that no automation message is present in the queues, the process passes back to block  404 . An automation message is a message that includes a request to be executed using one of the automation tools.  
         [0063]     Referring again to block  410 , if a determination is made that an automation message is present in the queue, the process passes to block  412  which depicts auditing the process which includes recording the time stamped, original contents of the automation request message and an associated unique transaction identifier. If a determination is made that an automation message is present in one of the queues, the process also passes to block  414  which illustrates a determination of whether or not the message includes a valid action verb defined in the automation tool configuration file(s). As described above, the configuration files map Automation Request verbs to automation tools. All of the verbs mapped to automation tools are considered “valid action verbs”, but if a verb is received that has no map defined to an automation tool, then there is no way of knowing how to process that verb, and it is considered invalid. If a determination is made that the message does not include a valid action verb, the process passes to block  416  which depicts logging an error.  
         [0064]     The workflow request received on the queue specifies one of the object managers. The request is received in XML format and contains a unique verb name and request ID. The request may also contain additional data for input to the automation tool that is responsible for responding to the request. Data for input to the automation tool must be passed to that tool in one of the accepted formats. The workflow manager will expect a reply to the request.  
         [0065]     The unique verb ID is passed to the automation tool, and then returned in the tool&#39;s reply to this request to the workflow manager. Data for output to the workflow manager must be passed to the reply tool in the same format that was used to pass the request to the automation tool.  
         [0066]     Verbs may be dispatched in parallel.  
         [0067]     Referring again to block  414 , if a determination is made that the message does include a valid action verb, the process passes to block  418  which illustrates creating a verb dispatcher and providing the message to the verb dispatcher. Each message includes a message identifier (ID) that identifies the particular message as well as the object that originally made the request. The object that made the request is also referred to herein as a requester. Block  418  illustrates passing the message including the verb data and message ID to the verb dispatcher.  
         [0068]     Thereafter, block  420  depicts obtaining an execution thread for the action verb from the verb group thread pool. Each automation verb available to the present invention is defined as belonging to a single specific verb group. A verb group may contain multiple automation verbs, but an automation verb may belong to only one verb group. The function of a verb group is to limit the maximum number of concurrent execution threads available to the set of all automation verbs defined as belonging to a verb group. This thread control strategy serves to protect from excessive load, and to control the number of concurrent automation processes running against a specific automation tool.  
         [0069]     When the present invention is started, automation verb and verb group definitions are obtained from an XML configuration file. Each verb definition specifies the verb group to which that verb belongs. Each verb group definition specifies the name of the verb group and the maximum number of concurrent threads available to that thread group. Each verb group is assigned a threadpool configured with a maximum number of concurrent threads, a minimum number of available threads, and the maximum time that a thread may be idle before it is considered stale.  
         [0070]     All threadpools are registered by verb group name with a threadpool manager object. The threadpool manager is responsible for providing a public interface into the threadpools registered to it, and provides a single point of control for all threadpools. The threadpool manager starts and stops all threadpools and returns a threadpool reference by verb group name. The threadpool manager is also capable of obtaining threadpool statistics from an active threadpool. Available threadpool statistics include configuration information, number of requests in progress, number of available threads and idle threads, and the number of pending requests.  
         [0071]     When an automation request is received, it is parsed and the automation verb is obtained. The threadpool assigned to the verb group to which the automation verb belongs is obtained from the threadpool manager. A verb dispatcher object is created to control the automation request processing and is forwarded to the threadpool for execution. If an idle thread is available from the threadpool, the verb dispatcher is executed immediately. If a thread is not available (all threads are in use) the threadpool will attempt to create a new thread constrained by the maximum number of concurrent threads, and execute the verb dispatcher on that new thread. If a new thread cannot be created (the maximum number of concurrent threads has been reached), the automation request is queued up by the threadpool to be executed on the next available thread. Threads exceeding a designated maximum idle time are considered stale and are discarded.  
         [0072]     Each instance of the queue listener is configured to listen for automation requests on a single asynchronous message queue. Each message queue listener executes on a separate thread but uses the same threadpool manager to control the execution of verb dispatchers. In this manner, the execution of automation requests received from different sources is controlled through a common threading mechanism.  
         [0073]     The process then passes to block  422  which depicts asynchronously executing the verb dispatcher on the verb group execution thread. The process then passes back to block  404 .  
         [0074]      FIG. 4  depicts a high level flow chart which illustrates a verb dispatcher process in accordance with the present invention. The process starts as depicted by block  500  and thereafter passes to block  502  which illustrates receiving a request message including verb data and a message ID from the queue listener. Thereafter, block  504  depicts creating an automation processor of the type required by the received verb. An automation processor encapsulates the operating system-specific command mechanism by which an automation verb is to be invoked. Next, block  506  illustrates configuring the automation processor from the verb definition and message.  
         [0075]     The process then passes to block  508  which depicts a determination of whether or not this is a workflow message. If a determination is made that this is not a workflow message, the process then passes to block  514 . Referring again to block  508 , if a determination is made that this is a workflow message, the process passes to block  510  which illustrates a determination of whether or not this message includes a workflow message ID. If a determination is made that this message does not include a workflow message ID, the process passes to block  512  which illustrates logging an error.  
         [0076]     Referring again to block  510 , if a determination is made that this message does include a valid workflow message ID, the process passes to block  514  which depicts translating the message&#39;s parameters from their original format into the format required by the requested automation tool. Thereafter, block  516  illustrates creating an automation parameter file of a type that is required by the requested automation tool. The process then passes to block  518  which depicts auditing the process. The process also passes to block  520  which illustrates synchronously executing the automation processor. Next, block  522  depicts providing the message, including the message ID and the translated parameters, to the automation processor. The process then terminates as depicted by block  524 .  
         [0077]      FIG. 5  illustrates a high level flow chart which depicts an automation processor in accordance with the present invention. The process starts as depicted by block  600  and thereafter passes to block  602  which illustrates receiving a message including the message ID and translated parameters from a verb dispatcher. The process then passes to block  604  which depicts auditing the process. The process also passes to block  606  which illustrates a determination of whether or not this is a workflow message. If a determination is made that this is not a workflow message, the process passes to block  610 . If a determination is made that this a workflow message, the process passes to block  608  which depicts caching the automation request information. Cached automation request information includes request type, request transaction identifiers, and reply queue destination. The process then passes to block  610 .  
         [0078]     Block  610 , then, illustrates constructing an automation tool command using the translated parameters. Next, block  612  depicts executing the automation tool command on an operating system (OS) process. Thereafter, block  614  illustrates a determination of whether or not there is an OS error. If a determination is made that there is an OS error, the process passes to block  616  which depicts a determination of whether or not this is a workflow message. If a determination is made that this is a workflow message, the process passes to block  618  which illustrates sending an error message to the workflow reply queue. The process then terminates as depicted by block  622 . Referring again to block  616 , if a determination is made that this is not a workflow message, the process passes to block  620  which illustrates sending an error message to the internal request reply queue. The process then terminates as depicted by block  622 .  
         [0079]     Referring again to block  614 , if a determination is made that no OS error occurred, the process passes to block  624  which depicts the automation tool sending a reply including the message ID to the workflow reply client in the automation tool&#39;s parameter format. The process then passes to block  622 .  
         [0080]      FIG. 6  depicts a high level flow chart which illustrates a workflow reply server process in accordance with the present invention. The process starts as depicted by block  700  and thereafter passes to block  702  which illustrates the workflow reply client sending the automation tool reply to the workflow reply server. Next, block  704  depicts a determination of whether or not the reply includes a valid workflow message ID. If a determination is made that the reply does not include a valid workflow message ID, the process passes to block  706  which illustrates logging an error.  
         [0081]     Referring again to block  704 , if a determination is made that the reply does include a valid workflow message ID, the process passes to block  708  which illustrates auditing the process. The process also passes to block  710  which depicts retrieving the cached automation request information. Next, block  712  illustrates translating the automation tool&#39;s reply from the parameter format used by the automation tool that the reply is in to the format used by the requester that the original request was in.  
         [0082]     Thereafter, block  714  depicts constructing a workflow reply message including the message ID and the automation tool&#39;s reply in the original format. The process then passes to block  716  which illustrates a determination of whether or not the message is a workflow message. If a determination is made that the message is a workflow message, the process passes to block  718  which depicts sending the workflow reply message to the workflow reply queue. Thereafter, block  720  illustrates deleting the cached automation request information. The process then passes back to block  702 . Referring again to block  716 , if a determination is made that the message is not a workflow message, the process passes to block  722  which depicts sending the workflow reply message to the internal request reply queue. The process then passes to block  720 .  
         [0083]     It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMS, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.  
         [0084]     The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.