FTP file transfer in Background

1) Creating RFC Destination for FTP.

Run program: RSFTP005.

The RFC destinations SAPFTP and SAPFTPA will be created automatically.

a) SAPFTP (for local system)

b) SAPFTPA (for running in Application server)(This is used for file transfer in background.

2) Code sample for developing FTP programs can be got from report program

a) RSFTP002

b) RSFTP007

c) RSFTP008

3) Sample code for getting customer details as tab delimited .TXT file in background.

*&---------------------------------------------------------------------* *& Report ZCUSTOMER *& *&---------------------------------------------------------------------* *&-Customer -All new/changed customer records created during the period. *&---------------------------------------------------------------------* *LedgerKey-------------Char(50) *AccountName-----------Char(80) *AccountReference -----Char(50) *Address1 -------------Char(80) *Address2 -------------Char(80) *Town -----------------Char(50) *County / State -------Char(50) *Post Code / ZIP ------Char(20) *Country---------------Char(2) *AccountCurrencyCode --Char(3) *ContactTelephone -----Char(20)

REPORT  zcustomer.

TABLES: kna1,knb1. 

TYPES: BEGIN OF st_customer,        ledgerkey TYPE char50,        name1 TYPE kna1-name1,        kunnr TYPE kna1-kunnr,        name2 TYPE kna1-name2,        stras TYPE kna1-stras,        ort01 TYPE kna1-ort01,        regio TYPE kna1-regio,        pstlz TYPE kna1-pstlz,        land1 TYPE kna1-land1,        waers TYPE knvv-waers,        telf1 TYPE kna1-telf1,        END OF st_customer. 

TYPES : BEGIN OF st_cus,               ledgerkey(50)  TYPE c, "LedgerKey               wrk_delim1      TYPE x ,               name1(80)   TYPE c,  "AccountName               wrk_delim2      TYPE x ,               kunnr(50)   TYPE c,  "AccountReference               wrk_delim3      TYPE x ,               name2(80)   TYPE c,      "Address1               wrk_delim4      TYPE x ,               stras(80)   TYPE c,    " Address2               wrk_delim5      TYPE x ,               ort01(50)   TYPE c,   " Town               wrk_delim6      TYPE x ,               regio(50)   TYPE c,   " County / State               wrk_delim7      TYPE x ,               pstlz(10)   TYPE c,   "Post Code / ZIP               wrk_delim8      TYPE x ,               land1(2)    TYPE c,    "Country               wrk_delim9      TYPE x ,               waers(3)    TYPE c,    "AccountCurrencyCode               wrk_delim10     TYPE x ,               telf1(20)   TYPE c,    "ContactTelephone          END OF st_cus .

DATA: wrk_file TYPE char200. DATA: it_customer TYPE STANDARD TABLE OF st_customer,       wa_customer LIKE LINE OF it_customer.

DATA: it_dat TYPE STANDARD TABLE OF st_cus,       wa_dat LIKE LINE OF it_dat.

SELECTION-SCREEN BEGIN OF BLOCK b2 WITH FRAME TITLE text-001.

SELECT-OPTIONS:cust_no FOR  kna1-kunnr,"customer no                com_code FOR knb1-bukrs,"company code                country FOR kna1-land1, "country                creat_on FOR kna1-erdat default sy-datum. "created or changed on SELECTION-SCREEN END OF BLOCK b2.

START-OF-SELECTION.

  IF creat_on-high IS INITIAL.     creat_on-high = creat_on-low.   ENDIF.

  CONCATENATE sy-mandt '_1_'  creat_on-low '_' creat_on-high '_Cust.txt' INTO                       wrk_file.

  PERFORM customer_data_select.    "Customer Data File   PERFORM build_template_data.   PERFORM ftp_file_customer.

*&---------------------------------------------------------------------* *&      Form  CUSTOMER_DATA_SELECT *&---------------------------------------------------------------------* *       text *----------------------------------------------------------------------* *  -->  p1        text *  <--  p2        text *----------------------------------------------------------------------* FORM customer_data_select .

  SELECT a~name1 a~name2 a~kunnr a~stras a~ort01 a~regio a~pstlz a~land1 a~telf1    

"Details of the Customer based on KNA1.        FROM kna1 AS a        INNER JOIN knb1 AS b ON a~kunnr = b~kunnr              INTO CORRESPONDING FIELDS OF TABLE it_customer              WHERE a~kunnr IN cust_no              AND ( ( a~erdat IN creat_on OR a~updat IN creat_on ) OR              ( b~erdat IN creat_on OR b~updat IN creat_on ) )              AND a~land1 IN country               AND b~bukrs IN com_code.

  IF sy-subrc = 0.     LOOP AT it_customer INTO wa_customer.

      SELECT SINGLE waers FROM knvv INTO wa_customer-waers                                            WHERE kunnr = wa_customer-kunnr.. 

      wa_customer-ledgerkey = '12345'.

      MODIFY it_customer FROM wa_customer.

    ENDLOOP.

  ENDIF.

ENDFORM.                    " CUSTOMER_DATA_SELECT *&---------------------------------------------------------------------* *&      Form  BUILD_TEMPLATE_DATA *&---------------------------------------------------------------------* *       text *----------------------------------------------------------------------* *  -->  p1        text *  <--  p2        text *----------------------------------------------------------------------* FORM build_template_data .

  LOOP AT it_customer INTO wa_customer.     MOVE-CORRESPONDING wa_customer TO wa_dat.

    wa_dat-wrk_delim1  = '09'.  "for adding tab after each field     wa_dat-wrk_delim2  = '09'.     wa_dat-wrk_delim3  = '09'.     wa_dat-wrk_delim4  = '09'.     wa_dat-wrk_delim5  = '09'.     wa_dat-wrk_delim6  = '09'.     wa_dat-wrk_delim7  = '09'.     wa_dat-wrk_delim8  = '09'.     wa_dat-wrk_delim9  = '09'.     wa_dat-wrk_delim10 = '09'.     APPEND wa_dat TO it_dat.   ENDLOOP.

ENDFORM.                    " BUILD_TEMPLATE_DATA *&---------------------------------------------------------------------* *&      Form  FTP_FILE_CUSTOMER *&---------------------------------------------------------------------* *       text *----------------------------------------------------------------------* *  -->  p1        text *  <--  p2        text *----------------------------------------------------------------------* FORM ftp_file_customer .

  DATA:  l_user(30) TYPE c VALUE 'ZTEST', "user name of ftp server          l_pwd(30) TYPE c VALUE '1234', "password of ftp server          l_host(64) TYPE c VALUE '111.2.1.198', "ip address of FTP server          l_dest LIKE rfcdes-rfcdest VALUE 'SAPFTPA'."Background RFC destination

  DATA: w_hdl TYPE i,         c_key TYPE i VALUE 26101957,         l_slen TYPE i.

*HTTP_SCRAMBLE: used to scramble the password provided in a format recognized by SAP.   SET EXTENDED CHECK OFF.   l_slen = STRLEN( l_pwd ).

  CALL FUNCTION 'HTTP_SCRAMBLE'     EXPORTING       SOURCE      = l_pwd       sourcelen   = l_slen       key         = c_key     IMPORTING       destination = l_pwd.

* To Connect to the Server using FTP   CALL FUNCTION 'FTP_CONNECT'     EXPORTING       user            = l_user       password        = l_pwd       host            = l_host       rfc_destination = l_dest     IMPORTING       handle          = w_hdl     EXCEPTIONS       OTHERS          = 1.  . *FTP_R3_TO_SERVER:used to transfer the internal table data as a file to other system in the character mode.

  CALL FUNCTION 'FTP_R3_TO_SERVER'     EXPORTING       handle         = w_hdl       fname          = wrk_file          "file path of destination system       character_mode = 'X'     TABLES       text           = it_dat     EXCEPTIONS       tcpip_error    = 1       command_error  = 2       data_error     = 3       OTHERS         = 4.

  IF sy-subrc <> 0.     MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno     WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4     RAISING invalid_output_file.   ENDIF.

*FTP_DISCONNECT: This is used to disconnect the connection between SAP and other system.

* To disconnect the FTP   CALL FUNCTION 'FTP_DISCONNECT'     EXPORTING       handle = w_hdl.

*RFC_CONNECTION_CLOSE:This is used to disconnect the RFC connection between SAP and other system.

  CALL FUNCTION 'RFC_CONNECTION_CLOSE'     EXPORTING       destination = l_dest     EXCEPTIONS       OTHERS      = 1.

ENDFORM.                    " FTP_FILE_CUSTOMER

On running this report in background a file will be created in ftp server location.

Understanding "Coverage Analyzer"

Coverage Analyzer is a very powerful runtime analysis tool provided by SAP that enables an ABAP developer to monitor processing blocks such as reports, subroutines, function-modules and methods.

Powerful filtering system in Coverage Analyzer facilitates developer to enter the number of calls separately according to periods, users and functional areas.

In a nut-shell; Coverage Analyzer is a function for monitoring the system-wide execution of ABAP programs;

It enables the success of test activities to be assessed for quality checks.

It also provides an overview of the use of programs for development purposes.

Developer can use this tool to trace programs for development purpose and Quality Manager can use this tool to check system performance for quality assurance.

It helps carry out a range of Administration Settings and the Monitoring Activity. Moreover it helps get summarized information of number of program executions, number of runtime errors, number of program resets. Fascinatingly, the results can be formatted separately according to user-group; each user-group can contain any number of users under one test key.

Broadly, functions of Coverage Analyzer are classified into two;

1. Administration Settings

• On/Off.

• Test Groups.

• Registrations.

• Reset.

• Settings.

• Monitor.

• Consistency Checks.

2. Display

• Global.

• Detail.

A simple exercise will help us easily understand Coverage Analyzer, rather simply going through documentation.

In order to make use of Coverage Analyzer, user has to have an appropriate role. To check user authorization;

Call up transaction SUIM (User Information System).

Expand Authorizations node.

Choose By Object and execute it (press F8).

Check the presence of authorization object S_COV_ADM in the system.

Confirm the where-used list for profiles using icon or Ctrl+Shift+F11.

Once user authorization is checked to have absolute access to SCOV (Coverage Analyzer) transaction; user can proceed further. If a role is not assigned to a user, Basis consultant has to be consulted in this regards.

In fact, a tip to be remembered is that Coverage Analyzer tool should be used on weekends or in the evening, when all users and packages are on loose ends. Since backup server collects data from all the servers including local and remote; system needs all packages and users to be in the passive mode.

Let’s start up with a simple example to understand Coverage Analyzer in a better way:

STEP 1: Call up the transaction SCOV or navigate through SAP Easy Access->SAP Menu->Tools->ABAP Workbench->Test->SCOV (Coverage Analyzer).

General Status of the system is shown on the right hand pane of the window;

Coverage Analyzer administration includes all of the functions required for carrying out settings and checks.

Administration and Display nodes are shown on the left pane of the window.

STEP 2: Before the Coverage Analyzer being switched on, settings have to be maintained for backup server and filters are to be set. Having not made settings for backup server, if Coverage Analyzer is started, it simply throws out an information message to maintain background server for data collection.

So, Administration settings are to be done before starting up the Coverage Analyzer.

Expand Administration node, select Settings;

Settings function is used to set the parameters for the Global and Detail views, and to filter the programs to be checked via the package.

In order to make settings, switch settings to Change Mode (Cntrl+F1).

Tip to remember: A program is regarded as tested if the following conditions are fulfilled;

Count1 Absolute Value > 0.

Count2 Absolute Value > 0.

RABAX2 Absolute Value = 0.

Unicode Check = 1.

Count1 and RABAX1 indicate the number of programs executed and runtime errors since the Coverage Analyzer was started.

Count2 and RABAX2 indicate the number of programs executed and runtime errors since the last reset.

Further, assign package to be used during analysis. When a package is pre-selected, the evaluation for the Global view is only performed for this package. If this restriction is not applied, all of the programs are included together with those from local packages ($*) and programs generated locally without packages ( ).

If ABAP programs with a set Unicode flag are only to be traced by the Coverage Analyzer, then select Unicode checkbox. Checking Unicode is to mark it as ‘X’, else leave it unattended.

It’s optional to set the lights; lights provide a visual means of representing the status of the results for the degree of coverage in the Global and Detail views.

Lights are set by default, which can be set according to developer’s way of analysis.

RED 0 LT 33 %

YELLOW 33 LT 66 %

GREEN 66 LE 100%

Further, Monitor Settings have to be done, which includes setting Trace Level and Maximum Entries Log and Maximum Entries Data Monitor.

There are 4 different trace levels (1-4), the higher the trace level, the more information is drawn for debugging.

Tip: The values for Maximum Entries Log and Maximum Entries Data Monitor limit the lines displayed for the General Log and Monitor Data Volumes in the monitor function.

The defaulted lines for log file are 100 and for data volume are 200.

Background server has to be specified, where precisely data is to be collected. Moreover, the period for which background job has to be repeated is also to be specified.

The defaulted value for Data Collection: Period (Min) is 30 mins, which can be modified based on developer’s way of analysis. In this case, current server is specified as Background server.

Further, Summarization function facilitates checking the same processing blocks in several systems simultaneously.

Tip to remember: The results from the individual systems are local and those from the remote systems are summarized.

Local Degree of coverage LE 100%.

Summarized degree of coverage LE 100%.

Local Degree of coverage GE Summarized degree of coverage.

To determine RFC connection with current server, call up transaction SM59->RFC Destinations->R/3 Connections->E6SCLNT900.

Desired RFC connections in Summarize coverage results can be specified; moreover period and start time for summarize data can also be specified.

Finally, save the Settings.

STEP 3: Choose On/Off, Status in the Administration node and start up the Coverage Analyzer.

Switch Coverage Analyzer On/Off: This displays the number of programs that have been initialized.

Switch Automatic Recordings On/Off: This displays the automatic recording period and the version number for the Global view.

Switch Data Aggregations from Different Remote Systems: This displays background server and all of the other systems whose results are used for Data-aggregation.

If the server is in switched-off mode exception shows RED signal, GREEN signifies server to be in switched-on mode and YELLOW represents either RFC problem or database and shared memory inconsistency.

In this case, we’ll proceed without switching on Switch Automatic Recording On/Off.

The servers which are actually running are shown as flagged up.

STEP 4: Create Test-Groups; Test-Groups are made to summarize and display the results of the Coverage Analyzer for a particular set of users under one generic key/heading.

Tip to remember: Test-groups should not be created more than 10. Moreover, only users assigned a role with the authorization object S_COV_ADM are allowed to define group.

Two pre-defined Test-groups are always available;

ALL – Coverage results summarized for all test groups on the local system.

COND – Coverage results on the local system as well as remote system.

In this case, we create a test-group.

To create a test-group; switch on the Change Mode, click Append Row icon provided in the application tool-bar.

Define a Test-group following Y/Z naming convention; then save it.

STEP 5: Next step is to assign users to the just-made test-group.

To assign Users to a test-group; switch on the Change Mode, click Append Row icon provided in the application tool-bar.

Select desired test-group for which users have to be assigned; in this case we assign SAPDEV02 as user to test-group ZTST.

Tip: A test-group can contain any number of users, for example, all HR developers in one group. That makes filtering pretty easy. Moreover, comparison of performance of test-groups can be done in Global view.

STEP 6: An optional function to be done is Reset; explicitly this function is intended for situations in which the results of the previous analyses are no longer required. It resets all the counters of the Coverage Analyzer to 0 for all the programs of a selected group.

Further more, implicit reset is carried out automatically as soon as the flow or the data of a program changes.

After successful reset, an information message is popped-up;

STEP 7: Consistency check has to be done for all the servers including remote ones, before proceeding to actual analysis;

Check Status of All Servers checks whether the status in the shared memory matches the status in the database.

Check Status of Background Jobs checks whether all the batch jobs of the Coverage Analyzer are activated. If this is not the case, the batch jobs are all rescheduled by means of the Repair function.

Check Table Consistency (Long Runtime) may become inconsistent if the Coverage Analyzer fails on an application server due to system error.

Repair function also bridges the gap between activating and generating a program.

So, in order to check inconsistencies, check the types of inconsistencies accordingly and Execute Checks, and then choose monitor to check for the inconsistency messages,

GREEN indicates Information message, YELLOW indicates Warning message and RED indicates Error message.

In the present case; no inconsistencies have been found while starting All Servers. In case, there arise any warning or error messages, those problems are to be fixed and then select particular row of the warning/error message and click Completed.

General Log gives general information, while Monitor Volume gives detailed information of started server.

Once the warning is attended, select the row and hit Completed, which will going to turn yellow signal to green signal.

Tip: Every time inconsistencies are checked; General Log should be refreshed.

To select more than 1 message, keep Cntrl key pressed.

STEP 8: Display; gives coverage results at author or package level according to criteria you select under Settings. Display gives high-level view.

Views can be based on Author or Package. ALL signifies all the authors on local system based on view given and the COND (y/z test groups) signifies all the authors on both local and remote systems based on view given. If ‘Other view’ is selected as Package, then selection is done accordingly.

Note: Since Automatic Recordings were not switched on; percentage-based progress display over time cannot be seen for selected SAPDEV02 author.

Normally, Display view gives Quality Managers to view the system, the following way;

Unicode:

This value indicates how many percent of the processing blocks have the Unicode flag set (the flag itself is set per program)

Capacity Utilization:

This value is computed as the ratio of used processing blocks to loaded processing blocks to loaded processing blocks.

Accumulated Executions (Percent)

This value indicates in percent how many processing blocks have been executed since the start of the Coverage Analyzer.

Tested processing blocks (Percent)

This value indicates in percent how many processing blocks have been executed in the actual version without runtime errors.

In the example above you can see that currently 98% of the processing blocks in the system belong to a program that has the Unicode flag set, 26% have been executed since start of the coverage analyzer, 9% have been executed in the active version without errors and the capacity utilization is 29%.

STEP 9: Exact Value Table can be viewed for author SAPDEV02; which displays number processing blocks for author SAPDEV02 on timely manner.

Graphical view of the selected row can be seen using icon; that displays graphical view of the individual date and all dates when no row is selected.

All rows selected for graphical analysis;

Individual selection for graphical analysis;

Tip: Moreover, previous saved history can also be viewed for the specific user.

STEP 10: Details view; gives summarized and detailed results. Details give low-level view.

Strong filtering options allow user to select on what conditions results are to be displayed.

Conditions can be set for range of test-groups, packages and authors pertaining to those test-groups.

In the present example; test-group ZTST and Author SAPDEV02 is taken as single-value selection, which gives results pertaining to specified criteria. Moreover, other filters can also be set and settings should be done defining access via Package Object, Package and Author. Defaulted access-via is Program Object.

Hitting Standard Settings is going to reset all the values.

Once settings are done; hit execute button, that is going to get detailed information, including number of calls made to that particular object, number of processing blocks, load size in Kilo byte. Besides all the information given; double-clicking the object name will navigate to the particular program or executing block where exactly error has been found.

Note: Current Executions = Program units currently used / Total no. of Program units.

Capacity Utilization = No. of Program units currently used / Loaded Program units.

Conclusion: Likewise, many such program executions, runtime errors and program resets can be easily traced using this powerful ABAP runtime analysis tool - Coverage Analyzer.

Understanding "Checkpoint Group"

The checkpoints are the type of statements introduced in the SAP Web Application Server (SAP WebAS) 6.20 that is totally dedicated to ensuring program correctness and maintainability. This improves the quality of software written in ABAP. These checks are transportable and can be transported .The transaction that takes care of these checkpoints and the place where they are maintained is SAAB.

The Checkpoints now can be created for break-points and checkpoints and the two statements for this are

1. Assertions
2. Break-points

The one which actually does not checks the errors but is used to log the data that u want is LOG-POINT.

To start with step by step explanation of the checkpoints we start first with the Assertions.

Assertions syntax as per the SAP Library that is to be used in the coding is as below:

ASSERT [[ID group [SUBKEY subkey]]
[FIELDS field1 field2 table1 table2...]
CONDITION] log_exp.

Assertions are used as a high quality means of problem determination in the case of code failure. Assertions are invoked at run time. They can be made active or inactive. Assertions can be left in code when promoted to production with no impact to the code. They are only invoked if the checkpoint group is activated.

The checkpoint groups can be activated through the transaction SAAB and that is referred by ID in the programs with assert statements.

This is the transaction below SAAB where in the checkpoint group we can create the group ID.

Clicking on the create button below the Name we get to the below screen.

Now the checkgroup activation can be done with three levels

1. Personal Activation
2. User Level activation
3. Server Level Activation.

In the personal level activation that checkgroup will be active for the current user only and for the User the Checkgroup will be active for that user that has been defined and same is for the Server.

The User when clicked there you can define the Specific users for it as this…

And similarly it can be done for specific Servers on clicking on the add Sign as below:

As for the screen below:-

There are three things that can be controlled with the checkgroups.

The breakpoints can be made active or inactive. Inactive then that particular statement will be ignored and if break then in the program wherever the statement occurs the program gets into debugging.

The Statement as per the SAP Library that goes with this in the Program is as below…

BREAK-POINT { [ID groupID]
| [log text] }.

Ex. BREAK-POINT ID YH_check.

Without the addition ID, the breakpoint is always active. The log text is the text which you can specify for the system log which is seen in the logs getting created.

During background processing the program execution is not interrupted. If the program reaches a breakpoint, the entry "Breakpoint reached" is written to the system protocol under which the program name and the location of the breakpoint in the program are recorded. An inactive breakpoint is ignored.

Now taking for the assertions…

Following are the ways the assertion can be used:-

• Inactive (default): statement is ignored
• Log: occurrence is logged
• Abort: program terminates with runtime error ASSERTION_FAILED

The below two options come with a pop-up having options as:-

• Break/Log: program is interrupted and starts the debugger / like LOG mode in background, batch etc.
• Break/Abort: program is interrupted and starts the debugger / like ABORT mode in background, batch etc.

The below two options come as this...

Assertion RULES:

1. Exception handling should always be used to trap and handle failures. DO NOT use an assertion in the place of exceptions.
2. Assertions should only be used on custom code rather than on standard codes.
3. When an assertion is invoked, it should create a log entry unless and until there is a compelling reason to terminate with a run time error.

Here is a sample program where the LOG-Points and ASSERTIONS are used.

REPORT yh1316_test_checkgrp..
** Parameters Declarations
PARAMETERS:
p_carrid LIKE sflight-carrid.

*data : max type i.
*Types Declarations of sflight
TYPES : BEGIN OF type_s_sflight,
carrid TYPE sflight-carrid,
connid TYPE sflight-connid,
fldate TYPE sflight-fldate,
price TYPE sflight-price,
max TYPE i,
END OF type_s_sflight.

*Field String Declarations for sflight
DATA: fs_sflight TYPE type_s_sflight.

*Internal table for Sflight Data
DATA : t_sflight LIKE
STANDARD
TABLE OF fs_sflight.
DATA yh1316_subkey TYPE char200.

IF p_carrid IS INITIAL.
SELECT carrid
connid
fldate
price
FROM sflight
INTO fs_sflight.
WRITE: / fs_sflight-carrid,
fs_sflight-connid,
fs_sflight-fldate,
fs_sflight-price.

APPEND fs_sflight TO t_sflight.
ASSERT ID yh1316_check SUBKEY 'YH1316_parameter_if_initial'
FIELDS p_carrid
t_sflight
fs_sflight-carrid
fs_sflight-connid
fs_sflight-fldate
fs_sflight-price
condition p_carrid eq 'LH' .

ENDSELECT.

ASSERT ID yh1316_check SUBKEY 'YH1316_1'
FIELDS p_carrid
t_sflight
CONDITION p_carrid EQ 'LH' .
EXIT.
ELSE.

ASSERT ID yh1316_check SUBKEY 'YH1316_2'
FIELDS p_carrid
t_sflight
CONDITION p_carrid EQ ’LH’.

SELECT carrid connid fldate MAX( price ) AS max
INTO CORRESPONDING FIELDS OF fs_sflight
FROM sflight
WHERE carrid EQ p_carrid
GROUP BY carrid connid fldate
ORDER BY carrid max DESCENDING.

IF sy-dbcnt < 4.

APPEND fs_sflight TO t_sflight.
LOG-POINT ID yh1316_check SUBKEY 'LOG_POINT'
FIELDS p_carrid
t_sflight
fs_sflight-connid
fs_sflight-fldate
fs_sflight-max.
WRITE: / fs_sflight-carrid, fs_sflight-connid, fs_sflight-fldate,
fs_sflight-max.

ENDIF.
ENDSELECT.
ENDIF.

A variant is created for the Particular Checkgroup created. Variant can be created as a Local as well as at a user level. Here it is created at the User Level.

Click on create and enter the following entries.

There are four kind of object type for which a variant can be created as

1. Check Group
2. Program
3. Class
4. Function Group

And for particular Object type the Different options can be given for Breakpoint, Logpoint and Assert. The Options for them are same as stated before in the Personal Activation screen for check group.

Now save the variant and then go back to the checkgroup for which we have created the variant. Don’t forget to activate the variant.

As above it is seen the Local variant is visible in the Variants tab the same way we can create a Global variant also.

Now run the Program.

If the assertion condition is violated the listed logs are created for the assertion as we have selected the log for assertion in the SAAB transaction in the Check Group.

The log will also be created for the LOG-POINT statement and the SUBKEY there defines the Key to distinguish that the log has been created for which Assertion and checkpoint.

In the Log the data is segregated according to the two Hierarchies:-

1. Gropu/Subkey/Program/Procedure
2. Group/Program/Procedure/Subkey

The log seen is like this.

Double clicking on the Line where the Include line number is seen we can see the description of the log as below.

As we have logged the table entries also double clicking on the table we can see the table entries too.