Avoiding Business Impact of Scripts
End User Experience Monitoring is used to provide performance and availability information about productive system landscapes. EEMon executes scripts from distributed locations against productive systems acting like real users in the landscape. That means from the server side perspective it is not possible to differentiate between actions performed by EEMon or actions triggered by business users. This guarantees that the measurements reflect the experience a real end user feels for the same activity at the same time.
The disadvantage of this synthetic probes in a productive system is easy to discover: Business Impact caused by automated script executions.
An very simplified example would be a script creating sales orders automatically to proof that this important business function is available.. For sure this is possible but what to do with the sales orders afterwards? Remember the script could be executed several times an hour and this from several different locations!
It is obvious that a strategy is needed to hande this kind of monitoring needs and the side effect of unwanted business impact:
Avoidance is better than disposal
This simple aphorism is not only valid for nuclear waste but sometimes it needs a bit willingness to think about this strategy in the area of EEMon. There is a great tendency of EEMon Administrators trying to model the scripts as close as possible to business scenarios to have authenticity on their side in discussions with business owners.
This includes a desperate affinity to insist on write/commit steps in EEMon scripts.
Let’s use a real life example:
Assumed you reach your office by car it may be of interest in the morning if your car is “available” for this trip.
A simply set of instructions for car-availability could be
- Enter the garage
- Have a look if the car is inside
- Start the Engine
- Drive to office
For sure, if all this steps are executed successfully you have the proof that the process is available and you could reach the office in the morning.
Of course it makes no sense to execute the car-check procedure yourself, so you should think about a monitoring infrastructure that is doing this repetitive work for you.
Instead of an EEMon Robot and EEMScripts we continue with the same real life metaphor and ask your 7 year old son to act as test robot to check the car availability before breakfast: Now the situation changed, you see? Some instructions which seemed to be simple appear very risky now, some other tasks seem pretty undefined having a closer look…
- Do you really want to ask your son to start the engine alone in the garage?
- Do you really think “Drive to office” with all those changing traffic situations outside is a full description on how to reach the office without “impact”?
- Are you allowed to ask him to drive?
- Isn’t the risk higher than the benefit now?
The lesson to learn from this example and to understand as well for the EEMon area contains at least two messages:
- If you insist to start the engine as a test procedure you have to live with the risk that your son is alone with 2 tons of moving steel.
- Whatever effort you invest to describe the way to your office and how to handle certain situations you will never teach your little son to manage that task because the traffic scenario is different every time.
Or translated to the EEMon area:
- If you insist to execute critical transactions in a productive system you risk to have a business impact
- You can only script scenarios which are deterministic. You know the exact starting conditions and a well defined pathway to execute all necessary steps.
But there is more to learn with the car-availability example. It shows EEM Administrators sometime don’t focus on the real target and forget what they can achieve with a pretty small invest/risk.
- Entering the garage: Be honest, how many times you lost time because you could not find your keys in comparison to a real issue with the car?
- Have a look if the car is inside: Why? Wait until your son is 18 years old…
- Start the engine: Too risky for your son? Did you know that the most cars are not starting because of the empty battery? Ask him to put on AND off the lights and you don’t need to be a prophet to predict if the engine will start. Without any risk for your son and the car.
- Drive to office: We already know that we cannot really provide proper instructions how to manage this complex task for a kid but is it really necessary? All the factors that may influence the process of “driving to the office” are not under your control or responsibility. A test drive at 8pm will not predict the traffic jam at 8:30 or tell you if a different way would have been better…
This results to a smart instruction set:
- Enter garage to proof you have the keys
- Have a look if the car is inside
- Turn on/off the lights to predict the engine start ability in 90% of the cases
- Don’t care about the world outside because it anyway changes till next test or real drive
If you know want an example what the SAP term “Continuous Optimization” in context of the Operation Control Center could mean: Ask your son to switch on the radio instead of the lights to proof the battery and listen to the traffic news at once. ;o)
The message translated to the EEMon area is similar:
- Avoid write-access and commits where ever you can. The effort and risk exceeds the benefits fast. There are often other ways to cover the 99% case with 5% of the effort. => Avoidance is better than disposal
- Keep the scripts simple and short! Script only scenarios if the corresponding infrastructure are under your control. You anyway cannot fix the “internet” if it is slow.
A more specific example: Enter a webshop, fill the basket, calculate the price, include some discounts, trigger availability check for goods BUT don’t press order button!
Strategies if it is not possible to avoid the commit in a productive system
In some cases it may not be possible to avoid a write operation during script execution. In this case EEM administrators use different strategies to avoid a business impact due to monitoring activities.
Fake goods in stock
Some EEM scripts are ordering or processing dummy goods in a productive environment which satisfy several nice requirements for an easy scripting process.
- Low price of 0.00 to avoid impact
- Significant dummy name to avoid mistake
- Unlimited availability for easy scripting
Normally this strategy is combined with a rollback process which wipes out the fake transactions frequently
Test user with different treatment
Of course an EEMon script is always running with a dedicated user for monitoring purpose but normally the user is treated like all other dialog users in the system. For the system it makes no difference whether a human or EEM Robot logs on.
It might be possible to chance that behavior in the way that the user is treated different in the system and therefore is hindered to create business impact
- Requires modification in target system
- Depends on software and customizing
- Monitoring results may differ from real user experience
Executing transaction in a non-productive client
- If productive and non productive client share the same technical infrastructure the measured system performance and availability should match to a certain degree
- Executing business transactions in a different client may require a customizing in the client
- RFC connections to other systems are client depending
- Some business data maybe cross client
Rollback with external batch jobs
Sometimes it is needed to remove data artifacts from monitoring in a productive system to avoid business impact. This could be done for example by a batchjob scheduled in the systems
Rollback with scripts
Sometimes a script is used to create and delete a manipulation in the business system in the same script run. For example creating a sales order and invalidating it afterwards. This is feasible but can cause issues if the script is aborted in between the two steps. Therefore the EEMon is at risk to create orders but to skip the deletion.