en eem whitepaper7.1

7/17/2019 En EEM Whitepaper7.1

http://slidepdf.com/reader/full/en-eem-whitepaper71 1/5

End User Experience Monitoring A question of the perspective

Today’s business processes are embedded in a global market with participants all over theworld. To guarantee the highest availability and performance from almost every location isnot just a challenge for huge companies anymore. SAP End-User Experience Monitoring(EEM) is an efficient toolbox for evaluating and reporting the availability and performanceof your productive systems from multiple client-side perspectives.

Contents

Introduction ....................................................... 1 Reliable Synthetic Load .................................... 2 E2E Trace Analysis Integration ........................ 2

Realtime Monitoring UI ..................................... 3 Alerting Infrastructure ...................................... 4 Reporting........................................................... 4 Where to find more information ....................... 5

INTRODUCTION

Methodology for determining whether IT is actual-ly usable from the perspective of the person oper-ating it is conventionally called end user expe-rience monitoring. Usability in this sense is gener-ally defined by the system's availability and per-

formance and is simply another name for the abili-ty to carry out a given task correctly and within anadequate timeframe. These methods do actuallyreflect the actual usability by collecting the datafrom the system users themselves and far awayfrom the server rooms.This approach seems unusual at first and wouldappear to take many an IT manager all too quicklyout of their comfort zone: after all, didn't we al-ways strive to document every aspect of our ITsystems by collecting thousands of measure-ments to prove that it was working correctly?Where Laplace was concerned, the goal was al-

ways to collect ever more measurement data at

ever decreasing intervals to describe the systemin ever greater detail. Unfortunately, even a quicklook at the support components forces determin-ism – also long since obsolete in physics – intothe realms of insignificance. Unmoved by the di-versity of measurement values available, endusers simply rate their IT system as either "Itdoesn't work!" or "It's slow" ˗ terms which can besuperimposed exactly over the aspects of availa-bility and performance that are observed in EndUser Experience Monitoring. So the concept ofmeasuring and verifying precisely what the user orcustomer wants and understands isn't far off themark.In terms of technical implementation, there arebasically two different points of departure: Themore apparent method attempts – put simply – to"look over the shoulder" of the user and to sendmeasurement data about the observed transac-tions to a central evaluation server. Depending onthe configuration and manufacturer, this can takeplace permanently (in the case of monitoring) or,in the event of an error, for analysis purposesonly. To counteract the feeling that employees arebeing placed under scrutiny, these solutions pro-vide a number of sophisticated anonymization andsecurity settings. If this bitter aftertaste persists oryou're worried about this kind of measuring struc-ture gaining widespread acceptance in your com-pany, there is an alternative approach, which alsoprovides decisive technical advantages.



Copyright/Trademark

RELIABLE SYNTHETIC LOAD

The approach adopted by SAP End User Expe-rience Monitoring (EEM) dispenses with humanusers as a source of data, relying instead on anetwork of artificial helpers who carry out transac-tions on site in the respective regions, reportinglevels of availability and performance of the IT

systems being used to SAP Solution Manager inthe process.These EEM helpers – known as "robots" – areinstalled on inexpensive desktop computers andoperate in the system landscape like genuineemployees or customers. They open portal pages,check shopping baskets, search databases, andcomplete SAPGUI forms, because the scriptsexecuted for these purposes were created bymapping precisely these activities, which are ac-tually reserved for human users. So on the systemside, these EEM robot activities are completelyunobtrusive and it's difficult to distinguish them

from those of normal users. They are carried outon an equal footing and are therefore a repre-sentative indicator. As the name "EEM robots" suggests, it is the ad-vantages provided by automatic load generationthat more than make up for the not inconsiderableinitial outlay for creating the scripts. Just like in-dustrial robots, the EEM robots go about theirwork resolutely, tirelessly, flawlessly, and withoutinterruption.Instead of simply waiting for a problem to arise,they are responsible for proactively monitoring alltransactions without exception, even if no real

user is currently using the function in that particu-lar region, either due to the local time difference orbecause the transaction is only used in infrequentbut extremely urgent cases. So in an emergency,you save valuable time and, depending on theerror, the application is up and running again be-fore your colleagues abroad have even startedtheir breakfast.One of the robot strategy's principal benefits is theability to reproduce script executions and the re-sulting ability to compare individual executions,either locally or between different regions, usingvarious robots as the data source. This way, it's

relatively easy to assess whether a problem islocalized, so it can only be observed in one loca-tion, or whether business processes are beingdisrupted globally for all EEM robots and it istherefore more an issue with the central IT sys-tem. So you monitor the behavior of a certainscript for numerous EEM robots.The opposite approach of examining one particu-lar robot and the different script types executedthere makes it easy to distinguish between a ge-neric network problem and more specific causes.If several scripts that are disjunctive from oneanother in terms of their content are affected bymalfunctions simultaneously, you don't have to be

