Field Catalog Options In ALV

Field catalog options :

FIELDNAME:
    You use this field to assign a field name of your output table to a row of the field catalog. All settings that you make in this row refer to the corresponding column of the output table.
REF_FIELD:
You must fill this field if:
• the output table field described by the current entry in the field catalog has a corresponding field in the Data Dictionary and
• the field name in the output table is not identical to the field name of the field in the Data Dictionary.
If the field names are identical, it is sufficient to specify the DDIC structure or table in field REF_TABLE of the field catalog.
REF_TABLE:
You must fill this field only if the output table field described by the current entry in the field catalog has a corresponding entry in the Data Dictionary. Using this assignment, the ALV Grid Control can copy the text for the column header from the Dictionary.
CHECKBOX:
Outputting a checkbox. The checkbox cannot be modified by the user.
COL_POS:
Relevant only if the relative column positions should not be identical to the sequence of fields in the field catalog when the list is displayed for the first time. The parameter determines the relative column position of the field for list output. The user can interactively modify the order of the columns. If this parameter is initial for each field catalog entry, the order of the columns corresponds to the sequence of fields in the field catalog.
DO_SUM:
If this field is set, the ALV uses this field to calculate the total (this corresponds to the generic totals function in the toolbar.)
EMPHASIZE:
If the field is set to 'X', the ALV uses a pre-defined color for highlighting the column. If it is set to 'Cxyz' (color code), the remaining numbers have the following meaning:
• x: color number
• y: intensified display on/off
• z: inverse display on/off
HOTSPOT:
If this field is set, all cells of this column are hotspot-sensitive.
HREF_HNDL:
Handle to which an URL is assigned. The ALV Grid Control displays all cells of the column as hyperlinks. You must maintain the target address of the hyperlink in a table of type LVC_T_HYPE and pass it using set_table_for_first_display.
KEY:
If this field is set, the ALV Grid Control color-codes the column as a
key field and fixes this column during horizontal scrolling. The order of the key columns in the ALV Grid Control can be modified interactively. In contrast to the SAP List Viewer, the ALV Grid Control allows you to directly hide key columns with NO_OUT
LOWERCASE:
If this field is set, the ALV Grid Control recognizes upper/lower case in the output table. This affects the sorting of fields, for example.
NO_OUT:
If you set this field, you hide the relevant column in the list. Nevertheless, the column is available in the field selection and can be interactively selected by the user as a display field. The ALV displays the contents of hidden fields on the detail screen for a row in the grid control.
NO_MERGING:
If this field is set, cells with the same value are not merged into a single cell when this column is sorted.
NO_SUM:
If you set this field, you lock totals calculation for the relevant field.
OUTPUTLEN:
Determines the column width of the field:
• If the field has a reference to the Data Dictionary, you can leave the field set to its initial value. In this case, the ALV adopts the output length of the relevant domain.
• For fields without reference to the DDIC, you must specify the desired field output length.
STYLE:
Displays all cells of this column with a style e.g. as pushbuttons. Constants "MC_STYLE..." of the class "cl_gui_alv_grid" can be passed to this field.
TECH:
If this field is set, the relevant field is not displayed on the list and cannot be shown interactively. The field is only known in the field catalog. (For example, it must not be specified as a sorting criterion).
DECIMALS_O:
If a field has no currency, then you can use this field to determine the number of decimal places to be displayed. This setting is kept even if you afterwards assign a currency field to this field or assign a currency to the CURRENCY field of the field catalog.
DECMFIELD:
Defining the digits after the comma on a row-by-row basis. You can use an additional field in the output table to determine how many digits are to be displayed after the comma in each row.
EDIT_MASK:
If you set a conversion exit (for example, conv = ' ==ALPHA ' for function module CONVERSION_EXIT_ALPHA_OUTPUT ), you enforce output conversion for the associated output field.
ICON:
If this field is set, the column contents of the output table are output as an icon. The column contents must consist of valid icon strings (  (xx) or @xx\Q <Quickinfo> @ ). You should consider the problem of printing icons.
JUST:
Relevant only to fields of data type CHAR or NUMC. Justifications:
• 'R': right justified
• 'L': left justified
• 'C': centered
How the column header is justified, depends on how the column contents are justified. You cannot justify the column header separately.
LZERO:
Relevant only to fields of data type NUMC. In the default setting, the
ALV Grid Control displays these fields right justified without leading zeros. If you set LZERO, leading zeros are displayed.
NO_SIGN:
Relevant only to value fields. If you set NO-SIGN, values are displayed without signs.
NO_ZERO:
If NO_ZERO is set, no zeros are displayed for initial value fields. The cell remains empty.
COLDDICTXT:
Relevant only to fields with reference to the Data Dictionary. You use values 'L', 'M', 'S' or 'R' to determine if SCRTEXT_L, SCRTEXT_M, SCRTEXT_S or REPTEXT is used as the column header.
COLTEXT:
Determines the column header of the column. You should assign a value to this field if it does not have a Data Dictionary reference.
REPTEXT:
Relevant only to fields with reference to the Data Dictionary. For such fields, the ALV Grid Control copies the field label for the header of the corresponding data element into this field.
SCRTEXT_L:
Relevant only to fields with reference to the Data Dictionary. For such fields, the ALV Grid Control copies the long field label of the corresponding data element into this field.
SCRTEXT_M:
Relevant only to fields with reference to the Data Dictionary. For such fields, the ALV Grid Control copies the medium field label of the corresponding data element into this field.
SCRTEXT_S:
Relevant only to fields with reference to the Data Dictionary. For such fields, the ALV Grid Control copies the short field label of the corresponding data element into this field.
SELDDICTXT:
Relevant only to fields with reference to the Data Dictionary. You use values 'L', 'M', 'S' or 'R' to determine if SCRTEXT_L, SCRTEXT_M, SCRTEXT_S or REPTEXT is used as the text for column selection.
SELTEXT:
Determines the text to be used in the column selection for the column. You should assign a value to this field if it does not have a Data Dictionary reference.
TIPDDICTXT:
Relevant only to fields with reference to the Data Dictionary. You use values 'L', 'M', 'S' or 'R' to determine if SCRTEXT_L, SCRTEXT_M, SCRTEXT_S or REPTEXT is used as the tool tip.
TOOLTIP:
Determines the text to be used as the tool tip for the column. You should assign a value to this field if it does not have a Data Dictionary reference.

