Syntax Check for GET part three

Previously we have discussed about GET SYNTAX in part ONE and TWO.Here is the continuation for that.

Basic form 3

GET PARAMETER ID key FIELD f.

Effect

Transfers the value stored under the key pid from the global user-related SAP memory memory to the field f .

The key pid must consist of three characters. For an overview of the keys (parameters) used, refer to the SAP system description or the appropriate function in the ABAP/4 Development Workbench.

The return code value is set as follows:

SY-SUBRC = 0 A value was read from SAP memory.

SY_SUBRC = 4 No value was found in SAP memory under the specified key

1. The global user-related SAP memory is available to each user for the entire duration of a terminal session.

For this reason, set values are retained when you leave a program.

2· The SAP memory should not be used for intermediate storage, since a user's parallel sessions use the same global memory.

Example

Read the program name from SAP memory:

DATA : REPID(8).
GET PARAMETER ID 'RID' FIELD REPID.

Basic form 4

GET PROPERTY OF obj p = f.

Addition

... NO FLUSH

Effect

Transfers attribute p of object obj to field f .

Object obj must be of type OLE2_OBJECT .

GET PROPERTY

Addition

... NO FLUSH

Example

Read the attribute 'Visible' of an EXCEL worksheet.

INCLUDE OLE2INCL.
DATA: EXCEL TYPE OLE2_OBJECT,
VISIBLE TYPE I.
CREATE OBJECT EXCEL 'Excel.Application'.
GET PROPERTY OF EXCEL 'Visible' = VISIBLE.

Basic form 5

GET RUN TIME FIELD f.

Effect

Relative runtime in microseconds. The first call sets (initializes) the field f to zero. For each subsequent call, f contains the runtime in microseconds since the first call. The field F should be of type I .

1. If the applications server is a multiple processor, switching the CPU to another processor may lead to fluctuations in the returned runtime. When measuring the runtime of smaller program components, you can achieve the correct result by taking several small measurements.

Example

DATA: T1 TYPE I,
T2 TYPE I,
TMIN TYPE I.
DATA: F1(4000), F2 LIKE F1.
TMIN = 1000000.

DO 10 TIMES.

GET RUN TIME FIELD T1.

MOVE F1 TO F2. "Time measurement of the MOVE statement

GET RUN TIME FIELD T2.
T2 = T2 - T1. IF T2 < tmin =" T2." href="http://abapprogramming.blogspot.com/2008/08/sap-abap-syntax-check-complete.html">

SAP BW Creating info area

The previous topic on SAP BW is regarding its architecture.Here we are going to deal with creation of info area for SAP BW.

In BW, InfoAreas are the branches and nodes of a tree structure. InfoCubes are listed under the branches and nodes. The relationship of InfoAreas to InfoCubes in BW resembles the relationship of directories to files in an operating system. Let's create an InfoArea first, before constructing the InfoCube.
Step 1 After logging on to the BW system, run transaction RSA1, or double-click Administrator Workbench.
Step 2 In the new window, click Data targets under Modelling in the left panel. In the right panel, right-click InfoObjects and select Create InfoArea….

Step 3 Enter a name and a description for the InfoArea, and then click the right mark to continue.

RELATED POSTS

Data ware housing introduction
SAP BW architecture
The previous post of this blog is regarding GET CURSOR SYNTAX.
sap internet transaction architecture
SAP internet transaction application components

Get Curser Syntax check part two

The present post is in continuation with GET CURSER Syntax part one and going through it shall give you more convenience in understanding the present extension.

Here is the continuation for the earlier post .......

Addition 1... OFFSET off

Effect

Copies the position of the cursor within the field to the field off (1st column = 0).

If the cursor is not somewhere within a field ( SY-SUBRC = 4 ), the offset value is set to 0.

Addition 2

... LINE lin

Effect

With step loops, lin contains the number of the loop line where the cursor stands. In list processing, this is the absolute line number (as stored in the system field SY-LILLI ).

Addition 3

... VALUE g

Effect

g contains the value of the field where the cursor stands, always in output format (character display).

Addition 4... LENGTH len

Effect

len contains the output length of the field where the cursor stands.


Variant 2GET CURSOR LINE lin.

AdditionsEffect

As for variant 1 with addition LINE , except that there are differences with the return value and the effect of the additions.

The return code value is set as follows:

SY-SUBRC = 0 The cursor is on one of the list lines (list processing) or on a loop line (step loop).

SY_SUBRC = 4 The cursor is not on one of the list or loop lines.

Addition 1

... OFFSET off

Effect

Applies to list processing only. The field off contains the position of the cursor releative to the beginning of the list line (1st column = 0). With horizontally shifted lists, the offset value can thus be greater than 0, even if the cursor is positioned on the extreme left of the window.

Addition 2

... VALUE g

Effect

List processing only. The field g contains the list line where the cursor is positioned.

Addition 3

... LENGTH len

Effect

List processing only. len contains the length of the line ( LINE-SIZE ).
MySAP environment security solutions
SAP security authentication and authorization
SAP security infrastructure for data production
SAP safety infrastructure

Get Cursor Syntax check

The previous syntax check deals with GET part one and two and it may be a good place to refer once about GET syntax. The present post deals with GET CURSOR.

Variant 1GET CURSOR FIELD f.

Additions
  1. OFFSET off
  2. LINE lin
  3. VALUE g
  4. LENGTH len
EffectTransfers the name of the field at the cursor position to the field f .

The return code value is set as follows:

SY-SUBRC = 0 Cursor was positionedd on a field.

SY_SUBRC = 4 Cursor was not positioned on a field.

Unlike screen processing, list processing allows you to output literals, field symbols, parameters and local variables of subroutines. Literals, local variables and VALUE parameters of subroutines are treated like fields without names (field name SPACE , return value 0).

Otherwise, GET CURSOR FIELD returns only names of global fields, regardless of whether they are addressed directly (i.e. by " WRITE "), by field symbols or by reference parameters.

Example Code:DATA: CURSORFIELD(20),

GLOB_FIELD(20) VALUE 'global field',

REF_PARAMETER(30) VALUE 'parameter by reference',

VAL_PARAMETER(30) VALUE 'parameter by value',

FIELD_SYMBOL(20) VALUE 'field-symbol'.

FIELD-SYMBOLS: .

PERFORM WRITE_LIST USING REF_PARAMETER VAL_PARAMETER.

ASSIGN GLOB_FIELD TO .

AT LINE-SELECTION.

GET CURSOR FIELD CURSORFIELD.

WRITE: / CURSORFIELD, SY-SUBRC.

FORM WRITE_LIST USING RP VALUE(VP).

DATA: LOK_FIELD(20) VALUE 'lokal field'.

ASSIGN FIELD_SYMBOL TO .

WRITE: / GLOB_FIELD, / LOK_FIELD,

/ RP, / VP,

/ 'literal', / FIELD_SYMBOL.

ENDFORM.

When you double-click on the word " global field ", CURSORFIELD contains the field name GLOB_FIELD , on " parameter by reference " the field name REF_PARAMETER , on " field symbol " the field name FIELD_SYMBOL , and on " local field ", " parameter by value " and " literal " the value SPACE .

You can go through the complete ABAP Syntax check here.



SAP authorization and client administration in mysap.com

IMPORT BADI - Procedure

Conflicts can occur at release upgrade or when transporting a Business Add-In within a system infrastructure containing multiple levels (country versions, industry solutions, partners, etc.).

Possible collisions include:

.......................................................................................................................

Whenever such collisions occur, corresponding error messages and warnings are created in the transport log at import. Their long texts provide you with information on how to proceed.

If the collision described in case 1 occurs in your system, proceed as follows:

1. Choose Utilities ® Adjustment ® Multiple active implementations (in transaction SE18).A list appears displaying your Business Add-Ins. A red traffic light indicates that multiple active implementations exist for that add-in.

2. Deactivate these implementations using the appropriate pushbutton or double-click on the name of the implementation to branch to the corresponding transaction where you can then correct the problem .

In cases 2 and 3, proceed as follows:

1. Choose Utilities ® Adjustment ® Multiple assigned interfaces or Multiple function codes assigned.

Both of these menu options display an overview; the add-ins in question are marked with a red traffic light.

2. The people responsible for those add-in definitions where identical interfaces and function codes occur must now decide how to proceed. To delete a function code or change an interface name, call the ABAP Workbench and use the appropriate pushbutton to call the tool you need. A new transport may be necessary.

The previous post of the topic is regarding screen enhancements implementation using BADI.
SAP Authorization and ALE
Authorization and implementation of SAP
Mysap market place introduction

badi screen enhancements implementation

The present post is in continuation with BADI SCREEN ENHANCEMENTS DEFINITION. Going through that post will give you more convenience and comfort in following this topic.

Here is the way of implementing SCREEN ENHANCEMENTS using BADI.

The user of the screen enhancement should perform the following steps:

1. Create a screen of the Sub screen type. Arrange the required fields on the screen.

2. Write the program for the screen by creating either a module pool or a function group. The program could have the following contents,

for example:

Top Include:

DATA: exit TYPE REF TO if_ex_badi_screen,

flight TYPE sflight.

TABLES sflview.

PBO:

MODULE status_0100 OUTPUT.

IF exit IS INITIAL.

CALL METHOD cl_exithandler=>get_instance_for_subscreens

CHANGING

instance = exit

EXCEPTIONS

OTHERS = 6.

...

ENDIF.

CALL METHOD exit->get_data_from_screen

IMPORTING

flight = flight

EXCEPTIONS

reserved = 1

OTHERS = 2.

...

SELECT SINGLE * FROM sflview

WHERE carrid = flight-carrid AND

connid = flight-connid AND

fldate = flight-fldate.

..

ENDMODULE.

PAI:

If data has been changed, the method PUT_DATA_TO_SCREEN is called at PAI.

MODULE user_command_0100 INPUT.

CALL METHOD exit->put_data_to_screen

EXPORTING

flight = flight

EXCEPTIONS

reserved = 1

OTHERS = 2.

IF sy-subrc <> 0.
...
ENDMODULE.

3. Choose the Subscreens tab. Enter the name of the called program and of the subscreen.

4. Choose the Interfaces tab.

If required, add any lines necessary to the sample code.


You can go through entire BADI COURSE HERE.

Authorization and implementation of SAP

Syntax check for Get part two

This syntax check for get is in continuation with GET SYNTAX PART ONE.

Addition 2

... FIELDS f1 ... fn

Effect

Performance option. Addresses only the fields f1, ..., fn of the tabelle dbtab (also possible with a dynamic ASSIGN ). Since only these fields have to be assigned values by the logical database, this can improve performance considerably.

The addition (for GET dbtab or GET dbtab LATE ) is allowed only for tables intended for field selection by the logical database (SELECTION-SCREEN FIELD SELECTION FOR TABLE btab ).
When executing the events GET dbtab , GET dbtab LATE or GET dbtab_2 for a subordinate table dbtab_2 in the database hierarchy, the contents of all all fields of dbtab apart from f1, ..., fn are undefined.

If both GET dbtab FIELDS f1 ...fn and GET dbtab LATE FIELDS g1 ...gm occur in the program, values are assigned to all the fields f1, ..., fn, g1, ..., gm .

In addition to the specified fields, values are also assigned to the key fields of dbtab .

If you use the FIELDS addition, you access only the specified fields. Any external PERFORM calls should be taken into account here.

A special rule applies for tables which are intended for field selection by the logical database, for which neither a GET dbtab nor a GET dbtab LATE event exists in the program, yet for which there is a subordinate table dbtab_2 with GET dbtab_2 or GET dbtab_2 LATE in the program.
If the table is declared with TABLES dbtab in the program, the work area of dbtab exists for GET dbtab_2 or GET dbtab_2 LATE and is can therfore receive values. Also, if a restricted field selection is sufficient for dbtab , you can achieve this with a GET dbtab FIELDS f1 ... fn statement (without subsequent processing).

If the program contains no TABLES dbtab statement, the system assumes no access to the work area of dbtab . In this case, therefore, only the key fields of dbatab are assigned values. If, however, you want to fill the work area of dbtab completely (e.g. for an external PERFORM call), you must include the TABLES dbtab statement in the program.

The field lists are made available to the report and the logical database in an internal table SELECT_FIELDS .

The exact definition of the object SELECT_FIELDS is stored in the TYPE-POOL RSFS and reads:

TYPES: BEGIN OF RSFS_TAB_FIELDS,
TABLENAME LIKE RSDSTABS-PRIM_TAB,
FIELDS LIKE RSFS_STRUC OCCURS 10,
END OF RSFS_TAB_FIELDS.
...

TYPES: RSFS_FIELDS TYPE RSFS_TAB_FIELDS OCCURS 10.
DATA SELECT_FIELDS TYPE RSFS_FIELDS.

SELECT_FIELDS is thus an internal table. Each line of this internal table contains a table name ( TABLENAME ) and another internal table ( FIELDS ) which contains the desired table fields ( TABLENAME ).

Neither the TYPE-POOL RSFS nor the declaration of SELECT_FIELDS have to be in the report. Both are automatically included by the system, if required. If, for some reason, you need to assign values to more fields, you can manipulate this table under INITIALIZATION or START-OF-SELECTION .

Examples

Specify the necessary fields under GET . Both SFLIGHT and SBOOK must be defined for field selection.

TABLES: SFLIGHT, SBOOK.
GET SFLIGHT FIELDS CARRID CONNID FLDATE
PLANETYPE.
WRITE: SFLIGHT-CARRID,
SFLIGHT-CONNID,
SFLIGHT-FLDATE,
SFLIGHT-PLANETYPE.
GET SBOOK FIELDS BOOKID CUSTOMID ORDER_DATE.
WRITE: SBOOK-BOOKID,
SBOOK-CUSTOMID,
SBOOK-ORDER_DATE.

In the above 'smoker' example, you can also specify the required SFLIGHT fields under 'GET SFLIGHT LATE':

TABLES: SFLIGHT, SBOOK.
DATA SMOKERS TYPE I.
GET SFLIGHT.
ULINE.
WRITE: / SFLIGHT-SEATSMAX,
SFLIGHT-SEATSOCC.
SMOKERS = 0.
GET SBOOK FIELDS SMOKER.
CHECK SBOOK-SMOKER <> SPACE.
ADD 1 TO SMOKERS.
GET SFLIGHT LATE FIELDS SEATSMAX SEATSOCC.
WRITE SMOKERS.

Only fields from SBOOK are output. No TABLES SFLIGHT statement exists. Then, for the table SFLIGHT , only the key fields are read (regardless of whether the FIELDS addition is used with GET SBOOK or not).

TABLES: SBOOK.
GET SBOOK FIELDS BOOKID CUSTOMID ORDER_DATE.
ITE: SBOOK-BOOKID,
SBOOK-CUSTOMID,
SBOOK-ORDER_DATE.

Only fields from SBOOK are output, but SFLIGHT is declared by TABLES SFLIGHT . In this case, all the fields of table SFLIGHT are read (regardless of whether the FIELDS addition is used with GET SBOOK or not).

TABLES: SFLIGHT, SBOOK.
GET SBOOK FIELDS BOOKID CUSTOMID
ORDER_DATE.
WRITE: SBOOK-BOOKID,
SBOOK-CUSTOMID,
SBOOK-ORDER_DATE.

You can go through entire SYNTAX CHECK here.


 SAP Project design look and feel
My SAP Project safety and security

SAP ABAP SYNTAX FOR GET

The previous post regarding SAP abap syntax is regarding GENERATE and you can browse it if you are interested.

Basic form

GET dbtab.

Additions

1. ... LATE
2. ... FIELDS f1 ... fn

Effect

Processing event.

Gets the table dbtab for processing while the logical database is running. You can address all the fields from dbtab in the subsequent processing. You can also refer to fields from tables in the logical database on the access path to the table dbtab .

Note

You can use the event " GET dbtab. " only once in the report.

Example

The program uses the logical database F1S which has a structure where the table BOOKING appears below the table FLIGHT .

TABLES: SFLIGHT, SBOOK.

GET SFLIGHT.

WRITE: SFLIGHT-CARRID,

SFLIGHT-CONNID,

SLFIGHT-FLDATE,

SFLIGHT-PLANETYPE.

GET SBOOK.

WRITE: SBOOK-BOOKID,

SBOOK-CUSTOMID,

SBOOK-ORDER_DATE.

Addition 1

... LATE.

Effect

Executes the code following " GET dbtab LATE. " only when all the subordinate tables have been read and processed.

Example

Count the smokers among the bookings already made.

TABLES: SFLIGHT, SBOOK.

DATA SMOKERS TYPE I.

GET SFLIGHT.

ULINE.

WRITE: / SFLIGHT-SEATSMAX,

SFLIGHT-SEATSOCC.

SMOKERS = 0.

GET SBOOK.

CHECK SBOOK-SMOKER <> SPACE.

ADD 1 TO SMOKERS.

GET FLIGHT LATE.

WRITE SMOKERS.

ERP Master data and data warehouse concept

abap sales order management business process

ABAP BADI SCREEN ENHANCEMENTS DEFINATION

This topic is in continuation with ABAP BADI SCREEN ENHANCEMENTS PART .It will be more convenient to if you go through that first if you are new to this blog.

Here is the step by step procedure for screen enhancement definitions using BADI .

1. Create the following methods.

The methods PUT_DATA_TO_SCREEN and GET_DATA_FROM_SCREEN are required for data transport. These methods are called from within the program of the application at PBO or PAI .

Here is the screen shot for defining the methods mentioned above and you can click it for enlarging.


2. Create an instance attribute in the interface. This attribute is used for passing data.


3. Write the code for the call of the screen enhancement in the program of the application:

Top Include:

DATA: program Type program,
dynpro Type dynnr.
exit type ref to if_ex_badi_screen
The variable for the object reference is created using data and typed to the interface.

PBO:

MODULE initialize OUTPUT.
CLEAR: sflight, ok_code.
IF exit IS INITIAL.
CALL METHOD cl_exithandler=>get_instance
CHANGING
instance = exit.
ENDIF.
CALL METHOD cl_exithandler=>set_instance_for_subscreen
EXPORTING
instance = exit.
ENDMODULE.

The factory method is used to create an instance of the adapter class. You then declare the instance using the public static method SET_INSTANCE_FOR_SUBSCREEN to allow the data for display on the screen to be used in the function group of the user or in the module pool.

MODULE data_for_subscreen OUTPUT.

program = sy-repid.
dynpro = sy-dynnr.
CALL METHOD cl_exithandler=>get_prog_and_dynp_for_subscr
EXPORTING
exit_name = 'BADI_SCREEN'
calling_program = program
calling_dynpro = dynpro
subscreen_area = 'SUB'
IMPORTING
called_program = program
called_dynpro = dynpro.
CALL METHOD exit->put_data_to_screen
EXPORTING
flight = sflight
EXCEPTIONS
reserved = 01.
ENDMODULE.

PAI:

MODULE user_command_0200 INPUT.
CASE save_ok.
WHEN 'BACK'.
SET SCREEN 100.
WHEN 'SAVE'.
PERFORM save_flights.
WHEN '+EXT'.
CALL METHOD exit->get_data_from_screen
IMPORTING
flight = sflight
EXCEPTIONS
reserved = 01.
ENDCASE.
ENDMODULE.

The method GET_PROG_AND_DYNP_FOR_SUBSCR and the input/output parameters specified above are used to determine the name of the customer program and the name of the subscreen. The method PUT_DATA_TO_SCREEN which is called at PBO as well as the method GET_DATA_FROM_SCREEN which is called at PAI are used to transport the data to be displayed.

These methods are implemented by the user:

When you define a screen enhancement, you are strongly recommended to provide sample code for the methods PUT_DATA_TO_SCREEN and GET_DATA_FROM_SCREEN. This code is automatically copied when you create an implementation and can be added to if required. The user of the BAdI definition should not be responsible for the data transport.

Y

Billing and payment process in erp sap abap