Coding verstecken

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
13 Beiträge • Seite 1 von 1
13 Beiträge Seite 1 von 1

Coding verstecken

Beitrag von migrationshansel (ForumUser / 5 / 0 / 0 ) »
Hallo zusammen,

brauche mal eure Hilfe:

Programmiere gerade an einem Tool herum, das Domäneninhalte umsetzen soll. Dafür brauche ich für eine bestimmte Funktionalität (Lizenzprüfung) Coding, welches im Debugger nicht sichtbar sein darf und das in diesem Zustand transportiert und beim Kunden eingespielt werden kann.

Ich hatte mal ein Stück Coding, ich glaube ZHIDE, mit welchem man das Coding für Programme die im Z- oder Y-Raum liegen, quasi "unsichtbar" machen konnte. Allerdings programmiere ich im Namensraum (/XXX/) und dort funktioniert der Codingschnipsel nicht.

Deshalb meine Frage:

Hat irgendjemand eine Source, mit dem man einen Report, besser ein Include, so verändern kann, das es zwar ausgeführt und transportiert wird, das Coding in der SE38/80 und im Debugger jedoch nicht sichtbar ist? Ausserdem muss der ganze Prozess auch reversibel sein (damit ich den Quellcode auch auf unserem Entwicklungssystem wieder bearbeiten kann).

Ach ja, wenn jemand eine Möglichkeit kennt, eine Lizenzabfrage so zu gestalten, das diese vom Kunden nicht ausgehebelt werden kann, bin ich auch dafür dankbar. Allerdings fällt mir dazu nichts rechtes ein, da alles was ich mir überlegt habe auch mit ABAP-Mitteln wieder ausgehebelt werden kann.

Und ja, ich weiss, das ich mir jetzt wieder anhören muss, das man Coding nicht versteckt und ich ein schlechter Programmierer bin oder das es schlechter Stil ist und was weiss ich nicht noch alles. Ja, ihr habt recht (bis auf den schlechten Programmierer :P ), aber mir fällt ausser dieser Möglichkeit keine andere ein, mit der ich ein lebenswichtiges Include vor Änderung schützen und in diesem auch noch die Lizenzprüfung unterbringen kann. Ja, ich weiss auch, das es Vereinbarungen mit Kunden gibt aber jeder von euch, der mehr als nur ein halbes Jahr in dieser Branche tätig war, weiss, das, sobald man kein Zugriff mehr auf das Kundensystem hat, dieser damit tun und lassen kann, was er will (und weiss auch von Fällen, wo genau das passiert ist. Leider kann ich es nicht beweisen, da ich keinen Zugriff mehr auf das System habe und auch nicht mehr bekommen werde).

Und nein, ich kann nicht per RFC auf ein anderes System zugreifen (falls jemand daran denkt, die Lizenz auf einem anderen System abzufragen).

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Coding verstecken

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
migrationshansel hat geschrieben:Ich hatte mal ein Stück Coding, ich glaube ZHIDE, mit welchem man das Coding für Programme die im Z- oder Y-Raum liegen, quasi "unsichtbar" machen konnte.
Das war aber Pillepalle - programmier das Zeugs extern (z.B. in C), in deinem Programm springst du dann ab und hast nach der Rückkehr ein Flag, das dir sagt, ob die Lizenzprüfung erfolgreich war -- so dass ABAP-technisch das "geheime" Codestückchen als Blackbox fungiert.

Abgesehen davon kann man Lizenzprüfungen auch so gestalten, dass sie offen sind ;)


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Beitrag von migrationshansel (ForumUser / 5 / 0 / 0 ) »
die idee es extern zu lösen hatte ich auch schon. allerdings ist mir das von meinem entwicklungsleiter untersagt worden (sagt nichts, ich tu es auch nicht. ich hab mich schon genug geärgert). also muss ich versuchen das ganze irgendwie NUR mit SAP-mitteln zu lösen. ob es dabei "schmutzig" zugeht ist mir dann im endeffekt egal.

Beitrag von Steff (Site Admin / 386 / 0 / 1 ) »
Hallo,

die wesentlichen Informationen findest Du wohl hier:

http://www.abapforum.com/viewtopic.php?p=5361#5361

Wie gesagt, es wird sich mit ABAP-Mitteln nicht loesen lassen - nur hart im Kernel. Oder eben die Variante mit externem Aufruf.

Gruss,
Steff

Re: Coding verstecken

Beitrag von Frank Dittrich (Expert / 674 / 0 / 15 ) »
migrationshansel hat geschrieben: Programmiere gerade an einem Tool herum, das Domäneninhalte umsetzen soll. Dafür brauche ich für eine bestimmte Funktionalität (Lizenzprüfung) Coding, welches im Debugger nicht sichtbar sein darf und das in diesem Zustand transportiert und beim Kunden eingespielt werden kann.
Und das Tool zum Umsetzen von Domäneninhalten (was auch immer Du da konkret "umsetzt", z.B. Feldinhalte in Tabellen, die mit Bezug auf die Domäne definiert sind) ist so toll, dass den Quelltext keiner sehen darf?

Und wer behebt dort die Bugs?
(Du willst noch mal kassieren? Du machst keine Fehler? Der Kunde kann ruhig warten, bis Du mal wieder Zeit hast?)
Ich hatte mal ein Stück Coding, ich glaube ZHIDE, mit welchem man das Coding für Programme die im Z- oder Y-Raum liegen, quasi "unsichtbar" machen konnte. Allerdings programmiere ich im Namensraum (/XXX/) und dort funktioniert der Codingschnipsel nicht.
Das Nicht-Funktionieren liegt aber nicht am Namensraum, soweit man bei ZHIDE von Funktionieren reden kann.
Jedenfalls ist das Aufheben der Beschränkung auf den Kundennamensraum noch das kleinste Problem.
Hat irgendjemand eine Source, mit dem man einen Report, besser ein Include, so verändern kann, das es zwar ausgeführt und transportiert wird, das Coding in der SE38/80 und im Debugger jedoch nicht sichtbar ist?
Das geht nicht. Der "Schutz" lässt sich umgehen.
Ausserdem muss der ganze Prozess auch reversibel sein (damit ich den Quellcode auch auf unserem Entwicklungssystem wieder bearbeiten kann).
Das Problem ist doch trivial lösbar..
Ach ja, wenn jemand eine Möglichkeit kennt, eine Lizenzabfrage so zu gestalten, das diese vom Kunden nicht ausgehebelt werden kann, bin ich auch dafür dankbar.
Steff hat schon den passenden Link zum Thread aus April 2002 genannt.
In meinem Beitrag sind auch ein paar Links auf News-Beiträge aus de.alt.comp.sap-r3.

Anscheinend haben sich nicht genug Eigentümer von /PREFIX/-Namensräumen gefunden, die mal entsprechende Entwicklungsanträge eingereicht haben.
Quelltext-Schutz lässt sich zwar auch von SAP nicht umsetzen.
Aber ein Ausführen nicht lizensierter Programme könnte die SAP-Laufzeitumgebung schon verhindern bzw. wesentlich schwerer umgehbar gestalten als so einen Quelltext-Schutz.
Allerdings fällt mir dazu nichts rechtes ein, da alles was ich mir überlegt habe auch mit ABAP-Mitteln wieder ausgehebelt werden kann.
Eben. Auch wenn man nicht weiß, wie man den Quelltext-Schutz aufheben soll, kommentiert man eben die Lizenzabfrage aus.
(Oder Du musst allen Deinen Quelltext schützen.)
Und ja, ich weiss, das ich mir jetzt wieder anhören muss, das man Coding nicht versteckt
Wenn Du das schon weißt, warum fragst Du dann?
und ich ein schlechter Programmierer bin oder das es schlechter Stil ist und was weiss ich nicht noch alles. Ja, ihr habt recht (bis auf den schlechten Programmierer :P )
Wasd heißt schon "schlechter Stil". Den findet man auch in vielen nicht "geschützten" Quelltexten.
Ob Du ein Schlechter Programmierer bist, kann ich nicht beurteilen. Allerdings hast Du bisher hier auch noch keinen Beweis des Gegenteils geliefert.
Dass Du ZHIDE nicht sofort als einen Haufen Sondermüll erkannt hast, spricht jedenfalls nicht gerade für Dich. (Ein paar der Probleme sind Dir aber anscheinend aufgefallen, z. B. das mit den Includes/der Transportierbarkeit.
Das ist aber nur ein Bruchteil.)
Aber mir fällt ausser dieser Möglichkeit keine andere ein, mit der ich ein lebenswichtiges Include vor Änderung schützen und in diesem auch noch die Lizenzprüfung unterbringen kann.
Es gibt auch keine brauchbare Möglichkeit.
Von wem Kommt denn die Anforderung.
Ja, ich weiss auch, das es Vereinbarungen mit Kunden gibt aber jeder von euch, der mehr als nur ein halbes Jahr in dieser Branche tätig war, weiss, das, sobald man kein Zugriff mehr auf das Kundensystem hat, dieser damit tun und lassen kann, was er will
Manchmal musss er auch einfach Zugriff haben, um Fehler zu korrigieren.
Gerade in Lizenzprüfungs-Routinen findet sich oft ekelhafter Code, der anscheinend auch nach gelungenem Aufheben des Quelltext-Schutzes das Umgehen der Lizenzprüfung verhindern soll.
(Geht sowieso nicht, man kommentiert die Prüfung einfach aus.)
Die ist oft nicht release-unabhängig, nicht unicode-fähig, scheitert in Systemen mit gemischten Big- und Little-Endian-Servern ...

