Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Using change pointer with flat files instead of IDOC

Former Member
0 Likes
980

Hello Gurus,

This is my first question on this forum, thanks in advance for your help

I am quite lost currently:

I need to set-up an interface to send daily the whole data of modified customers during the day, whatever field(s) are modified in general or sales data.

I need also to use flat files and not IDOCs.

I am a beginner on change pointers, so I decided to do the following:

- activate change pointer globally in BD61

- check in CDHDR modified customers based on Object (OBJECTCLAS) = DEBI ; Date (UDATE)= today and TCODE= XD01; XD02; VD01; VD02

- Take the result in "OBJECTID"

Then based on this list of modified customers during the day, I take the data I need in tables KNA1VV etc

What do you think of this?

Is there a smarte way to use change pointers without using IDOCs?

Is it possible to set-up a message if I don't want to use an IDOC for example?

It seems that CDHDR will grow without limit, will it affect performances? If yes, would you have any recommendations in terms of best practice ?

Thanks in advance for your help.

Regards,

Guy

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
875

Hello Guy,

I used the IDOCs as the vehicle to trigger the writing of the flat files. There is probably a way to avoid using IDOCs. But since IDOCs respond so well to change pointers it seemed like the cleanest way.

I needed to write and send out a flat file of certain A/P vendor details, but only when the vendor was added to a new company code.

The change pointer to trigger IDOC was only on the company code field, as this was the only time we wanted a flat file.

I created custom reduced IDOC with only vendor number and company code (the key fields needed by the custom flat file program to read the database), also a few other fields in the IDOC of no interest but required by ECC.

The IDOC was created when the vendor was added to a new company code.  The IDOC in turn ran the custom program, which read the database vendor master and wrote all data needed to the flat file.

Oh, and an archiving and delete job ran every night to remove all of these "temporary" IDOCs once they reached a few days old.  This kept the database from filling up with these IDOCs yet still left a few day's worth behind in case of troubleshooting.

~~Sue Morton

Hello Gurus,

This is my first question on this forum, thanks in advance for your help

I am quite lost currently:

I need to set-up an interface to send daily the whole data of modified customers during the day, whatever field(s) are modified in general or sales data.

I need also to use flat files and not IDOCs.

I am a beginner on change pointers, so I decided to do the following:

- activate change pointer globally in BD61

- check in CDHDR modified customers based on Object (OBJECTCLAS) = DEBI ; Date (UDATE)= today and TCODE= XD01; XD02; VD01; VD02

- Take the result in "OBJECTID"

Then based on this list of modified customers during the day, I take the data I need in tables KNA1VV etc

What do you think of this?

Is there a smarte way to use change pointers without using IDOCs?

Is it possible to set-up a message if I don't want to use an IDOC for example?

It seems that CDHDR will grow without limit, will it affect performances? If yes, would you have any recommendations in terms of best practice ?

Thanks in advance for your help.

Regards,

Guy

2 REPLIES 2
Read only

Former Member
0 Likes
876

Hello Guy,

I used the IDOCs as the vehicle to trigger the writing of the flat files. There is probably a way to avoid using IDOCs. But since IDOCs respond so well to change pointers it seemed like the cleanest way.

I needed to write and send out a flat file of certain A/P vendor details, but only when the vendor was added to a new company code.

The change pointer to trigger IDOC was only on the company code field, as this was the only time we wanted a flat file.

I created custom reduced IDOC with only vendor number and company code (the key fields needed by the custom flat file program to read the database), also a few other fields in the IDOC of no interest but required by ECC.

The IDOC was created when the vendor was added to a new company code.  The IDOC in turn ran the custom program, which read the database vendor master and wrote all data needed to the flat file.

Oh, and an archiving and delete job ran every night to remove all of these "temporary" IDOCs once they reached a few days old.  This kept the database from filling up with these IDOCs yet still left a few day's worth behind in case of troubleshooting.

~~Sue Morton

Read only

0 Likes
875

Thanks for you help Sue.