Vor einem Jahr bin ich mitsamt meiner Unternehmung bg-consulting umgezogen, und zwar aufs platte Land zwischen Bremen und Bremerhaven – Garlstedt bei Osterholz-Scharmbeck.

Wobei, so platt ist das hier gar nicht! Immerhin liegt einer der Gauß’schen Vermessungspunkte quasi um die Ecke. Aus der Wikipedia:
In den Jahren 1824 und 1825 hielt sich Carl Friedrich Gauß im Zuge der Hannoverschen Landesvermessung zeitweise in Garlste auf.[3] Der Gauß’sche Vermessungspunkt Garlste liegt auf 48,9 m über NN am Waldweg „An der Forst“.

Wer sich hier auskennt – 48,9 m über Normalnull ist für die hiesige Gegend ein Berg :) Angst vor Überflutung durch die Weser müssen wir daher definitiv keine haben. Eher fällt uns ein Baum aufs Dach. Zu Zeiten von Gauß muss hier sehr viel mehr abgeholzt gewesen sein, damit er irgendetwas anpeilen konnte.

Für meine Dienstleistungen rund um Dokumentations und Übersetzungsmanagement in SAP ändert das allerdings nichts, ich bin weiterhin sowohl im Raum Bremen/Bremerhaven als auch im Süddeutschen tätig. Der nächstgelegene Bahnhof Bremen-Burg bietet das Sprungbrett in die große weite Welt.

Und nur zwei Jahre nach Beantragung unseres Festnetzanschlusses haben wir auch schon DSL! Daher steht auch dem Homeoffice nichts im Weg. Von dem her – auf in die nächsten produktiven Jahrzehnte auf dem Land.

 

Im Bereich von eLearning/Autorentools/Schulung und Dokumentation gibt es eine Reihe von Anbietern:

SAP EnableNow – startete 2012 mit dem Erwerb von datango und wurde seitdem durch SAP weiterentwickelt, daher vermutlich am besten optimiert für SAP-Belange, inkl. S4/Hana

datango – das Original ist zurück mit seiner Performance Suite, die quasi ein eigenes Wiki mitbringt und laut Infos der Berater auch mit Confluence integriert werden kann

TTS – z.B. mit der Performance Suite. TTS bietet auch Dienstleistung rund um Erstellen und Trainings

Ancile uPerform – einer der Klassiker, begegnete mir in einer älteren Version in einem SAP-Projekt

Oracle Produktivity Kit – ebenfalls schon im Projekt begegnet

Alle diese Produkte arbeiten nach dem Prinzip, dass Filme aufgenommen werden, die dann in verschiedener Form ausgeliefert werden – als Film, klickbares Tutorial, Word, PDF und durchaus auch als Testvorlage.

Wer alles zu Fuß machen will, kann direkt mit einem Wiki arbeiten. Nachteil: es muss alles manuell dokumentiert werden. Vorteil: die Integration von Fremdinhalten und Dokumenten, die keine normale Anwenderdokumentationen / Schrittanleitungen sind, ist einfacher. Dies betrifft beispielsweise interne IT-Dokumentation. Außerdem sind die Lizenzkosten geringer (allerdings fließen mehr „Eh-da-Kosten“ der Mitarbeiter ein).

Die Lücke zwischen „Mitarbeiter nimmt Film auf in teurem Tool“ und „alles zu Fuß“ schließt mein Angebot Vids2Words – hier werden die aufgenommenen Filme durch Menschen in Dokumentationsform gegossen und stehen nachher als Word-Dateien für Schulungen zu Verfügung. Außer einem kleinen Tool wie SnagIt und einem Headset sind keine weiteren Aufwände in Ihrer Firma notwendig.

Das Grundproblem aller Ansätze ist allerdings die Pflege der Dokumentation. Leider gibt es keine Tools, die magisch neue Inhalte erkennen und einpflegen können. Auch Filme müssen aktualisiert werden, wenn sich Funktionen ändern. Daher ist der Change-Prozess für Dokumentation unbedingt festzulegen – idealerweise schon ausgehend von Entwicklung und Übersetzung muss die Aktualisierung von Dokumentation nachgeführt werden.

Hier punktet ein Wiki damit, dass eine Aktualisierung eine sehr niedrige Hürde für den Anwender hat. Es wurden schon installierte Tools abgelöst, weil die Fachanwender nicht bei Aktualisierungen alle 6 Monate erstmal das GUI für die Oberfläche des Tools neu installieren wollten.

Abhilfe kann hier ein internes Team sorgen, das den Hut aufhat. Dies gilt für alle Tools, die die Dokumentation unterstützen sollen – ein single point of contact, der bereichsweit kommuniziert ist, hält Reibungsverluste und Frust gering und sorgt dafür, dass die Fachanwender und Berater Zeit für ihre eigentlichen Themen haben, statt sich z.B. noch mit Übersetzung abzumühen.

SAP Report RSLANG20 verwenden

 SAP, Übersetzung  Kommentare deaktiviert für SAP Report RSLANG20 verwenden
Sep 142017
 

Der SAP-Report RSLANG20 ist dann hilfreich, wenn neue oder korrigierte Übersetzungen zwar im Objekt angekommen sind (Test hierfür ist z.B. der Aufruf des zugrundeliegenden DTEL in der SE63), aber nicht im Dynpro angezeigt wird.

RSLANG20 kann dann genutzt werden, um alle Dynpros einer Sprache mittels der Zusatzeinstellung „Force Mode“ neu zu generieren. Auf E/I-Systemen bedarf es dafür meist keiner Sonderrechte.

1. Transaktion SE38 aufrufen.
2. „RSLANG20“ eingeben und ausführen.
3. Sprache(n) wählen.
4. Einstellung „Force-Modus“ aktivieren.
5. Ausführen.

Erfahrungsgemäß treten Dynpro-Aktualisierungsprobleme auf P sehr selten, aber durchaus häufiger auf Q auf. Dort ist für das Ausführen dieses Reports dann ein Firefighter notwendig.

Die ausführliche SAP Note findet sich bei:
http://www.se63.info/110910-deleting-the-language-load/

Alternativ kann auch in der SE80 im Entwicklungspaket beim einzelnen Dynpro über einen Rechtsklick im Kontextmenü der Punkt „Aktivieren“ gewählt werden, dies aktualisiert dieses Dynpro.

SQL-Abfragen in Dragoman nutzen

 SAP, Übersetzung  Kommentare deaktiviert für SQL-Abfragen in Dragoman nutzen
Jul 042017
 

Es gibt in Dragoman die Möglichkeit, ein SQL-Statement für die Filterung von Tabelleneinträgen zu nutzen. Dies ist z.B. besonders sinnvoll, wenn die Tabelle sowohl SAP- als auch kundenspezifische Einträge enthält. Diese sind durch die führenden Buchstaben X, Y oder Z kenntlich (abhängig vom Projekt).

Wenn man in einem Dragoman-Szenario eine Tabelle einfügt, wird diese immer komplett ausgewertet. Bei einem Sprachtransport würden ebenfalls alle Zeilen transportiert werden. Über die SQL-Filter kann dies bis herunter auf einzelne Einträge eingeschränkt werden.

Ohne Filterung:

  • 15.000 Zeilen in der Tabelle = im Szenario und damit im Sprachtransport

Nach Filterung auf kundenspezifische Einträge:

  • 3.000 Zeilen im Szenario und damit im Sprachtransport

Nach Filterung auf den bekannten Namen von Einträgen, z.B. ZMNADR*:

  • 5 Zeilen im Szenario und damit im Sprachtransport

Nach spezifischer Filterung auf den bekannten Namen eines Eintrags, z.B. ZMNADR3:

  • 1 Zeile im Szenario und damit im Sprachtransport

Feldnamen für Filter ermitteln

Für den SQL-Filter sind die Feldnamen (DTEL-Objekte) sowie die Filterkriterien (z.B. der Inhalt startet mit „ZMNA*“) notwendig, auf die gefiltert werden kann.

Diese können am einfachsten über die SE16 ermittelt werden.

  1. SE16 aufrufen
  2. Tabelle eingeben.
  3. Vorhandene Felder prüfen, mit den Filtermöglichkeiten experimentieren und die Ergebnisse anzeigen lassen.
  4. Wenn das richtige Feld und Filter identifiziert sind, können diese in Dragoman übertragen werden.

SQL-Statements zusammenstellen

Prinzipiell wird ein FELD (aka eine Spalte) nach einem Inhalt durchsucht und dahingehend gefiltert.

FELD = 'ZMNADR3′        (gleich)

FELD <> 'ZMNADR3′    (ungleich)

FELD Like 'ZMNA%‘      (Feldinhalt beginnt mit ZMNA; das % entspricht einem * in SAP)

FELD Not Like 'ZMNA%‘   (Feldinhalt beginnt nicht mit ZMNA)

Kombinationen:

FELD = 'V2′ AND FELD2 like 'ZMNA%‘    (AND: beide Bedingungen müssen erfüllt sein)

FELD = 'V2′ OR FELD2 like 'ZMNA%‘   (OR: eine von beiden Bedingungen muss erfüllt sein)

 

SQL-Syntax in Dragoman eingeben

Die Eingabe des Filters kann im Dragoman über zwei Wege erfolgen:

  • Konfiguration > Texttabellen > Bearbeiten -> in der Bearbeitungssicht werden die SQL-Abfragen angezeigt
  • Szenariodefinition > Texttabellen

Link zur Dragoman-Dokumentation für SQL-Queries

Bei einer langen Liste von Tabellen, die z.B. mandantenabhängig gefiltert werden sollen, muss die SQL-Abfrage bei jeder Tabelle einzeln eingegeben werden.

Nach Eingabe des SQL-Filters sollte mit einer Vollanalyse und über den Vergleich mit dem Filterergebnis aus der SE16 geprüft werden, dass die richtigen Einträge gefunden wurden.

Danach kann in Dragoman wie üblich übersetzt und transportiert werden.

Als letzter Check kann in der SE09/SE10 noch der Transport geprüft werden. Auch dieser sollte nur die Einträge enthalten, die das SQL-Statement geliefert hat.

Tabellen übersetzen in SAP

 SAP, Übersetzung  Kommentare deaktiviert für Tabellen übersetzen in SAP
Jul 032017
 

Beim Übersetzen von Tabellen in SAP gibt es zwei mögliche Aspekte:

Kundenspezifische Felder (Spalten) der Tabelle

Die Tabelle wurde um kundenspezifische Felder erweitert, z.B. ZMMX_E_VERFALL. (Kundenspezifische Objekte beginnen üblicherweise mit X*, Y* oder Z*, abhängig vom Projekt.)

Analyse:

  1. SE11 aufrufen.
  2. Tabelle eingeben und „Anzeigen“.
  3. Struktur der Tabelle prüfen.
  4. Bei vorhandenem Datenelement mit Z*** Doppelklick auf das Feld, um das Objekt (vom Typ DTEL) zu öffnen.
  5. Über Springen > Übersetzung in die SE63 verzweigen und prüfen, wie der Übersetzungsstand ist.

Hier kann direkt übersetzt werden. Alternativ kann im Dragoman das Objekt in ein Dragoman-Szenario eingefügt werden über Konfiguration > Objektliste.

Übersetzungsrelevante Inhalte in der Tabelle

Die Tabelle selbst kann übersetzungsrelevante Inhalte haben. Dies kann man daran erkennen, dass es ein Feld SPRAS oder LANGU (beide vom Typ LANG) geben muss. Diese enthalten die Sprachkürzel.

Analyse:

  1. SE11 aufrufen.
  2. Tabelle eingeben.
  3. Struktur der Tabelle prüfen. Bei vorhandenem Feld SPRAS oder LANGU beinhaltet die Tabelle übersetzungsrelevante Inhalte.

Übersetzungsrelevante Tabelleneinträge können über die SE63 > Kurztexte > TABL übersetzt werden oder im Dragoman über Szenario > Konfiguration > Texttabellen.

Mehrere Quelldokumentationen sinnvoll in Zieldokumentation überführen

 Dokumentation, Tutorials  Kommentare deaktiviert für Mehrere Quelldokumentationen sinnvoll in Zieldokumentation überführen
Jan 132017
 

Eine häufige Ausgangssituation:

Dokumentation

  • aus zwei oder mehr Quellen
  • mit unterschiedlichen Strukturen
  • mit unterschiedlichen Inhalten
  • mit unterschiedlicher Tiefe an Inhalt

soll vereinheitlicht werden zu einer Zieldokumentation (meist in einem neuen Dokusystem), die alle aktuellen Inhalte abbilden soll.

Typischer Fehler, der an dieser Stelle  gemacht wird: „Wenn wir schon dran sind, vereinheitlichen wir jetzt alle Dokumente auf denselben neuen Stil!“

Meine Erfahrung: Dieser Ansatz führt dazu, dass alle vorhandene Dokumentation als „veraltet“ wahrgenommen und ein riesiger Arbeitsberg generiert wird, bei dem nach 20% dem Projekt die Puste ausgeht, weil das nächste dringende Projekt kommt.

Ein sinnvoller Ablauf (praxiserprobt für interne IT-Dokumentation; es war keine Rechtssicherheit notwendig):

1. Was genau liegt an Dokumenten vor? Dies erzeugt  eine lange und sehr wichtige Masterliste, z.B. in Excel. Hier gehören alle Infos rein:

  • Quellinfo: Laufende Nummer, Link in Dokusystem/Ordersystem/Sharepoint etc., Titel, Ansprechpartner, Größe des Dokument, Quellformat (bei mehreren vorhandenen Formaten), Qualitätsstatus (aktuell, nicht aktuell etc.).
  • Zielinfo: Status „Soll überführt werden“ (sonst Archivieren!), Status „Ist überführt“, Link im Zielsystem, ggf. neuer Titel, ggf. neues Format

Die Vollständigkeit der Liste ist entscheidend für jegliche Aussage über Aufwände und Fortschritt! Ohne eine klare Definition des Ausgangszustandes sind alle Aussagen zur Zielerreichung nur eine Schätzung/Hoffnung!

2. Den optimalen Zielzustand formulieren. Dies beinhaltet

  • das Format der Doku (alles von Copy&Paste bis stundenlanger Umarbeitung), ggf. von Hilfskräften durchführbar.
  • gewünschte Informationen und Tiefe der Informationen – dies führt potentiell zu sehr viel Arbeit bei den Sachexperten!

3. Mit einigen der ausgewählten Dokumente verschiedener Quellformate ein „Rapid Prototyping“ betreiben, d.h. einen Testlauf mit Zeitnahme (!), wie lange eine Umarbeitung in den 100% gewünschten Zustand dauert.

4. Dies mit einem Faktor von 2-3 auf die Dokumentation hochrechnen, die umgezogen werden soll.

5. Abgleichen mit dem gewünschten Endtermin des Projekts (z.B. Abschalttermin von Altsystemen) und den eingeplanten Personen und ihrer realistischen(!) Arbeitsstunden im Projekt.

An diesem Punkt stellt man meist fest, dass das Projekt so nicht machbar ist. Dokumentation umarbeitet kostet viel Zeit, diese wird immer unterschätzt.

6. Den machbaren Zielzustand definieren. Dies erfordert Abstriche an der Wunschliste, die in Punkt 2 formuliert wurde. Oft ist der Punkt „vollständige Dokumentation“ kritisch. Hier besser ein unvollständiges aktuelles Dokument umziehen und später ergänzen, als sich in der Datensammlung aufzuhalten (außer, es ist rechtlich kritische Dokumentation). Auch der Umbau der Formate sollte auf den kleinsten wirklich notwendigen Aufwand gekürzt werden.

7. Eine ausführliche Arbeitsanweisung für den Umzug der Dokumente erstellen, damit alle Schritte ausformuliert und festgehalten sind. Bei Quellformaten mit klaren Strukturen können hier oft Schritte automatisiert werden, z.B. mit VBA-Makros in Word.

