In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation. The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.
Discovering Direct Modifications of SAP Standard Objects – One Example
As I discussed in a previous post on this topic, direct modification of SAP standard objects within the SAP namespace carries a high risk in an upgrade project. It would be very valuable to be able to identify some details about these objects, so that further analysis could be performed to determine their disposition in the upgrade.
Modification of standard SAP objects typically requires that a modification registration key be obtained for that object from the SAP SSCR facility. The SSCR facility (SAP Software Change Registration) is a procedure which registers all manual changes to SAP sources and SAP Dictionary Objects. With a valid and authorized OSS ID for an SAP system, you can go to the SAP Support Portal on the web and view the SAP objects that were registered for modification by that OSS ID. If there are multiple OSS IDs for any SAP system, make sure that you check all of them to capture all objects registered by all of the authorized OSS IDs for an SAP system. Press the “Objects Registered by Me” button to view a list of the registered objects.
Another place that you can look for this information is directly within SAP. Table ADIRACCESS stores the registration keys which were obtained from SAP, and which were entered by the developer when the object was to be modified for the very first time. This entry shown below from table ADIRACCESS shows that function group SCPRPS was registered with SAP for modification.
Registering an object for modification does not mean that the object was actually modified.
What additional evidence can we discover that would show that the object was, in fact, modified? And, since a function group contains many objects, can we determine exactly which object or objects were modified?
With a little bit of forensic analysis, we can discover the specific object within the function group that was modified, the user name of the programmer who last modified the object, date of the last modification, and the line-by-line source code differences.
If you are familiar with the structure of function groups, you already know that they may contain many function modules, and that the source code for each function module resides within its own include file. At the moment, we know that the function group name is SCPRPS, but we do not have the list of function modules within that function group.
To obtain that list, we can use the SAP function module FUNCTION_SELECT_TFDIR.
The result list is shown here:
So which, if any, of these has been modified? To determine this, we need to find all of the rows in table TRDIR where the NAME field is equal to the PNAME entries listed above.
Here is an excerpt from SAP table TRDIR for SAP object names that begin with the characters LSCPRPSU:
Note that for all of these objects, which are not in the customer namespace, the Author Username field (TRDIR_CNAM) is ‘SAP’. Also note that for most of the entries listed here, the Last Changed By user name field (TRDIR_UNAM) is also ‘SAP’, except for one row, where the Last Changed By username field is not ‘SAP’. From this row, we can see that include file LSCPRPSU36 was last modified by user DXSDEV on 10/19/2009.
If we look back at the result list of FUNCTION_SELECT_TFDIR and find the row where the field PNAME is equal to LSCPRPSU36, we can see that the name of the modified function module is SCPR_PRSET_CT_IMPORT_INDUSTRY.
Exactly What Changes Were Implemented?
By going to the Version Management Utility for this function module, we can see what the various versions of the code contained. The Version Management Utility will also show us the transport request numbers, date and time, and username for each version of the code. The Version Management Utility also has a code comparison tool which will highlight the line-by-line differences between versions of the source code.
Here is an excerpt from the side-by-side source code comparison utility which shows the modified version on the left side and the original version on the right side. Fortunately, in this instance, the programmer left excellent notes indicating that a correction instruction from an OSS note was being applied.
What Are the Discovery Possibilities?
The manual example described above showed how to discover and analyze customizations that had been applied to a single SAP standard object. But what if the customizations number in the hundreds or even thousands? What about all of the customizations that were built entirely within the customer namespace?
It is possible to discover hundreds or even thousands of customizations regardless of which namespace they were developed in. The key is automation, understanding that this information already resides within SAP waiting to be discovered, and more importantly, understanding the meaning of the discovered information. I have already developed an ABAP discovery program which will mine, analyze, and report data about the following customized objects:
|ABAP Programs||Basic IDOCs|
|Function Modules||IDOC Extensions|
|Function Groups||Message Types|
|Class Definitions||Process Types Inbound|
|BADI Implementations||Process Types Outbound|
|Dictionary Domains||SAPSCRIPT FORMS|
|Dictionary Data Types||Smartforms Forms|
|Dictionary Transparent Tables||Smartforms Styles|
|Dictionary Views||Logical Databases|
|Dictionary Append Structures||FICO Client Dependent and Independent Exits|
|Dictionary Append Fields||Message Classes and Messages|
|Search Helps||Number Ranges|
|CMOD User Exits||Authorization Objects|
|User Exits for the SD Module (MV45AF*)||Authorization Fields|
|Requirements Definitions (transaction VOFM)||SPA/GPA Parameters|
More Discovery – Usage Statistics and Where-Used
Customization Usage Statistics
The goal of customization usage statistics analysis is to discover the usage frequency of customized objects. The usage discovery may show usage anywhere from several times daily by key users, to none when analyzed over a long time period. Since most companies really do not want to incur the cost and the risk of moving an unneeded customization into the upgrade system, objects which show no usage over long periods of usage history become targets. Care must be used here, as some transactions are exercised only quarterly, semi-annually, or annually. I always recommend letting the business process owner make the final decision to eliminate any customization object in the upgrade.
SAP keeps track of usage statistics, and this data is available for you to analyze. You will need to check what facility is available for your particular SAP system, as the transaction codes and programs differ among various versions of SAP. The amount of data stored within SAP is configurable, and is usually set to a small date range. Some companies that want to analyze the statistics over longer time periods actually download and store the statistics data in their own external databases.
Like usage statistics, the goal of customization where-used analysis is to discover customized objects that are orphan or not being used. What about that custom data type that is not used in any table or structure? What about that function module that shows an empty list when you click the where-used icon in the function builder?
To properly perform a where-used analysis, it is important to understand all of the various possible uses for an ABAP object. For example, here is the selection screen of possible uses that is presented by the ABAP Dictionary when you click the where-used icon to determine the where-used list for a data table:
And what about that custom function module, which I alluded to earlier, which shows a completely empty where-used list? Perhaps it is a remote-enabled function module that was installed by, and is currently being called by an external third-party package. Or, perhaps it is linked to an SAP EDI inbound or outbound process code. It is really important to be able to properly interpret the data being presented and to not draw any hasty conclusions.
ABAP Programs Where-Used Analysis Example
In the ABAP workbench, SAP provides a where-used facility, which reports the various areas where a single selected object is used. For a discovery project, you may want to automate this facility to analyze groups of ABAP objects (e.g. all custom ABAP programs, all custom tables, etc.).
Here is an ABAP programs where-used analysis example to help illustrate how a where-used analysis might be utilized.
Your automated where-used analysis program to analyze custom ABAP programs reports fifteen custom programs which show no usage in any of the following areas:
A quick analysis shows that all of these fifteen programs are simple reports. Since users typically execute their reports via transaction codes, you wonder how these fifteen programs could ever possibly be executed without transaction codes.
You further analyze the SAP job scheduler data as far back as possible and find that only ten of these ABAP programs were ever scheduled in a batch job. Some of these were scheduled very recently, and some have not been scheduled for a long time (another thread of evidence that we will need to pursue). This leaves five ABAP programs with no apparent means of being executed.
As further evidence, you perform a cross-check against the usage statistics report and find that two of these five ABAP programs show no usage.
Armed with this analysis, you are now ready to meet with the business process owners to discuss the disposition of the objects on your short list.
A salient point here is that you will need to gather your evidence from several different analysis sources to help paint the most accurate picture about the possible disposition of customized objects.
Throughout all three parts of this post, I have stressed that customizations, while necessary, add risk and cost to an upgrade project. And customizations that are not necessary or built poorly without the constraints of best-practice controls can add high levels of risk and cost. Here are some general guidelines to follow:
Many companies and their auditors consider a well-controlled and secure ERP system to be a fundamental component that is vital to the success of the business. They recognize that an out-of-control ERP system can easily paralyze a company for extended periods of time. With this in mind, implement and enforce best-practice controls and standards to make sure that future customizations are reviewed, approved, built, tested, documented, and implemented properly. This may already be an internal or external audit requirement, so check with your inside and outside auditors to make sure that your controls meet the auditing requirements.
Periodically review, audit, and amend your best-practice controls to make sure that they are still effective in supporting the needs of the business; and that both internal staff and external consultants are in compliance of these controls.
Know your customizations. Know where they are, why they are, and what they do. Whenever feasible, it is most efficient to eliminate ABAP object customizations, especially any that were performed within the SAP namespace, and any that are not really needed because they can be implemented within standard SAP.
The degree of risk and cost depends on the specific type of customization that was performed. Establish a formal review board to own the customization approval process. Understand that approving a customization also means approving the risk and the cost burdens. Some companies consider this to be so significant, that they include a high-level business executive as a default member of the review board.
Set and enforce a policy making ABAP object customization the last resort, only after all other options have been thoroughly researched and exhausted. Here are some examples:
- Research forums, blogs, become active in user groups, etc. to see how other companies might also be implementing the business function that you require.
- Find and use customer and user exits instead of directly modifying objects in the SAP namespace.
- Determine, for example, how to implement and maintain that complex pricing procedure using the pricing condition tables instead of writing custom code and building custom tables.
Share Your Experience.
Once again, I look forward to hearing from our readers to reply to this post with their own experience with customizations, best-practice standard and policies, and success stories illustrating how your company transitioned to best-practice controls.
[Editor’s Note] This blog is third of a multi-part series: