Page tree
Skip to end of metadata
Go to start of metadata

Identify Senarios for Scripting

Specify exact end user scenario to be scripted: The user scenario documentation is one of the most important steps during  an EEMon Project. It should be regarded as roll-in process where the business users explain a user scenario in detail and provide a well-defined click-sequence through the relevant scenarios.

To avoid unnecessary complexity in the scenarios the documentation step should be performed together with Application Operations team to reflect EEMon limitations and opportunities. Document all end user scenarios in detail, which means a stranger should be able to reproduce it.

  • Prepare screenshots for every transaction step
  • Note down every value used in input fields
  • Note down every mouse click
  • Note down indicators for a successful execution for each step
  • What protocol technology is used? (SAPGUI/HTTP(S)/RFC)
  • In case of HTTP, is an additional plugin used in the browser?
  • What authentication mechanisms are used in case of Http (NTLM, Basic, certificate logon, other)?
  • What authentication mechanisms are used for SAPGUI (user/password, SNC, other)?
  • In case of sapgui, do the scenarios include, e.g., file upload or download, or the use of any complex controls like Html control?
  • Which technical systems are involved?

It is also important to discuss and document the expected EEMon Script execution impact

  • Document business impact on script execution
  • Document roll back strategy for business impact. For example if a script is creating sales orders think about how this orders are removed or invalidated before the production tries to satisfy the requests.
  • Document scenario rollback in case a script execution was aborted in between
  • Estimate performance impact of EEMon on productive systems

Specify Alerting scope for EEMon: Beside a pure description of the interesting end user scenarios it is also important to discuss and agree between business and IT department how retrieved monitoring data would be rated and use for alerting significant IT issues which influence business. 

  • Document if steps are relevant for availability alerting
  • Document if steps are relevant for performance alerting
  • Discuss initial thresholds, maximum tolerances
  • Define propagation rules on how a single exceptionally executed script or part of a script is mapped to the global view of performance.
  • Define Support Components for Incident Management

Specify Reporting Scope: Interactive Reporting in EEMon  reflects the observations of the monitoring. In other words, it is a reporting about the monitoring itself. Every red rating will be written to BW and is therefore visible in the Interactive Reporting. It helps to compare the actual situation with measured end user experience of the past.

For SLA (Service Level Agreements) the Interactive Reporting is not sufficient. The thresholds for the proactive monitoring are set in a way that the administrator is alerted very early to have a chance to correct a problem before it reaches a critical level. So the same physical situation can be critical for an administrator while an end user is still satisfied with the system performance.

SLA Reporting with EEMon is providing a second set of thresholds for SLA purpose to overcome this interest conflict between being alerted very early and reporting exactly at the agreed point of SLA contract.

  • Document if steps are relevant for interactive reporting
  • Document if steps are SLA relevant
  • Define SLA Limits based on SLA Contract
  • Discuss initial thresholds
  • No labels