ERDAT or AEDAT

[Former Member]

I have two fields ERDAT(created on) and AEDAT(change date for order master). My question is -

Do I need to use AEDAT or ERDAt as delta specific field?

Do i need to put ERDAT with a time stamp or calender day?

How does the time stamp differ from calender day in my context?

Does ERDAT/AEDAT necessarily have to be system date to make the time stamp work?

What would happen if the ERDAT happens to be a prior date than the current date? Would that record be dropped or would be collected for delta if its on time stamp or calender day?

And in the infopack thats uploads the char, it uses a conversion routine in ERDAT.

data: l_idx like sy-tabix,

w_date like sy-datum,

w_char(8).

read table l_t_range with key

fieldname = 'ERDAT'.

l_idx = sy-tabix.

l_t_range-sign = 'I'.

l_t_range-option = 'BT'.

w_date = sy-datum - 103.

w_char = w_date.

l_t_range-low = w_char.

w_char = sy-datum.

l_t_range-high = w_char.

modify l_t_range index l_idx.

p_subrc = 0.

With this conversion routine in place, how would this effect the usage of ERDAT as a delta specific field.

Thanks in Advance. Any help or pointer would be appreciated and fully rewarded.

Thanks,

Mav.

[Former Member · Accepted solution]

Hi Mav,

everytime that I have this issue, I do my delta on both. I create a fm using a self defined extract structure that contains a field named extraction date. This field is used for the generic delta. In my fm I do a select on the table in question as follows:

select * from <table>

where erdat in ex_dat

or aedat in ex_dat.

This will give me all records created and all records changed since the last extraction.

You need to do this, because normally the aedat is empty if the record was just created.

Hope this helps

regards

Siggi

[Former Member · Accepted solution]

Hi Siggi,

"normally the aedat is empty if the record was just created" ... what do u mean the record would be empty?

Thanks,

Mav.

[Former Member · Accepted solution]

Hi Mav,

I think Siggi refers only to the situation in which you use only AEDAT...when you create a record this field could be empty and only ERDAT filled (only with a subsequent modification this field will be filled!)...

So it's recommendable to use both !

Bye,

Roberto

[Former Member · Accepted solution]

Hi Roberto,

select * from <table>

where erdat in ex_dat

or aedat in ex_dat.

What records would be pulled with this select statement? I mean what does this piece of code do actually, with what siggi has suggested? Let me guess, it would get all the records where …. I don’t know.

Thanks,

Mav

[Former Member · Accepted solution]

Hi Mav,

For example if ex_dat is 20051019, then the select statement will return all the records that have been either CREATED or UPDATED on 20051019.

Normally, when a new record is created, its ERDAT is avlbl but AEDAT is blank. So this statement can fetch such records. Also there could be records that were created previously but updated on 20051019.

This statement will ensure that all the CHANGES (additions / modifications) are extracted.

Hope it helps.

[Former Member · Accepted solution]

Thanks for the reply. It was what I was looking for. So would the ex_dat be the current date or system date. Am I right? If no what would be ex-dat? And one more thing, when siggi says a function module using a self defined extract structure, what does he mean?

I always thought the extract structure was system generated. From what I get is, create a view with all the required fields, and use the extract structure of the FM with all the addition custom fields. Correct me if I’m wrong.

Currently, I have view and the view has been enhanced using a user exit to fill in a lot of custom fields. So if I use a FM, How would I get my custom fields, now we are using EXIT_SAPLRSAP_002 to fill in the fields? Does this mean, I need to use the FM and user exit to achieve what I reaaly want?

And what would happen if the custom fields did not produce a time stamp to trace? Will that issue be taken care by the FM or the extract structure Siggi was suggesting?

Thanks,

Mav.

Message was edited by: Maverick

[Former Member · Accepted solution]

Hi Mav,

well I think you can create a view on the tables in question to use it as the basis for extraction. Additionally you need to create a ddic structure that contains all fields you want to extract and you need to create a fm for the extraction. When you set up your datasource, you need to specify a date field for the generic delta. Suppose the field is named just 'DATE'. When it comes to extraction this field will be passed to the fm (this is meant by ex_dat). In the fm you need to fill an internal table of type of your created ddic structure. See also my weblog about the generic extraction using a fm. You can implement all coding you need in the fm.

Hope it is clearer now!

regards

Siggi

PS: Here the link to my weblog: /people/siegfried.szameitat/blog/2005/09/29/generic-extraction-via-function-module

Message was edited by: Siegfried Szameitat

[Former Member · Accepted solution]

Thanks Siggi for all the patient answers. But please bear some more of my questions. I was asked to do an investigation on the feasibility of delta enabling a data source. So anything I write down on my report should make sense to me not to mention others. Hope you understand my anxiety. From the answers from the forum, I was pretty much convinced that this could be delta enabled, so I communicated the same to the client, now one of them says that many of the status fields (custom) were tracked in logs not in database tables, basically he says many of the custom fields don’t produce a time stamp to trace. So he thinks this data source cannot be delta enabled.

What do u think of this comment? Can we achieve a delta inspite of this using a FM?

What is a DDIC Structure?

Can I include all my custom fields in DDIC structure?

Do I need to use the user exit along with the FM? (No ABAP background)

Thanks in Advance.

Mav.

[Former Member · Accepted solution]

Hi Mav,

well I don't know about what application you are talking. But normally even for status changes there are tables. In R/3 e.g. there is jcds for system and user status changes. Additionally it might be possible to track the changes reading the change documents from table cdhdr. Using a fm it will surely be possible to get a delta as you/your customer want.

regards

Siggi

PS: May be you can let me know your requirement and possibly I will be able to help you.

[Former Member · Accepted solution]

Thanks for the reassuring answer. I don’t have any fancy requirement with me, but I can give an idea what is being asked. Here is the Scenario:

We have a generic extractor pulling data (Approx 80000) on a daily basis. The data source is Plant maintenance attribute and texts. The DB view consistes of tables, AFIH, ILOA, T350, AUFK, CRHD, and AFKO. And another 40 more custom fields that are being filled by a user exit like BWSTSYS1 to 7, BWSTUSR0 to 3 and some more ZZ fields. Now the client wants to see if there is possibility of delta as the full loads are taking up plenty of time. This is what is being asked.

How do u suggest me to go about it? I believe the FM solution u gave would certainly suffice the requirement, but now as I said customer thinks these custom fields are tracked in logs not in database tables, which I have no clue what he is talking about.

If the FM suffices our requirement, what would be the exact flow of the data. I mean when the extraction is triggered, what are all the logical steps the system would follow to get all the required data. I mean, when the extraction is triggered, what would come into the scene, the user exit or FM, then what would it do, the stuff like that

Thanks in Advance,

MAV.

Message was edited by: Maverick

[Former Member · Accepted solution]

Hi Maverick,

ok, so you are using the standard extractor for the pm orders. Hm... in this case your customer is right, you cannot get a delta for all these added fields. But what you can do is: you can create a second (a custom) datasource for the pm order number with all the 40 custom fields and create a fm to get the delta from jcds, cdhdr ... whereever the changes are tracked. So you will post 2 attribute datasources to your object in BW populating different fields from each. May be this is an option for you/your customer to go.

regards

Siggi

[Former Member · Accepted solution]

So the second data source would contain only the 40 custom fields. And the standard one would have the standard fields. The second data source would have a field ex_dat just like you suggested. And the procedure for extracting to the data would be the same as you suggested. How would the standard datasource attain delta? What would be the diff between the 2 datasources? Can you please elaborate on the procedure?

Thanks in Advance,

Mav.

[Former Member · Accepted solution]

Hi Maverick,

