Extract the new , changed , deleted vendor master data -urgent pls

Question

Hi all,
I have require ment like i need to extract all new, changed and deleted data from SAP TO MAXIMO
i need to send to a windows environment which both systems share,
i am using LFA1 ,CDHDR , CDPOS Tables , i will get the reuired information , can i use gui_download
to download to windows environment which both system are mapped to a common shared folder.
i will extract the infrmation and sent to a shared folder.
this a backround job  schedule daily once.and also i have to sent the file contents to spool also.
please suggent some code existing or how to do the logic behind.
shall i use open data set
                read data set
                close data set.
please suggest ways of doing............urgent.
regards
kodamanchili

Answer 1

With regards to the writing out of the data that, you are correct that you should use the Data Set commands if you are attempting to write a file out to the application server.  If you are using any sort of EAI tool then there maybe are other ways specific to the tool for sending data, such as some of the tools utilize RFCs to send the data.
For the actual identifying of the changed records, it is best not to write delta interfaces directly against the change document tables (CDHDR and CDPOS).  Instead you should be ustilizing change pointers.  Change pointers are transient data stored in the BDCP and BDCPS tables (combiend togehter into view BDCPV) or stored in BDCP2 if configured to use this newer change poitner table for much better performance.
An instance of a change pointer in the change pointer tables will indicate the record that has changed and point to the changed document in the change document tables that can be referenced to extract more specific information.
The nice thing about change pointers are:
- They are transient, at the end of your extract you clear the ones that you've extracted so that the next time you will get the ones that have been pulled since then.
- You can setup instances of your change pointer object that are specific to an extract program so that two extract programs for similiar or even completly the same data won't itnerfere with each other.
- The CDHDR and CDPOS tables are great for extracting changes that have occured over time for a specific instance of a buisenss document (ex. Vendor) but do not perform well over time for extracting all changes associated with all instances of a buisness document (ex. All vendors that have had changes since the last run of the program).  Programs that extract directly against CDHDR and CDPOS do perform delta extract functionality are oftern a performance problem as time progresses and the tables grow in size.  If used properly Change Pointers are efficient becuase the tabels can be kept small and are optimized for the extracting of deltas.
For any tables that log change documents in CDHDR and CDPOS you can configure change pointers to be populated in the BDCP* tables.
Change pointer configuration:
- BD61 - Activate change pointers globally within the SAP instance
- WE81 - Need to create an ALE message type (even if you're not actaully going to connect it to an IDoc)
- BD50 - Activate change pointer functionality for your message type
- BD52 - Define the individual change documents, tables and fields that you want to have as part of your tracking
Your extract program will use two functions:
- CHANGE_POINTERS_READ - Use this to get a list of all change pointers since the last execution
- CHANGE_POINTERS_STATUS_WRITE - Use this to mark the change pointers as extracted so that they won't get picked up on the next execution
Transaction BD22 (Program RBDCPCLR) should be scheduled to run regularily to delete from the change pointer tables the records that have been marked as processesd.
Note - A common mistake that is made is that the change pointers are read, some filtering is done for specific ones that should be extracted and then only the extracted ones have their change pointer status updated.  It's important to update the status on all of the change pointers because otherwise they'll be picked up again on the next run of the program and will be filtered out again, so over time the number of selected change pointers will keep growing since they will never get purged from the change poitner tables.
Note that the BDCP and BDCPS tables have a number of performance issues when the selections are done against them due to the way they are joined and the crieteria that is used for selecting.  Becuase of this SAP has implimented a new change pointer table BDCP2 which is a single table as opposed to using a join.  In order to utilize BDCP2:
- Used SM30 to update V_TBDME.  For your message type turn on the checkbox for BDCP2.
- Run program RBDCPMIG for your message type, this will migrate existing pointers over to the BDCP2 table.  If you can guarentee that there are no existing pointers then you can use SM30 to update for your message type the target of the pointers as being BDCP2
~Ian