12 diciembre, 2015

Batch input XD02 (Bancos)

Posted in ABAP, Código de ejemplo a 3:40 am por sapyabap


FUNCTION zxd02.
*”———————————————————————-
*”*”Interfase local
*” IMPORTING
*” REFERENCE(WA_KNBK) LIKE ZXD02_S STRUCTURE ZXD02_S OPTIONAL
*”———————————————————————-

DATA: it_bdcdata LIKE TABLE OF bdcdata WITH HEADER LINE,
it_message LIKE TABLE OF bdcmsgcoll WITH HEADER LINE.
DATA: lv_mode TYPE c LENGTH 1 VALUE ‘N’,
lv_update TYPE c LENGTH 1 VALUE ‘S’.

PERFORM bdc_dynpro TABLES it_bdcdata USING ‘SAPMF02D’ ‘101’ ‘x’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_CURSOR’
‘RF02D-D0130’.

PERFORM bdc_field TABLES it_bdcdata USING ‘RF02D-KUNNR’
WA_KNBK-KUNNR.

PERFORM bdc_field TABLES it_bdcdata USING ‘RF02D-D0130’
‘X’.
PERFORM bdc_dynpro TABLES it_bdcdata USING ‘SAPMF02D’ ‘130’ ‘X’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_CURSOR’
‘IBAN(01)’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_OKCODE’
‘=IBAN’.

PERFORM bdc_field TABLES it_bdcdata USING ‘KNBK-BANKS(01)’
‘ES’.

PERFORM bdc_field TABLES it_bdcdata USING ‘KNBK-BANKL(01)’
wa_knbk-bankl.

PERFORM bdc_field TABLES it_bdcdata USING ‘KNBK-BANKN(01)’
wa_knbk-bankn.

PERFORM bdc_field TABLES it_bdcdata USING ‘KNBK-BKONT(01)’
wa_knbk-bkont.
PERFORM bdc_dynpro TABLES it_bdcdata USING ‘SAPLIBMA’ ‘100’ ‘X’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_CURSOR’
‘IBAN01’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_OKCODE’
‘=ENTR’.

* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN01’
* ‘ES79’.
* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN02’
* wa_knbk-bankl+0(4).
* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN03’
* wa_knbk-bankl+5(4).
* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN04’
* ‘6101’.
* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN05’
* ‘2345’.
* PERFORM bdc_field TABLES it_bdcdata USING ‘IBAN06’
* ‘6789’.

PERFORM bdc_dynpro TABLES it_bdcdata USING ‘SAPMF02D’ ‘130’ ‘X’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_CURSOR’
‘KNBK-BANKS(01)’.

PERFORM bdc_field TABLES it_bdcdata USING ‘BDC_OKCODE’
‘=UPDA’.

 

CALL TRANSACTION ‘XD02’ USING it_bdcdata
MODE lv_mode
UPDATE lv_update
MESSAGES INTO it_message.
ENDFUNCTION.
*&——————————————————————–*
*& Form BDC_DYNPRO
*&——————————————————————–*
* text
*———————————————————————*
* –>LT_BDCDATA text
* –>L_PROGRAM text
* –>L_DYNPRO text
* –>L_DBEGIN text
*———————————————————————*
FORM bdc_dynpro TABLES lt_bdcdata STRUCTURE bdcdata
USING l_program
l_dynpro
l_dbegin.
CLEAR lt_bdcdata.
lt_bdcdata-program = l_program.
lt_bdcdata-dynpro = l_dynpro.
lt_bdcdata-dynbegin = l_dbegin.
APPEND lt_bdcdata.

ENDFORM. “adc_dynpro
*&——————————————————————–*
*& Form BDC_FIELD
*&——————————————————————–*
* text
*———————————————————————*
* –>LT_BDCDATA text
* –>L_CAMPO text
* –>L_VALOR text
*———————————————————————*
FORM bdc_field TABLES lt_bdcdata STRUCTURE bdcdata
USING l_campo
l_valor.

CLEAR lt_bdcdata.
lt_bdcdata-fnam = l_campo.
lt_bdcdata-fval = l_valor.
APPEND lt_bdcdata.

 

A tener en cuenta al crear el batch input.

Processing batch input data with CALL TRANSACTION USING is the faster of the two recommended data transfer methods. In this method, legacy data is processed inline in your data transfer program.

For more information, see

choosing a data transfer method.

Syntax:

CALL TRANSACTION <tcode>

USING <bdc_tab>

MODE  <mode>

UPDATE  <update>

 

<tcode>

: Transaction code

<bdc_tab>

: Internal table of structure BDCDATA.

<mode>

: Display mode:

A Display all
E Display errors only
N No display

 

<update>

: Update mode:

S Synchronous
A Asynchronous
L Local update

 

A program that uses

CALL TRANSACTION USING to process legacy data should execute the following steps:

  1. Prepare a

BDCDATA structure for the transaction that you wish to run.

  1. With a CALL TRANSACTION USING statement, call the transaction and prepare the BDCDATA structure. For example:

CALL TRANSACTION ‘TFCA’ USING BDCDATA
MODE ‘A’
UPDATE ‘S’.
MESSAGES INTO MESSTAB.

IF SY-SUBRC <> 0.

<Error_handling>.

ENDIF.

The MODE Parameter

You can use the MODE parameter to specify whether data transfer processing should be displayed as it happens. You can choose between three modes:

A Display all. All screens and the data that goes in them appear when you run your program.

N No display. All screens are processed invisibly, regardless of whether there are errors or not. Control returns to your program as soon as transaction processing is finished.

E Display errors only. The transaction goes into display mode as soon as an error in one of the screens is detected. You can then correct the error.

The display modes are the same as those that are available for processing batch input sessions.

The UPDATE Parameter

You use the UPDATE parameter to specify how updates produced by a transaction should be processed. You can select between these modes:

A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.

If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.

S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.

L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on

SET UPDATE TASK LOCAL for more information.)

The MESSAGES Parameter

The

MESSAGES specification indicates that all system messages issued during a CALL TRANSACTION USING are written into the internal table <MESSTAB> . The internal table must have the structure BDCMSGCOLL .

Example

You can record the messages issued by Transaction TFCA in table

MESSTAB with the following coding:

(This example uses a flight connection that does not exist to trigger an error in the transaction.)

DATA: BEGIN OF BDCDATA OCCURS 100.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDCDATA.
DATA: BEGIN OF MESSTAB OCCURS 10.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF MESSTAB.
BDCDATA-PROGRAM = ‘SAPMTFCA’.
BDCDATA-DYNPRO = ‘0100’.
BDCDATA-DYNBEGIN = ‘X’.
APPEND BDCDATA.
CLEAR BDCDATA.
BDCDATA-FNAM = ‘SFLIGHT-CARRID’.
BDCDATA-FVAL = ‘XX’.
APPEND BDCDATA.
BDCDATA-FNAM = ‘SFLIGHT-CONNID’.
BDCDATA-FVAL = ‘0400’.
APPEND BDCDATA.
CALL TRANSACTION ‘TFCA’ USING BDCDATA MODE ‘N’
MESSAGES INTO MESSTAB.
LOOP AT MESSTAB.
WRITE: / MESSTAB-TCODE,
MESSTAB-DYNAME,
MESSTAB-DYNUMB,
MESSTAB-MSGTYP,
MESSTAB-MSGSPRA,
MESSTAB-MSGID,
MESSTAB-MSGNR.
ENDLOOP.

The following figures show the return codes from CALL TRANSACTION USING and the system fields that contain message information from the called transaction. As the return code chart shows, return codes above 1000 are reserved for data transfer. If you use the MESSAGES INTO <table> option, then you do not need to query the system fields shown below; their contents are automatically written into the message table. You can loop over the message table to write out any messages that were entered into it.

Return codes:

Value Explanation
0 Successful
<=1000 Error in dialog program
> 1000 Batch input error

 

System fields:

Name: Explanation:
SY-MSGID Message-ID
SY-MSGTY Message type (E,I,W,S,A,X)
SY-MSGNO Message number
SY-MSGV1 Message variable 1
SY-MSGV2 Message variable 2
SY-MSGV3 Message variable 3
SY-MSGV4 Message variable 4

 

Error Analysis and Restart Capability

Unlike batch input methods using sessions, CALL TRANSACTION USING processing does not provide any special handling for incorrect transactions. There is no restart capability for transactions that contain errors or produce update failures.

You can handle incorrect transactions by using update mode S (synchronous updating) and checking the return code from CALL TRANSACTION USING. If the return code is anything other than 0, then you should do the following:

  • write out or save the message table
  • use the BDCDATA table that you generated for the CALL TRANSACTION USING to generate a batch input session for the faulty transaction. You can then analyze the faulty transaction and correct the error using the tools provided in the batch input management facility.

 

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: