Delta based on append structure field for datasource/customer exit

[Former Member]

Hello...

This questions is very good opportunity for those who want to show their expertise.

Here is the scenario.

We have master data source called 0ABCDFE_ATTR ( Example). This is delta.

I have added the ZFIELD to the append structure and populated with that.

Key - ZFIELD

0001- Hello

We did the full load and process the delta, everything is fine.

But cusotmer has changed the ZFIELD for old data ( this is not new record).

*Key - ZFIELD*

0001- Good bye

This changed image is not coming into BW with delta.

Fortunately this is not extracted into BW since it old record..?

Any ideas ..? how to get the latest image for ZFIELD although its old record that exists already in BW.

Thanks

SP

[Former Member · Accepted solution]

There is no way to track it with standard delta functionality. You can either do a full load daily (if the record count/time is not too much) or you can come up with an elaborate scheme of checking the delta on that field.

My guess is that you will end up doing a full load, but if you so desire, and have the skills, you can do one of the following:

1.) Create an event or trigger on the table that is updated with this field. When it is triggered, check to see if the field changed, if it did, place the record in a second "delta" table. Create a new generic datasource on this table to load into your info object in BW.

2.) When a record in your Z field's table is updated, put an X in a second Z field that will allow you to identify updated records. Create a generic datasource on this table and make the X field selectable. Always pull the X'd records and create a user exit routine to uncheck the X's after you pull the data.... a little risky, but it should work.

Like I said, a full load nightly is much easier, even if it takes a long time to load.

Brian

[Former Member · Accepted solution]

Guys,

We are already doing full load now till today. The question is for how to delta based on append field ..?

In fact that is text field that exists in TCode "SO10" there is no standard table for this.

We are using FM "READ_TEXT" to get this text field based on key in data source.

Tricky is the customers keep changing this text that we were unable to track them with delta untill some body notified it and we dont know what is changed untill its notified.

We can not do full load for all records but we can do for changed records which we are doing now. We want to automate this step which driving this.

Brian, your first even solution seems to be acceptable to me but i need to test it.

I will let you know.

Good luck.

SP

[Former Member · Accepted solution]

"there is no standard table for this" => disagree... if there's no (standard) table, then how is it stored in the database???

Anyways, there is a reason why SAP does not extract text fields into BI... maybe read some documentation on that. If you really need this field in BI and they keep changing it all the time (sounds like a pretty bad business process to me though), you may want to change the way the "text" field is entered in the source system... maybe add an append structure to the original table, that way a delta might be triggered whenever you change the field (as the change will trigger a change in the table).

[Former Member · Accepted solution]

Rafb, there are lots of non-standard tables in SAP! You have custom tables and all of those classification tables and lots more that I forgot about.

There isn't a problem with bringing over text fields either ..... I have worked with many customers that use texts fields to populate data (not texts) in those fields. Just because it's a text field doesn't necessarily mean it's bad. I have had Customer PO numbers populated in text fields of Sales Orders and it transferred easily and provided my end-users with valuable information (just to mention one such use of a text field).

Without fully understanding what he trying to do, we shouldn't be making any judgements.

Give the guy a break!

Brian

[Former Member · Accepted solution]

Brian, I specifically put (standard) in brackets... What the original poster was referring too (at least that's how I understood it), were tables that you (supposedly) cannot access directly, but through a function module... well, that function module somewhere has some kind of select statement.

Also, she/he was referring to free texts... and yes, you can load them and you can even get passed the 60 characters limit if you want to... but SAP does not like that (and it actually makes sense - wy would anyone report on free text?). That's all I was trying to point out.

You don't always have to "solve" things in BI... a lot of times the original process is just not optimal (or even plain wrong) and thus it needs adaptation in the source system itself, rather than trying to complicate things in BI.

[Former Member · Accepted solution]

Hello Brian,RafB,

I went to thru many options to figure out the solution. Its business critical req as of now.

As i decribed earlier its field in append structure that populate thru function module "READ_TEXT".

There is no way you can get delta for this field unless you add this field message type. But R3 folks never going to approve since this is not a attribute and stored in text table not in master tables. i cont even add this to text table since its not a text. Its decription for any object in SAP that stores in SXTH tables thru Tcode SO10. You can have decription for sales order 10000 also its not a text, its detail decription like big letter. I say today "good morning" i will say tomorrow "Happy morning.. did you watched Olympics last night, how is your kids doing, i had flat tire while coming to office", its confidential decription. You can find this decriptions for master/transcational objects anywhere in SAP.

So we ruled out change pointers.

RafB, yes there are many tables in SAP but all tables are not traceble although data store in form of tables. Still disagree..? techincall yes but debug chain never ends, Its weaste of time it has many joins more than 20. i am not ready to spend that much time for this.

Bian, we are working on events now, its seems to be working. thanks for your advice.

Lot of custom work.

Thanks

SP

[Former Member · Accepted solution]

hmm... I see your point, STXL contains clusters...

anyways, I still think it's a bad requirement, but that doesn't really help you

here's an idea (just thinking out loud)... you could load those texts on a daily basis into a separate DSO object (full loads) and then "mix" them with your master data in an InfoSet... is that an option?

[Former Member · Accepted solution]

Hi RafB,

Yes. When customer change the text its generate event, then we trigger PC in BW for this custom data source on STX* tables and get the data loaded to master objects. We ruled out change ponters/any other R3 related work.

I still feel its good design, its new requirement came in. Whats point of keep saying its bad design when customers wants this change updated.

When customer look at the master data , they just look at this decriptions whats going on to knw its okey or ill.

Thanks

SP

[Former Member]

check SAP-Note 141436:

....

Under which preconditions a self-defined InfoObject or DataSource can be changed into a delta capable InfoObject is described below.

The master data extraction in the delta mode is possible for a large number of R/3 tables and views. To do this, the transaction for which data is to be created and changed must be linked to the change document update. This service has been implemented for most of the master data in the R/3 System.

The update occurs in most cases for the transparent tables in which R/3 master data is stored (for example, for MARA or KNA1). If a field changes in a data record of the table the key to this record is recorded in a delta table. When reading the table in a BW, this key is used to fill the extract structure. Thus, you can extract master data delta in several ways:

The extract structure equals the transparent table in the database, whose maintenance is added to the change documents.

The extract structure is a view over one or more transparent tables whose maintenance is added to the change documents, for example, a view via KNA1 (customer) and KNB1 (customer and company code).

A basic requirement for the usability of a table for an InfoObject is that the key for this table explicitly specifies a record of the extract structure (key word compounding). Besides, you should make sure that the data elements of all the extract structure fields are relevant to the change document in the respective table. In other words: as soon as a field changes a record which is part of the extract structure, it must be updated in the delta pot.

According to the assignment InfoObject/table, the following steps must be executed:

1. Check, whether the ALE changepointer are active in your source system (Transaction BD61) and whether the number range is maintained (Transaction BDCP).

2. In addition, check in the ALE Customizing, whether all message types you need are active (Transaction SALE -> Model and implement business processes -> Configure the distribution of master data -> Set the replication of changed data -> Activate the change pointer for each message type ).

CAUTION !! For PI 2000 it is sufficient to check this item !!

3. Check, whether the number range for the message type BI_MSTYPE is maintained (Transaction SNUM -> Entry 'BI_MSTYPE' -> Number range -> Intervals). The entry for 'No.' must be exactly '01'. In addition, the interval must start with 0000000001, and the upper limit must be set to 0000009999.

4. Go to your BW system and restart the Admin. workbench.

All of the following activities occur in the InfoSource tree of the Admin. Workbench.

5. Carry out the function "Replicate DataSource" (1.2 local meta data upload) on the affected attached source system for the InfoObject carrying the master data and texts.

6. Activate the delta update

a) for master data (as of BW 1.2) and texts (as of BW 2.0): by activating the transfer rules.

b) for texts (1.2): the entry is in the menu of the right mouse button via the source system: Activate the text delta transmission.

All changes, all initial data creations and deletions of records from now on are recorded in the source system.

7. Create an InfoPackage for the source system. In the tabstrip 'update parameter', there are three alternative extraction modes:

Full update

Delta update

Initialization of delta procedure

First, initialize the delta procedure and then carry out the

delta update. .....

best,

Sascha

[Former Member]

Hi Swetha,

Here u have mentioned that your data source has the delta capability. When u say delta it will bring all the new and changed records into BW. To get the changes into bw u have to run the full load again in this case.

Khaja

[Former Member]

all you need to do is to make sure that a change in this field "triggers" a change in your "original" object which is linked to InfoObject 0ABCDFE...