You can reactivate a failed integration endpoint using Disable / Enable or Resume.
- If a background process fails and the processing of data is set to strict, you have to restart the endpoint before the endpoint is able to start another background process.
- If a background process fails and the processing of data is set to chain, the remaining background processes that belongs to the chain will also fail. You have to correct the failed background process before the endpoint is able to start another background process that belong to the same chain. The endpoint will, however, continue to process data from other chained background processes.
For more information about the strict and chain settings, see Integration Endpoint Transactional Settings documentation here.
Disable and Enable a Background Process
Setting an integration endpoint to Disable and then Enable does clear the log file.
- Right-click the endpoint and select Disable Integration Endpoint.
- Right-click the endpoint again, and select Enable Integration Endpoint.
Resume a Background Process
Resuming an integration endpoint does not clear the log file
Note: Whenever the STEP system is patched or restarted, the main background process is automatically restarted. The integration endpoint log still exists, and continues to show an overview of the started background processes.
- Right-click the endpoint, and select Resume Integration Endpoint.
Resolving a Failed Background Process
Errors can happen before the background process starts, and also after it is running. The Error Reporter can be configured when creating an IIEP, as described in the IIEP - Configure Error Reporter topic here.
The two levels of failure reported in STEP are errors and warnings.
- Warnings are minor errors that do not stop the import. A warning status allows the process to complete and data validation to be performed elsewhere in STEP. For example, specifying a parent that does not exist, or an invalid value for a validated attribute.
- Errors stop the import, and prevent the endpoint from processing more data until it is restarted once the error is resolved. Errors are used in cases such as when a malformed XML file is received, or when an endpoint expects XML but an Excel file is provided.
User friendly error logging is included on the Execution Report of the background process (accessible from the Background Processes tab of the IIEP), and more technical detailed logging is in the step.0.log (accessible from the system Start Page via the STEP System Administration button).
IIEP Fails Before the BGP Starts
In cases where the IIEP fails before the BGP is initiated, a report is available in Integration Endpoint Log on the Inbound Integration Endpoint tab. Refer to this log for information to make needed corrections.
IIEP Fails After the BGP Starts
The Error Log Excerpts tab includes details about failures within the background process.
- In System Setup select the relevant integration endpoint, and then click the Error Log Excerpts tab to display a list of failed background processes and the description of the failure.
You can also see if a process has been suspended because it is dependent on a failed process.
- In the Background Process column, hover over the background process to correct and click the BGP link.
The Background Process editor displays.
- In the Background Process editor Execution Report, view the progress of the background process, and where it failed.
- In the Properties area > Value column, click the Save button (
) near the failed status, and save the file locally.
- Open the file in a relevant editor and make the required changes.
- After completing the changes, upload the file back to the same background process. In the Background Process editor > Properties flipper > Status parameter Value column, click the Upload button (
) near the failed status. - Restart the process in the Properties area > Status parameter Value column, click the Restart button (
) near to the failed status. The background process is restarted. - If the background process is part of a batch of chained processes, restart the other processes that are part of the chain.