Task: Message-Use a Windows service to start WebSphere MQ File Transfer Edition Guest

Task: Message-Use a Windows service to start the WebSphere MQ File Transfer Edition client proxy

Replacing FTP clients with IBM®WEBSPHERE®MQ file Transfer Edition client proxies on the user's desktop is a good way to provide enterprise visibility and manageability to these file transfers. The user can start the WebSphere MQ File Transfer Edition Proxy, or place it in the Startup folder so that Windows® starts it automatically. But what if this client agent needs to run on a Windows server rather than on the desktop? After all, there are no user sessions and startup folders on the server. You can create a service from Ftestartagent, but this service initiates a child process, so it is difficult for Windows to monitor the process to restart the client agent. You can also call a class directly from the Ftestartagent call, but this requires the use of some (undocumented) interfaces that are not built, which may change in future versions. If possible, it is best to avoid the ability to use an unsaved document. This issue of "task: Message" will demonstrate how to use the Ftestartagent and WebSphere MQ triggers to solve this problem.

Brief introduction

In my earliest WebSphere MQ file Transfer Edition deployment, my clients wanted to run the WebSphere MQ file Transfer Edition client proxy on some unattended Windows servers. Although the WebSphere MQ File Transfer Edition does not now provide a Windows service, it is not difficult to make the agent run as a background task. The real trouble is how to make them resilient. The ftestartagent command generates a child process and then terminates. This means that if configured as a Windows service, it will either not reboot or try to reboot at each interval. We can bypass the Ftestartagent proxy to invoke the underlying class to start the proxy directly, but we must be careful not to use the file (documented) command.

The solution we have decided to use is the subject of this article. It consists of two parts: a Windows Service Trigger monitor program provided by Supportpac ma7k, and a small amount of "glue" code written in Perl. Not only does it launch the WebSphere MQ File Transfer Edition Proxy in an ideal way, it also makes this agent very difficult to terminate.

The core component is Supportpac ma7k, which relies on WebSphere MQ Client. The WebSphere MQ Client is available as a Supportpac MQC7. The ma7k service connects to a queue manager and listens for the so-called initiation Queue (initiation queue). The queue Manager is configured to place a message on this queue to respond to a message that arrives in the command queue (the commands queues) of the WebSphere MQ File Transfer Edition Proxy. When a trigger message is received, the triggering monitor resolves the command that will be executed and any parameters. The content is assembled into a running command line, and then controls the return result of the trigger monitor that restores monitoring on its originating queue.

Perl code is necessary because the trigger monitor assumes that the program that will be started is written to trigger and passes the entire TMC2 trigger message as a parameter. Of course, the Ftestartagent program is written for humans, not trigger monitors, and there is no concept of how a TMC2 structure looks. Therefore, if it is started directly by the triggering monitor, it will not run. A small Perl program acts as a "shim" between the ftestartagent and the trigger monitor, using the TMC2 parameter and converting it to a ftestartagent native parameter value. Perl is selected for its string-handling capabilities and is installed on all versions of the Windows server and is available at all times. It can also be compiled into a native Windows executable that runs without having to install Perl.

The final step is to configure the queue manager for triggering. This includes defining a process object and enabling the trigger on the broker command queue. The process definition includes the fully qualified command that will be used to start the agent, and the name of the agent that will be started.

When we installed the first Agent trigger monitor on this project, we found some other benefits. A single trigger monitor can handle any number of proxies on the same Windows server. Using the trigger monitor also means that the WebSphere MQ administrator can start or stop the remote Client agent from the Queue Manager without logging on to the Windows server running the agent. One problem my customers have encountered is that WebSphere MQ administrators do not have direct access to Windows servers, in which case the ability to remotely start and stop agents is particularly useful.

The following steps will help you set up your own Windows client trigger monitor to start the WebSphere MQ File Transfer Edition Proxy. These instructions assume that the WebSphere MQ File Transfer Edition Client Agent has been installed to C:\IBM\WMQFTE and that the configuration directory is C:\IBM\WMQFTE\config. I found that it would be much easier to manage the WebSphere MQ File Transfer Edition on Windows If you used a short pathname without embedded spaces. The path to the account running the trigger monitor should have C:\IBM\WMQFTE\bin and Perl runtime. Before you begin installing the tools described in this article, it is a good idea to configure the WebSphere MQ File Transfer Edition Agent and ensure that it runs correctly.

Set up and test a Windows client trigger monitor

Install ftetriggeragent.pl

Download the ftetriggeragent.pl file and place it in the C:\IBM\WMQFTE\bin directory on the server where the WebSphere MQ file Transfer Edition Agent will run.

This script assumes that the WebSphere MQ file Transfer Edition is installed in C:\IBM\WMQFTE\ and attempts to write the log file to C:\IBM\WMQFTE\Logs. If the path above does not exist, the script will attempt to create it. If you want the log file from the ftetriggeragent.pl script to be written to a different directory, you need to change the $LogPath variable that is near the top of the script.

This script file should have the same ownership and permissions as the rest of the files in C:\IBM\WMQFTE\bin. To run this script, the. pl extension should be associated with the Perl executable file. (If you want to compile this script into an executable file, see Perl Pro Studio from Active state.) ）