Creating Simple ABAP Query Quick View

ABAP query quick view for Sales Document Item (Table: VBAP)

Step 1. Go to transaction SQ01.


Step 2. Enter a Name for Query and Press the Quick Viewer Push Button.


Step 3. Press the Button "Create" for creating a new query with name entered. Here "ZTEST" is used.


Step 4. Enter a description for the query. Chose Source as Table, Enter the table name Ex. VBAP.

Step 5. Choose the list of fields to be displayed in the report.


Step 6. Choose the fields for Selection Screen


Step 7. Choose the fields based on which the report needs to be sorted. Press the layout mode button for layout settings.


Step 8. Enter Header and Footer for the report. Using Tool Box, color the key columns. Read the Tool Box Help text for details. Press Execute button on completion.


Step 9. Enter the selection criteria.


Step 10. Report is displayed for Sales Document Item data.

Author: Arnab Bhattacharyya

REPORT

PURPOSE -:
GETTING PROFIT CENTER DETAILS FROM CEPC & CEPCT TABLES BASED ON USER INPUT AND SAVING THE DATA IN A DESKTOP FILE AND DISPLAYING THEM.

DESCRIPTION -:
On providing the Profit Center data and file path of the .txt file, the user should get the PROFIT CENTER DETAILS from CEPC & CEPCT Tables saved on the file and the details will be displayed in the output.

CODE -:
* ALL THE GLOBAL DECLARATIONS
*&---------------------------------------------------------------------*
*&-------------------------DECLARATION OF TYPES------------------------*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF TY_FINAL,
BUKRS TYPE BUKRS, " Company Code
PRCTR TYPE PRCTR, " Profit Center
DATBI TYPE DATBI, " valid to date
KOKRS TYPE KOKRS, " controlling area
DATAB TYPE DATAB, " valid from date
VERAK TYPE VERAPC, " person in charge of profit center
KHINR TYPE PHINR, " profit center area
TXJCD TYPE TXJCD, " tax jurisdiction code
KTEXT TYPE KTEXT, " general name
LTEXT TYPE LTEXT, " long text
ABTEI TYPE ABTEIL, " department
SEGMENT TYPE FB_SEGMENT, " segment for segmental reporting
END OF TY_FINAL.

TYPES: TY_PRCTR_T TYPE RANGE OF PRCTR,
TY_KOKRS_T TYPE RANGE OF KOKRS,
TY_BUKRS_T TYPE RANGE OF BUKRS,
TY_KHINR_T TYPE RANGE OF PHINR.
*&---------------------------------------------------------------------*
*&------------------DECLARATION OF INTERNAL TABLE----------------------*
*&---------------------------------------------------------------------*

DATA: I_FINAL TYPE STANDARD TABLE OF TY_FINAL.
*&---------------------------------------------------------------------*
*&-----------------DECLARATION OF WORK-AREA----------------------------*
*&---------------------------------------------------------------------*

DATA: WA_FINAL TYPE TY_FINAL.
*&---------------------------------------------------------------------*
*&------------------------------VARIABLES------------------------------*
*&---------------------------------------------------------------------*

DATA: G_PRCTR TYPE PRCTR,
G_DATBI TYPE DATBI,
G_KOKRS TYPE KOKRS,
G_BUKRS TYPE BUKRS,
G_KHINR TYPE PHINR.

DATA: L_V_RECORD TYPE STRING,
L_V_REM TYPE STRING,
L_V_LEFT TYPE STRING,
L_V_FILE TYPE STRING.
*&-----------------------------------------------------------------------&*
*& SELECTION SCREEN &*
*&-----------------------------------------------------------------------&*
SELECTION-SCREEN BEGIN OF BLOCK B WITH FRAME TITLE text-001.

SELECT-OPTIONS: S_PRCTR FOR G_PRCTR,
S_DATBI FOR G_DATBI,
S_KOKRS FOR G_KOKRS,
S_BUKRS FOR G_BUKRS,
S_KHINR FOR G_KHINR.

PARAMETERS: P_PREFIL TYPE RLGRAP-FILENAME obligatory.

SELECTION-SCREEN END OF BLOCK B.
*&------------------------------------------------------------------------&*
*& VALIDATING SELECTION SCREEN &*
*&------------------------------------------------------------------------&*
AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_PREFIL.
PERFORM f_getfile_name
CHANGING P_PREFIL.

AT SELECTION-SCREEN ON S_PRCTR.

* PERFORM VALIDATION OF Profit Centre
PERFORM f_validate_profit_centre
USING S_PRCTR[].

AT SELECTION-SCREEN ON S_KOKRS.

* PERFORM VALIDATION OF Controlling Area
PERFORM f_validate_control_area
USING S_KOKRS[].

AT SELECTION-SCREEN ON S_BUKRS.

* PERFORM VALIDATION OF Company Code
PERFORM f_validate_company_code
USING S_BUKRS[].

AT SELECTION-SCREEN ON S_KHINR.

* PERFORM VALIDATION OF Profit Center Area
PERFORM f_validate_center_area
USING S_KHINR[].

*&***********************************************************************&*
START-OF-SELECTION.


*&*******FETCHING DATA FROM CEPC & CEPCT TABLES BASED ON USER INPUT******&*

SELECT CEPC~BUKRS
CEPC~PRCTR
CEPC~DATBI
CEPC~KOKRS
CEPC~DATAB
CEPC~VERAK
CEPC~KHINR
CEPC~TXJCD
CEPCT~KTEXT
CEPCT~LTEXT
CEPC~ABTEI
CEPC~SEGMENT

INTO TABLE I_FINAL
FROM CEPC INNER JOIN CEPCT ON CEPC~PRCTR = CEPCT~PRCTR

WHERE CEPC~PRCTR IN S_PRCTR
AND CEPC~DATBI IN S_DATBI
AND CEPC~KOKRS IN S_KOKRS
AND CEPC~BUKRS IN S_BUKRS
AND CEPC~KHINR IN S_KHINR .

END-OF-SELECTION.
IF SY-SUBRC <> 0 .
MESSAGE 'No Data Found' TYPE 'I'.
LEAVE LIST-PROCESSING.
ELSE.
PERFORM F_SAVE_PRES_SERVER.
PERFORM F_DISPLAY_REPORT1.
ENDIF.