Und auch bei Deinem Programm kann ich mir die Notwendigkeit, Fehler beheben zu müssen, gut vorstellen.
Wenn Du nur die Tabelleninhalte für Felder anpasst, die sich auf die Domäne beziehen, ist ein Hauptproblem ja die Wiederaufsetzbarkeit.
Insbesondere wenn der alte und neue Wertebereich sich überschneiden.
(Je nach SDOMA und Tabellen kann es auch noch um die Größe der Rollback Area, Sperren von Objekten, Änderungsbelege ... gehen.)

Wenn Du aber auch noch Report-Varianten anpassen mussst, in denen Felder sich über DTEL auf die DOMA beziehen, komt man schnell in komplexere Abhängigkeiten, wo man durchaus Fehler machen kann.
Ebenso bei DDIC-Strukturen, die mit EXPORT ... TO DATABASE gesichet wurden.
(und weiss auch von Fällen, wo genau das passiert ist. Leider kann ich es nicht beweisen, da ich keinen Zugriff mehr auf das System habe und auch nicht mehr bekommen werde).
Dann schreib doch genau dieses Recht in Deine Lizenzverträge rein.

Bedenke aber, dass Du ehrliche Kunden verprellen könntest.

Da Du mal "wir" und mal "ich" sagst: Wem gehört denn der Namensraum?
Welche Kostem muss man mindestens für eine Entwickler-Lizenz einkalkulieren, so dass man bei SAP seinen eigenen Namensraum registrieren darf?

Re: Coding verstecken

Beitrag von migrationshansel (ForumUser / 5 / 0 / 0 ) »
Doppelpost
Zuletzt geändert von migrationshansel am 12.03.2007 21:54, insgesamt 2-mal geändert.

Re: Coding verstecken

Beitrag von migrationshansel (ForumUser / 5 / 0 / 0 ) »
Frank Dittrich hat geschrieben:
migrationshansel hat geschrieben: Programmiere gerade an einem Tool herum, das Domäneninhalte umsetzen soll. Dafür brauche ich für eine bestimmte Funktionalität (Lizenzprüfung) Coding, welches im Debugger nicht sichtbar sein darf und das in diesem Zustand transportiert und beim Kunden eingespielt werden kann.
Und das Tool zum Umsetzen von Domäneninhalten (was auch immer Du da konkret "umsetzt", z.B. Feldinhalte in Tabellen, die mit Bezug auf die Domäne definiert sind) ist so toll, dass den Quelltext keiner sehen darf?

Hab ich das gesagt? Davon war nie die Rede. Hättest du genau gelesen, hättest du festgestellt, das es hier nicht um den Schutz vor "abgucken" sondern um das nicht umgehbare Abfragen eines Lizenzschlüssels geht (bzw. die Unbrauchbarmachung des Tools wenn jemand die Abfrage auskommentiert).

