IDocs using Change Pointers - Useful Transactions
1. BD21 - Creating IDoc Types from Change Pointers
Sometimes lot of Change Pointer gets created, but fails to get processed due to system issues.
This t-code is quite helpful to generate IDocs from unprocessed change pointers. The status of change pointer can easily be checked from BDCPV table/view.
2. BD22 -Delete Change Pointers
This one is also quite helpful in production environment. Sometimes we can have scenarios where a lot of change pointers gets created due to some erroneous configuration or settings. In order to remove them from the system and clear up the associated tables, this t-code is quite helpful.
3. Reprocessing Successful IDocs again
Using BD87, we cannot re-process successful IDocs again, but sometime certain issues may require us to re-send an already processed successful IDoc.
Also, If the number of Idocs that needed to be retransmitted is limited, then you can retransmit them from the concerned application like Shipment, Delivery, Purchase Order by Reprocessing the Output Type.
But when we need to transmit multiple IDocs, using the standard program RC1_IDOC_SET_STATUS is quite helpful.
You can go to WE02 or WE09, copy all the processed IDoc numbers and paste them after executing this program in SE38. You would also need to specify the new IDoc status .
If you need to process this IDoc again using BD87, you cann;t directly set the same to 30 ( IDoc ready for dispatch), as BD87 remembers the last status (which was '53'- Application document posted) and hence wouldn't again process this IDoc.
Hence we can change the status to say some intermediate one like 32 - (Idoc was edited) and then again run this program and change the status t0 30 from 32.
After that we can again process this IDocs using BD87 and re-send them to the external system like EDI.
IDoc Tips - Change Pointers and Reprocessing IDocs
by Biswa | Sunday, April 26, 2009 in Change Pointers, IDocs | comments (3)
Sending Inbound IDocs from a SAP Program
by Biswa | Tuesday, November 04, 2008 in IDocs, Tips | comments (3)
In most cases, the inbound IDoc to SAP is generated by an external system (say XI) and passed on to SAP. The inbound IDoc is then processed using the process code / corresponding function module. But in certain cases, due to the client requirements, the interface program needs to be designed in such a way that the Inbound IDoc originates from within the same SAP system i.e. both the sending and receiving system are the same.
Now mostly in such requirements, we generally generate the IDoc after reading data from a flat file. The file is passed to the application server by a middleware (say XI). The SAP interface program reads the file from the application server and then starts processing the data. To create the inbound IDoc, we need to use the Function Module ‘IDOC_INBOUND_WRITE_TO_DB’. This creates and saves the IDoc to the database.
The control record information for the inbound IDoc is passed to pc_control_record (Similar to EDIDC – IDoc control record). In the control records, all relevant information like status (53); receiver port, receiver partner no.; sender port; sender partner no etc are populated. All the IDoc data is passed to internal table t_data_records (Similar to EDIDD – IDoc control record). The IDoc data is read from the incoming file and processed and then populated to internal table itab_data_records_db with segment name etc.
The inbound process data is passed to the function module.
CALL FUNCTION 'IDOC_INBOUND_WRITE_TO_DB'
exporting
pi_do_handle_error = 'X'
pi_return_data_flag = ' '
importing
pe_idoc_number = control_record_db_in-docnum
pe_inbound_process_data = wa_inbound_process_data_in
tables
t_data_records = itab_data_records_db
changing
pc_control_record = control_record_db_in
exceptions
idoc_not_saved = 1
others = 2.
Now if the inbound IDoc has been successfully created and we want to process the same, the function module ‘IDOC_START_INBOUND’ can be used. Here we pass the inbound process data containing the IDoc process code and event code to wa_inbound_process_data_in. The status and release are added to the control records internal table i_control_records.
CALL FUNCTION 'IDOC_START_INBOUND'
exporting
pi_inbound_process_data = wa_inbound_process_data_in
pi_called_online = 'X'
succ_show_flag = 'X'
tables
t_control_records = i_control_records
exceptions
others = 1.
If we have no exception, then the IDoc will be successfully processed and have status ‘53’.
Link to this post on our new blog : http://www.sapyard.com/
Now mostly in such requirements, we generally generate the IDoc after reading data from a flat file. The file is passed to the application server by a middleware (say XI). The SAP interface program reads the file from the application server and then starts processing the data. To create the inbound IDoc, we need to use the Function Module ‘IDOC_INBOUND_WRITE_TO_DB’. This creates and saves the IDoc to the database.
The control record information for the inbound IDoc is passed to pc_control_record (Similar to EDIDC – IDoc control record). In the control records, all relevant information like status (53); receiver port, receiver partner no.; sender port; sender partner no etc are populated. All the IDoc data is passed to internal table t_data_records (Similar to EDIDD – IDoc control record). The IDoc data is read from the incoming file and processed and then populated to internal table itab_data_records_db with segment name etc.
The inbound process data is passed to the function module.
CALL FUNCTION 'IDOC_INBOUND_WRITE_TO_DB'
exporting
pi_do_handle_error = 'X'
pi_return_data_flag = ' '
importing
pe_idoc_number = control_record_db_in-docnum
pe_inbound_process_data = wa_inbound_process_data_in
tables
t_data_records = itab_data_records_db
changing
pc_control_record = control_record_db_in
exceptions
idoc_not_saved = 1
others = 2.
Now if the inbound IDoc has been successfully created and we want to process the same, the function module ‘IDOC_START_INBOUND’ can be used. Here we pass the inbound process data containing the IDoc process code and event code to wa_inbound_process_data_in. The status and release are added to the control records internal table i_control_records.
CALL FUNCTION 'IDOC_START_INBOUND'
exporting
pi_inbound_process_data = wa_inbound_process_data_in
pi_called_online = 'X'
succ_show_flag = 'X'
tables
t_control_records = i_control_records
exceptions
others = 1.
If we have no exception, then the IDoc will be successfully processed and have status ‘53’.
Link to this post on our new blog : http://www.sapyard.com/
Subscribe to:
Posts (Atom)