Page History

...

• Installation Path
  • Recommendations
    • We suggest to create a folder structure that includes the vendor name, product name and major/minor release. Do not use the bug-fix number in the release number as you would update the installation later on with bug-fix releases for the same major/minor release number. Consider the below mentioned Scheduler ID configuration item that is automatically used as a sub-directory to the Installation Path and that could be used to indicate the major/minor release number that therefore could be omitted from the Installation Path.
      • Examples: 
        • C:\Program Files\sos-berlin.com\jobscheduler

        • C:\Program Files\sos-berlin.com\jobscheduler_agent
    • We suggest to separate the software Installation Path and the path for configuration files:
      • Installation Path 
        • could/should be write protected for normal users. It contains files that are exclusively modified during a software update that is typically perfomred performed by an administrator. 
        • is pointed to by the environment variable SCHEDULER_HOME.
      • Configuration Path 
        • could be writeable for a couple of users who are entitled to manage jobs by use of their personal account.
        • is pointed to by the environment variable SCHEDULER_DATA
      • Examples
        • Windows
          • Installation Path: C:\Program Files\sos-berlin.com\jobscheduler
          • Configuration Path: C:\ProgramData\sos-berlin.com\jobscheduler
        • Unix
          • Installation Path: /opt/sos-berlin.com/jobscheduler
          • Configuration Path: /home/jobscheduler_user/sos-berlin.com/jobscheduler
• Scheduler ID: this configuration item identifies a JobScheduler environment.
  • This ID is used for
    • a Passive Cluster and Active Cluster in which all cluster members have to use the same Scheduler ID.
    • individual JobScheduler instances.
  • This ID is used as 
    • a sub-directory to the Installation Path of a JobScheduler installation. It is therefore perfectly suited to indicate the major/minor release number of the JobScheduler installation.
    • a name for the JobScheduler Windows service and should comply with Windows service name conventions.
  • This ID is stored in the JobScheduler database. 
    • Therefore, if you run a number of JobScheduler instances that share the same database connection (and schema) then you have to use different Scheduler IDs.
    • Consider using different Scheduler IDs when running JobScheduler instances with different databases or schemas. The history data from all instances could later on be consolidated to a reporting database that requires a different Scheduler ID to be used for each instance.
  • Recommendations 
    • Use prefixes such as dev, test, uat, prod, to indicate the environment that the respective JobScheduler instance is used for. This will help to identify e.g. misconfigured database connections.
    • Use the major/minor release number in the Scheduler ID.
    • Decide if you run JobScheduler as a shared service or as a dedicated service for your audience. A shared service would refer to a single central instance on one server whereas a dedicated service could lead to multiple instances on the same or different servers. If you intend a dedicated service then add the name of the project or application to the Scheduler ID.
    • Examples
      • scheduler_dev_110
      • bancs_uat_scheduler19
• Port
  • There is no reserved Port for JobScheduler. We chose 4444 as a default for the JobScheduler Master and 4445 for the Agent as these ports tend to be rarely used, see Service Name and Transport Protocol Port Number Registry
  • Recommendations
    • Do not use the same port numbers for Master and Agent. You might not be able to tell from the hostname if the JobScheduler instance works as a Master or Agent, therefore it might be helpful to use the port number to distinguish both components.
    • Use an arbitrary port number for the Master and try to use the same port number for all Agents. In most cases you will run one Master but you might operate any number of Agents. The automated roll-out of Agents is simplified if they can use the same port number. 
• Account
  • Do not run the JobScheduler with a root Account. This would introduce security risks as job scripts could switch to any user account and perform jobs for that user.
  • Recommendations
    • Use a System Account for the JobScheduler Windows service.
    • Use a dedicated User Account for the JobScheduler daemon with Unix.
    • Why not use the same Account for running the JobScheduler and for access to the JobScheduler database? For systems with integrated security, e.g. Oracle, SQL Server, this allows to use the same Account and to centrally manage the Account, e.g. for password change.

...

• Job Name
  
  • A Job Name is unique within the folder where it is located.
  • Recommendations
    • Use lowercase Job Names. Though you might be tempted to use camel case names, e.g. with case-sentive file systems as for Unix, there is hardly any reason to use the same name with different spellings for different jobs - except for unwanted complexity.
      • For Windows systems JobScheduler is not case-sensitive when it comes to file names.
      • For Unix systems JobScheduler preserves respects case-sensitivity.
    • Jobs are performing operations, therefore we recommend to use a naming convention that requires a verb and an object for a Job Name.
    • Examples
      • convert_txt2pdf
      • check_file_existence
      • import_csv2database
• Job Title
  • Recommendations
    • The Job Title can be used as a plain text confiuguration item, however, if you add a URL such as http://myknowledgebase/job_explanations/... to the title then this will be displayed as a link in the JOC GUI that can andcan be clicked on by your operations team and that e. Such links could  e.g. could point  point to a knowledge base with more information about the job.

...

• Lock Name
  • The nature of locks is to be unique across a JobScheduler environment. A lock has a name and a path that is created from its location. 
  • Should you have multiple locks with the same name in different folders then this is technically viable, however, it reduces the visibility and applicability when it comes to analyzing logs.
  • Recommendations
    • The usefulness of a lock is to restrict access to a resource. Therefore we recommend to use the resourece name as the lock name.
    • Examples
      • accounting_tables for a lock that restricts is intended to restrict parallel access to the same tables in a database.

Process Classes

...