Archive for the 'ABAP' Category

SAP: How to use Lock Objects in ABAP

Published
by
rs
on March 23, 2009
in ABAP, BASIS, SAP and Technical
. 2 Comments

Let say we have a customized table ZCUST_INFO that holds a specific customer information with MANDT(client number) and KUNNR(customer number) as the key field.

So let’s create a Lock Object for our customized table:
1. Go to transaction SE11
2. Click on Lock Object radio button and type-in EZCUST_INFO on name field and click on create button.
3. On Tables Tab, type-in ZCUST_INFO on name field and choose Write Lock on Lock Mode.
4. Go to Lock Parameter Tab and on the first row, type-in mandt on lock parameter, zcust_info on
table, and mandt on field.
5. On second row, type-in custnum on lock parameter, zcust_info on table, and kunnr on field.
6. Click save and activate.

Now let say we also have a dialog program for managing this the content of this table. We have screen 100 for our selection screen with customer number as selection parameter, screen 200 for editing screen, and screen 300 for display screen.

On the PBO of screen 200, let’s add the code below.

  CALL FUNCTION ‘ENQUEUE_EZCUST_INFO’
    EXPORTING
    MODE_ZCUST_INFO = ‘X’
    MANDT = sy-mandt
    CUSTNUM = <customer number from screen 100>
  EXCEPTIONS
    FOREIGN_LOCK = 1
    SYSTEM_FAILURE = 2
    OTHERS = 3.
  IF sy-subrc = 1.
    MESSAGE ‘This record is currently locked by another user!’ type ‘I’.
leave to screen 300.
  ENDIF.

The code above will request for lock on the table zcust_info specifically on the record specified on
the mandt and custnum parameter. If the record is already locked by another user, the user will be
prompted and will be redirected to screen 300 which is the display screen.

Lastly, on the PAI of screen 200, add the code below to release and unlock the object queued on the PBO:

  CALL FUNCTION ‘DEQUEUE_EZCUST_INFO’
    EXPORTING
    MODE_ZCUST_INFO = ‘X’
    MANDT = sy-mandt
    CUSTNUM = <customer number from screen 100>
  EXCEPTIONS
    FOREIGN_LOCK = 1
    SYSTEM_FAILURE = 2
    OTHERS = 3.

SAP: Changing ALV Row Color

Published
by
rs
on March 19, 2009
in ABAP, ALV, SAP and Technical
. 1 Comment

Changing the color of an ALV row is very simple. First you have to add a field on your internal table that will holds the color attribute (Refer to the sample code below).

TYPES: BEGIN OF t_rowcolor,
column1 TYPE string,
column2 TYPE string,
column3 TYPE string,
rowcolor(4) TYPE c,
END OF t_rowcolor.

DATA:  it_rowcolor TYPE STANDARD TABLE OF t_rowcolor,
wa_rowcolor TYPE t_rowcolor.

Next step is to Set the layout field for color attributes. In our case, that field is “rowcolor” (Refer to the sample code below).

DATA: gd_layout TYPE slis_layout_alv.

gd_layout-info_fieldname = ‘ROWCOLOR’.

Lastly, you have to populate the rowcolor field with the color attributes of your choice. You can do this when you loop at your internal table into your work area table (Refer to the sample code below).

LOOP AT it_row INTO wa_row.
wa_row-rowcolor = ‘C100′
MODIFY it_row FROM wa_row.
ENDLOOP.

In the code above, ‘C100′ is the color attribute. For the complete list of different color attributes, please refer to the figure below.

ALV color attributes

SAP: How to Create and Use the Authorization Objects in ABAP

Published
by
rs
on March 16, 2009
in ABAP, Authorization, BASIS, SAP and Technical
. 4 Comments

Authorization Objects are used to manipulate the current user’s privileges for specific data selection and activities from within a program.

