0CRM_MKTATTR_ATTR delta not working

[Former Member]

Hi Experts,

I´ve been facing a problem with datasource 0CRM_MKTATTR_ATTR that is delta-enabled. It is used to extract Marketing Attributes information from Business partners from SAP CRM to SAP BW. We´re on BW 7.01 and CRM 7.3 (and BBPCRM 702 SP4).

After a sucessfull INIT execution, there no data been generated in RSA7. I´ve done an extensive search about this subject and so far, I can list the points bellow regarding the configuration needed:

1) Change pointers are activated (through transaction BD61) in SAP CRM

2)  Al RS00* Message types are flaged in transaction BD50. I´m not sure the reason all message types bellow are related to 0CRM_MKTATTR_ATTR

RS0022

RS0023

RS0027

RS0028

RS0029

RS0030

RS0031

RS0032

RS0033

RS0034

RS0035

RS0036

RS0037

RS0038

RS0039

RS0040

RS0041

RS0042

3) I´ve read that we can have better performance in a delta scenario if the configuration in BD60 is set for the same message types. In this case, we´re NOT using this configuration. We´re not sure if this configuration is also needed for this scenario.

4) Lastly, we´ve segregrated the INITIAL data load in 10 different BP ranges, because we need to upload around 900 million records to SAP CRM. So far, we´ve done 3 executions (one per day).

Therefore, does anybody could help me understand this scenario? What is missing to enable the Delta scenario in this case?

I´ll really appreciate any help given.

Thanks in advance.

Fábio

[Former Member]

We have had delta update errors out of this extractor, but not of this kind. I will track your progress. We have found it extremely difficult to get any effective help from SAP service upon CRM extraction failure, and specifically with this extractor. We find that the delta message for attributes which have been deleted do not send a delta with the deleted value, among other problems, requiring a full BW reload of this data every day..

[Former Member]

Hi Doug,

Thanks for your input. It´s really not an usual functionality.

Therefore, after a period of intense research and tests, I found out the following:

1) In order to upload 900 million records, we initially splitted the INIT executions in 10 different BP ranges. By doing this we found out that DELTA execution would work only for the first INIT. I´m not sure why. After that, we excluded all INIT pointers and executed another without any filters and without data loading as well. It worked fine after we first changed the source data and executed the DELTA infopackage.

2) The first time I thought DELTA was not working was checking RSA7 data. Differently from other datasources, the new and changed records are not displayed there for this datasource.

3) Another observation: we have around 35 marketting attributes for each BP. If you change only one, all 35 goes with the Delta execution.

That´s it.

Regards,

Fábio

[Former Member]

Interesting information Fabio, thank you. I will note that we discovered that the delta for this extractor does not update when an attribute is deleted for a Business Partner. So for example if a customer had an attribute for "buys yellow paint" set to YES, when the YES is removed (let's say it was incorrectly entered in CRM and must be deleted), BW will never update the absence of YES into the BP's attributes. This caused us many difficulties, and SAP so far, has essentially refused to fix the extractor so that BW gets an update row with he erased attribute update. They have a start routine available which has to scan the entire BW master data for each PSA row, but we consider this an unacceptable workaround due to data volume and performance. Thanks, Doug

[Former Member]

Hi Doug,

I´m now facing a Delta extraction issue related to the same datasource. I still don´t know if it´ll work or not, but it´s taking a very long time to finish.

This datasource works with a different Delta method that is related to change pointers, as we mentioned before. When we do the proper configuration in BD60 we can notice that the table BDCP2 is used to received the changed data for the delta execution (which is not shown in RSA7).

After I executed the infopackage, the job in the source system took a long time to select all data (in my case 1.4 million records) and put it into memory (as seen in SM66) - reached almost 6Gb.

Then, another step started. I noticed that the field PROCESS at BDCP2 table started to change to "X" value, meaning "processed". After almost one full day, all data from this table is now marked with this information.

The extraction is still executing but till now I haven´t identified what´s going on. I believe some data should appear at BW side soon and hopefully all these "processed" data should be removed from BDCP2 table, because is also causing a serious performance issues to other process we have.

Does anyone else have something else to add here??

I´ll keep this post updated.

Regards,

Fábio