Und wer behebt dort die Bugs?
(Du willst noch mal kassieren? Du machst keine Fehler? Der Kunde kann ruhig warten, bis Du mal wieder Zeit hast?)

Danke für die Unterstellung. Die Wartung und Pflege für den Zeitraum der Lizenz bzw. des Projekte obliegt selbstverständlich mir oder unserem Unternehmen. Auch davon war in keinem meiner Posts die Rede.
Allerdings fällt mir dazu nichts rechtes ein, da alles was ich mir überlegt habe auch mit ABAP-Mitteln wieder ausgehebelt werden kann.
Eben. Auch wenn man nicht weiß, wie man den Quelltext-Schutz aufheben soll, kommentiert man eben die Lizenzabfrage aus.
(Oder Du musst allen Deinen Quelltext schützen.)

Da hätte ich schon eine Idee, wenn der Quelltext-Schutz funktionieren würde.Sonst hätte ich die Frage ja auch nicht gestellt.
Und ja, ich weiss, das ich mir jetzt wieder anhören muss, das man Coding nicht versteckt
Wenn Du das schon weißt, warum fragst Du dann?

Weil es, wie von dir, sowieso von irgendjemandem gekommen wäre.

Dass Du ZHIDE nicht sofort als einen Haufen Sondermüll erkannt hast, spricht jedenfalls nicht gerade für Dich. (Ein paar der Probleme sind Dir aber anscheinend aufgefallen, z. B. das mit den Includes/der Transportierbarkeit.
Das ist aber nur ein Bruchteil.)

Danke für die Blumen. Ich könnte dir auch noch ein paar nennen aber lassen wir das.
Aber mir fällt ausser dieser Möglichkeit keine andere ein, mit der ich ein lebenswichtiges Include vor Änderung schützen und in diesem auch noch die Lizenzprüfung unterbringen kann.
Es gibt auch keine brauchbare Möglichkeit.
Von wem Kommt denn die Anforderung.

Lies den dritten Post, dann weisst du es.
Ja, ich weiss auch, das es Vereinbarungen mit Kunden gibt aber jeder von euch, der mehr als nur ein halbes Jahr in dieser Branche tätig war, weiss, das, sobald man kein Zugriff mehr auf das Kundensystem hat, dieser damit tun und lassen kann, was er will
Manchmal musss er auch einfach Zugriff haben, um Fehler zu korrigieren.

Braucht er nicht, da der Kunde nur eine Projektlizenz erwirbt und er das Projekt eh nicht selber durchführt. Wenn er will, darf er das Tool gerne danach löschen (wenn es denn alle täten).

Und auch bei Deinem Programm kann ich mir die Notwendigkeit, Fehler beheben zu müssen, gut vorstellen.
Wenn Du nur die Tabelleninhalte für Felder anpasst, die sich auf die Domäne beziehen, ist ein Hauptproblem ja die Wiederaufsetzbarkeit.

Kein Problem

Insbesondere wenn der alte und neue Wertebereich sich überschneiden.
(Je nach SDOMA und Tabellen kann es auch noch um die Größe der Rollback Area, Sperren von Objekten, Änderungsbelege ... gehen.)

Kein Problem was die Grösse des Rollbacks bzw. das Sperren von Objekten und die Änderungsbelege betrifft. Überschneidungen des Wertebereiches sind eine Definitionssache des Kunden. Ich werde natürlich nicht Daten umsetzen, bei denen der Zielwert bereits vorhanden ist (wäre ja auch schwachsinnig). Sollte es dennoch zu Überschneidungen kommen (z.b. bei variablen Schlüsseln), so muss vorher zusammen mit dem Kunden festgelegt werden, wie in diesen Fällen verfahren werden soll.

Wenn Du aber auch noch Report-Varianten anpassen mussst, in denen Felder sich über DTEL auf die DOMA beziehen, komt man schnell in komplexere Abhängigkeiten, wo man durchaus Fehler machen kann.

Report-Varianten sind auch kein Problem. Erfordern zwar mehr Analyseaufwand aber auch das ist machbar.

Ebenso bei DDIC-Strukturen, die mit EXPORT ... TO DATABASE gesichert wurden.