your standard datasource 0pm_order_attr you can handle the delta using 2 infopackages. The first one should extract all orders created in a selected period and the second should extract all order changed in the same period. You can handle this using erdat for the first and aedat for the second infopackage.

The next step is to create the new datasource and a fm for data extraction. This one will provide a delta which will be programmed by you. If you need some sample code let me know. I already explained the functionality of this extraction in my weblog.

Hope this helps!

regards

Siggi

[Former Member · Accepted solution]

Thanks Siggi for all those patient answers. Sorry for all the dumb questions.

From what u say abt the 2 infopacks, I assume you want me to do a selective update thru infopacks. One infopack would get records that are changed and the other would get records that are created.

If so, do I need to write a piece of Code (routine) in the info pack?

So do I need to make the data source delta enabled on the R/3 side?

If I need to, how can I make two fields delta enabled, as the system would allow to include one field as delta specific? Can u be more specific?

Regarding the new data source what would be the logic behind it? I mean what do I ask the system to do when the extraction is triggered? What does the FM do?

Where does it go and check what are the fields that it needs to pick?

Where do I go and track the changes for all the 40 custom fields?

Anyhow I would need help with the sample code, but that would be some time later, once I understand myself what I’m supposed to do and successfully explain it to the customer.

Thanks,

Mav

[Former Member · Accepted solution]

Hi Mav,

about the 2 infopackages, you are absolutely right. You need to do some coding or if available you can use a variable for restricting the load on the actual day or a specific time range, depending on your planned scheduling. E.g. For a daily load always restrict the package to one day, for a weekly load restrict it to today - 7 days. You don't need to enable the datasource for delta extraction in this case.

For the fm you need to check your 40 additional fields and how the changes for them are tracked in the system. As for the status fields I believe you can check the entries in table jcds and for the others you might check the contents of table cdhdr and cdpos. May be you need to check other entries or may be you need to enable the logging first. I cannot provide you with this information as this has to be checked in your system. But if you identified the tables it is possible to create a fm that selects all changes on these fields for a specific pm order by selecting the change docs created in a specific time range.

Hope it helps a bit more additionally.

regards

Siggi

PS: I also think it is time to assign some points as a little thank's to all that already helped you with this issue.

[Former Member · Accepted solution]

Thanks for everything Siggi. A few more questions. In the FM do we need to have a field of PM_ORDER too? If no, how would the FM select all the changes on the custom fields for a specific PM Order.

Is there a way I can track changes in the system for all the custom fields? As I’m not sure which field is tracked in which table? I understand you need to take a look at the system to answer my question, I was just curious if there was any generic way to track the changes to the fields.

Thanks alot.

Mav.

PS: Siggi, I don’t see the usually buttons to assign points. Some times it happens I believe even last time, I couldn’t assign points to other guy who was very helpful, but the system did allow me after a couple of days and I did assign points. Sorry for that, you deserve all the points I can assign

Message was edited by: Maverick

[Former Member]

Hi Maverick,

we need to extract the jcds tables for user

status changes etc.

we are facing similar problem with our client,

Do you have code/documentation for the problem are facing. it would be great if you could provide abap code / for the design issue on the PM_ORDER.

Thanks for the BW guru sigi.. too.

Thanks,

Andy

[Former Member]

1) You will want to use the change date because it updates for every change. The creation date will never change and hence modifications to a record will not be detected.

2) If I understand well: You have an ABAP in place that calculates the extraction dates? For a delta this is not needed. Keep the selection fields empty.

3) If I remember correctly: A timestamp gives a date and time according to Greenwich Mean Time (GMT). That means that timestamps can be used by all you systems even in other countries and they will have all records 'stamped' correctly.

The change date relates to the local system date (sy-datum).

4) If you use a calender field, upon init the delta administration makes a note about the last calendar date that has been extracted. During the next delta, all dates between the last extraction date and the current date are included in the delta package. That is why ERDAT isn't suitable for most delta applications.

Hope this helps.