* ALL THE PERFORMS.
*&---------------------------------------------------------------------*
*& Form f_getfile_name
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->FP_P_FILE text
*----------------------------------------------------------------------*
FORM f_getfile_name CHANGING fp_p_file TYPE LOCALFILE.

CALL FUNCTION 'F4_FILENAME'
EXPORTING
program_name = syst-cprog
dynpro_number = syst-dynnr
field_name = 'P_PREFIL'
IMPORTING
file_name = fp_p_file.

ENDFORM. "f_getfile_name



*&---------------------------------------------------------------------*
*& Form F_VALIDATE_PROFIT_CENTRE
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->P_G_PRCTR text
*----------------------------------------------------------------------*
FORM F_VALIDATE_PROFIT_CENTRE USING P_S_PRCTR TYPE TY_PRCTR_T.

SELECT PRCTR
FROM CEPC
INTO G_PRCTR
UP TO 1 ROWS
WHERE PRCTR IN P_S_PRCTR.
ENDSELECT.

IF sy-subrc NE 0.
MESSAGE 'invalid profit centre' TYPE 'E'.
ENDIF.

ENDFORM. " F_VALIDATE_PROFIT_CENTRE
*&---------------------------------------------------------------------*
*& Form F_VALIDATE_CONTROL_AREA
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->P_G_KOKRS text
*----------------------------------------------------------------------*
FORM F_VALIDATE_CONTROL_AREA USING P_S_KOKRS TYPE TY_KOKRS_T.

SELECT KOKRS
FROM TKA01
INTO G_KOKRS
UP TO 1 ROWS
WHERE KOKRS IN P_S_KOKRS.
ENDSELECT.

IF sy-subrc NE 0.
MESSAGE 'invalid controlling area' TYPE 'E'.
ENDIF.

ENDFORM. " F_VALIDATE_CONTROL_AREA
*&---------------------------------------------------------------------*
*& Form F_VALIDATE_COMPANY_CODE
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->P_G_BUKRS text
*----------------------------------------------------------------------*
FORM F_VALIDATE_COMPANY_CODE USING P_S_BUKRS TYPE TY_BUKRS_T.

SELECT BUKRS
FROM T001
INTO G_BUKRS
UP TO 1 ROWS
WHERE BUKRS IN P_S_BUKRS.
ENDSELECT.

IF sy-subrc NE 0.
MESSAGE 'invalid company code' TYPE 'E'.
ENDIF.

ENDFORM. " F_VALIDATE_COMPANY_CODE
*&---------------------------------------------------------------------*
*& Form F_VALIDATE_CENTER_AREA
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->P_G_KHINR text
*----------------------------------------------------------------------*
FORM f_validate_center_area USING P_S_KHINR TYPE TY_KHINR_T.

SELECT KHINR
FROM CEPC
INTO G_KHINR
UP TO 1 ROWS
WHERE KHINR IN P_S_KHINR.
ENDSELECT.

IF sy-subrc NE 0.
MESSAGE 'invalid profit centre area' TYPE 'E'.
ENDIF.

ENDFORM. " F_VALIDATE_CENTER_AREA
*****************SAVING DATA IN PRESENTATION SERVER*********************
*&---------------------------------------------------------------------*
*& Form F_SAVE_PRES_SERVER
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text *----------------------------------------------------------------------* FORM F_SAVE_PRES_SERVER . L_V_FILE = P_PREFIL. CALL FUNCTION 'GUI_DOWNLOAD' EXPORTING FILENAME = L_V_FILE FILETYPE = 'ASC' APPEND = ' ' WRITE_FIELD_SEPARATOR = '|' NO_AUTH_CHECK = 'X' TABLES DATA_TAB = I_FINAL EXCEPTIONS FILE_WRITE_ERROR = 1 NO_BATCH = 2 GUI_REFUSE_FILETRANSFER = 3 INVALID_TYPE = 4 NO_AUTHORITY = 5 UNKNOWN_ERROR = 6 HEADER_NOT_ALLOWED = 7 SEPARATOR_NOT_ALLOWED = 8 FILESIZE_NOT_ALLOWED = 9 HEADER_TOO_LONG = 10 DP_ERROR_CREATE = 11 DP_ERROR_SEND = 12 DP_ERROR_WRITE = 13 UNKNOWN_DP_ERROR = 14 ACCESS_DENIED = 15 DP_OUT_OF_MEMORY = 16 DISK_FULL = 17 DP_TIMEOUT = 18 FILE_NOT_FOUND = 19 DATAPROVIDER_EXCEPTION = 20 CONTROL_FLUSH_ERROR = 21 OTHERS = 22 . IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

ENDFORM. " F_SAVE_PRES_SERVER
***************DISPLAYING DATA FROM PRESENTATION SERVER*****************
*&---------------------------------------------------------------------*
*& Form F_DISPLAY_REPORT1
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text *----------------------------------------------------------------------* FORM F_DISPLAY_REPORT1 . CALL FUNCTION 'GUI_UPLOAD' EXPORTING FILENAME = L_V_FILE FILETYPE = 'ASC' HAS_FIELD_SEPARATOR = '|' NO_AUTH_CHECK = 'X' TABLES DATA_TAB = I_FINAL EXCEPTIONS FILE_OPEN_ERROR = 1 FILE_READ_ERROR = 2 NO_BATCH = 3 GUI_REFUSE_FILETRANSFER = 4 INVALID_TYPE = 5 NO_AUTHORITY = 6 UNKNOWN_ERROR = 7 BAD_DATA_FORMAT = 8 HEADER_NOT_ALLOWED = 9 SEPARATOR_NOT_ALLOWED = 10 HEADER_TOO_LONG = 11 UNKNOWN_DP_ERROR = 12 ACCESS_DENIED = 13 DP_OUT_OF_MEMORY = 14 DISK_FULL = 15 DP_TIMEOUT = 16 OTHERS = 17 . IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

WRITE:/ 'Code',
5 sy-vline,
6 'Pro.Ctr',
16 sy-vline,
17 'To Date',
28 sy-vline,
29 'Area',
34 sy-vline,
35 'From Date',
47 sy-vline,
48 'In charge',
70 sy-vline,
71 'Ctr Area',
84 sy-vline,
85 'Tax Code',
101 sy-vline,
102 'Name',
122 sy-vline,
123 'Long Text',
152 sy-vline,
153 'Dept',
165 sy-vline,
166 'Segment'.

ULINE.

LOOP AT I_FINAL INTO WA_FINAL.

WRITE:/ WA_FINAL-BUKRS,
5 sy-vline,
6 WA_FINAL-PRCTR,
16 sy-vline,
17 WA_FINAL-DATBI,
28 sy-vline,
29 WA_FINAL-KOKRS,
34 sy-vline,
35 WA_FINAL-DATAB,
47 sy-vline,
48 WA_FINAL-VERAK,
70 sy-vline,
71 WA_FINAL-KHINR,
84 sy-vline,
85 WA_FINAL-TXJCD,
101 sy-vline,
102 WA_FINAL-KTEXT,
122 sy-vline,
123 WA_FINAL-LTEXT,
152 sy-vline,
153 WA_FINAL-ABTEI,
165 sy-vline,
166 WA_FINAL-SEGMENT.
ENDLOOP.
ULINE.

ENDFORM. " F_DISPLAY_REPORT1

OUTPUT -:

REPORT

PURPOSE -:
To get customer item selected subtotal.

DESCRIPTION -:
On clicking subtotal button in the toolbar, user should get subtotal of customer items which are selected. Then subtotal of not selected items and in the end all items total.

CODE -:
1. This checkbox is provided using the slis_layout_alv.

FORM f_build_layout CHANGING fp_wa_layout TYPE slis_layout_alv.

CONSTANTS: l_c_total TYPE char5 VALUE 'TOTAL'.

fp_wa_layout-colwidth_optimize = c_x .
fp_wa_layout-box_fieldname = c_box.
fp_wa_layout-zebra = c_x. " striped pattern
fp_wa_layout-totals_text = l_c_total.


ENDFORM. " f_build_layout

2. Now since this ‘BOX’ field is available hence, using the sort table, we can get the selected item total.
FORM f_sort_tab CHANGING fp_it_sort TYPE slis_t_sortinfo_alv.

* Local work area For Sort info.
DATA: l_wa_sort TYPE slis_sortinfo_alv.
CONSTANTS: l_c_1 TYPE char1 VALUE '1',
l_c_kunnr TYPE char5 VALUE 'KUNNR'.


CONSTANTS: l_c_box TYPE char3 VALUE 'BOX',
l_c_2 TYPE char1 VALUE '2'.
l_wa_sort-fieldname = l_c_kunnr.
l_wa_sort-spos = l_c_1.
l_wa_sort-up = c_x.
l_wa_sort-subtot = c_x.
l_wa_sort-comp = c_x.
APPEND l_wa_sort TO fp_it_sort.
CLEAR l_wa_sort.

l_wa_sort-fieldname = l_c_box.
l_wa_sort-spos = l_c_2.
l_wa_sort-down = c_x.
l_wa_sort-subtot = c_x.
l_wa_sort-comp = c_x.
APPEND l_wa_sort TO fp_it_sort.
CLEAR l_wa_sort.

ENDFORM. " f_sort_tab

Please note that subtotal will not work unless we check the ‘COMP’ field of sort table (l_wa_sort-comp = ‘X’.).

3. In user command, refresh the output.
WHEN l_c_subt. “Subtotal button FCODE.
rs_selfield-refresh = c_x.

Transport Organizer - Moving Task

Moving Task from One Request to Another Request

Step 1. Open Transport Organizer TCODE - SE10, with your user ID


Step2. You have two transport requests. And task needs to be moved from one request to another request.
Ex: Task RS6K900743 needs to be shifted from RS6K900743 to RS6K905085


Step 3. Select the task and Go to Utilities->Reorganize->Reassign Task

Step 4. Enter the new Request Number in the pop up box and Press Enter.Step 6. Task RS6K900743 is moved to request# RS6K905085. Check the object entries.

Author: Arnab Bhattacharyya.

BAPI

Introduction to BAPI

To define the scenario the BAPI is to be used for, consider the following issues:
• Which scenario is to be implemented?
Every BAPI should be based on a model of a scenario in which it can be usefully employed. You can describe the scenario in the form of a process model.
• Which SAP Business Objects are involved?
From the scenario definition and with the help of the process model you can get information about the SAP Business Objects relevant to the BAPI scenario.
In the scenario to be implemented, a BAPI is required to read data about a creditor. First of all, a list of creditors is to be displayed from which a specific creditor can be selected. Then, using another BAPI, specific details about this creditor are to be displayed.
The relevant SAP Business Object for this scenario is Creditor.
• What functionality should the BAPI provide and how does it affect related BAPIs, especially the other BAPIs of the SAP Business Object in question?
In line with the scenario concept BAPIs must complement each other to create a complete scenario. Their relationships with each other must be clearly defined.
To read a creditor's details as described in the above scenario, two BAPIs are required:
- Display list of creditors- Display details of a specific creditor
The interdependency between these two BAPIs is evident because first the creditor list is displayed to obtain the ID of the specific creditor sought. From this ID, details of this creditor can then be displayed.
However, the two BAPIs remain functionally independent of each other, because if the creditor ID is known, the BAPI "Display details of a specific creditor" can be used without first calling the BAPI "Display list of creditors".
• To what extent can the BAPI's functionality be implemented within the scope of the business object?
A BAPI should be developed so that it provides functionality exclusively within the context of its associated SAP Business Object. If the data of a different SAP Business Object is to be read or updated then the appropriate interface for this object must be used. The functions or methods of these other objects are used implicitly (delegation principle).
The BAPIs required to read creditor details in the above scenario are only able to access data in the SAP Business Object Creditor. Other object types are not involved.

Defining a BAPI and Its Interface

To define the scope and required components of the BAPI to be implemented, the following steps must be completed:
• Determining the SAP Business Object and Its Key Fields

• Defining the Interface Structure of the BAPI

• Identifying the name of the function group, or if a function group does not exist already, planning a name for one.
All BAPIs belonging to one SAP Business Object should be stored as function modules in one function group. Ascertain whether a function group has already been created for the BAPIs of the SAP Business Object in question. If a function group does not already exist, then plan a name for the one to be created.
You can use the default technical name (object type) of the SAP Business Object as the basis of the function group name. The technical name of a SAP Business Object usually takes the form of BUSnnnn, where n is a number.
Use the suffix "nnnn" as the name of the function group. For example, if the technical name of the object is BUS1008 then the associated BAPI function group is called 1008.
To ascertain the technical name of the Business Object, open the Business Object in the Business Object Repository (BOR), as described in Determining the SAP Business Object and Its Key Fields. To display further details, for example, the object type, double click the name of the Business Object.
• Assigning a name to the function module
Choose a name that gives an indication of what the BAPI is used for. The naming convention is: BAPI__. For information about naming a method refer to Naming the Method in the BOR.
For example, in the case of a BAPI which reads details for the object type Creditor, the name of the associated function module is BAPI_CREDITOR_GETDETAIL.
• Naming Parameters in the Function Module
• Defining the format for passing the values in the function module interface.Parameters must not be converted before they are passed to and from the BAPI interface. This is because BAPIs are programming interfaces and not end user interfaces. Exceptions are currency codes, ISO codes and fields with an internal key.
• Specifying the Required Objects in ABAP Dictionary

• Naming the Method in the BOR

• Naming Parameters in the BOR

Standardized BAPIs
Use
Some BAPIs and methods provide basic functions and can be used for most SAP business object types. Such BAPIs are known as "standardized" BAPIs.
Features
With object methods and especially with BAPIs, you can differentiate between instance methods and class methods. Instance methods refer to precisely one instance (one specific occurrence) of an SAP Business Object type, for example, to one explicitly specified customer order. Whereas class methods are instance-independent.
BAPIs for Reading Data
The following BAPIs provide you with read-only access to data in the associated business object type:
GetList() With the BAPI GetList() you can select a range of object key values, for example, company codes and material numbers. The BAPIs GetList() is a class method.
GetDetail() The BAPI GetDetail() uses a key to retrieve details about an instance (one specific occurrence) of a business object type and returns this data to the calling program. Then this information is reported back to the calling program. The BAPI GetDetail() is an instance method.
GetStatus() The BAPI GetStatus() is used to query the status of an SAP business object instance, for example, the processing status of a sales order. This BAPI is used only for displaying the status of an object and does not retrieve full details like the BAPI GetDetail(). The BAPI GetStatus() is an instance method.
ExistenceCheck() The BAPI ExistenceCheck() checks whether an entry exists for a business object instance, for example, whether the customer master has been created. The ExistenceCheck() BAPI is an instance method.

BAPIs for Creating or Changing Data

The following BAPIs can create, change or delete instances of a business object type:
Create() or CreateFromData() The BAPI Create() or CreateFromData() creates an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.
Change() The BAPI Change() changes an existing instance of a SAP business object type, for example, a purchase order. The Change() BAPI is an instance method.
Delete() and Undelete() The BAPI Delete() deletes an instance of an SAP business object type from the database, for example, a purchase order.The BAPI Undelete() removes a deletion flag.These BAPIs are instance methods.
Cancel() Unlike the BAPI Delete () the BAPI Cancel() cancels an instance of a business object, that is the instance to be cancelled remains in the database and an additional instance is created that is canceled).The Cancel() BAPI is an instance method.
Add and Remove The BAPI Add adds a sub-object to an existing object instance and the BAPI and Remove removes a sub-object from an object instance. These BAPIs are instance methods.

PERFORMANCE TUNING IN SAP


Few points that should be noted by a developer while writing a piece of code to
Develop a good quality object with high performance.

For checking the performance of any object the transaction that should be used are:-
a) ST05
b) SE30.


SE30: ABAP Runtime Analysis

1. On running the transaction, the object name or the transaction associated to it must be specified as follows and then execute the same.

2. The screen below (Fig 1.0.1) shall appear once the code is executed and when you come back to the SE30 transaction screen by clicking “Back” button in the menu. Once you reach the Fig 1.0 screen, click on the “Analyze” button.

This screen shows a bar diagram that indicates the system time utilized by the code (in microseconds) which is classified under three categories:-
a) ABAP Time
b) Database Time
c) R/3 System Time

Out of the three mentioned time’s the ABAP & Database Time can be controlled by proper usage of the ABAP & SQL statements respectively which is mentioned in the later half of this document.

3. Now to get a detail analysis of the time utilized by each and every ABAP statement in your code click on the button at the top left most corner of the
Fig 1.0.1. The detail analysis is as follows:-

ST05: Trace Request

• Under this transaction there are several Trace Modes of which SQL trace checkbox needs to be checked to know the performance of each and every select query written in a piece of code.

• After checking the check box against the SQL Trace one has to switch on the trace request which can be done in two ways:-

1. Trace on: The SQL trace shall be on for the particular object that needs to be tested under the developers Username.

2. Trace on for user: The SQL trace shall be on for the particular object that needs to be tested under the developers Username with filter.


The difference between the two buttons can be explained by the following example:-

If a code is been executed by several users at the same time and if “Trace on” button is clicked then the performance analysis that shall be shown will be a effect of execution of that code for more than one scenario by different users at the same time.

Else if the same code is been executed by many users at the same time and if “Trace on for user button” is clicked then the performance analysis that shall be shown will be only for the scenario under that particular user for which the code is executed.

Now if you are clicking the “Trace On” button to ON the trace the only care that need to be taken before doing it is you need to be ready with all your inputs in the selection screen. Because if you ON the trace and then go to execute the object & fill the input fields, the time lapse between the Trace ON & Executing the code does effect the performance time.

On clicking the “Trace on for user” button a popup window shall be flashed which shall ask for the object name or the transaction associated to it of which the performance needs to be tested.

On entering the object name the trace status shall be on as shown in the Fig 2.0.1 / Fig 2.0.2.

Now the object needs to be executed with the desired inputs. Once it is executed then the trace need to be put off by clicking the “Trace off” button as shown in the Fig 2.0.

To view the performance analysis of the object, click on the “List Trace” button as shown in the Fig 2.0. A popup window shall be flashed which is as follows:-

Now on clicking enter a Basic Trace List screen shall appear which shall possess the analysis of all the select queries in that particular object.

Now place the cursor on the Object name against the Op. = REOPEN and click the “Explain” button as shown in the Fig 2.0.5. On clicking the same the Execution plan for SQL statement shall be displayed.

In the Fig 2.0.6, it is seen that the estimated cost = 1 and the estimated rows = 1.
For a SQL statement to be performance tuned the Estimated Cost of it should be tending to 1 and the Estimated Rows must be equal to the no. of desired rows that need to be fetched from the DB Table.

So to make the SQL statement in your code performance tuned we need to check its Estimated Cost and Estimated Rows values. To make it tend to the desired values mentioned above the following points need to be taken care by the developer while writing the code:-

i. Complete conditions are specified in the where clause taking care of all the primary keys and the order of it in the DB table.
ii. SELECT INTO TABLE is used instead of SELECT & APPEND.
iii. SELECT SINGLE is used instead of SELECT….ENDSELECT.
iv. SELECT * need to be avoided in case of fetching only few fields from the DB table. Instead mention the field names that need to be fetched.
v. Usage of AGGREGATE functions (MAX, MIN, SUM, COUNT, etc) must be minimum.
vi. SELECT into CORRESPONDING-FIELDS should be avoided in case of few records being selected
vii. Internal table is not empty check must be done before using FOR ALL ENTRIES in a SELECT query.
viii. SELECT queries using FOR ALL ENTRIES must use the key fields.
ix. Multiple identical SELECTs must be avoided on the same DB table. Instead the data must be fetched at one go into a global internal table and later on this internal table should be used for further processing.
x. Avoid using JOINS in SELECT queries for more than three DB tables.
xi. Avoid using SELECT inside a LOOP ….ENDLOOP statement.
xii. MOVE statement must be used instead of MOVE-CORRESPONDING.
xiii. Usage of IS/IS NOT INITIAL instead of hard code values.
xiv. Already existing INDEXES associated with the DB tables must be used as they help in making the search faster.


INDEXES
• Which indexes are actually available
• How they are denoted
• Which index can be used with a given SELECT statement?
To tell the optimizer which index to use, you need to:
• Start transaction SE11.
• On the initial screen of the ABAP Dictionary, enter SPFLI in the Database table field and choose Display.
• On the maintenance screen of this table, choose Indexes to get a list of all identifiers of SPFLI's secondary indexes. To obtain a description of the related index, position the cursor on the selected line and click Choose. (I know this sounds ridiculous, but don't blame me!)
For example, the identifier 001 represents a non-unique secondary index comprising the table columns CITYFROM and CITYTO. The index name on the database adheres to the convention ~ (SPFLI~001, in our example). Because the convention for defining the index name in the database has changed several times, I strongly recommended you check out the valid name in this way. To find appropriate candidates for index access, start with the set of columns referenced in the WHERE clause of the SELECT statement (in our example, MANDT CARRID CITYFROM). Candidates are indexes that match up some of their leading columns. I'd like to clear up a common misunderstanding: The sequence of the fields in the WHERE clause doesn't influence the optimizer's index selection. Regarding the list of secondary indexes, SPFLI~001 clearly is the only candidate. The situation becomes a little more complicated if you use comparison operators other than "=" or logical operators other than AND.
Another candidate for index access is the primary index consisting of the table fields MANDT CARRID CONNID. For the primary index, 0 is reserved as the index identifier. But again, always check out the valid name:
• On the maintenance screen of the table SPFLI, choose Database Utility in the Utilities menu.
• On the utility screen of this table choose Indexes to get a list of the identifiers of all SPFLI indexes. To obtain the primary index's database name, position the cursor into the selected line and choose Ok.

To sum up, the database system can alternatively use FULL TABLE SCAN, the primary key index SPFLI_0, or the secondary index SPFLI~001 to access the requested data. But how can you tell the optimizer which one to use?
GIVE ME A HINT
Since release 4.5, you can provide optimizer hints for SELECT statements using the %_HINTS parameter that enables emergency repairs on the spot. Of course, this parameter only works for those database systems that support optimizer hints. Because optimizer hints are not covered by SQL standards, each database vendor is free to provide them. Note that parameters starting with "%_" are never published in the documentation and should be used with special care only in an emergency. This introduction is very simplified; for a detailed description, please refer to Note 129385 in OSS.
Using the %_HINTS parameter, the example becomes:
SELECT carrid connid cityfrom
FROM spfli INTO (xcarrid, xconnid, xcityfrom)
WHERE carrid = 'LH ' AND cityfrom = 'FRANKFURT'
%_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")'.
WRITE: / xcarrid, xconnid, xcityfrom.
ENDSELECT.

If you specify hints incorrectly, ABAP ignores them but doesn't return a syntax or runtime error. This lack of notification is the reason why you have to make sure that you specified the index's correct denotation.
Now you should know how to perform optimizer hints. If you aren't careful to use them sparingly, you'll only have yourself to blame when things go wrong. o




Now if you click on ECMCT~1 in the Fig 2.0.6 the detailed information of the index 1 defined for the ECMCT table shall be displayed as in the
Fig 2.0.7(below). It indicates the usage of the Index of ECMCT table in your
SQL statement. If in the Execution Plan you find ECMCT~0 it means that the
basic primary keys of the table are used.


Clicking on ECMCT in the execution plan displays the following information of the indexes associated with the ECMCT table. To get the detailed Index Statistics click on the “Index Statistics” Button in the Fig 2.0.8 (below).


xv. Performance tips specifically with Internal Tables:-
Unnecessary sorting must be avoided.
READ TABLE must be used with BINARY SEARCH.
It must be Cleared / Refreshed wherever necessary.
APPEND to be used instead of COLLECT.
Usage of Memory ID should be minimal & freed immediately after use.
CLEAR the Header Line / Work Area after the APPEND statement.
CLEAR Header Line after DELETE statement.

Credit Management

Credit Management is one very important feature of SAP in the AR Cycle.

Basically against the Customers - Credit Limits are set and based on the Limit several things can be performed like Blocking Delivery.

Customer Credit Limits are set against Credit Control Area. Credit Control Area is assigned to Company Code (1: n Relationship). The SPRO node is as below –


Some Important Transactions
F.31 – Customer Credit Overview
FD32 – Customer Credit Management


Some Important Tables
KNKK - Customer master credit management: Control area data
KNKA - Customer master credit management: Central data


Some Important Notes on Credit Management in SD Cycle

Assignment of Sales Area to Credit Control Area:

Sometimes for example - you will find your sales Order is blocked for Delivery due to Credit Limit Check. These kinds of things are controlled by certain configurations.

Please go through the below set of Transactions (Configurations) to control aspects mentioned above.

OVAK - Define Credit Limit Check by sales Document Type
OVAD - Define Credit Limit Check by Delivery Order

VKM1 - Blocked SD Documents
VKM2 - Released SD Documents
VKM3 - Releasing Credit Block in Sales Order
VKM4 - Releasing Credit Block in Sales Order / Delivery Order
VKM5 - Releasing Credit Block in Delivery Order



Some Important SAP Credit Management Programs