Kein Problem solange der Kunde mir seine eigenen "Clustertabellen" und deren Aufbau mitteilt. Eine Umsetzung ist auch hier generisch möglich (Umsetzung von Tabellen wie PCL2, RFDT etc. ist schon mit der Standardauslieferung möglich).
(und weiss auch von Fällen, wo genau das passiert ist. Leider kann ich es nicht beweisen, da ich keinen Zugriff mehr auf das System habe und auch nicht mehr bekommen werde).
Dann schreib doch genau dieses Recht in Deine Lizenzverträge rein.

Steht schon drin. Trotzdem weiss ich, das zwei Kunden sich genau darum, auf gut Deutsch gesagt, einen Scheissdreck gekümmert und auf eigene Faust mit dem Tool gearbeitet haben (und wie ich gehört habe auch erfolgreich). Aber wie gesagt, ich hab den Beweis nicht.

Bedenke aber, dass Du ehrliche Kunden verprellen könntest.

Auch das ist mir klar. Aber ehrlich: welches kommerzielle Programm, d.h. gegen Geld erwerbbare Programm, hat keine Lizenzprüfung? Nenn mir nur ein einziges (Distributionen zählen nicht).

Da Du mal "wir" und mal "ich" sagst: Wem gehört denn der Namensraum?

Der Namensraum gehört der Firma, bei der ich angestellt bin.


Aber egal, diese Diskussion führt zu nichts. Ich lass einfach die Finger davon und werde mitteilen, das ich dieses Problem mit den mir zur Verfügung stehenden Mitteln nicht lösen werden kann. Sollen sich die Anwälte Gedanken darüber machen, die kriegen schliesslich Geld dafür.

Bitte den Thread schliessen.

Danke

P.S.: @Steff: Danke für den Link

Re: Coding verstecken

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
migrationshansel hat geschrieben:Aber egal, diese Diskussion führt zu nichts. Ich lass einfach die Finger davon und werde mitteilen, das ich dieses Problem mit den mir zur Verfügung stehenden Mitteln nicht lösen werden kann. Sollen sich die Anwälte Gedanken darüber machen, die kriegen schliesslich Geld dafür.
Mir fallen einige Dinge auf in diesem Thread, tlw. erwecken sie meinen Unmut:

1. Das offensichtlichste: Der OP kann offensichtlich nicht quoten. Das sollte er lernen wenn er häufiger in Foren dieser Machart (phpBB) posten will. Sonst werden seine Postings unleserlich, insbesondere wenn sie so lang sind wie das letzte.

2. Warum blafft ihr euch so an? Die Verhältnisse sind doch klar: Der OP hat die Anweisung von seinem Entwicklungsleiter, das auf eine bestimmte Art durchzuführen. Dass er das so will, spricht klar gegen den Entwicklungsleiter, weil es fachlicher Schwachsinn ist (abgesehen davon: jede Firma, die sowas SO löst, disqualifiziert sich in meinen Augen). Hier bietet sich an, sich bei der SAP abzugucken, wie die solche Probleme löst.

3. Nun zum eigenltichen Thema: Einhellige Meinung ist, dass der Vorschlag dieses Entwicklungsleiters (ich drücke mich mal diplomatisch aus) "Potential hat". Es gibt zwei Arten von Entwicklungsleitern/Projektleitern (und ich habe in meiner fast 10jährigen beruflichen Praxis beide kennengelernt): Die, die genug Fachwissen haben, um solche Detailentscheidungen zu treffen und die, die das nicht haben.

Der Chef vom OP gehört scheinbar zu letzteren Gruppe, bedauerlicherweise scheint ihm das aber noch niemand gesagt zu haben. Als Angehöriger der "Nicht-Experten" (das ist in keinster Weise ehrenrührig, es ist nicht die Aufgabe eines Entwicklungsleiters, sich so in die Details zu verstricken; mir sind solche Leute lieber als die Detailexperten, die am liebsten alles selbst machen) sollte er die Entwickler solche Entscheidungen treffen lassen.

Tipp daher an den OP: Geh zu dem Typen und begründe ihm sachlich, warum die von ihm vorgeschlagene Lösung nicht gut ist - dann gibt es zwei Möglichkeiten: Du bekommst die dienstliche Anweisung es trotzdem zu machen, dann macht man eine entsprechende Notiz/Mail, damit man später nachweisen kann, dass man Bedenken hatte. Oder er sieht es ein und ihr kommt zur technisch besseren Lösung.

