Skip to Content
avatar image
Former Member

LO COCKPIT---DATASOURCE ENHANCEMENT PROCESS

Hi gurus,

i have a situation like we have a billing datasource which is already in production for a couple of days feeding two ODS.

But the requirement now is that i have to add a field from communication structure in LBWE.

i am planing to do these activities in this sequence please someone kindly voche my sequence.

1. change the extract structure by maintaning and also generate the datasource in the dev system.attach to a transport request

2. in DEv BW replicate it and add the infoobject to the infosource and also add to the concerned ODS. and attach to the request.

3. transport to the QAS of R/3 and BW.

4. In producton R/3 --->

Run the V3 job control so that all the entries in the Extraction queue are moved to RSA7 and from BW production run the infopackage twice so as to empty the RSA7.

and also inactivate the update of the datasource.

5. import the R/3 Quality request into Production R/3 and generate the datasource and activate the update.

6. In BW Production side replicate the datasource and import the BW QAS request of ODS and INfosource with transfer rules.

7. And we can start our loading as usual without initializing

please kindly correct me if i am wrong.

thanks and regards

neelu

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    May 16, 2006 at 06:03 AM

    Hi Neel

    First of all , I think you have to add the field from available structures (MC* in LBWE when you execute maintain extract structure). Then in that case you don't need changes in USER EXIT coding on R/3 side .

    My comments on your setps

    1. change the extract structure by maintaning and also generate the datasource in the dev system.attach to a transport request ->> Fine . Make sure that you capture all necessary objects in this R/3 side transport.

    2. in DEv BW replicate it and add the infoobject to the infosource and also add to the concerned ODS. and attach to the request.->> Fine.

    3. transport to the QAS of R/3 and BW - R/3 first and then BW ->> fine .

    4. In producton R/3 --->

    Run the V3 job control so that all the entries in the Extraction queue are moved to RSA7 and from BW production run the infopackage twice so as to empty the RSA7.and also inactivate the update of the datasource.

    ->> In order to make RSA7 no of LUWs to zero , first you need to STOP the v3 collector job and also lock out the users for billing related transactions .

    5. import the R/3 Quality request into Production R/3 and generate the datasource and activate the update.

    ->> don't activate the update now . Check the extract structure with the extractor checker program , it should be Green (OK)

    6. In BW Production side replicate the datasource and import the BW QAS request of ODS and INfosource with transfer rules ->> fine .

    7. And we can start our loading as usual without initializing

    ->> Run delta Info package (should be green with 0 records )and then activate the v3 update on r/3 side.

    It seems you don't have a requirement to populate the history data for this new field .

    So you are going in correct direction.

    Regards

    Pradip

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 16, 2006 at 04:23 AM

    Here's the link to Roberto's blog on this topic:

    /people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it

    cheers,

    Vishvesh

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi Vishvesh

      Thanks for the blog to be frank i only could do Lo cockpit after Robertos weblogs only...

      i just want someone to vouch my sequence of activities

      thanks and regards

      neelu

  • avatar image
    Former Member
    May 16, 2006 at 06:21 AM

    Hello Neel,

    You seem to follow correct steps, but there are many issues which you need to take care or else you may end up losing the existing inits or the deltas etc. Please refer to the following section from Roberto's weblog:

    =============

    Enhance it, but mind the queue !

    If you change an extract structure in the Logistic Cockpit through transaction LBWE (or one of the LIS communication structures which are the basis for the extract structure or, in individual cases, also an application table - e.g. MSEG, it’s happened to me ! - by importing a transport request or a support package or by carrying out an upgrade, you have to operate with a lot of cautiousness.

    Many problems in this area result from the fact that, although everything is well organized in the development system, the transport that takes place in the production system is not controlled.

    In fact, a not responsible and diligent behaviour (when your datasource had already been activated for update, even if for a very short period) can lead to various errors: delta requests terminate, the update from the extraction queue does not finish or V3 update is no longer processed, the initialization on data that was generated before the change no longer works, the protocol terminates...in short, a real tragedy !

    Without venturing on a too technical ground, this situation can be briefly described in this way: when you change a structure, the data which is stored in the old form can no longer be interpreted correctly by the new version of the same extract structure.

    For the same reason, you can no longer use the statistical data already contained in setup tables and you have to delete it via transaction LBWG.

    Therefore, you should carry out the following steps before you change the extract structure (also for an R/3 release upgrade or plug-in/support package import):

    close your system and make sure that no updates are performed (both by users or batch/background process);

    start the update collective run directly from LC (that concerns either the V3 update or the Delta Queued update);

    At this moment, with "delta direct" method, the delta queue (RSA7) must be empty, with "delta queued" method, the extraction queue (LBWQ) and delta queue (RSA7) must be empty, with "unserialized V3 update", the extraction queue (SM13) and the delta queue (RSA7) must be empty.

    load all data of the respective datasources into your BW System.

    To completely empty the delta queue, request a delta twice, one after the other: in this way the second upload will transfer 0 data records, but only with the second upload is the data of the delta queue that is available as a delta repeat deleted.

    Anyway, with plug-in PI 2000.2 (or PI-A 2000.2) specific checks were implemented in LBWE so that structures are changed only if (in this order) there are no entries in setup tables of the affected application, there are no entries in the V3 update and in the queue for the affected application.

    Now, that all data containers of the relevant data flow are empty, you can make (import) the change.

    IMPORTANT: the fields that are available by default in LBWE are automatically filled during the extraction and are delta relevant(see later in this weblog for more details about ‘delta relevant’ changes).

    ================================

    you can also follow other approach WHERE YOU NEED NOT ENHANCE THE EXISTING EXTRACT STRUCTURE to accomodate the new fiels and rather create a generic datasource to populate the additional fields.

    Please refer to a very good discussion/post yesterday:

    How to populate historical data into a newly added field in an infoprovider

    Hope it helps..

    thanks,

    Add comment
    10|10000 characters needed characters exceeded