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.
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.
In the following, there are several use cases listed where the Job Framework can be useful:
The Job Framework offers the following features:
|IOM||The abbreviation for Intershop Order Management|
The following steps are necessary to create a new job and execute it at runtime:
bakery.persistence.dataobject.job.Jobas a local stateless session bean.
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.
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.
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.
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).
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.
All existing Schedule locks (ScheduleDO.lockedSince) are removed to ensure that pending jobs get reactivated.
Since IOM 188.8.131.52
Schedules who had reached their max number of retries, are reactivated only when the attribute "reactivateOnStart" is set to true.
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.
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.