Best Practices: Namenskonventionen

Wenden Sie konsistente Namenskonventionen auf Ihre Objekte an. Namenskonventionen helfen Ihnen, Warnungen zu erkennen, potenzielle Sicherheitsprobleme zu identifizieren und Objekte und Prozesse zu unterscheiden. Sie sind besonders nützlich, wenn Sie Objekte exportieren und importieren und sie transportieren.

Diese Seite beinhaltet Folgendes:

Einführung

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

Ihre Systeme zu warten
Warnungen zu erzeugen, verstehen und darauf zu reagieren
Ein Sicherheitskonzept zu definieren
Objekte und Prozesse von einem Mandanten zu einem anderen zu transportieren
Objekte und Prozesse von einem System in ein anderes zu transportieren
Neue Mitarbeiter zu schulen

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 von einer Umgebung in eine andere zu transportieren, ist es äußerst wichtig, konsistente Objektnamen zu verwenden.

Zeichenkonventionen

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

Objektspezifische Einschränkungen

Mandant: 4 nummerische Ziffern zwischen 0001 und 9999
Agent: 32 Zeichen
Agentengruppe: 32 Zeichen
Zeitzone: 8 Zeichen

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.

Beispiel: Unterschiedliche Mandantennummernbereiche in unterschiedlichen Umgebungen

In der folgenden Tabelle wird dargestellt, wie die Zahlenbereiche, die für Mandanten verwendet werden, in drei verschiedene Bereiche (Systeme) aufgeteilt werden. Die Mandantennummern, die für jede Abteilung oder jeden Kunden verwendet werden, unterscheiden sich einheitlich in den Tests, der Entwicklung und in den Produktionssystemen.

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

Diese Art der numerischen Zuordnung ist beim Definieren von Aufgaben hilfreich, da Aufgaben bestimmen können, auf welchem Mandanten (System) sie ausgeführt werden. Bei einem logischen Nummerierungskonzept können Aufgaben die erforderlichen Parameter automatisch konfigurieren. Dies macht die manuelle Konfiguration der Aufgaben für jede einzelne Umgebung überflüssig.

Namenskonventionen für Agenten

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

Agenten für Betriebssysteme
Agenten für Anwendungen

Agenten für Betriebssysteme

Die Verwendung des Namens des Systems, auf dem der Agent installiert ist, ist eine gute Wahl. Alternativ können Sie den primären DNS-Namen des Systems verwenden, falls dieser nicht mit dem Systemnamen übereinstimmt. In jedem Fall können Sie sofort erkennen, auf welchem Betriebssystem ein Mandant ausgeführt wird.

Warnungen:

Wenn das System auf ein neues Hardwaresystem migriert wird, kann sich auch der Systemname ändern. 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 zeitaufwendig sein.

Um größere Probleme zu vermeiden, speichern Sie die Agentennamen zentral für jeden Mandanten oder Prozess, z. B. in 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 Anwendungen

Um Agenten für Anwendungen von Agenten für Betriebssysteme zu unterscheiden, verwenden Sie Präfixe, die die Anwendung identifizieren, gefolgt von dem Namen der Anwendungsinstanz. Die Struktur solcher Agentennamen wäre wie folgt:

<APP-PRÄFIX>_<APP_INSTANZ>

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:

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, verwenden Sie ein Präfix oder Suffix, um diese von Nicht-Cluster-Agenten zu unterscheiden. Zum Beispiel:

Objektname: P01_UNX_CLUSTER_A

Beschreibung: UNIX-Agent für SAP P01-Instanz im Cluster A.
Objektname: P02_WIN_CLUSTER_X

Beschreibung: 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, FileTransfers 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 Verarbeitung 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:

Ein statischer Teil, der aus einem oder mehreren Teil/en bestehen kann. Diese können sein:
- Zweig
- Abteilung
- Spezielle Kennung für die globalen Objekte eines Mandanten
- Automation Engine Objekttyp
Die einzelnen Kennungen des statischen Teils des Namens sollten für jeden Objekttyp eine einheitliche Struktur und Länge aufweisen. Dies verbessert die Lesbarkeit und erleichtert das Auffinden von Objekten. Es vereinfacht auch die automatische Auswertung von Objektnamen bei dynamischen Objekten. Stellen Sie sicher, dass der statische Teil des Namens nicht zu lang ist. Dadurch wird auch die Lesbarkeit verbessert, z. B. bei Prozess-Schedules, die nur den Start der Objektnamen anzeigen.
Ein dynamischer Teil, der die Aufgabe beschreibt.
Eindeutige Trennzeichen, die konsistent verwendet werden, um die verschiedenen Teile des Objektnamens zu identifizieren.

Beispiel

Namenskonzept für einzelne Objekte

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

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:

SYS.LOGIN#WINDOWS

Globales Login-Objekt für alle Windows-Agenten
SYS.CALE#PRODUCTION

Globaler Kalender für die Produktion
UK.FIAC.JOBS_UNX#MONTH_END_CLOSE$STEP1

Unix-Jobschritt 1 für die monatliche Abrechnung der Finanzbuchhaltung in Großbritannien
UK.FIAC.JOBP#MONTH_END_CLOSE$MASTER

Master-Workflow für die monatliche Abrechnung der Finanzbuchhaltung in Großbritannien
UK.FIAC.SCRI#MONTH_END_CLOSE$CHECK_FILES

Datei-Prüf-Script 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 Liste enthält Beispiele für das Benennen und Verwenden globaler Objekte:

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.

<AA>.<BBBB.CCCC_DDD>#BESCHREIBUNG

Allgemeine Jobs
<AA>.<BBBB.CCCC>_DDD>#<Report>@<Variante>#DESCRIPTION

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.

Siehe auch: