Die Datenbank ist das Fundament jeder Automic-Automation-Umgebung. Performance, Stabilität und Betriebskosten hängen maßgeblich von ihr ab. In vielen Unternehmen kommt traditionell Oracle zum Einsatz – ein etabliertes, aber lizenz- und ressourcenintensives Produkt.

In einem aktuellen Projekt hat die setis GmbH einen Kunden dabei unterstützt, seine Automic-Datenbank von Oracle nach PostgreSQL zu migrieren – und damit gleich mehrere Ziele erreicht:

• Kosten gesenkt
• Cloud-Readiness hergestellt
• die Open-Source-Strategie des Unternehmens umgesetzt

Die bestehende Oracle-Datenbank verursachte hohe Lizenzkosten, erforderte immer leistungsstärkere Hardware und trieb auch den Speicherbedarf für Backups in die Höhe. Parallel dazu hatte sich das Unternehmen strategisch für den stärkeren Einsatz von Open Source entschieden.

Vor diesem Hintergrund beriet setis den Kunden bereits im Entscheidungsprozess: Welche Alternativen sind möglich? Welche Auswirkungen hat eine Migration auf Betrieb und Kosten? Wie lässt sich Automic zukunftssicher betreiben? Die Analyse führte zu einer klaren Entscheidung: PostgreSQL als Datenbankplattform.

Die Umsetzung folgte einem strukturierten, mehrstufigen Ansatz:

• Analyse der bestehenden Automic-Umgebung, Abhängigkeiten und Datenbestände
• Migrationskonzept mit Tools, Zeitplan und Anpassungen (z. B. Monitoring, SQL-Skripte, Berechtigungskonzept)
• Aufbau neuer Umgebungen für Test und Produktion
• Testmigration mit Validierung aller Funktionen
• Produktionsmigration in enger Abstimmung mit den Teams und Dienstleistern des Kunden
• Abschaltung der Altumgebung und Aktualisierung der Dokumentation

Die Migration verlief reibungslos und ohne Unterbrechung der Automatisierungsprozesse. Der Kunde profitierte unmittelbar von:

• Wegfall der Oracle-Lizenzen und deutlicher Reduktion der Infrastrukturkosten
• Geringeren Ressourcenanforderungen von PostgreSQL, insbesondere bei Storage und Backups
• Cloud-Readiness und besserer Integrationsfähigkeit in moderne Plattformen
• Strategischer Zukunftsfähigkeit durch die konsequente Umsetzung der Open-Source-Strategie

Besonders wichtig für den Erfolg waren:

• die frühzeitige Einbeziehung von setis bereits im Entscheidungsprozess,
• eine saubere Testmigration zur Absicherung der Produktivumstellung,
• sowie die enge Zusammenarbeit zwischen allen Beteiligten.

Dadurch konnte aus einer technisch anspruchsvollen Aufgabe ein reibungsloser Modernisierungsschritt werden.

Die Migration von Automic Automation von Oracle nach PostgreSQL zeigt, dass sich technische Modernisierung und strategische Ziele verbinden lassen: Kosten senken, Komplexität reduzieren und die Weichen für die Cloud stellen.

Mit seiner Erfahrung in Automatisierungsprojekten begleitet setis Kunden nicht nur in der Umsetzung, sondern auch bereits in der Entscheidungs- und Planungsphase – und sorgt so dafür, dass Migrationen nicht nur funktionieren, sondern echten Mehrwert liefern.

Broadcom hat das Lizenzmodell für Automic Automation grundlegend überarbeitet und vereinfacht. Die Lösung folgt nun einem modernen, ausführungsbasierten Ansatz und ersetzt das bisherige Modell. Dieser Artikel erklärt, wie das Lizenzmodell funktioniert, zeigt die Vorteile auf und gibt praktische Hinweise, wie Sie den größtmöglichen Nutzen erzielen. Außerdem erläutern wir, warum die Überwachung von Ausführungen hilfreich ist und wie Sie eine wirksame Monitoring-Strategie etablieren.

Ausführungsbasierte Lizenzierung verknüpft Kosten direkt mit dem geschäftlichen Mehrwert, da Gebühren von der erfolgreichen Ausführung automatisierter Jobs abhängen. Dieser Ansatz passt besser zu den heutigen Automationsanforderungen: Skalierung in hybriden Cloud-Umgebungen, Orchestrierung durchgängiger Geschäftsprozesse und das Hinauswachsen über traditionelle Batch-Workloads. Mit dem Fokus auf Workflows und API-getriebene Orchestrierung spiegelt er die Realität moderner Automationslandschaften wider.

Die Lizenzgröße wird durch die Anzahl erfolgreicher Jobausführungen über alle Umgebungen hinweg bestimmt, einschließlich DEV und QA. Als Berechnungsgrundlage für die Lizenzgröße dient der Kalendermonat mit der höchsten Zahl an Ausführungen.

Welche Jobs werden gezählt?

• Alle Ausführungen der Typen JOBS und JOBF, die erfolgreich mit Status 1900 oder 1904 enden.
• Ausgenommen sind Ausführungen mit den Agent-Typen AVALOAGENT oder BS2000, diese Agenten werden separat lizenziert.

Welche Umgebungen werden berücksichtigt?

• Alle Ihre Umgebungen. Es gibt keine Trennung zwischen PROD, QA oder DEV.

Berechnung der Lizenzkosten

• Die Ausführungen werden pro Monat gezählt.
• Der Monat mit der höchsten Ausführungszahl im Jahr bildet die Grundlage für die Lizenzgröße.

Wie werden die Daten erfasst?

• Über die Telemetrie-Funktion von Automic Automation. Sie sammelt die Daten und meldet diese an Broadcom.

Die Telemetrie-Funktion in Automic Automation unterstützt Anwender bei der Erfassung und Übermittlung lizenzrelevanter Statistiken.

Am besten greifen Sie über den Client 0 in der AWI auf die Telemetriedaten zu. Neben der Konfiguration sind dort auch die Telemetriedaten einsehbar. Die Daten können gefiltert und als CSV-Datei exportiert werden. Die Ausführungen werden nicht nach Client oder Applikation aufgeschlüsselt.

Die Erfassung erfolgt täglich und die Daten werden in der Datenbank gespeichert – die wichtigsten Informationen stehen in den Tabellen LAH und LAHD. Außerdem kann die aktuelle Übersicht der Ausführungen über die REST-Endpunkte abgerufen und angezeigt werden.

👉 Weitere Infos und Konfiguration: Telemetrie-Dokumentation
👉 REST-Endpunkte: API-Dokumentation

Das neue Modell erfordert eine präzisere Überwachung der Ausführungen:

• Wo fallen die meisten Ausführungen an (welche Applikation)?

• Wie viele Ausführungen entstehen insgesamt?

Es ist hilfreich, aktuelle Höchststände (High-Watermarks) zu definieren und zu überwachen. So lassen sich unerwartete Lizenzsteigerungen vermeiden, z. B. durch Entwicklungsfehler.

👉 Auf Basis dieser Daten können gezielte Optimierungen vorgenommen werden.

Die Änderungen bringen auch einige wichtige Vorteile mit sich:

• Lizenzkosten können fair auf Applikationen umgelegt werden.

• Das Lizenzmodell wurde verschlankt und transparenter gestaltet.

• Analysen decken Optimierungspotenziale in Workflows und Prozessen auf.

• Bei einem späteren Wechsel auf Broadcom Automic SaaS lassen sich die Kosten vorauskalkulieren.

Monitoring und Analyse sind der Schlüssel zur Optimierung Ihrer Umgebung. Sie erhalten einen schnellen Überblick über den aktuellen Gesamtstatus und erkennen, welche Applikationen den größten Einfluss haben.

Dies hilft, den Mehrwert pro Ausführung zu erhöhen und verhindert auch unnötige Lizenzvergrößerung z. B. durch Entwicklungsfehler. Zugleich ermöglicht es Ihnen, Kosten auf dieser Basis einfach Ihren Kunden zuzuordnen.

Wir haben eine eigene Lizenz-Reporting-Lösung entwickelt, um diese Herausforderung zu meistern. Für weitere Informationen kontaktieren Sie uns gerne.

Key-Features:

• Monatliches Reporting pro Client/Applikation ermöglichen.

• Definition von Kunden und Zuschlüsselung an die jeweiligen Applikationen, um so zusätzliche Reports an den Applikationen zu versenden.

• Validierung und Abgleich mit Telemetriedaten zur Qualitätssicherung.

• Unterstützung von Schwellwertwarnungen (High-Watermarks), um Lizenzüberschreitungen zu vermeiden.

• Individuell anpassbar (z. B. Mapping von Sub-Applikationen innerhalb eines Clients).

• Funktioniert für die Reports auch ohne Retentionpolicy.

Der Umstieg auf die ausführungsbasierte Lizenzierung ist einfach und eröffnet zusätzliche Vorteile. Nachfolgend finden Sie einige Empfehlungen, die bei diesem Prozess helfen.

• Bewerten Sie regelmäßig die Ausführungsergebnisse, um unerwartete Änderungen bei den Ausführungen zu vermeiden.
  • Etablieren Sie kontinuierliches Monitoring und Alerting für dauerhafte Transparenz.
• Sensibilisieren Sie Ihre Kunden für die Auswirkungen höherer Ausführungszahlen.
• Bei möglichen Optimierungen sollte das Kosten-Nutzen-Verhältnis stets berücksichtigt werden.
• Identifizieren und optimieren Sie die Applikationen mit dem größten Einfluss.
• Etablieren Sie interne Empfehlungen und Richtlinien und teilen Sie diese offen mit Ihren Applikationsteams. Zum Beispiel:
  • Erwägen Sie, ForEach-JOBPs bei Bedarf zu reduzieren. Asynchrone REST-Aufrufe benötigen kein ForEach-JOBP mit Polling mehr – der neue IG REST Agent verfügt über eine integrierte Polling-Funktion. In anderen Anwendungsfällen verwenden Sie einen Job, der die ForEach-Logik in eigenen Schleifen oder AE-Skript-Datensequenzen umsetzt. Die Anzahl der Jobausführungen innerhalb der Workflows wird dadurch deutlich optimiert.
  • Überprüfen Sie hochfrequente, zeitgesteuerte Workflows und deren Ausführungsintervalle, um sicherzustellen, dass sie den aktuellen Anforderungen entsprechen. Nicht selten ändern sich Anforderungen im Laufe der Zeit – hier entsteht Optimierungspotenzial.
  • Wandeln Sie dateigetriggerte Workflows nach Möglichkeit in Batch-Prozesse um und passen Sie deren Ausführungsfrequenz an die geschäftlichen Anforderungen an, um gleichzeitig die Effizienz zu steigern.

Broadcoms ausführungsbasiertes Lizenzmodell sorgt für mehr Transparenz und vereinfacht die Lizenzierung, bringt aber auch neue Anforderungen mit sich. Wirksames Monitoring und Optimierung vermeiden unnötige Lizenzerweiterung.

Wenn Sie Unterstützung benötigen, kontaktieren Sie mich oder mein Unternehmen setis GmbH. Wir unterstützen Sie bei der Implementierung des Lizenz-Monitorings sowie bei Prozessanalyse und Optimierung.

Die Migration in die Cloud stellt viele Unternehmen vor die Frage, wie bestehende Prozesse und Werkzeuge in der neuen Infrastruktur weiter genutzt werden können. Besonders relevant ist das beim Einsatz von Automatisierungslösungen wie Automic Automation im Kontext von RISE with SAP – dem Cloud-Angebot von SAP für die Transformation hin zu einem intelligenten Unternehmen.

In diesem Beitrag zeigen wir, welche Möglichkeiten und Einschränkungen es beim Einsatz von Automic Automation im Umfeld von RISE with SAP gibt – und welche Best Practices sich bereits bewährt haben.

Wenn Unternehmen ihre SAP-Systeme neu in die Cloud bringen (Greenfield) und noch keine zentrale Jobsteuerung im Einsatz ist, kann Automic Automation gezielt als Orchestrierungslösung etabliert werden.

Da RISE with SAP keine Installation von Drittsoftware – und dazu zählt auch der SAP-Agent von Automic – auf den SAP-Systemen erlaubt, erfolgt der Datenaustausch typischerweise über standardisierte Protokolle wie SFTP. Diese Architektur ermöglicht einen klar getrennten Aufbau zwischen SAP und Automatisierungssystem und bildet eine solide Grundlage für die spätere Erweiterung.

In der Praxis migrieren viele Unternehmen ihre SAP-Landschaft schrittweise in die Cloud – und verfügen bereits über etablierte Automatisierungslösungen wie Automic Automation zur Steuerung von Geschäftsprozessen, SAP-Jobs und Dateiübertragungen.

Besonders verbreitet sind hier Automic JOBF-Jobs für Filetransfers zwischen SAP-Systemen und Drittsystemen. In der neuen RISE-Umgebung sind solche direkten Transfers jedoch problematisch, da auf den Cloud-Systemen keine Agenten oder andere Komponenten von Drittanbietern installiert werden dürfen.

Eine vollständige Umstellung auf SFTP-Transfers ist zwar möglich, jedoch mit erheblichem Zusatzaufwand verbunden – insbesondere bei umfangreichen, historisch gewachsenen Automatisierungslandschaften.

Ein erprobter Weg zur Integration besteht in der Nutzung von Fileshares, die auf Cloud-Seite gemountet und vom Automic-System angesprochen werden können. Zwei Varianten haben sich dabei als praktikabel erwiesen:

1. On-Premises-Filesystem mit Mount in der Cloud
   Ein zentrales, lokales Dateisystem (z. B. NetApp) wird den SAP-Systemen in der Cloud als Fileshare zur Verfügung gestellt. So können Dateiübertragungen weiterhin zentral gesteuert werden.

2. Cloudbasiertes Filesystem mit Mount durch Automic-Agent
   Ein cloudseitig bereitgestelltes zentrales Filesystem wird auf einem On-Premises-System mit installiertem Automic-Agent eingebunden. So kann Automic die Dateioperationen wie gewohnt steuern, ohne dass Software auf den RISE-Systemen installiert werden muss.

Beide Varianten ermöglichen den Weiterbetrieb bestehender Automatisierungsprozesse mit überschaubarem Anpassungsaufwand – und im Einklang mit den Vorgaben von SAP.

Der Einsatz von Automic Automation in einer RISE with SAP-Umgebung ist möglich – aber an bestimmte technische und organisatorische Rahmenbedingungen gebunden. Insbesondere in Migrationsszenarien mit vorhandenen JOBF-Transfers empfiehlt sich frühzeitige Planung, um kostspielige und zeitintensive Umstellungen zu vermeiden.

Der Schlüssel liegt in einer Architektur, die bestehende Stärken von Automic Automation nutzt, ohne mit den Betriebsrichtlinien von RISE with SAP zu kollidieren – z. B. durch den Einsatz zentraler Fileshares oder durch die Kombination mit standardisierten Schnittstellen.

Gerne unterstützen wir Sie dabei, Ihre SAP- und Automatisierungsstrategie zukunftssicher zu gestalten – sprechen Sie uns an.

In einer modernen IT-Architektur, in der Ereignisse in Echtzeit verarbeitet und zuverlässig verteilt werden müssen, greifen Unternehmen zunehmend auf Apache Kafka zurück – oder dessen kommerzielle Variante Confluent Kafka.

Ein Beispiel: Ein global agierender Konzern möchte Statusinformationen aus einem System nahezu verzögerungsfrei an mehrere Microservices verteilen – inklusive Validierung der Datenformate via Schema Registry. Der Clou: Die Daten sollen direkt über Automic Automation verarbeitet und versendet werden.

Was in der Theorie simpel klingt, bringt in der Praxis einige Herausforderungen mit sich – insbesondere bei der Anbindung an Confluent Cloud.

Kafka wurde ursprünglich von LinkedIn entwickelt und 2012 an die Apache Software Foundation übergeben und ist eine real time messaging Plattform.

Die ursprünglichen Entwickler gründeten später Confluent, einen kommerziellen Anbieter, der auf Kafka aufbaut und es um zahlreiche Funktionen erweitert – darunter

• Einfaches Cloud-Deployment
• Intuitive Weboberfläche
• Erweiterte Authentifizierung (z. B. OAuth über Microsoft Entra ID)
• Schema Registry für AVRO-Serialisierung

Diese Features machen Confluent Kafka insbesondere für regulierte und verteilte Umgebungen attraktiv.

• Kafka Variante: Confluent Kafka
• Authentifizierung
  • Topic Inhalt: OAUTH Microsoft Entra ID (ServicePrincipal)
  • Schema Registry: BasicAuth Confluent Kafka
• Schema Registry: AVRO (Pflicht)

Der native Kafka-Agent von Automic Automation unterstützt derzeit nicht die erweiterten Features der Confluent Cloud, insbesondere Schema Registry mit AVRO.

Die Lösung: Ein individuell entwickelter Kafka Producer auf Basis von Python, der über Automic Automation gesteuert wird.

Die finale Integration wurde vollständig über den Unix-Agenten von Automic Automation realisiert.
Der Ablauf gliedert sich in folgende Schritte:

• Confluent Kafka Bibliothek inkl. Abhängigkeiten auf den Automic Automation Unix Agenten installieren
• Python Module auf den Automic Automation Unix Agenten installieren
• Python Skript – generisch erzeugt
• Automic Automation Job – Dieser erzeugt den Python Skript generisch und ruft diesen auf

Installation der Confluent Kafka-Bibliotheken und Abhängigkeiten auf dem Unix-Agenten:

yum install -y python3 python3-pip python3-devel gcc make cyrus-sasl-gssapi librdkafka-devel

Im Anschluss müssen die notwendigen Python Module ebenfalls auf den Automic Automation Agenten installiert werden.
Hier wurde in Automic Automationen einen separaten Jobplan erstellt, der diese automatisiert auf alle aktiven Agenten der entsprechenden Automic Automation Hostgruppe installiert.

Hinweis: Die Installation der Python Module kann in den Userspace des ausführenden Benutzer Accounts installiert werden – z.B. im Regelfall notwendig, wenn diese automatisiert durch Automic Automation Jobplan installiert werden.

• requirements Datei erzeugen z.B. (/tmp/kafka_python_requirements.txt).
  • cat <<< 'confluent-kafka == 2.4.0
fastavro
pydantic
pydantic_avro' >/tmp/kafka_python_requirements.txt
• Installation der Module
  • Allgemeine Installation:
    pip3 install -r /tmp/kafka_python_requirements.txt
  • Installation innerhalb des aktuellen Userspace:
    pip3 install -r /tmp/kafka_python_requirements.txt --user

Hier wird ein generischer Python Skript durch Automic Automation erzeugt – inkl. aller Parameter.
Wichtige Ausnahme: Bitte keine Passwörter in das Skript übergeben, diese werden im Aufruf als Parameter übermittelt.

Hinweis: Einen Beispiel Producer für Confluent Kafka finden Sie weiter unten.

Generierung eines individuellen Python-Producers durch einen Automic Automation Job, inklusive dynamischer Übergabe aller Parameter.
Die sensiblen Daten (z. B. Passwörter) werden in geschützten Automic Automation Objekten verwaltet und zur Laufzeit sicher übergeben.

Der Aufruf des Skripts erfolgt über den „UC4 JOBMELDER“-Mechanismus. Dieser stellt sicher, dass die sensiblen Passwörter geschützt bleiben.

Wie ein Producer Skript für Confluent Kafka aussehen kann, ist im angefügten Beispiel Skript ersichtlich.
In der beiliegenden Readme ist die Verwendung beschrieben.

Producer Details:

• Authentifizierung Kafka Topic: OAuth über Microsoft Entra ID
• Authentifizierung Schema Registry: Zugriff mit BasicAuth Confluent Cloud
• Schema Registry: Definition der Datenstruktur via AVRO-Schema

Diese Lösung zeigt, wie maßgeschneiderte Integration zwischen kommerziellen Plattformen wie Confluent Kafka und etablierten Automatisierungswerkzeugen wie Automic Automation möglich ist – auch wenn der native Agent an funktionale Grenzen stößt.

Durch den Einsatz von Python und moderner Authentifizierung wurde eine robuste und erweiterbare Schnittstelle geschaffen, die nicht nur technisch sauber, sondern auch sicher betreibbar ist.