The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not update the repository.

Source string Source string

14/10000 · 14
English Actions
Only execute error handling module on errors that occur during specific processing stages.
Example: Handle only errors where mapping for outgoing data could not be applied.
Error code
An error identifier for this error handling module.
This identifier will be available in XSLT-Mapping and shown in debugger output.
Error message
An error explanation for this error handling module.
This message will be available in XSLT-Mapping and shown in debugger output.
Define if processing should be stopped after module was executed, skipping all remaining modules or only those of the same backend.
Default behavior is to resume, processing the next module.
This module allows to configure scheduled retries for failed requests.
Default behavior of GenericInterface web services is to send each request exactly once and not to reschedule after errors.
If more than one module capable of scheduling a retry is executed for an individual request, the module executed last is authoritative and determines if a retry is scheduled.
Request retry options
Retry options are applied when requests cause error handling module execution (based on processing options).
Schedule retry
Should requests causing an error be triggered again at a later time?
Initial retry interval
Interval after which to trigger the first retry.
Note: This and all further retry intervals are based on the error handling module execution time for the initial request.
Factor for further retries
If a request returns an error even after a first retry, define if subsequent retries are triggered using the same interval or in increasing intervals.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute' and retry factor at '2', retries would be triggered at 10:01 (1 minute), 10:03 (2*1=2 minutes), 10:07 (2*2=4 minutes), 10:15 (2*4=8 minutes), ...
Maximum retry interval
If a retry interval factor of '1.5' or '2' is selected, undesirably long intervals can be prevented by defining the largest interval allowed.
Intervals calculated to exceed the maximum retry interval will then automatically be shortened accordingly.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute', retry factor at '2' and maximum interval at '5 minutes', retries would be triggered at 10:01 (1 minute), 10:03 (2 minutes), 10:07 (4 minutes), 10:12 (8=>5 minutes), 10:17, ...
Maximum retry count
Maximum number of retries before a failing request is discarded, not counting the initial request.
Example: If a request is initially triggered at 10:00 with initial interval at '1 minute', retry factor at '2' and maximum retry count at '2', retries would be triggered at 10:01 and 10:02 only.
Note: Maximum retry count might not be reached if a maximum retry period is configured as well and reached earlier.

Loading…

User avatar None

New source string

OTRS / i18n — English

New source string 4 years ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

String information

Source string description
Template: AdminGenericInterfaceErrorHandlingRequestRetry
Flags
read-only
String age
4 years ago
Source string age
4 years ago
Translation file
string 635