Ein Programm sollte je Min. pro Tag in einer Tabelle nachgucken und ...
Dann würde ich einen Änderungszeiger anglegen.
Dieser wird über den Änderungsbeleg erzeugt, man kann definieren bei welchem Änderungsbelegobjekt und bei welchen Feldern der Änderungszeiger geschrieben wird. Wenn nötig kann man noch via BADI zusätzlich Filtern (also mit eigenem Coding). https://blogs.sap.com/2014/03/09/change-pointers-in-r3/
Am Ende hat man einen Eintrag in der BDCP2 (oder BDCP falls noch die alte Fortschreibung aktiv ist) je Änderungsbeleg incl. Flag ob der Zeiger verarbeitet ist.
Somit hat man einen eigenen "Arbeitsvorrat" und baucht "nur" ein ZProgramm um diesen zu verarbeiten.
Und nicht davon abhalten lassen das es eigentlich für die automatische Stammdatenverteilung erfunden wurde...
Wenn wirklich alle fünf Minuten auf geänderte Werte geprüft werden soll, würde ich das nicht via Job lösen. Man kann ein Workflow-Ereignis an die Erzeugung eines Änderungsbeleges "hängen". http://saphelp.ucc.ovgu.de/NW750/EN/4f/ ... ameset.htm. Die Verarbeitung dann entsprechend in einer WF-Hintergrundaufgabe gekapselt und man ist bei einer Inline Verarbeitung (inlc. aller sich damit ergebenen Probleme: Sperren, Parallel Verarbeitung eines Objektes, etc...) Kann man btw. auch mit den Änderungszeiger kombinieren bzw. muss es evtl. auch. Im WF hat man "nur" die ObjektID im Zugriff, nicht aber die Änderungen.
Ist aber eher für erfahrene Entwickler, aber als Einstieg evtl. nicht uninteressant.
Gruß Hendrik
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
ich finde die Anforderung ziemlich krank.
Wäre es nicht sinnvoller, zu prüfen, ob man in den Prozess, der die Änderung auslöst oder verbucht einzugreifen und gleich die 2. Tabelle synchron zu aktualisieren?
Und/oder wenn der Eintrag in der 2. Tabelle initial geschrieben werden soll den Eintrag aus Tabelle 1 lesen und den Wert übernehmen, falls dann schon vorhanden.
Dass die selbe Information in 2 Tabellen gehalten werden soll, ist eigentlich auch schon ein Designfehler.
Das Problem ist die 2 Tabellen synchron zu halten. Wenn es alternative, bessere Methoden gibt, als so ein permanent laufender Report, dann sollte man eine Lösung skizieren und dem Auftraggeber präsentieren.
ich finde die Anforderung ziemlich krank.
Wäre es nicht sinnvoller, zu prüfen, ob man in den Prozess, der die Änderung auslöst oder verbucht einzugreifen und gleich die 2. Tabelle synchron zu aktualisieren?
Und/oder wenn der Eintrag in der 2. Tabelle initial geschrieben werden soll den Eintrag aus Tabelle 1 lesen und den Wert übernehmen, falls dann schon vorhanden.
Dass die selbe Information in 2 Tabellen gehalten werden soll, ist eigentlich auch schon ein Designfehler.
Das Problem ist die 2 Tabellen synchron zu halten. Wenn es alternative, bessere Methoden gibt, als so ein permanent laufender Report, dann sollte man eine Lösung skizieren und dem Auftraggeber präsentieren.
Also erstmal gibt es für deine Frage x mögliche Lösungen. Manche hier sind sehr kompliziert.
1. Frage : Was ist das für ein Feld ? Etliche SAP Programme lösen beim Ändern von Daten eigene Funktionsbausteine aus etc, wo man sich direkt in den dort in der Regel vorhandenen User-Exit hängen kann. Eine andere Technik die SAP verwendet sind definierte Zeitpunkte.
2. Wie der Kommentator davor schrieb : In der Regel ist die bessere Variante sich im erzeugenden Programm nach einem User-Exit, BAPI etc umzusehen. Grundsätzlich ist alles was zusätzlich gemacht wird und nachträglich als "Murks" anzusehen. Man sollte sich immer an das Verursacher-Prinzip halten.
2. Wenn CDHDR und CDPOS schon geschrieben werden ist die Lösung minimalistisch einfach : Das Programm läuft im Job. Es prüft einfach : Wann bin ich zuletzt gelaufen ? ( kein Admin reorganisiert die Joblogs die jünger sind als 30 Tage ) Damit brauchst du nicht mal eine eigene Z-Tabelle. Dann liest man CDHDR und CDPOS zu dem Feld . Ist der Eintrag jünger als der letzte Laufzeitpunkt des Programmes gab es eine Änderung.
3. Ich würde allgemein diese Anforderung als sehr kritisch ansehen. Da scheint einiges an Wissen zu fehlen.
1. Frage : Was ist das für ein Feld ? Etliche SAP Programme lösen beim Ändern von Daten eigene Funktionsbausteine aus etc, wo man sich direkt in den dort in der Regel vorhandenen User-Exit hängen kann. Eine andere Technik die SAP verwendet sind definierte Zeitpunkte.
2. Wie der Kommentator davor schrieb : In der Regel ist die bessere Variante sich im erzeugenden Programm nach einem User-Exit, BAPI etc umzusehen. Grundsätzlich ist alles was zusätzlich gemacht wird und nachträglich als "Murks" anzusehen. Man sollte sich immer an das Verursacher-Prinzip halten.
2. Wenn CDHDR und CDPOS schon geschrieben werden ist die Lösung minimalistisch einfach : Das Programm läuft im Job. Es prüft einfach : Wann bin ich zuletzt gelaufen ? ( kein Admin reorganisiert die Joblogs die jünger sind als 30 Tage ) Damit brauchst du nicht mal eine eigene Z-Tabelle. Dann liest man CDHDR und CDPOS zu dem Feld . Ist der Eintrag jünger als der letzte Laufzeitpunkt des Programmes gab es eine Änderung.
3. Ich würde allgemein diese Anforderung als sehr kritisch ansehen. Da scheint einiges an Wissen zu fehlen.
"Code lügt nicht ^^"
A6272 hat geschrieben: ↑22.05.2023 11:47Hallo,
ich finde die Anforderung ziemlich krank.
Wäre es nicht sinnvoller, zu prüfen, ob man in den Prozess, der die Änderung auslöst oder verbucht einzugreifen und gleich die 2. Tabelle synchron zu aktualisieren?
Und/oder wenn der Eintrag in der 2. Tabelle initial geschrieben werden soll den Eintrag aus Tabelle 1 lesen und den Wert übernehmen, falls dann schon vorhanden.
Dass die selbe Information in 2 Tabellen gehalten werden soll, ist eigentlich auch schon ein Designfehler.
Das Problem ist die 2 Tabellen synchron zu halten. Wenn es alternative, bessere Methoden gibt, als so ein permanent laufender Report, dann sollte man eine Lösung skizieren und dem Auftraggeber präsentieren.
Da findest du in SAP aber eine Menge "Designfehler". Pauschal kann man das allerdings so nicht sagen. An manchen Stellen ist das durchaus notwendig, wobei man sich da auf die absolut notwendigen Daten beschränkt.
"Code lügt nicht ^^"
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Nein, es bleibt ja nur ein einziger Wert. Bei jedem Programmlauf änderst Du den Tabelleneintrag auf das aktuelle Datum. Die Zeiten der früheren Abfragen brauchst Du ja nicht, sondern nur die jeweils letzte.HH_ABAP hat geschrieben: ↑21.05.2023 14:51Ja, soll ich eine DB-Tabelle (Z-Tabelle) anlegen und die letzte überprüfung in der Tabelle speichern (Datum und Zeit), oder?DeathAndPain hat geschrieben: ↑20.05.2023 20:15Du musst Dir doch nur irgendwie merken, wann Du das letzte Mal auf Änderungen geprüft hast (Datum und Uhrzeit). Beim nächsten Mal selektierst Du alle Tabelleneinträge, deren Änderungsdatum und -zeit danach liegen. Das sind die Einträge, die sich geändert haben.
Dann nach 14 Tage sollten die Einträge aus der Tabelle gelöscht werden, damit die Tabelle nicht schnell voll wird, oder?
Theoretisch könntest Du dafür also eine DB-Tabelle mit nur einer einzigen Zeile anlegen. Eine DB-Tabelle, nur um einen einzigen Wert zu merken, ist natürlich ein ganz mieses Design. Entweder Du legst Dir eine eigene allgemeine Customizingtabelle an, die Du dann auch noch für andere Werte verwenden kannst (zwei Spalten: key und value. Dann kannst Du z.B. als key "LETZTER_CHECK" und als Value dann Datum und Uhrzeit verwenden), oder Du machst es wie von wreichelt empfohlen über einen im ABAP Memory hinterlegten Wert.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
HH_ABAP
Hallo DeathAndPain,
vielen Dank für deine Hilfe!
Ich finde, die Idee mit Customizingtabelle gut.
Also, ich muss mir merken, wann ich das letzte Mal auf Änderungen geprüft habe.
Bitte siehe unten den Screenshot.
Verstehe ich richtig? Ich brauche das Datum und Zeit aus dem Jobübersicht? Wenn ja, wie kann ich an diese Daten zugreifen?
Vielen Dank im Voraus!
VG
vielen Dank für deine Hilfe!
Ich finde, die Idee mit Customizingtabelle gut.
Also, ich muss mir merken, wann ich das letzte Mal auf Änderungen geprüft habe.
Bitte siehe unten den Screenshot.
Verstehe ich richtig? Ich brauche das Datum und Zeit aus dem Jobübersicht? Wenn ja, wie kann ich an diese Daten zugreifen?
Vielen Dank im Voraus!
VG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Mit BP_JOB_SELECT kannst du einfach die letzte Ausführungszeit ermitteln.
Reicht das denn aus?
Was wenn der Job zwar gelaufen, das Update aber nicht ausgeführt wurde (Abbruch, SperrEintrag, etc...).
Man bräuchte doch den letzten "erfolgreichen Job"...kann aber auch über den genannten FuBa ermittelt werden. Wobei das dann wiederum eine richtiges Fehlerhandling (=Job wird abgebrochen) voraussetzt,
Gruß Hendrik
Hallo Hendrik,
vielen Dank für die Antwort.
Ich habe die Tabelle TBTCO (Job-Zustandsübersichtstabelle) gefunden.
Ist es nicht einfacher die Daten aus der Tabelle nehmen.
vielen Dank für die Antwort.
Ich habe die Tabelle TBTCO (Job-Zustandsübersichtstabelle) gefunden.
Ist es nicht einfacher die Daten aus der Tabelle nehmen.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Ummm... wir reden hier davon, dass Dein Programm feststellen soll, wann es selber (!) zum letzten Mal gelaufen ist. Da brauchst Du keinen Job auslesen, sondern da schreibt Dein Programm einfach vor seinem Ende SY-DATUM und SY-UZEIT in Deine Customizingtabelle, und dann ist das gut. Wenn der Job das nächste Mal läuft, dann liest Dein Programm diese Werte wieder aus und weiß dadurch, wann es das letzte Mal gelaufen ist.
Hat nebenbei den Vorteil, dass das auch dann funktioniert, wenn es zwischendurch mal von Hand im Vordergrund gestartet wird (z.B. für einen Test).
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
HH_ABAP
Kommt drauf an was du am Ende genau machen willst.
Via BDCP2 Tabelle bekommt man einen "Arbeitsvorrat" an Änderungen, die man per Programm auswerten und bearbeiten kann.
Du fokusierst dich darauf wann der Job das letzte mal gelaufen ist um dann die Änderungen in dieser und der jetzt Zeit zu ermitteln.
Ich finde den Arbeitsvorrat "besser" denn der funktioniert auch ohne Job!
Denn wie arbeitet dein Programm wenn es nicht im Job ausgeführt wird?
Der erste Online-Aufruf past ja noch, aber der zweite kann den ersten nicht mehr ermitteln.
Was genau du aber machen musst im Programm hast du bisher nicht "erklärt", außer:
Also: Wenn TAB1-FELD1 sich ändert, fülle FELD2 in TAB2!
Mit Änderunszeiger:
Wenn TAB1-FELD1 sich ändert, erzeuge Änderungszeiger (SAP-Standard)...
ZProgramm: Lies unverarbeitete Änderungszeiger, fülle FELD2 in TAB2, setzte Erledigungs-KNZ im Änderungszeiger.
Funktioniert sauber im Job und auch Online, egal ob alle 5 Minuten oder alle 5 Tage...
Mit Job:
Ermittel wann das Programm das letzte Programm lief, ermittel alle Änderungsbelege zu TAB1-FELD1 seit diesem Zeitpunkt bis jetzt, ändere FELD2 in TAB2.
Geht beides, Enno hatte dir in der ersten Antwort aber schon erklärt, dass es X-Lösungen gibt. Welche dann am besten passt, hängt von der genauen AUfgabenstellung ab.
Gruß Hendrik
Hallo Hendrik,
vielen Dank für die ausführliche Antwort.
Zur Info.: Mit Job möchte ich die Aufgabe lösen.
Ich habe Fragen bzgl. Customizingtabelle. Bitte siehe den Screenhot.
1. Im Feld Auslieferungsklasse welche soll ich auswählen?
2. Bzgl. Customizingtabelle worauf soll ich achten? Ist es wie Anwendungstablle?
3. Du hast mir geschrieben:
Wie soll ich "eine richtiges Fehlerbehandlung" machen?
Vielen Dank im Voraus!
VG
vielen Dank für die ausführliche Antwort.
Zur Info.: Mit Job möchte ich die Aufgabe lösen.
Ich habe Fragen bzgl. Customizingtabelle. Bitte siehe den Screenhot.
1. Im Feld Auslieferungsklasse welche soll ich auswählen?
2. Bzgl. Customizingtabelle worauf soll ich achten? Ist es wie Anwendungstablle?
3. Du hast mir geschrieben:
Was soll ich machen, wenn Job abgebrochen wird?...Wobei das dann wiederum eine richtiges Fehlerhandling (=Job wird abgebrochen) voraussetzt,
Wie soll ich "eine richtiges Fehlerbehandlung" machen?
Vielen Dank im Voraus!
VG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Welche Aufgabe?
Sorry aber du gibst zu wenig Infos, was aber auch zeigt, dass du die Aufgabe/Lösung noch nicht zu Ende gedacht hast.
Customizing-Tabellen sind transportpflichtig, werden also im Entwicklungssystem gepflegt und die Einträge dann bis ins Produktiv-System transportiert. Meist ist es Typ C, denn SAP ist außen vor.
Was soll jetzt deine Tabelle genau tun?
Welche Einträge sollen transportiert werden...eigentlich willst du doch protokollieren wann das Programm letzt malig ausgeführt wurde.
Egal ob per Job oder Online?
Oder kommt der letzte Ausführungszeitpunkt doch aus den Job Logs?
Wenn ich Glaskugeln soll:
Du willst ein ZProgramm erstellen...das folgendes kann:
- letzten Ausführungspunkt ermitteln
- alle Änderung von TAB1-FELD1 seit dem letzten Ausführungszeitpunkt ermitteln
- TAB2-FELD2 updaten
- aktuellen Ausführungszeitpunkt fortschreiben
Du brauchst eine Tabellle in dem du den letzten Ausführungszeitpunkt protokollierst.
Das sind aber Bewegungsdaten, also brauchst du eine Anwendungstabelle!
Auch wenn es dich aktuell wahrscheinlich noch nicht kümmert:
- Was machst du bei Abbrüchen (Dump, Fehler beim Schreiben von TAB2-FELD2)
- Wie verhinderst du parallele Ausführungen des Programms (z.B. weil die Ausführung per Job verzögert wurde)
- Wie bestimmst du den Ausführungszeipunkt, der protokolliert wird? Wenn also nachdem lesen der Änderungen, noch weitere Änderungen kommen...
- ...
Gruß Hendrik
Kann es vielleicht auch "die Aufgabe" sein zu erkennen, dass die Anforderung krank ist und man nach alternativen Lösungsansätzen zu suchen hat?
Ist eine Analyse erfolgt, woher das Problem der Asynchronität kommt?
Ist eine Analyse erfolgt, ob man das Problem nicht schon an der Quelle der Ursache beseitigen kann?
Warum so kompliziert mit Tabelle und letzten Lauf weg schreiben? Der Report benötigt eigentlich nur ein Eingabefeld, für Datum, Uhrzeit und alles was neuer ist wird synchronisiert. Datum, Uhrzeit dynamisch über die Jobvariante füllen und noch vom Datum 1 Tag abziehen, falls die Ab > Jetzt ist. Jobperiode und Jobvariante aufeinander abstimmen und gut ist es. Dann kannst Du auch beliebige Zeiträume im Fehlerfalle nochmals nachverarbeiten.
Der Selektionszeitraum muss größer als die Jobperiode sein. Und wenn ein paar Einträge doppelt Synchronisiert werden, dann ist es halt so.
Wenn man das mit der Tabelle korrekt macht, dann musst Du dir den Zeitpunkt merken, der vor deiner Datenselektion war und darfst diesen erst am Ende des Reports schreiben, aber nur wenn alle Datensätze erfolgreich upgedatet wurden. Wenn auch nur ein Datensatz einen Fehler enthält, dann bleibt der Zeiger stehen und im Zweifelsfall bis auf ewig und der Report wird immer langsamer. d.h. irgendwer muss das auch monitoren.
Hallo,
ich habe ein kleines Programm dafür erstellt:
tables: vbkd.
TABLES INDX.
data: sup like vbkd-zterm.
DATA: BEGIN OF INDXKEY,
UNAME LIKE SY-UNAME.
data: END OF indxkey.
*
INDXKEY-UNAME = SY-UNAME.
IMPORT SUP FROM DATABASE INDX(50) ID INDXKEY.
if sy-subrc ne 0.
"erster Eintrag
else.
write: / 'alter eintrag', sup.
endif.
select single * FROM vbkd
WHERE vbeln = '0001115203'
and posnr = '000000'.
if vbkd-zterm ne sup.
write: / 'alter eintrag', sup.
write: / 'neu ', vbkd-zterm.
sup = vbkd-zterm.
EXPORT sup TO DATABASE INDX(50) ID INDXKEY.
endif.
das Programm listet dann den 'alten' und den neuen Eintrag auf und speichert den neuen Wert.
ok ist nicht schön und kann besser gemacht werden.
Gruß Wolfgang
ich habe ein kleines Programm dafür erstellt:
tables: vbkd.
TABLES INDX.
data: sup like vbkd-zterm.
DATA: BEGIN OF INDXKEY,
UNAME LIKE SY-UNAME.
data: END OF indxkey.
*
INDXKEY-UNAME = SY-UNAME.
IMPORT SUP FROM DATABASE INDX(50) ID INDXKEY.
if sy-subrc ne 0.
"erster Eintrag
else.
write: / 'alter eintrag', sup.
endif.
select single * FROM vbkd
WHERE vbeln = '0001115203'
and posnr = '000000'.
if vbkd-zterm ne sup.
write: / 'alter eintrag', sup.
write: / 'neu ', vbkd-zterm.
sup = vbkd-zterm.
EXPORT sup TO DATABASE INDX(50) ID INDXKEY.
endif.
das Programm listet dann den 'alten' und den neuen Eintrag auf und speichert den neuen Wert.
ok ist nicht schön und kann besser gemacht werden.
Gruß Wolfgang
Vergleichbare Themen
1
Antw.
Antw.
1863
Views
Views
0
Antw.
Antw.
1155
Views
Views
Programm RLLNACH1 nach Z-Tabelle selektieren lassen
von max1 » 13.02.2007 14:58 • Verfasst in ABAP® für Anfänger
von max1 » 13.02.2007 14:58 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
1137
Views
Views
Mehrere Werte aus Tabelle (LTAP) auslesen und an Programm(Feld) übergeben
von f.weissenberger » 21.12.2020 14:19 • Verfasst in ABAP® für Anfänger
von f.weissenberger » 21.12.2020 14:19 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
2700
Views
Views
LSMW Programm in ABAP Programm überführen
von mherke » 07.02.2007 15:02 • Verfasst in ABAP® für Anfänger
von mherke » 07.02.2007 15:02 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
3315
Views
Views
Programm aus anderem Programm heraus aufrufen
von Namp » 27.03.2006 13:34 • Verfasst in SAP - Allgemeines
von Namp » 27.03.2006 13:34 • Verfasst in SAP - Allgemeines
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 455
vor 23 Stunden von a-dead-trousers 5 / 455
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 455
vor 23 Stunden von a-dead-trousers 5 / 455