Namenskonventionen

Die Entscheidung für und die konsequente Anwendung von Namenskonventionen für Ihre Automation Engine-Objekte hilft Ihnen bei der täglichen Arbeit sowie bei Wartungsaufgaben, erleichtert das Erkennen und Verstehen von Warnungen, Sicherheitsfragen, den Transport von Objekten und Prozessen von einem System zu einem anderen usw.

Dieses Thema beinhaltet Folgendes:

Einführung

Das Umbenennen von Objekten ist jederzeit möglich. Objekte von Grund auf konsistent zu benennen, hilft Ihnen in vielerlei Hinsicht:

Tipp: Verwenden Sie verschiedene Server und Datenbanken, um Produktionsumgebungen von Test- und Entwicklungsumgebungen zu trennen. Auf diese Weise wird die Produktion nicht durch Testläufe oder Aktualisierungen der Testumgebung beeinträchtigt. Bei Bedarf können jedoch alle drei Umgebungen innerhalb eines einzigen Automation Engine-Systems ausgeführt werden. Um Objekte und Prozesse reibungslos von einer Umgebung in eine andere transportieren zu können, ist es äußerst wichtig, konsistente Objektnamen zu verwenden.

Zeichenkonventionen

Objektnamen können aus bis zu 200 Zeichen bestehen. Die folgenden Zeichen sind erlaubt:

Die folgenden objektspezifischen Einschränkungen müssen berücksichtigt werden:

Namenskonventionen für Mandanten

Mandanten agieren als eigenständige Umgebungen. Sie werden durch Mandantenobjekte dargestellt.

Wenn es keine Abhängigkeiten zwischen Aufgaben in einzelnen Sachgebieten, Abteilungen oder Kunden gibt, können Sie für jeden Bereich eigene Mandanten betreiben. Dies hat den Vorteil, dass das Einrichten eines Benutzerberechtigungskonzepts einfach ist. Auf der anderen Seite kann das Zusammenführen von Mandanten zu einem sehr zeitaufwendigen Prozess werden.

Die folgende Tabelle ist ein Beispiel dafür, wie Sie die Nummernbereiche für Ihre verschiedenen Bereiche aufteilen können. Die Mandant Nummern, die für jede Abteilung oder jeden Kunden verwendet werden, unterscheiden sich einheitlich in den Tests, der Entwicklung und in den Produktionssystemen. Diese Art der numerischen Zuordnung ist nützlich, wenn es darum geht, Aufgaben zu definieren, da Aufgaben bestimmend dafür sein können, auf welchem Mandanten (d. h. auf welchem ​​System) sie ausgeführt werden. Bei einem logischen Nummerierungskonzept können Aufgaben daher die erforderlichen Parameter automatisch konfigurieren. Dies kann die manuelle Konfiguration der Aufgaben für jede einzelne Umgebung überflüssig machen.

Testsystem Entwicklungssystem

Produktionssystem
0001 Ausbildung    

0100 interne Wartung

 0200 interne Wartung 0300 interne Wartung
1000 FA Finanzen 1100 FA Finanzen 1200 FA Finanzen
2000 FA Versicherung 2100 FA Versicherung 2200 FA Versicherung
3000 FA Lagerhaltung 3100 FA Lagerhaltung 3200 FA Lagerhaltung

Namenskonventionen für Agenten

Berücksichtigen Sie beim Definieren eines Namenskonzepts für Agenten, dass es zwei Typen gibt: Agenten für Betriebssysteme und Agenten für Anwendungen.

Agenten für Betriebssysteme

Die Verwendung des Namens des Systems, auf dem der Agent installiert ist, ist hier eine gute Wahl. Alternativ können Sie den primären DNS-Namen des Systems verwenden, falls dieser nicht mit dem Systemnamen übereinstimmt

Auf diese Weise können Sie sofort erkennen, auf welchem Betriebssystem ein Mandant läuft. Das ist hilfreich bei der Zuweisung von Betriebssystemjobs.

Ein potentieller Nachteil dieses Ansatzes ist, dass sich auch der Systemname ändern kann, sollte das System in ein neues Hardwaresystem migriert werden. Wenn das Benennungskonzept beibehalten werden soll, müssen alle betroffenen Agentennamen aktualisiert werden und mit ihnen die Jobobjektnamen.

Bei dynamisch generierten Jobs, bei denen der Agent erst zur Laufzeit ermittelt und dann von einem Script festgelegt wird, kann das Umbenennen des Agentenobjekts auch zeitaufwendig sein. Um dies zu verhindern, sollten die Agentennamen zentral für jeden Mandanten oder Prozess gespeichert werden (in Automation Engine-Variablen oder Include-Objekten). Dieser Ansatz ist sinnvoll, wenn Sie später Objekte von einem Mandanten zu einem anderen transportieren möchten.

