Skip to Content
Author's profile photo Former Member

How to Replace GRMG with Enduser Experience Monitoring – Part II

Welcome back to the second part of this blog, what we have done so far ist getting the infrastructure ready and create a script that will do the monitoring job for us. The first part can be found here:–part-I

  1. In the step 3.2 “Maintain Scenario” you first create your own scenario and give it a name that speaks for itself. Although you can have several scripts in one scenario, keep in mind that reporting is done on a scenario level. Meaning if you just use the scenario for monitoring and alerting HTTP availability then you are probably well served with one scenario that contains all your scripts for all the systems. BUT if you want to report your systems HTTP availability later on the you are probably better off with one scenario per system.EEM_Step3.2.jpgEEM_Step3.2b.jpg
  2. After you have created your EEM scenario you can assign your systems (ABAP or JAVA) to it. You need to have at least one system in your scenario despite the fact that it is really more important for the Workmode Management than for the monitoring and alerting of the scripts. In this demo case I just put my Solution Manager into the EEM scenario.EEM_Step3.2c.jpgEEM_Step3.2d.jpgEEM_Step3.2e.jpg
  3. In step 3.3 “Assign Script” you will see your script that you’ve uploaded before and can assign it to the scenario you just created EEM_Step3.3.jpg
  4. In step 3.4 “Distribute Script” you deploy your script to the robot(s). Personally I prefer the matrix view here.EEM_Step3.4.jpg
  5. In Step 4 “Monitoring” you should first enter your global Parameters including make sure you have the right password for the SM_EXTERN_WS user.EEM_Step4.jpg
  6. Still in the same step you can also reconfigure the scheduling and thresholds of you scriptsEEM_Step4b.jpg
  7. In step 6 “Alerting” it gets really interesting as here you can define for which scripts you want to have alerts and also enter recipients for notifications. Make sure you do this on script level instead of a scenario level because you ideally have one script per monitored system. This also allows you to differentiate between performance and availability alerting. You can also enter the recipients for the notifications to every alert. After you have entered all information do not forget to click on the “Configure Alerting” button.EEM_Step5.jpg
  8. In Step 6.1 you define how the SLA fulfilment is evaluated. Make sure you have a look at the documentation to choose what fits best your needs. The choices here aren’t really that many and values are calculated over the whole scenario, so if you want to have your SLA fulfilment monitored per system then you probably have to go with one scenario per system or otherwise you are stuck with averaged or best child calculations over several systems.EEM_Step6.jpg
  9. In step 6.2 you enter the thresholds for your SLA fulfilment as in how many milliseconds are still ok for a response time.EEM_Step6b.jpg
  10. In step 7 you can create users that serve you as templates for real life user authorizations. They do not have any technical functionality other than for testing purposes or serving as templates. Make sure to also consult your Solution Manager security guide on this.EEM_Step7.jpg
  11. In the final step you can export the whole wizard as a documentation of what you have done. This is pretty handy.EEM_Step8.jpg

Finally you can enjoy the EEM functions with all the integrations and reporting from transaction SM_WORKCENTER.




All in all it’s a pretty big effort just to monitor an URL the way it used to be in GRMG but it you have crucial systems like your SLD, ADS or CPS then it might be worth it. I think the guys at SAP already figured that out and that’s why they came up with the new URL availability monitoring as of SolMan 7.1 SP12.

Well that’s all for now, I hope you find this helpful.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.