a mind-reader to suspect that the cause of thebranch's problem is generic and more technical innature.So as you can see, with its broadly based mea-suring set-up and simple status comparisons,SAP End User Experience Monitoring providesimportant indications as to the cause of the prob-lem with no need to apply a more detailed under-standing of the script processes.Naturally, individual steps for scripts and detailederror notifications for each step are also shown inEEM RealTime Monitoring. Consequently, notonly the implemented business process as awhole but also individual steps can be evaluatedand analyzed specifically according to the criteriaof availability and performance. So to put it simply,the script represents a business transaction andthe stages of the script a user interaction, such asa button being pressed or details being entered ona request screen by the user or robot.

Knowing the stage at which a script is executedwith which error status considerably limits therange of possible causes. If the system returns"Wrong Password or Username" as confirmationof the first step, an error search will probably in-volve something more obvious than an intensivelock table or heapdump check.

E2E TRACE ANALYSIS INTEGRATION

Unfortunately, the expectations of an ideal busi-ness transaction are diametrically opposed forproductive human users and End User Expe-rience Monitoring. To achieve optimal evaluations,

from an EEM perspective, it is preferable to adoptthe most linear approach possible, taking thesmallest possible steps. The better you can splitsubtasks into separate steps, the easier it is topinpoint a certain component as being responsiblefor an incident. A user-friendly application, on the other hand, isdesigned with the aim of relieving the operator ofany complexity, carrying out as many activities aspossible in the background, which is what the userwants. This digital equivalent of an Aladin's Lampis a nightmare for pure End User Experience Mon-itoring: Just one click of the mouse and everything

happens in the background, as if by magic. Merelypushing a button triggers a frenzy of activity andhectic goings-on behind the scenes as dozens ofRFC connections are used for a variety of data-bases and systems, data is consolidated, opera-tions wait for work processes, and lock entries arewritten and deleted.From the user's point of view and, unfortunately,also the EEM robot's perspective, all you get isthe monotonous rotating hourglass until the resultis displayed. Or not. So the measured values thatthe EEM robot can send to SAP Solution Managerin this situation are probably of little help in nar-rowing the problem down.



Copyright/Trademark

At this point, it may comfort to you to know thatthe measurement enables a localized, objectivequantification of the bottleneck to be carried outand this information is provided proactively, evenbefore a real user has had to report the problem.But a really satisfactory solution must go a stepfurther, look behind the curtains, and shed somelight on the hidden procedures going on behindthe scenes. For this, SAP End User ExperienceMonitoring uses SAP Passport Technology, whichis also used by E2E Trace Analysis.Every message that is sent by the EEM robot tothe IT system has an "SAP Passport" attachment.The SAP Passport contains a unique ID numberand details about which information the other per-son should retain for analysis purposes while theactual request is being processed. If processinghas to be continued in the background on anothercomponent, the SAP Passport is forwarded to-gether with the request and the local systems are

instructed to also retain information about theprocessing.To continue with the same metaphor, the robotstill might not be able to look behind the curtainsitself, but it is now in a position to slide a businesscard underneath them, including the request tokeep a record of all activities taking place behindthe scenes and to ensure that everyone involvedlearns of this procedure by word of mouth. So inRealTime Monitoring, script execution and all itsassigned steps are reported by an EEM robot andsimply evaluated in terms of availability and per-formance as before. In a downstream process, the

IT system's involved components are addressedby SAP Solution Manager and the informationstored there is requested in line with the relevantSAP Passort ID number. The RealTime Monitor-ing UI now shows more the individual script stepsin greater detail and lists, for example, the in-volved SAP systems, RFC times, client times, andHTTP times. By the time you switch to the E2ETrace Analysis at the latest, the curtain is fullyraised and, depending on the configured level ofdetail, a bottleneck can be accurately analyzed,for example, by ABAP, Wily, or SQL Traces.So that you don't have to choose between minimal

influence on the IT system through tracing and thein-depth analysis option, SAP End User Expe-rience Monitoring offers you three ways of in-creasing the level of detail if required. You canexecute another one-off script manually with afreely configured level of detail whenever you likeand without permanently changing the regularexecution configuration. However, you can alsoincrease the level of detail for a fixed period oftime before the script returns to its normal settingsautomatically. If a measured runtime is exceeded,the third option automatically ensures that themeasurement is repeated immediately with a free-

ly configurable level of detail. The latter two me-

thods are particularly well suited to getting to thebottom of phenomena that occur sporadically, canseldom be selectively reproduced, and generallygenerate frustration on the part of users and sup-port personnel.Who's never experienced this before: "Murphy'sLaw" ensures that users first have to convince thesupport staff that there is a problem before it istaken seriously. Having laboriously convinced theperson responsible that there really is a problem,this individual then repeatedly executes the trans-action successfully as similar complaints graduallyaccumulate. With SAP End User Experience Mon-itoring, the EEM robot takes care of the arduousdetective work and reports its findings to Real-Time Monitoring.

REALTIME MONITORING UI

The RealTime Monitoring UI is the central analy-sis platform for End User Experience Monitoring

data. Based on Adobe Flash, this application isaccessible via the Technical Monitoring workcen-ter and mainly comprises tab pages that query aselected group of script executions in certain loca-tions from Solution Manager over a specific periodof time. Or to put it more simply: You specifywhich scripts you're interested in, which robots areto focus on them, and how far into the past youwish to look.In the next step, you decide how the requesteddata should be displayed by choosing one ormore views (more commonly known as "apps") forthe tab page. You can choose from a number of

options, including tree structures, pie charts, curvediagrams, and tile views. Depending on the taskat hand, these are of varying suitability for provid-ing an overview or comparing different executionsin detail. What they all have in common, however,is that they always operate using the data re-quested on the tab page. So they always showthe same thing but they display it in differentways.



Copyright/Trademark

If the requested data is no longer in the local databuffer, the RealTime Monitoring UI requests con-solidated data from Business Warehouse. Sotaking a quick look at the previous year's datadoesn't force you to switch to an unfamiliar BWWeb template environment. There are countlessoptions and workflows on the RealTime Monitor-ing UI, but most are intuitive to learn.

The operational demo version will give you aquick introduction and can be found at:http://wiki.sdn.sap.com/wiki/display/EEM/Home.

ALERTING INFRASTRUCTURE

Globally monitoring the usability of businesstransactions in real time and, if required, beingable to carry out a detailed technical analysis is afascinating opportunity. But if you're beginning tofeel like you'll be sitting in the Kennedy SpaceCenter control room, you're in for a disappoint-

ment, because although Realtime Monitoring isaesthetically appealing and functional, it won'tconstantly be the focus of attention and only rarelyyour initial access to End User Experience Moni-toring. Generally, the EEM robosts will be left todo their work in the background while you concen-trate on more pressing matters.Here, you can totally rely on the alert infrastruc-ture of Solution Manager 7.1. If an EEM robotmeasures unexpectedly long response times orunearths functional deficits, an alert event iscreated in the Unified Alert Inbox, the person re-sponsible is informed by text message or e-mail,

and, depending on the configuration, an incidentcan also be generated. A direct link to RealTimeMonitoring then enables you to investigate thisimmediately. A sophisticated algorithm also pre-vents a problem that is already reported but stillneeds time to solve from attracting too much at-tention with a constant stream of alert events andtext messages, thus obscuring other events.

REPORTING

The final data sink in SAP Solution Manager 7.1 isBusiness Warehouse and this is also how EEM

data from the local data buffer is eventually storedin consolidated form in BW. You can access thisoverview data using RealTime Monitoring and avariety of BW Web templates in Interactive Re-porting. The criteria used to assess whethermeasured response times are expected values orexceeded critical thresholds are rigorously trans-ferred from the alerting configuration. So reportingcorresponds exactly with the data displayed in theMonitoring application.However, if BW is used for verification purposeswithin the context of a service level agreement

(SLA), this threshold philosophy could soon elicita conflict of interests. On the one hand, thresholdvalues and their associated alerts are importantindicators for quickly identifying inconsistenciesand, if possible, rectifying them even before theyreach a really critical level. On the other hand, theservice level agreement precisely defines thethreshold values, thus reducing the advancewarning time to almost zero. Help here is providedby an independent set of threshold values forservice level agreements in SAP End User Expe-rience Monitoring and an additional disjunct reportfrom Interactive Reporting. This enables adequateadvance warning using appropriate alerts, while atthe same time providing accurate reports for theservice level agreement. In this context, "accu-rate" also means that an agreement has beeneither upheld or broken, so only one thresholdvalue that clearly defines this limit must be speci-fied.

To display the collected SLA data, an SAP Xcel-sius-based application is used which is limited topresenting relevant core data. So for each of the"availability" and "performance" categories, youcan immediately see the percentage of cases inwhich the defined thresholds were adhered to.Using the green and red color coding, you cansee whether these percentages meet the specifi-cations of the SLA, and the previous month's datais also displayed in graphical format. It is no long-er necessary to have a detailed knowledge of theunderlying threshold values for interpretation pur-poses. Causal research and the search for admin-

istrative countermeasures remain exclusively re-served for the field of RealTime Monitoring andE2E Trace. Reporting in the field of service levelagreements is aimed primarily at external andinternal customers of an IT solution who expressonly a certain level of interest in the technicalbackground so long as the usability can be guar-anteed and documented.

http://wiki.sdn.sap.com/wiki/display/EEM/Home





WHERE TO FIND MORE INFORMATION

If you want to know more, please consider the following resources:

End User Experience Monitorin g in SDN:


Technical Operations in SDN

http://wiki.sdn.sap.com/wiki/display/TechOps

App lication Li fecycle Management in general

http://service.sap.com/alm










en eem whitepaper7.1

Documents