„Lösung, die die Vorteile des replizierten und des referenzierten Szenarios vereint.“

Siehe auch: Übersicht

Vor- und Nachteile

Vorteile: gute Performance, schlankes BPMS
Nachteile: höhere Entwicklungskosten, Fachdatenreplik kann Sicherheitsbestimmungen entgegenstehen

Beschreibung

Das vereinigte Szenario kombiniert das replizierte mit dem referenzierten Szenario. Für die Umsetzung des vereinigten Szenarios werden die Fachdaten aus dem externen Fachdaten-System nach Bedarf extrahiert und in zusätzlichen Datenbanktabellen nahe dem BPMS gespeichert. Das BPMS hält ausschließlich Referenzen auf die gespeicherte Replik, wodurch das externe System nicht mehr vom BPMS beansprucht wird. Als Seiteneffekt ist sichergestellt, dass die beiden Teilsysteme (BPMS und Fachdaten-System) ausschließlich auf ihre Hauptaufgaben ausgerichtet sind – und die Laufzeit sehr unabhängig voneinander betrachtet werden können. In die hierfür angelegten Datenbanktabellen werden lediglich die prozessrelevanten Fachdaten abgelegt. Tipp: Es bietet sich an, diese Daten stark normalisiert abzulegen, um den zusätzlichen „Insert- und Update-Overhead“ möglichst gering zu halten. Der Zugriff auf die Daten aus dem BPMS heraus erfolgt nun auf lokaler Ebene.

Die Performance bei der Ausführung und vor allem bei der Erstellung einer gemeinsamen Aufgabenliste mit Prozess- und Fachdaten ist damit gegenüber den anderen Szenarien deutlich verbessert. Die Aufgabenliste als Kombination aus Fach- und Prozessdaten kann nämlich bereits physikalisch in der zusätzlichen Datenbanktabelle aufbereitet werden, beispielsweise mithilfe von Datenbank-Triggern. Die Aufgabenliste besteht dann aus nur einer Tabelle mit vielen Spalten. Das oftmals zeitraubende „Zusammensuchen“ (SQL JOINs…) der verschiedenen Informationen für die Aufgabenliste wird dann bereits beim Füllen (und Updaten) der Tabelle gemacht  und geschieht nicht nach oder während der Abfrage bzw. Erstellung. Komplexe Such- und Filterkriterien können nun von der Datenbank mit Leichtigkeit durchgeführt werden – die Abfrage geht ja nur gegen eine Tabelle – der Datenbank ist nun die Auswahl einer “falschen” Zugriffsstrategie genommen. Zusätzliche Indizes können Suchen selbstverständlich weiter beschleunigen.

Prozess- und Fachdaten werden in <strong>einer</strong> Tabelle gespeichert.

Prozess- und Fachdaten werden in einer Tabelle gespeichert.

Gründe für diese Art der Aufteilung von Prozess- und Fachdaten können verschieden sein:

  • Architekturelle Vorgaben: das externe Fachdaten-System besteht bereits, bietet jedoch nicht die für die BPM-Suite notwendige Performance
  • Das Fachdaten-System hält viele für die Prozesse irrelevante Daten
  • Extreme Performance-Anforderungen an das System: Aufgabenlisten sollen im Millisekunden-Bereich zur Anzeige gebracht werden, auch wenn sich große Datenmengen im System befinden.

Zu beachten ist: Durch das Hinzufügen einer weiteren Datenbank besitzt dieses Szenario gegenüber den anderen vorgestellten eine gesteigerte Komplexität. Der Aufwand für die Erstellung der Fachdatenreplik hängt von der Art des Fachdatensystems ab. Die Integration externer Systeme stellt meist einen erhöhten Aufwand dar.

Dieses Szenario kommt, trotz Idealisierungen, der Realität sehr nahe. In der Regel sind Fachdaten nicht komplett integriert, aber auch nicht komplett extern referenziert gehalten. Die Vereinigung der Daten lässt sich je nach Fall individuell gestalten und ist daher für die meisten Anwendungsfälle einsetzbar. Dadurch entfällt unter Umständen auch die Verwendung eines weiteren Systems, das sich bisher um die Beschaffung und Bereitstellung der Fachdaten gekümmert hat (siehe Grafik). Die Optimierung der Aufgabenliste(n) ist eine Erweiterung, die sich je nach Datenvolumen zu entwickeln lohnt.

Die Umsetzung dieses Szenarios ist grundsätzlich mit allen BPMS möglich. Stärken können solche BPMS ausspielen, die bei der Darstellung der Aufgabenlisten nicht an eine bestimmte „interne“ Art der Darstellung der Daten gebunden sind. Im Extremfall ist es hier von Vorteil, wenn die Aufgabenliste „frei programmiert“ werden kann oder muss – und somit die eigens hierfür erstellte Tabelle optimal abgefragt werden kann. Dass dies mit zusätzlichem Entwicklungsaufwand verbunden ist, ist klar – dafür bekommt man aber auch die am besten mögliche Performance und spart beim Performance-Tuning.

Navigation

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close