Monday, November 9, 2015

UFLAG field entries in table USR02

Regular entries of field USR02-UFLAG which refers to domain XUUFLAG are following below. However in many customer systems there are many other values which do not refer to the domain.

0        Not locked
32      Locked Globally By Administrator = Locked by CUA admin (User Admin)
64      Locked Locally By Administrator
128     Locked due to incorrect logon attempts or too many failed attempts

Some of the values in there are sums of two different values which are actually present in the domain. For example value of 192:

192     A combination of 128 and 64: 128 + 64 = 192. The user was locked by itself by entering too many incorrect passwords and later it was locked again by Administrator.

There is also common practice by basis people to increase the value of field for all users in the system by e.g. 1. They do this in events of e.g. upgrades when they need to lock all users in the system. Once such an activity is done they decrease the values again by 1 to get to the state as it was before the activity. In case you encounter some strange values in the table it might be got created by such activity.


More information:
1887820 - Incorrect User Lock Status (UFLAG) in table USR02

Sunday, November 8, 2015

SAP NetWeaver 7.5

On Oct 20th 2015 next version of SAP NetWeaver – 7.5 a successor of 7.4 was announced. Main drivers for the 7.5 version are SAP S/4HANA; SAP Business Suite EhP 8 for SAP ERP (both on premise editions) and so called SAP NetWeaver hubs (SAP NetWeaver Identity Management (IdM), SAP Enterprise Portal (EP), SAP Business Warehouse (BW) and SAP Process Orchestration (PO) ).

From technology point of view the 7.5 supports Java 8, it includes enhancements for integration with SAP HANA Cloud Platform, contains innovations in ABAP, and it supports Internet of Things (IoT), mobile, cloud, big data and analytics.

Of course the NetWeaver 7.5 will soon be followed by other of its components (or hubs) with same version number. Therefore let’s look in more details to just technology – or so called basis components of the 7.5. In case ODATA (SAP Gateway) it supports OData version 4. With regards to HANA there is obvious trend that continues of pushing code down to the database and leveraging the information management capabilities of HANA. Speaking of big data the 7.5 has support for Hadoop and multi tiering. In case of Fiori performance optimization is delivered within the 7.5. Lastly within cloud topic there is integration with SAP HANA Cloud Platform (HCP) and the 7.5.

Looking closer at ABAP of the 7.5 the ABAP engine includes programming model via Core Data Services (CDS) for support for web based communication in real time for IoT use over TCP protocols. This is built on concept of the ABAP channels (already introduced in 7.4)

Currently there are following SP of NW 75:
SAP NetWeaver 7.5 SP0                GA 20 Oct 2015


More information:

Detecting debugger in ABAP program

With relation to my recent post “How to determine simulation mode of DTP” where I was blogging about detecting debugger within BW’s transformation’s routines I was curious how to achieve the same with classic ABAP environment. Within the BW’s transformation it was simple there is a clear variable which simple evaluation get the answer weather the transformation is running in the debugger or not.

In case of pure ABAP environment it is not that simple. There are ABAP system field like SY-DEBUG and SY-BATCH which I immediately thought of. However at least in newer versions of NetWeaver (7.x) they seems not be functioning in case of evaluating whether the ABAP program runs in the debugger or not.

As next I found FM TH_GET_DEBUG_INFO which looked from description that it does the job: get debugging info… I tried to put following code into my report:

DATA: lv_dbg_cnt TYPE i.
 CALL FUNCTION 'TH_GET_DEBUG_INFO'
  IMPORTING
DEBUGGING_COUNT= lv_dbg_cnt.
IF  lv_dbg_cnt EQ 2.
   write: / 'dbg is ON'.
 ENDIF.
  IF  lv_dbg_cnt EQ 1.
   write: / 'dbg is OFF'.
 ENDIF.

However this didn’t work out either.

As third thing I found FM SYSTEM_DEBUG_BREAKPOINTS. This FM calls C function called 'DEBUG_CNTL' which finally does the job. Actually the breakpoints seem to be stored somewhere within app server memory and the C function provides them. The above mentioned FM needs to be called up with input parameter MAIN_PROGRAM which’s values is the program that we want to evaluate whether it run in debugger.

Down below is simple call of the FM. In case TABLE parameter’s BREAKPOINTS has at least one row then the debugger is set in source code if input’s parameter MAIN_PROGRAM.

This solution will work in cases someone puts breakpoints manually in source code. Therefore I think it should cover all switches to debugger in case the breakpoints are set. However it won’t cover the case if someone just hits /h and continues to debug the code.

REPORT  ZMM_TEST.
DATA: lt_breakpoints TYPE TABLE OF breakpoint.
CALL FUNCTION 'SYSTEM_DEBUG_BREAKPOINTS'
 EXPORTING
   main_program                = 'ZMM_TEST'
 TABLES
   breakpoints                 = lt_breakpoints.


Tracing incoming RFC or why SAP user is getting locked?

There are many discussion threads on SCN dealing with issue of SAP user which gets locked frequently and reason of this it not know. I recently faced same issue. My SAP user I’m regularly using in one of my SAP system was locked. As I’m using my cloud provider to host the SAP system for me and every time I needed to write an email to provider to unlock the user. After few times of bothering them I obtained new user which I was using to unlock my regular user. I started to use that new user instead of my regular one however from time to time I needed to use the regular user and it was still locked. I decided to invest some time to hunt a mystery of why my regular user was getting locked.

As mentioned I started with having a look at SCN and elsewhere to get an overview what I should do to get the mystery solved. I came a across posts like:

·         this – suggesting to use tcode STAD
·         this – suggesting to use ST03N tcode
·         this – suggesting to use tcode SM19/SM20 – Audit logs
·         this suggesting to use tcode ST01
·         this suggesting to use CCMS
·         this / this suggesting to use report ZRFC_STATRECS_SUMMARY (or tcode STRFCTRACE in newer versions of NetWeaver see Note 931251)
·         and many others.

I went through all of them however I was not able to figure out what was an issue.
One thing was obvious from reviewing all the posts was that it happens because of some RFC call. I checked with rest of developers who shares the same SAP system with me but none of them was using my regular SAP user to run their automated tests. Only thing which was for sure was that in tcode SM21 I was getting entries like following:

7.11.2015
00:51:32 DIA  008 800 MYUSER US  1 User MYUSER locked due to incorrect logon
02:16:58 DIA  001 800 MYUSER US  1 User MYUSER locked due to incorrect logon
17:06:42 DIA  000 800 MYUSER US  1 User MYUSER locked due to incorrect logon

I tried to setup few system profile parameters to increase level of logging. After every such an attempt I unlocked my regular SAP user and I waited to get user locked and I reviewed logs but not a chance to reveal the mystery.

Finally I ran to SCN post which suggested to setup following profile parameter:
rfc/signon_error_log to value 2

The parameter causes that when the RFC logon fails the SAP system create an ABAP dump with all the call’s detail. The ABAP dump is called “CALL_FUNCTION_SIGNON_REJECTED” and it basically provides all information that helps to identify the FCR call causing the issue:

Category               Installation Errors
Runtime Errors         CALL_FUNCTION_SIGNON_REJECTED
Date and Time          08.11.2015 18:11:32
 Short text
     You are not authorized to logon to the target system (error code 53).
Meaning:
53   PASSWORD_ATTEMPTS_LIMITED  Lock counter exceeded
Server-Side Connection Information
Client.............. 000
User................ "SAPSYS"
Transaction......... " "
Call Program........."CL_BGRFC_SUPERVISOR_START=====CP"
Function Module..... "BGRFC_CHECK_SCHEDULERS"
Call Destination.... "xxxx_RFC"
Source Server....... "abcserver_SID_sysno"
Source IP Address... "1.1.1.1"

Based on “Call Program” I was able to identify the thing which was causing the issue. Once I entered proper password to RFC destination actually used for bgRFC in tcode “SBGRFCCONF - bgRFC Configuration” issue disappeared and the mystery was solved!

Tuesday, November 3, 2015

How to determine simulation mode of DTP

Simulation mode of DTP is quite useful function of BW. When there are some issues with the data in target of transformation we can use it to see how actually the data was transformed. In particular we can see in the debugger what is going on with the data within the transformation.

For debugging of the DTP we use Simulation of the DTP.  While using system basically jumps into debugger. For details how to use it see this wiki or online documentation.

While the DTP is running in Simulation mode no data is uploaded into the data target. This basically means that no data is changed. Sometimes there is ABAP code within the transformation where we manipulate further data e.g. in custom tables. Of course running in the Simulation mode we want to avoid manipulating the data in custom tables. As these are the custom tables by SAP standard it is not guaranteed that data is not saved as it is not saved into the BW data targets. So it is up the BW developer to ensure that no data is changed in in custom tables.

To implement it we can leverage the attributes of Simulation mode of the transformation – means Simulation of the DTP. In custom coding we can easily identify heather the DTP is running in the simulation mode. The attribute of simulation DTP carries value "DTPR_SIMULATION" in the request. Here’s example ABAP coding:

    IF request NE 'DTPR_SIMULATION'.
      MODIFY dbtab …
    ENDIF.


This fragment of code can be used in any of start/end/expert routines.