Document Tree
Document Properties
Kbid
28D528
Last Modified
05-Apr-2023
Added to KB
08-Jan-2018
Public Access
Everyone
Status
Online
Doc Type
Concepts
Product
  • IOM 4.0
  • IOM 4.1
  • IOM 4.2
  • IOM 4.3
  • IOM 4.4
  • IOM 4.5
  • IOM 4.6
  • IOM 4.7
  • IOM 5.0
  • IOM 5.1
Concept - IOM Job Framework

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.

References

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.

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

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.

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.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Home
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to supportadmin@intershop.de if you experience login issues,
or if you want to register as customer.