Remote ABAP debugging

Remote ABAP debugging: 

Scenario:  

When I initially started working on Integration tools like Business Connector/.Net connectors/XI, I always wondered how to debug the process in the backend SAP R/3 system when I make an RFC call. Because when we call any SAP RFC function module from any integration tool, it will be processed on any available application server in the backend, where a user breakpoint cannot be triggered to debug the ABAP code in the backend system. The situation becomes worst to the developers/testers when they want to test the scenarios like HTTP-XI-RFC, HTTP-XI-PROXY, and FTP-XI-RFC so on. But we have a simple solution to debug the ABAP code when we are working on Remote function calls.

PRE-REQUISITE:  

• The backend SAP system should be ECC 6.0 with latest patch updates.
• It is assumed that user has developed a simple scenario HTTP-XI-PROXY/HTTP-XI-RFC or any similar scenario where XI makes an RFC or Proxy call to SAP R/3 system. 

When developing the scenario, in the integration directory configuration, while creating the Receiver communication channel with RFC adapter or Proxy Adapter user has to use own SAP R/3 user id/password as authentication parameters with which user wants to login to the SAP system to debug the code. i.e. the same user id has to use to log in the sap system to set the breakpoint in the ABAP Code.

SOLUTION:

Log in to the sap system where RFC function module or Proxy class implemented.  

Open the Function module/ Proxy class and set a break-point. It is not mandatory that break-point has to set only at the initial line of the code; the user can set anywhere in the entire code, which will be executed on RFC call.  

Execute the transaction code “SRDEBUG” (Note: this tcode is available only in latest ECC 6.0 system)  

Click on the button Activate Debugging. A pop-up screen will be opened. Fill the User-ID with which break-point has been set. (The same user-id should be used as authentication data in the XI while creating RFC communication channel).  Select the radio buttons “all Appl. Servers” and “External break points already set”. Click on OK. 

Another pop-up will be opened with a message “End debugging?” Leave the pop-up as it is. (Don’t close the transaction).  

Now start sending a message from HTTP client. When the message arrives in SAP R/3 system, a debug session will be started from the point where the user kept the break-point in the step-2. From this point, the user can start debugging the code as usual.

Thus, concluding setup of Remote ABAP debugging.

SAP ABAP TIPS:

SAP ABAP TIPS:

There is a very interesting function module, with the help of which you can send the pop-up messages to the users/friends who are logged into the SAP system.

The interesting function module name is ‘TH_POPUP’.

For this, you and your friend should be logged on into the SAP system and you must know the SAP user id of your friend to whom you are going to send the message.

Please go through this and enjoy chatting with your friends while working on SAP system.

STEPS :

1.     Go to transaction SE37 and enter the function module name TH_POPUP.

2.     Pass the client, user name and the message which you want to send and execute the function module.

Output :

The pop up will appear to the user/friend’s SAP system.

Note - if the user has logged on multiple systems then the message will be sent to multiple systems.

Script,Smartform,Adobe Form Differentiation

	What would(should) I use?
What is the requirement?	SAPScript	SmartForms	Adobe
Complex drawing of lines and boxes (static and dynamic)	No This is a messy work and take a lot of time	Yes, you got a good support	Absolutely yes!
Label printing	Yes, just depends how complex it is	Yes	Yes, but it will take some time to understand the concept
Graphics without converting or SE78-uploads (BMP, JPEG, GIF, PNG, EXIF)	No	No	Yes
A lot of different TrueType fonts using in one font (not Helve and Courier  )	Yes, but not recommended	Yes, but not recommended	Yes
Systembarcodes (that means you do not need a barcode-module	Yes, also here, have a look at SAP-OSS 1558595	Yes	Yes
Interactive scenarios	No, not possibleat all	No, not possible at all	Yes (who would have thought  )
Colored Fonts	No, not possible without using the backdoor	Yes	Yes
How fast can I  find a mistake?	fast	Fast to slow, it really depends on the delivered quality	Fast, but you might end in trouble when you love to code inside your form
What do you need to know	ABAP	ABAP	ABAP + JavaScript / FormCalc, at least you need one of the additional

Smartforms OOPS (object oriented)

Here is a step by step sample of a pick list printed from a warehouse transfer order.

STEP 1 – Create class to collect data

CLASS ztestclass_pick_list DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    DATA:
      g_lgnum   TYPE lgnum,
      g_ltak    TYPE ltak,
      gi_ltap   TYPE SORTED TABLE OF ltap WITH UNIQUE DEFAULT KEY,
      g_vbeln   TYPE vbeln,
      g_company TYPE char15.

    METHODS constructor
      IMPORTING
        lgnum TYPE lgnum
        tanum TYPE tanum.

  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.


CLASS ZTESTCLASS_PICK_LIST IMPLEMENTATION.


* <SIGNATURE>------------------------------------------------------------+
* | Instance Public Method ZTESTCLASS_PICK_LIST->CONSTRUCTOR
* +----------------------------------------------------------------------+
* | [--->] LGNUM                          TYPE        LGNUM
* | [--->] TANUM                          TYPE        TANUM
* +-----------------------------------------------------------</SIGNATURE>
  METHOD constructor.
    " Select TO header
    SELECT SINGLE * FROM ltak
      WHERE lgnum = @lgnum
      AND tanum = @tanum
      INTO @g_ltak.

    IF sy-subrc = 0.
      " Select TO line
      SELECT * FROM ltap
        WHERE lgnum = @lgnum
        AND tanum = @tanum
        INTO TABLE @gi_ltap.

      "Populate stand alone attributes from various sources
      g_lgnum = lgnum.
      g_vbeln = g_ltak-vbeln.
      g_company = 'ACME WIDGET Co'.
    ELSE.
      " Raise error here
    ENDIF.
  ENDMETHOD.
ENDCLASS.

In this class declare public attributes for the data that you will be retrieving from the SmartForm. In this example, I will be retrieving the Transfer Order number, a Company name and Transfer Order Item details.

Step 2 – Create the SmartForm

When creating the SmartForm, create the layout and design as you normally would. The difference is in the code and declarations. First in the form interface, declare only the variables that are already available to the calling program. If the calling program does not already have the data, don’t bother collecting the data and passing it in – that is the job of the class. In this case, I have the warehouse and transfer order number. From this the class can get the data needed for the report.

In the global definitions, I have a single variable (OB_PICK_DATA) declared with reference to the class I have created. This is the variable that will be used throughout the SmartForm for access to data.

I also have a Field Symbol declared that will be used to get the line item details for the table LTAP.

And here is the only code that goes into the entire SmartForm! It is hard to imagine why anyone would want to put a break point here!

If you are writing this in pre-7.4 ABAP, you would write this as

     CREATE OBJECT ob_pick_data
       EXPORTING
         lgnum = lgnum
         tanum = tanum.

Note that in the output parameters, there is also the field-symbol <LTAP> even though there is no data being set. This is prevent subsequent error / warning messages stating “Field <ltap>-matnr has no defined value“.

In the individual text elements, the data can be accessed from the attributes of the class directly or as an element of a structure. In this case, I have used…

Company name: &OB_PICK_DATA->G_COMPANY&
Transfer Order Number: &OB_PICK_DATA->G_LTAK-TANUM&
Warehouse to pick from: &OB_PICK_DATA->G_LTAK-LGNUM&

For a tabular output itself, you have to reference the attribute as an internal table. In this case, OB_PICK_DATA->GI_LTAP is a table of Transfer Order Lines that I am assigning to the field-symbol <LTAP>. Another alternative here is to declare a Global Field and have the data going into it instead of assigning. If you want to avoid any variable on the SmartForm, you can create an attribute in the class and send the data to that variable. While this is possible, I feel that a field-symbol being a pointer is the most efficient way to access this data.

In the individual cells, you reference the field-symbol or local variable in this case instead of the object.

"Using Field-Symbol
&<LTAP>-TAPOS&
&<LTAP>-MATNR&

  "OR

"Using a variable
&L_LTAP-TAPOS&
&L_LTAP-MATNR&

And step 3 – there is no step 3… just test and use! Another advantage that I have not used yet is that you could set up a test class so that you are covered for immediate testing as well as future regression testing. Try that with standard SmartForm code!

OO ABAP Basics

To understand about the Classes and Objects, lets have a quck look at these concepts.
 CLASS:
 Structure of a Class:
1.     A class contains components.
2.     Each component is assigned to a visibility section.
3.     Classes implement methods.
 

 Defining Classes (Local):
The declaration part of a class <class> is a statement block:
CLASS <class> DEFINITION.
...                       declaration for all components (attributes, methods, events) of the class
ENDCLASS.
 CLASS <class> IMPLEMENTATION.
...          contains the implementation of all methods of the class
ENDCLASS.

 Visibility Sections
Public Section:  All of the components declared in the public section are accessible to all users of the class, and to the methods of the class and any classes that inherit from it. The public components of the class form the interface between the class and its users.
 Protected Section: All of the components declared in the protected section are accessible to all methods of the class and of classes that inherit from it. Protected components form a special interface between a class and its subclasses.

Private Section: Components that you declare in the private section are only visible in the methods of the same class. The private components are not part of the external interface of the class.
 OBJECTS
Objects are instances of classes. Each object has a unique identity and its own attributes. To access an object from an ABAP program, you use object references. Object references are pointers to objects.
 Reference variables contain references. A reference variable is either initial or contains a reference to an existing object. The identity of an object depends on its reference. A reference variable that points to an object knows the identity of that object. Users cannot access the identity of the object directly.
 There are two principal types of references: 
Class references and interface references.
 You define class references using the
... TYPE REF TO <class>
 addition in the TYPES or DATA statement, where <class> refers to a class. A reference variable with the type class reference is called a class reference variable.
 A class reference <cref> allows a user to create an instance (object) of the corresponding class, and to address a visible component <comp> within it using the form
cref->comp
 Create Object : Once you have declared a class reference variable <obj> for a class <class>, you can create an object using the statement
 CREATE OBJECT <cref>.
 Addressing the Object Components
Programs can only access the instance components of an object using references in reference variables. The syntax is as follows (where <ref> is a reference variable):
§         To access an attribute <attr>: <ref>-><attr>
§         To call a method <meth>: CALL METHOD <ref>-><meth>
 You can access static components using the class name as well as the reference variable. It is also possible to address the static components of a class before an object has been created.
§         Addressing a static attribute <attr>: <class>=><attr>
§         Calling a static method <meth>: CALL METHOD <class>=><meth>
 Within a class, you can use the self-reference ME to access the individual components:
§         To access an attribute <attr> in the same class: ME-><attr>
§         To call a method <meth> in the same class: CALL METHOD ME-><meth>
  Events
Triggering and handling an event means that certain methods act as triggers and trigger events, to which other methods - the handlers - react. This means that the handler methods are executed when the event occurs.
 To trigger an event, a class must
1.      Declare the event in its declaration part.
2.      Trigger the event in one of its methods.
 To handle an event, a method must
1.      be defined as an event handler method for that event.
2.      be registered at runtime for the event.
 *Registering Event Handler Methods :*To allow an event handler method to react to an event, you must determine at runtime the trigger to which it is to react. It links a list of handler methods with corresponding trigger methods.
 There are four different types of event.
1.      An instance event declared in a class.
2.      An instance event declared in an interface.
3.      A static event declared in a class.
4.      A static event declared in an interface.

A tip for the beginners in OO ABAP.

We often get so carried away by the syntactical correctness of our programs that we tend forget/ignore the underlying concepts. In some cases, this might lead to serious semantic errors. A case in point is where a programmer was trying to compare/equate two objects as if they were normal variables…

Look at the following code snippet –

REPORT ZBASICS_OOABAP. DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. OBJECT2 = OBJECT1.

The above piece of code does not give you any syntax error. But you must understand here, that there is only one object created here. The last statement does not create another object. It only makes the reference variable object2 point to the object created in the previous statement. Object1 and Object2 are now two reference variables which both point to the same object.

The concept of Object-Orientation is based on modeling real-world entities. Let us say we have two customers. It makes no sense what ever to say that these two customers are equal – even if they have the same attributes. Don’t you agree? Consider the following example –
Most of us are known by different names among different people and in different contexts. At work, I’m Anand. My friends have got some nickname for me  and at home, I’m called by yet another name. But all of them are actually referring to the same person.

Now look at the following code –

DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. CREATE OBJECT OBJECT2. OBJECT2 = OBJECT1.

Two objects are created and Object1 and Object2 point to them respectively. But after the assignment statement, the reference variable Object2 also points to the first Object (which is referred to by the reference variable Object1). Now the second object has not got any variable referring to it. In other words, the second object that has been created can no longer be accessed. Its handle is completely lost and it is ultimately cleaned up (automatically) by the Garbage Collector.

And finally, another small pitfall which you must look out for.

DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. CREATE OBJECT OBJECT2. ...... ...... ...... ...... ...... IF ( OBJECT1 = OBJECT2 ). " Some processing based on the above condition ENDIF.

The above condition only checks whether OBJECT1 and OBJECT2 point to the same object. It is NOT a check for the equality of the two objects (which obviously does not make sense).

A more concrete example would be the case where you are using two ALV Grids in your program to display the data from two different tables.

DATA: GRID1 TYPE REF TO CL_GUI_ALV_GRID, GRID2 TYPE REF TO CL_GUI_ALV_GRID. DATA: ITAB_SPFLI TYPE TABLE OF SPFLI, ITAB_SCARR TYPE TABLE OF SCARR. ..... ..... ..... CREATE OBJECT GRID1. CREATE OBJECT GRID2. ..... SELECT * FROM SPFLI INTO TABLE ITAB_SPFLI. SELECT * FROM SCARR INTO TABLE ITAB_SCARR. CALL METHOD GRID1->SET_TABLE_FOR_FIRST_DISPLAY EXPORTING I_STRUCTURE_NAME = 'SPFLI' CHANGING IT_OUTTAB = ITAB_SPFLI. CALL METHOD GRID2->SET_TABLE_FOR_FIRST_DISPLAY EXPORTING I_STRUCTURE_NAME = 'SCARR' CHANGING IT_OUTTAB = ITAB_SCARR. ..... ..... ..... ..... IF GRID1 EQ GRID2. " Conditional Processing ENDIF.

Technially, the above comparison is okay. There’s no syntax error. But I’m sure you can see the absurdity of trying to test whether GRID1 and GRID2 are displaying the same data (or something similar in intent) with the above condition.