RFDKLI10 - Customers with Missing Credit Data
RFDKLI20 - Reset Credit Limit for Customers

BAPI Introduction

General Introduction to BAPIs
Purpose
BAPIs (Business Application Programming Interfaces) are the standard SAP interfaces. They play an important role in the technical integration and in the exchange of business data between SAP components, and between SAP and non-SAP components. BAPIs enable you to integrate these components and are therefore an important part of developing integration scenarios where multiple components are connected to each other, either on a local network or on the Internet.

BAPIs allow integration at the business level, not the technical level. This provides for greater stability of the linkage and independence from the underlying communication technology.

The Business Application Programming Interfaces allow object-oriented access to the SAP system through methods for the business object types. Together with the business object types, BAPIs define and document the interface standard at the business level.

Integration
BAPIs can be called within the R/3 System from external application systems and other programs. BAPIs are the communication standard for business applications. BAPI interface technology forms the basis for the following developments:
• Connecting:
• New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business Information Warehouse (BW).
• Non-SAP software
• Legacy systems
• Isolating components within the R/3 System in the context of Business Framework
• Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)
• Connecting R/3 Systems to the Internet using Internet Application Components (IACs)
• PC programs as frontends to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age for Java (IBM).
• Workflow applications that extend beyond system boundaries
• Customers' and partners' own developments

The graphic below shows how BAPI interfaces enable different types of applications to be linked together. BAPIs - Interfaces to the R/3 System

Objectives for Implementing BAPIs

When implementing BAPIs, you should pursue the goal of avoiding the disadvantages of the "postcard effect" associated with conventional interfaces: No separation between contents and transport. In the case of a postcard, the text is written on a card that also serves as the information medium. If the information medium changes, then the receiver has to read the text in a different way. As a result, changes to the interface affect the type of access. BAPIs, in contrast, clearly separate the business contents from the underlying communication technology. This procedure can be compared to a letter in an envelope: It is easy to put a letter in a new envelope, just like it is easy to apply new and/or different communication technologies like COM/DCOM, the CORBA standard, or new Internet standards. The envelope itself is irrelevant to understanding the contents of the letter. In this example, the BAPIs correspond to the letter, meaning they are independent of the programming language and communication mechanisms used.

Using BAPIs results in the following benefits:
• BAPIs represent well-defined, internally consistent units that always represent business facts and leave a consistent database state behind.
• The business contents can be standardized, since BAPIs not only allow the integration of the SAP system and other software components at a technical level, but also at the business level.
• BAPIs have become a communication standard between business systems. Access is possible through object-oriented interface technologies (such as COM/DCOM from Microsoft). The SAP business objects conform to the guidelines of the OAG (Object Application Group), and meet the CORBA standard from the OMG (Object Management Group).
• Stability and compatibility
Once SAP has released a BAPI, its interface definitions and parameters will remain stable in the long term, which means application programs will not be affected by changes to the underlying SAP software or data. If upward-compatible enhancements are made to the BAPIs, the stability of the existing applications is not affected.
• Openness
BAPIs can be accessed from any widespread development platform.

Universal Usability of BAPIs

To allow their use in any scenario, BAPIs must support all forms of communication and be available to all types of participants:
• Support of synchronous and asynchronous communication
BAPIs can be used for both the synchronous and for the asynchronous call to an SAP component. If the call is synchronous, the BAPI is called as a remote function call (RFC).
ALE inbound processing is used to enable asynchronous communication with BAPIs. When the BAPI is called in the sender system, an IDoc is generated and dispatched to the receiver system. When the IDoc reaches the receiver, the parameters of the corresponding BAPI are automatically filled with the IDoc data, and the BAPI is called synchronously.
• Support of machine-to-machine and human-to-machine communication
BAPIs can be used both to integrate application systems and to link up alternative frontends.

• The integration of application systems is characterized by machine-to-machine communication. It is implemented by exchanging large volumes of data and requires high system performance. As a result, the BAPIs used for this type of scenario have a lower level of detail.
• The integration of alternative frontends allows human-to-machine communication. BAPIs used for this purpose have a higher level of detail. They must be designed to allow more flexible communication that is free of errors.

• Communication support for components that are narrowly linked and coupled through the Internet

In addition to the use of BAPIs under communication technologies like CORBA and COM/DCOM, BAPIs can also be accessed via the Internet with the SAP Business Connector. The Business Connector generates an XML document from a BAPI call, or transforms an inbound XML document into a BAPI call. This makes it possible to dispatch BAPI calls as XML documents, enabling communication of components that are linked via the Internet.

All BAPIs are published centrally in the XML-based Interface Repository (IFR) and are stored there as XML schema, which means that they are immediately ready for use with the Business Connector.

BATCH DATA COMMUNICATION

BATCH DATA COMMUNICATION


Data Transfer –
Implementing a new software system requires moving data from the present system i.e., legacy system into the R3 system. Data transfer program is an effective and efficient way of transferring large amount of data into the new system, saves time and resources. But more importantly it ensures that accurate data is transferred into R/3.

Two steps are involved in data transfer –

• Conversion- Data is converted from legacy system into required flat file format.
• SAP Data Transfer- Data is automatically entered into the system. A SAP data transfer program reads the prepared data from the flat file and moves it into R/3.

Steps for any data transfer-
• Analysis and cleanup of data in the non-SAP system.
• Extraction of data from the non-SAP system.
• Mapping the data in SAP format.
• Transferring the data to the SAP System.
• Checking the data.


There are three different options to enter data into R/3-
• Automatically, with SAP standard data transfer programs.
• Automatically, by creating own branch input programs
• Manually, by entering the data via the corresponding online transaction



Automatic transfer with a standard data transfer program
This can be done if:
• A standard program exists for the data transfer of a business object in
R/3.
• The data is available in electronic form.
• There is a significant number of records to transfer.
• The cost of converting the legacy data into the required flat file format is acceptable.

Manually transferring business objects
This can be done if:
• No legacy system is available.
• There is only small number of records to enter.
• Translating legacy data into the R/3 structure is more an effort than
manually entering the data.

Using customer specific batch input to transfer business objects
This can be done if:
• No standard program exists to transfer the business object in R/3.
• The data is available in electronic form.
• There is a significant number of records you to transfer.
• Translating legacy data into the structure required by custom
program is easier than manually entering data.

Batch input is a standard procedure for transferring large amount of data into
the R/3 system. It simulates manual data entry. Data consistency is ensured
because batch input uses all the checks conducted on the normal screen.
Using batch input is like entering the data online. Another advantage to
batch input is that there is no need to check the data in advance.

Batch input is a two-step procedure.
It involves a program that creates the batch input session. This session is the data file that includes everything to begin the transaction and the data to be entered on the appropriate screens .The data is not yet in the database tables of R/3 application.
The second steps to process the session, which then actually transfers the data to database table.


Batch Data Communication-

In the process of transferring data, following situations might occur –
• The first is when application data to be replaced is transferred at
once and only once.
• The second situation is to transfer data periodically from external
systems to SAP system and vice versa.
• There is a period of time when information has to be transferred
from existing application, to SAP R/3, and often this process will be
repetitive.

The SAP system offers two primary methods for transferring data into SAP systems from non-SAP systems or legacy system. These methods are collectively called “Batch Input” or “Batch Data Communication”.

The BDC can transfer data from one SAP System to another SAP System or can transfer data from non-SAP System to SAP System too. BDC can be only be used for uploading data into R/3 and so it is not bi-directional. BDC works on the principle of simulating user input for transactional screen, via an ABAP program. Typically the input comes in the form of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The transaction is then started using this internal table as the input and executed in the background.
BDC allows you to perform database updates in the background using standard SAP transactions. The resultant entries will be as if the user had manually entered the data via SAP. This means that there is no bypassing of any of the standard SAP consistency checks, authorizations etc.

Advantages offered by Batch Input method:
• Can process large data volumes in batch.
• Can be planned and submitted in the background.
• No manual interaction is required when data is transferred.
• Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.

Data Transfer Program –

The batch input program must build all of the input to execute the SAP
transaction.
Two main steps are required:
• To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.
• To pass the table to SAP for processing.

Prerequisite for Data Transfer Program
Writing a Data Transfer Program involves following prerequisites:
• Analyzing data from local file
• Analyzing transaction


Analyzing transaction involves following steps:
• The transaction code.
• Which fields require input i.e., mandatory.
• Which fields can be allowed default to standard values.
• The names, types, and lengths of the fields that are used by a transaction.
• Screen number and Name of module pool program behind a particular
transaction.

Once the program name, screen number, field name (screen field
name) are known , the Data Transfer program can be written.
• Declaring internal table
First Internal table similar to structure like local file.
• Declaring internal table like BDCDATA

The data from internal table is not transferred directly to database table, it
has to go through transaction. We need to pass data to particular screen and
to particular screen-field. Data is passed to transaction in particular format,
hence there is a need for batch input structure.
The batch input structure stores the data that is to be entered into SAP
system and the actions that are necessary to process the data. The batch
input structure is used by all of the batch input methods. The same structure can be used for all types of batch input, regardless of whether a session is created in the batch input queue or CALL TRANSACTION is used.

This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. Hence the processing in a program is done in a loop as follows:
• Create a BDCDATA structure
• Write the structure out to a session or process it with CALL TRANSACTION USING

Within a BDCDATA structure, organize the data of screens in a transaction.
Each screen that is processed in the course of a transaction must be
identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.
The screen identifier record is followed by a separate BDCDATA record for
each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:
• Data that is entered into screen fields.
• Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.


The BDCDATA structure contains the following fields:
• Program : Name of module pool program associated with the screen. Set this field only for the first record for the screen.
• Dynpro : Screen Number. Set this field only in the first record for the screen.
• Dynbegin : Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to ‘ ‘ (blank) for all other records.)
• Fnam : Field Name. The FNAM field is not case-sensitive.
• Fval : Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format.

Data is uploaded to internal table by UPLOAD of WS_UPLOAD or GUI_UPLOAD function. Population of BDCDATA for each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure.
All these five initial steps are necessary for any type of BDC interface.
Data Transfer program can call ‘Session Method’ or ‘Call Transaction’.
The initial steps for both the methods are same.
First step for both the methods is to upload the data to internal
table. From Internal Table, the data is transferred to database table
by two ways i.e., Session method and Call transaction.

Session Method –

In this method data is transferred from internal table to database table
through sessions. An ABAP/4 program reads the external data that is to be entered in the SAP System , synchronous processing takes place and stores the data in session , which is to be handled through SM35. Through this method the data can be read by the BDC program from a sequential dataset file. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.
When the program has finished generating the session, the session can be executed to run the SAP transactions in it. The session can be explicitly started and monitored or run in the background processing system. Unless session is processed, the data is not transferred to database table.

BDC_OPEN_GROUP -
Sessions can be created through program by BDC_OPEN_GROUP function.
Parameters to this function are:
• User Name: User name
• Group: Name of the session
• Lock Date: The date on which you want to process the session.
• Keep: This parameter is passed as ‘X’ when session is to be retained
after processing or ‘ ‘ when it is to be deleted.

BDC_INSERT –
This function transfers data to the session.
Parameters to this function are:
• Tcode: Transaction Name
• Dynprotab: BDC Data

BDC_CLOSE_GROUP –
This function closes the BDC Group.
No Parameters.

Some additional information for session processing –

When the session is generated using the KEEP option within the
BDC_OPEN_GROUP, the system always keeps the sessions in the queue,
whether it has been processed successfully or not.
However, if the session is processed, it has to be deleted manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session , the session can be analyzed. The Analysis function allows to determine which screen and value has produced the error. If there are small errors in data, they can be corrected interactively, otherwise batch input program, which has generated the session or many times even the data file has to be modified.

Call Transaction –

Asynchronous processing takes place and the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling and messages have to be captured at runtime.
In this method, a transaction can be called from the program by
Call transaction using
Mode
Update
Parameter –1 is transaction code.
Parameter –2 is name of BDCTAB table.
Parameter –3 here the execution mode for the transaction is spexcified
A is all screen mode. All the screen of transaction are displayed .
N is no screen mode. No screen is displayed when the transaction is executed.
E is error screen. Only those screens are displayed have error records.
Parameter –4 here update type for the database table updation is specified.
S is for Synchronous update in which data of one table is changed then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.
A is for Asynchronous update in which data of one table is changed,
the sy-subrc is returned. And then updating of other
affected tables takes place. So if system fails to update other
tables, still sy-subrc returned is 0 (i.e., when first table gets
updated).
Parameter – 5 when updating database table takes place, operation is either
successful or unsuccessful or operation is successful with some
warning. These messages are stored in internal table, which is specified along with MESSAGE statement. This internal table should
be declared like BDCMSGCOLL, a structure available in ABAP/4.

It contains the following fields:
Tcode : Transaction code
Dyname: Batch point module name
Dynumb: Batch input Dyn number
Msgtyp : Batch input message type (A/E/W/I/S)
Msgspra: Batch input Lang, id of message
Msgid : Message id
MsgvN : Message variables (N = 1 - 4)

For each entry, which is updated in database, table message is available in
BDCMSGCOLL. As BDCMSGCOLL is structure, a internal table is declared which can contain multiple records (unlike structure).

Steps for Call Transaction method:
• Internal table for the data (structure similar to the local file)
• BDCTAB like BDCDATA
• UPLOAD or WS_UPLOAD function to upload the data
from local file to itab. (Considering file is local file)
• Loop at itab.
• Populate BDCTAB table.
• Call transaction using
Mode
Update .
• Refresh BDCTAB.
• Endloop.


Difference between Batch Input and Call Transaction in BDC –
Session method -
1) Synchronous processing.
2) Can transfer large amount of data.
3) Processing is slower.
4) Error log is created.
5) Data is not updated until session is processed.
Call transaction.-
1) Asynchronous processing.
2) Can transfer small amount of data.
3) Processing is faster.
4) Errors need to be handled explicitly.
5) Data is updated automatically.
Error Handling in CALL TRANSACTION-
When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually there is a need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:

Steps for the error handling in CALL TRANSACTION:
1. Internal table for the data (structure similar to your local
file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL
4. Internal table similar to 1st internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from
the local file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction using
Mode
Update
Messages .
Perform check.
Refresh BDCTAB.
Endloop.
7. Form check.
IF sy-subrc <> 0. (Call transaction returns the sy-subrc if
updating is not successful).
Call function Format_message.
(This function is called to store the message given by
system and to display it along with record)
Append itab2.
Display the record and message.

Direct Input –

In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly.

Common batch input errors -
• The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen.
• The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.
• On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this.
• The BDCDATA structure contains fields, which are longer than the actual definition.
• Authorization problems.

Recording a Batch Input-

A BI recording allows to record a R/3 transaction and generate a program that contains all screens and field information in the required
BDC-DATA format.
SHDB transaction can be used for recording .

SAP Workflow-Adding /manipulating outcome in a standard task

Author Information:
Name: Arnab Banerjee
Location: Kolkata

Technical Details:

Outcomes: Outcomes are defined as No of Paths which comes out of a Workflow step. As for example if condition of Workflow has 2 outcomes either “YES” or “NO”. Depending on the no of outcomes Workflow step can be classified into

· Activity :- Usually Single outcome

· Condition :2 outcomes

· Multiple Condition :- 2 or more than 2 outcomes

Condition:-



In an Activity step the Outcomes can be added using three techniques as follows:

· Underlying Task level :Adding Terminating Events to the Tasks attached to the step

· Underlying Business Object Level: Setting the System Container Result to the underlying Business Objects methods attached to the tasks which in turn attached to the steps from which outcomes come out.

· Modeled Deadline: The Number of Outcome is added to the step in accordance with the Deadline Modeled. As for example if 2 deadlines is modeled then 2 outcomes will added to the step.

In this ICM we will discuss about first 2 Technique.
Underlying Task level: Adding Terminating Events to the Tasks attached to the step

1. Two Events Term_Event1 and Term_Event2 are created in Business Object ZARN1_LR with an Existing Event Request Created.


2. A task with name zarn_task1 is created

Basic data are populated as follows:

Three Terminating Events which are created in Business Object ZARN1_LR are added to the task

The task is inserted in the Workflow template which is just created and is saved



Now if we view the Workflow template, we can see that 3 Outcomes with the names “Test Event 1”, “Test Event 2” and “Leave Request Created” appeared as follows:


Business Object level

1. Business Object coding and Modification:
• A Method is created with name “GETSTATUS” which is used to retrieve the status of the Leave. Example of Leave Status including
• A Leave Applied
• B Pending Approval
• C Leave rejected
• D Leave Approved
• E Leave Held
• F User Cancelled
• G Leave Changed

• A container element Result is populated based on the values of table field “LEAVESTATUS”.
• A local variable “L_RESULT” is declared and is holding the Leave Status. This variable holds the type of leave status
• A System Container Result is set using the variable “L_RESULT”.
• The process of Business Object coding /Changing is explained with the screen shot below :

1. The Synchronous and Result Parameter need to be checked. Synchronous method signifies that the Workflow will hold its execution until and unless the method will completely executed. In other word the execution will be serial. Result Parameter checkbox signifies that this method returns its (main) result in a result parameter.


2. The Result parameter must have a result type. So result Type need to be declared

3. A System Container element result needs to be set. Screen shot referring the entire Code for Method “GETSTATUS” is as follows :

2. Task Design:

1. Transaction Code “PFTC” is given Standard task is selected and let the value entered is “ZARN_OC” followed by Create Button.

2. The task is created with the following values and the method “GETSTATUS” of Business object zarn1_lr.
3. We checked the task and just save the task. The System automatically assign the Task Number as 99900525

3. Workflow Design:

We need to start the Workflow Design .This is just an one step Workflow to demonstrate the Outcome manipulation (No of Outcome comes out of a Step).
The process is as follows:

1. Transaction Code PFTC is used, Workflow Template is selected and we provide the Workflow Abbreviation as ZOUTCOME and F5 Pressed


2. Basic data is filled and Workflow Builder Button is clicked .The Workflow Builder Window appears as shown below


3. The task created earlier need to be added to the Workflow template. Activity step type from the above shown step type window is selected and the task “ZARN_OC” is placed in the Task text box.



4. The Workflow template is saved and we got the required Outcome as shown below. Looking at the outcomes from the step it is obvious that the outcomes are
• Leave Applied
• Pending Approval
• Leave rejected
• Leave Approved
• Leave Held
• User Cancelled
• Leave Changed
These outcomes are same as the data type of the variable “L_STATUS” (Domain ZEAVESTATUS) which is written in the “GETSTATUS” Method of Business Object “ZARN_LR”


Below is the screen shot for value range of Domain “ZLEAVESTATUS”


A system defined outcome “Processing obsolete” automatically comes with the step and is deactivated by default. This outcome can be activated.

Deactivated Status:
After Activating:


In Workflow template another outcomes is added: