2016 Feb 12 11:56 AM
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
2016 Feb 12 2:51 PM
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
2016 Feb 12 2:51 PM
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
2016 Feb 16 1:53 PM
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |