TransportManager Version 5.0

Transkript

1 TransportManager Version 5.0

2 Inhalt TransportManager...3 Systemvoraussetzungen...3 Spezielle Voraussetzungen...3 Systemlandschaft...3 Andere Transportverfahren...3 TMS-Konfiguration...3 Funktionsbeschreibung...3 Technische Grundlage...3 Definition von Transportstufen...4 Definition von Transportzielen...4 Definition von Benutzergruppen...4 Definition von Projekten...5 Definition kritischer Objekte...5 Definition kritischer Aspekte...5 Die Kollisionsprüfung...6 Definition von Abhängigkeitsvermerken...7 Der Workflow...7 Paketbildung...7 Die Transportsteuerung...8 Scheduling von Importen...9 Kommunikationsschnittstellen...9 Tracking/Reporting...10 Backup...11 Lizenzierung...11 Dienstleistungen...11 Softwarewartung und Support...11 Kontakt...12 Stand Copyright REALTECH 2006 Seite 2 von 12

3 TransportManager Systemvoraussetzungen Die Voraussetzungen für den Einsatz des TransportManagers können dem Dokument Systemvoraussetzungen entnommen werden. Spezielle Voraussetzungen Systemlandschaft Alle Systeme, die von einem TransportManager-Server verwaltet werden oder deren Tracking- Informationen an ein zentrales System gesendet werden, müssen eine eindeutige SID besitzen. Alle Systeme, die von einem TransportManager-Server verwaltet werden, müssen per Remote Function Call (RFC) vom TransportManager-Server aus über eine Standleitung erreichbar sein. Ein Connect des SAP-Transportwerkzeugs tp an die Datenbank eines SAP-Systems muss von allen seinen Applikationsservern aus möglich sein. tp muss in der Lage sein, von allen Applikationsservern eines SAP-Systems ein Ereignis an dieses zu senden Der TransportManager kann zwischen Systemen in verschiedenen SAP-Transportdomänen importieren und unterstützt Landschaften mit mehreren Transportverzeichnissen, sowie heterogene Landschaften (NT, UNIX). Andere Transportverfahren Bei Verwendung des TransportManagers ist ein selektives Importieren mit SAP-Standardmethoden (TMS, tp) weiterhin möglich. Die Verwendung von Import all oder Import all (Projekt xyz) darf allerdings nicht mehr erfolgen, da die TMS-Importqueues vom TransportManager gepflegt werden und es sonst zu Interferenzeffekten kommen kann. Mit Hilfe eines Scanners können extern durchgeführte Transporte mit erfasst werden. Eine Berücksichtigung von externen Transporten in der Workflow-Positionierung ist dagegen nicht möglich. TMS-Konfiguration Der TransportManager unterstützt sowohl Systemlandschaften ohne, als auch mit eingeschalteter erweiterter Mandantensteuerung(CTC=1). Funktionsbeschreibung Technische Grundlage Der TransportManager basiert auf der Architektur des SAP Transport Management Systems (TMS). Es können alle Objekttypen transportiert werden, die durch Änderungsaufträge aufgezeichnet und mit dem TMS verteilt werden können. Folgende Typen von Änderungsaufträgen werden unterstützt: Customizing-Aufträge Workbench-Aufträge Transport von Kopien Stand Copyright REALTECH 2006 Seite 3 von 12

4 Umzug von Objekten ohne Entwicklungsklassenwechsel Umzug von Objekten mit Entwicklungsklassenwechsel Umzug einer kompletten Entwicklungsklasse REALTECH garantiert den zukünftigen Support auf Basis der TMS-Technologie. Definition von Transportstufen Eine Transportstufe beschreibt eine Gruppe von Systemen und Mandanten, die im transporttechnischen Sinne als gleich anzusehen sind. Eine Genehmigung im Workflow wird immer für alle Systeme gleichzeitig geleistet, die im zugewiesenen Zielweg der aktuellen Transportstufe zugeordnet sind. Die Anzahl der definierbaren Transportstufen ist auf 25 beschränkt. Transportstufen können beliebig benannt werden. Die Länge der Namen ist auf 27 Zeichen beschränkt. Definition von Transportzielen Ein Transportziel beschreibt die Summe aller Systeme und Mandanten, die mit einem spezifischen Transportauftrag beliefert werden sollen. Die Anzahl der definierbaren Transportziele ist beliebig Transportziele können beliebig benannt werden. Die Länge der Namen ist auf 20 Zeichen beschränkt. Einer Transportstufe innerhalb eines Zielweges können beliebig viele Zielsysteme und -mandanten zugeordnet werden. Innerhalb des selben Zielweges kann ein System nur einer Transportstufen zugewiesen werden. Mindestens einer Transportstufe innerhalb eines Zielwegs muss mindestens ein Zielsystem zugeordnet werden. Für jede Transportstufe kann die Anzahl und der Typ der zu leistenden Genehmigungen festgelegt werden. Folgende Einstellungen sind möglich 1 : Technische Genehmigung Technische und fachliche Genehmigung Technische und 2. fachliche Genehmigung Technische, fachliche und 2. fachliche Genehmigung Pro Genehmigungsschritt können über Benutzergruppen bis zu 9 Genehmigungen erfolgen Definition von Benutzergruppen Benutzer, welche die gleiche organisatorische Rolle im Transport-Workflow besitzen, können einer gemeinsamen Benutzergruppe zugeordnet werden. 1 Die Namen der Genehmigungstypen sind historisch bedingt. Letztendlich obliegt die Bedeutung aber der kundenspezifischen Interpretation. Stand Copyright REALTECH 2006 Seite 4 von 12

5 Die Anzahl der definierbaren Benutzergruppen ist beliebig Benutzergruppen können beliebig benannt werden. Die Länge der Namen ist auf 30 Zeichen beschränkt. Ein Benutzer kann genau einer Gruppe zugeordnet werden Eine Gruppe kann beliebig viele Benutzer enthalten Definition von Projekten Projekte dienen der Gruppierung von Transportaufträgen und können im Workflow als Filter verwendet werden. Ebenso wie Transportstufe und Zielweg, ist das Projekt ein Berechtigungsfeld im Berechtigungsobjekt des TransportManagers. Damit dient es auch der flexibleren Zuweisung von berechtigten Benutzern und/oder Benutzergruppen zu einzelnen Workflow-Schritten. Die Anzahl der definierbaren Projekte ist beliebig. Projekte können beliebig benannt werden. Die Länge der Namen ist auf 20 Zeichen beschränkt. Einem Projekt muss mindestens ein erlaubter Zielweg zugeordnet sein. Innerhalb eines Projektes können den einzelnen Transportstufen der erlaubten Zielwege bis zu neun Benutzergruppen sowohl für die fachliche, als auch für die technische Genehmigung, zugewiesen werden. Des Weiteren kann unter den zugewiesenen Benutzergruppen optional eine spezifische Reihenfolge festgelegt werden. Definition kritischer Objekte Um die Aufgabe der Genehmiger zu erleichtern, kann eine beliebige Liste von kritischen Objekten angelegt werden. Bei jedem Genehmigungsschritt wird die Objektliste des betreffenden Auftrags gegen diese kritischen Objekte geprüft. Es können alle Objekttypen des SAP-Transportwesens, sowie deren Untertypen definiert werden (Beispiel: R3TR PROG und LIMU REPS ) Die Anzahl der definierbaren kritischen Objekte ist beliebig Kritische Objekte können global und/oder systemspezifisch definiert werden. Systemspezifische Einstellungen haben eine höhere Priorität als globale Einstellungen. Jedem kritischen Objekt wird eine Severity ( Warnung oder Fehler ) zugewiesen. Der weitere Ablauf des Workflows kann nach der Entdeckung eines kritischen Objektes hierdurch beeinflusst werden. Definition kritischer Aspekte Neben den kritischen Objekten, können während eines Genehmigungsschrittes auch noch spezielle kritische Aspekte geprüft werden. Diese sind: XPRAs Durch Einbindung von sog. XPRAs lässt sich eine automatische Ausführung beliebiger Reports im Zielsystem erreichen. Da dies in höchstem Maße sicherheitskritisch ist, können Aufträge dahingehend geprüft werden. SAP-Objekte Sind in einem Auftrag SAP-Objekte enthalten, so ist davon auszugehen, dass diese modifiziert wurden. Da Modifikationen immer ein erhebliches Risiko darstellen, kann hier eine Prüfung erfolgen. Stand Copyright REALTECH 2006 Seite 5 von 12

6 Objekte nicht original Werden Nicht-Originalobjekte transportiert und liegt das Original in einem anderen System des Kunden, so muss darauf geachtet werden, dass evtl. die Änderung am Original nachgezogen werden muss. Tabellen ohne Schlüssel Werden vom SAP-Standard Customizing-Änderungen aufgezeichnet, so werden immer die betroffenen Tabellensätze durch ihren Schlüssel im Auftrag spezifiziert. Wird eine gesamte Tabelle im Auftrag gefunden, ist dieser mit hoher Wahrscheinlichkeit manuell angelegt worden. Der Import einer kompletten Tabelle stellt immer ein erhöhtes Risiko dar. Anwendungsdaten Anwendungsdaten sollten aus Konsistenzgründen auf keinen Fall transportiert werden. Bei der Genehmigung kann die Objektliste darauf hin geprüft werden. Keine Dokumentation Will man zur Qualitätssicherung die Dokumentation von Transportaufträgen erzwingen, kann eine entsprechende Prüfung stattfinden. Warnungen/Fehler bei Export oder Testimporten Traten hier Fehler oder Warnungen auf, sind diese oftmals für den Erfolg oder Misserfolg eines Importes relevant Aufträge mit Mindestexportzeitstempel Hiermit kann verhindert werden, dass Aufträge genehmigt (und somit später importiert) werden, die vor einem bestimmten Datum (Exportdatum) exportiert wurden. Kritische Aspekte können global und/oder systemspezifisch definiert werden. Systemspezifische Einstellungen haben eine höhere Priorität als globale Einstellungen. Jedem kritischen Aspekt wird eine Severity ( Warnung oder Fehler ) zugewiesen. Der weitere Ablauf des Workflows kann nach der Entdeckung eines kritischen Aspektes beeinflusst werden. Die Kollisionsprüfung Zur Vermeidung von Versionsüberholungen, kann eine Kollisionsprüfung aktiviert werden, die bei jedem Genehmigungsschritt stattfindet. Hierbei kann festgelegt werden, ob die Kollisionen bei der Genehmigung immer oder nur im Fall von drohenden Überholungen eingeblendet werden sollen und ob im Fall einer Überholung nur bestimmte Benutzer genehmigen dürfen. Des weiteren kann der gewählte globale Prüfungsmodus für bestimmte Auftragsbeziehungen geändert werden. Kollisionen werden erkannt zwischen Aufträgen, die: teilweise gleiche Objekte enthalten. eine Überschneidung von Objekt und Unterobjekt aufweisen z.b. R3TR PROG ZTEST >>>> LIMU REPS ZTEST R3TR FUGR ZFUGR >>>> LIMU FUNC ZFUNC Tabelleninhalte mit sich überlappenden Schlüsselbereichen aufweisen. Für die Einstufung eines Auftrags als Überholer wird seine Position im Workflow herangezogen. Wird ein Auftrag genehmigt und dabei festgestellt, dass die enthaltenen Objekte teilweise noch in mindestens einem anderen Auftrag vorkommen, der selbst im Workflow weiter zurück liegt, so gilt dies als Überholung. Es soll also vermieden werden, dass überhaupt eine neuere Version vor einer älteren Version eines Objektes importiert wird. Stand Copyright REALTECH 2006 Seite 6 von 12

