SAP Transaction usage report with component level aggregation
Tamás Holics
SAP + ServiceNow/Jira integration ?? Simplify SAP support and operations using smart automation
There are several reasons why one may want to know which SAP transactions are used in a system and how often. It may be related to security, possibly a manager needs a report or it can be related to SAP licensing.
We've created a simple report to list all transactions used in a specific period, and also get the application components for them and make an analysis on component level.
Why?
We have a special use case, which is related to our SAP add-on product: the ITSM Connector . In a nutshell, it allows SAP users to create tickets in external ITSM platforms, like ServiceNow, Jira, 4me, Cherwell, EasyVista etc.
One key feature of the solution is the automatic routing: it can assign the tickets to the relevant support groups based on transaction or application component (module).
However, in order to make this work, someone needs to map the SAP modules and all custom transactions to the support groups in the connected ITSM platform. This is not a huge task, but we always want to make the deployment of the ITSM Connector as easy as possible, so we partly automated this process.
The problem we solve
Some of our customers have started by exporting the full list of their custom Z transactions to an Excel sheet and then mapping them to support teams in ServiceNow. Later, it turned out that more than 50% of all Z transactions were old, obsolete programs, not used anymore. This made lot of their efforts useless.
Another customer also started mapping all standard transactions to support teams in ServiceNow. They were overwhelmed by the number of standard TCodes, but they were relieved that you can also set up component level rules in the ITSM Connector. For example, all tickets created from any transaction that belongs to the MM module will be routed to the MM support team in ServiceNow.
However, the application component tree in SAP is still huge. It can be up to 5 levels deep and an S/4HANA system contains more than 10.000 application components! Just go and check view DF14VD in SE16...
The solution
Our report reads the standard Workload Monitor logs (ST03), aggregates it and the output is a CSV file that can easily be processed using Excel. This way you'll get the list of transactions that are actually used by your SAP end users, and you can also get all the application components to which these transactions belong. You can also specify the maximum level of the application component hierarchy, on which the statistics are aggregated.
Use case #1 - get only transaction statistics
Let's start with getting all the transactions and nothing else:
After executing the report, it downloads a CSV to your laptop with the following content:
As you can see, all the transactions are listed that were executed in the system since the specified date. The Execution count and User count are the number of times the transaction was executed and by how many SAP users.
The first 21 entries are transactions that do not belong to any application component (are in a package that is not assigned to any).
Please keep in mind that this is our demo system in which only a few users exist, so the User counts are correct.
If we scroll down a bit, we can see that I've executed many business transactions so we have a bit more entries here:
Use case #2 - let's aggregate on component level
Executing the report with the settings below, you won't get any transaction codes, but only the components:
This results in the CSV below. Now you can see how often were transactions in each component executed, up to the Maximum component level, you've specified (2 in this example):
Here you can notice that the User count is always zero. We decided to not calculate that as it can get inconsistent with the next use case: getting data from multiple systems at once.
领英推荐
Use case #3: process multiple systems at once and individually
You can execute the report and specify multiple RFC destinations from which you want to read the logs. Additionally, you can decide to aggregate the results or to keep them grouped by SAP system. This way you can make the mapping even more granular.
Here you'll find that some transactions were only executed in one system, some in many:
You can also see that we are a software development company so most of our transaction usage is in the Basis Component. Scrolling down you'll find some business transactions:
Use case #4: process multiple systems at once and aggregate
Ticking this checkbox will aggregate on system level:
Here you'll find that the SAP system column is removed as all numbers are aggregated:
This may take more time if you have dozens or hundreds of systems, so it is advisable to run this as a background job, and let the output CSV be generated on the application server.
Use case #5: create the ITSM Connector mapping
You can tick checkbox "Add ServiceNow mapping fields" to format the CSV output in a way that you can immediately start mapping the support teams and several other fields (Configuration Item, Business Service, Service Offering, Category, Subcategory, Impact, Urgency, Severity and three additional fields):
After successfully exporting the list, it is super easy to maintain the mapping in Excel. The program can also add your existing mapping rules to the Excel so you can also maintain the changes easily. Also, checkbox "Only tcodes without component" will make the program exclude transactions that are assigned to application components, as it is easier to define rules on component level.
Once you are ready with the mapping, you can simply upload it using another report. You won't need to enter data for every row, there is an order of precedence (transaction - component (per level) - system).
Boom, you have all your modules and custom transactions mapped to a support team in ServiceNow.
Benefits
The deployment of the ITSM Connector was already simple and straightforward, as the technical installation is super easy. Now there is a tool that simplifies the implementation step that required the most manual effort.
Sharing is caring
If you like this article, please share it and subscribe to my newsletter. Additionally,?If you like my posts, please follow me (Tamás Holics) and press the????icon on my profile so you get notified about my new posts.
Impressive insights on optimizing SAP system management – the ability to process and aggregate transaction data across multiple systems seems like a game-changer for efficiency and security.