Blue Prism Tags bringt die Datenbank zum Überlaufen, Wie arbeitet ihr mit Tags?

[RobertRoginer]

Hallo zusammen,

bei uns stürtzt Blue Prism bei manchen Prozessen ab, wenn wir das Session Log öffnen. Habe dann ein Ticket bei Blue Prism erzeugt und es wurde festgestellt, das wir zuviele Tags benutzten und zuviele Work Queues Items haben.

Da wollte ich mal Fragen wie ihr denn damit umgeht.

Bei uns ist ein Fall eine Work Queue.
Bezüglich Tags, wir geben in den Fehlern manchmal eindeutige Werte mit, das wird aber im Standard Template bei den Mark as Exception automatisch im Standard getagt.
Beispiel:
Unter Tags und Exception Reason wird im Control Room folgendes angezeigt:

Im Prozess selbst wird im Objekt der Fehler mitgegeben.
und im Standard Template wird es dann automatisch getagt:
Dadurch sind die Tags teilweise unique.

Wie geht ihr denn damit um?
Sichert ihr die Work Queues und löscht die dann irgendwann raus.
Benutzt ihr für die Logs Unicode, oder habt ihr das ausgeschaltet?

------------------------------
Robert Roginer
RPA Modeller
Mainova
Europe/Berlin
------------------------------

[RamónRequena_L1]

Servus Robert, 

wir versuchen höchstens 5 Tags pro Queue zu verwenden. Wieso nimmt ihr die Belegnummer dynamisch? Reicht es nicht mit dem Item Key?

------------------------------
Ramón Requena López
RPA Developer
Magenta Telekom
------------------------------

[Walter.Koller]

Hallo,

Wir haben dutzende WQ mit teilweise mehreren 1000 Items. Im Fehlerfall können die Tags bei uns auch schon den Fehlertext enthalten, ähnlich wie auf Deinem Bild zu sehen. Probleme haben wir deshalb aber keine.
Ich wüsste jetzt auch nicht wie die WQ mit den Session Logs zusammen zusammen hängen sollte?

Aber vielleicht hängt es von der Häufigkeit ab bei der lange Tags in die WQ geschrieben werden?!
Es sollte wahrscheinlich nicht die Regel sein lange Tags zu schreiben sondern eher der Ausnahmefall. 
Wenn die langen Tags zu häufig vorkommen würde ich sie nicht mehr als Ausnahmen betrachten sondern sie als eigenen Zweig im Bearbeitungsworkflow implementieren. Selbst wenn dieser Zweig nur "der Fall wurde zur manuellen Bearbeitung übergeben" und ihn in der WQ auf done setzen. 

Ich sehe aus den Fehlertexten dass es sich häufig auch um Datenqualitätsprobleme handelt. Bei einigen Prozessen haben wir ein "Pre-processing" dass ein Qualitätsminimum bei den Eingabedaten sicherstellt. 
Bei DQ Problemen ist es sehr hilfreich Statistiken mitzuschreiben, welche Dinge wie häufig auftreten und die dann regelmäßig mit den Quelldatenbeauftragten bespricht. Mittelfristig führen diese DQ Reviews normalerweise zu einer Verbesserung der DQ schon in Vorsystemen.

------------------------------
Walter Koller
Solution Manager
Erste Digital / Erste Group Bank
Europe/Vienna
------------------------------

[Ricardo.Ullbrich]

Hallo Robert,

das Thema Tag Handling führt bei vielen Kunden im Veraluf der  zunehmenden Automatisierung zu Herausforderungen, da zwischen dem Application Server und der Datenbank bei der Verarbeitung von Prozessen Abfragen gegen die Datenbank abgesetzt werden. Je größer die Anzahl der eindeutigen Tags, desto länger dauert die Rückmeldung in der Datenbak und es kommt zu einem Abbruch des Prozesses. Die Empfehlung von Blue Prism ist es, wie folgt vorzugehen: Support Center | Blue Prism Portal

Darüber hinaus habe ich in meinem Tipp der Woche Artikel das Thema der Datenbank Wartung angesprochen, welches ich jedem Kunden empfehle:
Blue Prism Datenbank Wartung | Deutschsprachige Community

Viele Grüße
Ricardo

------------------------------
Ricardo Ullbrich
Partner Solution Consultant
BluePrism
Europe/Berlin
------------------------------