7 Definition von Abhängigkeitsvermerken Zwischen Aufträgen können Abhängigkeiten definiert werden. Folgende Arten der Abhängigkeit sind möglich: Nachfolger: Der abhängige Auftrag muss nach dem aktuellen Auftrag importiert werden. Vorgänger: Der abhängige Auftrag muss vor dem aktuellen Auftrag importiert werden. Begleiter: Aktueller und abhängiger Auftrag müssen zusammen importiert werden. Begleitender Nachfolger: Der abhängige Auftrag muss zusammen mit, jedoch nach dem aktuellen Auftrag importiert werden. Begleitender Vorgänger: Der abhängige Auftrag muss zusammen mit, jedoch vor dem aktuellen Auftrag importiert werden. Die definierte Abhängigkeit wird bei der Genehmigung geprüft und bei der Generierung der System-Queues berücksichtigt. Der Workflow Im TransportManager ist ein eigener Workflow definiert. Innerhalb dieses Workflows erfolgen alle Genehmigungsschritte, die für die Bereitstellung eines Transportauftrages zum Import notwendig sind. Die Zuweisung der Benutzer zu einer bestimmten Rolle erfolgt ausschließlich durch Pflege und Zuweisung von Berechtigungen über SAP-Standardmethoden (Profilgenerator, etc.). Der Workflow für einen bestimmten Auftrag wird entweder manuell oder mittels eingeplantem Hintergrundjob gestartet. Optional kann auch die mitgelieferte Implementierung eines SAP-Business Add-Ins verwendet werden. Sowohl die fachliche als auch die technische Freigabe kann durch geeignete Definition von Projekten und Benutzergruppen auf bis zu 9 Genehmigungsschritte mit optional festgelegter Reihenfolge erweitert werden. Bereits erteilte Genehmigungen können in umgekehrter Reihenfolge auch wieder entzogen werden. Hierzu ist die gleiche Berechtigung erforderlich, die auch zur Erteilung der Genehmigung notwendig war. Sämtliche Aktivitäten im Workflow werden auf Dateiebene mitprotokolliert. Hierzu werden SAP- Standarddateien verwendet, die auch aus den Transaktionen SE01, SE09 und SE10 einsehbar sind. Ein Genehmigungsschritt kann immer nur für alle Systeme gemeinsam erfolgen die, innerhalb des dem Auftrag zugewiesenen Zielwegs, auf einer Transportstufe liegen. Dieser Umstand schränkt auf den ersten Blick die Flexibilität des Workflows ein. Gleichzeitig garantiert er jedoch damit die Synchronität von Systemen der gleichen Transportstufe. Paketbildung Mehrere Änderungsaufträge können zu einem Paket zusammengefasst werden. Innerhalb eines Paketes kann die Reihenfolge, in der die enthaltenen Aufträge importiert werden sollen, beliebig festgelegt werden. Aufträge, die zu einem Paket gehören, können nicht separat genehmigt werden. Hierdurch wird gewährleistet, dass immer der gesamte Paketinhalt im Workflow weiterbewegt wird. Grundsätzlich verhält sich ein Paket wie ein einzelner Auftrag. Stand Copyright REALTECH 2006 Seite 7 von 12

8 Folgende Funktionen sind auf Paketen zur Zeit nicht möglich: Automatischer Status Switch Einplanung zu reservierten Zeiten, abweichend von den eingeplanten Systemqueue-Importen Aufträge können nur dann in ein bestimmtes Paket aufgenommen werden, wenn sie: dem gleichen TM-Projekt zugewiesen sind wie das Paket dem gleichen TM-Zielweg zugeordnet sind wie das Paket sich in der selben Transportstufe und im selben Status wie das Paket befinden Die Transportsteuerung Technisch basiert der TransportManager auf dem SAP Transport Management System (TMS) und dem darunter liegendenden Transportwerkzeug tp. Zum Import der genehmigten Aufträge stehen zwei unterschiedliche Verfahren zur Verfügung. Beide Verfahren rufen über RFC das Transportwerkzeug tp der SAP auf dem entsprechenden Zielsystem auf. Für beide Verfahren gilt: Die Transporte werden sequentiell als Einzelimporte (Single-Mode) oder gebündelt (Subset-Mode) durchgeführt. Für den gebündelten Import muss die erweitertemandantensteuerung für alle beteiligten Systeme im Transportsteuerungsprofil eingeschaltet sein. Ist die erweiterte Mandantensteuerung im SAP-TMS inaktiv, so wird im Falle der Belieferung mehrerer Mandanten des selben Systems in jeden Mandanten der komplette Auftrag importiert. Ist die erweiterte Mandantensteuerung im SAP-TMS aktiv, so wird bei Aufträgen, die aus einem bestimmten System exportiert wurden, bei einem möglichen Rücktransport in andere Mandanten dieses Systems nur der mandantenabhängige Anteil zurückimportiert. Alle übrigen Zielsysteme werden genauso behandelt, wie im Falle inaktiver erweiterter Mandantensteuerung. Jeder Auftrag wird vor dem Import explizit in die Transportqueue gestellt und nach dem Import auch wieder entfernt (Abhängig vom SAP-Basisrelease unterbleibt das Entfernen nach einem hohen Returncode). Zusätzliche Transportoptionen werden aus den Einstellungen der SAP-Transportsteuerungsdatei übernommen Systemqueue Die Systemqueue ist das Standardmittel zum Import von Aufträgen. Für jedes in einem Zielweg vorhandene System wird mindestens eine Queue verwaltet. Ist ein System mehreren Transportstufen zugeordnet, wird für dieses System pro Transportstufe eine Queue verwaltet. Die Systemqueue kann (z.b. periodisch) über den Scheduling-Monitor des TransportManagers eingeplant werden. Bei Start eines Importjobs werden alle Systemqueues neu generiert. Grundlage hierfür bilden alle neu genehmigten Transportaufträge. Durch eine eigene Stoppmarkenlogik wird die Synchronität von Systemen gleicher Transportstufe sichergestellt. Stehen mehrere Aufträge zum Import an, so werden diese standardmäßig sortiert nach Exportreihenfolge importiert. Diese kann durch Definition von Abhängigkeitsbeziehungen überschrieben werden. Des weiteren ist der direkte Start der Systemqueue Stand Copyright REALTECH 2006 Seite 8 von 12

9 aus dem Workflow-Monitor auch möglich. Hier erfolgt keine automatische Queue-Generierung. Diese muss vorher manuell veranlasst werden. Wird der Import einer Systemqueue aufgrund entsprechender TM-Customizing-Einstellungen nach einem Importfehler abgebrochen, so verhält sich die Queue nach einem Freischalten wie folgt: a) Single-Mode Der Auftrag, der einen Abbruch verursacht hat, ist entsprechend markiert. Aufträge mit solchen Markierungen können jederzeit wieder freigeschaltet werden. Der nächste Importlauf berücksichtigt dann neben den regulär anstehenden Aufträgen auch alle wieder freigeschalteten Aufträge. b) Subset Mode Es werden immer alle Aufträge des betroffenen Importlaufs als freizuschalten markiert. Dementsprechend können auch nur alle zusammen freigeschaltet werden. Dies ist jedoch nur solange möglich, bis ein nachfolgender Importlauf ebenfalls abbricht. Danach können nur noch die Aufträge dieses Queuelaufs zusammen freigeschaltet werden. Aufträge aus früheren abgebrochenen Importläufen können dann nur noch einzeln freigeschaltet werden. Persönliche Queue Für Not- und Sondertransporte kann die Persönliche Queue verwendet werden. In diese kann jeder berechtigte Benutzer beliebige Aufträge für beliebige Systeme einfügen und ihren Import starten. Einzige Bedingung ist die zuvor erteilte Genehmigung für die betroffenen Systeme. Der Import mit der persönlichen Queue verhindert nicht, dass die nächsten Systemqueue-Importe der betroffenen Systeme die so importierten Aufträge nochmals importiert. Hierdurch soll die Gefahr von Versionsüberholungen minimiert werden. Die persönliche Queue kann nur direkt aus dem Workflow- Monitor gestartet werden. Für die richtige Reihenfolge der in diese Queue gestellten Aufträge ist der Verfasser selbst verantwortlich. Der TransportManager unterstützt jedoch durch Feststellung von Verletzungen eventueller Abhängigkeitsvermerke. Während die persönliche Queue läuft, darf der TransportManager nicht verlassen werden. Da diese in einem eigenen Task gestartet wird, wird dieser mit Verlassen seines Vaterprozesses auch beendet. Scheduling von Importen Der Import der Systemqueues kann mit einem TransportManager eigenen Scheduler eingeplant werden. Es können einzelne oder periodische Jobs eingeplant werden. Grundsätzlich können Importjobs jedoch auch über den SAP-Standard oder externe Scheduling-Produkte eingeplant werden. Die Sicht auf Jobs, die extern eingeplant werden, ist allerdings nur eingeschränkt möglich. Kommunikationsschnittstellen CCMS Optional kann in verschiedenen Fällen eine Alarmierung an das SAP-CCMS erfolgen. Im Einzelnen geschieht dies bei o Returncode größer 8 bzw. 12 beim Import. Dies kann generell oder systembezogen definiert werden. o Importjobs, die aus bestimmten Gründen keine Transporte gestartet haben. o Überschrittenem Zeitintervall, in dem der Importscanner auf einem System nicht mehr gelaufen ist. Stand Copyright REALTECH 2006 Seite 9 von 12

