04. 12. 2019
Unified Monitoring
14. 09. 2026
Franco Federico
APM
When Automation Cleans Up After Itself: An Alyvix Story on Dynamics AX
Every automation project starts with a clear goal, but the interesting part almost always shows up later. This is the story of how a synthetic monitoring test case on Microsoft Dynamics AX did exactly what it was supposed to do, and how that success eventually created a problem that only further automation could solve.
It’s also a story about a simple idea: If a task is repetitive enough that a human would spend months doing it, then it’s probably a task a robot should be doing instead.
A quick clarification before we begin: Alyvix wasn’t born to do this kind of work. Its core purpose is visual monitoring, driving an application’s GUI exactly as a real user would, to measure whether a business service is available and how it performs. Using it to bulk-edit or clean up data is well outside that original scope. But as you’ll see, sometimes the tool you already trust for one job turns out to be the most sensible way to solve a very different one.
The Context: Monitoring a Business Process, Not Just a Server
For an enterprise customer within the Würth Group, we were asked to implement test cases on Microsoft Dynamics AX using Alyvix, our visual synthetic monitoring tool. The point wasn’t to ping a server or check that a service was up. It was to answer a much more business-relevant question: Can a real user actually complete a real transaction right now?
The transaction in question was a sales order for a specific product, including the consumption and reduction of that product’s stock. Alyvix drives the GUI exactly as a person would: It moves through the Dynamics AX interface, clicks, types, reads the screen, and verifies that each step behaves as expected. If a human were doing this by hand every few minutes, all day, forever, it would be unthinkable. For Alyvix, it’s just Tuesday.
This first challenge was completed successfully. The test case went into production, ran every 15 minutes, and we started collecting metrics on how the ordering process was really performing.
The First Twist: Success That Runs Out of Stock
Here’s the thing about simulating a real sales order: It has real consequences. Every run consumed a bit of stock for that product. And since the test ran every 15 minutes, after a while the inevitable happened: The product ran out. The item was no longer available, and the test case that had worked perfectly began to fail. Not because Alyvix was doing anything wrong, but because it had done its job too well.
After several meetings with the customer, we agreed on a solution that had a certain symmetry to it: build a second test case that puts the missing material back in. We wired it so that every time an order was created (reducing stock on one side), the replenishment ran too (topping it back up on the other side). Consumption and restock, in balance. Two test cases, working as a pair.
And for several weeks, this worked.
The Second Twist: The User Account That Got Tired
Then we noticed something new. The account Alyvix used to perform these operations had started to misbehave. It could no longer navigate Dynamics AX correctly – the flows that had been reliable for weeks became erratic.
Our first instinct was the usual one: Increase the timeouts so Alyvix would wait longer before flagging an error. It felt reasonable. It was also wrong. Longer timeouts didn’t fix anything; if anything they made the situation worse, by letting a bad state drag on instead of surfacing it.
So we stopped patching the symptom and decided to properly clean things up.
We sat down with the customer’s team to plan the remediation, and that’s when the real problem revealed itself: There was no simple cleanup procedure. All the data that Alyvix had inserted over the weeks had to be removed by hand, element by element. To put that in perspective, it meant repeating the same sequence of steps thousands of times. An enormous amount of manual work that would deliver zero business value. Pure toil.
We did consider the easy way out: Just switch to a different user profile and move on. But that would have been a convenience, not a solution, since the mess would still be sitting there. So we made a different call. If the problem was thousands of repetitive GUI steps, then we already had the perfect tool to handle repetitive GUI steps.
We decided to use Alyvix to clean up after Alyvix.
The Third Test Case: Passing the Key through the Clipboard
I designed a third test case to perform the repetitive cleanup actions. The logic itself was straightforward: Navigate to an element, remove it, delete it, and move on. But it had exactly one point where it needed outside information: the primary key that uniquely identified the specific element to delete. Everything else was mechanical – that single value was the only thing that changed from one iteration to the next.
So the question became: How do we feed thousands of different keys into a GUI automation flow, one per run?
After thinking it through and comparing notes with the colleagues who work on Alyvix with me, we landed on a simple and robust approach. We wrote a small Python script that reads the primary keys from a CSV file (the file containing the thousands of keys to be removed) and places the next key into the system clipboard. Alyvix, trusting the value it’s handed, simply performs a paste at the right moment and proceeds to remove and delete the element.
Since Alyvix itself is built on Python, the choice of language was almost automatic. Writing the helper in Python meant it would run natively on the same Windows machines that already host Alyvix, with no additional runtime to install and nothing new to maintain. We deliberately kept the script lightweight and dependency-free. It uses only the Python standard library and the built-in Windows clip command, so there’s nothing to pip install and nothing that could break on a locked-down production host. The whole thing is a single file that lives next to its CSV:
import os
import subprocess
# CSV file in the same folder as the script
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
CSV_FILE = os.path.join(BASE_DIR, "file1.csv")
def copy_to_clipboard(text):
"""Copy the text to the clipboard using the Windows 'clip' command."""
subprocess.run("clip", input=text, encoding="utf-8", shell=True)
def main():
try:
with open(CSV_FILE, "r", encoding="utf-8") as f:
lines = f.readlines()
except FileNotFoundError:
copy_to_clipboard("problem with file")
return
if not lines:
copy_to_clipboard("problem with file")
return
# Take the first line (stripping any trailing newline)
line = lines[0].rstrip("\n")
# Copy it to the clipboard
copy_to_clipboard(line)
# Rewrite the file without the first line
with open(CSV_FILE, "w", encoding="utf-8") as f:
f.writelines(lines[1:])
if __name__ == "__main__":
main()
The design is intentionally boring, and that’s the point. Each run pops the first key off the CSV, drops it into the clipboard, and rewrites the file without that line. So the CSV doubles as both the work queue and the progress tracker. If the file is missing or empty, the script writes a plain “problem with file” marker into the clipboard, which Alyvix can recognize and stop at instead of blindly pasting garbage.
It’s almost a humble mechanism, the clipboard as a communication channel between a script and a GUI robot, but it’s exactly the kind of pragmatic bridge that makes visual automation so flexible. Alyvix doesn’t need to know where the key came from; it just needs it to be there when it reaches for it.
With this in place, we let the third test case run through the entire backlog, temporarily suspending the production-related activities so the cleanup could work undisturbed. Element by element, thousands of times, without complaint, it remediated the whole history that had accumulated over the weeks – work that would have cost a person months, done in a fraction of the time and with none of the fatigue that had caused the problem in the first place.
What This Project Taught Me
A few lessons stuck with me from this one:
- Simulating real transactions means accepting real consequences. If your synthetic test consumes stock, creates orders, or writes data, you have to design for the footprint it leaves behind.
- Timeouts hide problems; they don’t solve them. When a flow starts failing, resist the temptation to simply wait longer. Longer waits often just postpone and amplify the underlying issue.
- The convenient fix is rarely the right one. Switching accounts would have been quick, but the mess would have remained. Cleaning up properly was slower to plan out, but was a far better solution in the end.
- The best tool for repetitive GUI work is the one already doing repetitive GUI work. Turning Alyvix on its own output closed the loop elegantly.
Conclusion
What started as a single test case to monitor a sales order in Dynamics AX turned into a small journey through the realities of automating a live business system: success that outpaced its own resources, a user account worn down by its own workload, and a cleanup problem with no manual shortcut. At each step, the answer wasn’t to work around the automation, but to lean further into it. At the end Alyvix wasn’t only performing the business process, but also maintaining the environment it ran in.
That, to me, is the quiet promise of visual synthetic monitoring: It doesn’t just tell you whether a process works. Used with a bit of imagination, it can carry the weight of the work that a human simply couldn’t sustain.
If you’re curious about applying Alyvix to your own GUI-driven processes whether for monitoring, testing, or large-scale repetitive operations feel free to reach out. My colleagues and I are always happy to talk it through.
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
Franco Federico
Hi, I’m Franco and I was born in Monza. For 20 years I worked for IBM in various roles. I started as a customer service representative (help desk operator), then I was promoted to Windows expert. In 2004 I changed again and was promoted to consultant, business analyst, then Java developer, and finally technical support and system integrator for Enterprise Content Management (FileNet). Several years ago I became fascinated by the Open Source world, the GNU\Linux operating system, and security in general. So for 4 years during my free time I studied security systems and computer networks in order to extend my knowledge. I came across several open source technologies including the Elastic stack (formerly ELK), and started to explore them and other similar ones like Grafana, Greylog, Snort, Grok, etc. I like to script in Python, too. Then I started to work in Würth Phoenix like consultant. Two years ago I moved with my family in Berlin to work for a startup in fintech(Nuri), but the startup went bankrupt due to insolvency. No problem, Berlin offered many other opportunities and I started working for Helios IT Service as an infrastructure monitoring expert with Icinga and Elastic, but after another year I preferred to return to Italy for various reasons that we can go into in person 🙂 In my free time I continue to dedicate myself to my family(especially my daughter) and I like walking, reading, dancing and making pizza for friends and relatives.
Author
Latest posts by Franco Federico
10. 06. 2026
Unified Monitoring
Transform Metrics into Alerts
10. 03. 2026
Unified Monitoring
Elastic AutoOps in NetEye: Simplifying Elasticsearch Operations with Real-Time Intelligence
09. 09. 2025
NetEye
Backing up a MariaDB Galera Cluster
12. 06. 2025
NetEye, Unified Monitoring
From Monitoring to SOC