entwicklerhandbuch_v2.01

SAP Entwicklerhandbuch Entwicklungsrichtlinien und Namenskonvention des CCSAP der ETH Zürich Verbindliche Vorschriften für interne und externe Berater und Entwickler Author: Adrian Fischer Dokumentname: C:\Documents and Settings\afr1\Desktop\Entwicklerhandbuch_v2.0.doc Version 2.01

Verteiler: CCSAP Berater Entwickler

SAP Entwicklerhandbuch Seite 2 von 36

Referenz

- SAP Standards Inhaltsverzeichnis

1.1 Verwendungszweck ...................................................................................................4 1.2 Einleitung ...................................................................................................................4 1.3 Abkürzungen und Bezeichnungen .............................................................................4 1.4 Gültigkeit ....................................................................................................................4 2.1 Projekte und Entwicklungsanforderung .....................................................................5

2.1.1 Dokumente und Vorlagen ...................................................................................5 2.2 Programmänderung und Anpassungen .....................................................................6 2.3 Modifikation................................................................................................................6 2.4 Customizing ...............................................................................................................6 2.5 Transport....................................................................................................................7 2.6 Berechtigungsantrag/änderung..................................................................................7

2.6.1 Entwickler ...........................................................................................................7 2.6.2 Systemadministratoren .......................................................................................7 2.6.3 Modulverantwortliche..........................................................................................7 2.6.4 Berater ................................................................................................................7 2.6.5 OSS Benutzer.....................................................................................................7

3.1 Zentrale Definitionen..................................................................................................8 3.1.1 Modulbereich ......................................................................................................8 3.1.2 Bereiche im Business Intelligent.........................................................................8

3.2 Koordination...............................................................................................................8 3.2.1 Entwicklungspakete ............................................................................................8 3.2.2 Transporte ........................................................................................................10

3.3 Entwichlung (Programme) .......................................................................................11 3.3.1 Programme .......................................................................................................11 3.3.2 Varianten für ABAP/4 Jobs und Reports ..........................................................11 3.3.3 Transaktionscodes............................................................................................12 3.3.4 Testprogramme ................................................................................................12

3.4 Jobs und Schnittstellen ............................................................................................13 3.4.1 Jobs ..................................................................................................................13

3.5 Funktionsgruppen/ -bausteine .................................................................................13 3.5.1 Funktionsgruppen .............................................................................................13 3.5.2 Funktionsbausteine...........................................................................................14

3.6 Spezielle Entwichlungsbereiche (Dynpro, MP) ........................................................14 3.6.1 Dynpro ..............................................................................................................14 3.6.2 Module Pool......................................................................................................14

3.7 Data Dictionary Objects ...........................................................................................16 3.7.1 Tabellen/Views/Strukturen................................................................................16 3.7.2 Domäne ............................................................................................................16 3.7.3 Daten Elemente ................................................................................................16 3.7.4 Daten Elemente in Tabellenfeld von SAP Tabellen (Erweiterungen/Modi) ......17 3.7.5 Meldungen/Nachricht........................................................................................17 3.7.6 Suchhilfen .........................................................................................................18

3.8 Objektorientierte Programmierung...........................................................................18 3.8.1 Klassen .............................................................................................................18

3.9 Filesystem, Fileablage .............................................................................................20 3.9.1 Filesystem.........................................................................................................20 3.9.2 Verzeichnisse ...................................................................................................20 3.9.3 Windows Zugriff [SAMBA] ................................................................................20 3.9.4 Datanfiles..........................................................................................................21

CCSAP@ETH Zürich verbindlich


4.1 Systemname............................................................................................................22 4.2 Hintergrundbenutzer ................................................................................................22 4.3 Quellsysteme ...........................................................................................................22

4.3.1 Quellsystem-ID .................................................................................................22 4.4 Applikations Komponenten & InfoAreas ..................................................................23 4.5 InfoObjects Catalog .................................................................................................24

4.5.1 Typtabelle .........................................................................................................24 4.6 InfoObjects...............................................................................................................24 4.7 Hierarchien...............................................................................................................25 4.8 InfoProvider..............................................................................................................26

4.8.1 InfoCube: ..........................................................................................................26 4.8.2 DatenStore-Objekte: .........................................................................................27 4.8.3 VirtualProvider. .................................................................................................27 4.8.4 MultiProvider:....................................................................................................27 4.8.5 InfoSets:............................................................................................................27

4.9 DataSource ..............................................................................................................27 4.10 InfoPackages und Datentransferprozess .............................................................28

4.10.1 InfoPackage Groups .........................................................................................29 4.11 Prozessketten.......................................................................................................29

4.11.1 Varianten Prozessketten...................................................................................30 4.12 Business Explorer – Query Designer ...................................................................30

4.12.1 Eingeschränkte Kennzahlen und berechnete Kennzahlen ...............................30 4.12.2 Variable.............................................................................................................31 4.12.3 Strukturen .........................................................................................................31 4.12.4 Workbook Template..........................................................................................32 4.12.5 Workbooks........................................................................................................32

4.13 Reporting Berechtigungs-Objekte ........................................................................32 5.1 Programmcode ........................................................................................................33

5.1.1 ETH Standardprogramm...................................................................................33 5.1.2 Kopf und Fusszeilen .........................................................................................33 5.1.3 Codedokumentation..........................................................................................33 5.1.4 Klonen von SAP Standardcode ........................................................................34 5.1.5 Datendeklaration und Parameterbehandlung ...................................................34

5.2 Daten Definition .......................................................................................................34 5.2.1 Datenelemente – Definition ..............................................................................34 5.2.2 Initialisieren von Variablen................................................................................35 5.2.3 Interne Tabellen................................................................................................35 5.2.4 Hard-Coding .....................................................................................................35 5.2.5 Message und Error Handling ............................................................................35 5.2.6 Berechtigungsprüfung.......................................................................................35

5.3 Layout ......................................................................................................................35 5.3.1 Ein Kommando pro Zeile ..................................................................................35 5.3.2 Einrücken [Pretty Printer]..................................................................................35 5.3.3 Gross/Kleinschreibung......................................................................................36

5.4 Daten Selektion........................................................................................................36 5.5 Restart und Recovery von Programmen..................................................................36 5.6 User Exits.................................................................................................................36



1 Entwicklerhandbuch 1.1 Verwendungszweck Dieses Dokument schafft verbindliche Richtlinien für interne und externe Nutzer und Entwickler/Berater die mit dem SAP der ETH arbeiten. Die Prozesse und Qualitätsstandards sind zwingend einzuhalten und gelten als Grundlage für eine erfolgreiche Einführung in den Betrieb und anschiessender Abnahme.

1.2 Einleitung Die Entwicklungsrichtlinien sind Bestandteil der allgemeinen Systemdokumentation und Anwendungsdokumentation. Sie gelten im Zweifelsfalle als übergeordnete Richtlinie und ist immer auf dem aktuell Stand.

1.3 Abkürzungen und Bezeichnungen # Beschreibung WSL Eidgenössische Forschungsanstalt für Wald, Schnee und

Landschaft EAWAG Eidgenössische Anstalt für Wasserversorgung, Abwasserreinigung

und Gewässerschutz PSI Paul Scherrer Institut SAP Standardsoftware Anwendung der der Firma SAP AG SAP Basis Technischer Teil der SAP Anwendung / technischer Support CCSAP Competence Center SAP der ETH FA Finanzabteilung, Finanzen HR Personalabteilung, Personal-Modul PRD SAP – Produktionssystem QSS SAP – Qualitätssicherungssystem BOX SAP – Testsystem ausserhalb der produktiven Transportschiene BAS SAP – Testsystem ausserhalb der produktiven Transportschiene

ausschliesslich für technische Testzwecke SP Support Packages, auch Hot Packages genannt LCP Legal Change Packages [gesetzliche und durch Behörden

verordnete Anpassungen] FI Finanzmodul SAP HHM oder auch FI-FM ist das Haushaltsmanagement von SAP CO Controlling Modul SAP MM Materialmanagement HR Personalmanagement SD Verkauf und Fakturierung [Sales und Distribution] CRM Marketing und Kundenbewirtschaftungsmodul der SAP [Customer

Relationship Management] ABAP/4 Integrierte Entwicklungs- und Programmierumgebung in SAP BI SAP Lösung für Business Intelligence und Data Warehousing

1.4 Gültigkeit Diese Richtlinien sind gültig ab 1.6.2002 bis auf Widerruf. Die aktuelle Version ist im WEB und/oder in der Groupwareumgebung für alle einsehbar abgelegt.



2 Prozesse 2.1 Projekte und Entwicklungsanforderung Dieses Vorgehen ist relevant für Aufgaben > 5 Tage oder > 7000.- CHF

Fachdienst CCSAP -Fachdienst CCSAP-Basis CCSAP

Ausschuss

Anforderung

Idee, Problem,fachliche Forderung

Antrag

FunktionaleSpezifikation

Grobplanung

Grobe Aufwand- undUmsetzplanung

Überprüfenund

priorisierenAntrag

Abgelehnt

Angenommen

Nachbessern,Ablehnungsbescheid

Umsetzungsplan

Auftrag zur Umsetzungerteilen

Realisierung

Technisch Spezifikationund Umsetzung mit

Benutzer

Freigabe

Testen, Schulung,kommunizieren und

freigeben

Nutzung

Information-

Mitarbeit

2.1.1 Dokumente und Vorlagen Antragsformular : Vorlage für funktionale Spezifikation : Funktionale Spezifikation.docVorlage für Grobplanung : Vorlage für technische Spezifikation : Technische Spezifikation.docVorlage für das Testkonzept



2.2 Programmänderung und Anpassungen Dieses Vorgehen ist relevant für Aufgaben < 5 Tage oder < 7000.- CHF

Fachdienst CCSAP -Fachdienst CCSAP-Basis CCSAP

Ausschuss

Anforderung

Idee, Problem,fachliche Forderung

Antrag

Prüfung undKoordination

Grobplanung

Grobplanung undPriorisierung

RealisierungTechnisch Spezifikation

und Umsetzung mitBenutzer

FreigabeTesten, Schulung,

kommunizieren undfreigeben

Nutzung

Information-

Mitarbeit

2.3 Modifikation Modifikationen sind immer zu vermeiden und werden nur in Ausnahmefällen und gut begründet bewilligt. Eine Bewilligung erfolgt durch den CCSAP - Koordinationsausschuss via einen Antrag aus dem CCSAP - Fachdienst oder dem CCSAP-Basis. Modifizierte Programme sind im SAP OSS festgehalten. Ein vollständige Dokumentation existiert zu Zeit nicht (Restanz aus dem Einführungsprojekt) Das Einpflegen von Modifikationen erfolgt immer im Entwicklungssystem (TST) und wird im Testsystem (QSS) einer umfassenden Kontrolle unterzogen. Die anschliessende Freigabe erfolgt über das CCSAP Basis mit dem Transportauftrag ins PRD.

2.4 Customizing Einstellungen am Customizing werden ausschliesslich durch das CCSAP (i.B. Modulverantwortlichen) gemacht. In der Regel werden die Einstellungen zusammen mit einem Berater oder der SAP Basis erarbeitet. Eingepflegt werden sie aber durch den entsprechenden Modulverantwortlichen. Die Dokumentation ist innerhalb des Transportauftrages sicherzustellen. Das Pflegen des Customizings erfolgt in der Regel im Entwicklungssystem (TST) und wird im Testsystem (QSS) einer umfassenden Kontrolle unterzogen. Die anschliessende Freigabe erfolgt über das CCSAP Basis mit dem Transportauftrag ins PRD. Gewisse Stammdatenpflege findet im SAP Customizing statt und benötigt ein änderbares System (offener Mandant). Für diese Aktivitäten ist eine enge Abstimmung mit dem CCSAP Basis erforderlich. Dokumentation Customizing : tbd



2.5 Transport Transporte sind über die normale Support Organisation der SAP-Basis zu beantragen. Bezüglich Reaktionszeit und Verfahren ist das Transportkonzept massgebend. Der Modulverantwortliche und/oder der Projektleiter ist für die korrekte Pflege des Transportauftrages verantwortlich. Sie sind berechtigt die Transporte im TST freizugeben (SE10) um sie für den automatische Import im QSS vorzubereiten. Zur Zeit sind automatische Importe (Import ALL) je halbe Stunde ins QSS eingeplant. Dadurch können Entwicklungen umgehend im Testsystem (QSS) überprüft und umfassend getestet werden. Importe ins PRD erfolgen ausschliesslich auf Antrag der Modulverantwortlichen an das CCSAP Basis.

2.6 Berechtigungsantrag/änderung Inhaltlich sind die Berechtigungen im SAP Berechtigungshandbuch festgehalten. An dieser Stelle sind die Berechtigungen für Entwickler und Systembetreuer der vollständigkeitshalber grob beschrieben. 2.6.1 Entwickler Entwickler mit Entwicklerschlüssel sind in den Gruppen CCSAP oder BASIS zuzuteilen. Für Externe Berater mit Entwicklungsfunktion kann auch die Gruppe BERATER eingetragen sein. Welche Entwicklerschlüssel für die produktive Systemlandschaft vorhanden sind, ist im OSS der SAP festgehalten. Ein Entwicklerschlüssel ist immer gültig für die ganze Systemlandschaft und nicht pro System. Z.B. R/3 ist eine Systemlandschaft, BW ist eine andere. 2.6.2 Systemadministratoren Systemadministratoren arbeiten in der Regel mit persönlichen User-Accounts. Die Benutzer SAP* und DDIC sind nur in Ausnahmefällen zu verwenden und unterstehen der Meldepflicht an den Leiter CCSAP. Systemadministratoren arbeiten mit der Berechtigung SAP_ALL. 2.6.3 Modulverantwortliche Die Gruppe der Modulverantwortlichen arbeitet im Auftrag des CCSAP. Sie haben hohe Berechtigungen im Bereich der Daten und müssen namentlich bekannt sein. Sie werden in der Regel in der Benutzergruppe CCSAP geführt, auch wenn sie in den Fachbereichen für das Tagesgeschäft relevante Aufgaben zuständig sind. 2.6.4 Berater Externe Berater erhalten einen persönlichen User-Account und sind verpflichtet diesen auch persönlich zu halten (keine Weitergabe von User und Passwort). In der Regel werden dem Berater die entsprechenden Berechtigungen zugeteilt gemäss Erfahrung der SAP Basis. Spezielle Berechtigungen müssen über den internen Projektleiter oder den Modulverantwortlichen beantragt werden. Alle Berater werden der Gruppe BERATER zugeteilt. Aktiviert (End Datum) wird der Account nur auf Antrag der Modulverantwortlichen für die geplante Zeitspanne des Einsatzes. 2.6.5 OSS Benutzer Benutzer mit der Berechtigung zum absetzen von Supportmeldungen über das OSS der SAP werden gemäss Erfahrung und SAP Kenntnissen der Anwender vergeben.



