Sep 25, 2013

Tool to check status (active/inactive) of process chain objects


Scenario:

It happens sometimes that process chains stop their activity caused by inactive objects. Their are tools that check all objects of a system but this can lead to confusion since not all objects are part of certain process chains.

The idea behind this tool is to check only the objects of one certain process / meta chain and inform the user about their activity status.

Let's say that we check the status of DTPs only. Since they are affected by ICs, DSOs, Transformations, etc. they should give us a good overview of the process chain. We will use the following BW tables:

  • Resources: 
    • RSBKDTP - BW: Data Transfer Process Header Data

FieldDescription
dtpData Transfer Process ID
objversObject version
tgtName of the Data Target for a Data Transfer Process
srcName of Source Object of a Data Transfer Process
tstpnmLast changed by
timestmpUTC Time Stamp in Short Form (YYYYMMDDhhmmss)

    • RSBKDTPSTAT - Status Information on Data Transfer Process 
FieldDescription
dtpData Transfer Process ID
objstatObject Status

    • RSPCCHAIN - Process chain 
FieldDescription
chain_idProcess Chain
objversObject version
typeProcess type
varianteProcess variante (name)

 Programm flow:
    1. Tracking down inaktive DTPs in the system environment into a table #1
    2. Identifying all DTPs that belong to a certain Chain / Meta Chain table #2
    3. Removing all DTPs from table #1 that are not part of table #2
    4. Out put of the consolidated table #1
 Solution / Coding:

*&---------------------------------------------------------------------*
*& Report  Z_PROCESS_CHAIN_CHECKER
  
REPORT  Z_PROCESS_CHAIN_CHECKER LINE-SIZE 150 NO STANDARD PAGE HEADING.


*----------------------------------------------------------------------
* Declaration area
*----------------------------------------------------------------------


TYPE-POOLS: rssm.


TYPES:      " Structures
            BEGIN OF ls_dtp,
              dtp      like rsbkdtp-dtp,
              tgt      LIKE rsbkdtp-tgt,
              src      LIKE rsbkdtp-src,
              tstpnm   LIKE rsbkdtp-tstpnm,
              timestmp LIKE rsbkdtp-timestmp,
              aedat    LIKE sy-datum,
              aezeit   LIKE sy-uzeit,
            END OF ls_dtp,


            BEGIN OF ls_pchain,
              pc_id               TYPE RSPC_CHAIN,
              pc_typ              TYPE RSPC_TYPE,
              pc_variante         TYPE RSPC_VARIANT,
            END OF ls_pchain.


DATA:       " local variables
            lv_index              TYPE i,
             lv_error(1)           TYPE c,
            lv_timestamp_txt(15)  TYPE n,
            lv_pos                TYPE i,
            lv_maxpos             TYPE i,
            lv_input              TYPE c LENGTH 60,
            lv_mail_title         TYPE string,
            lv_text               TYPE c LENGTH 120,

            " local tables
            lt_dtp       TYPE TABLE OF ls_dtp,
            lt_pchain    TYPE TABLE OF ls_pchain,
            lt_hpc_chain TYPE TABLE OF ls_pchain,

            " workareas
            wa_dtp       LIKE LINE OF lt_dtp,
            wa_pchain    LIKE LINE OF lt_pchain.


************************** ********************************************


PARAMETERS:  p_pc LIKE (lv_input) OBLIGATORY.


START-OF-SELECTION.


******************** track down intactive DTPs ***********************************
* Step 1

SELECT r~dtp tgt src tstpnm timestmp
  FROM rsbkdtp AS r
  INNER JOIN rsbkdtpstat AS l
  ON r~dtp = l~dtp
  INTO CORRESPONDING FIELDS OF TABLE lt_dtp
  WHERE objvers = 'A' AND
        l~objstat = 'INA'.


* splitting field timestmp
    IF sy-subrc = 0.
      LOOP AT lt_dtp INTO wa_dtp.
        lv_index = sy-tabix.
        IF NOT wa_dtp-timestmp IS INITIAL.
          lv_timestamp_txt = wa_dtp-timestmp.
          wa_dtp-aedat   = lv_timestamp_txt+1(8).
          wa_dtp-aezeit  = lv_timestamp_txt+9(6).
         MODIFY lt_dtp FROM wa_dtp INDEX lv_index.
        ENDIF.
      ENDLOOP.
    ENDIF.


********************** Indentify objects of a certain chain *****************************
* Step 2

SELECT chain_id type variante
  FROM rspcchain
  INTO TABLE lt_pchain
  WHERE chain_id = p_pc AND objvers = 'A'.


LOOP AT lt_pchain INTO wa_pchain.
  IF wa_pchain-pc_typ = 'CHAIN'.


    SELECT chain_id type variante
      FROM rspcchain
      APPENDING TABLE lt_pchain
      WHERE chain_id = wa_pchain-pc_variante
        AND objvers = 'A'
        AND type = 'DTP_LOAD'.


  ENDIF.
ENDLOOP.


DELETE lt_pchain WHERE pc_typ NE 'DTP_LOAD'.




*********************************************************** ***********
* Step 3


LOOP AT lt_dtp INTO wa_dtp.
     lv_index = sy-tabix.
     READ TABLE lt_pchain
        WITH KEY pc_variante = wa_dtp-dtp
        TRANSPORTING NO FIELDS.
          IF sy-subrc <> 0.
            DELETE lt_dtp INDEX lv_index.
          ELSE.
            "Do nothing
          ENDIF.
      ENDLOOP.




*********************** Table header **************************************


  NEW-PAGE.


  lv_maxpos = 150.


  NEW-LINE. ULINE AT 1(lv_maxpos).


  DATA: lv_outputtext TYPE string.

  CONCATENATE '| Inactive objects in process chain: ' p_pc
    INTO lv_outputtext.

  WRITE: / lv_outputtext, AT 150 '|'.

  NEW-LINE. ULINE AT 1(lv_maxpos).

  WRITE: / '| Object | Technical ID                  | Target                      | Source                        |                 -- last change --           |',
         / '| status |                               |                             |                               | User         | Date          | Time         |'.


  NEW-LINE. ULINE AT 1(lv_maxpos).


******************* Table ***********************************************


  IF lt_dtp IS NOT INITIAL.


    LOOP AT lt_dtp INTO wa_dtp.

      ADD 1 TO lv_index.

      NEW-LINE.

      lv_pos = 1.

      WRITE AT lv_pos sy-vline.
        ADD 2 TO lv_pos.
      WRITE AT lv_pos icon_red_light AS ICON.
        ADD 7 TO lv_pos.
          WRITE AT lv_pos sy-vline.
            ADD 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-dtp.
        ADD 30 to lv_pos.
          WRITE AT lv_pos sy-vline.
            ADD 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-tgt.
        ADD 28 TO lv_pos.
          WRITE AT lv_pos sy-vline.
            ADD 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-src.
        ADD 30 TO lv_pos.
          WRITE AT lv_pos sy-vline.
            ADD 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-tstpnm.
        ADD 13 TO lv_pos.
          WRITE AT lv_pos sy-vline.
            AD D 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-aedat.
        ADD 14 TO lv_pos.
          WRITE AT lv_pos sy-vline.
            ADD 2 TO lv_pos.
      WRITE AT lv_pos wa_dtp-aezeit.
         ADD 13 TO lv_pos.
          WRITE AT lv_pos sy-vline.
    ENDLOOP.


  ELSE.

      write: / "the process chain is okay".

  ENDIF.


  NEW-LINE. ULINE AT 1(lv_maxpos).



  • Result:

Input mask
input.png

Output table
output.jpg

Sep 18, 2013

BW - Process Chain Analysis

At one of my clients, we're in the process of "redesigning" their BW environment. Basically we're doing a technical (only) (re)validation of the current system, meaning we just check whether data flows can be improved purely technically (migrate old flows to 7.x, improve coding in start, end and/or expert routines, rearrange characteristics in dimensions, ...).

In addition, we're creating new process chains and slowly replace the "old" ones (on a functional domain basis) with new ones in the productive "meta" chain.

In order to make sure we're doing things right, we need to check (from time to time) whether our efforts have the required impact. One of the things to check is to see whether the loads are performing the same (or, ideally, better). Hence, we should check the (meta) process chain.

Via ST13 I took the data for our "meta" chain (one chain that contains ALL daily loads) for the p ast 2,5 months.

PC - input.JPG

To have a "better" (read: nicer & cleaner) view, I decided to process this data with Lumira (actually Predictive Analysis since you can't have both on the same pc and I have Predictive Analysis installed on my laptop - but, the visualization part is exactly the same).

PC - flow.JPG
Here I filtered out the "failed" loads (the ones in red) as they create too much distortion on the view and also I filtered on the pas t 1.5 months (instead of the entire data set which contains 2.5 months of data).

What do we see immediately? The past weeks our daily load time has increased with approx. 10000 seconds (almost 3 hours). Obviously that is NOT the goal of our project. We see that this has been occurring since September 7th (last Saturday). We did transport some changes on Friday (a bit against the rules, but our exception was approved) impacting one flow (concerning PP data).

I already identified where the "error" is located at, namely: one InfoPackage is extremely bigger than the others (in the past this had been split up into smaller InfoPackages, however they did it directly in the productive environment, so those changes were never made in our development environment).

This is just a very "practical" way of using Lumira (or Predictive Analysis) to help identifying (possible) issues in your BW loads.