Introduction

This document explains how the interrupt process is handled by the process chains. This
technical description supposes that the reader has a good knowledge of the process chain
development.
The page Summary (analyze helper) aims to help in the analyze of the interrupt event
failures.
The technical aspects are vaild with the BW version 7.30 (support package 7).

What is an interrupt process?

The chain is scheduled with an interrupt process
inside:

The start conditions of

the interrupt process
are:

The process chain scheduling creates 2 jobs for this interrupt

process in the table TBTCO:

The job BI_PROCESS_INTERRUPT manage the process step behavior and records the
waiting for the event.
The
BI_INTERRUPT_WAIT
is scheduled
to start
the
interrupt
It consumes
the
If thejob
chain
is not scheduled then
the system
doeson
not
handle
the event.
interrupt
event.
event.

Case 1: The interrupt event is raised while the interrupt process is waiting - 1

The process chain started and reached the

interrupt step. The interrupt process is
waiting for the event:

The job BI_PROCESS_INTERRUPT is executed. It creates an entry in the table

RSPCINTERRUPTLOG:
LOG_ID: chain log
INSTANCE: identifier of the current interrupt process
FINISHED: empty value means the interrupt process is waiting for the interrupt event
REPORTED: the UTC date & time of the update
If an entry was existing with FINISHED empty then it was deleted.
The job BI_PROCESS_INTERRUPT is finished and a new one is created because the interrupt
process is periodic (table TBTCO):

Case 1: The interrupt event is raised while the interrupt process is waiting - 2
The interrupt event is raised by another chain or manually.
The job BI_INTERRUPT_WAIT starts and identifies the process chain and the process variant.
In the table RSPCINTERRUPTLOG, it selects the entry for the chain, the process variant, and
FINISHED empty. The field LOG_ID allows retrieving the chain run and the field INSTANCE
allows terminating the interrupt process. The entry is updated with FINISHED = X.
Table RSPCINTERRUPTLOG:

The job BI_INTERRUPT_WAIT is finished and a new one is scheduled because the job is
periodic.
Table TBTCO:

Case 2: The interrupt event is raised before the interrupt process

If the chain with the interrupt process is not already scheduled, then the event is not
followed by the system.
The interrupt event has been raised by another chain or manually.
The content of the table RSPCINTERRUPTLOG is:
This entry means that the interrupt event has been raised.
The fields LOG_ID and INSTANCE are empty. The field REPORTED is the UTC date & time of
the event creation. The field JOBCOUNT refers to the job BI_INTERRUPT_WAIT. The field
FINISHED is empty.
An entry is created for each interrupt process.
The chain having the interrupt process starts. In the table RSPCINTERRUPTLOG, the job
BI_PROCESS_INTERRUPT selects the entry with the chain, the process variant, and FINISHED
empty. This entry is deleted. A new entry is created in the table: The fields LOG_ID and
INSTANCE are updated with the parameters of the current interrupt process. The field
FINISHED equals X. The field REPORTED is the UTC date & time of the interrupt step
termination (job BI_PROCESS_INTERRUPT).

How to purge the event history?

The table RSPCINTERRUPTLOG is not purged and contains entries since 2009 in PBA.
The table has entry because the event has been raised:

Display the process chain, right-click

on the interrupt process and click on
reset interrupt. A successful
message Interrupt was successfully
reset is displayed in the status bar.
This method is also valid if the chain
is not scheduled.
The entry is deleted from
RSPCINTERRUPTLOG.

How to stop chain with interrupt process - 1?

The chain is running and wait for the

interrupt event:

The table RSPCINTERRUPTLOG should have entry corresponding to the interrupt process:

Display the chain and remove from schedule. As a consequence the current run is stopped.
If this action is not done, then the jobs BI_PROCESS_INTERRUPT and BI_INTERRUPT_WAIT
remain in the system and future events will be assigned to the wrong chain execution.
Terminate the interrupt process with the
function module RSPC_PROCESS_FINISH.
The input parameters are found in the
table RSPCINTERRUPTLOG:

How to stop chain with interrupt process - 2?

The status of the interrupt process must be cancelled (X) int the table RSPCPROCESLOG:

The chain run must be cancelled be cancelled (X) int the table RSPCLOGCHAIN:

MANUAL_ABORT = X the run was stopped manually (example: the chain is unscheduled).
The function module RSPC_API_CHAIN_INTERRUPT allows terminating a chain run by
removing it from scheduling. It leads to the same result.
The chain status is red, but the interrupt
process remains yellow.
The table RSPCINTERRUPTLOG still has the
entry.
This method avoid event desynchronization.
It is not useful to deactivate and reactivate
the chain.

How to raise an event?

The function BP_RAISE_EVENT is obsolte and has been replaced by the method
cl_batch_event=>raise.
The program BTC_EVENT_RAISE.
The transaction SM64.

These methods are compliant with the coordination between events and process chains.

Summary (analyze helper)

The event has already been raised . As a consequence, the chain will not wait. The content
of the table RSPCINTERRUPTLOG is:

The field REPORTED is the creation UTC date&time of the event. It is possible to know the
event by displaying the chain and the interrupt process (see VARIANTE).
If the event has been raised unexpectedly or must be deleted, then the page How to purge
the event history? explains the event cancellation.

The chain started and waits for the event. The event is not raised at yet. The content of the
table RSPCINTERRUPTLOG is:

If the chain is waiting for an event and the event will not raise, then the page How to stop
chain with interrupt process? explains the method to stop properly the chain execution.

Waiting job
Table BTCEVTJOB owns all jobs which are waiting an event.
For exemple, processchain XTR_TD_OD_EVENT_TESTCPS starts when event
XTR_EVENT_TESTCPS_START is raised.
Next run of start variant is identify by JOBCOUNT : 13443200

Find more details about run into TBTCO table:

Waiting job

If an event is used for several interrupt, a jobcount is saved into

BTCEVTJOB for each occurence. For example, XQM_E134 is waiting by
several processchains.

Annex
The sap note 1723513 solves the problem of malfunction with interrupt process.
Job BI_PROCESS_INTERRUPT: aims to execute the process chain step by executing the
method execute of the class CL_RSPC_INTERRUPT.
Job BI_INTERRUPT_WAIT: planned to start on the interrupt event and aims to terminate
the interrupt step with the program RSPCINTERRUPT.
SAP documentation:
http://help.sap.com/saphelp_nw2004s/helpdata/en/44/c079599d3756a2e10000000a1553f
6/frameset.htm