7 Replies Latest reply: May 13, 2012 7:39 PM by Ernesto Plaza RSS

Problem in functional extension of standard datasource 0CO_OM_CCA_9

Virginio D'Amico
Currently Being Moderated

Hello SAP BI Gurus,

 

I would like to submit a question here regarding an annoying problem I'm facing with the functional extension of the datasource 0CO_OM_CCA_9 on our SAP/R3 system.

The extension was required to fill the Vendor column (LIFNR) in some cases where the standard extractor was leaving the field empty.

To fulfil such a requirement I put some custom code in the customer exit modules relating to the transactional datasources (function module EXIT_SAPLRSAP_001, include module ZXRSAU01), as shown below:

 

In include module ZXRSAU01:

CASE i_datasource.

 

when ...

 

....

 

  when '0CO_OM_CCA_9'.

    CALL FUNCTION 'ZZ0CO_OM_CCA_9'

      TABLES

        c_t_data = c_t_data.

 

ENDCASE.

 

The function module ZZ0CO_OM_CCA_9 finally contains the actual logic that fills the LIFNR field when it is empty and the other fields in the extracted structure enable the search of LIFNR in table MSEG:

 

data: begin of mov_cdc.

        include structure ICCTRCSTA1.

data: end of mov_cdc.

 

  • If field LIFNR is empty its value is searched for in

  • table MSEG:

  loop at c_t_data into mov_cdc.

    if ( mov_cdc-lifnr is initial ).

      select single lifnr into mov_cdc-lifnr from mseg

        where MBLNR = mov_cdc-REFBN

        and MJAHR = mov_cdc-REFGJ

        and ZEILE = mov_cdc-REFBZ

        and MATNR = mov_cdc-MATNR

        and WERKS = mov_cdc-werks.

      if ( sy-subrc = 0 ).

          modify c_t_data from mov_cdc INDEX sy-tabix.

      endif.

    endif.

  endloop.

 

ENDFUNCTION.

 

With this customer exit saved and activated, the datasource extractor works fine when launched locally on the R/3 system with the execution test utility for datasources (transaction RSA6).

The weird behaviour that I really can't explain arises when the extractor is activated remotely by our BW system.

In this case, differently from the local execution case, when the custom code is executed we see that the fields REFBN, REFGJ and REFBZ of the extracted structure are always empty and therefore the query select always fails.

Of course, we have replicated the datasource in the BW system more than once to be sure to make the datasource changes visible.

Since the R/3 user launching the extractor remotely (BWREMOTE) was different from the user that launched it successfully in local tests, as a first trial we tried to assign the SAP_ALL profile to BWREMOTE, but nothing has changed.

To summarize, the datasource extractor 0CO_OM_CCA_9 seems not to be extracting the fields

REFBN,

REFGJ ,

REFBZ

when started remotely, whereas it fills those fields when it is run locally.

Could anyone please give me an explanation of that?

Thank you in advance for your support.

 

Virginio D'Amico

  • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
    Simon Turnbull
    Currently Being Moderated

    Just to make sure - you have checked the data in the PSA? and you have created a transfer rule to move thos efields into BW infobjects?

    • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
      Virginio D'Amico
      Currently Being Moderated

      Hello Simon,

       

      I could not check the data in PSA because the missing fields are not actually transferred to any infoobject because they are not needed in the target infoprovider (ODS 0CCA_O09). However, I suppose those fields are empty when uploaded from the source R/3 system. I did not define a transfer rule for these fields because I'm only interested in filling the field LIFNR in some cases where it is left empty by the standard extractor, and that field is still empty in the PSA when it should have been filled.

       

      Thank you so much for quick reply

       

      Regards,

      Virginio D'Amico

      • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
        Simon Turnbull
        Currently Being Moderated

        I think I understand

        You extended the datasource structure with an include - then you looked at the fields in the extract structure of the datasource and I guess they are set to "hidden" or "only used in the extractor"

        You then ran the extractor in RSA3 with no problems

         

        You then replicated the meta data (just in case) and reactivated the datasource and trasfer rules in BW (just in case) - then ran an infopackage and the ipakretuned no data for vendor numbers when they shoudl have been some (as poeved by the RSA3)

         

        Well first thing I would do is reset the BWREMOTE to what t should be - then unhide the fields (the look up fields REF etc.)  from the datasouce and bring them into the datasource in BW just to prove somethign is coming in for them and then run the ipak and check the PSA

        • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
          Virginio D'Amico
          Currently Being Moderated

          Dear Simon,

           

          thank you for your precious support. You are on the way to understand the problem, but there are still some details missing, certainly because of my inaccurate description.

          I have not extended the datasource because I don't need to add extra fields in the current datasource: I only had to customize the extraction process so as to make it fill an already existing field for Vendor (LIFNR) when it is left empty by the standard implementation. Therefore, no new fields set to "hidden" in the data structure.

          Then I replicated the metadata and reactivated the datasource in BW. When I run the infopackage from BW I get the LIFNR field empty as before the functional extension on the R/3 source, but if I run the extractor with RSA3 in the source system (with the same selections as in the infopackage) I see that the LIFNR field is filled correctly as expected.

          The problem I'm submitting is thus concerning this strange difference in the behaviour of the extractor depending on how it is invoked.

           

          PS: Of course, after my test on user BWREMOTE, I have reset it to the previous configuration.

          • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
            Simon Turnbull
            Currently Being Moderated

            A few more questions....

            1. Did you run RSA3 and the ipak in the same mode - ie delta?

            2. Still not quite sure what you are doing - but this is what I woudl try next

            Stick an endless loop in the cmod code - ie declare a constant - then loop around a while data field = constant

             

            Then run your ipak - go into R3 and debuf the process in SM50/SM66 and then change the constant in the abap editor to get out of the endless loop - then step throug the cmod code to find out what is going on

            • Re: Problem in functional extension of standard datasource 0CO_OM_CCA_9
              Virginio D'Amico
              Currently Being Moderated

              Hello Simon,

               

              here you are my answers:

               

              1. Yes, I've run both ipak and RSA3 in the same mode (full), with the same selection parameters.

               

              2. I find this suggestion about debugging background processes very useful. I've been wondering several times about how to debug pieces of code in similar situations but could never find a good solution: now I know how to do in these cases. Thank you!

              In this specific case, to see what was going on in the extraction process in R/3, as an alternative to debugging I have put some logging messages in the cmod code with the WRITE statement, and then inspected the spool output of the ipak execution.

              The result of this test was that the query for selecting the LIFNR value

               

              select single lifnr into mov_cdc-lifnr from mseg
                     where MBLNR = mov_cdc-REFBN
                     and MJAHR = mov_cdc-REFGJ
                     and ZEILE = mov_cdc-REFBZ
                     and MATNR = mov_cdc-MATNR
                     and WERKS = mov_cdc-werks.

               

              fails (sy-subrc = 4) because the fields REFBN, REFGJ and REFBZ are not filled (initial) in the extract structure passed to the custom function module.

              When the extraction is executed with RSA3, instead, the above mentioned fields are filled and the query works correctly.

               

              Thank you so much for your suggestions.

               

              Regards,

               

              Virginio D'Amico

Actions