Einen anderen Weg sehe ich nicht.


So, das musste ich noch dazuschreiben.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Wenn die Lizenzabfrage lediglich einmalig erfolgen muss, könnte man einen Teil des Quelltexes einfach chiffriert ausliefern und beim ersten Aufruf dechiffriert in die Programmdatenbank zurückschreiben
Ausserdem muss der ganze Prozess auch reversibel sein
Damit ist schon gewährleistet, dass das System potenziell kompromittierbar ist.
Auch das ist mir klar. Aber ehrlich: welches kommerzielle Programm, d.h. gegen Geld erwerbbare Programm, hat keine Lizenzprüfung? Nenn mir nur ein einziges (Distributionen zählen nicht).
Nenn mir ein einziges Programm mit Lizenzprüfung dessen Lizenzprüfung sicher ist. Stichwort: Serial ( und ich meine keine Serialnummern im SAP )
Und ich habe zu Hause genug Programme, die ich gekauft habe und die keine Lizenzprüfung benötigen. Einige sind z.B. auf Cartrigdes die in meinen Nintendo DS passen...
Aber wie gesagt, ich hab den Beweis nicht.
Wenn das Programm hinreichend komplex ist und die Ergebnisse auch nur minimal variieren dürfen erzeuge Wasserzeichen. ( Dazu reicht z.B. schon eine Reihenfolge und/oder Manipulation von Zeitstempeln )
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Beitrag von MarkusW (Specialist / 406 / 5 / 0 ) »
Es gibt doch die Möglichkeit in SAP 'Makros' zu schreiben....diese werden nicht debugged (können nicht debugged werden, weils nur zeilen in einer tabelle sind)

vllt ist das ja ein ansatz...

Gruß
Markus

Beitrag von poldi (Specialist / 116 / 0 / 0 ) »
Hallo Migrationshansel,

setze den Kommentar in die erste Zeile des Quelltextes: *@#@@[SAP] .
das geht nur über INSERT REPORT.

Warnung: Ich konnte den Quelltext nicht mehr sichtbar machen. Es geht nur noch ausführen und löschen.

Ob das Ganze transportiert werden kann, weiß ich nicht.

Viele Grüße
Wilfried
Wir sind lustig und haben es gar nicht nötig!

Beitrag von DeathGuardian (Expert / 759 / 0 / 3 ) »
poldi hat geschrieben:Hallo Migrationshansel,

setze den Kommentar in die erste Zeile des Quelltextes: *@#@@[SAP] .
das geht nur über INSERT REPORT.

Warnung: Ich konnte den Quelltext nicht mehr sichtbar machen. Es geht nur noch ausführen und löschen.

Ob das Ganze transportiert werden kann, weiß ich nicht.

Viele Grüße
Wilfried
Ging das ganze nicht nur bis zu einem bestimmten Relase?
Glaub ab 4.6C ging es schon nicht mehr.

Beitrag von poldi (Specialist / 116 / 0 / 0 ) »
Geht in 4.7 (SAP R/3 Enterprise)!
Wir sind lustig und haben es gar nicht nötig!

Seite 1 von 1

Vergleichbare Themen

6
Antw.
3739
Views
SALV-Varianten - Admin-Button verstecken
von DUTZMIC » 20.02.2015 09:42 • Verfasst in ABAP Objects®
5
Antw.
2020
Views
Link in Mail hinter einzelnem Wort verstecken
von Dyrdek » 04.10.2017 13:42 • Verfasst in ABAP® Core
2
Antw.
1253
Views
Anzeigen/Verstecken eines Textfeldes zur Laufzeit - möglich?
von Paba » 24.05.2005 11:24 • Verfasst in ABAP® Core
1
Antw.
1075
Views
HTML-Diagramm Trial Version Kennzeichen verstecken/löschen
von JanR » 28.10.2020 12:26 • Verfasst in Fiori, UI5, JavaScript
3
Antw.
3681
Views
In der TA PR05 Felder "Stornieren" ausgrauen oder verstecken
von Anfänger » 28.08.2018 11:09 • Verfasst in SAP - Allgemeines

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141