Agenten für Applikationen

Um Agenten für Applikationen besser von Agenten für Betriebssysteme unterscheiden zu können, sollte für diese ein Präfix verwendet werden, der die Anwendung eindeutig identifiziert, gefolgt vom Namen der Anwendungsinstanz. Die Struktur solcher Agentennamen wäre wie folgt:

<APP-PREFIX>_<APP_INSTANCE>

Zum Beispiel:

SAP_P01

Namenskonventionen für Agentengruppen

Agentengruppen enthalten Agenten, die dasselbe Betriebssystem oder dieselbe Anwendung verwenden. In Jobs können Agentengruppen anstelle von einzelnen Agenten zum Lastenausgleich, zur Parallelisierung von Prozessen oder zur Sicherstellung einer hohen Verfügbarkeit angegeben werden. Folglich sollte die Benennung auf den gemeinsamen Eigenschaften der in der Gruppe enthaltenen Agenten basieren. Um sie besser unterscheiden zu können und die Suche nach Agentengruppen zu erleichtern, können Sie ein Präfix wie ‚AG_‘ verwenden. Zum Beispiel:

Objektname

 Beschreibung
AG_UNX_ALL Gruppe bestehend aus allen UNIX-Agenten.

AG_UNX_ORA

Gruppe bestehend aus allen UNIX-Agenten, die auf Oracle-Datenbankservern ausgeführt werden.
AG_WIN_SQL Gruppe bestehend aus allen Windows-Agenten, die auf MS SQL-Datenbankservern laufen.

AG_SAP_BASIS

 Gruppe bestehend aus allen SAP-Agenten, die zum Ausführen von SAP-Basisjobs verwendet werden sollen

Cluster-Agenten

Wenn Agenten als Teil eines Clusters ausgeführt werden, sollten Sie ein Präfix oder Suffix verwenden, um diese von Nicht-Cluster-Agenten zu unterscheiden. Zum Beispiel:

Objektname

 Beschreibung
P01_UNX_CLUSTER_A UNIX-Agent für SAP P01-Instanz im Cluster „A“.

P02_WIN_CLUSTER_X

Windows-Agent für SAP P02-Instanz im Cluster „X“.

Namenskonventionen für Objekte - Allgemeine Überlegungen

Objekte, die zum Entwerfen von Prozessen verwendet werden, sind entweder ausführbare oder globale Objekte. Anmelde-, Einschluss-, Variablen-, Benachrichtigungs- und Kalenderobjekte sind Beispiele für globale Objekte. Diese können von allen Prozessen innerhalb eines Mandanten verwendet werden. Jobs, Dateiübertragungen und Workflows sind wiederum Beispiele für ausführbare Objekte.

Bei der Auswahl von Objektnamen ist es sehr wichtig, Ihr Zugriffsrechtskonzept zu berücksichtigen. Ein sowohl effektives als auch wartungsfreundliches Berechtigungskonzept beruht auf einem logisch strukturierten Namenskonzept. Achten Sie bei der Vergabe von Namen darauf, dass Sie die verwendeten Transportpfade berücksichtigen. Wenn beispielsweise zwei Mandanten in Zukunft zu einem einzigen Mandanten zusammengeführt werden, führen Objekte mit identischen Namen zu Problemen.

Wenn Sie Prozesse zwischen Automation Engine-Mandanten transportieren möchten, z. B. zwischen dem Test- und dem Produktionsmandanten, sollten alle mandantenabhängigen Parameter für jeden abgeschlossenen Prozess (Transporteinheit) an einem zentralen Prozessort (z. B. in einem Automation Engine-Variablenobjekt) gespeichert werden. Dies schließt Agenten und Pfade für die Prozessierung ein, die zwischen Test und Produktion variieren können.

Dieses zentrale Konfigurationsobjekt enthält entweder die Konfiguration für alle Mandanten, auf denen der Prozess ausgeführt wird, wobei es in diesem Fall immer im Transport enthalten ist, oder nur die Konfiguration des Mandanten, auf dem der Prozess gerade ausgeführt wird. In diesem Fall ist es möglicherweise nicht beim Transport enthalten. Der erste dieser beiden Ansätze ist in Bezug auf die Wartung zeitaufwendiger, jedoch auch zuverlässiger für den Betrieb.

In der Automation Engine können Berechtigungen nur über Objektnamen und Objekttypen gesteuert werden; sie können nicht über benutzerdefinierte Ordnerstrukturen gesteuert werden. Aus diesem Grund sollten globale Objekte, die nur von einer eingeschränkten Benutzergruppe bearbeitet werden können, in ihrem Namen entsprechend gekennzeichnet werden.

Objektnamen sollten daher aus Folgendem bestehen:

Beispiel

Namenskonzept für einzelne Objekte

Die folgende Konvention lässt Namen aus 6 Informationsblöcken bestehen und definiert, welche Trennzeichen konsequent verwendet werden:

Informationsbrocken im Objektnamen

 Beschreibung
SYS

Präfix, das Objekte identifiziert, die global über den Mandanten verwendet werden können. Mögliche Veränderungen sind auf eine bestimmte Benutzergruppe beschränkt
AA Ländercode bestehend aus zwei Ziffern, ISO 3166-konform.
BBBB Abteilung (vierstellig).
CCCC Standardabkürzung Objekttyp (OBP, JOBS, JSCH usw.).
DDD Plattform (dreistellig).
BESCHREIBUNG Benutzerdefinierter Text, der die Aufgabe beschreibt

. _ #

 Trennzeichen.

Nach dem Schema könnten Sie die folgenden Objektnamen haben:

Objektname

 Beschreibung
SYS.LOGIN#WINDOWS

Globales Login-Objekt für alle Windows-Agenten
SYS.CALE#PRODUCTION Globaler Kalender für die Produktion
Großbritannien.FIAC.JOBS_UNX#MONTH_END_CLOSE$SCHRITT1 Unix-Jobschritt 1 für die monatliche Abrechnung der Finanzbuchhaltung in Großbritannien
Großbritannien.FIAC.JOBP# MONTH_END_CLOSE$MEISTER Master-Workflow für die monatliche Abrechnung der Finanzbuchhaltung in Großbritannien
Großbritannien.FIAC.SCRI# MONTH_END_CLOSE$CHECK_FILES Datei-Prüfscript für die monatliche Abrechnung der Finanzbuchhaltung in Großbritannien

Namenskonventionen für globale Objekte

Um die Wartung von Prozessen zu vereinfachen, sollte die Verwendung von globalen Objekten gleich zu Beginn, d. h. bevor die Prozesse an das Produktionssystem übertragen werden, installiert werden. Beispielsweise können bereits beim Anlegen neuer Prozesse zentrale Objekte als Teil der Objektvorlagen eingeplant werden.

Beispiele hierfür sind globale Includes (Script-Komponenten) für alle verfügbaren Script-Karten der Objekte, die später die schnelle Aktualisierung mehrerer Objekte ermöglichen, oder die Definition von mindestens einem zentralen Benachrichtigungsobjekt für Abschlüsse innerhalb eines Prozesses. Für beide Beispiele müssten nicht nur die entsprechenden Objekte definiert werden, sondern auch die Objektvorlage(n) aktualisiert werden, damit die zentralen Objekte für alle neuen Prozesse verfügbar sind. Alle bestehenden Prozessaufgaben, die noch auf den alten Vorlagen basieren, müssten manuell angepasst werden. Aus diesem Grund ist es sinnvoll, die Verwendung globaler Objekte so früh wie möglich zu planen.

Diese Tabelle enthält Beispiele für das Benennen und Verwenden globaler Objekte:

Objektname

 Beschreibung
SYS.INC#JOBS_UNX.PRE

Include für die Pre-Script-Karte der UNIX-Jobvorlage
SYS.INC#JOBS_UNX.SCRI Include für die Script-Karte der UNIX-Jobvorlage
SYS.INC#JOBS_UNX.POST Include für die Post-Script-Karte der UNIX-Jobvorlage
SYS.CALL#OPERATING Include für die Attributkarte der Workflow-Vorlage (‚Ergebnisauswertung pro Einzelaufgabe‘)

Namenskonventionen für ausführbare Objekte

Ausführbare Objekte können beim Start ihren Namen ermitteln. Jede nützliche Information, die in ihren Namen enthalten ist, kann dann verwendet werden, um die Objektparameter zu konfigurieren.

Beispiel: Die folgenden Namenskonventionen ermöglichen es Benutzern, den Namen des SAP-Reports und der zugehörigen Variante in den Objektnamen aufzunehmen und SAP-Jobs von anderen Jobs zu unterscheiden.

Objektname (Syntax)

 Beschreibung
<AA>.<BBBB.CCCC_DDD>#BESCHREIBUNG

Allgemeine Jobs
<AA>.<BBBB.CCCC>_DDD>#<Report>@<Variante>#BESCHREIBUNG SAP-Jobs

Die Automation Engine-Script-Kommandos zum Zerlegen des Namens werden erneut in zentralen Include-Objekten gespeichert. Diese Includes werden zu Beginn der Erstellung des Automation Engine-Systems zu den (SAP) Job-Templates hinzugefügt. Auf diese Weise hat jeder neu erstellte Job bereits das erforderliche Include.

Nützliche Links

Dieses Thema enthält Verweise auf eine Reihe von Funktionen, über die Sie mehr erfahren möchten.