Transfer von Tabelleninhalten
Hallo allerseits,
hier noch eine Frage.
Ich würde gern Testdaten von einer Maschine Q (Qualitätssicherung) auf eine Maschine E (Entwicklung) übernehmen, so dass ich mit vernünftigen Daten zumindest einen Entwicklertest machen kann.
Es gibt eine Datenbanktabelle in Q und die gleiche in E - die in Q ist ja entstanden durch einen früheren Transport von E auf Q.
Gibt es eine Möglichkeit, Tabelleninhalte von Q nach E zu transferieren - ein Transport von Tabelleninhalten scheidet hier leider aus organisatorischen Gründen aus.
Vielleicht ein Selektionsbaustein welcher von E per RFC aufgerufen werden kann und die Daten aus Q abgreift und in E in die Tabelle schreibt ?
Bin für jede schmutzige Idee zu haben, so lange sie funktioniert
gruß
hier noch eine Frage.
Ich würde gern Testdaten von einer Maschine Q (Qualitätssicherung) auf eine Maschine E (Entwicklung) übernehmen, so dass ich mit vernünftigen Daten zumindest einen Entwicklertest machen kann.
Es gibt eine Datenbanktabelle in Q und die gleiche in E - die in Q ist ja entstanden durch einen früheren Transport von E auf Q.
Gibt es eine Möglichkeit, Tabelleninhalte von Q nach E zu transferieren - ein Transport von Tabelleninhalten scheidet hier leider aus organisatorischen Gründen aus.
Vielleicht ein Selektionsbaustein welcher von E per RFC aufgerufen werden kann und die Daten aus Q abgreift und in E in die Tabelle schreibt ?
Bin für jede schmutzige Idee zu haben, so lange sie funktioniert
gruß
Ich weiß viel - aber nicht alles - deswegen lerne ich gern dazu & bin für Hinweise von erfahrenen ITlern immer dankbar.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
als Ergänzung - ich könnte den Baustein für das lesen von Inhalten in die Q Maschine transportieren - das ist problemlos möglich.
Ich weiß viel - aber nicht alles - deswegen lerne ich gern dazu & bin für Hinweise von erfahrenen ITlern immer dankbar.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
RFC_READ_TABLE
RFC_GET_TABLE_ENTRIES
RFC_GET_TABLE_ENTRIES
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
debianfan
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
So einen Tipp sollte man nicht ohne Warnhinweise geben. Das Q ist oft ein Abzug des Produktivsystems, in einem E-System (wo Entwickler SAP_ALL haben), haben solche Daten nichts zu suchen. Da reißt man im Zweifel enorme Datenschutz- und Sicherheitslücken auf.
Der Entwickler braucht eine Schulung in professionellen Testverfahren, keinen Funktionsbaustein. Sowas stellt das gesamte Berechtigungskonzept ad absurdum.
Für einen Entwicklertest braucht man keine speziellen Daten, sondern man sollte gescheite Unit-Tests schreiben, die diverse Konstellationen simulieren. Entwicklertest ist mehr als „F8, kein Dump, ab zum Test in den Fachbereich“.
Ralf
Der Entwickler braucht eine Schulung in professionellen Testverfahren, keinen Funktionsbaustein. Sowas stellt das gesamte Berechtigungskonzept ad absurdum.
Für einen Entwicklertest braucht man keine speziellen Daten, sondern man sollte gescheite Unit-Tests schreiben, die diverse Konstellationen simulieren. Entwicklertest ist mehr als „F8, kein Dump, ab zum Test in den Fachbereich“.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
debianfan
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Ich brauche als Entwickler einen hinreichenden Satz an halbwegs realistischen Testdaten an denen ich mein Programm testen kann bevor es auf das Test/Qualitätssystem geht um eben diverse Konstellationen selber durchtesten zu können. Und was nützen alle Unittests wenn die Methoden dann zwar das machen was abgetestet wurde, aber beim 1. Programmlauf mit realistischen Daten festgestellt wird, dass die wirklich interessanten und wesentlichen Kombinationen eben nicht erkannt/berücksichtigt/falsch interpretiert wurden.
Wenn du, Ralf, so gut bist, dass du all so was nicht brauchst: Chapeau. Bist dann aber der Einzige den ich kenne, der dermaßen gut ist!
Wenn du, Ralf, so gut bist, dass du all so was nicht brauchst: Chapeau. Bist dann aber der Einzige den ich kenne, der dermaßen gut ist!
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
Daniel • DeathAndPain • debianfan
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Da schüttele ich am Beginn des Wochenendes mal gepflegt mein weises Haupt. Ich überlege gerade wie viele Firmen ich kenne bzw. von denen ich über Umwege weiß, dass man als Entwickler sowieso alles sehen kann - auch auf dem Produktivsystem.ralf.wenzel hat geschrieben:So einen Tipp sollte man nicht ohne Warnhinweise geben. Das Q ist oft ein Abzug des Produktivsystems, in einem E-System (wo Entwickler SAP_ALL haben), haben solche Daten nichts zu suchen.
Wenn die Daten so wichtig sind, dann darf es sowieso keine RFC-Verbindung in ein System mit Echtdaten geben, in welches das Otto-Normal-Programmierwesen sonst nicht schauen dürfte. Das Problem ist dann nicht das Übertragen der Daten in ein E-System sondern die Existenz der Daten in einem System was das erlaubt mit Zugangsmöglichkeiten für Leute die das nicht dürfen.
Zumal die beiden FuBa berechtigungstechnisch abgesichert werden könnten falls es denn gelebt wird. ( Und wenn es nicht gelebt wird, ist das Problem doch eh viel höher aufgehängt ... )
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
debianfan
Lieber Ralf,ralf.wenzel hat geschrieben:So einen Tipp sollte man nicht ohne Warnhinweise geben. Das Q ist oft ein Abzug des Produktivsystems, in einem E-System (wo Entwickler SAP_ALL haben), haben solche Daten nichts zu suchen. Da reißt man im Zweifel enorme Datenschutz- und Sicherheitslücken auf.
Der Entwickler braucht eine Schulung in professionellen Testverfahren, keinen Funktionsbaustein. Sowas stellt das gesamte Berechtigungskonzept ad absurdum.
Für einen Entwicklertest braucht man keine speziellen Daten, sondern man sollte gescheite Unit-Tests schreiben, die diverse Konstellationen simulieren. Entwicklertest ist mehr als „F8, kein Dump, ab zum Test in den Fachbereich“.
Ralf
ich bin bei Dir - das Thema Datenschutz ist mir hier völlig klar.
Im Q System liegen aber namentlich Anonymisierte Daten vor - ich kann Dich also beruhigen.
Es geht hier um einen Test von Kombinationen von Daten welche keinen Rückschluss auf Kunden oder Mitarbeiter oder... zulassen.
Ich habe lange bei Finanzdienstleistern in der SAP IT gearbeitet - ich weiss wie allergisch die Revisionsmitarbeiter auf solche Dinge reagieren.
Gruß
Ich weiß viel - aber nicht alles - deswegen lerne ich gern dazu & bin für Hinweise von erfahrenen ITlern immer dankbar.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
debianfan hat geschrieben:ich bin bei Dir - das Thema Datenschutz ist mir hier völlig klar.
Im Q System liegen aber namentlich Anonymisierte Daten vor - ich kann Dich also beruhigen.
Das wusste ich nicht, sehr löblich.
Wenn ich mal geblitzt werde, werde ich das anführen: "Es fahren doch fast alle zu schnell, dann ist das nicht so schlimm".black_adept hat geschrieben:wie viele Firmen ich kenne bzw. von denen ich über Umwege weiß, dass man als Entwickler sowieso alles sehen kann - auch auf dem Produktivsystem.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Daten auf dem Produktivsystem sehen zu können ist für Entwickler zuweilen schlicht und ergreifend notwendig, etwa um Fehler zu finden, die nur auf dem Produktivsystem auftreten. Ich denke auch, dass man durchaus einige wenige Mitarbeiter definieren kann, denen man genug Vertrauen entgegenbringt, sie an alle Daten (lesend) heranzulassen. Gerade als Entwickler hat man so viel Macht. Wenn ich wollte, könnte ich - auch mit stark abgekniffenen Produktivberechtigungen - auf dem P praktisch alles machen. Da würde ich in irgendeinem Programm von mir in irgendeiner Programmversion etwas Code unterbringen, der irgendwas veranstaltet oder auch Daten für mich ausliest und mir zukommen lässt, und in der nächsten Programmversion wäre der wieder weg. Theoretisch könnte man den zwar natürlich auch später über die Versionierung noch wiederfinden, aber in der Praxis durchsucht ja niemand alle alten Version aller Programme, ob da irgendwas Hinterhältiges drinne ist (jedenfalls nicht, solange kein konkreter Verdacht aufkommt).Wenn ich mal geblitzt werde, werde ich das anführen: "Es fahren doch fast alle zu schnell, dann ist das nicht so schlimm".wie viele Firmen ich kenne bzw. von denen ich über Umwege weiß, dass man als Entwickler sowieso alles sehen kann - auch auf dem Produktivsystem.
Von daher halte ich es für wenig praktikabel, Entwickler Code schreiben zu lassen, der nachher auf dem Produktivsystem laufen wird, wenn man zu der Integrität dieser Entwickler kein Vertrauen hat. Ich hätte problemlos die Möglichkeit, die Gehälter auch der höchsten Führungsebene des Unternehmens, wo ich arbeite, einzusehen. Ich kenne diese Gehälter - ebenso wie die meiner umgebenden Kollegen - aber nicht, weil ich da nicht reinschaue. Sie gehen mich nichts an, und ich würde mich mit solchen Informationen nur selber belasten und verrückt machen - und im Extremfall irgendwo verplappern.
Von daher sehe ich für Entwickler auch Debug (ohne Replace) auf dem P als nicht dramatisch an.
Ich gebe Dir aber recht, dass nicht anonymisierte, produktive Daten nicht ins E gehören.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das hat mit Vertrauen nichts zu tun, was du da schreibst, ist in dieser Pauschalität schlichtweg verboten! Mal die DSGVO gelesen?DeathAndPain hat geschrieben:Daten auf dem Produktivsystem sehen zu können ist für Entwickler zuweilen schlicht und ergreifend notwendig, etwa um Fehler zu finden, die nur auf dem Produktivsystem auftreten. Ich denke auch, dass man durchaus einige wenige Mitarbeiter definieren kann, denen man genug Vertrauen entgegenbringt, sie an alle Daten (lesend) heranzulassen.Wenn ich mal geblitzt werde, werde ich das anführen: "Es fahren doch fast alle zu schnell, dann ist das nicht so schlimm".wie viele Firmen ich kenne bzw. von denen ich über Umwege weiß, dass man als Entwickler sowieso alles sehen kann - auch auf dem Produktivsystem.
Du hast offensichtlich noch nie in sicherheitskritischen Unternehmen gearbeitet. Ich kenne Kunden, bei dem JEDER Transportauftrag auditiert wird. Dann kriegst du auf "legalem" Weg kein Entwicklungsobjekt ins P (nichtmal ins Q!), das nicht wer kontrolliert hat.DeathAndPain hat geschrieben:Gerade als Entwickler hat man so viel Macht. Wenn ich wollte, könnte ich - auch mit stark abgekniffenen Produktivberechtigungen - auf dem P praktisch alles machen. Da würde ich in irgendeinem Programm von mir in irgendeiner Programmversion etwas Code unterbringen, der irgendwas veranstaltet oder auch Daten für mich ausliest und mir zukommen lässt, und in der nächsten Programmversion wäre der wieder weg. Theoretisch könnte man den zwar natürlich auch später über die Versionierung noch wiederfinden, aber in der Praxis durchsucht ja niemand alle alten Version aller Programme, ob da irgendwas Hinterhältiges drinne ist (jedenfalls nicht, solange kein konkreter Verdacht aufkommt).
Erzähl das bloß keinem -- wenn sowas die Aufsichtsbehörde erfährt, hat dein Arbeitgeber ratzfatz ein Bußgeldverfahren am Hals. Weil das nach DSGVO schlichtweg verboten ist.DeathAndPain hat geschrieben:Von daher halte ich es für wenig praktikabel, Entwickler Code schreiben zu lassen, der nachher auf dem Produktivsystem laufen wird, wenn man zu der Integrität dieser Entwickler kein Vertrauen hat. Ich hätte problemlos die Möglichkeit, die Gehälter auch der höchsten Führungsebene des Unternehmens, wo ich arbeite, einzusehen.
Sei froh, dass ich nicht dein Kollege bin und davon erfahre. Das ist ein klarer Rechtsverstoß.DeathAndPain hat geschrieben:Ich kenne diese Gehälter - ebenso wie die meiner umgebenden Kollegen - aber nicht, weil ich da nicht reinschaue. Sie gehen mich nichts an, und ich würde mich mit solchen Informationen nur selber belasten und verrückt machen - und im Extremfall irgendwo verplappern.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Die DSGVO ist ein riesiges Pamphlet, das ich nicht gelesen habe, nein. Ich habe übrigens auch das BGB noch nie von Anfang bis Ende gelesen. Auch nicht das StGB und die StVO. Noch nicht einmal das Grundgesetz. Das Telefonbuch übrigens auch nicht.Mal die DSGVO gelesen?
Aber bei Einführung der DSGVO wurde hier ein großes, monatelanges Projekt mit vielen Beteiligten, darunter Anwälte usw. aufgesetzt und alles in dieser Hinsicht sorgsam abgeklopft. Auch was meine Abteilung angeht. Solange Du also nicht benennen kannst, gegen genau welche Vorschrift der DSGVO bei uns verstoßen werden soll, behalte ich mir vor, Deinen Standpunkt für falsch zu halten.
Hier finden übrigens auch regelmäßige Audits statt.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
DIe DSGVO berührt aber unmittelbar deine berufliche Tätigkeit, die StVO nicht. Und nur weil nicht rausgekommen ist, dass du die Berechtigung hast, die Gehälter der Kollegen einzusehen, ohne dass die ihr Einverständnis gegeben haben, wird das noch nciht rechtmäßig.DeathAndPain hat geschrieben:Die DSGVO ist ein riesiges Pamphlet, das ich nicht gelesen habe, nein. Ich habe übrigens auch das BGB noch nie von Anfang bis Ende gelesen. Auch nicht das StGB und die StVO. Noch nicht einmal das Grundgesetz. Das Telefonbuch übrigens auch nicht.Mal die DSGVO gelesen?
Und an deiner Frage sehe ich schon, dass du die DSGVO nichtig Ansatz verstanden hast. Es gibt übrigens wenige Gesetze, die einfacher zu lesen sind. Grundsätzlich ist das Speichern personenbezogener Daten verboten. Es gibt nur wenige Ausnahmetatbestände:
1. Weil ein Gesetz das vorschreibt
2. Weil ein Vertragsverhältnis nicht anders umzusetzen ist
3. Weil der Betroffene eingewilligt hat
Es gibt kein Gesetz, das vorschreibt, dass ein Entwickler in die Gehaltsdaten gucken muss. Da andere Unternehmen das können, gibt es auch keinen Zwang, zur Realisierung des Arbeitsverhältnisses den Entwickler in die Gehaltsdaten gucken zu lassen. Und eingewilligt haben sie sicher auch nicht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Da fällt mir ein, vor 15 Jahren oder so habe ich mal eine Schnittstelle entwickelt in der firmeneigene Personaldaten hin und her geschoben wurden. Irgendwann haben die mir als Testdaten aus versehen Originaldaten geschickt, aller Angestellten, jede Lohnkomponente, Vorschüsse, Firmenwagenversteuerung usw. 
ich kannte natürlich nicht alle ca. 900 Personalnummern und habe sie nach und nach vervollständigt und wusste zumindest bei dem oberen Drittel wer was verdient. Und ich würde es in der gleichen Situation wieder machen. Natürlich hat die niemals jemand außer mir zu Gesicht bekommen.
Ich befand mich irgendwo unten im oberen Drittel, war ok für mich, habe es auch in etwa so geahnt.
ich kannte natürlich nicht alle ca. 900 Personalnummern und habe sie nach und nach vervollständigt und wusste zumindest bei dem oberen Drittel wer was verdient. Und ich würde es in der gleichen Situation wieder machen. Natürlich hat die niemals jemand außer mir zu Gesicht bekommen.Ich befand mich irgendwo unten im oberen Drittel, war ok für mich, habe es auch in etwa so geahnt.
Aua, solche Schweinereinen waren auch vor 15 Jahren garantiert nicht erlaubt.
Und sowas gibt man vor allem nicht schriftlich von sich.
Und sowas gibt man vor allem nicht schriftlich von sich.
Folgende Benutzer bedankten sich beim Autor A6272 für den Beitrag:
ralf.wenzel
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Du ziehst seltsame Schlussfolgerungen. Insbesondere scheinst Du mir hier die Speicherung und die Verarbeitung von Daten zu verwechseln. Wenn ich in Daten reinschauen kann, dann speichere ich sie nicht. Gespeichert sind sie, weil sie für die Geschäftsprozesse des HR erforderlich sind (Umsetzung des Beschäftigungsvertragsverhältnisses). In diesem Rahmen werden die Daten verarbeitet. Und ich bin letztlich ein Mitarbeiter der Abteilung, die dies tut.Ralf hat geschrieben:Und an deiner Frage sehe ich schon, dass du die DSGVO nichtig Ansatz verstanden hast. Es gibt übrigens wenige Gesetze, die einfacher zu lesen sind. Grundsätzlich ist das Speichern personenbezogener Daten verboten. Es gibt nur wenige Ausnahmetatbestände:
1. Weil ein Gesetz das vorschreibt
2. Weil ein Vertragsverhältnis nicht anders umzusetzen ist
3. Weil der Betroffene eingewilligt hat
Es gibt kein Gesetz, das vorschreibt, dass ein Entwickler in die Gehaltsdaten gucken muss. Da andere Unternehmen das können, gibt es auch keinen Zwang, zur Realisierung des Arbeitsverhältnisses den Entwickler in die Gehaltsdaten gucken zu lassen. Und eingewilligt haben sie sicher auch nicht.
Insofern finde ich es völlig schräg, wie Du aus den von Dir genannten Punkten schlussfolgern möchtest, dass es keinen Mitarbeiter im Unternehmen geben darf, der Zugriff auf die Daten hat.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Vergleichbare Themen
1
Antw.
Antw.
2367
Views
Views
Open Dataset, Transfer, Close Dataset.Transfer unvollständig
von mari » 25.09.2007 09:28 • Verfasst in ABAP® Core
von mari » 25.09.2007 09:28 • Verfasst in ABAP® Core
5
Antw.
Antw.
2203
Views
Views
3
Antw.
Antw.
2078
Views
Views
2
Antw.
Antw.
2376
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.