SAP ABAP SYNTAX FOR COLLECT

Basic form

COLLECT [wa INTO] itab.

Addition

... SORTED BY f

Effect

COLLECT is used to create unique or compressed datsets. The key fields are the default key fields of the internal table itab .

If you use only COLLECT to fill an internal table, COLLECT makes sure that the internal table does not contain two entries with the same default key fields.

If, besides its default key fields, the internal table contains number fields (see also ABAP/4 number types ), the contents of these number fields are added together if the internal table already contains an entry with the same key fields.

If the default key of an internal table processed with COLLECT is blank, all the values are added up in the first table line.

If you specify wa INTO , the entry to be processed is taken from the explicitly specified work area wa . If not, it comes from the header line of the internal table itab .

After COLLECT , the system field SY-TABIX contains the index of the - existing or new - table entry with default key fields which match those of the entry to be processed.

Notes

COLLECT can create unique or compressed datasets and should be used precisely for this purpose. If uniqueness or compression are unimportant, or two values with identical default key field values could not possibly occur in your particular task, you should use APPEND instead. However, for a unique or compressed dataset which is also efficient, COLLECT is the statement to use.
If you process a table with COLLECT , you should also use COLLECT to fill it. Only by doing this can you guarantee that

the internal table will actually be unique or compressed, as described above and

COLLECT will run very efficiently.

If you use COLLECT with an explicitly specified work area, it must be compatible with the line type of the internal table.

Example

Compressed sales figures for each company

DATA: BEGIN OF COMPANIES OCCURS 10,

        NAME(20),

        SALES TYPE I,

      END   OF COMPANIES.

COMPANIES-NAME = 'Duck'.  COMPANIES-SALES = 10.

COLLECT COMPANIES.

COMPANIES-NAME = 'Tiger'. COMPANIES-SALES = 20.

COLLECT COMPANIES.

COMPANIES-NAME = 'Duck'.  COMPANIES-SALES = 30.

COLLECT COMPANIES.

ADDITION

... SORTED BY f

Effect

COLLECT ... SORTED BY f is obsolete and should no longer be used. Use APPEND SORTED BY F which has the same meaning.

Note

Performance

The cost of a COLLECT in terms of performance increases with the width of the default key needed in the search for table entries and the number of numeric fields with values which have to be added up, if an entry is found in the internal table to match the default key fields.
If no such entry is found, the cost is reduced to that required to append a new entry to the end of the table.

A COLLECT statement used on a table which is 100 bytes wide and has a key which is 60 bytes wide and seven numeric fields is about approx. 50 msn (standardized microseconds).

Note

Runtime errors

COLLECT_OVERFLOW : Overflow in integer field when calculating totals.

COLLECT_OVERFLOW_TYPE_P : Overflow in type P field when calculating totals.

RELATED POST

SYNTAX FOR CLOSE AND CNTsap internet transaction architecture
SAP internet transaction application components

Mysap market place introduction
Customer interface in mysap market place

SAP ABAP SYNTAX FOR CLOSE AND CNT

Basic form

... CNT(h) ...

Effect

CNT(h) is not a statement, but a field which is automatically created and filled by the system if f is a sub-field of an EXTRACT DATA SET.

CNT(h) can only be addressed from within a LOOP on a SORTED extract.

If h is a non-numeric field (see also ABAP/4 number types ) from the field group HEADER and part of the sort key of the extract dataset, the end of a control level (AT END OF , AT LAST ) is such that CNT(h) contains the number of different values which the field h has accepted in the group, i.e. the number of records in the group for which the field f has changed its value.

CLOSE

Basic form

1. CLOSE DATASET dsn.
2. CLOSE CURSOR c.

Basic form 1

CLOSE DATASET dsn.

Effect

Closes the file dsn , ignoring any errors which may occur. CLOSE is required only if you want to edit dsn several times. For further details, see the documentation for OPEN DATA SET .

Basic form 2

CLOSE CURSOR c.

Effect

Closes the database cursor c . CLOSE CURSOR is only required if you want to read sets of database records several times with c . For further information, refer to the documentation on OPEN CURSOR and FETCH .

CLOSE CURSOR belongs to the Open SQL command set.
24.5 RELATED POST

SAP Authorization and ALE
Authorization and implementation of SAP
Mysap marketplace an introduction

SAP ABAP SYNTEX FOR CLEAR

Basic form

CLEAR f.

Additions

1. ... WITH g
2. ... WITH NULL

Effect

Resets the contents of f to its initial value.For predefined types the following initial values are used:
Type C : ' ... ' (blank character) Type N : '00...0' Type D : '00000000' Type T : '000000'
Type I : 0 Type P : 0 Type F : 0.0E+00 Type X : 0
If f is a field string, each component field is reset to its initial value. If it is an internal table without a header line, the entire table is deleted together with all its entries. If,

however, f is an internal table with a header line, only the sub-fields in the table header entry are reset to their initial values.

Example

DATA: TEXT(10)       VALUE 'Hello',

      NUMBER TYPE I  VALUE 12345,

      ROW(10) TYPE N VALUE '1234567890',

      BEGIN OF PLAYER,

        NAME(10)      VALUE 'John',

        TEL(8) TYPE N VALUE '08154711',

        MONEY  TYPE P VALUE 30000,

      END   OF PLAYER.

...

CLEAR: TEXT, NUMBER, PLAYER.

The field contents are now as follows:

ROW = '1234567890'
TEXT = ' '
NUMBER = 0
PLAYER-NAME = ' '
PLAYER-TEL = '00000000'
PLAYER-MONEY = 0

Notes

When CLEAR references an internal table itab with a header line, it only resets the sub-fields in the header entry to their initial values (as mentioned above). The individual table entries remain unchanged.
To delete the entire internal table together with all its entries, you can use CLEAR itab[] or REFRESH TAB . Here, a Note is still required to explain how to manipulate tables with/without header lines.
Within a logical expression , you can use f IS INITIAL to check that the field f contains the initial value appropriate for its type.
Variables are normally initialized according to their type, even if the specification of an explicit initial value (addition " ... VALUE lit " of the DATA statement) is missing. For this reason, it is not necessary to initialize variables again with CLEAR after defining them.

Addition 1

... WITH g

Effect

The field f is filled with the value of the first byte of the field g .

Addition 2

... WITH NULL

Effect

Fills the field with hexadecimal zeros.

You should use this addition with particular care because the fields of most data types thus receive values which are really invalid.

Performance
CLEAR requires about 3 msn (standardized microseconds) of runtime to process a field of type C with a length of 10 and about 2 msn to process a field of the type I. To delete an internal table with 15 fields, it needs about 5 msn.

RELATED POST

SYNTAX FOR CHECK IN REPORTS
Authorization and implementation of SAP
Mysap marketplace an introduction

CHECK special for reports with logical databases SAP ABAPsyntax check

Variants

1. CHECK sel.
2. CHECK SELECT-OPTIONS.

Variant 1

CHECK sel.

Effect

Checks the selection criterion requested by the statement SELECT -OPTIONS SEL...

This statement is equivalent to f IN sel , if sel was defined by SELECT-OPTIONS SEL FOR f and can be used anywhere in logical expressions

If the result of this check is negative, the processing in this event is terminated and the GET events for any subordinate database tables are not processed either.

This variant of the CHECK statement should be used only if the logical database for the corresponding table does not support dynamic selections (see CHECK SELECT-OPTIONS ), or SELECT-OPTIONS with the addition NO DATABASE SELECTION . Otherwise, the relevant record is not read from the database and made available to the program.

Variant 2

CHECK SELECT-OPTIONS.

Effect

Called only after a GET event.
This statement checks all the selections for SELECT-OPTIONS where the reference field after FOR belongs to the current table dbtab (specified after GET . However, this applies only if the logical database for dbtab does not support dynamic selections . Otherwise, the selections are passed directly to the logical database (with the exception: addition " NO DATABASE SELECTION " to SELECT-OPTIONS ).

This variant of the CHECK statement only makes sense if the logical database does not support dynamic selections for the corresponding table or SELECT-OPTIONS are defined with the addition " NO DATABASE SELECTION ".

You can determine from the ABAP/4 Development Workbench whether dynamic selections are defined and, if so, for which logical database tables by selecting Development -> Programming environ. -> Logical databases followed by Extras -> Dynamic selections .

Example

The logical database F1S of the demo flight reservation system contains the tables SPFLI with, and the table SFLIGHT without, dynamic selections.

TABLES:

  SPFLI, SFLIGHT.

SELECT-OPTIONS:

  SF_PRICE  FOR SFLIGHT-PRICE,

  SP_CARR   FOR SPFLI-CARRID,

  SP_FROM   FOR SPFLI-CITYFROM NO DATABASE SELECTION,

  SP_DEPT   FOR SPFLI-DEPTIME.

Since dynamic selections are defined with the table SPFLI , but not with the table SFLIGHT , the following procedure applies:

...

GET SFLIGHT.

  CHECK SELECT-OPTIONS.

This CHECK statement is equivalent to the following statement:

  CHECK SF_PRICE.

With

GET SPFLI.

  CHECK SELECT-OPTIONS.

the CHECK statement is equivalent to the following statement:

  CHECK SP_FROM.

Note

With CHECK SELECT-OPTIONS , fields from superior tables in the database hierarchy are not (!) checked.

Note

Runtime errors

CHECK_SELOPT_ILLEGAL_OPTION : Wrong " OPTION " in SELECT-OPTIONS or RANGES table

CHECK_SELOPT_ILLEGAL_SIGN : Wrong " SIGN " in SELECT-OPTIONS or RANGES table

SAP ABAP SYNTAX FOR CHECK WITH IN LOOPS

Basic form

CHECK logexp.

Effect

CHECK evaluates the subsequent logical expression . If it is true, the processing continues with the next statement.

In loop structures like

DO... ENDDO

WHILE ... ENDWHILE

LOOP ... ENDLOOP

SELECT ... ENDSELECT

CHECK with a negative outcome terminates the current loop pass and goes back to the beginning of the loop to start the next pass, if there is one.

In structures like

FORM ... ENDFORM

FUNCTION... ENDFUNCTION

MODULE ... ENDMODULE

CHECK with a negative outcome terminates the routine or modularization unit.

If CHECK is not in a loop or a routine or a modularization unit, a negative logical expression terminates the current event. In contrast, the statement REJECT terminates the current event, even from loops or subroutines.

If a CHECK produces a negative result in a GET event , the GET events in subordinate tables of the logical database are not processed either.

SAP Authorization and ALE
Authorization and implementation of SAP
Mysap marketplace an introduction

CHECK SYNTAX FOR SAP ABAP

Basic form

CASE f.
Effect Case distinction.

Depending on the current contents of a field, this statement executes one of several alternative processing branches. The field whose contents determine how the subsequent processing is specified after CASE ; the individual processing branches are introduced by WHEN , followed by the value to be tested. The entire block is concluded by ENDCASE . The structure of the CASE statement is as follows:

CASE f.

  WHEN f1.

...

  WHEN f2.

...

...

ENDCASE.

On
reaching such a CASE statement, the processor compares f with f1 .

If f = f1 , it executes the processing block between " WHEN f1. " and
the next WHEN statement. If there are no further WHEN statements, it executes
the processing block up to the ENDCASE statement and then continues with any
subsequent processing.

If f <> f1 , the processor compares the field f2 in the next WHEN
statement with f and proceeds as with f1 and so on.



Although f should be a variable, f1 can be a variable or a literal. For the
comparison " f = f1 ", the rules are the same as for IF .



There is a second variant of the WHEN statement:



WHEN OTHERS.

No more than one such WHEN statement is allowed within a CASE block. The "
WHEN OTHERS " processing block is always concluded by ENDCASE , i.e. no
further WHEN statements can follow.



The " WHEN OTHERS " processing block is executed only if none of the
preceding WHEN blocks have been executed, i.e. if all previous comparisons
(" f = ... ) have returned a negative result.

Example

DATA: ONE TYPE I VALUE 1, THREE TYPE P VALUE 3.DO 5 TIMES. CASE SY-INDEX. WHEN ONE. WRITE / 'That is'. WHEN 2. WRITE 'a'. WHEN THREE. WRITE 'good'. WRITE 'example'. WHEN OTHERS. WRITE '!'. ENDCASE.ENDDO.

Output: " That is a good example ! ! "

Notes

You can nest several CASE statements and even combine them with IF statements.
The statement " WHEN: f1, f2. " does not make sense. The example below shows that the block belonging to " WHEN f1 " is empty:

WHEN f1.
WHEN f2.

RELATED POST

CALL TRANSACTION SYNTAX FOR SAP ABAP


SAP authorization and client administration in mysap.com
SAP Authorization and ALE

CALL TRANSACTION syntax for SAP ABAP

Basic form

CALL TRANSACTION tcod.

Additions

1. ... AND SKIP FIRST SCREEN
2. ... USING itab
2a. ... MODE mode
2b. ... UPDATE upd
2c. ... MESSAGES INTO messtab

Effect

Calls the SAP Transaction tcod ; tcod can be a literal or a variable. To return from the called transaction, you use the key word LEAVE PROGRAM .

Example

CALL TRANSACTION 'SP01'.

Addition 1

... AND SKIP FIRST SCREEN

Effect

Skips the first screen in the transaction (provided all the required fields have been assigned values by the SPA/GPA process).

Addition 2

... USING itab

Effect

Calls the Transaction tcod and passes the internal table itab , which contains one or several screens in batch input format.
If necessary, one of the messages output by the Transaction is returned to the fields SY-MSGID , SY-MSGTY SY-MSGNO , SY-MSGV1 , ..., SY-MSGV4 .

The return code value is set as follows:

SY-SUBRC = 0 Processing was successful.
SY-SUBRC <> 0 Transaction ended with an error.

Note

A called Transaction ends successfully for the following reasons:
COMMIT WORK Next screen = 0 LEAVE TO TRANSACTION ' '

Addition 2a

... MODE mode

Effect

The specified processing mode can accept the following values:

'A' Display screen
'E' Display screen only if an error occurs
'N' No display

If the addition MODE is not specified, the processing mode is set to 'A' .

Addition 2b

... UPDATE upd

Effect

The specified update mode upd defines the update type. This can have one of the following values:

'A' Asynchronous update
'S' Synchronous update

If the addition UPDATE is not specified, the processing mode is set to 'A' .

Addition 2c

... MESSAGES INTO messtab

Effect

The specified internal table contains all system messages that occur during CALL TRANSACTION USING ... . The internal table messtab must have the structure BDCMSGCOLL .

Example

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.

DATA REPORT(8).

BDCDATA-PROGRAM  = 'SAPMS38M'.

BDCDATA-DYNPRO   = '0100'.

BDCDATA-DYNBEGIN = 'X'.

APPEND BDCDATA.

CLEAR BDCDATA.

BDCDATA-FNAM     = 'RS38M-PROGRAMM'.

BDCDATA-FVAL     = REPORT.

APPEND BDCDATA.

...

CALL TRANSACTION 'SE38'  USING BDCDATA  MODE 'N'

                         MESSAGES INTO MESSTAB.

Run time errors

CALL_TRANSACTION_NOT_FOUND : Transaction is unknown.

CALL_TRANSACTION_IS_MENU : Transaction is a menu.

CALL_TRANSACTION_USING_NESTED : Recursive CALL TRANSACTION USING

RELATED POST

What is enjoySAP technology and how it is used
sap internet transaction server introduction
sap internet transaction architecture
SAP internet transaction application components

SAP ABAP SYNTAX FOR CALL SCREEN

Basic form

CALL SCREEN scr.

Addition

... STARTING AT x1 y1 ... ENDING AT x2 y2

Effect

Calls the screen scr ; scr is the number of a screen of the main program. You use SET SCREEN 0 or LEAVE SCREEN to define the return from the CALL screen .

Addition

... STARTING AT x1 y1 ENDING AT x2 y2

Effect

The coordinates x1 , y1 (start column and start line in the window) and x2 , y2 (end column and end line in the window) define the size and position of the CALL screen ("top left - bottom right"). Besides these coordinates, you can also see the contents of the primary window, but cannot perform any action there.

Note

If " ENDING AT ... " is not specified, suitable values are substituted for x2 and y2 , taking into account the size of the called screen .

Note

Runtime errors
DYNP_TOO_MANY_CALL_SCREENS : No further screen level (call screen); the maximum number of nested screen levels is restricted to 50 at present.

MySAP technology RFC,BAPI,ALE and IDOC overview
MySAP new generation technologies overview
SAP cost,definition,authorization and architecture

SAP ABAP SYNTAX FOR CALL METHOD of an external object

Basic form

CALL METHOD OF obj m.

Additions

1. ... = f
2. ... EXPORTING p1 = f1 ... pn = fn
3. ... NO FLUSH

Effect

Calls the method m of the object obj . m can be a literal or a variable.
CALL METHOD

Addition 1

... = f

Effect

Stores the return value of the method in the variable f . The return value can also be of type OLE2_OBJECT . This addition must always come before other additions.

Addition 2

... EXPORTING p1 = f1 ... pn = fn

Effect

EXPORTING passes values of fields to the parameters of the method. p1 , p2 , ... are either key word parameters or position parameters. If assignment of parameters is by sequence, p1 , p2 , ... must begin with "#", followed by the position number of the parameter. At present, only position parameters are supported. The export parameters always come at the end of the statement.

Addition 3

... NO FLUSH

Example

Open an EXCEL file with the method 'Open'.

INCLUDE OLE2INCL.

DATA EXCEL    TYPE OLE2_OBJECT.

DATA WORKBOOK TYPE OLE2_OBJECT.

CREATE OBJECT   EXCEL    'Excel.Application'.

CALL METHOD  OF EXCEL    'Workbooks' = WORKBOOK.

CALL METHOD  OF WORKBOOK 'Open'    EXPORTING #1 = 'C:\EX1.XLS'.




RELATED POST

SYNTAX FOR CALL FUNCTION PART FOUR
MySAP technology RFC,BAPI,ALE and IDOC overview
MySAP new generation technologies overview
SAP cost,definition,authorization and architecture

SAP ABAP SYNTAX FOR CALL FUNCTION part four

Variant 3

CALL FUNCTION func IN UPDATE TASK.

Additions

1. ... EXPORTING p1 = f1 ... pn = fn
2. ... TABLES p1 = itab1 ... pn = itabn

Effect

Flags the function module func for execution in the update task. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task. Update function modules must be flagged as such in the function library.

Addition 1

... EXPORTING p1 = f1 ... pn = fn

Effect

Values of fields and field strings specified under EXPORTING are passed from the calling program to the function module. In the function module, the formal parameters are defined as import parameters. In the interface definition, default values must be assigned to all import parameters of the update function module.

Addition 2

... TABLES p1 = itab1 ... pn = itabn

Effect

TABLES passes references to internal tables. All table parameters of the function module must have values.

Note

With update function modules, both import parameters and exceptions are ignored when the call is made.
Administration transaction .

RELATED POST

sap internet transaction server introduction
sap internet transaction architecture
SAP internet transaction application components

CALL FUNCTION SYNTAX FOR SAP ABAP part three

Variant 2

CALL FUNCTION func ...STARTING NEW TASK

Additions

1. ... DESTINATION dest
2. ... PERFORMING form ON END OF TASK
3. ... EXPORTING p1 = f1 ... pn = fn
4. ... TABLES p1 = itab1 ... pn = itabn
5. ... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Starts the function module func asynchronously in a new mode. In contrast to normal function module calls, the calling program resumes processing as soon as the function module is started in the target system. It does not wait until the function module has finished. Through CALL SCREEN , the called function module can, for example, display a screen and thus interact with the user.

Notes

This variant applies only from R/3 Release 3.0. Both partner systems (the client and the server systems) must have a Release 3.0 version of the R/3 System.

With this variant, the called function module must also be

flagged in the Function Library as externally callable, even if it is executed locally (without the addition DESTINATION).

Addition 1

... DESTINATION dest

Effect

Executes the function module externally as a Remote Function Call ( RFC ); dest can be a literal or a variable. The R/3 System where the function module is executed depends on the specified destination. Externally callable function modules must be flagged as such in the Function Library (of the target system).

Addition 2

... PERFORMING form ON END OF TASK
Whereas the parameters for receiving results (i.e. IMPORTING and TABLES parameters) are specified directly as additions in the case of "conventional" function modules (see variant 2), these are logged in the FORM routine form when making an asynchronous call .

Note

If a function module returns no result, this addition ( ... PERFORMING form ON END OF TASK ) can be omitted.

Addition 3

... EXPORTING p1 = f1 ... pn = fn

Effect

EXPORTING passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters.

Addition 4

... TABLES p1 = itab1 ... pn = itabn

Effect

TABLES passes references to internal tables. All table parameters of the function module must contain values.

Addition 5

... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

While any exceptions arising in the called function module are handled by the second addition (in the FORM routine), this addition can handle two special system exceptions, as with function module calls with the addition DESTINATION :
SYSTEM_FAILURE

is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE

is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with the optional addition

... MESSAGE mess

Example

DATA: MSG_TEXT(80). "Message text

...

* Asynchronous call to Transaction SM59 -->

* Create a new session

CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'

  DESTINATION 'NONE'

  EXPORTING

      TCODE = 'SM59'

  EXCEPTIONS COMMUNICATION_FAILURE MESSAGE MSG_TEXT.

  IF SY-SUBRC NE 0.

    WRITE: MSG_TEXT.

  ELSE.

    WRITE: 'O.K.'.

  ENDIF.

Note

Runtime errors

CALL_FUNCTION_TASK_YET_OPEN : Task already open.

RELATED POST

CALL FUNCTION SYNTAX PART TWO

MySAP technology RFC,BAPI,ALE and IDOC overview
MySAP new generation technologies overview

CALL FUNCTION SYNTAX FOR SAP ABAP extended

Variant 5

CALL FUNCTION func IN BACKGROUND TASK.

Additions

1. ... DESTINATION dest
2. ... EXPORTING p1 = f1 ... pn = fn
3. ... TABLES p1 = itab1 ... pn = itabn

Effect

Flags the function module func to be run asynchronously. It is not executed at once, but the data passed with EXPORTING bzw. TABLES is placed in a database table and the next COMMIT WORK then executes the function module in another work process.

Note

This variant applies only from R/3 Release 3.0. Both partner systems (the client and the server systems) must have a Release 3.0 version of the R/3 System.

Addition 1

... DESTINATION dest

Effect

Executes the function module externally as a Remote Function Call ( RFC ); dest can be a literal or a variable.
Depending on the specified destination, the function module is executed either in another R/3 System or as a C-implemented function module. Externally callable function modules must be flagged as such in the function library (of the target system).
Since each destination defines its own program context, further calls to the same or different function modules with the same destination can access the local memory (global data) of these function modules.

Addition 2

... EXPORTING p1 = f1 ... pn = fn

Effect

EXPORTING passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters. Default values must be assigned to all import parameters of the function module in the interface definition.

Addition 3

... TABLES p1 = itab1 ... pn = itabn

Effect

TABLES passes references to internal tables. All table parameters of the function module must contain values.

Notes

If several function module calls with the same destination are specified before COMMIT WORK , these form an LUW in the target system.
Type 2 destinations (R/3 - R/2 connections) cannot be specified.

CALL FUNCTION

Variant 4

CALL FUNCTION func DESTINATION dest.

Additions

1. The same as with CALL FUNCTION func
2. ... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Executes the function module externally as a Remote Function Call ( RFC ); dest can be a literal or a variable.
Depending on the specified destination, the function module is executed in another R/3 or R/2 System. Externally callable function modules must be flagged as such in the function library (of the target system).
Since each destination defines its own program context, further calls to the same or different function modules with the same destination can access the local memory (global data) of these function modules.

You can maintain existing destinations by selecting Tools -> Administration -> Administration -> Network -> RFC .

Notes

Special destinations:

The destination NONE refers to the calling system. Function modules called with

CALL FUNCTION func DESTINATION 'NONE' ...

are executed in the system of the calling program, but in their own program context.

You can use the destination BACK if the current program was already called by RFC . The, BACK refers back to the calling program:

CALL FUNCTION func DESTINATION 'BACK' ...

If the program is not called from a "remote" source, the exception COMMUNICATION_FAILURE is triggered.

Each R/3 System has a standard name. This is formed from the host name (e.g. SY-HOST ), the system name ( SY-SYSID ) and the system nummer (two-character

number assigned on installation of the applications server).
You can use this name as a destination. For example, you can call the function module func in the system C11 on the host sapxyz with system number 00 as follows:

CALL FUNCTION func DESTINATION 'sapxyz_C11_00' ...

You can also use saprouter path names as destinations (see also saprouter documentation).

Note

Parameter passing. When you pass data to an externally called function module, there are some differences to the normal function module call:

With table parameters, only the table itself is passed, not the header line.

If one of the parameters of the interface of an externally called function module is not specified when called, the import parameters are set to their initial value. If no default value was given in the interface definition, TABLES parameters are defined as an empty table and unspecified export parameters are lost.

Note

Passing structured data objects. Since transport to another system may require data conversion, the structure of field strings and internal tables must be known to the runtime system when the call is made. The structure of a field string or internal table is not known if it was defined with

... LIKE structure ,

if the structure passed was passed to the subroutine with the explicit addition STRUCTURE , or if it is a parameter of a function module.

In these cases, external calls can result in a conversion error.

Note

C interface. You can call externally callable function modules from C programs. It is also possible to store function modules in a C program and call them via CALL FUNCTION ... DESTINATION . For this purpose, SAP provides a C interface .

Addition 2

... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Function module calls with the addition DESTINATION can handle two special system exceptions:
SYSTEM_FAILURE

This is triggered if a system crash occurs on the receiving

side.
COMMUNICATION_FAILURE

This is triggered if there is a connection or communication problem.
In both cases, you can use the optional addition

... MESSAGE mess

to receive a description of the error.

Note

Runtime errors

CALL_FUNCTION_DEST_TYPE :Destination type not allowed.

CALL_FUNCTION_NO_DEST :Destination does not exist.

CALL_FUNCTION_NO_LB_DEST :Destination (in 'Load Balancing' mode) does not exist.

CALL_FUNCTION_TABINFO :Data error (info internal table) during 'Remote Function Call'

CALL FUNCTION SYNTAX FOR SAP ABAP

Variant 1

CALL FUNCTION func.

Additions

1. ... EXPORTING p1 = f1 ... pn = fn
2. ... IMPORTING p1 = f1 ... pn = fn
3. ... TABLES p1 = itab1 ... pn = itabn
4. ... CHANGING p1 = f1 ... pn = fn
5. ... EXCEPTIONS except1 = rc1 ... exceptn = rcn

Effect

Calls the function module func ; func can be a literal or a variable.To edit function modules, select Tools -> ABAP/4 Workbench -> Function Library .The assignment of parameters is by name ( p1 , p2 , etc.), not by sequence. To return from the function module, you use the key word EXIT, unless EXIT occurs in a loop or a subroutine.

Note

You can use the editor commands " SHOW FUNCTION func " and " SHOW FUNCTION * " to get information about the function module func or any other function module.

Addition 1

... EXPORTING p1 = f1 ... pn = fn

Effect

EXPORTING passes fields, field strings or internal tables to the function module. You must declare the parameters p1 ... pn in the function interface as import parameters. When you call the function module, you must assign values to all import parameters which are not flagged in the interface definition as optional and do not have any default values.

Addition 2

... IMPORTING p1 = f1 ... pn = fn

Effect

IMPORTING passes fields, field strings or internal tables from the function module back to the calling program. The parameters p1 ... pn must be declared as export parameters in the function interface.

Addition 3

... TABLES p1 = itab1 ... pn = itabn

Effect

TABLES passes references to internal tables. The parameters p1 ... pn must be declared as table parameters in the function interface. When you call the function module, you must assign values to all table parameters which are not flagged as optional in the interface definition.

Addition 4

... CHANGING p1 = f1 ... pn = fn

Effect

CHANGING passes fields, field strings or internal tables to the function module and the changed values are returned. The parameters p1 ... pn must be declared as CHANGING parameters in the function interface. When you call the function module, you must assign values to all CHANGING parameters of the function module which are not flagged as optional in the interface definition and have no default values.

Addition 5

... EXCEPTIONS except1 = rc1 ... exceptn = rcn

Effect

EXCEPTIONS lists the exceptions to be handled by the calling program itself. At the end of the exception list, you can use OTHERS to refer to all the remaining exceptions.
If one of the listed exceptions occurs, SY-SUBRC is set to the appropriate value rc (a number literal!) and control passes back to the calling program. By specifying a return code, you can divided the exceptions into classes. With the second form, without "=rc", SY-SUBRC is set to a value other than 0 if an exception occurs.
If the function module triggers an exception (with the statements RAISE and MESSAGE ...RAISING ) and the exception is not to be handled by the calling program itself,

RAISE terminates the program with a runtime error;

MESSAGE ... RAISING outputs the message.

Note

The following EXCEPTIONS are predefined by the system and have a special meaning:

OTHERS : Covers all user-defined exceptions in the called function module.

ERROR_MESSAGE : This exception instructs the system to ignore S messages, I messages and W messages until return from the function module (although they still appear in the log during background processing). When an E message or an A message occurs, the called function module terminates, as if the exception ERROR_MESSAGE has been triggered.

Examples

DATA: FIELD(30) VALUE 'Example: This is a field.',

      head(30).

CALL FUNCTION   'STRING_SPLIT'

     EXPORTING  DELIMITER = ':'

                STRING    = FIELD

     IMPORTING  HEAD      = HEAD

                TAIL      = FIELD

     EXCEPTIONS NOT_FOUND = 1

                OTHERS    = 2.

CASE SY-SUBRC.

  WHEN 1. ...

  WHEN 2. ....

ENDCASE.

...

DATA: BEGIN OF TAB1 OCCURS 10, X, END OF TAB1,

      BEGIN OF TAB2 OCCURS 20, Y, END OF TAB2.

CALL FUNCTION 'ITAB_COPY'

     TABLES   TAB_IN    = TAB1

TAB_OUT = TAB2.

Runtime errors

CALL_FUNCTION_NOT_FOUND : The called function is unknown.

CALL_FUNCTION_NO_VB : Only update function modules can be called in the update task.

CALL_FUNCTION_NOT_ACTIVE : The called function is known, but not active.

CALL_FUNCTION_PARM_MISSING : The function expects a parameter, but none was passed by the calling program.

CALL_FUNCTION_PARM_UNKNOWN : The calling program passed a parameter which the function does not recognize.

CALL_FUNCTION_CONFLICT_LENG : The function expected a different actual parameter length.

CALL_FUNCTION_CONFLICT_TYPE

CALL_FUNCTION_CONFLICT_GEN_TYP : The actual parameter type does not satisfy the requirements of the function interface.

CALL_FUNCTION_WRONG_ALIGNMENT : An actual parameter does not satisfy the alignment requirements of the corresponding formal parameter.

CALL_FUNCTION_BASE_LITL : A literal was supposed to be passed to a structured formal parameter.

Subscribe to: Posts ( Atom )