#TippderWoche
Blueprism Runtime Ressource auf einem Terminal Server betreiben.
Bisher fokussiert Blueprism erfolgreich den Betrieb der Runtime Ressourcen primär auf einen Desktop, egal ob Windows Client Betriebssystem (z.B. Windows 10) oder das Server Betriebssystem (z.B. Windows Server 2019) und auch egal, ob physikalisch oder virtuell.
Es gibt aber auch die Möglichkeit die Runtime Ressourcen auf einem Terminal Server in mehreren Sessions zu betreiben.
Das klingt sehr verlockend, da man die Vorteile eines Terminal Servers (Remote Desktop Session Host) mit der RPA Technologie verbinden kann.
Um ein einfaches Beispiel zu nennen, auf dem Server wird die Software einmal installiert und dann von mehreren Benutzern in verschiedenen Sessions gleichzeitig genutzt. Gibt es Applikationsupdates, muss wieder nur einmal installiert / upgedated werden und alle Benutzer/Sessions nutzen die neuste Version. Für die gedachte Nutzung durch Benutzer bieten Terminal Dienste eine einfache Administration und einen einfachen Weg des Zugriffs. Auch Zugriff aus anderen Netzen oder Homeoffice bietet viele Vorteile für diese Technologie. Da primär nur Bildschirminhalten und keine „echten" Daten das Rechenzentrum verlassen, haben die Terminal Dienste über die letzten 20+ Jahre zu einer guten Alternative anwachsen lassen. Spätestens seit dem „Corona-Homeoffice-Zwang" in vielen Unternehmen haben diese Technologien ihre Bekanntheit erlangt.
Können wir diese Vorteile mit den aktuellen Anforderungen einer RPA Lösung kombinieren und was ist zu beachten?
Ja, man kann sie kombinieren, aber man sollte auch gewisse Schritte und Punkte beachten.
Wir haben in unserer Digital Exchange einen Asset im März diesen Jahres zu diesem Thema aktualisiert.
https://digitalexchange.blueprism.com/dx/entry/3439/solution/remote-desktop-services---blue-prism
Dort beschreiben wir die Möglichkeiten, notwendigen Parameter, aber auch die Herausforderungen und stellen ein VBO für die Nutzung mit Terminal Servern bereit.
In dem früheren Guide hatten wir diesen Einsatz aufgrund von Verfügbarkeit der Terminal Server für die zu automatisierenden Prozesse eher als kritisch gesehen. Das ist natürlich nachvollziehbar, wenn z.B. viele businesskritische Prozesse auf einem Terminal Servern laufen und dieser ausfallen sollte. Dann würden alle businesskritische Prozesse nicht laufen und die IT muss sich mit Hochdruck um Wiederherstellung kümmern.
Das hat sich entsprechend weiterentwickelt und so sind Lastenausgleich, Farmen oder auch globale Architekturen möglich, um solche Gefahren zu minimieren.
Es gibt aber weiter einige Punkte, bei denen gerade die businesskritischen Prozesse durchaus geprüft werden sollten, bevor sie auf Terminal Servern betrieben werden. Je nach Applikation und Art und Weise des Prozesses könnte hier ein Beeinflussen von einer zu anderen Session passieren. Ein einfaches Beispiel wäre die Möglichkeit eine Applikation hart zu beenden (kill). Passiert dies im reinen Benutzerkontext, dann sorgt das Betriebssystem dafür, dass nur die Applikation von diesem angemeldeten Benutzer (Digital Worker) beendet werden. Benötigen aber Applikationen Admin Rechte, dann könnte durch das Beenden (Kill) sämtliche Instanzen der Applikation beendet werden, was durchaus andere Prozesse auf anderen Benutzer (Digital Worker) Sessions stark beeinflussen könnte. Auch ein sehr präzises Definieren der Applikationen z.b. durch Process IDs muss beachtet werden.
Viel Spaß beim Betrachten und Bewerten dieser weiteren Möglichkeit, Runtime Ressourcen (Digital Worker) bereitzustellen.
------------------------------
Martin Rohde
Solution Consultant
Blue Prism
------------------------------
