On October 29, 2019 we ran a Performance Clinic - SAP and Citrix Enterprise Application Monitoring with Dynatrace. Recording of this webinar is available on
And Dynatrace University: https://university.dynatrace.com/ondemand/dynatrace/21409/23740
There have been lots of questions asked by the audience during the webinar and we ran out of time to address them all. In this article, we’d like to answer these questions.
Is the SAP ABAP extension an ActiveGate plugin or OneAgent plugin?
How is the SAP ABAP monitoring extension related to the NAM/DCRUM?
Does the SAP ABAP monitoring plugin require ABAP code instrumentation?
What metrics are gathered when SAP is making requests to an unmonitored host?
How about monitoring RFC calls the same way as the plugin does for T-Codes?
How to enable the SAP ABAP monitoring extension? What are the Installation, deployment requirements?
Does the SAP ABAP extension gather error/crash information?
What are the differences between Dynatrace SAP ABAP monitoring and the SAP Solution Manager?
What is the availability timeline of the SAP plugin?
Can Dynatrace monitor ABAP code down to the call stack level, like it does for Java?
Does the SAP ABAP extension support BW, PI and other SAP modules? Does it work with SAP Java systems?
Which SAP versions are supported by the extension?
Does the Dynatrace plugin require SAP Solution Manager to be present?
Does the SAP plugin monitor only GUI response time or the background jobs too?
What are the T-Codes exactly? Are these just the Windows GUI transactions?
Does the SAP plugin monitor only T-codes, but not RFC?
What are the licensing requirements of the SAP monitoring extensions?
Is the Citrix monitors extension an ActiveGate plugin or OneAgent plugin?
How to enable the Citrix monitoring extension? What are the Installation, deployment requirements?
Does the Citrix extension gather error/crash information?
Does the Citrix agent require full stack monitoring?
Does the Citrix extension work for XenDesktop?
What is the availability timeline of the Citrix plugin?
Does the Citrix plugin report on client connection failures?
How does the custom application for Citrix monitoring visible in Dynatrace relate to the Citrix published applications?
On the Citrix application startup waterfall chart, the breakdown bars don't add up. Why?
On the Citrix application startup waterfall chart, how to interpret the sequence of the bars? Do those events like occur in exactly that sequence?
Do you have more questions? Ask them here and tag with SAP or Citrix, we will do our best to address them all.
SAP extension works in our lab with S/4HANA 1809. We didn't test it with 1709. However, extension uses only standard RFC functions, so chances are high it would work. But you need to verify it yourself.
Thanks for the insightful webinar, Q&A write-up, and SAP ABAP plugin!
We have it running in Preview at two clients and I've had the same question from both: are there any plans to allow T-codes to be grouped together e.g. by function, module or business unit? In NAM we could create BU's and group certain T-code operations together to create views on FI, PM, HR etc. and it also auto-displayed the task and module to which the T-code belongs.
Hi Michael, the latest version works quite nicely, especially in conjunction with the USQL queries - thanks for that.
Is it possible to rename user actions (t-codes) when there are custom t-codes involved? I've looked at naming rules, but they don't quite do what I need: say the custom t-code is /ABC/RT_PI_CAP_CNT, where RT='Retail' and I want to rename that to 'Retail PI_CAP_CNT' I don't think that's currently possible?
I could set up a rule that would rename any custom t-code which starts with /ABC/RT_ to 'Retail' but I'd like to retain the portion after the RT_ in the resulting name too, similar to e.g. 'Sales and Distribution - VF02 (Change Billing Document)' which is a standard SAP t-code. I assume these standard t-codes are somehow auto-detected and renamed in the plugin?
Is there any way to achieve the same for custom t-codes?
The current translation is done in a translation csv that is placed in the jar file in the remote plugin directory.
You could go into that file and add additional ones in there and then kill the java process so it starts up again, but you'd lose your changes on every update, which is not optimal.
I'll add a backlog item of letting you point to an additional csv for your custom t-codes unless user action renaming will be able to handle it soon. I'll point one of the product managers in this direction.
Thanks for the feedback, Michael; I looked for the csv file but only found a .esv file, which looks like the one you're referring to - I can open it in a text editor, but it seems the file uses an encoding format which is not standard to that of csv/txt format.
I'm hoping at some point in the near future, user action renaming will be able to handle it or via the other alternative you mentioned.
Another question, if I may: I see a lot of 'Unknown' GUI versions or in some cases, the GUI version is just blank (empty). What could cause this and is there something I can do to resolve that?
It's indeed that esv file. It's in UTF-8 with euro signs as seperate character (ergo esv 😄 )
The unknown GUI version is curious, could it be that the users don't connect directly the the SAP server? We request a list of all logged in users from SAP every minute (using TH_USER_LIST) and cache the version of users for up to 7 days if they reconnect.
One prospective client is concerned about the 1-min frequency at which the plugin will query the SAP system, suggesting we could cause overhead e.g. response time increase on their SAP system.
Also, they want to know how much data do we 'extract' e.g. traffic volumes since their users are global and the data centre is in Europe. Do we have any hard facts regarding these, apart from what's listed in this forum thread and the documentation?
We have the extension running in several production systems of some of the largest SAP installations in the world without seeing any issues with overhead.
The traffic volume will depend on the system. If you install it we drop the size of data we extract into the extension log file.
Regarding 1-minute intervals: The fact that we use such frequent polling helps generating lower load on the whole system. 1-minute data can be served entirely from SAP app server RAM, with no database interrogation. Longer intervals would force SAP to go to the database for aggregate data. SAP creates those aggregates automatically (that's an internal SAP task, we don't manage it) and writes them to the database. 1-min data is available without aggregates and without the need to go to the database.