3 Namenskonventionen 3.1 Zentrale Definitionen 3.1.1 Modulbereich

ID Bezeichnung BC für Modul BC [Basis] BI für Modul BI (Business Warehouse) CO für Modul CO [Controlling] inkl. EC FI für Modul FI [Finanzen] inkl AA

FM für Modul FI-HHM [Haushaltsmanagement] HR für Modul HR [Human Ressource] LO Logistik (Webshops) MM für Modul MM [Material Management] PS für Modul PS [Projectsystem] SD für Modul SD [Sales and Distribution] XO IXOS XX Anwendungsübergreifende Funktionalität

3.1.2 Bereiche im Business Intelligent

Im Business Intelligent erfolgt die Aufteilung aufgrund der diversen Datenquellen, die im BI Verwendung finden.

Bereiche Beschreibung STU Studenten DOZ Dozenten RAM Räume/Gebäude

3.2 Koordination 3.2.1 Entwicklungspakete Entwicklungen müssen je nach Modulzugehörigkeit der dafür vorgesehenden Entwicklungspakete zugeordnet werden. Neue Entwicklungspakete werden ausschliesslich durch das CCSAP-Basis erstellt/zugeteilt. Anträge sind an das CCSAP zu richten und zu begründen.

Z MM Ccccc Vervollständigung der Bezeichnung oder

Abkürzung, alternativ eine fortlaufende Zahl Modulspezifische Abkürzung [ModulID]

Z [Benutzerdefinierte Entwicklungsklasse]

Beispiel: Es soll eine neue Entwicklungsklasse für Entwicklungen für das Modul CO-OM angelegt werden. Gemäss der obigen Namenskonvention setzt sich der Name wie folgt zusammen:



1. Stelle: „Z“ + 2. – 3. Stelle: „CO“ für Modul CO + 4. Stelle: „M“ zur Verdeutlichung, dass es sich um das Teilgebiet „OM“ handelt Möglicher Wert: „ZCOM“.

3.2.1.1 Abschliessende Menge aktiver Entwicklungspakete Paket Kurzbeschreibung ZBC1 Basis Entwicklungsklasse für Basis-Entwicklungen ZBC2 Basis Entwicklungsklasse für FI Entwicklungen ZBC3 Basis Entwicklungsklasse für HR entwicklungen ZBC4 Basis Entwicklungsklasse für SD/MM Entwicklungen ZBCA Allg. Funktionen und Development Programme ZBCV ETH-Programmvorlagen, Testentwicklungen ZBPS Batch Print Server (BPS) ZBW1 Entwicklungen Business Warehouse ZCCB Entwicklungen zu Berechtigungen, Berechtigungspflege ZCO1 Entwicklungen Controlling (CO/PS) ZFH1 Entwicklungen PSM (HHM) ZFI1 Entwicklungen FI ZFM_HIS Schnittstelle SAP - HIS ZHEO Entwicklungen HR fuer Erwerbsersatz - Ordnung (EO) ZHR1 Entwicklungen HR ZHRC Entwicklungen für HRC-Solutions (HR) ZHRD Entwicklungen HR Dokumente ZHRMDT Entwicklungen/Funktionen HR - Manager's Desktop ZHRX Entwicklungen Personalwesen IXOS (e-Dossier) ZIXOS Entw. IXOS - Archivierung ZLOWS Programmpaket ETH-Webshops ZMM1 MM: Bestellformular ZMMCATT Entwicklungen für MM Bereich CATT ZNRM Entwicklungen NRM ZPFC Entwicklungen und Einrichtung für den Profilgenerator ZSD1 Entwicklungen SD ETH Zürich ZSDB Entwicklungen SD Batchfakturierung ZSDVT Programmpaket SD Verrechnungstool (Intern/Extern) ZWWW Entwicklungen Web (BSP, Web Dynpro, etc.)



3.2.2 Transporte Transporte sollen wenn immer möglich gut dokumentiert werden. Text aus Mail/Antrag etc. soll in der Transportdoku beigelegt werden.

Besonderes: Maximale Länge: 45

MM (UUUUUUUU) DDMMYY XXXX xxxx

Prosa mit

sprechendem Text Kurzbezeichung (Programm /

Transaktion, Hinweis, SNOTE) Erstellungsdatum [Tag, Monat, Jahr] User = User-ID des Auftragsverantwortlichen NUR wenn der

Auftraggeben nicht mit dem Ersteller übereinstimmt! ansonsten kann es weggelassen werden)

MM [betroffenes Modul]

Beispiel: FI NIEDERER 060644 SKZ Überarbeitung Hinschnittstelle Rundung cc_afr_2.5.07 bereinigung transaktionen und programme



3.3 Entwichlung (Programme) 3.3.1 Programme


Z MM_ [I/O_]xxxxxxxxxxxxxx

Prosa mit sprechendem Text

Bei Schnittstellen erstes Zeichen: O_=Output I_=Input

Modulbereich [ModulID] Z [Benutzerdefiniertes Programm]

Beispiel: Neues benutzerspezifisches Programm im Finanzwesen. Möglicher Wert: «ZF_UPDATE_MARA» Outputschnittelle mit den Zahlungen via SKZ SKZ Schnittstelle: «ZF_O_SKZ_ZAHLUNGEN» 3.3.2 Varianten für ABAP/4 Jobs und Reports

Besonderes: Maximale Länge: 14 (Bezeichnung 30)

xxxxxxx Prosa [strukturierter Text 14 Stellen] + Beschreibung

In der Regel soll hier eine Wiedererkennung möglich sein schon in der Kurzbezeichnung. Daher ist ein strukturierter Text wichtig. Strukturiert kann über den persönlichen Kürzel (Kurzbezeichnung Name/Vorname), nethz, Einheit, Datum, etc. am Anfang stehen, eine Aussage zu den Filtern wie z.B. all, 2007, etc.. Beispiel: AFR_ALL_MK21 PSI_KP2007



3.3.3 Transaktionscodes Wenn immer möglich Transaktionen ähnlich/gleich wie Programm benennen – mit dem Unterschied, dass kein Unterstrich verwendet wird. Grundsatz: Transaktionsnamen sollten kurz sein!


Z MM Xxxxxxxxxxxxx

Prosa mit sprechendem Text oder

logischen Abkürzungen

Modulbereich [ModulID Z [Benutzerdefinierte Transaktionscode]

Beispiel: Neue benutzerspezifische Transaktion im Finanzwesen. Möglicher Wert: „ZSDUPADR“ 3.3.4 Testprogramme Testprogramme sollen ins Entwicklerpaket $TMP (lokal) gespeichert werden.

Besonderes: Testprogramme sind nicht vorgesehen für eine Produktivsetzung. Sie sind daher speziell zu behandeln.

Maximale Länge: 15

ZZ MM_ xxxxxxxxxxxxxx Prosa mit sprechendem Text Modulbereich [ModulID] ZZ [Benutzerdefiniertes Testprogramm]

Beispiel: Programm zum Testen von Funktionen Möglicher Wert: «ZZCO_HELLO_WORLD»



3.4 Jobs und Schnittstellen 3.4.1 Jobs

Besonderes: SAP R/3 lässt bei der Vergabe von Namen für Batch-Jobs nur Grossbuchstaben zu

Maximale Länge: 36 Regelmässige Batch-Jobs werden im System gemäss Betriebsplan und Systemauslastung durch das CCSAP-Basis eingeplant. Der produktive Job muss mit dem Benutzer ZZBATCH angelegt werden.

BBB_ MM_ XXXXXX Eindeutige Bezeichnung

Modulbereich [ModulID] BBB ETH Bereich – ETH ETH Zürich – PSI Paul Scherrer Institut – EAW für EAWAG – WSL

Beispiel: ETH_FM_FONDSAZ_JUN00

3.5 Funktionsgruppen/ -bausteine 3.5.1 Funktionsgruppen

Besonderes: Achtung es gibt eine Limite von Anzahl Funktionsbausteinen pro Gunktionsgruppe

Maximale Länge: 8

Z MM xxxxxxxxxxxxxx Prosa mit sprechendem Text Modulbereich [ModulID] Z [Benutzerdefinierter Funktionsbaustein]

Beispiel: ZHRMDT



3.5.2 Funktionsbausteine


Z_ MM_ xxxxxxxxxxxxxx

Prosa mit sprechendem Text Modulbereich [ModulID] Z [Benutzerdefinierter Funktionsbaustein]

Beispiel: Z_HR_PDB_AUTH

3.6 Spezielle Entwichlungsbereiche (Dynpro, MP) 3.6.1 Dynpro

Besonderes: Der Wert der Dynpronummer muss zwischen 9000 und 9990 liegen. Hauptsynpros sind in 10er Schritten und die Pop-Ups in 1er Schritten zu inkrementieren

Maximale Länge: 4

nnnn 8888 [vierstelliger numerischer Wert]

Beispiel: Dynpro #: 9110 Pop-Up des Dynpro 9110: 9111 3.6.2 Module Pool

Besonderes: exklusive Infotypen Maximale Länge: 40

SAP I Z MM_ xxxx

Prosa mit sprechendem Text Modulbereich [ModulID] .. Z [Benutzerdefiniertes Objekt] Modulpool ID

M= Dialogbaustein, Screen



D= Dynpro, Dialog F= Subroutine, Unterroutine U= Update, Verbucher

SAP [SAP]

Beispiel: SAPMZHR_Publica_Selectionmask

3.6.2.1 Includes zum Modulpoolprogramm Besonderes: Die Datendeklaration erfolgt immer in einem TOP Include

Wenn immer möglich mit wenigen Standardincludes arbeiten für Projekte und geschlossene Programmeinheiten

Maximale Länge: 20

I[d] YA_ xnxnxnx P Position T Top O Before Output I After Output F Form

[FORM..ENDFORM] Prosa mit sprechendem

Text oder Nummerierung

Y[Benutzer definierter Include] Aufgabengebiet [ID] Modulpool ID

M= Dialogbaustein, Screen D= Dynpro, Dialog F= Subroutine, Unterroutine U= Update, Verbucher

Beispiel: DYP_HSS_GlobalT, FYP_0990T



3.7 Data Dictionary Objects 3.7.1 Tabellen/Views/Strukturen

Besonderes: Gilt für alle Arten [Pool, Cluster, Transparente] Datenfelder innerhalb einer Kundentabelle müssen keine Kundenspezifische Kennzeichnung [Z] haben.

Maximale Länge: 16

Z MM T Xxxxxxxxxxxxx Typ (T=Tabelle, S=Struktur, V=View) Modulbereich [ModulID Z [Benutzerdefinierte Variante]

Beispiel: ZHRTPUBPro ZMMVMARAMIRO (View über Tabelle MARA etc.) 3.7.2 Domäne


Z MM T Xxxxxxxxxxxxx

Typ D = Domäne Modulbereich [ModulID Z [Benutzerdefinierte Variante]

Beispiel: ZHRDCHAR12 3.7.3 Daten Elemente

Besonderes: Müssen immer zu einer Domäne gehören Modulzugehörigkeit ist über das Entwicklungspaket definiert – richtige Wahl bei der Definition beachten!

Maximale Länge: 30



Z MM T Xxxxxxxxxxxxx

Typ E = Datenelement Modulbereich [ModulID Z [Benutzerdefinierte Variante]

Hinweis Bei abgeleiteten Datenelementen kann auch nur ein Z vorangestellt werden, um einen möglichst nahen Bezug zum Original zu haben. Beispiel: ZSDEANSVH 3.7.4 Daten Elemente in Tabellenfeld von SAP Tabellen (Erweiterungen/Modi) Ist ein Spezialfall der nur für Erweiterungen und Modifikationen an SAP Standardobjekten zum Zuge kommt – zur besseren Identifikation.

Besonderes: Gilt für alle Arten [Pool, Cluster, Transparente] Datenfelder innerhalb einer SAP-Tabelle müssen Kundenspezifische Kennzeichnung [Z] haben.

Maximale Länge: 30

ZZ_ xxxxxxx Prosa [sprechender Text] Z [Benutzerdefinierte Variante]

Beispiel: ZZ_Namensindex 3.7.5 Meldungen/Nachricht


Z MM T NNN

Nachrichtennummer [000 – 999]

- 000 wird nicht verwendet - 999 ist reserviert

Nachrichtentyp



A Abort [Abbruch] E Error [Fehler] W Warning [Warnung] S Success [erfolgreicher Abschluss] I Information X Exit [Aussteigen, Abschliessen] Modulbereich [ModulID] Z [Benutzerdefiniert]

Beispiel: Möglicher Wert: „ZPE321“ = Meldung ID ZP Typ E Nummer 321 3.7.6 Suchhilfen


Z MM_ T_ Xxxxx

Prosa Nachrichtentyp SH Suchhilfe Modulbereich [ModulID] Z [Benutzerdefiniert]

Beispiel: Möglicher Wert: ZMM_SH_DEBPER

3.8 Objektorientierte Programmierung Im Zweifelsfalle Paket ZLOWS anschauen 3.8.1 Klassen


Z MM T_ Xxxxxxxxxxxxx

Typ CL = Klasse Modulbereich [ModulID Z [Benutzerdefinierte Variante]



ZHRCL_Tools_und_Upload

3.8.1.1 Methoden/Interfaces Keine bindende Definitionen



3.9 Filesystem, Fileablage Bei der Verwendung Datenfiles [Schnittstellen] sind die angegebenen Vorgaben im Konzept zu berücksichtigen. Grundsätzlich gilt, dass Schnittstellen unter der Benützung des UNIX Filessystems und den Netzwerkkomponenten der ETH immer mit der SAP Basis Administration abgesprochen und eingerichtet werden müssen. 3.9.1 Filesystem Name SAP Name Physischer Name System NFS-mounted on

Systeme TST QSS DBS AS1 AS2 AS3 Datafiles /datafiles sap-dbs X X X X Testfiles /testfiles sap-dbs X X

3.9.2 Verzeichnisse Alle Schnittstellen Files werden in die jeweiligen Unterverzeichnisse des Filesystemenverzeichnisses «datafiles» oder «testfiles» abgelegt. Hinweis! Das Verzeichnis /testfiles ist nur auf dem DB Server so bezeichnet. In den Testsystemen wird das Filesystem über NFS an ein Mountpunkt /datafiles gemounted. Dadurch laufen alle Programm mit default Pfaden auch in den Testsystem – legen aber die Files physisch in das Verzeichnis /testfiles.

XXXX Sub Unterverzeichnis [Standardmässig alle vier anlegen, vor allem bei

Einsatz SSH relevant] in Ablage für Files die von extern geliefert werden

[In-Schnittstelle. out Ablage für Files die die nach extern geliefert

werden [In-Schnittstelle. in/test Ablage für Test- und Temporärfiles out/test Ablage für Test- und Temporärfiles ID [Verzeichnissname max. 5 Stellen, sprechender Name, Grossbuchstaben]

Beispiel: Bundesverwaltung SKZ Files SKZ SKZ/in SKZ/out SKZ/in/test SKZ/out/test 3.9.3 Windows Zugriff [SAMBA] Die Schnittstellenfiles können auch für berechtigte Benutzer über den Windows-Explorer [freigegeben via SAMBA] betrachtet und bearbeitet werden. Die Verzeichnisse sind speziell freigeben für bestimmte Personen und auf dem Schnittstellen Server smb1 freigeben. Mögliche Verzeichnisse:



\\sapsmb1\ethz-fa (zugelassen für gewisse IP Ranges) \\sapsmb1\ethz-fc (zugelassen für gewisse IP Ranges) \\sapsmb1\ethz-pa (zugelassen für gewisse IP Ranges) 3.9.4 Datanfiles

3.9.4.1 Ohne SSH Keine wirklichen Auflagen. Das UNIX Filesystem ist «Case Senistive» und verlangt daher die genaue Bezeichnung [Gross/Kleinschreibung]. Der Name muss sinnvoll und sprechend sein. Testfiles sind im Verzeichnis testin oder testout abzulegen oder falls nicht anders möglich eindeutig zu kennzeichnen.

3.9.4.2 Mit SSH Der genaue Syntax der Filebezeichnung muss eingehalten werden, damit die SSH Automatisierungssoftware die Aufgaben korrekt durchführen kann.

NNN_ YY nnn .xxx [Zeit] Zeitstempel [für fehlerfrei

übertragene Files – Quittung] Format yyyymmddhhmm

Bezeichnung für die

Übermittlungskontrolle .asc Produktivfiles .tst Testfiles Zähler [Fortlaufende Nummer] Jahr [Jahreszahl] DS- Nummer [Dienstellennummer, 3 Stellen, 330 für ETH, 335 für EMPA]

Beispiel: 330_02001.asc [nicht bearbeitet/übertragen] 330_02001-asc_200206121413 [ bearbeitet oder übertragen am 12. Juni 2002 um 14:13]



4 Namenskonvention im Business Warehouse

4.1 Systemname Für die Verbindung von Business Intelligent System zu den SAP Quellsystemen, muss ein logischer Systemname in beiden Systemen eingerichtet werden. Dieser wird auch für die Benennung der RFC-Destination verwendet. Nicht- SAP Systeme sind sinngemäss zu definieren.

Besonderes: Quell-/Zielsystem Maximale Länge: 9 (SAP SID = 3 und Mandant = 3) 3 Reserve Beschreibung 50

SID XXX

Mandant XXX [SID = System Name]

Beispiel: BID330 Business Intelligent BOX330 Quellsystem

4.2 Hintergrundbenutzer Der Datentransfer und die Aktivierung des Business Content erfolgt über einen technischen Benutzer, der sowohl im Quellsystem als auch im BI-System vorhanden sein muss. Diesbezüglich gibt es folgende Benutzer. Quellsystemen ALEREMOTE PW: Typ: System BI-System BWREMOTE PW: Typ: Kommunikation

4.3 Quellsysteme Ein Quellsystem stellt dem BI-System Daten zur Verfügung. BI unterscheidet zwischen folgenden Quellsystemen

• MySAP Business Suite • Dateien als Flatfile im ASCII- oder CSV-Format • Fremdsysteme • Daten-Provider • Datenbanken

4.3.1 Quellsystem-ID Die Quellsystem ID ist ein 2-stelliges Kürzel für einzelnes Quellsystem oder ein Gruppe von Quellsystemen im BI. Die Quellsystem ID wird mit der ID der Quellsystemen fortgeschrieben, welche die Daten liefert.



Präfix Bezeichnung P Produktion Q Quality Assurance / User Acceptence Test

Development/Entwicklung D IT Teststage / Projektsystem I

Für die angebundenen Systeme ergibt sich folgende Zuteilung.

ID Bezeichnung Text Quellsystem ID P1 PRD SAP Produktion P2 Org DB Organisation DB Produktion P3 Pers. DB Personen DB Produktion P4 LISETH PRO LISETH Produktion P5 SEMPRO+ SEMPRO+ Produktion Q1 QSS SAP QSS Q2 Org DB Organisation DB Q3 Pers. DB Personen DB Q4 LISETH PRO LISETH Q5 SEMPRO+ SEMPRO+ D1 TST SAP TST D2 Org DB Organisation DB D3 Pers. DB Personen DB D4 LISETH PRO LISETH D5 SEMPRO+ SEMPRO+

BOX SAP BOX I1

4.4 Applikations Komponenten & InfoAreas InfoAreas sind die obersten Organisationskriterien in den Bäumen. In diesen Mappen werden die InfoProvider und InfoObjectCatalogs organisiert und damit einfacher administrierbar. Da mehrere Standard Applikations Komponenten von SAP verwendet werden und um die zukünftig Organisation von anderen Quellen besser organisiert zu können, wird eine eigene InfoAreas-Hierarchie angelegt:

Besonderes: Die InfoAereas werden unter der InfoArea ZETHZ_01 angehängt

Maximale Länge: 30 Beschreibung 60

Z MMm_ XXXX

InfoArea gemäss SAP Modul-Bereich [ID] Z [Kundennamensraum]



Beispiel: (Baum) ZETHZ_01 Eidgenössisch technische Hochschule Zürich ZBI_0BW Techn. BI Content ZFI_0FI SAP Finanzbuchhaltung ZFI_0FIGL Hauptbuch ZHR_0HCM SAP Human Resources ZHR_PAPA Personaladministration ZHR_0PY Personalabrechnung ZFM_0PSM Public Sector Management ZFM_0PSM_FM Haushaltsmanagement Etc.

4.5 InfoObjects Catalog InfoObjects Cataloge werden für die Gruppierung von Merkmalen oder Kennzahlen verwendet. Damit können Merkmale, Kennzahlen, Einheiten/Zeitmerkmale gruppiert werden. Da die InfoObjects Cataloge nur einer InfoArea zugeweisen werden kann, werden eigene InfoObjects Cataloge für die Bereiche eingerichtet.

Besonderes: Die infoObject Cataloge werden den entsprechenden InfoAreas zugeordnet


4.5.1 Typtabelle

Typ (ID) Bezeichnung der Typen Merkmale CHA01 Kennzahlen KYF01 Zeitmerkmale 0TIM

0UNI Einheiten

Z MMm_ XXXX_ ID Typ gem. Typ-Tabelle InfoCatalog gemäss SAP Modul-Bereiche [ID] Z [Kundennamensraum]

Beispiel: ZHR_PAPA_KYF01 Personaladministration: Kennzahlen

4.6 InfoObjects InfoObjects sind die kleinsten verfügbaren Informationsbausteine oder Felder in BI. InfoObjects werden klassifiziert in

• K = Kennzahlen • M = Merkmale



• Z = Zeitmerkmale • T = Technische Merkmale • E = Einheiten

Die InfoObjects werden in InfoCubes, Strukturen, Transformationen verwendet. InfoObjects können an mehrere InfoAreas oder InfoCatalog zugewiesen werden. Grundsätzlich werden die Original-InfoObjects von SAP verwendet. Wenn Anpassungen der Standard-InfoObjects notwendig sind, wird vom InfoObject eine Kopie erstellt. Dabei wird die führende null „0“ durch „Z“ ersetzt.

Besonderes: Ein infoObject kann mehreren InfoAreas bzw. InfoCatalogs zugewiesen werden.


Z MMm T Xxxxxxxx

Bezeichnung Typ K=Kennzahl, M=Merkmal, E = Einheit, etc. Modulbereich [ModulID Z [Benutzerdefinierte Variante]

Beispiel: Erweiterung des InfoObjects Person: 0PERSON wird zu ZPERSON Neuanlage eines InfoObjects: ZHRMPERKAT Personalkategorie ZHRMOENR OE-Nr. (Leitzahl)

4.7 Hierarchien Mit Hierarchien werden Merkmalswerte baumartig strukturiert. Sie bestehen aus mehreren Knoten und Blättern, die einander über- bzw. untergeordnet sind. Die Knoten stellen die gewünschte Gruppierung dar, z.Bsp. Altersgruppen. Die Blätter werden von den Merkmalswerten dargestellt. Eine Hierarchiestruktur kann zeitabhängig und/oder versionsabhängig sein.

Im Reporting können Sie Merkmalshierarchien auf folgende Weisen einsetzen:

• als Präsentationshierarchie für ein Merkmal, wenn dieses hierarisch dargestellt werden soll

• als Auswahl für bestimmte Merkmalswerte, wenn ein Merkmal auf eine Hierarchie bzw. auf Hierarchieknoten eingeschränkt werden soll

Hierarchien können in das BI-System geladen oder im BI-System zu Hierarchiebasismerkmalen manuell angelegt werden. Sie können InfoProvider-übergreifend verwendet werden.



Besonderes: Eine Hierarchie kann max. 98 Ebenen besitzen.

Das Anzeigeverhalten in einer Query kann für jeden Knoten beeinflusst werden (zBsp. Vorzeichenumkehr)


Im BI direkt angelegten Hierarchien werden wie folgt aufgebaut:

Z MMm HIR Xxxxxxxx Bezeichnung HIR fixer Wert für Hierarchie Modulbereich [ModulID¨] Z [Benutzerdefinierte Variante]

HIRXX

• HIR Kennzeichen Hierarchie • XX Bezeichnung

4.8 InfoProvider (InfoCubes, Virtualprovider, MultiProvider & DSO Objects) Als InfoProvider werden BI-Objekte genannt, wenn auf ihrer Basis Queries im Enterprise Reporting definiert/ausgeführt werden können. Es werden folgende InfoProvider unterschieden:

Typ Bezeichnung InfoProvider InfoCube IC VirtualProvider VP MultiProficer (alt MC MultiCubes) MP DataStore Objekte DS InfoSet IS

4.8.1 InfoCube: Der InfoCube vom Typ InfoCube ist der zentrale Datenkontainer im BI, da nur in diesem InfoCube die Daten physisch in der Datenbank gehalten werden. Berichte und –Analysen beruhen darauf. Aus Reporting-Sicht beschreibt ein InfoCube einen in sich abgeschlossenen Datenbestand eines beriebswirtschaftlichen Bereichs, zu dem Queries definiert werden können. Der InfoCube beinhaltet zwei Typen von Daten. Die Kennzahlen und Merkmale. Er besteht aus einer Anzahl relationaler, multidimensional angeordneter Tabellen, d.h. er



besteht aus einer zentralen Faktentabelle (Bewegungsdaten, Kennzahlen), die von mehreren Dimensionstabellen umgeben ist. SID-Tabellen verknüpfen diese Dimensionstabellen mit ihren jeweiligen Stammdatentabellen (Merkmale). Es können bis zu max. 13 Dimensionstabellen zu einer InfoCube definiert werden. Es werden die Typen VirtualProvider und InfoCube vom Type InfoCubes unterschieden. 4.8.2 DatenStore-Objekte: In einem DatenStore-Objekt warden konsolidierte und bereinigte Daten (Bewegungsdaten oder Stammdaten) auf Dokumentenebene (atomarer Ebene) gespeichert. 4.8.3 VirtualProvider. Ein VirtualProvider stellt eine logische Sicht dar. Anders als bei InfoCubes werden keine Daten physisch in BI abgelegt. Die Daten werden erst bei Ausführung einer Query aus dem Quellsystem beschafft. 4.8.4 MultiProvider: Über MultiProvider können mehrere InfoProvider zusammengeführt und gemeinsam für das Reporting zur Verfügung gestellt werden. Der MultiProvider enthält selber keine Daten. Seine Daten ergeben sich ausschliesslich aus den zugrunde liegenden InfoProvidern. 4.8.5 InfoSets: Mit InfoSets können im BI verschiedene Datenziele in einer logischen Sicht gesammelt und verknüpft werden. Diese können gesammelt und als Provider für Queries verwendet werden. Sie verhalten sich in vielen Aspekten analog zu Datenbank-Views, die verschiedene Tabellen sammeln.

Besonderes: Maximale Länge: 9 Beschreibung 60

Z MMm_ Typ

Typ InfoProvider[Typ] Modulbereich [ModulID] Z [Kundennamensraum]

Beispiel: ZHR_IC Beschreibung: Personalbestand

4.9 DataSource DatenSources sind BI-Objekte, die für die Extraktion und Aufbereitung von Daten aus den Quellsystemen verwendet werden. DataSources untergliedern die von einem Quellsystem bereitgestellten Daten in sich geschlossene betriebswirtschaftliche Bereiche. Eine DataSource enthält eine Menge von logisch zusammengehörigen Feldern, die in einer flachen Struktur angeordnet sind und an das BI zu übertragende Daten enthalten.



Die Anlage einer DateSource erfolgt im Quellsystem, d.h. im R/3 System, der technische Namen und Beschreibung wird aus dem technischen Namen und Beschreibung des zugrunde liegenden InfoObject übernommen.

Besonderes: Stammdaten-DataSources werden unterteilt in _ATTR = Stammdaten Attribute _TEXT = Stammdaten Texte _HIER = Stammdaten Hierarchien

Maximale Länge: 30 Kurz Text 20 Mittel Text 40 Langer Text 60

Z MMm XXXX_ Typ

Typ ATTR, TEXT, HIER Techn. Name IO] Modulbereich [ModulID] Z [Kundennamensraum]

Beispiel. ZHRMPERKAT_ATTR

4.10 InfoPackages und Datentransferprozess Das InfoPackages beschreibt welche Daten einer DataSource aus einem Quellsystem angefordert werden sollen. Dabei können die Daten anhand von Selektionsparametern gezielt ausgewählt werden. Ein InfoPackage kann folgende Datenarten anfordern:

• Bewegungsdaten • Attribute Stammdaten • Stammdatentexte • Hierarchien zu Stammdaten

Der Datentransferprozess wird aus Metadatenobjekten, wie z.B. DataSources, Transformationen, InfoSources und InfoProvidern, aufgebaut. Sobald der Datenfluss aufgebaut ist, übernehmen die InfoPackages und die Datentransferprozesse die Verwaltung von Ausführung und Einplanung des eigentlichen Datentransfers. Die technischen Name für den Datentransferprozess sowie die InfoPackages werden im BI automatisch vergeben. Es können nur die Bezeichnungen vergeben werden. Neben der Bezeichnung, dass es sich um ein manuell angelegtes InfoPackage handelt, wird die technische Bezeichnung der DataSource sowie die Quelle eingefügt. Damit jederzeit ersichtlich, welches Objekt verwendet wird.



Besonderes: Maximale Länge: Beschreibung 60

Zxxx Aaaaaa Cccccc

Quellsystem Techn. Namen DataSource] ZPAK [InfoPackage]

[Datentransferprozess] ZDTP Beispiel: ZPAK_0Employee_ATTR_BOX ZDTP_0PERSON_TEXT / BOX330 -> 0PERSON 4.10.1 InfoPackage Groups Gruppierung der InfoPackage. Damit können mehrere InfoPackage gleichzeitig geladen werden. Der technische Namen wird intern vom BI vergeben. Es kann nur die InfoPackage-Bezeichnung vergeben werden. Neben der Bezeichnung, dass es sich um eine manuell angelegte Gruppe von Infopackage handelt wird eine freie Bezeichnung verwendet.

Besonderes: ZPAK_techn. Namen DataSource Maximale Länge: Beschreibung 60

ZGxx A CCC

Quellsystem Freie Bezeichnung] ZGPAK [InfoPackage]

Beispiel: ZGPAK_HR_Stammdaten_BOX

4.11 Prozessketten Wird noch definiert.



4.11.1 Varianten Prozessketten Wird noch definiert.

4.12 Business Explorer – Query Designer Mit dem Business Explorer werden Query-Definitionen angelegt. Diese Query-Definitionen bestimmen, wie die Daten aus den verschiedenen Quellen (BI-Daten-Provider) für die Darstellung aufbereitet werden. Es sind folgende Anspruchsgruppen vorgesehen:

KZ Bezeichnung Professur P Departement/Studiengangleitung D Schulleitung S Controller C

Besonderes: Die Namenskonvention der Querys muss mit dem Berechtigungskonzept überein stimmen.


Z A _X _XXXX _ABC

Beschreibung Nummer Anspruchsgruppe Kennzeichen Standard/Individuell] Z [Kundennamensraum]

Beispiel. ZS_P_0001_MittelguthabenproOE (Standard-Query) ZI_P_0001_SpesenproMKbezahlt (individuelle Query) 4.12.1 Eingeschränkte Kennzahlen und berechnete Kennzahlen Eingeschränkte Kennzahlen sind Basis-Kennzahlen des InfoProviders, die durch eine oder mehrere Merkmalsselektionen eingeschränkt oder gefiltert sind. Im Gegensatz zur Filterung einer ganzen Query, beschränkt sich die Filterung bei einer eingeschränkten Kennzahl auf das zugeordnete Merkmal. Werden neue Kennzahlen definiert, für die eine Berechnung notwendig war, wird diese Kennzahl als berechnete Kennzahlen definiert.

Besonderes: Die Definition der Namenskonvention beschränkt sich auf dieses Kennzahlen, die auf Ebene InfoProvider eingerichtet werden.


Z MMm _CCC



Kurzbeschreibung Modulbereich [ModulID]] Z [Kundennamensraum]

Beispiel: ZP_AlterJahre 4.12.2 Variable Variable sind Parameter eine Qurey, die im Query Designer definiert und erst beim Ausführen der Query oder der Web Application mit Werten gefüllt werden. Die definierten Variablen stehen in allen InfoProvidern für die Query-Defintion zur Verfügung. Variablen sind nicht vom InfoProvider abhängig, sondern von dem InfoObject, zu dem sie angelegt werden.

Besonderes: Im Business Conten des Business Warehouses werden eine Reihe von Variablen ausgeliefert. Die Namenskonvention beschränkt sich auf die Variablen, die manuell angelegt werden mussten.


Z MMm_ ABCD

Kurzbeschreibung Modulbereich [ModulID] Z [Kundennamensraum]

4.12.3 Strukturen Strukturen sind Kombinationen aus Merkmalen und Kennzahlen (Basiskennzahlen, berechnete oder eingeschränkte Kennzahlen) des InfoProviders.

Besonderes: Die Defintiion der Namenskonvention beschränken sich auf diese Strukturen, die als wieder verwendbar abgespeichert werden.


Z MMm_ ABCD



Kurzbeschreibung Modulbereich [ModulID]] Z [Kundennamensraum]

4.12.4 Workbook Template 4.12.5 Workbooks

Besonderes: Der vom System generierte technische Name des Workbooks kann nicht verändert werden

Maximale Länge: 25 generiert vom System Beschreibung 210

4.13 Reporting Berechtigungs-Objekte Damit für das Reporting entsprechenden Berechtigungen vergeben werden können, müssen diese für die berechtigungsrelevanten Objekte angelegt werden.

Besonderes: Maximale Länge: 10 Beschreibung 60

Z_ MMm XXXX Name berechtigungsrelevantes InfoObject Modulbereich [ModulID] Z [Kundennamensraum]



5 Programme 5.1 Programmcode 5.1.1 ETH Standardprogramm Es existiert in der ABAP Library ein aktuelles Standardprogramm welches die Struktur und die allgemeinen Einstellungen eines ABAP Programmes beinhaltet. Dieses Programm ist immer als Ausgangslage für ein neues Programm zu kopieren – oder den entsprechenden Kopfteil im eigenen Programm einzupflegen. REPORT ZS_ETH_STANDARD. *-----------------------------------------------------------------* * Programmname : ZS_ETH_Standard * Entwickler : "Firma" / "Entwicklername" * Beschreibung :Beispieltext Beispieltext Beispieltext Beispieltext * Beispieltext Beispieltext Beispieltext Beispieltext * * Programmspezifikation: "Verweis auf Dokumentation" * Verantwortliche Stelle ETH: "z.B. HR Administraton" *-----------------------------------------------------------------* * SAP-Rel. : * Erstellungsdatum : : *-----------------------------------------------------------------* *-----------------------------------------------------------------* *Änderungs Log *-----------------------------------------------------------------* * Änderungsdatum : * Änderungsantrag : * Bearbeiter : * Beschreibung : * *-----------------------------------------------------------------* * Änderungsdatum : * Änderungsantrag : * Bearbeiter : * Beschreibung : * * *-----------------------------------------------------------------* * Aenderungen im Programmcode vermerken mit: "Name Datum * entweder am Anfang und Ende der Anpassung oder am Ende jeder Zeile * z.B. * Start Anpassung "Liechti 23.02.02 * Tables: zgr00, " Batch-Input Mappendaten * Ende Anpassung "Liechti 23.02.02 * oder * perform file_einlesen. "Liechti 23.02.02

5.1.2 Kopf und Fusszeilen Siehe Standardprogramm ZS_ETH_Standard 5.1.3 Codedokumentation Zusätzlich zu den fachlichen und technischen Dokumentationen muss jedes EU-Objekt im SAP dokumentiert werden. Dabei ist von der Möglichkeit der Langtexte Gebrauch zu machen.



Besonders ausführliche Dokumentationen sind zu folgenden EU-Objekten zu hinterlegen:

Objekt Was soll dokumentiert werden Programm – Grundsätzliche Programmbeschreibung im Programm-Header

– Änderungsdokumentation im Programm-Header – Beschreibung der Funktionalität in jeder Form – Beschreibung des Codings, so dass Änderungen durch andere

Entwickler durchgeführt werden können. Funktionsbaustein *) – Funktionalität des Funktionsbausteins

– Parameter des Funktionsbausteins Tabelle, Datenelement, ...

– Sind in der technischen Spezifikation festgehalten

Schema & Regel – Zur Dokumentation dieser Objekte können die SAP-Dokumentationen als Vorlage genommen werden. Diese sind exzellent dokumentiert.

*) Nicht oder schlecht dokumentierte Funktionsbausteine führen dazu, dass sie nicht gefunden bzw. nicht verwendet werden.

