A few modifications might be required to the script to accommodate variations in specific installation file paths. The install_service.bat file can be used to install the service. For example, if the processor is only to process NONMEM and R process types, then the file would look something like this: The types of processes that are processed on a server can be limited by removing or commenting unused process types. The example configuration file that is shipped with the product contains definitions for all process types. ![]() Defines, in seconds, how often requests are sent to the Queue. Port to use when accessing the Queue Server. If not specified, then a UNC path is constructed in the form: \\server\PathFromRoot for shortcut results. If the share name is specified, Phoenix shortcuts use the share name when constructing UNC paths to the file. This is useful when there are shortcut results. Name that the output folder is shared as on the network. OutputShareName: Not a required attribute. If not specified, a temporary folder is created and deleted after execution and results are returned to the Queue. Each job creates a unique subdirectory based on the Job ID. Root location for output from this job type. If not specified, no job specific log info will be available in the Queue. File name to use for job specific log information requested by the Queue. Indicate if more than one instance of this process type can execute simultaneously. This value should only change if a custom processor is required.ĪllowConcurrentExecution: Required attribute. Java class to use to process all jobs for that type. Valid names include: r, sas, nonmem7, psn, and custom.Ĭlass: Required attribute. Processor element configuration attributes: Maximum number of lines to return when log info is requested by the Queue. Maximum number of processes the server can execute simultaneously. Processors element configuration attributes: Valid values include: ALL, FINEST, FINER, FINE, CONFIG, INFO, SEVERE, WARNING, and OFF. Settings element configuration attributes: ![]() Configuration consists of specifying the queue address, defining which types of processes the server can execute, specifying the number of concurrent processes the server is allowed to process, and process-specific attributes such as desired output location. RPS processors are configured by editing the file serverConfig.xml. See “Windows Service Notes” and “Linux Daemon Notes” for some platform-specific information. Modify the serverConfig.xml file as needed (discussed below).Īfter saving changes to serverConfig.xml start the RPS by opening a command window, navigating to the installation folder and typing the following: Unzip PhoenixJobProcessor.zip into the new installation folder. The executing machine must be able to ping the machine where the RPS Queue is installed.Ĭreate a new folder where the RPS processor will be installed. The queue will only send a processor jobs of types that it is configured to process.Ĭopy PhoenixJobProcessor.zip to the machine that will perform the execution. For instance, there could be one server that only processes R jobs, one server that only processes NONMEM jobs, and yet another server that processes R, NONMEM and SAS jobs. RPS processors can be installed on any number of servers, and each processor can be configured to process different job types. This section includes the following topics:Įach RPS processing server should contain only one RPS processor installation, but each processor installation can be configured to process multiple jobs concurrently. The RPS Queue and RPS Processor work together to efficiently submit the remote jobs to the various programs and return the results. The RPS (Remote Processing Server) allows users to submit particular steps in their workflows to external programs (e.g., NONMEM, SAS, etc.) for remote execution.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |