QUEUE _ERROR IN BDC
hi all,
iam using BDC_close_group.
while executing this iam getting queue error.
plz suggest me any solution
Hi ,
Can you please let us know, actual error ur getting, when re u getting that error,
If possible , paste that error message, so that we can try to help you.
regards,
Naveen
Similar Messages
-
Hi all,
I am processing more than 50 BDC sessions programatically. Will SAP queue the sessions if sufficient resources are not available ?
Will any changes / settings in Basis (setting for number of background / dynpro processes) can help in increasing the efficiency of my task.
Appreciate your help.
Thanks,
Regards,
MohaiyuddinAssuming SAP Kernel will take care for queuing BDC sessions
-
Hi everyone
I have multiple questions on BDC.Would u please answer them with explanations ASAP...
1. How do you create a batch input session for a transaction?
a) We create a bdc and use ‘call transaction’ in background mode.
b) We create a bdc and use ‘call transaction’ in error mode.
c) We create a bdc and use ‘bdc_insert’ for the transaction.
d) None of the above.
2. What is the alternative to batch input session?
a) Load module
b) Call transaction
c) BAPI
d) Idoc segment
3. Which SAP table stores the BDC session queue information?
a) APQD
b) APQL
c) APQQ
d) APQI
4. Which program can be used to release BDC sessions within a job?
a) RSBDCSUB
b) RSBDCJOB
c) RSSUBBDC
d) BDCRECXX
5. Which one of the following is output to the job log when included in an ABAP program running in the background?
a) Write statements
b) message statements
c) report parameters
d) Submit statements
6. Your program specs call for you to read the first 10 records from a text file (fname1), and write them out to another text file (fname2).
Which block of code will accomplish the result desired in the above scenario?
a) Open dataset fname2 for input in text mode.
Do 10 times.
Read dataset fname1 into hold_var.
Transfer hold_var to fname2.
Enddo.
b) open file fname1 for output.
Open file fname2 for input.
Read dataset fname1 into hold_var 10 times.
Transfer hold_var to fname2.
c) open file fname1 for input.
Open file fname2 for output.
Do 10 times.
Read file fname1 into hold_var.
Transfer hold_var into fname2.
Enddo.
d) open dataset fname1 for input in text mode.
Open dataset fname2 for output in text mode.
Do 10 times.
Read fname1 into hold_var.
Write hold_var to fname2.
Enddo.
7. sy-dynpro is
a) screen no
b) program
c) table
d) field name
8. Which of the following are NOT correct usage of BDC_cursor?
a) To position the cursor on a particular field.
<bdc_tab>-FNAM = 'BDC_CURSOR'.
<bdc_tab>-FVAL = ‘fieldx’ .
b) To position the cursor on a particular field.
<bdc_tab>-FNAM = ‘fieldx’
<bdc_tab>-FVAL = 'BDC_CURSOR'. .
c) For fifth row of Table control
<bdc_tab>-FVAL = 'fieldx(5)'.
d) For fifth row of Table control
<bdc_tab>-FNAM = 'BDC_CURSOR(5) '.
9. In case of background processing of a BI session, which authorization is checked?
a) Developer of the program that schedules BI Session
b) User who executes the BI session
c) User who executes the program that schedules BI Session
d) User ID that is passed to the BDC_OPN_GROUP function module inside the calling program
10. Which of the following are TRUE about Transaction Recorder?
a) Transaction Code is SHDB
b) Transaction Code is SM35
c) It can generate ABAP code for the BDC program automatically
d) It can generate ABAP code for the Call Transaction program automatically
Regards,
PratibhaHi,
1) C We create a bdc and use bdc_insert for the transaction
2) b) Call transaction
3. d) APQI
4. a) RSBDCSUB
5. b) message statements
6. d) open dataset fname1 for input in text mode.
Open dataset fname2 for output in text mode.
Do 10 times.
Read fname1 into hold_var.
Write hold_var to fname2.
Enddo.
7. a) screen no
8. b) To position the cursor on a particular field.
<bdc_tab>-FNAM = fieldx
<bdc_tab>-FVAL = 'BDC_CURSOR'. .
9.b) User who executes the BI session (or)
c) User who executes the program that schedules BI Session
10. a) Transaction Code is SHDB
c) It can generate ABAP code for the BDC program automatically
Regards -
URGENT - HOW TO PROCESS A BDC SESSION (IN BACKGROUND) FROM INSIDE A REPORT
Hi All,
I have a requirement wherein I need to create a BDC session for mass update(from file) of one transaction and check if at all that update has taken place and proceed with the same session for another transaction.
For this I need to know how to process the session in background in a report, so that if the processing is done, the next set of data to update a different transaction can happen.
All inputs are welcome and highly valuable to me.
If someone is unable to intrepret this, I'll detail it again.
Thanks in advance,
Vaishnavi VaradarajanHi,
1.Use RSBDCDRU is an exe pg.With this u can download the logs into local file.
2.It will create the spool request .from there u can download or print.
OtherWise:
Use the code from the link below. U need to provide the session queue id as input and it will download the log to an excel file. U can change it to ur reqmt.
Re: BDC
regards
kiran -
RFC enabled function module is not runing the BDC code in it.
Dear Experts,
1. We have created a RFC enabled function module to change status of a activity and to save it we are using BDC code and we have also put the code in the RFC FM only.
The RFC fm is runing fine and changing the data and also saving it by runing the BDC when run in the R/3 system only.
But when i run the FM from portal its just chaning the status but not runing the BDC code in it.
below i am puting the code of the FM.
FUNCTION ZRFC_CRM_STATUS_CHANGE_EXTERN .
""Local Interface:
*" IMPORTING
*" VALUE(CHECK_ONLY) TYPE XFELD DEFAULT ' '
*" VALUE(CLIENT) LIKE SY-MANDT DEFAULT SY-MANDT
*" VALUE(OBJNR) TYPE CRM_JSTO-OBJNR OPTIONAL
*" VALUE(USER_STATUS) LIKE CRM_JEST-STAT
*" VALUE(SET_INACT) TYPE XFELD DEFAULT ' '
*" VALUE(SET_CHGKZ) LIKE CRM_JSTO-CHGKZ OPTIONAL
*" VALUE(XNOAUTO) LIKE CRM_JSTO_UPD-XNOAUTO OPTIONAL
*" VALUE(NO_CHECK) TYPE XFELD DEFAULT ' '
*" VALUE(ZOBJNR) TYPE CHAR80
*" VALUE(OBJECT_ID) TYPE CRMT_OBJECT_ID
*" EXPORTING
*" VALUE(STONR) LIKE TJ30-STONR
*" EXCEPTIONS
*" OBJECT_NOT_FOUND
*" STATUS_INCONSISTENT
*" STATUS_NOT_ALLOWED
*{ INSERT D60K900707 1
DATA: BEGIN OF JSTAT_TMP.
INCLUDE STRUCTURE JSTAT.
DATA: END OF JSTAT_TMP.
data: bdcdata like bdcdata occurs 0 with header line.
data: dire type CRMD_ACTIVITY_H-direction.
CLEAR: DIRE.
OBJNR = ZOBJNR.
MANDT = CLIENT.
JSTAT_TMP-STAT = USER_STATUS.
JSTAT_TMP-INACT = SET_INACT.
IF USER_STATUS+0(1) NE EXTERN.
RAISE STATUS_NOT_ALLOWED.
ENDIF.
Statusobjekt ggf. einlesen
PERFORM STATUS_READ USING OBJNR IOBTYP ISTSMA NOT_FOUND.
CHECK NOT_FOUND = OFF.
ggf. Änderungsbelege aktivieren
IF SET_CHGKZ = 'X' AND JSTO_BUF-CHGKZ = SPACE AND CHECK_ONLY = SPACE.
PERFORM SET_CHGKZ USING OBJNR.
ENDIF.
set XNOAUTO-flag if desired
IF XNOAUTO = 'X' AND CHECK_ONLY = SPACE.
PERFORM SET_XNOAUTO USING OBJNR.
ENDIF.
crm_jostd-OBJNR = OBJNR.
Status-Puffer füllen
REFRESH JEST_BUF_A.
REFRESH JEST_BUF_E.
CLEAR JEST_BUF_A.
CLEAR JEST_BUF_E.
CLEAR JEST_K.
MOVE MANDT TO JEST_K-MANDT.
MOVE crm_jostd-OBJNR TO JEST_K-OBJNR.
READ TABLE JEST_BUF WITH KEY JEST_K BINARY SEARCH.
IF SY-SUBRC IS INITIAL.
TABIX = SY-TABIX.
MOVE-CORRESPONDING JEST_BUF TO JEST_BUF_E.
APPEND JEST_BUF_E.
MOVE-CORRESPONDING JEST_BUF TO JEST_BUF_A.
MOVE MANDT TO JEST_BUF_A-MANDT.
APPEND JEST_BUF_A.
DO.
ADD 1 TO TABIX.
READ TABLE JEST_BUF INDEX TABIX.
IF SY-SUBRC IS INITIAL AND JEST_BUF-OBJNR = crm_jostd-OBJNR.
MOVE-CORRESPONDING JEST_BUF TO JEST_BUF_E.
APPEND JEST_BUF_E.
MOVE-CORRESPONDING JEST_BUF TO JEST_BUF_A.
MOVE MANDT TO JEST_BUF_A-MANDT.
APPEND JEST_BUF_A.
ELSE.
EXIT.
ENDIF.
ENDDO.
ENDIF.
g_no_check = no_check.
OBJNR = ZOBJNR.
PERFORM STATUS_CHANGE_EXTERN USING CHECK_ONLY
OBJNR
JSTAT_TMP
EXTERN.
clear g_no_check.
Zurückschreiben in Puffer
PERFORM CHG_JEST_BUF_E.
ggf. Statusordnungsnummer ermitteln
IF STONR IS REQUESTED.
CALL FUNCTION 'CRM_STATUS_READ'
EXPORTING
OBJNR = OBJNR
ONLY_ACTIVE = 'X'
IMPORTING
STONR = STONR.
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT = 'X'
IMPORTING
RETURN =
*COMMIT WORK.
wait up to 10 seconds.
CLEAR bdcdata.
bdcdata-program = 'SAPLCRM_1O_MANAG_UI'.
bdcdata-dynpro = '0100'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_OKCODE'.
bdcdata-fval = '=READ'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-program = 'SAPLCRM_1O_MANAG_UI'.
bdcdata-dynpro = '0510'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_CURSOR'.
bdcdata-fval = 'GV_OBJECT_ID'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'GV_OBJECT_ID'.
bdcdata-fval = OBJECT_ID.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_OKCODE'.
bdcdata-fval = '=OKAY'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-program = 'SAPLCRM_1O_MANAG_UI'.
bdcdata-dynpro = '0100'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_OKCODE'.
bdcdata-fval = '=1OMAIN_TT'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-program = 'SAPLCRM_1O_MANAG_UI'.
bdcdata-dynpro = '0100'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_CURSOR'.
bdcdata-fval = 'CRMT_7010_ACTIVITY_UI-DIRECTION'.
APPEND bdcdata.
select single direction from CRMD_ACTIVITY_H into dire
where guid = objnr.
if sy-subrc = 0.
if dire = '0'.
dire = '1'.
elseif dire = '1'.
dire = ''.
elseif dire is initial.
dire = '1'.
endif.
endif.
CLEAR bdcdata.
bdcdata-fnam = 'CRMT_7010_ACTIVITY_UI-DIRECTION'.
bdcdata-fVAL = DIRE.
APPEND bdcdata.
CLEAR bdcdata.
bdcdata-fnam = 'BDC_OKCODE'.
bdcdata-fval = '=SAVE'.
APPEND bdcdata.
CALL TRANSACTION 'CRMD_BUS2000126' using bdcdata mode 'N'.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT = 'X'
IMPORTING
RETURN =
*COMMIT WORK.
wait up to 5 seconds.
*} INSERT
ENDFUNCTION.
Thanks and regards
NeelDear experts,
Already the FM is RFC enabled other i won't be able to call it from portal
and coming to using the BAPI_ACTIVITY CHANGE fm that acting very weird so we are using the CRM EXTERN CHANGE USER STATUS fm which is working fine but the only problem is even when we comit from BAPI_TRANSACTION_COMMIT its not getting the delta queue of BW updated eventhough its chaning the status.
So for the above reasons we are using the BDC code in the FM for pressing the save button then its will update the changes to BW delta queue as well.
its working fine when i run it from the system in tcode SE37 only the BDC code is not runing when i am doing it from portal apart from the fm is chaning the status .
thanks and regards
Neel -
Issue while inserting a BDC program in Inbound Proxy.JDBC-- PI-- SAP.
The scenerio is jdbcsender-sappi-inboundproxy(ECC6.0).
The issue is related to SAP Plant Maintenance Module where We have a requirement for creating Maintenance item
programmatically from (SQLDatabase)Legacy Data for one of the interface.
since there are no standard BAPIS/Idocs or function modules available from SAP side for creating the maintenance item. So I
have written BDC program and with the help of submit statement in inbound proxy program, I am calling BDC program for
creation of the maintenance item.
When I tested the program independently on proxy side the Maintenance Item is getting created successfully but when I
executed from end-to-end ie. SQLDATABASE->SAP PI-->SAP. The message is getting strucked into the queue and queue got stopped on SAP.
ECC side and the status of the message is scheduled state on SXMB_MONI transaction of SAP ECC.
As the message is in scheduled state multiple number of Maintenance Items are getting created with the same values.
Has any one of our SAP friends, encountered this type of issue while inserting a BDC program in inbound proxy, please help
in fixing this issue. FYI... I am using sap pi7.0 with service pack 24 and ecc6.0
Waiting for your kind expert guidance...
cheers,
RamRaj,
Thanks for the reply. I have tried registering the queues but still the same problem. the message got stuck in the queue of ECC and showing below message in queue.
function module StatusText
SXMS_ASYNC_EXEC connection closed (no data)
I have checked in the forums especially for this issue but no one has provided the answer for this.
Thanks and Regards
Ram -
Problem in the BDC Table Control for the T.Code VA01
Hi,
I faced probelm in the BDC of the VA01. In the Table Control
the records are entered upto 12 line items. after 13th line item overwrites the first record. How to solve the Problem.
Please help me.or use this
Internal table definition *
data : begin of bdcdata occurs 0.
include structure bdcdata.
data : end of bdcdata.
data: begin of messtab occurs 0.
include structure bdcmsgcoll.
data: end of messtab.
data: v_chr_opengrp type c,
r_matnr like mara-matnr, "variable for material conversion
r_werks like marc-werks, "variable for plant
v_str_fname type string.
data: begin of count2,
inrec(9) type n, " input I_MATERIAL count
create(9) type n, " create count
error(9) type n, " error count
bdc(9) type n, " count of BDC creates
end of count2.
types: begin of ty_source,
partn_numb(10) type n ,"Customer Number 1
ref(035),
sales_org(4) , "Sales Organization
distr_chan(2) , "Distribution Channel
division(002), "DIVISION
doc_type(4) , "Sales Document Type
purch_no(020), "Purchase order
material like vbap-matnr,
reqqty(018),
reqdate(010),
end of ty_source,
begin of ty_header ,
partn_numb(10) ,"Customer Number 1
ref(035),
sales_org(4) , "Sales Organization
distr_chan(2) , "Distribution Channel
division(002), "DIVISION
doc_type(4) , "Sales Document Type
purch_no(020), "Purchase order
end of ty_header,
begin of ty_item,
partn_numb(10) ,"Customer Number 1
ref(035),
material like vbap-matnr,
reqqty(018),
reqdate(010),
end of ty_item.
data : msg(240) type c, " Return Message
e_rec(8) type c, " Error Records Counter
rec_no(8) type c, " Records Number Indicator
s_rec(8) type c, " Successful Records Counter
t_rec(8) type c, " Total Records Counter
v_matnr like mara-matnr.
data: val(2) type n value 01.
data : begin of bdc_itab occurs 0.
include structure bdcdata.
data : end of bdc_itab.
data : t_source type standard table of ty_source with header line,
t_header type standard table of ty_header initial size 1,
t_item type standard table of ty_item initial size 1,
t_target type standard table of bdcdata initial size 1.
data : w_source type ty_source,
w_source1 type ty_source,
w_header type ty_header,
w_item type ty_item,
w_target type bdcdata,
count type i,
count1 type n.
Variable Declaration
data: w_fname type string,
fnam(20),
date1(10),
i(2) type n,
v_count type i,
v_group type apqi-groupid.
*& selection screen
selection-screen :begin of block bl1 with frame title text-001.
parameters : p_fname type rlgrap-filename, "Input file
p_update(1) default 'N', "Input for update mode
p_bdcgrp(12) default 'SD_ORDERS'. "Input for session name
selection-screen end of block bl1.
**&SELECTION SCREEN VALIDATIONS
at selection-screen on value-request for p_fname.
call function 'KD_GET_FILENAME_ON_F4'
exporting
program_name = 'ZMATERIAL'
dynpro_number = '1000'
field_name = 'P_FNAME'
changing
file_name = p_fname.
*& Start of selection
start-of-selection.
if p_fname is initial.
message i016(rp) with 'Please enter a file name'.
leave list-processing.
else.
move p_fname to v_str_fname.
endif.
call function 'GUI_UPLOAD'
exporting
filetype = 'ASC'
filename = v_str_fname
has_field_separator = 'X'
tables
data_tab = t_source
exceptions
file_open_error = 1
file_read_error = 2
no_batch = 3
gui_refuse_filetransfer = 4
invalid_type = 5
no_authority = 6
unknown_error = 7
bad_data_format = 8
header_not_allowed = 9
separator_not_allowed = 10
header_too_long = 11
unknown_dp_error = 12
access_denied = 13
dp_out_of_memory = 14
disk_full = 15
dp_timeout = 16
others = 17.
if sy-subrc <> 0.
message id sy-msgid type sy-msgty number sy-msgno
with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
endif.
sort t_source by ref partn_numb.
loop at t_source into w_source.
add 1 to count2-inrec.
w_source1 = w_source.
AT NEW PARTN_NUMB. "10/31 KVB
at new ref.
w_header-doc_type = w_source1-doc_type..
w_header-sales_org = w_source1-sales_org . "'0001'
w_header-distr_chan = w_source1-distr_chan. "'01'
w_header-division = w_source1-division. " '01'
w_header-purch_no = w_source1-purch_no.
w_header-partn_numb = w_source1-partn_numb.
w_header-ref = w_source1-ref.
append w_header to t_header.
endat.
w_item-partn_numb = w_source1-partn_numb.
w_item-material = w_source1-material.
w_item-reqqty = w_source1-reqqty.
w_item-ref = w_source1-ref.
w_item-reqdate = w_source1-reqdate.
append w_item to t_item.
clear :w_item,w_header.
endloop.
loop at t_header into w_header.
perform bdc_dynpro using 'SAPMV45A' '0101' .
perform bdc_field using 'BDC_CURSOR' 'VBAK-SPART'.
perform bdc_field using 'BDC_OKCODE' '/00'.
perform bdc_field using 'VBAK-AUART' w_header-doc_type.
perform bdc_field using 'VBAK-VKORG' w_header-sales_org.
perform bdc_field using 'VBAK-VTWEG' w_header-distr_chan.
perform bdc_field using 'VBAK-SPART' w_header-division.
perform bdc_dynpro using 'SAPMV45A' '4001' .
perform bdc_field using 'BDC_OKCODE' '/00'.
perform bdc_field using 'BDC_CURSOR' 'VBKD-BSTKD'.
perform bdc_field using 'VBKD-BSTKD' w_header-purch_no.
perform bdc_field using 'KUWEV-KUNNR' w_header-partn_numb.
i = 1.
loop at t_item into w_item where partn_numb = w_header-partn_numb
and ref = w_header-ref.
at new partn_numb.
clear count1.
count = 0.
endat.
count = count + 1.
if count gt 5.
clear i.
i = 2.
perform bdc_dynpro using 'SAPMV45A' '4001' .
perform bdc_field using 'BDC_OKCODE' '=POAN'.
endif.
count1 = count1 + 1.
concatenate 'VBAP-POSNR(' i ')' into fnam.
perform bdc_field using fnam
count1.
concatenate 'RV45A-MABNR(' i ')' into fnam.
perform bdc_field using fnam w_item-material.
concatenate 'RV45A-KWMENG(' i ')' into fnam.
perform bdc_field using fnam w_item-reqqty..
concatenate 'RV45A-ETDAT(' i ')' into fnam.
perform bdc_field using fnam w_item-reqdate.
concatenate 'VBKD-BSTKD_E(' i ')' into fnam.
perform bdc_field using fnam w_item-ref.
i = i + 1.
clear: w_item.
endloop.
clear w_header.
perform bdc_dynpro using 'SAPMV45A' '4001'.
perform bdc_field using 'BDC_OKCODE'
'=SICH'.
perform post_transaction.
refresh bdc_itab.
clear bdc_itab.
endloop.
*endloop.
end-of-selection.
perform finalization.
Start new screen *
form bdc_dynpro using program dynpro.
clear bdc_itab.
bdc_itab-program = program.
bdc_itab-dynpro = dynpro.
bdc_itab-dynbegin = 'X'.
append bdc_itab.
endform. "bdc_dynpro
Insert field *
form bdc_field using fnam fval.
if fval <> ''.
clear bdc_itab.
bdc_itab-fnam = fnam.
bdc_itab-fval = fval.
append bdc_itab.
endif.
endform. "bdc_field
**& Form get_filename
text
--> p1 text
<-- p2 text
*form get_filename .
*call function 'WS_FILENAME_GET'
exporting
def_filename = space
def_path = file
mask = ',.,..'
mode = 'N'
title = text-015
importing
filename = file
exceptions
inv_winsys = 1
no_batch = 2
selection_cancel = 3
selection_error = 4
others = 5.
*endform. " get_filename
*& Form post_transaction
text
--> p1 text
<-- p2 text
form post_transaction .
refresh messtab.
clear messtab.
call transaction 'VA01' using bdc_itab
mode p_update
update 'S'
messages into messtab.
read table messtab with key msgtyp = 'E'.
if sy-subrc eq 0.
perform process_error_messages.
add 1 to count2-bdc.
if v_chr_opengrp is initial.
perform bdc_open_group.
endif.
call function 'BDC_INSERT'
exporting
tcode = 'VA01'
tables
dynprotab = bdc_itab
exceptions
internal_error = 1
not_open = 2
queue_error = 3
tcode_invalid = 4
others = 5.
if sy-subrc <> 0.
case sy-subrc.
when 1.
write: / 'Internal error'.
when 2.
write: / 'Not open error'.
when 3.
write: / 'queue error'.
when 4.
write: / 'tcode invalid error'.
when others.
write: / 'other error'.
endcase.
endif.
else.
add +1 to count2-create.
format intensified off.
format color col_normal.
format color col_normal off.
endif.
clear bdc_itab.
refresh bdc_itab.
endform. " post_transaction
*& Form finalization
text
--> p1 text
<-- p2 text
form finalization .
if v_chr_opengrp = 'X'.
call function 'BDC_CLOSE_GROUP'
exceptions
not_open = 1
queue_error = 2
others = 3.
endif.
get time.
skip 2.
write: / 'Time', sy-uzeit.
skip.
format color col_total on.
write: / 'Total Records: ', 40 count2-inrec.
write: / 'PERNR not of Emp Group 6 ', 40 count2-error.
write: / 'Records Created: ', 40 count2-create.
write: / 'BDC Create in group: ', 40 count2-bdc.
if v_chr_opengrp = 'X'.
skip 1.
format intensified on.
format color col_negative on.
write: / 'PLEASE USE TRANSACTION "SM35" ',
'TO PROCESS THE GENERATED BDC SESSION ... ',
p_bdcgrp.
endif.
endform. " finalization
*& Form bdc_open_group
text
--> p1 text
<-- p2 text
form bdc_open_group .
call function 'BDC_OPEN_GROUP'
exporting
client = sy-mandt
group = p_bdcgrp
holddate = sy-datum
keep = 'X'
user = sy-uname
exceptions
client_invalid = 1
destination_invalid = 2
group_invalid = 3
group_is_locked = 4
holddate_invalid = 5
internal_error = 6
queue_error = 7
running = 8
system_lock_error = 9
user_invalid = 10
others = 11.
if sy-subrc eq 0.
v_chr_opengrp = 'X'.
endif.
endform. " bdc_open_group
*& Form process_error_messages
text
--> p1 text
<-- p2 text
form process_error_messages .
data: begin of loc_aux_message.
include structure message.
data: end of loc_aux_message.
data : msgno type sy-msgno.
loop at messtab.
move messtab-msgnr to msgno.
call function 'WRITE_MESSAGE'
exporting
msgid = messtab-msgid
msgno = msgno
msgty = messtab-msgtyp
msgv1 = messtab-msgv1
msgv2 = messtab-msgv2
msgv3 = messtab-msgv3
msgv4 = messtab-msgv4
importing
messg = loc_aux_message
exceptions
others = 1.
if sy-subrc eq 0.
format color col_negative on.
write: /10 loc_aux_message.
format color col_negative off.
else.
format color col_negative on.
write: /10 t_source-partn_numb.
write: / 'Error creating message'.
format color col_negative off.
exit.
endif.
endloop.
endform. " process_error_messages -
hi,
I want to make bdc for any type of items ,plzz help me out by proving the easiest way of doing it,plzz provide such a tutorial for creating a bdc and help me out by providing excel file format for it.
as help will be definately rewarded.Hi
Hope it will help you.
Reward help.
BATCH DATA COMMUNICATION
About Data Transfer In R/3 System
When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes into replace or complement existing application.
In the process of replacing current applications and transferring application data, two situations might occur:
The first is when application data to be replaced is transferred at once, and only once.
The second situation is to transfer data periodically from external systems to SAP and vice versa.
There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive.
The SAP system offers two primary methods for transferring data into SAP systems. From non-SAP systems or legacy system. These two methods are collectively called batch input or batch data communication.
1. SESSION METHOD
2. CALL TRANSACTION
3. DIRECT INPUT
Advantages offered by BATCH INPUT method:
1. Can process large data volumes in batch.
2. Can be planned and submitted in the background.
3. No manual interaction is required when data is transferred.
4. Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.
To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP system. This program, known as a data transfer program must map the data from the external system into the data structure required by the SAP batch input program.
The batch input program must build all of the input to execute the SAP transaction.
Two main steps are required:
To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.
To pass the table to SAP for processing.
Prerequisite for Data Transfer Program
Writing a Data Transfer Program involves following prerequisites:
Analyzing data from local file
Analyzing transaction
Analyzing transaction involves following steps:
The transaction code, if you do not already know it.
Which fields require input i.e., mandatory.
Which fields can you allow to default to standard values.
The names, types, and lengths of the fields that are used by a transaction.
Screen number and Name of module pool program behind a particular transaction.
To analyze a transaction::
Start the transaction by menu or by entering the transaction code in the command box.
(You can determine the transaction name by choosing System Status.)
Step through the transaction, entering the data will be required for processing your batch input data.
On each screen, note the program name and screen (dynpro) number.
(dynpro = dyn + pro. Dyn = screen, pro = number)
Display these by choosing System Status. The relevant fields are Program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen.
The technical info pop-up shows not only the field information but also the program and screen.
For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical Info.
Note the following information:
- The field name for batch input, which youll find in its own box.
- The length and data type of the field. You can display this information by double clicking on the Data Element field.
Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen).
Place the cursor on the button or menu entry while holding down the left mouse button. Then press F1.
In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.
You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.
Once you have program name, screen number, field name (screen field name), you can start writing.
DATA TRANSFER program.
Declaring internal table
First Integral Table similar to structure like local file.
Declaring internal table like BDCDATA
The data from internal table is not transferred directly to database table, it has to go through transaction. You need to pass data to particular screen and to particular screen-field. Data is passed to transaction in particular format, hence there is a need for batch input structure.
The batch input structure stores the data that is to be entered into SAP system and the actions that are necessary to process the data. The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION.
This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is as follows:
Create a BDCDATA structure
Write the structure out to a session or process it with CALL TRANSACTION USING; and then
Create a BDCDATA structure for the next transaction that is to be processed.
Within a BDCDATA structure, organize the data of screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.
The screen identifier record is followed by a separate BDCDATA record for each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:
Data that is entered into screen fields.
Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.
The BDCDATA structure contains the following fields:
PROGRAM: Name of module pool program associated with the screen. Set this field only for the first record for the screen.
DYNPRO: Screen Number. Set this field only in the first record for the screen.
DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to (blank) for all other records.)
FNAM: Field Name. The FNAM field is not case-sensitive.
FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format.
Transferring data from local file to internal table
Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.
Population of BDCDATA
For each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure.
All these five initial steps are necessary for any type of BDC interface.
DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same.
First step for both the methods is to upload the data to internal table. From Internal Table, the data is transferred to database table by two ways i.e., Session method and Call transaction.
SESSION METHOD
About Session method
In this method you transfer data from internal table to database table through sessions.
In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.
When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system.
Unless session is processed, the data is not transferred to database table.
BDC_OPEN_GROUP
You create the session through program by BDC_OPEN_GROUP function.
Parameters to this function are:
User Name: User name
Group: Name of the session
Lock Date: The date on which you want to process the session.
Keep: This parameter is passed as X when you want to retain session after
processing it or to delete it after processing.
BDC_INSERT
This function creates the session & data is transferred to Session.
Parameters to this function are:
Tcode: Transaction Name
Dynprotab: BDC Data
BDC_CLOSE_GROUP
This function closes the BDC Group. No Parameters.
Some additional information for session processing
When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not.
However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.
CALL TRANSACTION
About CALL TRANSACTION
A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>
Messages into <MSGTAB>.
Parameter 1 is transaction code.
Parameter 2 is name of BDCTAB table.
Parameter 3 here you are specifying mode in which you execute transaction
A is all screen mode. All the screen of transaction are displayed.
N is no screen mode. No screen is displayed when you execute the transaction.
E is error screen. Only those screens are displayed wherein you have error record.
Parameter 4 here you are specifying update type by which database table is updated.
S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.
A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).
Parameter 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:
1. Tcode: Transaction code
2. Dyname: Batch point module name
3. Dynumb: Batch input Dyn number
4. Msgtyp: Batch input message type (A/E/W/I/S)
5. Msgspra: Batch input Lang, id of message
6. Msgid: Message id
7. MsgvN: Message variables (N = 1 - 4)
For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).
Steps for CALL TRANSACTION method
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)
4. Loop at itab.
Populate BDCTAB table.
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>.
Refresh BDCTAB.
Endloop.
(To populate BDCTAB, You need to transfer each and every field)
The major differences between Session method and Call transaction are as follows:
SESSION METHOD CALL TRANSACTION
1. Data is not updated in database table unless Session is processed. Immediate updation in database table.
2. No sy-subrc is returned. Sy-subrc is returned.
3. Error log is created for error records. Errors need to be handled explicitly
4. Updation in database table is always synchronous Updation in database table can be synchronous Or Asynchronous.
Error Handling in CALL TRANSACTION
When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:
Steps for the error handling in CALL TRANSACTION
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL
4. Internal table similar to Ist internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction <tr.code> using <Bdctab>
Mode <A/N/E>
Update <S/A>
Messages <BDCMSG>.
Perform check.
Refresh BDCTAB.
Endloop.
7 Form check.
IF sy-subrc <> 0. (Call transaction returns the sy-subrc if updating is not successful).
Call function Format_message.
(This function is called to store the message given by system and to display it along with record)
Append itab2.
Display the record and message.
DIRECT INPUT
About Direct Input
In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly.
You can start a Direct Input program in two ways;
Start the program directly
This is the quickest way to see if the program works with your flat file. This option is possible with all direct input programs. If the program ends abnormally, you will not have any logs telling you what has or has not been posted. To minimize the chance of this happening, always use the check file option for the first run with your flat file. This allows you to detect format errors before transfer.
Starting the program via the DI administration transaction
This transaction restarts the processing, if the data transfer program aborts. Since DI document are immediately posted into the SAP D/B, the restart option prevents the duplicate document posting that occurs during a program restart (i.e., without adjusting your flat file).
Direct input is usually done for standard data like material master, FI accounting document, SD sales order and Classification for which SAP has provided standard programs.
First time you work with the Direct Input administration program, you will need to do some preparation before you can transfer data:
- Create variant
- Define job
- Start job
- Restart job
Common batch input errors
- The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen.
- The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.
- On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this.
- The BDCDATA structure contains fields, which are longer than the actual definition.
- Authorization problems.
RECORDING A BATCH INPUT
A B recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format.
You can either use SHDB transaction for recording or
SYSTEM ? SERVICES ? BATCH INPUT ? EDIT
And from here click recording.
Enter name for the recording.
(Dates are optional)
Click recording.
Enter transaction code.
Enter.
Click Save button.
You finally come to a screen where, you have all the information for each screen including BDC_OKCODE.
Click Get Transaction.
Return to BI.
Click overview.
Position the cursor on the just recorded entry and click generate program.
Enter program name.
Click enter
The program is generated for the particular transaction.
BACKGROUND PROCESSING
Need for Background processing
When a large volume of data is involved, usually all batch inputs are done in background.
The R/3 system includes functions that allow users to work non-interactively or offline. The background processing systems handle these functions.
Non-interactively means that instead of executing the ABAP/4 programs and waiting for an answer, user can submit those programs for execution at a more convenient planned time.
There are several reasons to submit programs for background execution.
The maximum time allowed for online execution should not exceed 300 seconds. User gets TIMEOUT error and an aborted transaction, if time for execution exceeds 300 seconds. To avoid these types of error, you can submit jobs for background processing.
You can use the system while your program is executing.
This does not mean that interactive or online work is not useful. Both type of processing have their own purposes. Online work is the most common one entering business data, displaying information, printing small reports, managing the system and so on. Background jobs are mainly used for the following tasks; to process large amount of data, to execute periodic jobs without human intervention, to run program at a more convenient, planned time other than during normal working hours i.e., Nights or weekends.
The transaction for background processing is SM36.
Or
Tools ? Administration ? Jobs ? Define jobs
Or
System ? services ? Jobs
Components of the background jobs
A job in Background processing is a series of steps that can be scheduled and step is a program for background processing.
Job name. Define the name of assigned to the job. It identifies the job. You can specify up to 32 characters for the name.
Job class. Indicates the type of background processing priority assigned to the job.
The job class determines the priority of a job. The background system admits three types of job classes: A B & C, which correspond to job priority.
Job steps. Parameters to be passed for this screen are as follows:
Program name.
Variant if it is report program
Start criteria for the job: Option available for this are as follows:
Immediate - allows you to start a job immediately.
Date/Time - allows you to start a job at a specific name.
After job - you can start a job after a particular job.
After event - allows you to start a job after a particular event.
At operation mode - allows you to start a job when the system switches to a particular operation mode.
Defining Background jobs
It is two step process: Firstly, you define the job and then release it.
When users define a job and save it, they are actually scheduling the report i.e., specifying the job components, the steps, the start time.
When users schedule program for background processing, they are instructing the system to execute an ABAP/4 report or an external program in the background. Scheduled jobs are not executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time. Both scheduling and releasing of jobs require authorizations.
HANDLING OF POP UP SCREEN IN BDC
Many times in transaction pop up screen appears and for this screen you dont pass any record but some indication to system telling it to proceed further. For example: The following screen
To handle such screen, system has provided a variable called BDC_CURSOR. You pass this variable to BDCDATA and process the screen.
Usually such screen appears in many transactions, in this case you are just passing information, that YES you want to save the information, that means YES should be clicked. So you are transferring this information to BDCDATA i.e., field name of YES which is usually SPOT_OPTION. Instead of BDC_OKCODE, you are passing BDC_CURSOR.
BDC_CURSOR is also used to place cursor on particular field.
AN EXAMPLE WITH SESSION METHOD
Following program demonstrates how data is passed from flat file to SAP transaction and further to database table by using SESSION method.
The transaction is TFBA (to change customer).
A simple transaction where you are entering customer number on first screen and on next screen data is displayed for the particular customer number. Field, which we are changing here, are name and city. When you click on save, the changed record gets saved.
Prerequisite to write this BDC interface as indicated earlier is:
1. To find screen number
2. To find screen field names, type of the field and length of the field.
3. To find BDC_OKCODE for each screen
4. Create flat file.
Flat file can be created in your hard disk as follows:
1 Vinod Hyderabad
2 Kavitha Secunderabad
3 Kishore Hyderabad
(Where 1st character field is Customer number, 2nd field is Customer name and 3rd field is City.)
To transfer this data to database table SCUSTOM following interface can be used.
REPORT DEMO1.
Following internal table is to upload flat file.
DATA: BEGIN OF ITAB OCCURS 0,
ID(10),
NAME(25),
CITY(25),
END OF ITAB.
*Following internal table BDCDATA is to pass date from internal table to session.
DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE.
Variables
DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. This is for Hold Date
To upload flat file to internal table.
CALL FUNCTION UPLOAD
EXPORTING
FILE NAME = C:\FF.TXT
FILE TYPE = ASC
TABLES
DATA_TAB = ITAB
EXCEPTIONS
CONVERSION_ERROR = 1
INVALID_TABLE_WIDTH = 2
INVALID_TYPE = 3
NO_BATCH = 4
UNKNOWN_ERROR = 5
OTHERS = 6.
If sy-subrc = 0.
Calling Function to Create a Session
CALL FUNCTION BDC_OPEN_GROUP
EXPORTING
CLIENT = SY-MANDT
GROUP = POTHURI
HOLDDATE = DATE1
KEEP = X
USER = SY-UNAME
EXCEPTIONS
CLIENT_INVALID = 1
DESTINATION_INVALID = 2
GROUP_INVALID = 3
GROUP_IS_LOCKED = 4
HOLDDATE_INVALID = 5
INTERNAL_ERROR = 6
QUEUE_ERROR = 7
RUNNING = 8
SYSTEM_LOCK_ERROR = 9
USER_INVALID = 10
OTHERS = 11.
If sy-subrc = 0.
*-- MAIN Logic--
LOOP AT ITAB
PERFORM GENERATE_DATA. Populating BDCDATA Table
CALL FUNCTION BDC_INSERT
EXPORTING
TCODE = TFBA
TABLES
DYNPROTAB = BDCTAB
EXCEPTIONS
INTERNAL_ERROR = 1
NOT_OPEN = 2
QUEUE_ERROR = 3
TCODE_INVALID = 4
PRINTING_INVALID = 5
POSTING_INVALID = 6
OTHERS = 7.
REFRESH BDCTAB
ENDLOOP.
Calling function to close the session
CALL FUNCTION BDC_CLOSE_GROUP
EXCEPTIONS
NOT_OPEN = 1
QUEUE_ERROR = 2
OTHERS = 3.
Endif.
Endif.
*& Form GENERATE_DATA
Create BDC Data
FORM GENERATE_DATA
Passing information for 1st screen on BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAX-DYNPRO = 100.
BDCTAP-DYNBEGIN = X.
APPEND BCDTAB.CLEAR BDCTAB.
Passing field information to BDCDATA
BDCTAB-FNAM = SCUSTOM-ID
BDCTAB-FVAL = ITAB-ID.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = /5.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information for next screen to BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAB-DYNPRO = 200.
BDCTAB-DYNBEGIN = X.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-NAME.
BDCTAB-FVAL = ITAB-NAME.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-CITY.
BDCTAB-FVAL = ITAB-CITY.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = SAVE.
APPEND BDCTAB.CLEAR BDCTAB.
ENDFORM. GENERATE_DATA
AN EXAMPLE WITH CALL TRANSACTION
Same steps to be repeated for CALL TRANSACTION
The only difference between the two types of interface is in Session method, you create session and store information about screen and data into session. When session is processed the data is transferred to database. While in CALL TRANSACTION, data is transferred directly to database table.
REPORT DEMO1.
Follow above Code till MAIN Logic. Even the Subroutine should be copied
LOOP AT ITAB
PERFORM GENERATE_DATA, Populating BDCDATA Table
Call transaction TFBA using BCDDATA Mode A Update S.
REFRESH BDCTAB
ENDLOOP. -
DEFERRED TRANSACTION QUEUE의 내용을 지우는 여러가지 방법 (replication)
제품 : ORACLE SERVER
작성날짜 : 2004-08-13
PURPOSE
advanced replication 환경에서, 특정 master site나 updatable snapshot
site은 다른 remote의 master site로 데이타를 propagation시키기 위해서
해당 local site에 deferred transaction queue를 유지한다.
remote site로 잘 전달된 데이타는 주기적으로 dbms_defer_sys.purge job에
의해 deferred transaction queue인 DEFCALL에서 지워지게 되는데, 경우에
따라 문제가 발생하면서 DEFCALL의 내용이 remote site로 전달이 안되면서
계속해서 지워지지 않고 남게 될 수 있다.
이러한 경우 다음 트랜잭션의 진행이나 전달에도 방해가 될 수 있어
강제로 지우고자 하는 상황이 발생하는데 그러한 경우의 조치 방법에 대해서
자세히 설명한다.
SCOPE
Advanced Replication Feature는 8~10g Standard Edition에서는 지원하지
않는다.
Explanation
1. 특정 deferred transaction id를 지우는 경우
기본적으로 deferred transaction queue에 쌓인 트랜잭션을 지우는
방법은 다음과 같다.
dbms_defer_sys.delete_tran(deferred_tran_id, destination)
즉 다음 예와 같다.
SQL>exec dbms_defer_sys.delete_tran('2.7.10', 'rep2.world');
이때, 해당 destination에 대한 모든 트랜잭션인경우는 앞의 argument를
null로 하고, 특정 transaction id에 대한 모든 destination에 대해서인
경우는 뒷부분의 argument를 null로 한다.
결국 저장된 모든 deferred transaction이라면, 다음과 같다.
SQL>exec dbms_defer_sys.delete_tran(null,null);
2. 특정 table에 관한 내용만 지우는 경우
예를 들어 특정 table, 여기서는 DEPT table에 관한 사항을 DEFCALL에서
지우고자 한다면 다음과 같이 조치하면 된다.
SQL>connect repadmin/repadmin
SQL>set pagesize 1000
SQL>set head off
SQL>spool purgedefcall.sql
SQL>select 'exec dbms_defer_sys.delete_tran('''
|| deferred_tran_id || ''', null);'
from defcall
where packagename like 'DEPT%';
SQL>spool off
spool에 의해 만들어진 purgedefcall.sql을 깨끗하게 편집한 후 다시 save한다.
SQL>connect repadmin/repadmin
SQL>@purgedefcall.sql
이때 만약 특정 site로의 전달만을 막고자 한다면, null대신 MS_B.WORLD와 같이
해당 site를 가리키는 database link이름을 직접 지정하면 된다.
3. 전체 queue의 내용을 모두 지우는 경우
DEFCALL의 내용을 모두 지우는 경우라면 기본적으로는 앞에서 사용한
DBMS_DEFER_SYS.DELETE_TRAN을 이용하면 된다.
SQL>connect repadmin/repadmin
SQL>exec dbms_defer_sys.delete_tran(null,null);
DEFERROR의 내용을 모두 지우는 경우에는 DBMS_DEFER_SYS.DELETE_ERROR를
사용한다.
SQL>exec dbms_defer_sys.delete_error(null,null);
그런데 이 delete_tran과 delete_error의 경우는 내부적으로 delete문장을
사용하면서 undo record를 위해 rollback을 사용하면서 지워야 하는 데이타가
매우 많은 경우 속도도 문제가 되고 rollback space오류도 발생 가능하다.
이러한 경우에는 다음과 같이 truncate command를 이용하여 간단하고 빠르게
deferred transaction queue의 내용을 정리할 수 있다.
(1) Oracle7의 경우
DEF$_CALL, DEF$_CALLDEST, DEF$_ERROR 를 모두 truncate시킨다.
단 이때 DEF$_CALLDEST가 DEF$_CALL을 reference하는 constraint가 있는 관계로,
DEF$_CALLDEST를 모두 truncate하여 데이타가 전혀 없는 상태에서도,
DEF$_CALL이 truncate가 되지 않는다.
delete operation의 경우 child table이 비어 있다면 master table의 데이타를
지우는데 오류가 없지만, truncate의 경우는 데이타 확인 없이 바로 지우는
것이기 때문에 child table에 데이타가 없다하더라도 그러한 check없이,
무조건 자신을 reference하는 child table의 constraint가 enable되어 있는한은
master table이 truncate가 불가능하게 된다.
SQL>connect as system/password
SQL>alter table system.DEF$_CALLDEST disable constraint
DEF$_CALLDEST_CALL;
SQL>truncate table system.DEF$_CALL;
SQL>truncate table system.DEF$_CALLDEST;
SQL>truncate table system.DEF$_ERROR;
SQL>alter table system.DEF$_CALLDEST enable constraint DEF$_CALLDEST_CALL;
(2) Oracle8의 경우
Oracle8에서는 DEF$_CALLDEST가 더이상 DEF$_CALLDEST_CALL constraint를
가지지 않으므로 이 부분에 대한 고려는 필요없이 다음과 같이 해당 table들을
truncate시키면 된다.
SQL>truncate table system.DEF$_AQCALL;
SQL>truncate table system.DEF$_CALLDEST;
SQL>truncate table system.DEF$_ERROR;
SQL>truncate table system.DEF$_AQERROR;
4. deferror의 내용을 지우는 방법
deferred transaction이 remote로 전달되어 반영되다가 오류가 발생하면
source가 되는 데이타베이스의 queue에서는 해당 내용이 사라지고,
반영되던 destination 데이타베이스의 deferror와 defcall/deftran에
해당 내용이 쌓이게 된다.
이러한 경우 error의 내용을 다시 반영을 시도하거나 아니면 내용을
확인 후 지우게 된다.
다음과 같이 지우면 된다.
SQL>exec dbms_defer_sys.delete_error(null,null);
참고로 다시 수행하는 것은
SQL>exec dbms_defer_sys.execute_error(null,null);
Reference Documents
<Note:190885.1> How to Clear Down the Deferred Queue and DBMS_DEFER_SYS.
DELETE_TRAN -
What is the use of 'keep' parameter in BDC
Hi
In BDC while transfering data, what is the use of 'keep' parameter in BDC.Hi Jyothsna,
In the function module <b>BDC_OPEN_GROUP</b>, the <i>EXPORTING</i> parameter<i><b> KEEP</b></i> acts as a <b>deletion indicator for session</b> in which the batch data executed.
<i><b>CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
CLIENT = SY-MANDT
DEST = FILLER8
GROUP = FILLER12
HOLDDATE = FILLER8
KEEP = FILLER1
---</b></i>
<i><b>KEEP</b></i> retains the session after successful processing if its value is set to <i><b>'X'</b></i>. A session that is kept remains in the input/output queue until an administrator deletes it in <i><b>SM35</b></i> transaction.
Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted. Only the batch input log is kept in SM35 transaction.
Hope this sort out your query.
PS If the answer solves your query, plz close the thread by rewarding points to each reply.
Regards -
BDC Data transfer - Session method...?
Dear All,
How to Transfer data using BDC Session method? - Step-by-step Process.
Regards,
Dharmeshhi,
this will be usefull to u
2.1. Steps for submitting data for Batch Processing
1. Analyze the transactions for which a BDC program.
The user has to determine the sequence of screens in the transactions and the information about all the fields in every screen. To do this the user must run the transaction .
Then select System  Status. This will give the screen number and the module pool associated with this screen of the transaction. These two are the most important fields that the user would need in order to write the BDC program.
2. Use transaction SE38 to write the BDC program. This ABAP/4 program should reads the external data that is to be entered in the SAP System and stores the data in a "batch-input session." A session stores the actions that are required to enter data using normal SAP transactions. This is done by basically using three functions:
BDC_OPEN_GROUP
BDC_INSERT
BDC_CLOSE_GROUP.
3. To create a batch input session, use the function BDC_OPEN_GROUP. This function has the following 5 parameters :
a. CLIENT which is by default set to SY_MANDT. It is the client in which the session is to be processed.
b. GROUP which is the name of the BDC session. This parameter is important because it is with this name that the user will recognize the BDC session in the batch input queue. Using this name process the BDC session.
c. USER which is usually set to SY-UNAME. It is the user name for starting the session in background.
d. KEEP indicates whether the session should be kept or deleted after processing. If then the session is deleted. If X then the session is retained even after it is successfully processed without any errors.
e. HOLDDATE Lock date. The session is locked and may not be processed until after the date that is specified. Default: No lock date, session can be processed immediately. A lock date is optional.
4. Populate the bdcdata table .
The user may define the table as follows:
DATA: BEGIN OF BDCDATA OCCURS 0.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDCDATA.
This bdcdata structure has the following fields:
PROGRAM
Name of the program.
DYNPRO
Number of the screen. Set this field only in the first record for the screen.
DYNBEGIN
Indicates the first record for the screen. Set this field to X only in the first record for the screen. (Reset to ' ' (blank) for all other records.)
FNAM
Name of a field in the screen. The FNAM field is not case-sensitive.
FVAL
Value for the field named in FNAM.
5. The next step is to submit the BDC session. Use the BDC_INSERT function module to add a transaction to a batch input session. Specify the transaction that is to be started in the call to BDC_INSERT.
BDC_INSERT takes the following parameters:
TCODE
The code of the transaction that is to be run. TCODE is an EXPORTING parameter in the function module.
DYNPROTAB
The BDCDATA structure that contains the data that is to be processed by the transaction. DYNPROTAB is a tables parameter in the function module.
6. The final step is to close the BDC session. Use the BDC_CLOSE_GROUP function module to close a session. Once a session is closed, it can be processed.
7. Running this program will create a batch input session by the name that is specified in the GROUP parameter in the BDC_CREATE_GROUP function call.
8. Transaction SM35 can be used to process the submitted session. This transaction can be used to check the status of all BDC sessions.
2.2. Summary: Creating Batch Input Session:
Open Batch Input group
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
CLIENT = SY-MANDT
GROUP = GROUP
USER = USER
KEEP = KEEP.
Fill in the Data for Transaction in an internal table 'BDCDATA'
FORM INSERT_SCREEN USING PROGRAM DYNPRO.
CLEAR BDCDATA.
BDCDATA-PROGRAM = PROGRAM.
BDCDATA-DYNPRO = DYNPRO.
BDCDATA-DYNBEGIN = 'X'.
APPEND BDCDATA.
ENDFORM.
FORM INSERT_FIELD USING FNAM FVAL.
CLEAR BDCDATA.
BDCDATA-FNAM = FNAM.
BDCDATA-FVAL = FVAL.
APPEND BDCDATA.
ENDFORM.
Insert Transacton
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TCODE = 'ME21'
TABLES
DYNPROTAB = BDCDATA.
Close Batch Input group
CALL FUNCTION 'BDC_CLOSE_GROUP'.
Finally to process Batch Input Session, first execute the BDC ABAP. This will create
a BDC session. Run transaction 'SM35' & processes the BDC session.
regards,
padma. -
Hi! Kindly check the codes why is it that performance is very very slow. Hope you can give me some advice on how i can improve the performance this program.
REPORT zheg_hrpae001_mass_execution .
TABLES: pernr, "Use Table PERNR to Retrieve the personnel
bdcdata. "BDC Table
INFOTYPES DECLARATION *
In this section you can declare all infotypes that you are going to *
use in your program. *
INFOTYPES: 0000, "Actions
0315. "Time Sheet Default
TYPES/TYPE POOL DECLARATION *
In this section you can declare all types and type pools that you *
are going to use in your program. *
TYPES: BEGIN OF t_errorall,
msgid LIKE bdcmsgcoll-msgid,
msgnr LIKE bdcmsgcoll-msgnr,
msgv1 LIKE bdcmsgcoll-msgv1,
fldname LIKE bdcmsgcoll-fldname,
recno(50),
END OF t_errorall.
DATA/VARIABLE DECLARATION *
In this section you can define internal tables,variables and etc. *
DATA: i_errorall TYPE t_errorall OCCURS 0 WITH HEADER LINE,
w_errorall TYPE t_errorall,
v_recordname(50).
DATA: i_bdcdata LIKE bdcdata OCCURS 0 WITH HEADER LINE.
DATA: i_error2 TYPE bdcmsgcoll OCCURS 0,
w_error2 TYPE bdcmsgcoll.
DATA: v_begda TYPE dats, "Beginning date
v_date1(10) TYPE c, "Converted Begin date
v_read TYPE i, "Counter for identifying total records
v_process TYPE i, "Counter for identifying no error record
v_error TYPE i. "Counter for identifying total errors
CONSTANTS DECLARATION *
Constants are named data objects that you create statically using *
a declarative statement. They allow you to store data under a *
particular name within the memory area of a program. *
The value of a constant cannot be changed during the execution of *
the program. *
CONSTANTS: c_a(1) TYPE c VALUE 'A', "A Value
c_n(1) TYPE c VALUE 'N', "Background
c_date(4) TYPE c VALUE 'DYMD', "Date format
c_msgtyp(1) TYPE c VALUE 'E', "MSgtype E
c_endda TYPE dats VALUE '99991231', "End Date
***Start of Modification SIR-16196 by FEDERISOV 03/11/2005
c_active LIKE p0000-stat2 VALUE '3', "Active Employees
c_inactve LIKE p0000-stat2 VALUE '1', "Inactive Employees
***End of Modification by FEDERISOV 03/11/2005
c_x TYPE c VALUE 'X', "X Indicator
c_zero TYPE n VALUE '0'. "Zero value
TYPES: BEGIN OF t_0315,
pernr LIKE p0315-pernr,
endda LIKE p0000-endda,
stat2 LIKE p0000-stat2,
END OF t_0315.
DATA: i_0315 TYPE STANDARD TABLE OF t_0315,
w_0315 TYPE t_0315.
START-OF-SELECTION *
This event occurs after the selection screen has been processed and*
before data is read using the logical database. *
START-OF-SELECTION.
GET pernr.
PROVIDE pernr FROM p0315
endda stat2 FROM p0000 BETWEEN pn-begda AND pn-endda
WHERE p0000-endda = c_endda
AND ( p0000-stat2 = c_active
**Start of Modification SIR-16196 by FEDERISOV 03/11/2005
OR p0000-stat2 = c_inactve ).
**End of Modification by FEDERISOV 03/11/2005
PROVIDE pernr endda FROM p0315 BETWEEN pn-begda AND pn-endda
WHERE p0315-endda = c_endda.
AND ( p0000-stat2 = c_active
***Start of Modification SIR-16196 by FEDERISOV 03/11/2005
OR p0000-stat2 = c_inactve ).
CHECK p0000-stat2 eq c_active or p0000-stat2 eq c_inactve.
IF p0000-endda = c_endda
and ( p0000-stat2 = c_active or p0000-stat2 = c_inactve ) *
IF p0315_valid = 'X'.
and p0315-pernr = p0000-pernr.
PERFORM f_determine_date. "Determine the effective date
PERFORM f_convert_date. "Convert the effective date
PERFORM f_upload. "This will update the infotype 0315
w_0315-pernr = p0315-pernr.
APPEND w_0315 TO i_0315.
CLEAR w_0315.
ENDIF.
ENDPROVIDE.
END OF PROCESSING *
End of program processing. *
END-OF-SELECTION.
LOOP AT i_0315 INTO w_0315.
PERFORM f_determine_date. "Determine the effective date
PERFORM f_convert_date. "Convert the effective date
PERFORM f_upload. "This will update the infotype 0315
ENDLOOP.
PERFORM f_report. "Print / Audit Report
FORM f_determine_date.
Use to supply the effective date supplied in the selection screen
FORM f_determine_date.
IF pnptimr1 = c_x.
v_date1 = sy-datum.
ELSEIF pnptimr6 = c_x.
v_date1 = pnpbegda.
ENDIF.
ENDFORM.
FORM f_convert_date.
Use to covert the date in the standard format
FORM f_convert_date.
CALL FUNCTION '/SAPDMC/LSM_DATE_CONVERT'
EXPORTING
date_in = v_date1 "Date In
date_format_in = c_date
to_output_format = c_x
IMPORTING
date_out = v_date1 "Converted Date
EXCEPTIONS
illegal_date = 1
illegal_date_format = 2
no_user_date_format = 3
OTHERS = 4.
IF sy-subrc <> 0.
ENDIF.
ENDFORM.
FORM f_upload.
This will update the existing record in infotype 0315
FORM f_upload.
CLEAR i_bdcdata.
REFRESH i_bdcdata.
PERFORM f_dynpro:
USING 'X' 'SAPMP50A' '1000',
USING ' ' 'BDC_CURSOR' 'RP50G-PERNR',
USING ' ' 'RP50G-PERNR' w_0315-pernr,
USING ' ' 'BDC_CURSOR' 'RP50G-CHOIC',
USING ' ' 'RP50G-CHOIC' '0315',
USING ' ' 'RP50G-TIMR6' 'X',
USING ' ' 'BDC_OKCODE' '/00'.
PERFORM f_dynpro:
USING 'X' 'SAPMP50A' '1000',
USING ' ' 'BDC_CURSOR' 'RP50G-PERNR',
USING ' ' 'RP50G-PERNR' w_0315-pernr,
USING ' ' 'BDC_CURSOR' 'RP50G-CHOIC',
USING ' ' 'RP50G-CHOIC' 'Time Sheet Defaults',
USING ' ' 'RP50G-TIMR6' 'X',
USING ' ' 'BDC_OKCODE' '=INS'.
PERFORM f_dynpro:
USING 'X' 'MP031500' '2000',
USING ' ' 'BDC_CURSOR' p0315-begda,
USING ' ' 'P0315-BEGDA' v_date1,
USING ' ' 'P0315-KOSTL' p0315-kostl,
USING ' ' 'BDC_SUBSCR' 'ZP031500',
USING ' ' 'BDC_OKCODE' '=UPD'.
*Runs transaction on background
CALL TRANSACTION 'PA30' USING i_bdcdata
MODE c_n UPDATE c_a
MESSAGES INTO i_error2.
IF sy-subrc <> 0.
PERFORM f_bdc_error.
ADD 1 TO v_error.
ELSE.
ADD 1 TO v_process.
ENDIF.
ENDFORM.
Form f_dynpro
Subroutine used to populate the BDC table.
FORM f_dynpro USING fp_dynbegin
fp_name
fp_value.
IF fp_dynbegin EQ 'X'.
CLEAR bdcdata.
bdcdata-program = fp_name.
bdcdata-dynpro = fp_value.
bdcdata-dynbegin = fp_dynbegin.
APPEND bdcdata TO i_bdcdata.
ELSE.
CLEAR bdcdata.
bdcdata-fnam = fp_name.
bdcdata-fval = fp_value.
APPEND bdcdata TO i_bdcdata.
ENDIF.
ENDFORM. " F_DYNPRO
Form f_bdc_error
Check BDC Error when processing
FORM f_bdc_error.
CLEAR w_error2.
READ TABLE i_error2 INTO w_error2 WITH KEY msgtyp = c_msgtyp.
IF sy-subrc EQ 0.
MOVE: w_error2-msgnr TO w_errorall-msgnr.
w_error2-msgv1 TO w_errorall-msgv1,
w_error2-fldname TO w_errorall-fldname.
*Capture errors in BDC background processing
CALL FUNCTION 'MESSAGE_TEXT_BUILD'
EXPORTING
msgid = w_error2-msgid
msgnr = w_error2-msgnr
msgv1 = w_error2-msgv1
msgv2 = w_error2-msgv2
msgv3 = w_error2-msgv3
msgv4 = w_error2-msgv4
IMPORTING
message_text_output = w_errorall-fldname.
CLEAR v_recordname.
CONCATENATE text-001
w_0315-pernr
INTO v_recordname SEPARATED BY space.
MOVE: v_recordname TO w_errorall-recno.
APPEND w_errorall TO i_errorall.
CLEAR i_errorall.
ENDIF.
ENDFORM. " f_bdc_error
Form F_OREPORT
Writes the summary report of the program that will provide the
number of records process, number errors and the location of errors
in the BDC.
FORM f_report.
v_read = v_process + v_error.
*Output Report
WRITE: text-006.
ULINE.
WRITE:/ ,
/5 text-007,
36 v_read,
/5 text-008,
36 v_process,
/5 text-009,
36 v_error.
NEW-PAGE.
WRITE: /5 text-003,
20 text-010,
60 text-004.
ULINE.
CLEAR w_errorall.
LOOP AT i_errorall INTO w_errorall.
WRITE: /5 w_errorall-msgnr,
20 w_errorall-fldname,
60 w_errorall-recno.
CLEAR w_errorall.
ENDLOOP.
ENDFORM.Hi,
Maybe instead of using call transaction you could insert the transactions onto the SM35 BDC queue. You could then batch the transactions (into groups of 10 for example) and submit RSBDCSUB for each batch. This would means that you process the BDCs in parrallel rather than the sequential approach you have now.
It could go something like:
FORM F_UPLOAD
IF w_session_open IS INITIAL.
CALL FUNCTION 'BDC_OPEN'.
CLEAR: w_record_number.
w_session_open = 'X'.
ENDIF.
<insert BDC logic here>.
CALL FUNCTION 'BDC_INSERT'.
w_record_number = w_record_number + 1.
IF w_record_number >= 10.
CALL FUNCTION 'BDC_CLOSE'.
SUBMIT RSBDCSUB (passing unique BDC session name) AND RETURN.
CLEAR: w_session_open
ENDIF.
ENDFORM.
As RSBDCSUB creates a background job to process the BDC session, your program would continue whilst the BDC session was being processed.
As the sessions are being handled in SM35 you would also get a much nicer record of the errors, and it would allow you to replay them and correct interactively (rather than just having an error report).
Of course, this is just a quick sketch of a possible solution, but you could adapt the technique to suit the specifics of your implementation.
Hope that helps.
Cheers,
Brad -
Hi SAP Gurus,
A program creates 4000 sessions with similar name like 'SESSION_NAME' each having 200 records.This BDC updates same Transaction.
I have a another program with parameter as Session name. With this session name i will get all the QUEUE ID's of 4000 sessions and using this ID i submit RSBDCBTC.
Now the problem is that all the sessions run at the same time .
The consequence was that all session ran on errors because they lock each other.
I have used WAIT UPTO 2 SESONDS..But this doesn't work.
Please suggest how to overcome this problem.
Thanks in Advance.
Regards,
Dinakaran.RHi Dinakaran
use:
SUBMIT rsbdcsub
WITH mappe EQ 'MIG_LISTING' " Session Name
WITH von EQ sy-datum " Starting Interval date
WITH bis EQ sy-datum " Closing Interval Date
WITH z_verarb EQ 'X'
WITH logall EQ 'X' " Log Info
AND RETURN .
here even though session name is same by mentioning the Starting Interval Date and Closing Interval date, we can process the 2 created pool sessions successfully.
Feel free to ask any queries regarding this.
Regards,
Kumar -
i wanna know the concept of BDC with simple examples... also CA
BATCH DATA COMMUNICATION
About Data Transfer In R/3 System
When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes into replace or complement existing application.
In the process of replacing current applications and transferring application data, two situations might occur:
The first is when application data to be replaced is transferred at once, and only once.
The second situation is to transfer data periodically from external systems to SAP and vice versa.
There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive.
The SAP system offers two primary methods for transferring data into SAP systems. From non-SAP systems or legacy system. These two methods are collectively called batch input or batch data communication.
1. SESSION METHOD
2. CALL TRANSACTION
3. DIRECT INPUT
Advantages offered by BATCH INPUT method:
1. Can process large data volumes in batch.
2. Can be planned and submitted in the background.
3. No manual interaction is required when data is transferred.
4. Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.
To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP system. This program, known as a data transfer program must map the data from the external system into the data structure required by the SAP batch input program.
The batch input program must build all of the input to execute the SAP transaction.
Two main steps are required:
To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.
To pass the table to SAP for processing.
Prerequisite for Data Transfer Program
Writing a Data Transfer Program involves following prerequisites:
Analyzing data from local file
Analyzing transaction
Analyzing transaction involves following steps:
The transaction code, if you do not already know it.
Which fields require input i.e., mandatory.
Which fields can you allow to default to standard values.
The names, types, and lengths of the fields that are used by a transaction.
Screen number and Name of module pool program behind a particular transaction.
To analyze a transaction::
Start the transaction by menu or by entering the transaction code in the command box.
(You can determine the transaction name by choosing System Status.)
Step through the transaction, entering the data will be required for processing your batch input data.
On each screen, note the program name and screen (dynpro) number.
(dynpro = dyn + pro. Dyn = screen, pro = number)
Display these by choosing System Status. The relevant fields are Program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen.
The technical info pop-up shows not only the field information but also the program and screen.
For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical Info.
Note the following information:
- The field name for batch input, which youll find in its own box.
- The length and data type of the field. You can display this information by double clicking on the Data Element field.
Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen).
Place the cursor on the button or menu entry while holding down the left mouse button. Then press F1.
In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.
You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.
Once you have program name, screen number, field name (screen field name), you can start writing.
DATA TRANSFER program.
Declaring internal table
First Integral Table similar to structure like local file.
Declaring internal table like BDCDATA
The data from internal table is not transferred directly to database table, it has to go through transaction. You need to pass data to particular screen and to particular screen-field. Data is passed to transaction in particular format, hence there is a need for batch input structure.
The batch input structure stores the data that is to be entered into SAP system and the actions that are necessary to process the data. The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION.
This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is as follows:
Create a BDCDATA structure
Write the structure out to a session or process it with CALL TRANSACTION USING; and then
Create a BDCDATA structure for the next transaction that is to be processed.
Within a BDCDATA structure, organize the data of screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.
The screen identifier record is followed by a separate BDCDATA record for each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:
Data that is entered into screen fields.
Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.
The BDCDATA structure contains the following fields:
PROGRAM: Name of module pool program associated with the screen. Set this field only for the first record for the screen.
DYNPRO: Screen Number. Set this field only in the first record for the screen.
DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to (blank) for all other records.)
FNAM: Field Name. The FNAM field is not case-sensitive.
FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format.
Transferring data from local file to internal table
Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.
Population of BDCDATA
For each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure.
All these five initial steps are necessary for any type of BDC interface.
DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same.
First step for both the methods is to upload the data to internal table. From Internal Table, the data is transferred to database table by two ways i.e., Session method and Call transaction.
SESSION METHOD
About Session method
In this method you transfer data from internal table to database table through sessions.
In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.
When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system.
Unless session is processed, the data is not transferred to database table.
BDC_OPEN_GROUP
You create the session through program by BDC_OPEN_GROUP function.
Parameters to this function are:
User Name: User name
Group: Name of the session
Lock Date: The date on which you want to process the session.
Keep: This parameter is passed as X when you want to retain session after
processing it or to delete it after processing.
BDC_INSERT
This function creates the session & data is transferred to Session.
Parameters to this function are:
Tcode: Transaction Name
Dynprotab: BDC Data
BDC_CLOSE_GROUP
This function closes the BDC Group. No Parameters.
Some additional information for session processing
When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not.
However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.
CALL TRANSACTION
About CALL TRANSACTION
A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>
Messages into <MSGTAB>.
Parameter 1 is transaction code.
Parameter 2 is name of BDCTAB table.
Parameter 3 here you are specifying mode in which you execute transaction
A is all screen mode. All the screen of transaction are displayed.
N is no screen mode. No screen is displayed when you execute the transaction.
E is error screen. Only those screens are displayed wherein you have error record.
Parameter 4 here you are specifying update type by which database table is updated.
S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.
A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).
Parameter 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:
1. Tcode: Transaction code
2. Dyname: Batch point module name
3. Dynumb: Batch input Dyn number
4. Msgtyp: Batch input message type (A/E/W/I/S)
5. Msgspra: Batch input Lang, id of message
6. Msgid: Message id
7. MsgvN: Message variables (N = 1 - 4)
For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).
Steps for CALL TRANSACTION method
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)
4. Loop at itab.
Populate BDCTAB table.
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>.
Refresh BDCTAB.
Endloop.
(To populate BDCTAB, You need to transfer each and every field)
The major differences between Session method and Call transaction are as follows:
SESSION METHOD CALL TRANSACTION
1. Data is not updated in database table unless Session is processed. Immediate updation in database table.
2. No sy-subrc is returned. Sy-subrc is returned.
3. Error log is created for error records. Errors need to be handled explicitly
4. Updation in database table is always synchronous Updation in database table can be synchronous Or Asynchronous.
Error Handling in CALL TRANSACTION
When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:
Steps for the error handling in CALL TRANSACTION
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL
4. Internal table similar to Ist internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction <tr.code> using <Bdctab>
Mode <A/N/E>
Update <S/A>
Messages <BDCMSG>.
Perform check.
Refresh BDCTAB.
Endloop.
7 Form check.
IF sy-subrc <> 0. (Call transaction returns the sy-subrc if updating is not successful).
Call function Format_message.
(This function is called to store the message given by system and to display it along with record)
Append itab2.
Display the record and message.
DIRECT INPUT
About Direct Input
In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly.
You can start a Direct Input program in two ways;
Start the program directly
This is the quickest way to see if the program works with your flat file. This option is possible with all direct input programs. If the program ends abnormally, you will not have any logs telling you what has or has not been posted. To minimize the chance of this happening, always use the check file option for the first run with your flat file. This allows you to detect format errors before transfer.
Starting the program via the DI administration transaction
This transaction restarts the processing, if the data transfer program aborts. Since DI document are immediately posted into the SAP D/B, the restart option prevents the duplicate document posting that occurs during a program restart (i.e., without adjusting your flat file).
Direct input is usually done for standard data like material master, FI accounting document, SD sales order and Classification for which SAP has provided standard programs.
First time you work with the Direct Input administration program, you will need to do some preparation before you can transfer data:
- Create variant
- Define job
- Start job
- Restart job
Common batch input errors
- The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen.
- The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.
- On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this.
- The BDCDATA structure contains fields, which are longer than the actual definition.
- Authorization problems.
RECORDING A BATCH INPUT
A B recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format.
You can either use SHDB transaction for recording or
EDIT BATCH INPUT  SERVICES SYSTEM
And from here click recording.
Enter name for the recording.
(Dates are optional)
Click recording.
Enter transaction code.
Enter.
Click Save button.
You finally come to a screen where, you have all the information for each screen including BDC_OKCODE.
Click Get Transaction.
Return to BI.
Click overview.
Position the cursor on the just recorded entry and click generate program.
Enter program name.
Click enter
The program is generated for the particular transaction.
BACKGROUND PROCESSING
Need for Background processing
When a large volume of data is involved, usually all batch inputs are done in background.
The R/3 system includes functions that allow users to work non-interactively or offline. The background processing systems handle these functions.
Non-interactively means that instead of executing the ABAP/4 programs and waiting for an answer, user can submit those programs for execution at a more convenient planned time.
There are several reasons to submit programs for background execution.
The maximum time allowed for online execution should not exceed 300 seconds. User gets TIMEOUT error and an aborted transaction, if time for execution exceeds 300 seconds. To avoid these types of error, you can submit jobs for background processing.
You can use the system while your program is executing.
This does not mean that interactive or online work is not useful. Both type of processing have their own purposes. Online work is the most common one entering business data, displaying information, printing small reports, managing the system and so on. Background jobs are mainly used for the following tasks; to process large amount of data, to execute periodic jobs without human intervention, to run program at a more convenient, planned time other than during normal working hours i.e., Nights or weekends.
The transaction for background processing is SM36.
Or
Define jobs Jobs  Administration Tools
Or
Jobs services System
Components of the background jobs
A job in Background processing is a series of steps that can be scheduled and step is a program for background processing.
Job name. Define the name of assigned to the job. It identifies the job. You can specify up to 32 characters for the name.
Job class. Indicates the type of background processing priority assigned to the job.
The job class determines the priority of a job. The background system admits three types of job classes: A B & C, which correspond to job priority.
Job steps. Parameters to be passed for this screen are as follows:
Program name.
Variant if it is report program
Start criteria for the job: Option available for this are as follows:
Immediate - allows you to start a job immediately.
Date/Time - allows you to start a job at a specific name.
After job - you can start a job after a particular job.
After event - allows you to start a job after a particular event.
At operation mode - allows you to start a job when the system switches to a particular operation mode.
Defining Background jobs
It is two step process: Firstly, you define the job and then release it.
When users define a job and save it, they are actually scheduling the report i.e., specifying the job components, the steps, the start time.
When users schedule program for background processing, they are instructing the system to execute an ABAP/4 report or an external program in the background. Scheduled jobs are not executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time. Both scheduling and releasing of jobs require authorizations.
HANDLING OF POP UP SCREEN IN BDC
Many times in transaction pop up screen appears and for this screen you dont pass any record but some indication to system telling it to proceed further. For example: The following screen
To handle such screen, system has provided a variable called BDC_CURSOR. You pass this variable to BDCDATA and process the screen.
Usually such screen appears in many transactions, in this case you are just passing information, that YES you want to save the information, that means YES should be clicked. So you are transferring this information to BDCDATA i.e., field name of YES which is usually SPOT_OPTION. Instead of BDC_OKCODE, you are passing BDC_CURSOR.
BDC_CURSOR is also used to place cursor on particular field.
AN EXAMPLE WITH SESSION METHOD
Following program demonstrates how data is passed from flat file to SAP transaction and further to database table by using SESSION method.
The transaction is TFBA (to change customer).
A simple transaction where you are entering customer number on first screen and on next screen data is displayed for the particular customer number. Field, which we are changing here, are name and city. When you click on save, the changed record gets saved.
Prerequisite to write this BDC interface as indicated earlier is:
1. To find screen number
2. To find screen field names, type of the field and length of the field.
3. To find BDC_OKCODE for each screen
4. Create flat file.
Flat file can be created in your hard disk as follows:
1 Vinod Krishna Hyderabad
2 Kavitha Secunderabad
3 Kishore Hyderabad
(Where 1st character field is Customer number, 2nd field is Customer name and 3rd field is City.)
To transfer this data to database table SCUSTOM following interface can be used.
REPORT DEMO1.
Following internal table is to upload flat file.
DATA: BEGIN OF ITAB OCCURS 0,
ID(10),
NAME(25),
CITY(25),
END OF ITAB.
*Following internal table BDCDATA is to pass date from internal table to session.
DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE.
Variables
DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. This is for Hold Date
To upload flat file to internal table.
CALL FUNCTION UPLOAD
EXPORTING
FILE NAME = C:FF.TXT
FILE TYPE = ASC
TABLES
DATA_TAB = ITAB
EXCEPTIONS
CONVERSION_ERROR = 1
INVALID_TABLE_WIDTH = 2
INVALID_TYPE = 3
NO_BATCH = 4
UNKNOWN_ERROR = 5
OTHERS = 6.
If sy-subrc = 0.
Calling Function to Create a Session
CALL FUNCTION BDC_OPEN_GROUP
EXPORTING
CLIENT = SY-MANDT
GROUP = POTHURI
HOLDDATE = DATE1
KEEP = X
USER = SY-UNAME
EXCEPTIONS
CLIENT_INVALID = 1
DESTINATION_INVALID = 2
GROUP_INVALID = 3
GROUP_IS_LOCKED = 4
HOLDDATE_INVALID = 5
INTERNAL_ERROR = 6
QUEUE_ERROR = 7
RUNNING = 8
SYSTEM_LOCK_ERROR = 9
USER_INVALID = 10
OTHERS = 11.
If sy-subrc = 0.
*-- MAIN Logic--
LOOP AT ITAB
PERFORM GENERATE_DATA. Populating BDCDATA Table
CALL FUNCTION BDC_INSERT
EXPORTING
TCODE = TFBA
TABLES
DYNPROTAB = BDCTAB
EXCEPTIONS
INTERNAL_ERROR = 1
NOT_OPEN = 2
QUEUE_ERROR = 3
TCODE_INVALID = 4
PRINTING_INVALID = 5
POSTING_INVALID = 6
OTHERS = 7.
REFRESH BDCTAB
ENDLOOP.
Calling function to close the session
CALL FUNCTION BDC_CLOSE_GROUP
EXCEPTIONS
NOT_OPEN = 1
QUEUE_ERROR = 2
OTHERS = 3.
Endif.
Endif.
*& Form GENERATE_DATA
Create BDC Data
FORM GENERATE_DATA
Passing information for 1st screen on BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAX-DYNPRO = 100.
BDCTAP-DYNBEGIN = X.
APPEND BCDTAB.CLEAR BDCTAB.
Passing field information to BDCDATA
BDCTAB-FNAM = SCUSTOM-ID
BDCTAB-FVAL = ITAB-ID.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = /5.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information for next screen to BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAB-DYNPRO = 200.
BDCTAB-DYNBEGIN = X.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-NAME.
BDCTAB-FVAL = ITAB-NAME.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-CITY.
BDCTAB-FVAL = ITAB-CITY.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = SAVE.
APPEND BDCTAB.CLEAR BDCTAB.
ENDFORM. GENERATE_DATA
AN EXAMPLE WITH CALL TRANSACTION
Same steps to be repeated for CALL TRANSACTION
The only difference between the two types of interface is in Session method, you create session and store information about screen and data into session. When session is processed the data is transferred to database. While in CALL TRANSACTION, data is transferred directly to database table.
REPORT DEMO1.
Follow above Code till MAIN Logic. Even the Subroutine should be copied
LOOP AT ITAB
PERFORM GENERATE_DATA, Populating BDCDATA Table
Call transaction TFBA using BCDDATA Mode A Update S.
REFRESH BDCTAB
ENDLOOP.
For BDC:
http://myweb.dal.ca/hchinni/sap/bdc_home.htm
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/bdc&
http://www.sap-img.com/abap/learning-bdc-programming.htm
http://www.sapdevelopment.co.uk/bdc/bdchome.htm
http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm
http://help.sap.com/saphelp_47x200/helpdata/en/69/c250684ba111d189750000e8322d00/frameset.htm
http://www.sapbrain.com/TUTORIALS/TECHNICAL/BDC_tutorial.html
Check these link:
http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm
http://www.sap-img.com/abap/question-about-bdc-program.htm
http://www.itcserver.com/blog/2006/06/30/batch-input-vs-call-transaction/
http://www.planetsap.com/bdc_main_page.htm
call Transaction or session method ?
http://www.sapbrain.com/FAQs/TECHNICAL/SAP_ABAP_DATADICTIONARY_FAQ.html
http://www.****************/InterviewQ/interviewQ.htm
http://help.sap.com/saphelp_46c/helpdata/en/35/2cd77bd7705394e10000009b387c12/frameset.htm
regards,
srinivas
<b>*reward for useful answers*</b> -
BDC issues in FB60 while posting through proxy
Hi All,
I have created a BDC for FB 60 & FB65. Now, the requirement is that Data will come from XI as inbound proxy and the code will get executed. XI sends a separate file for each record. That is if 10 documents are to be created from FB 60 , then XI will send 10 separate files at the same time to ECC. This particular design is creating the issue.
What happens is 10 files are getting executed at the same time in ECC and few records are getting created properly and few are failing. The error status shows that it is holding a wrong company code. Probably the reason for this failure is the company code that needs to be set everytime in FB60 or 65 . As we know these are two tcodes where once we set the Co. Code it holds the value for that logon . I have written the code in such a way that everytime the co. code will be reset but since all the files are getting executed right at the same moment, somehow there is some clash.
If I send the records as a single file from XI, it works out perfectly. But the need from Xi is to send them in separate files and at the same time.
Please suggest me is there any way to handle this issue.Hi
Try making your Inbound interface in XI as Synchronous so that you will receive files one by one. In case of any error return the reposne back to XI so that you know which records failed. This seems a good option for you.
Else You can also make your proxy behave EOIO. Refer below link. But error handling will be an issue. If any message fails youe queue will be stucked till somebody clears that one.
http://help.sap.com/saphelp_nw04/helpdata/en/65/40c9a4a1fa476288ac61b5fcc6bbde/frameset.htm
Regards
Vinit
Maybe you are looking for
-
Is this possible? DELETE LT_WIP1 WHERE ABS( Z_O_K0007 ) = ABS( Z_O_K0003
Hi, Is this statement possible because I can't get it to work? Am I just formatting it incorrectly? I'm trying to delete entries from internal table LT_WIP1. DELETE LT_WIP1 WHERE ABS( Z_O_K0007 ) <= ABS( Z_O_K0003 ). Thanks!
-
I have project I filmed on a Sony PD170 in 16:9, brought it into FCPHD and changes sequence to 16:9 looks fine for what I want. Now when I export it out for DVDSpro I use the "Export-Quicktime-DVPAL 48kHz anamorphic" setting when I look at the file i
-
Installing SAP ERP on DB2 with high availability
Hey Gurus, currently we're installing SAP ERP 6 EHP 6 based on DB2 for unix and windows, this is done using the high availability option on AIX 7.1 and IBM's power HA. We have the following architecture: Node A: 1-A host
-
REGEXP_INSTR on a multi line string
Hello , I am trying to search through a string that is stored with multi line and trying to find the first occurrence of a character. For example : The string is - "This is a sample text to test from [first string] to [second string] " When i try to
-
Opening 2 webapps on different browser session
Hi friends I have 2 webapplications deployed in weblogic. When I use CTRL-N and open a new window for the new browser and access the second application the session in my first application is lost. If I login to the first application and then come to