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.
English Japanese
Additionally or alternatively to a periodic execution, you can define ticket events that will trigger this job.
If a ticket event is fired, the ticket filter will be applied to check if the ticket matches. Only then the job is run on that ticket.
Add dynamic field
Do you really want to delete this error handling module?
The name can be used to distinguish different error handling configurations.
This OTRS error handling backend module will be called internally to process the error handling mechanism.
Configure filters to control error handling module execution.
Only requests matching all configured filters (if any) will trigger module execution.
Note: Operation is undetermined for errors occuring while receiving incoming request data. Filters involving this error stage should not use operation filter.
Enter a regular expression to restrict which error messages should cause error handling module execution.
Error message subject and data (as seen in the debugger error entry) will considered for a match.
Example: Enter '^.*401 Unauthorized.*\\$' to handle only authentication related errors.
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.
This identifier 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.
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.
Retry options are applied when requests cause error handling module execution (based on processing options).