# Request management

# Introduction

You can use Request Management to execute processes in the background. This is necessary for processing requests that could potentially take a long time. The aim of Request Management is to create an expandability for future requests (such as download). This native CoreEngine module is not supported by default for all users.

The storage of the module configuration is described in:

modules/request_mngt/

Request types are described in concrete terms; so far, the request contains.

Manage the following types of operations:

  • Upload
  • Download
  • Mass indexing
  • E-Ticket
  • Report Creation
  • PDF Creation

After the start of a request (upload, download, etc.) the Request Management table request_mngt an entry is made and passed to the respective request processors and processed. The respective "status" is set by the processor and back to request management, which sends the respective message gives.

# Fields

Path of the Fields:

ce_modules/request_mngt/fields
Felder
Feldname Type Description
status CEInteger
Status of the request:

The values for the respective processing status. Values including the labels for display in the frontend.

See also RequestStatus <requestStatus>

data CEText
Data for the request processor:

Request/Response information for the request processor to process the data. Example contents include form and related beanid.

instance_id CEVarchar
Processing on different instances:

The instance ID specifies the instance (server) in the network on which the request is/was executed.

mode CEInteger
Synchronous or asynchronous:

Mode indicates whether the processing mode is synchronous or asynchronous. A request is synchronous if it does not have a timeout. If it does, the request is processed asynchronously. In asynchronous processing, a token is provided for the frontend to retrieve the request (for example, a download link).

timeout_time CETimestamp
Time of the timeout:

Time at which job(s)/process(es) run into the timeout This time results from the Creation_Time+Timeout. The time for the timeout is configurable and depends on the respective job.

retry_count CEInteger
Counter for the timeout:

At errors the counter counts down from the configured value to 0. If not equal to 0, the request is tried to be executed again after the timeout has expired. If 0, the request is set to error..

tec_pro_inf CETextList
Error Information:

List of errors/error messages with detailed information for the administrator

# Permitted values for status

Status Value Description
0 Initial Initial creation of the request
1 In process The operation is currently being processed by the system
2 Finished with errors The process was completed with errors
3 Completed The process was completed successfully
4 Error The process was aborted due to an error
5 Cancellation by user The process was aborted by the user

# Views / Admin GUI

The view is configured for the module so that the data is transferred to the frontend can be delivered.

  • Status
  • Creation date
  • Modified on
  • Creator

# Configuration

Request jobs can be created in each module:

ce_modules/{module}/request_job/*.4apreqjob

Example configuration:

<?xml version="1.0" encoding="UTF-8"?>
<request_job>
   <name>file_processing</name>
   <info>Import and generation of filehash, preview, metadata etc.</info>
   <threads unit="absolute">8</threads>
   <classPath>com.cm4ap.ce.fsi.requestjob.FileProcessingJob</classPath>
   <mode>async</mode>
   <timeout>3600000</timeout> <!-- 60 minutes -->
   <retry_count>3</retry_count>
</request_job>
Elements of the XML
Element Description default
name Name des Jobs
info About the job
threads Number of threads created for the job type. At least 1 thread is created.
Allowed values:
  • absolute: Number of threads that are created. (Integers >= 1)
  • percent: Factor multiplied by the number of cores visible to the JVM (decimal numbers)
1
classPath Path to job class
mode Permitted values are: sync, async und hybrid hybrid
timeout Timeout, after a process is regarded as faulty and repeated by a new job. 120000 (2 minutes)
retry_count Number of attempts if the job runs on errors 3
Request missing documentation