Introduction

The IOM Job Framework encapsulates timed jobs so that jobs can be developed independently¹ from the underlying timer framework (such as Quartz). This feature provides the ability to define the timing (through cron expressions) in the database and start and stop the jobs. Runtime-relevant data are also recorded and are available for evaluation. The target audiences are partners, consultants and developers of Intershop.

References

• Cookbook - IOM Job Framework
• Concept - IOM Quartz Jobs
• For JobDefDO see Reference - IOM Database Documentation
• Overview - IOM Database Documentation
• Reference - IOM Schedule Jobs

Use Cases

There are several use cases where the Job Framework can be useful:

• Create customized reports in a scheduled way, for example, sales analytics
• Sending data to external systems
• Fetching data from external systems

Features

The Job Framework offers the following features:

• Simple job configuration
• Configuration of jobs at run-time:
  • Disable/enable jobs via active flag
  • Change of timings
• Simple job implementation, see Cookbook - IOM Job Framework
• Exception handling with a retry mechanism
• Job-run-history logging for further evaluations, such as:
  • Job start, end, run-time
  • Job status
  • Job exit codes (OK, ERROR, or WARN)
  • Error messages

Implementation

The following steps are necessary to create a new job and execute it at runtime:

1. Implement the interface bakery.persistence.dataobject.job.Job as a local stateless session bean.
   See Cookbook - IOM Job Framework for details.
2. Register the new bean with the jndiName in bakery.persistence.dataobject.job.ExpandedJobDefDO.
3. Create a new entry in ScheduleDO.
   If necessary, entries in a bean-specific configuration table.

Data Model - Jobs and Schedules

The following diagram shows data objects that are used by the Job Framework and its relations.
The diagram does not claim to be complete and serves as a rough overview only. The marked section Persisted shows objects that are persisted in the database.

Sequence Diagram

The following diagram shows message action between the actors within the Job Framework.
The diagram does not claim to be complete and serves as a rough overview only.

Error Handling

The Job Framework "knows" about two basic types of exceptions in which the normal execution of the job is not possible.
One exception occurs if a resource is temporarily unavailable, the other type of exception occurs if the situation cannot be cleaned up by the system, but requires manual intervention.
The first situation is described with Retry, the other with Exception.
A retry is noted in the log, but there is (normally) no information for the operations department. An exception always leads to a message to operations (internal error mail).
This means that throwing an exception must be considered to minimize the number of manual interventions. On the other hand, the overall system should not end up in an inconsistent state (just think of order-sensitive processing of article data).

Retry

A retry is thrown primarily by the jobs themselves. The framework updates the next run and checks the number of retries. If it exceeds a configured threshold, the retry becomes an exception.

On server start (Schedules)

All existing Schedule locks (ScheduleDO.lockedSince) are removed to ensure that pending jobs get reactivated.

Exception

The framework differentiates between JobRunStateDefDO.CodedException and RuntimeException.JobRunStateDefDO.CodedException also provides the processing step in which the error occurred. A RuntimeException only catches all other unexpected errors. The treatment of the two errors does not differ in the end.