10 theguard! ApplicationManager REALTECHs System Management Lösung theguard! ApplicationManager bietet für die ans CCMS gelieferten Alerts entsprechende Managed Objects. SAP Office Es werden optional, zum Teil ausführbare, Dokumente ans SAP-Office des TransportManager-Servers versendet. Die Optionen sind: o Benachrichtigung an den/die berechtigten Benutzer über eine neu vorliegende Genehmigungsanforderung (ausführbares Dokument) o Benutzerspezifische Benachrichtigung über durchgeführte Importe generell oder nur im Fehlerfall für: eigene Aufträge vom Benutzer genehmigte Aufträge alle Aufträge Externes Mailsystem Im Rahmen der von SAP unterstützten MS Outlook Versionen können Outlook Clients über die SAP- Mapi-Schnittstelle angebunden werden. Ist auf dem Arbeitsplatzrechner zusätzlich ein SAPGui installiert, ist die komplette Funktionalität, wie sie auch im SAP-Office vorliegt, gegeben. Andere externe Mailsysteme können nur mit den von SAP angebotenen Alternativmethoden angebunden werden (SAP-Connect, SAP-Exchange, etc.). Diese bieten nicht den vollen Funktionsumfang der Mapi-Schnittstelle. So kann nicht direkt von der Mail in den TransportManager gewechselt werden. Auch eine bidirektionale Synchronisation zwischen externem Mailsystem und SAP- Office ist nicht möglich. Die Realisierung der Anbindung ist nicht Bestandteil der Installationsleistung seitens REALTECH. Tracking/Reporting Folgende Daten werden aufgezeichnet: Zeitpunkt einer Genehmigung Objekt der Genehmigung Genehmigende Person Wurden bei der Genehmigung kritische Objekte/Aspekte ignoriert? Auflistung der Verletzung von Abhängigkeitsvermerken Diese Daten werden im SAP-Actionlog mitprotokolliert. Dadurch sind sie auch aus den Standardtransaktionen SE01, SE09 und SE10 einsehbar. Eine kumulative Auswertung im Sinne eines Reportings ist zur Zeit nicht möglich. Zusätzlich werden alle Importaktivitäten aufgezeichnet. Hierfür ist eine Langzeitauswertung verfügbar. Aufgezeichnet werden pro Importvorgang: Zielsystem eines Imports Zielmandant eines Imports Transportauftrag Autor des Auftrags Datum/Uhrzeit des Imports Stand Copyright REALTECH 2006 Seite 10 von 12

11 Returncode des Imports Kurztext des Auftrags Auftragsart (Customizing, Workbench, etc.) TM-Projekt und aktuelle Stufe/Status im TM-Workflow Das Tracking umfasst auch Aufträge, die ohne TransportManager importiert wurden. Voraussetzung hierfür ist jedoch die Einplanung des Importscanners. Des Weiteren steht ein Delta-Tracking zum Systemvergleich zur Verfügung. Dieses bezieht sich immer auf einen bestimmten Zeitraum und ist deshalb nur dann vollständig, wenn ein Referenzzeitpunkt mit einem Delta von null zwischen den zu vergleichenden Systemen existiert (z.b. nach einer Systemkopie). Eine nachträgliche Ermittlung von Tracking-Informationen, deren Ursprung vor Einsatz des TransportManagers liegt, ist nicht möglich. Backup Sollte der TransportManager-Server z.b. durch eine Systemkopie neu aufgesetzt werden, so müssen vorher alle Daten des TransportManagers gesichert und nach der Kopie wieder eingespielt werden. Hierzu wird der Report /RTC/TM_BACKUP ausgeliefert, mit dessen Hilfe man alle relevanten Daten als Transportauftrag sichern und exportieren kann. Attribute vom Typ File werden zur Zeit nicht mitgesichert. Lizenzierung Die Lizenzierung des TransportManagers wird in einem separaten Dokument beschrieben. Dienstleistungen Die im Rahmen des TransportManagers angebotenen Dienstleistungen werden in einem separaten Dokument beschrieben. Softwarewartung und Support Siehe Leistungsbeschreibung Support. Stand Copyright REALTECH 2006 Seite 11 von 12

12 Änderungen und Irrtümer vorbehalten. Stand 06/2006. Warenzeichen sind: Windows, Windows/NT/2000, Outlook von Microsoft, SAP R/3 von SAP, theguard! von REALTECH system consulting GmbH. Kontakt Weitere Informationen über REALTECH s Softwareprodukte unter: REALTECH AG Industriestr. 39c Walldorf Germany Tel Fax mailto:[email protected] Stand Copyright REALTECH 2006 Seite 12 von 12