We could always create our own authorization objects and implement it in our own abap programs. As an example, we will create our own authorization field similar to TCD used in S_TCODE Authorization object (see #3 in figure 1).

Figure 1
Figure 1

Steps to create authorization field
1. Go to transaction code SU20
2. Click the create new button on the application toolbar.
3. Enter “ZTCODE” in the Field Name and “TCODE” in the Data Element, then hit Enter.
4. Click the save button on the system toolbar.

Next step is to create the authorization class(see #1 in figure 1) and authorization object(see #2 in figure 1).

Steps to create authorization class
1. Go to transaction code SU21
2. Click on the Create button’s drop down icon and select “Object Class”.
3. Enter “ZTRN” on the Object Class field.
4. Give it a description and save it.

Steps to create authorization object
1. Again in SU21, in the list of authorization class(folder icon), click the one that we’ve created(ZTRN).
2. Click on the Create buttodrop down, this time selecting “Authorization Object”.
3. Enter “Z_TCODE” on the Object field and give it a description.
4. On the authorization fields section, enter ACTVT and ZTCODE. ACTVT is used to set and limit the activity of the user, while the ZTCODE is the authorization field that we’ve created earlier which is
responsible for holding a list of tcodes.
5. On the Further Authorization Object Settings, click on “Permitted activities” button. Here we will select the specific activities that we want to be available for our authorization object.
6. As an example, we will select 01(Create), 02(Change), and 03(Display).
7. Save and Exit.

Now we’re done creating our own authorization object, let us now use and assign it to a user.

Steps to create a role(see figure 2)
1. Go to transaction code PFCG.
2. Enter “ZAUTHTEST” on Role field and click the “Single Role” button.
3. Now give it a description, click the save button and click the Authorization tab.
4. Click the “Change Authorization Data” button inside the authorization tab.
5. Then click the “Manually” button on the application toolbar and type in the name of the authorization object that we’ve created earlier(”Z_TCODE”) and press enter.
6. Expand all the nodes, double click on the input field of the Activity and select activity 01 and 02.
7. Enter the tcode of our own abap program in ZTCODE field, in our example I used “ZCOMM” .
8. And also don’t forget to add the S_TCODE authorization object and enter ZCOMM on it’s field.
9. Now Click on the Generate button in the application toolbar and press enter on the pop-up screen.
10. press the back button and assign a specific user on the user tab and click User Comparison button.
11. Now create another role by repeating steps 1 to 9 but this time select activity 03 on step 6.
12. Then assign this 2nd role to another user.

Figure 2
Figure 2

Now let’s implement this authorization in our ABAP program. Let say we have a dialog program(ZCOMM) wherein we have a button on the screen that when clicked, the user will go to the Create/Edit screen(1000) if he’s authorized. On the other hand, he will go to display only screen(2000) if he’s not authorized. To do that, simply add the code below on your program.

  AUTHORITY-CHECK OBJECT ‘Z_TCODE’    “authorization object that we’ve created
      ID ‘ACTVT’ FIELD ‘01′                        “Activity = 01, authorized to create
      ID ‘ZTCODE’ FIELD ‘ZCOMM’.            “tcodes that we wants to check for authorization
  IF sy-subrc EQ 0.
      CALL SCREEN 1000.        “The user is authorized to create
  ELSE.
      CALL SCREEN 2000.        “User is not authorized to create (Display only)
  ENDIF.

SAP: ALV Auto Refresh through Function Module

Published
by
rs
on February 25, 2009
in ABAP, ALV, SAP and Technical
. 2 Comments

I created a simple ALV report displaying the data of my customized table through Function Module REUSE_ALV_GRID_DISPLAY. I also created a screen for the details view when you double click on a record from ALV. On this screen you could change the record details as you want and save it. When the user clicked on the save button, he will be automatically return to the ALV screen.

Now, what I want is when the user returns back from details view to ALV screen, I want the ALV to refresh automatically without clicking the refresh button on the application toolbar.

When I googled for the solution, I mostly came up with OOP(Object Oriented Programming) codes, wherein you declare an object with reference to the CL_GUI_ALV_GRID to create an ALV. In my case this is not applicable since I’ve already started my ALV code through function module. Fortunately I stumbled upon http://www.sap-basis-abap.com/abap/auto-refresh-alv-list.htm that provides a simple code for ALV auto refresh every 5 seconds.

In my case, I only have to add a a single line of codes in the form i used for the i_callback_user_command parameter of the REUSE_ALV_GRID_DISPLAY function module.

Below is my code for calling the REUSE_ALV_GRID_DISPLAY function module.

CALL FUNCTION ‘REUSE_ALV_GRID_DISPLAY’
  EXPORTING
    i_callback_program = gd_repid
    i_callback_pf_status_set = ‘F_STATUS’
    i_callback_user_command = ‘F_USER_COMMAND’
    is_layout = ls_layout
    it_fieldcat = lt_fieldcat
    i_callback_top_of_page = ‘TOP_OF_PAGE’
  it_sort = lt_sort
  TABLES
    t_outtab = it_comm.

And below is the code for the form F_USER_COMMAND:

FORM f_user_command USING UCOMM LIKE SY-UCOMM v_selfld TYPE slis_selfield.

  some codes here for processing the user command

  PERFORM f_get_data. “codes for retrieving data for ALV

  v_selfld-refresh = ‘X’. “codes I added for auto refresh

ENDFORM.

SAP: Selection-Screen as subscreen in dialog programming

Published
by
rs
on February 9, 2009
in ABAP, Dialog, SAP and Technical
. 0 Comments

There would be a time that you will have a certain selection-screen that is being used in more than one dynpro in your program. Instead of coding it for each dynpro, you could just create a subscreen on every dynpro and call the same selection-screen. In this way, you only have one code block for your selection-screen but able to display it on any dynpro you want within your program.

To do this, first create a subscreen area through the screen painter. As an example, let’s name this subscreen area as SUB_1. Now let say we want to call the selection-screen below into our subscreen area SUB_101.

  SELECTION-SCREEN BEGIN OF SCREEN 101 AS SUBSCREEN.
    SELECT-OPTIONS: p_comp FOR bseg-bukrs OBLIGATORY,
    p_cust FOR kna1-kunnr.
  SELECTION-SCREEN END OF SCREEN 101.

When calling a subscreen, we must call it in both the PBO and PAI sections of the flow logic of our main screen. The CALL SUBSCREEN statement tells the system to execute the PBO and PAI processing blocks for the subscreen as components of the PBO and PAI of the main screen. Please Refer to the code below.

  PROCESS BEFORE OUTPUT.
    MODULE STATUS_100.
    CALL SUBSCREEN SUB_101 INCLUDING sy-repid ‘101′.

  PROCESS AFTER INPUT.
    CALL SUBSCREEN SUB_1.
    MODULE USER_COMMAND_100.

SAP: Setting Attributes of Screen Objects Dynamically

Published
by
rs
on February 7, 2009
in ABAP, Dialog, SAP and Technical
. 0 Comments

In visual basic, you could easily change any property of a specific control dynamically. We could also do that in ABAP. The sample code below will show you the basics on how to loop on all objects in a screen and change its property at runtime.

Let say we have a set of textbox in our screen that contains details of a single customer from table KNA1(General Data in Customer Master). Now we want to disable all textboxes that has already a value on it so that empty textboxes are the only editable field in the screen. To do this, we need to create a code on PBO(Process Before Output) module that will loop on all objects in the screen.

But before we proceed with the coding, we have to specify a MODIF ID or Modification Group ID. This will enable us to modify object before the selection screen is displayed, using the statement MODIFY SCREEN. The name of the modification group ID must be directly specified and can have a maximum length of three characters. There are two ways to set the mod ID of an object.

One is through code:

PARAMETERS: p_sample TYPE c LENGTH 10 MODIF ID GR1.

In this sample code, we set the mod ID of p_sample to “GR1″

Another way is through screen painter:

On the screen painter, select a specific object on the screen and then go to its attributes(double click or press F2). A window will appear showing the attributes of the object. You will see 4 textboxes in a row which is indicated as Groups. Type-in GR1 in the first textbox. Close the attributes window and click save.

We could now create the codes that will loop on all objects in a screen. In our case, we only want to loop on all textboxes in a screen so set the mod ID of all textboxes to GR1.

FIELD-SYMBOLS : <FS> TYPE ANY.

LOOP AT SCREEN.
  IF SCREEN-GROUP1 = ‘GR1′.
    ASSIGN (SCREEN-NAME) TO <FS>.
    IF <FS> IS NOT INITIAL.
      SCREEN-INPUT    = ‘0′.
    ENDIF.
  ENDIF.
  MODIFY SCREEN.
ENDLOOP.

Using the code above, one loop pass is executed for every screen element of the current dynpro. SCREEN-NAME is the name of the element, SCREEN-GROUP1 refers to the modification group of the element, and SCREEN-INPUT is the input property of the element. MODIFY SCREEN affects the attributes input, output and invisible.

The table below shows the components of screen and their assignment to the field properties in the dynpro.

Component

Length

Type

Meaning

Attribute

name

132

C

Name of the screen field

Name

group1

3

C

Modification group 1

Group 1

group2

3

C

Modification group 2

Group2

group3

3

C

Modification group 3

Group3

group4

3

C

Modification group 4

Group4

required

1

C

Field input is mandatory

Mandatory field

input

1

C

Field is ready for input

Entry

output

1

C

Field is for display only

The output is as follows:

intensified

1

C

Field is highlighted

Highlighted

invisible

1

C

Field is suppressed

Invisible

length

1

X

Field length

VisLg

active

1

C

Field is active

Input/Output/Invisible

display_3d

1

C

Three-dimensional box

Two-dimensional

value_help

1

C

Input help button display

Input helps

request

1

C

Input exists

-