How Extractor Work:

Form my learning of past few weeks; I want to share my experience and knowledge with all of you.

Actually we can use R/3 or CRM to display and present the data; even we can create the report in source system to get the data but due to huge data volume it is not very desirable option, that is why data is extracted by a desirable destination system mostly BI, which is ideal for handling huge volume of data, and also using BI we can have historical data accumulated over a period of time which might be useful for forecasting, long term planning etc.

BI or destination system extract data from Data Source, we define data in source system ( For example we were trying to solve the issue of data source 0CRM_SRV_PROCESS_H which is defined in CRM system)

We can go to transaction RSA2 to see how the data source is defined.

See the print screen below

Now click on display

There is 3 tab:General

This gives us the name of data source its type, application component, and many more information, though I can go much details about these fields but it is not desired as part of this document.

Extraction:

This is most important time tab, this tell us who is going to extract the data may be a function module, a class, abap query, there are so many u will get that from the list. In our case it is a function module type F1:

'F1': The data is extracted using a function module, which distributes the data in packages automatically. This is useful for large quantities of data.

2nd field of this tab is extractor: SMOX3_GET_DATA this is the function module which will be called to fetch data.

Then there is extract structure which will give you the structure of data extracted. in our case it is CRMT_BW_SERVICEPROCESS_H,

Direct access: If the data supports the direct access, then the data can be retrieved from that source without actually loading into BW

Other info which we get from this tab which is very important is how delta is handled by the extractor.

DELTA PROCESS: this makes sure that the data is interpreted correctly in BW, in the same sense that it is uploaded to correct data target.

You can correct interpretation of delta process from table RODELTAM

So in our case delta process is AIDM it means , delta with new image, delta with after Image, delta with non additive delta records, serialization of delta record is required, type of delta process is D i.e. generic delta for Service API.

Similarly you can get the information about other delta process.

Before moving forward I just want to put one line about Delta. Actually delta is accumulated in delta queue on source system in the form of packet.

Record Mode field: his is part of extract structure. This shows how a record is updated in

delta process.

Archive Link: It shows whether data is needed to be fetched from Archive or not.

Last Tab is field: It just shows the fields which are needed to be extracted are.

Now I want to talk property of field of data extract:

It depends on 4 properties:

Selection: it is part of selection criteria

Hide Field: This filed will be hidden not in display

Inversion: this field is inverted in case of reverse posting

Field only: This is not part of standard extraction but fetched using an user exit.

For example in our example CASE ID is field only and it is fetched using user exit ZXRSAU01.

I hope this information is enough to solve the issue if it happens with extractor. Now I want to discuss regarding our defect 7601.

Issue: After a rigorous analysis it was found that data from CRM is going to BI but somehow case id is missing, and case id being important field this become a very big problem.

Case id being filed only and hence fetched in user exit ZXRSAU01 we can say that there is problem with this user exit. But what is the problem? This was question in front of me, and initially as I have never worked on CRM or BW / BI issue before I was unaware that data does not move from CRM to BW in one single packet but it goes in packet. Later during my analysis I established the problem in user exit.

Actually we were getting data from srmprotocol and scmg_t_case and scmg_t_case_attr for getting the case id. For the first data packet data selection were available for all the three tables but code has a bug due to which data from srmprotocol were unavailable in subsequent data packets.

Corrected the code and resolved the issue.

Issues faced while resolving the issues.

1. No help from process team, they do not know how this extractor works.2. Lot of authorization related dependencies.3. My unawareness about CRM process, I asked how I will relate case id with

sales org and I did not got any proper answer (Answer was debug the code and find it out.)

4. User exit is written in a very bad manner due to which the processing is very slow and take hours to execute the whole process which makes the debugging very difficult.

How to solve the issue in case some problem happens in future?

Eg: If user complains case id 159732 is not flowing to BI and it should go there for the posting period march 2009

Step to do: Go to transaction SCASE

Got to case->case search.

Click on search button:

You will get the selected entry against case id if it is available

Click over it

You will get record entry

Go to reasons

You will get two entry under it both are last processed in the month of APRIL so if you run it for the month of April you will get two entry with case id 159732, but you will not get any in month of march

And just to add answer of my question above how case id is linked to sales org, click on of the node under reasons:

Go to transaction Data-> Organization

Here you will find field sales org as SORG. 4440do F4 over it and you can find the SORG.4440 means Sales organization 5000651.

I am finishing this document at this moment, I do not what this cased id functionally signifies and I accept my functional incompetency as I am not aware of CRM process.