Avoid attribute change run collision


,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

How to avoid attribute change run collision

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


                         Attribute and hierarchy change run : If you change master data (navigation attributes) or hierarchies of a characteristic that is contained in aggregates, you must adjust these aggregates. This ensures that queries that access the InfoCube or assigned aggregates are consistent. Unlike in the aggregates, no data that refers to navigation attributes or 
hierarchies is stored in the InfoCube. 
                       The master data or the hierarchy tables are joined with the tables of the cube when the query is executed.Regardless of whether or not aggregates exist, the system does not automatically transfer master data record changes, rather you must activate this master data explicitly. If aggregates are involved, you must adjust them using the change run before you can 'release' the data record changes (the corresponding InfoObjects or hierarchies are registered for the next change run:
                      Transaction RSA1 ->
                                                  Tools -> 
                                                        Apply Hierarchy/Attribute Change ->
                                                                                       InfoObject List or Hierarchy List).
Problem
                                 In any SAP System only One attribute change run can run at one point of time. i. e If one attribute change run is running in system from any process chain or for any project and 2nd one fails, if start at same time due to locking problem. Due to this entire data load fails.
Solutions
1. Shift Change runs from info package level to global level and/or process chain level in order of priority. Means instead of keeping ACR after each infopackage update we can accumulate all in one ACR at end of Process Chain or in a separate chain, if this data is not dependent for next loads(means no look ups).

2. Increase CR_MAXWAIT time. CR_MAXWAIT is to create a delay for second attribute change run while the first attribute change run is running in the system.
At any single point in time, there can only be one CR in the startphase. Every other CR will immediately fail when unsuccessfullytrying to acquires the startlock. No wait is done here.
Above option is helpfull When the running CR is in the workphase, only then will a second CR enter the start phase and wait as long as specified in CR_MAXWAIT.And when the second CR is in the startphase, all other CRs trying to start will again immediately fail.

3. Created an ABAP Program and included before each Attribute Change Run in Process Chains. This Program checks if any ACR running in the system or not. If any ACR is running it delays 10 Secs. Recursively it checks and delays 10 secs every time. Program execution finishes only when there is not ACR running in the system and allows next process(Attribute Change Run) to trigger in Process Chain. After implementation of this program no ACR failures in our system. Check the coding at end of this blog in appendix.
How to implement
Step1
Create an ABAP program(eg: ZRSDDS_CHANGERUN_MONITOR), coding available at Appendix. create a variant aswell for no of sces neets to wait at max.
Step2
Include this ABAP program in Process Chains between infopackage and Attribute Change runs as shown in the screenshot.
Step3
Goto Process Chain(TCode: RSPC) and choose perticular process chain, then goto processes and choose ABAP program provide technical name and description. Provide created ABAP program and Variant save and activate Process Chain.
Code

*REPORT ZRSDDS_CHANGERUN_MONITOR.
TYPE-POOLS: rsdds, rrhi, rsd.
SELECTION-SCREEN BEGIN OF BLOCK NO_TIMES WITH FRAME.
PARAMETERS : L_TIMES TYPE I. --> Create a variant provide value(ex: 100, then it will wait at max 100*10 secs).
SELECTION-SCREEN END OF BLOCK NO_TIMES.
DATA: l_cr_state TYPE rsdds_cr_state,
l_t_chanm TYPE rsd_t_iobjnm,
l_s_chanm TYPE rsd_s_iobjnm,
l_t_hieid TYPE rshi_t_hieid,
l_hieid TYPE rshi_hieid,
l_t_aggrstate TYPE rsdds_t_aggrstate,
l_s_aggrstate TYPE rsdds_s_aggrstate,
l_t_msg TYPE rs_t_msg,
l_s_msg TYPE rs_s_msg.
write: /1 'Date' color 7, 12 'Time' color 7,
22 'Attribute change run Status'
color 7 .
Write AT /1(52) SY-ULINE.
DO L_TIMES TIMES.
CALL FUNCTION 'RSDDS_CHANGERUN_MONITOR'
IMPORTING
e_cr_state = l_cr_state
e_t_chanm = l_t_chanm
e_t_hieid = l_t_hieid
e_t_aggrstate = l_t_aggrstate
e_t_msg = l_t_msg.
case l_cr_state.
when rsdds_c_cr_state-finished.
write: /1 sy-datum, 12 sy-timlo,
22 'No Attribute change run Running'
color col_positive . --> We can check this program is usefull or not... how many times it saved dataload failues due to ACR Collision (SPOOl we can check at TCODE: SP01)
EXIT.
when rsdds_c_cr_state-start.
write: /1 sy-datum, 12 sy-timlo,
22 'Attribute change run Started'
color 3.
wait up to 10 SECONDS.
when rsdds_c_cr_state-running.
write: /1 sy-datum, 12 sy-timlo,
22 'Attribute change run Running'
color col_negative.
wait up to 10 SECONDS.
when rsdds_c_cr_state-canceld.
write: /1 sy-datum, 12 sy-timlo,
22 'Attribute change run Cancelled'
color 4.
EXIT.
endcase.
ENDDO.
,,