Data Security Concept In the automated Action Handler, the data security concept guarantees data consistency when an error occurs or an action cannot be carried out and posted because of a system crash.
See Automated Action Handler .
You set the event parameter TABLEOFEVENTS2 when establishing the technical connection to the production control system .
When an error occurs or the system crashes, the event and its data is temporarily saved.
In the case of an error, the event is temporarily saved with errors in the event queue of the workflow (transaction SWEQADM, tab page
Linkages
with
errors
).
If the system crashes and the event queue is switched off, the event is temporarily saved in the RFC monitor (transaction SM58).
If the system crashes and the event queue is switched on, the event is temporarily saved in the event queue of the workflow (transaction SWEQADM, tab page
Linkages
with
errors
).
Once you have eliminated the cause of the error, you can deliver the event again (see below). The system then only repeats the actions that were canceled . Actions that were carried out successfully are not repeated.
Caution
If you do not use the data security concept, the system repeats all actions when you deliver the event again, including those that were carried out successfully. Actions that cannot be carried out twice for business reasons may then cause data inconsistencies. Such an action could be a production backflush that does not use order numbers, that is, a backflush that just refers to the material.
From a technical point of view, each event receives an external name that the system saves together with the action that was triggered by the event, after the action has been carried out. This way the system can log exactly which actions have been carried out and prevent that an action is carried out for a second time or that two instances of the Action Handler process the same event simultaneously.
Note
Make sure that old entries in the /SAPAPO/AHT_EVAC table, that is, the table in which the actions are logged, are deleted regularly. If the amount of data in these tables is too large, system performance may be impaired. Use transaction SE11 (pushbutton
Technical Settings
) to check for which amount of data records the table has been optimized.
The data security concept does not work with optional action points that can be executed retroactively . The reason for this is:
If an action point is reported retroactively and the action for this action point is carried out, the action must have been triggered by an event that belongs to a later action point. The name of this event is already being used for this later action point. It cannot be valid for the action point that has been reported retroactively as well, as event names can only be used once.
This problem does not occur with optional action points that cannot be carried out retroactively . They are simply skipped.
Proceed as follows to deliver an event again:
If an error has occurred:
Proceed as described in Errors and Error Handling .
If the system crashes and the event queue is not switched on:
Choose (transaction SM58).Select a line in the RFC monitor, and choose in the menu.This delivers the event again.
If the system crashes and the event queue is switched on:
Choose (transaction SWEQADM).The event is displayed.The system delivers the event again automatically providing that the following prerequisites are fulfilled:
You have set the
Enable
event
queue
indicator in the
Event
Type
Linkages
view (transaction SWETYPV).
You have set the indicator
Switch
on
event
queue
on the
Activation
tab page in the event queue administration (transaction SWEQADM).
On the
Background
job tab page of the event queue administration (transaction SWEQADM), you have set that the system reads the event queue automatically as a background job.