Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Naming Conventions

  • There are probably as many naming conventions as there are users of JobScheduler.
  • We do not urge on our users specific conventions, however, some best practices might be interesting to consider.

Installation

  • Installation Path
    • Recommendations
      • We suggest to create a folder structure that includes the vendor name, product name and release
        • Examples: 
          • C:\Program Files\sos-berlin.com\jobscheduler\scheduler110
          • C:\Program Files\sos-berlin.com\jobscheduler_agent\jobscheduler_agent.1.10
      • We suggest to separate the programm 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 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\scheduler110
            • Configuration Path: C:\ProgramData\sos-berlin.com\jobscheduler\scheduler110
          • Unix
            • Installation Path: /opt/sos-berlin.com/jobscheduler/scheduler110
            • Configuration Path: /home/jobscheduler_user/sos-berlin.com/jobscheduler/scheduler110
  • Scheduler ID: this configuration item identifies a JobScheduler environment
    • This ID is used
    • This ID is stored in the JobScheduler database. Therefore, if you run a number of JobScheduler instances that should share the same database connection (and schema) then you have to use different IDs
    • Recommendations 
      • Use prefixes such as dev, test, uat, prod, to indicate the environment that the respective JobScheduler instance is used for. This would help to identify misconfigured database connection.
  • 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
    • Recommendation
      • Use a four digit port if you access JobScheduler by the built-in web server.
      • Use a five digit port if you access JobScheduler via Jetty.
      • 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 distinguis the components.
      • Use an arbitrary port number for the Master and 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 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 accounts 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 change passwords.

Configuration

  • As a rule of thumb it is not too important to have most elaborated naming conventions for each object type, but it is helpful to be able to distinguish the objects such as jobs, job chains and orders from their name. This will be extremely helpful when analyzing logs that would not show the file extension (*.job.xml, *.job_chain.xml, *.order.xml) but the basename of the object.

Jobs

  • 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 never 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 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 be clicked on by your operations team.

Job Chains

  • Job Chain Name
    • A job chain name is unique within the folder where it is located.
    • Recommendations
      • A job chain quite often is the result of the mapping of a business process to an IT process. Therefoe it might not be a bad idea to use the name of the business process that is implemented by the job chain for its' name.
  • Job Chain Titlle
    • Recommendations
      • The same recommendation applies as for jobs

Orders

  • Order ID
    • The Order ID is unique across a JobScheduler environment.
    • Orders are triggers that will start a job chain. Therefore it might not be a bad idea to add the name of the respective occurrence - either time based or event based - to the name of an order.
    • Recommendations
      • Add the order occurrence to its name.It is somewhat redundant to add a reference to the job chain to an order as the order file name is anyways created from the Order ID and the job chain name.
      • Examples
        • daily_morning
        • end_of_day_processing, end_of_week_processing, end_of_month_processing
  • Order Title
    • Recommendations
      • The same recommendation applies as for jobs

Locks

  • 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 access to the same tables in a database.

Process Classes

  • Process Class Name
    • Process classes can be either used 
      • to restrict parallelism for a group of jobs
      • to assign the execution of a job or job chain to an Agent
    • Recommendations
      • Decide on the use case of your process class:
        • If it is intended to limit the number of processes for a group of jobs then specify the group for the name of the process class.
        • If it is intended to specify an Agent then use the purpose of that Agent, e.g. the application, for the name of the process class. Do not use the hostname that the Agent is operated for.
      • Examples
        • long_running for a process class with a smaller number of processes and slower throghput.
        • short_running for a process class with a larger number of processes and faster throughput.
        • accounting_system, crm_system for process classes that are used for programs or scripts of the respective applications.

 

  • No labels