5.1.4 Klonen von SAP Standardcode Wenn Standardprogramme von SAP „geklont“ werden müssen folgende Regeln eingehalten werden: – Der originale SAP Code muss in Kommentar gesetzt werden [auf keinen Fall gelöscht

werden] – Wenn nur Teile [Zeilen] modifiziert werden, muss der Originalcode auskommentiert und

der modifizierte Code direkt unterhalb der Originalzeile eingefügt werden. – Wenn mehrere Zeilen oder ganze Blöcke verändert werden, müssen Beginn und Ende

des Blocks mit einer ganzen Zeile Kommentar und einer kurzen Beschreibung der Aktivität versehen werden.

5.1.5 Datendeklaration und Parameterbehandlung

5.2 Daten Definition Die Lesbarkeit und Wartbarkeit von ABAP-Programmen wird wesentlich erhöht, wenn programminterne Namenskonventionen eingehalten werden.

5.2.1 Datenelemente – Definition Alle Datenfelder die an ein externe System versendet werden müssen zwingend ein existierendes Objekt aus dem Data Dictionary referenzieren. Alle Datenelemente auf Reports müssen die selbe Länge und den selben Typ aufweisen wie im SAP Datendictionary.

# Typ Max. Länge

ID Bezeichnung

1 Interne Tabelle 30 it_ Bezug DB-Tabelle oder sinnvoller Name 2 Line of Interne Tab. 30 lo_it_ 3 Interne Struktur 30 s_ Bezug DB-Tabelle oder sinnvoller Name 4 Konstante [Fixwert] 30 c_ Fixwert [die Definition erfolgt über

«constants» und nicht über «data» 5 Select Option 8 so_ Bezug DB-Tabelle oder sinnvoller Name 6 Parameter 8 p_ Bezug DB-Tabelle oder sinnvoller Name 7 Checkbox 8 cb_ Checkbox sinnvoller Name 8 Radio Button 8 rb_ Radiobutton sinnvoller Name 9 Hilfsfeld 30 v_ temporäre Hilfsvariable 10 Variable [Text] 30 v_ Bezug DB-Tabelle oder sinnvoller Name 30 v_ Sinnvoller Name [keine v_1 – v_x] Variable [Numerisch]



Zähler/Loop Counter 30 cn_ Sinnvoller Name Range 8 r_ Bezug DB-Tabelle oder sinnvoller Name 30 f_ Für Flag, sinnvoller Name [keine f_1 – f_x]Switch [Schalter]

5.2.2 Initialisieren von Variablen Alle Felder und Tabellen müssen bei der Deklaration so initialisiert werden, dass kein zufälliger Wert entstehen kann [für eine direkte oder indirekte Nutzung]. Z.B. über Clear, Refresh, etc. 5.2.3 Interne Tabellen Interne Tabellen sollen immer nach neuer Regelung aufgebaut werden.

1. Struktur (Programm intern oder Data Dictionary) Types: begin of s_xxx 2. Interne Tabelle data: it_xxx type table of s_xxx 3. Line of Tabelle data: lo_it_xxxx like line of it_xxx

5.2.4 Hard-Coding In der Regel soll auf hart codierte Einträge wie Usernamen, Datum, Bezeichnungen, etc. verzichtet werden und der Weg über eine Steuertabelle oder unsichtbare Select Options/Parameter gewählt werden. 5.2.5 Message und Error Handling 5.2.6 Berechtigungsprüfung Alle Programme sind mit sinnvollen Berechtigungsprüfungen zu versehen. Nur die standardmässig eingebaute Prüfung auf den Transaktionscode reicht nicht, da oft Personen Programme laufen lassen können, auch aus fremden Modulen.

5.3 Layout 5.3.1 Ein Kommando pro Zeile Jedes ABAP/4 Kommando soll auf einer separaten Zeile stehen und mit einem Punkt abgeschlossen werden. Diese Vorgehensweise ermöglicht später in der Programmpflege die einzelnen Zeilen einfacher zu löschen, auszukommentieren und vor allem zu debuggen. Empfohlene Variante: IF N_STATUS EQ F_ERROR. EXIT. ENDIF. Nicht empfohlen: IF N_STATUS EQ F_ERROR. EXIT. ENDIF.

5.3.2 Einrücken [Pretty Printer] Damit alle Programme ein einheitliches «Look and Feel» haben sollen die logischen und strukturellen Levels immer um zwei Leerzeichen eingerückt werden. Beispiel: SELECT * FROM ZZTABRT. DELETE ZZTABRT. IF SY-SUBRC EQ 0. N_DEL_TABRT = N_DEL_TABRT + 1. ENDIF. ENDSELECT.



Der einfachheitshalber soll die «Pritty Printer» Funktion verwendet werden. 5.3.3 Gross/Kleinschreibung

5.4 Daten Selektion Die Datenselektion muss so effizient wie möglich erfolgen. SQL interne loops über SELECT und ENDSELECT sind zu vermeinen und mit der Varianten interne Tabelle zu ersetzen. Verschachtelte SELECT Anweisungen sind mit Joins zu ersetzen oder gegebenenfalls mit Views.

5.5 Restart und Recovery von Programmen

5.6 User Exits


entwicklerhandbuch_v2.01

Documents

externe berater

entwickler author

adrian fischer dokumentname

documents and

oss benutzer

zentrale definitionen

entwichlung programme