Address

parameters

Specific reference structures are defined for address parameters in

BAPIs. You should copy these structures to use in your BAPI, especially
if the underlying object type uses the central address management
(CAM).

Change
Parameters

In BAPIs that cause database changes (for example, Change() and

Create() BAPIs) you must be able to distinguish between parameter
fields that contain modified values and parameter fields that have not
been modified. This distinction is made through the use of standardized
parameters.

Extension
parameters

The parameters ExtensionIn and ExtensionOut provides customers with

a mechanism that enables BAPIs to be enhanced without modifications.

Return
Parameters

Each BAPI must have an export return parameter for returning messages
to the calling application. To provide application programmers with a
consistent error handling process for BAPI calls, all return parameters
must be implemented in the same, standardized way.

Selection
Parameters

Standardized selection parameters are used in BAPIs that can be used to

search for specific instances of a business object type (e.g. in GetList() ).
These parameters enable the BAPI caller to specify the relevant
selection criteria.

Test Run
Parameters

The parameter TestRun is used in write BAPIs (Create() and Change() ),

to check the entries for the object instance in the database before
actually creating the object instance. The creation of the object instance
is only simulated and data is not updated.

Text Transfer
Parameters

To transfer BAPI documentation texts (e.g. the documentation of a

business object type), you have to create standardized text transfer
parameters.

Important things to remember..

It is important to follow the guidelines below when develop9ng BAPIs:
BAPIs must not contain CALL TRANSACTIO or SUBMIT REPORT
BAPIs must not invoke a COMMIT WORK. instead use the BAPI
TransactionCommit to execute the commit after the BAPI has executed.
BAPI structures must not use includes.
There should be no functional dependecies between two BAPIs
BAPIs must perform there own authorization check
BAPIs should not use dialogs
BAPIs must not cause the program to abort or terminate. re4levant messages must
be communicated through the return parameter.

BAPI/ALE Integration
When you use the BAPIs for asynchronous messagning, the application in the sendig
systen calls the generated ALE IDoc interface isntead of the BAPI.
Asynchronous BAPIs use the ALE interface this way:

Creates an IDOC from the BAPI data

Sends the IDOC to the target system
Receives the IDOC in trhe target system, crreates the BAPI data from the IDoc
and calls the BAPI

An ALE interface for a BAPi is created in transaction BDBG.

IDOC:
The messages exchanged between systems are of various message types. The message type
depends on the data contained and the process involved. It determines the technical structure
of the message, the IDoc type. For example, the FIDCMT message type is used for journal
messages.
The IDoc type indicates the SAP format that is to be used to interpret the data of a business
transaction.
An IDoc type consists of the following components:

a control record
This is identical for each IDoc type.

several data records

One data record consists of a fixed key part and a variable data part. The data part is
interpreted using segments, which differ depending on the IDoc type selected.

several status records

These are identical for each IDoc type and describe the statuses an IDoc has already passed
through or the status an IDoc has attained.

Upload/Download SAP Scripts To/From PC

If you wish to keep a copy of your layout sets in your own hardisk. You can run this SAP
program. You can keep it as a backup copy and upload it back whenever you need it
again.
RSTXSCRP - SAP Scripts Export/Import
How to Print TIF image in SAP Script?

To print image, you have to import a tif file from your local hardisk via the SAP abap
program RSTXLDMC.
In the sap script, add in the following script.
: / INCLUDE ZLOGO OBJECT TEXT ID ST LANGUAGE EN.
or
Tested in 4.6x
Go to transaction SE78.
Follow the path given below (on the left windows box) :SAPSCRIPT GRAPHICS --> STORED ON DOCUMENT SERVER -->
GRAPHICS --> BMAP
Enter the name of the graphics file on the right side and Go to the menu GRAPHIC -->
IMPORT.
Convert Spool request to PDF format to your local drive
After sending your ABAP List or SAP Scripts to the spool request (SP01), you can use
the SAP standard spool PDF conversion program.
RSTXPDFT4 - Convert ABAP List and SAP Script to PDF files
Difference with SMARTFORMS vs. SapScript(SE71)
The Following are the differences :a) Multiple page formats are possible in smartforms which is not the case in SAPScripts
b) It is possible to have a smartform without a main window .
c) Labels cannot be created in smartforms.
d) Routines can be written in smartforms tool.
e) Smartforms generates a function module when activated.
Smart forms whose function module that was generated is not saved in any
development class. Is it anything to do with / name space. When I transported the
smartforms only the layout went but not function module. How could this be sorted?
That is because the Function module is not transported.

It is regenerated on the Target System as a new function module all together.

You can transport the smartform from SE01.
* Executing Unix command from ABAP
*
REPORT ZUNIX.
data: unix_command(50) type c value 'ls -ls /usr/sap/trans/data'.
data: begin of internal_table occurs 0,
line(200),
end of internal_table.
PARAMETERS UNIXCOMM LIKE unix_command
DEFAULT 'ls -ls /usr/sap/trans/data' LOWER CASE.
call 'SYSTEM' id 'COMMAND' field UNIXCOMM
id 'TAB' field internal_table-*SYS*.
EDITOR-CALL FOR INTERNAL_TABLE DISPLAY-MODE.
*--- End of Program
ABAP Debugger
Activate the Debugger before executing your ABAP program
System -> Utilities -> Debug ABAP/4
The purpose of the debugger is to allow you to execute your program line by line. It also
allow you display the data as you execute the program. (double click on the varaible field
name and it will be display)
or after program have been executed,
Run transaction SM66 and find your work process.
Select the line of your work process and double click on it
Click the debugging option.
If this is a custom program, you can put a wait statement in the code to buy yourself some
time.

Passing Data Between Programs

Transactions, dialog modules and executable programs (reports) all run in their own roll areas.
When you call any of these from your transaction, you must also pass them the data they need to
run. The options for passing data to an external program are:

Using SPA/GPA parameters (SAP memory)

This the most common method for passing data from one external program to another.
For information, see: Passing Data with SPA/GPA Parameters.

Using EXPORT/IMPORT data (ABAP memory)

Any program can store clusters of data fields in ABAP memory using the EXPORT
statement. This data is then available globally (using IMPORT), in the program itself, and
in any called transactions, reports or other modules. To use EXPORT:
EXPORT <OBJECT1> <OBJECT2>... <OBJECTN> TO MEMORY ID <ID-NAME>.
The program you are calling then retrieves the data with :
IMPORT <OBJECT1> <OBJECT2>... <OBJECTN> FROM MEMORY ID <ID-NAME>.
The ID parameter identifies the data cluster uniquely. If you export the same objects
again to the same ID, you overwrite the first version of the cluster in memory. If you
export a subset of the objects the second time, you still overwrite all the objects (not just
the subset) in the first version of the group.
Use EXPORT/IMPORT to implement parameter passing only when the calling and called
programs are always used together. EXPORT/IMPORT is not recommended for calling
programs that will be available to outside applications, since these applications will have
no way of knowing the interface required for calling.

For information about EXPORTing and IMPORTing data clusters, see Data Clusters in ABAP
Memory.
The MEMORY-ID option of the PARAMETERS statement allows you to use a default value from
the global SAP memory (SPA/GPA parameters). The syntax is as follows:
Syntax
PARAMETERS <p>...... MEMORY ID <pid>......
When you use this option, the value stored at that point under the name <pid> in the global userrelated SAP memory appears as the default value for <p> on the selection screen.
<pid> can be up to 3 characters long and must not be enclosed in quotation marks.
You use the global SAP memory to pass values retained beyond transaction limits between
programs. This memory is available to a user for the entire duration of a terminal session and any
parallel sessions use the same memory. The SAP memory is thus more comprehensive than the
transaction-bound ABAP memory (see Data Clusters in ABAP Memory).

Parameters can be set user specific in the users master records with the name <pid>. For further
information about the SAP memory, refer to the keyword documentation for SET/GET
PARAMETER and to Passing Data Between Programs.

The following program stores a value under the name "HK" in the global SAP
memory:
REPORT SAPMZTS1.
SET PARAMETER ID 'HK' FIELD 'Test Parameter'.
This value is used in the following executable program (report)as a default value
for the parameter TEST:
PROGRAM SAPMZTS2.
PARAMETERS TEST(16) MEMORY ID HK.
The selection screen of SAPMZTS2 looks as follows:

Transferring SPA/GPA Parameters to Transactions

To fill the input fields of a called transaction with data from the calling program, you can use the
SPA/GPA technique. SPA/GPA parameters are values that the system stores in the global, userrelated SAP memory. You use the SAP memory to transfer values between programs beyond the
borders of transactions. A user can access the values stored in the SAP memory during one
terminal session for all modes used in parallel.
Usually, the input fields on the initial screen of a transaction are connected to SPA/GPA
parameters. If you fill these parameters from within your program before calling the transaction,
the system fills the input fields with the corresponding values.
To fill an SPA/GPA parameter, use:
Syntax
SET PARAMETER ID <pid> FIELD <f>.
This statement saves the contents of field <f> under the ID <pid> in the SAP memory. Use three
characters for the ID <pid>. If the ID <pid> exists, this statement overwrites the value previously
stored there.
If the ID <pid> does not exist, double-click on <pid> in the ABAP Editor to create a new parameter
object.
To read an SPA/GPA parameter into an ABAP program, use:
Syntax

GET PARAMETER ID <pid> FIELD <f>.

This statement fills the value stored under the ID <pid> into the variable <f>. If the system does
not find a value for <pid> in the SAP memory, it sets SY-SUBRC to 4, otherwise to 0. To transfer
parameters to a called program, you do not need this statement.
When calling transactions, you must know which SPA/GPA parameters are connected to the input
fields on the transaction's initial screen. To find this out, start the transaction, position the cursor
on the individual input fields, choose Help, and on the dialog window that appears, choose
Technical Information. The dialog window Technical Information appears, showing the appropriate
SPA/GPA parameter in the field Parameter ID.

The technical information for the first input field of the booking transaction TCG2
looks like this:

The SPA/GPA parameter for the input field Company has the ID CAR. Use this
method to find the IDs CON, DAY, and BOK for the other input fields.
The following executable program (report) is connected to the logical database
F1S and calls Transaction TCG2:
REPORT SAPMZTST NO STANDARD PAGE HEADING.
TABLES SBOOK.
START-OF-SELECTION.
WRITE: 'Select a booking',
/ '----------------'.
SKIP.
GET SBOOK.
WRITE: SBOOK-CARRID, SBOOK-CONNID,
SBOOK-FLDATE, SBOOK-BOOKID.
HIDE: SBOOK-CARRID, SBOOK-CONNID,
SBOOK-FLDATE, SBOOK-BOOKID.
AT LINE-SELECTION.
SET PARAMETER ID: 'CAR' FIELD SBOOK-CARRID,
'CON' FIELD SBOOK-CONNID,
'DAY' FIELD SBOOK-FLDATE,
'BOK' FIELD SBOOK-BOOKID.
CALL TRANSACTION 'TCG2'.
The basic list of the program shows fields from the database table SBOOK
according to the user entries on the selection screen. These data are also stored
in the HIDE areas of each line.

If the user selects a line of booking data by double-clicking, the system triggers
the AT LINE-SELECTION event and takes the data stored in the HIDE area to fill
them into the SPA/GPA parameters of the initial screen of Transaction TGC2.
Then it calls the transaction. Since you do not suppress the initial screen using
AND SKIP FIRST SCREEN, the initial screen may appear as follows:

If you would use the AND SKIP FIRST SCREEN option with the CALL
TRANSACTION statement, the second screen would appear immediately, since
all mandatory fields of the first screen are filled.