Document Properties
Kbid28D528
Last Modified22-Jun-2020
Added to KB08-Jan-2018
Public AccessEveryone
StatusOnline
Doc TypeGuidelines, Concepts & Cookbooks
Product
  • IOM 2.0
  • IOM 2.1
  • IOM 2.2
  • IOM 2.9
  • IOM 2.15
  • IOM 2.16
  • IOM 2.17
  • IOM 3.0

Concept - IOM Job Framework

1 Introduction

The IOM Job Framework encapsulates timed jobs so that jobs can be developed independently1 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.

Info

1 In this context, independently means that it is not required to care about the Quartz-framework that is technically related (and used) for the IOM Job Framework. The user can focus on the business context.

1.1 Use Cases

In the following, there are several use cases listed 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

1.2 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 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

1.3 Glossary

TermDescription
IOMThe abbreviation for Intershop Order Management

1.4 References

2 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.

With the first two steps, everything is done from the implementation side, the job is known in the system. For the execution, at least step 3 is required.

2.1 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.

CLS Datenmodell Jobs Schedules

2.2 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.

SEQ Timer

2.3 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).

2.3.1 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.

2.3.2 On server start (Schedules)

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

Note

Since IOM 2.9.5.0
Schedules  who had reached their max number of retries,  are reactivated only when the attribute "reactivateOnStart" is set to true.

2.3.3 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.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets