Sprechen wir über den Berichts-Server. Warum brauchen wir eigentlich einen Berichts-Server? Nun, wir beobachten einen Trend, dass Ihre Umgebungen immer größer und komplexer werden und Sie deutlich mehr Ausführungsvorgänge durchführen, um all diese Anwendungsprozesse zu automatisieren. Und das Datenvolumen wächst erheblich. Gleichzeitig teilen Sie uns jedoch mit, dass Sie Compliance- und regulatorische Anforderungen erfüllen müssen, die eine längere Aufbewahrung der Daten erfordern – das haben wir gerade anhand der Umfrageergebnisse gesehen. Und das gilt nicht nur für die allgemeine Berichterstattung, sondern auch für Prüfungszwecke und zur Bereitstellung von Analysen für diagnostische und prädiktive Erkenntnisse. Wir wollen nicht alle diese Daten in der Primärdatenbank aufbewahren, und wir wollen unsere Ressourcen nicht dafür einsetzen, komplexe Berichte auf Basis dieser Daten zu erstellen. Als wir uns also näher damit befassten und die allgemeinen Berichtsanforderungen für den neuen Berichts-Server untersuchten, haben uns die Kunden mit überwältigender Mehrheit mitgeteilt, dass sie genau das wollen, was wir derzeit im UAC haben. Sie waren also tatsächlich sehr zufrieden mit den bestehenden Berichtsfunktionen. Deshalb haben wir diese Lösung entwickelt. Es handelt sich um einen Berichts-Server, der eine separate Instanz des UAC darstellt und auf den Bereich der Berichterstellung beschränkt ist. Ein Berichts-Server, der jede unterstützte Datenbank nutzen kann, die nicht mit der primären UAC-Datenbank identisch sein muss. Sie können beispielsweise Postgres sowohl für Ihren Berichts-Server als auch für Ihren Langzeitdatenspeicher verwenden, sodass Sie keine zusätzliche Lizenzdatenbank benötigen. Es ist ein Berichts-Server, der den Wartungsaufwand nicht wesentlich erhöht. Wie Sie wissen, ist unser Upgrade-Prozess einfach und gehört zu den vielen Dingen, die Kunden an UAC schätzen. Der dedizierte Anwendungsbereich des Berichts-Servers und diese einfachere Umgebung – wir haben kein OMS und keine angehängten Agenten – bedeuten, dass das Upgrade im Grunde nur einen weiteren Schritt im Prozess darstellt und Ihren Upgrade-Prozess nicht wesentlich komplexer macht. Ganz wichtig ist, dass die Anwendung die Datenreplikation auf den Berichts-Server verwaltet. Wie Sie wissen, betreiben einige Kunden bereits einen Archivserver und verwalten den Export, den Import sowie den gesamten Datenlebenszyklus manuell selbst. Es ist sehr sinnvoll, die Replikationsaktivitäten von der Anwendung selbst durchführen zu lassen. Und ganz wichtig: Es kommt zu keinem Datenverlust, da die Daten erst dann aus Ihrem primären UAC gelöscht werden, wenn sie auf den Berichtsserver repliziert wurden. Außerdem gibt es eine sehr elegante Möglichkeit, Ihre Daten von Ihrem bestehenden Archivserver auf den neuen Berichtsserver zu replizieren. Das bedeutet, dass Sie die Vorteile des neuen Berichtsservers nutzen und dennoch Zugriff auf die bereits gesammelten Langzeitdaten haben, die Sie im Laufe der letzten Zeit erfasst haben. Das ist wirklich wichtig. Alle Ihre Anforderungen an die Berichtsverteilung werden erfüllt – von einfachen Berichts-E-Mails, die direkt vom Berichtsserver versendet werden, bis hin zu komplexeren Verteilungsvorgängen wie der Freigabe von Daten in Ihren Cloud-Speicher. Diese Vorgänge können weiterhin von Ihrem primären UAC aus ausgeführt werden, während die Berichtsaufgaben an den Berichtsserver delegiert werden. Gehen wir also zur nächsten Folie über und sehen wir uns die Visualisierung dazu an. Wir haben also eine Eins-zu-Eins-Beziehung zwischen dem Berichts-Server und der UAC-Instanz, und dafür gibt es gute Gründe. Wie Sie wissen, müssen wir alle Sicherheitszugriffe und Definitionen genau wie beim Quell-UAC beibehalten. Die Agentendefinitionen selbst werden so dargestellt, als wären sie ein wichtiger Teil des ursprünglichen Durchlaufs. Sie existieren jedoch nicht tatsächlich als angehängte Agenten auf dem Berichts-Server, da wir vom Berichts-Server aus nichts ausführen. Und die Replikation der Daten aus dem Produktions-UAC erfolgt nicht über die Instanz selbst, sondern wird direkt aus der Datenbank abgerufen. Dies ist die effizienteste Art, die Replikation zu verwalten, und beansprucht keine Ressourcen des Primärservers. Bislang haben wir von allen Kunden, mit denen ich gesprochen habe, sehr positives Feedback erhalten. Wir freuen uns schon sehr darauf, auch von Ihnen zu hören, sobald Sie beginnen, diese neue Funktion des Berichts-Servers zu nutzen. Also