8. Mit der Verarbeitung der Quelldokumente beginnen und – wichtig! – Soll-Prozess mit Ist-Prozess abgleichen! Wie lange dauert die Umarbeitung wirklich? Ist der Fortschritt wie geplant?
Erfahrungsgemäß muss eine Automatisierung immer wieder für Fälle erweitert werden, die im ursprünglichen Testset nicht erfasst waren.

Auch  ein Dokumentenumzug unterliegt der 80-20 Regel: 80% der Dokumente machen wenig Aufwand, 20% viel. Dokumente, die Probleme erzeugen, beiseite legen und in der Excel-Masterliste vermerken, damit sie mit etwas mehr Ruhe nachbearbeitet werden können. Etwas für regnerische Freitagnachmittage oder lange Zugfahrten.

Archivieren oder Löschen?

  • Nur wirklich obsolete oder doppelt vorhandene Dokumente sollten gelöscht werden.
  • Archivierte Dokumente sollten noch mindestens 2 Jahre im Zugriff sein. Erfahrungsgemäß muss immer wieder darauf zugegriffen werden, z.B. weil beim Umzug Inhalte verloren gingen oder sich Dokumente nachträglich als doch wichtig herausstellen. Für optimale Durchsuchbarkeit ist ein Ablegen von Word-oder PDF-Snapshots der Quelldateien in einem ganz normalen Ordnersystem hilfreich. Für datenbankbasierte Dokusysteme sollte zwei Jahre ein read-only Zugriff möglich sein. Motto: „Dateien fressen kein Brot. Archivieren ist billiger als neu Schreiben“.

Abschließender Tipp

Hier am Ende möchte ich nochmals betonen, dass ein genauer Überblick über die Dokumentation zum Startpunkt des Umzugs lebenswichtig ist. Dieser Überblick sollte an einer einzigen Stelle vorhanden sein (nicht verteilt über mehrere Systeme), und idealerweise von 1-2 Personen gepflegt sowie von allen Personen im Projekt gelesen werden können.

Mit einer Excel-Masterliste bin ich damals perfekt gefahren. Excel wird gerne kritisiert, dabei hat es auch viele Vorteile:

  • in jeder Firma vorhanden (jedenfalls in jeder, in der ich in 17 Jahren unterwegs war)
  • fast jeder kann die Kernfunktionen schon bedienen oder schnell geschult werden
  • sehr gute und schnelle Filtermöglichkeiten
  • sehr gut mit VBA automatisierbar
  • jederzeit schnell ein Backup in ein ZIP schreibbar

Soweit zum Thema Dateiumzug. Die ebenfalls große Frage „Und wie wird das dann alles zukünftig aktualisiert?“ behandle ich in einem zukünftigen Blogbeitrag.

Wichtigste Schnittstellen beim Übersetzen mit SNP Dragoman

 Business, SAP, Übersetzung  Kommentare deaktiviert für Wichtigste Schnittstellen beim Übersetzen mit SNP Dragoman
Jan 092017
 

Beim Übersetzen mit SNP Dragoman ist die Technik (aka die Verwendung von Dragoman) meist das kleinere Problem, wenn man einige grundlegende Ansätze – wie das Thema Vorschlagswerte und deren Befüllung – verstanden hat.

Die Schnittstelle zu Übersetzungsfirmen wird über die ausgeleiteten Excels abgebildet. Hier gibt es typischerweise folgende Probleme:

  • Das eigenartige Excel-Format (.xls, Format „XML Kalkulationblatt“) führt beim Öffnen beim Empfänger zu einer Meldung, die extra bestätigt werden muss. Dies kann über ein Speichern als echtes .xls geändert werden, muss aber vor dem Import wieder korrigiert werden. Dazu das Excel unter „XML Kalkulationsblatt“ speichern und die Endung im Explorer auf .xls ändern.
  • Bei der Verarbeitung kann es dazu kommen, dass die maximale Länge überschritten wird. Dies muss vor dem Import geprüft werden, bzw. nach erfolglosem Import muss die von Dragoman angemerkte überlange Zeile korrigiert werden.

Eine andere große Schnittstelle ist die mit der SAP Basis. Da SAP-Übersetzungen transportiert werden müssen, sind sie Teil des Transportwesens und unterliegen den in der Firma gelebten Prozessen. Folgende zwei Strategien sind üblich:

  • Übersetzungstransporte hängen an der Anforderung der jeweiligen Entwicklung und werden vom Anforderer selbst freigegeben und weiterbehandelt. Dies ist transporttechnisch die einfachste Strategie, führt allerdings in Dragoman zu vielen kleinen Szenarien. Für den Überblick sollten immer auch zusätzlich regelmäßig Analysen über Module gefahren werden.
  • Übersetzungen gelten als eigene Anforderungen, die Übersetzungen werden übergreifend über alle Module und ungeachtet der spezifischen Entwicklungen darin durchgeführt. Das Übersetzungsteam muss dabei analog zu jedem Entwickler den ganzen Zyklus einer Anforderungs-ID mitmachen. Dies führt zu Mehraufwänden und wird leicht problematisch, wenn das Übersetzungsteam nicht automatisch alle Entwicklungsinfos wie z.B. GoLive-Termine erhält. Außerdem kann durch die Entkopplung von Entwicklung und ihrer Übersetzung nicht immer nachvollzogen werden, wer zuständig ist (siehe nächsten Punkt).

Die dritte Schnittstelle ist die zur Entwicklung / den SAP-Teams, wenn es darum geht, fehlende Übersetzungen aufzuspüren. Typische Probleme:

  • Kein Entwickler zur Unterstützung der Analyse vorhanden. Fehlende SAP-Übersetzungen analysieren erfordert schon SAP-Kenntnisse. Dennoch kann es notwendig sein, für schwierige Fälle einen Entwickler mit der Analyse zu betreuen. Hier muss dem Auftraggeber klargemacht werden, dass hier ein gewisser Bedarf besteht, ca. 1-2 Stunden/Woche.
  • Bei analysiertem, aber für die Übersetzung unlösbaren Problem: Kein definiertes Team vorhanden, d.h. kein dezidierter Ansprechpartner z.B. für ein Modul greifbar. Manchmal hilft hier, Probleme solange auszusitzen, bis das Thema nach oben eskaliert und sich jemand auf der Entwicklungsseite dafür zuständig fühlt, das Problem anzugehen.

Die hier genannten Schnittstellenthemen sind besonders bei der Schätzung des Zeitaufwands von Übersetzungen wichtig, da hier sehr schnell viel Zeit vertreichen kann.

Mehrzeilige Texte in SNP Dragoman

 SAP  Kommentare deaktiviert für Mehrzeilige Texte in SNP Dragoman
Dez 152016
 

Mehrzeilige Texte können in SNP Dragoman in zwei Varianten auftreten:

  • Multiline-Texte („Langtexte“ in SAP): Langtextobjekte wie z.B. DOCU für F1-Hilfen, die in einer gesonderten Datei mit dem Namenszusatz „_ML“ ausgegeben werden.
  • Mehrzeilige Kurztexte: Kurztexte, deren Text auf mehrere Zeilen verteilt ist.

Problem der mehrzeiligen Kurztexte

Normalerweise werden Kurztexte alphabetisch ausgegeben. Bei einem mehrzeiligen Kurztext enden die Textteile daher verteilt im Excel, was für die Übersetzung problematisch sein kann.

Zerlegter Beispielsatz in alphabetischer Sortierung:

  • ggf. mit dem Einbauort aus dem Equipment
  • Soll der Technische Platz
  • überschrieben werden?

Diese Zeilen 1:1 zu übersetzen führt zu einem sehr missverständlichen Ergebnis.

Mehrfachsortierung in Excel

Durch eine Mehrfachsortierung in Excel ist es möglich, solche verteilten Kurztextzeilen zu finden:

Excel-Einstellung „Sortieren und Filtern“ -> „Benutzerdefiniertes Sortieren“:

  1. aufsteigend nach Obj_Name
  2. aufsteigend nach Object
  3. aufsteigend nach Object_Name_3

Das Ergebnis ist der korrekt sortierte Satz, der dann passend (aber auch hier nicht zeilenweise 1:1) übersetzt werden kann.

Soll der technische Platz Should the funct.loc.
ggf. mit dem Einbauort aus dem Equipment possibly be overwritten with inst.loc.
überschrieben werden? of the equipment?

Troubleshooting: Objekte können nicht in SNP Dragoman gefunden werden

 SAP  Kommentare deaktiviert für Troubleshooting: Objekte können nicht in SNP Dragoman gefunden werden
Dez 122016
 

Der Ausgangspunkt: Übersetzungen in der SAP-Oberfläche fehlen und sollen mit SNP Dragoman korrigiert werden. Doch die Objekte können in Dragoman nicht gefunden werden.

Mögliche Ursachen in SAP:

  • Hardkodierte Texte in der Programmierung: für Analyse und Korrektur Entwickler notwendig
  • Oberflächentexte werden aus z.B. einer Tabelle gezogen: für Analyse Entwickler oder Berater notwendig, Korrektur über Szenario mit der Tabelle darin

Mögliche Ursachen in Dragoman:

  • Falsches Entwicklungspaket im Blick, Texte werden aus anderem Modul gezogen: Prüfung über alle Entwicklungspakete
  • Analyse wird über „Anwendertexte“ gefahren, aber der Text wird von Dragoman als „technischer Text“ bewertet: Szenarioeinstellung anpassen und neue Vollanalyse starten
  • Szenario wurde über einzelne Objekte erstellt, aber das gesuchte Objekt ist noch nicht im Szenario: dies erfordert ein komplexeres Vorgehen.
    Beispiel fehlende Objekte in BW: Gesuchter Quelltext ist ABC, einziges bekanntes ELEM ist 123.
  1. Für die Start-Analyse wird ein sehr übergreifendes Szenario benötigt, beispielsweise über alle gelaufenen Transporte (von BW-Team erfragen).
  2. Über dieses Szenario eine Vollanalyse mit den Einstellungen „Alle Texte“ und „Verwendungsnachweis“ laufen lassen.
  3. Den Text ABC suchen und den Verwendungsnachweis aufrufen. Dieser liefert ELEM 123, ELEM 324, ELEM 654 und IOB 1XZ.
  4. Im Einzelszenario alle vier Objekte hinzufügen und die Vollanalyse laufen lassen. Sehr wahrscheinlich tauchen die fehlenden Objekte hier auf.

 

Was ist SAP Fiori?

 Sammelsurium  Kommentare deaktiviert für Was ist SAP Fiori?
Mrz 312016
 

SAP Fiori ist eine Möglichkeit, auf SAP aufsetzende Apps zu entwickeln, mit deren Hilfe sich definieret Prozesse in SAP durchführen lassen. Diese Prozesse müssen im SAP-Backend korrekt funktionieren, die Fiori-App setzt auf dem Backend auf. Es wird SAP HANA als Grundlage empfohlen.

In der Ausgabe basiert Fiori auf OpenUI5, einer von SAP mit-unterstützten Open-Source-JavaScript-Bibliothek.

Unter dem Link können Sie eine Fiori-Ausgabe sehen:
https://www.sapfioritrial.com/

Schöner Einführungsartikel zum Thema:
https://www.linkedin.com/pulse/20140608082721-29503826-sap-fiori-implementation-starter-guidlines

Die Dokumentation zu drei Standard-Apps finden Sie hier:
http://scn.sap.com/community/fiori/blog/2015/03/31/fiori-reference-apps-technical-documents

Eine ausführliche Anleitung zur Erweiterung der Standard-App gibt es hier:
https://de.scribd.com/doc/294681429/4/Technical-Background

Wie zu sehen, benötigt SAP Fiori sowohl Kenntnisse in SAP als auch in GUI-Design.
Nach einigen schmerzhaften Erfahrungen in großen Firmen kann ich nur hoffen, dass heutzutage auch fähige UX-Designer für die Apps genutzt werden – und nicht nur Junior-SAP-Berater ;)

© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha