Intervallbildung mit Provide-Endprovide??
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo,
ich habe da ein kleines Problem. Dachte, das ich sowas schonmal programiert hätte, aber warscheinlich trübt mich da meine Erinnerung (das Coding finde ich nicht mehr, und bin auch nicht mehr in dieser Firma).
Ich suche eine Möglichkeit, möglichst einfach und elegant aus verschiedenen HR-Infotypen (die beinhalten ja immer BEGDA-ENDDA) automatisch Intervalle bei Wechsel von verschiedenen Feldern zu machen.
Bsp:
IT1: PERSG
IT7: EMPCT TEILK
IT1: 1.1.2020-31.12.2020 PERSG = 1
IT7: 1.1.2020-30.6.2020 EMPCT=100 TEILK = SPACE
IT7: 1.7.2020-31.12.2020 EMPCT=50 TEILK= X
Das würde ja 2 Intervalle ergeben wenn man es in einer internen Tabelle zusammenfügt
1.1.2020-30.6.2020: Persg=1, EMPCT=100,TEILK=Space
1.7.2020-31.12.2020: PERSG=1, EMPCT=50,TEILK=X
PROVIDE PERNR
PERSG
FROM P0001
EMPCT
TEILK
FROM P0007
BETWEEN PNPBEGDA AND PNPENDDA
WHERE P0000-PERNR EQ PERAS-PERNR.
ENDPROVIDE.
Grundsätzlich bietet das Provide-Statement ja diese Möglichkeit. Aber BEGDA-ENDDA nehme ich woher? Das wird ja nicht automatisch generiert, soweit ich das sehe.
Gruss
ich habe da ein kleines Problem. Dachte, das ich sowas schonmal programiert hätte, aber warscheinlich trübt mich da meine Erinnerung (das Coding finde ich nicht mehr, und bin auch nicht mehr in dieser Firma).
Ich suche eine Möglichkeit, möglichst einfach und elegant aus verschiedenen HR-Infotypen (die beinhalten ja immer BEGDA-ENDDA) automatisch Intervalle bei Wechsel von verschiedenen Feldern zu machen.
Bsp:
IT1: PERSG
IT7: EMPCT TEILK
IT1: 1.1.2020-31.12.2020 PERSG = 1
IT7: 1.1.2020-30.6.2020 EMPCT=100 TEILK = SPACE
IT7: 1.7.2020-31.12.2020 EMPCT=50 TEILK= X
Das würde ja 2 Intervalle ergeben wenn man es in einer internen Tabelle zusammenfügt
1.1.2020-30.6.2020: Persg=1, EMPCT=100,TEILK=Space
1.7.2020-31.12.2020: PERSG=1, EMPCT=50,TEILK=X
PROVIDE PERNR
PERSG
FROM P0001
EMPCT
TEILK
FROM P0007
BETWEEN PNPBEGDA AND PNPENDDA
WHERE P0000-PERNR EQ PERAS-PERNR.
ENDPROVIDE.
Grundsätzlich bietet das Provide-Statement ja diese Möglichkeit. Aber BEGDA-ENDDA nehme ich woher? Das wird ja nicht automatisch generiert, soweit ich das sehe.
Gruss
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
PROVIDE/ENDPROVIDE sind schon seit Jahren veraltete Befehle, die ich nicht mehr benutzen würde. Sie setzen auf logischen Datenbanken auf, und das sind schreckliche, quälend langsame Gebilde, deren einziger Vorteil darin besteht, dass man ein paar Programmzeilen weniger braucht (zum Preis von furchtbarer Performance und nur bedingter Transparenz, was da überhaupt passiert).
Heutzutage liest man die Datensätze lieber selber über SELECTs, in Deinem Beispiel also aus den Datenbanktabellen PA0001 und PA0007. Dann bekommst Du Datensatzzeilen mit BEGDA und ENDDA in je einer (von Dir definierten) internen Tabelle pro Infotyp. An dieser Stelle kommst Du dann an das Problem, um das es Dir eigentlich geht: diese Datensätze übereinanderzulegen und festzustellen, in welchen Teilzeiträumen sie alle gleich sind. Genau dafür gibt es einen (undokumentierten) SAP-Standard-Funktionsbaustein namens RHXPROVIDE_PERIODS. Da schmeißt Du einfach alle in Deinen Datensätzen vorkommenden Perioden rein und bekommst sie in überschneidungsfreien Teilzeiträumen ohne Duplikate zurück. Für jeden dieser Teilzeiträume kannst Du dann einfach alle Deine Infotypen lesen, beispielsweise zum BEGDA. Die Daten aller Infotypen werden zum ENDDA identisch sein (sonst hätte der RHXPROVIDE_PERIODS einen weiteren Teilzeitraum angelegt), so dass Du die Daten einfach zum BEGDA lesen und davon ausgehen kannst, dass sie für alle Infotypen und den gesamten Zeitraum so gelten.
Zum RHXPROVIDE_PERIODS habe ich noch anzumerken, dass er eine sehr elegante Idee darstellt, jedoch einen kleinen Programmierfehler enthält, den ich gefunden habe, als ich mir mal den Spaß gemacht habe zu analysieren, wie er funktioniert. Dieser Programmierfehler führt nicht zu falschen Resultaten; Du kannst dem Funktionsbaustein also problemlos vertrauen. Seine Behebung führt allerdings dazu, dass der Baustein 5x schneller läuft, also mit ca. 20% der Rechenzeit auskommt (weil sinnlose Programmschleifen dann verhindert werden). Das war für mich der Anlass, eine kundeneigene Klasse und Methode anzulegen, die korrigiert ist und es mit elegantem OO-Aufruf erlaubt, die bessere Performance zu genießen.
Aber das Eigentliche ist die pfiffige Idee des RHXPROVIDE_PERIODS, denn diese Idee reduziert das von Dir beschriebene Problem der Handhabung überlappender Teilzeiträume zum einfachen Lesen von Daten zu einzelnen Datümern.
Heutzutage liest man die Datensätze lieber selber über SELECTs, in Deinem Beispiel also aus den Datenbanktabellen PA0001 und PA0007. Dann bekommst Du Datensatzzeilen mit BEGDA und ENDDA in je einer (von Dir definierten) internen Tabelle pro Infotyp. An dieser Stelle kommst Du dann an das Problem, um das es Dir eigentlich geht: diese Datensätze übereinanderzulegen und festzustellen, in welchen Teilzeiträumen sie alle gleich sind. Genau dafür gibt es einen (undokumentierten) SAP-Standard-Funktionsbaustein namens RHXPROVIDE_PERIODS. Da schmeißt Du einfach alle in Deinen Datensätzen vorkommenden Perioden rein und bekommst sie in überschneidungsfreien Teilzeiträumen ohne Duplikate zurück. Für jeden dieser Teilzeiträume kannst Du dann einfach alle Deine Infotypen lesen, beispielsweise zum BEGDA. Die Daten aller Infotypen werden zum ENDDA identisch sein (sonst hätte der RHXPROVIDE_PERIODS einen weiteren Teilzeitraum angelegt), so dass Du die Daten einfach zum BEGDA lesen und davon ausgehen kannst, dass sie für alle Infotypen und den gesamten Zeitraum so gelten.
Zum RHXPROVIDE_PERIODS habe ich noch anzumerken, dass er eine sehr elegante Idee darstellt, jedoch einen kleinen Programmierfehler enthält, den ich gefunden habe, als ich mir mal den Spaß gemacht habe zu analysieren, wie er funktioniert. Dieser Programmierfehler führt nicht zu falschen Resultaten; Du kannst dem Funktionsbaustein also problemlos vertrauen. Seine Behebung führt allerdings dazu, dass der Baustein 5x schneller läuft, also mit ca. 20% der Rechenzeit auskommt (weil sinnlose Programmschleifen dann verhindert werden). Das war für mich der Anlass, eine kundeneigene Klasse und Methode anzulegen, die korrigiert ist und es mit elegantem OO-Aufruf erlaubt, die bessere Performance zu genießen.
Aber das Eigentliche ist die pfiffige Idee des RHXPROVIDE_PERIODS, denn diese Idee reduziert das von Dir beschriebene Problem der Handhabung überlappender Teilzeiträume zum einfachen Lesen von Daten zu einzelnen Datümern.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Thomas R.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Ich gebe dir vollkommen recht -- allerdings kenne ich Leute im HR-Bereich die darauf schwören, weil die Berechtigungen direkt verknüpfelt werden können. Ich verstehe allerdings zu wenig davon, um das verifizieren zu können.DeathAndPain hat geschrieben: ↑25.11.2021 16:51Sie setzen auf logischen Datenbanken auf, und das sind schreckliche, quälend langsame Gebilde, deren einziger Vorteil darin besteht, dass man ein paar Programmzeilen weniger braucht (zum Preis von furchtbarer Performance und nur bedingter Transparenz, was da überhaupt passiert).
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
bei der Verwendung der log. Datenbank im HR bekommt man nicht nur die Berechtigungsprüfung sondern auch einen Selektionsbildschirm "geschenkt". In diesem kann u.a. ein Datenauswahlzeitraum selektiert werden, der dann an die Felder
PNPBEGDA/ENDDA durchgereicht wird.
Beste Grüße
Dieter
bei der Verwendung der log. Datenbank im HR bekommt man nicht nur die Berechtigungsprüfung sondern auch einen Selektionsbildschirm "geschenkt". In diesem kann u.a. ein Datenauswahlzeitraum selektiert werden, der dann an die Felder
PNPBEGDA/ENDDA durchgereicht wird.
Beste Grüße
Dieter
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Deine Bekannten haben zwar recht (zumal das HR mit der strukturellen Berechtigung ein zusätzliches, eigenes Berechtigungssystem besitzt, das sich orthogonal zum herkömmlichen verhält); ich finde diese Rechtfertigung aber dennoch idiotisch, denn eine komplette Berechtigungsprüfung für einen Zugriff kostet nicht mehr als den Aufruf eines Funktionsbausteins. Wir reden hier also davon, das Programm mit einer quälend langsamen, viel mehr Systemlast erzeugenden, kaum debugbaren und von der SAP längst als veraltet deklarierten Technik zu programmieren, damit der Programmierer sich den Einbau von ein paar Funktionsbausteinaufrufen (nebst Auswertung des Returncodes, also Verwerfen bzw. Nichtlesen der Daten bei fehlender Berechtigung) spart.ralf.wenzel hat geschrieben: ↑23.01.2022 19:03Ich gebe dir vollkommen recht -- allerdings kenne ich Leute im HR-Bereich die darauf schwören, weil die Berechtigungen direkt verknüpfelt werden können.
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
3543
Views
Views
2
Antw.
Antw.
2735
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 13 Stunden von DeathAndPain 4 / 784
vor 13 Stunden von DeathAndPain 4 / 784
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 13 Stunden von DeathAndPain 4 / 784
vor 13 Stunden von DeathAndPain 4 / 784