SAP for Utilities Discussions
Connect with fellow SAP users to share best practices, troubleshoot challenges, and collaborate on building a sustainable energy future. Join the discussion.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Mass/Parallel Archiving T-codes

Former Member

‎08-25-2014 7:29 PM

0 Kudos

Hi

SAP has provided us mass/parallel archiving t-codes like (EAPDH, EAPDL, EABBP, EABIH, EABIL). When I am trying to run one the print document line item mass activity it finishes fine; this t-code or mass activity triggers the Pre Processing job which ended ok and finishes sucessfully. Just before finishing it triggeres the Write Mass Activity and write triggers the Delete mass activity.

My issue is since I am triggering the Mass activity which just keeps the log for pre processing job (external job monitor tool) can keep track of the pre processing job only and if the write job fails there is no trigger for me to validate anything happened in the system. Can this job be scheduled 3 times? First run for Pre - Processing; Second for Write and Third for Delete. Rather than one triggers the other automatically.

Appricate a quick reply!!!

Thanks


1 REPLY 1

AmlanBanerjee
Active Contributor

‎08-26-2014 9:22 AM

0 Kudos

Hi Ankur,

The archiving transaction codes that you have mentioned triggers the following events-

(a) EAPDH- Event R490 which triggers embedded standard program REPDAR_ANALYSE_HEAD

(b) EAPDL- Event R491 which triggers embedded standard program REPDAR_ANALYSE_LINES 

(c) EABBP-Event R492 which triggers embedded standard program REAR_ANALYSE_BBP

(d) EABIH-Event R493 which triggers embedded standard program REAARCH_ANALYSE_HEAD

(e) EABIl-Event R494 which triggers embedded standard program REAARCH_ANALYSE_LINE

All these standard program run are called in the events internally before the main archiving program and are used to determine which entries in the table are able to be archived and writes them to an index table and hence are protected from any update.

The output of the index table is being feed into a standard FM ARCHIVE_ADMIN_SCHEDULE_WRI_JOB which performs the write and the deletion activity.

There are already some exception handling done against the FM in these events, like Object not found, job not created etc.

However, if you still want to have some more visibility, you can create a custom FM in these events and call the reports and the FM which in trigger will schedule a job in background so that you can monitor them.

Hope it helps..

Thanks,

Amlan