Global Declaration not cleared in BW Transformation at every instance

[UmaArjunan]

In SAP BW Transformation , there are two global declaration part in it. whats the initialization value of this variable or the life time of the variables declared in global declaration during every instance of the data loading.

In the sample code given below, for every cube load , time is read from the the table tvarv and stored in global variable , this value is updated in the object routine in the cube final target fields. it is running for every 2 hours

The issue here is , in the one of the 2 hrly load, previous load time is updated in the current time, for example 10th hr load completed , then 12 th hour load started , in the cube 12thhour load, it is storing the 10th hour time in the columns by right it has to store 12hr load. this is happening on a random basis, say for example 10 days the all 12 loads time are updated properly. in 11th or 12 th load this type of issue is happening again

Question is : g_time global variable is not cleared explicity in the routines. Will the global variable not initialised or gets cleared automatically during every data load frequency at 2 hours. Unable to track this as it is running in the background in process chain . Please advise . ( To avoid select querying mulitple times , if g_time is inital is declared ).

In BW data load transformation, declared a global variable in the first section of class definition lcl_transform

CLASS lcl_transform DEFINITION.
*$*$ begin of global - insert your declaration only below this line *-*
    ... "insert your code here
    DATA : g_time TYPE  /BI0/OTCTTIMSTMP.-->>is this cleared during every instance of data load ?
    *$*$ end of global - insert your declaration only before this line *-*
ENDCLASS. "routine DEFINITION

*$*$ begin of 2nd part global - insert your code only below this line *
... "insert your code here
*$*$ end of 2nd part global - insert your code only before this line *

CLASS lcl_transform IMPLEMENTATION.
METHOD start_routine.
data : l_cube  TYPE rvari_vnam.
l_cube ='CUBE_01'.
 IF g_time IS INITIAL.
 SELECT SINGLE low FROM tvarv INTO lv_low
 WHERE name = l_cube. "(lv_low time is updated at beginnig of process chain for every data load")
   IF sy-subrc EQ 0.
      g_time = lv_low.
   ELSE.
      g_time = sy-datum && sy-uzeit.
   ENDIF.
 ENDIF.
ENDMETHOD. "start_routine
ENDCLASS. "routine IMPLEMENTATION

In the characteristic Routine this is updated:
 result =  g_time.

[UmaArjunan · Accepted solution]

Thanks for the reply Matthew !!

If that is the case, this issue is still happening in production even on 26th sep 2020,

I would like to add some additional information , there are around 20 process chains for 15 different cubes and 5 different dso , all are having the similar logic in the start routine ( variable names are also similar ) to read and update the time stamp in the object routine . All these process chains are scheduled to start and run within 2 hours duration ( 12 to 2 hours ), next set of load from 2 to 4 hours , and load frequency is every 2 hours . Each process chain will run upto 12 times a day. I noticed that when ever there is a single data package, this issue is likely happening. In development , simulating this issue is not possible ,as this is occurring only in production. Unable to figure it out as this is happening on a random basis and random timings. Any other checking will help to solve ?

changing to update timestamp for every data packet in start routine removed , if g_time is inital . will this help ?

SELECT SINGLE lowF ROM tvarv INTO lv_low
 WHERE name= l_cube." 
(lv_low time is updated at beginnig of process chain for every data load  uusing a simple separate update program, thats being read in start routine")
IFsy-subrc EQ0.
      g_time = lv_low.
ELSE.
      g_time =sy-datum &&sy-uzeit.
ENDIF.

[matt · Accepted solution]

If you add an answer instead of a comment, I don't get notified. I only happened to see your question in the queue again. I wouldn't have known you'd responded. As it says just below:

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.

I've responded to your question as a comment on my answer. Please respond there if you still can't resolve the issue. As a comment.

[matt]

Every time you run a DTP, the variables are initialised. They absolutely cannot and do not hold values from previous DTP runs. Within the run, the DTP may divide the processing into a number of each parallel streams. Within each stream, data is processed in packages.

For each stream, globally defined variables are entirely discrete. There is no communication whatsoever between streams. As each package within a stream runs though, the global variables retain their values. So if, in your global declaration you have:

DATA my_data_handler TYPE REF TO zcl_my_data_handler.

and in the routine itself you have

IF my_data_handler IS NOT BOUND.
  my_data_handler = new #( ).<br>ENDIF.

the instantiation of my_data_handler will only happen at the start of each parallel stream. It will not happened for every package.

You seem to indicate you've got something that looks like global variables retaining their values between separate DTP runs. I can tell you 100% definitely this does not and cannot happen.

[matt]

Right. The issue isn't global variable. What you're actually doing is persisting your timestamp in TVARV (You should properly use TVARVC - that's client dependent - but unless you've more than one productive client using the same TVARV variable it shouldn't be an issue).

Clearly then, your TVARV variable isn't being updated properly is the problem. You need to look there.

If you can't figure it out, then please post the simple separate update program.

[UmaArjunan]

Hi Matthew,

Please find the simple Update program below :

PARAMETERS : p_inf TYPE rvari_vnam DEFAULT 'XXX_CUBE01'. " DSO or CUBE technical name 
DATA : lv_low TYPE tvarv_val,
       lv_msg TYPE string.

SELECT SINGLE low  FROM tvarv INTO lv_low 
WHERE name = p_inf.

* Update new timestamp for every new run of process chain
  lv_low = space.
  lv_low = sy-datum && sy-uzeit.

TRY.
    UPDATE tvarv SET low = lv_low
    WHERE name = p_inf.
**
    IF sy-subrc EQ 0.
     COMMIT WORK AND WAIT .
      IF sy-subrc EQ 0.
        lv_msg = 'Database updated'.
        MESSAGE lv_msg  TYPE 'S'.
      ELSE.
        lv_msg = 'Database not updated'.
        MESSAGE lv_msg  TYPE 'S'.
      ENDIF.
*
      lv_msg = ` Time stamp variable updated for `  && p_inf && ' : ' && lv_low.
      MESSAGE lv_msg  TYPE 'S'.
    ELSE.
      lv_msg = ` Time stamp variable not updated for`  && p_inf && ' : ' && lv_low.
      MESSAGE lv_msg  TYPE 'S'.
    ENDIF.
*
  CATCH cx_sy_dynamic_osql_error.
    MESSAGE `Error` TYPE 'I' RAISING p_inf.
    WRITE : /  `Error !` , p_inf.
ENDTRY.

[matt]

Where does this run?

A couple of suggestions:

• Try using BYPASSING BUFFER in your select in the start routine.
• Query table RSBKREQUEST to find out when the DTP last ran.

[UmaArjunan]

this "update timestamp" program runs in the first step of every process chain , and then info pack run and then dtp ( place where this updated time is read and updated in the cube / dos load timestamp column) .

I will try the above options and update you. Thanks Matthew