The Features of BICsuite and schedulix

Branches

Branches can be implemented in alternative sub-workflows using dependencies that have the exit state as a condition.

Hierarchical workflow modelling

Among other benefits, hierarchical definitions for work processes facilitate the modelling of dependencies, allow sub-processes to be reused and make monitoring and operations more transparent. The additional Milestone object type makes it easier to model complex workflows.

Job and batch parameters

Both static and dynamic parameters can be set for Submit batches and jobs.

Job result variable

Jobs can set any result variables via the API which can then be easily visualised in the Monitoring module. Results can impact the rest of the workflow due to conditional dependencies, resource requirements and triggers.

Dynamic submits

(Sub-)workflows can be dynamically submitted or paralleled by jobs using the Dynamic Submit function.

Pipelining

Local dependencies between parts of the submitted batch instances are correctly assigned when parallelising batches using the Dynamic Submit function. This hugely simplifies the processing of pipelines.

Job and batch triggers

Dynamic submits for batches and jobs can be automated using exit state-dependent triggers. This allows notifications and other automated reactions to workflow events to be easily implemented.

In addition to the exit state and trigger type, events can also be specified more precisely by defining a condition. Additional trigger types allow reactions to be given to warnings and extend the functionality of loops. Additional asynchronous triggers enable events to be triggered during runtime. This also allows for reactions to runtime timeouts.

Loops

Automatic reruns of sub-workflows can be implemented by using triggers.

External jobs

So-called ‘pending’ jobs can be defined to swap out sub-workflows to external systems without overloading the system with placeholder processes.

Audit

All special events and operator actions are logged in an audit trail.

Warning system

Warnings can be dynamically set by jobs and attended to by the operator. The occurrence and handling of warnings are logged in the audit. Automatic reactions are possible using warning triggers.

Folders

Job, Batch and Milestone workflow objects can be orderly organized in a folder structure.

Folder parameters

All jobs below a folder can be centrally configured by defining parameters at folder level.

Folder environments

Requirements for static resources can be configured to be inherited by all jobs below a folder by defining folder environments. This allows jobs to be assigned to different runtime environments (development, test, production, etc.) dependent upon a higher-level folder.

Folder resources

Resources can also be globally instanced at folder level as well as in the workflow environment, making them available to all the jobs below this folder.

Job and batch resources

Instancing resources at batch or job level allows a workflow load generated by hierarchically subordinate jobs to be locally controlled.

Static resources

Static resources can be used to define where a job is to be run. If the requested resources are available in multiple environments, the jobs are automatically distributed by the schedulix and BICsuite Scheduling System.

Load control

A quantity of available units of a resource can be defined for runtime environments using system resources. A quantity can be stated in the resource requirement for a job to ensure that the load on a resource is restricted.

Job priority

The job priority can be used to define which jobs are to take priority over other jobs when there is a lack of resources. Jobs can be prevented from ‘starving’ with a configured ‘priority aging’ which automatically raises their priority over the time span.

PROFESSIONAL and ENTERPRISE: The job priority aging can be configured individually for each job

Load balancing

The interplay of static and system resources allows jobs to be automatically distributed over different runtime environments dependent upon which resources are currently available.

Synchronizing resources

Synchronizing resources can be requested with different lock modes (no lock, shared, exclusive, etc.) or assigned them for synchronizing independently started workflows.

Sticky allocations

Synchronizing resources can be bound to a workflow across multiple jobs with sticky allocations to protect critical areas between two or more separately started workflows.

Resource states

A state model can be assigned to synchronizing resources and the resource requirement can be defined dependent upon the state. Automatic state changes can be defined dependent upon a job’s exit state.

Resource expirations

Resource requirements can define a minimum or maximum time interval in which the resource was assigned a new state. This allows actuality and queue conditions to be easily implemented.

Resource triggers

A reaction to the changing states of synchronizing resources can be triggered with an automatic submit of a batch or job. After the state transition, the activation of the trigger can be more precisely specified with an extra condition.

Resource parameters

Resource parameters allow jobs to be configured dependent upon the allocated resource. Resource parameters of exclusively allocated resources can be written via the API. This allows resources to be used to store meta data.

Scope parameters

Scope parameters allow jobs to be configured dependent upon the effective execution environment.

Resource pools

Resource pools allow system resources to be automatically and dynamically shared between one or more pooled resources. This enables system resources to be easily shared between workgroups and projects, and this dispersion can be adapted whenever necessary to accommodate actual requirements using pool distributions.

Resource tracing

Resource loads can be selectively logged for system analysis and tuning purposes.

Object Monitoring

Object Monitoring, like the monitoring of a directory, can be easily installed. The scheduling system will react automatically to events like file creation, file changes or file deletion.

Nice Profiles

With Nice Profiles priorities and suspend state of already submitted and newly submitted batches and jobs can be adapted to special system states like backlog situations.

Access controlling

Authentication routines for job servers, users and jobs using IDs and passwords are effective methods of controlling access to the system.

Privileges

Time scheduling

The schedulix and BICsuite Time Scheduling module allows workflows to be automatically run at defined times based on complex time conditions. This usually obviates the need for handwritten calendars, although they can be used whenever required.

Export / Import

The dump functionality enables the export and import of any modelling objects under the detailed control of the linked objects involved and allows their deployment between different system environments (development, test, production, etc.) as well as versioning in external source code control systems (rcs, cvs, svn, etc.).

Web Interface

The schedulix and BICsuite web front end allows standard browsers to be used for modelling, monitoring and operating in intranets and on the internet. This obviates the need to run client software on the workstations.

API

The full API of the BICsuite Scheduling System allows the system to be completely controlled from the command line or from programs (Java, Python, Perl, etc.).

Repository

The schedulix and BICsuite Workload Automation System stores all the information about modelled workflows and the runtime data in an RDBMS repository. All the information in the system can be accessed via the SCI (Standard Catalog Interface) whenever required using SQL.

Warm Standby

More demanding availability requirements can be supported with proxies and a warm standby function if a suitable RDBMS system is available.

SSL/TLS

The secure network communication of the schedulix and BICsuite components via SSL/TLS also fulfils more stringent security standards.

Approvals

The Approval system allows to configure a four eyes principle for critical operator actions.