Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Introduction

Excerpt

The JOC cockpit Cockpit allows service providers to configure both shared and dedicated services over any number of JobScheduler Masters.

The JobScheduler Masters can then be operated, managed and monitored from a single user interface and with permissions and roles assigned for each Master.

The JOC Cockpit can also be configured to work with JobScheduler Masters that use different databases and database management systems.

Architecture-Based Multi-Client Capability

...

  • Increased processing requirements and resource consumption of one user client will not affect the processing capacity available for another, meaning that service requirements can be clearly stated and met.
  • Maintenance windows, Planned down-time / maintenance windows for software updates, hardware upgrades, etc. can be implemented individually according to customer requirements.Changes such as software updates and hardware upgrades can be implemented independently according to client wishes.

The use of individual JobScheduler Masters for individual clients also allows authorization - the allocation of user rights and permissions determining what a user is allowed to do - to be granted according to duties or roles. This approach may be contrasted with other systems that allocate rights and permissions according to resources such as files or folders. See the JOC Cockpit - Authentication and Authorization article for more information.

JobScheduler makes use of two logically separate database instances:

  • JobScheduler Database
  • Reporting Database

All JobScheduler Master instances that should be managed with the same JOC Cockpit instance have to use the same Reporting Database. However, the Master instances can use the same or different JobScheduler Databases. 

For more information see

Configuration when JobScheduler Masters use Different Databases and DBMSs

This section describes how to configure the JOC Cockpit to operate with different JobScheduler Masters that are using different databases. Note that this is only possible when these JobSchedulers are configured to use different JobScheduler and Reporting databases.

The database configuration information for each JobScheduler Master is stored in a hibernate XML configuration file. By default this file is named hibernate.cfg.xml and is to be found in the $SCHEDULER_DATA/config/ directory of each JobScheduler Master.

The configuration information that the JOC Cockpit uses to access the JobScheduler Master databases is stored in one or more hibernate XML configuration files. The default locations for these files are:

  • /home/[JOCC user]/sos-berlin.com/joc/resources/joc on Linux systems and

  • C:\ProgramData\sos-berlin.com\joc\resources\joc on Windows.

When the JOC Cockpit is used with one or more JobScheduler Masters that are using a common database then the hibernate information file is named jobscheduler.hibernate.cfg.xml. The location of this file is specified in the joc.properties file that by default is stored in the same folder as the jobscheduler.hibernate.cfg.xml file.

Hibernate configuration files for databases used by specific JobScheduler Masters can be configured where each file is named according to the format:

  • <jobschedulerID>.hibernate.cfg.xml

where <jobschedulerID> is the ID of the relevant JobScheduler Master.

These files can be stored in the same folder as the joc.properties file or in another folder.

These files have to be listed in the joc.properties file in the section:

  • ### Path to hibernate configuration file of a JobScheduler database.

with each list entry following the pattern:

  • hibernate_configuration_file_<jobschedulerID> = <jobschedulerID>.hibernate.cfg.xml

where <jobschedulerID> is the ID of the relevant JobScheduler Master.

If the hibernate database configuration files are not stored in the same folder as the joc.properties file, the files are to be listed as follows:

  • hibernate_configuration_file_<jobschedulerID> = <path><jobschedulerID>.hibernate.cfg.xml

where <path> is either relative to the joc.properties file or absolute.

For more information see