Prozesse auf mehrere Server verteilen
Beitrag
von ABAP_BEGINNER (ForumUser / 12 / 9 /
0
)
»
Hallo,
ich hoffe Ihr könnt mir bei meinem Problem helfen.
Man kann ja (soweit ich weiß), die Performance von einem Programm beträchtlich beschleunigen wenn man die "Prozesse" auf verschiedenen Servern verteil.
Oder so etwas in der Art. Ich bin mir da selbst nicht ganz sicher, hab mal was in die Richtung gehört.
Es geht darum, das ja manche Programme mehrere Tage laufen, wenn sie ausgeführt werden(Lässt man dann meistens am Wochenende laufen).
Wenn man z.B. mit einer Tabelle arbeitet, wo Mio. von Daten drin sind.
Wenn man jetzt z.B. ein Select auf die Tabelle macht(und nach einem Datum filtert), könnte man doch theoretisch mehrere Selects machen, die auf unterschiedliche Server laufen und unterschiedliche where Bedingungen haben, sodass sozusgaen die Where-bedingng in kleinere Teile herunter gebrochen wird und gleichzeitig auf unterschiedlichen servern ausgeführt wird. (das Feld, in der where Bedingung hätte dann natürlich ein Index).
Ich hoffe ich konnte es halb Wegs erklären
.
Meine Frage wäre jetzt, wie so etwas funktioniert, dass man die "Prozesse" auf unterschiedlichen Servern verteilt.?
Für Hilfe, bin ich sehr Dankbar.
Grüße, der ABAP_BEGINNER
ich hoffe Ihr könnt mir bei meinem Problem helfen.
Man kann ja (soweit ich weiß), die Performance von einem Programm beträchtlich beschleunigen wenn man die "Prozesse" auf verschiedenen Servern verteil.
Oder so etwas in der Art. Ich bin mir da selbst nicht ganz sicher, hab mal was in die Richtung gehört.
Es geht darum, das ja manche Programme mehrere Tage laufen, wenn sie ausgeführt werden(Lässt man dann meistens am Wochenende laufen).
Wenn man z.B. mit einer Tabelle arbeitet, wo Mio. von Daten drin sind.
Wenn man jetzt z.B. ein Select auf die Tabelle macht(und nach einem Datum filtert), könnte man doch theoretisch mehrere Selects machen, die auf unterschiedliche Server laufen und unterschiedliche where Bedingungen haben, sodass sozusgaen die Where-bedingng in kleinere Teile herunter gebrochen wird und gleichzeitig auf unterschiedlichen servern ausgeführt wird. (das Feld, in der where Bedingung hätte dann natürlich ein Index).
Ich hoffe ich konnte es halb Wegs erklären
.Meine Frage wäre jetzt, wie so etwas funktioniert, dass man die "Prozesse" auf unterschiedlichen Servern verteilt.?
Für Hilfe, bin ich sehr Dankbar.
Grüße, der ABAP_BEGINNER
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von michael.sbs (ForumUser / 6 / 0 /
1
)
»
Hallo Beginner,
Mein Kenntnisstand ist, dass die User-Anmeldungen auf mehrere Applikationsserver verteilt werden können. Nicht aber einzelne Programme oder Programm-Routinen.
Lass mich aber gerne belehren.
Gruß Michael
Mein Kenntnisstand ist, dass die User-Anmeldungen auf mehrere Applikationsserver verteilt werden können. Nicht aber einzelne Programme oder Programm-Routinen.
Lass mich aber gerne belehren.
Gruß Michael
Folgende Benutzer bedankten sich beim Autor michael.sbs für den Beitrag:
ABAP_BEGINNER
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hallo ABAP_BEGINNER,
eigentlich brauchst du dich gar nicht darum zu kümmern auf welchem Server die kleineren Teile ausgeführt werden. Wenn du deinen großen Job in mehrere kleine herunterbrichst und diese alle ganz normal einplanst, sollte das SAP-System die schon selbständig auf die verschiedenen Anwendungsserver verteilen.
Falls du aber ganz explizit selber steuern willst (warum auch immer) , auf welchem Server welche (Hintergrund)-Task laufen soll, so schau doch mal in den FuBau JOB_CLOSE und dort die Importparameter TARGETSERVER oder TARGETGROUP an.
eigentlich brauchst du dich gar nicht darum zu kümmern auf welchem Server die kleineren Teile ausgeführt werden. Wenn du deinen großen Job in mehrere kleine herunterbrichst und diese alle ganz normal einplanst, sollte das SAP-System die schon selbständig auf die verschiedenen Anwendungsserver verteilen.
Falls du aber ganz explizit selber steuern willst (warum auch immer) , auf welchem Server welche (Hintergrund)-Task laufen soll, so schau doch mal in den FuBau JOB_CLOSE und dort die Importparameter TARGETSERVER oder TARGETGROUP an.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ABAP_BEGINNER
HI ABAP_BEGINNER,
eine Möglichkeit ist die Verteilung des Programms auf Jobs wie black_adept angesprochen hat.
Solltest du nicht mit Jobs arbeiten wollen/können, dann schau dir doch die Parallelisierung bei SAP ab:
In den Baustein packst du dann deine Logik und übergibst ihm immer schön deine kleinen Pakete, sagen wir in 5 Tasks (die musst du selbst zählen). Im RECEIVING Unterprogramm kannst du dann alles in eine interne Tabelle sammeln.
Allerdings hab ich selbst noch kein Programm gesehen, was mehrere Tage läuft (maximal DB-Reorgs oder sowas). Und wenn doch, dann liegts mit ziemlicher Sicherheit nicht am DB-Select wenn es halbwegs performant programmiert ist, sondern an inperformanten SELECT ... ENDSELECTs oder LOOPs.
Grüße
CASMAN
eine Möglichkeit ist die Verteilung des Programms auf Jobs wie black_adept angesprochen hat.
Solltest du nicht mit Jobs arbeiten wollen/können, dann schau dir doch die Parallelisierung bei SAP ab:
Code: Alles auswählen.
CALL FUNCTION 'FUNKTIONSBAUSTEIN'
STARTING NEW TASK g_wa_taskname
DESTINATION l_dest ( bzw. IN GROUP l_wa_groupname)
PERFORMING mt_receive_data ON END OF TASK.Allerdings hab ich selbst noch kein Programm gesehen, was mehrere Tage läuft (maximal DB-Reorgs oder sowas). Und wenn doch, dann liegts mit ziemlicher Sicherheit nicht am DB-Select wenn es halbwegs performant programmiert ist, sondern an inperformanten SELECT ... ENDSELECTs oder LOOPs.
Grüße
CASMAN
Folgende Benutzer bedankten sich beim Autor casman für den Beitrag:
ABAP_BEGINNER
Beitrag
von ABAP_BEGINNER (ForumUser / 12 / 9 /
0
)
»
[quote="casman"]
Allerdings hab ich selbst noch kein Programm gesehen, was mehrere Tage läuft (maximal DB-Reorgs oder sowas).
Die Wahrheit ist, genau darum geht es eigentlich auch.
Das ganze soll dann so aussehen, dass wen der User ein Datum eingibt, das Programm die Selektion automatisch aufteilt und auf verschiedenen Servern ausführt.
Und vielen Dank für die schnellen Antworten, super Forum echt.
Die doku zum Fuba hab ich mir schon angeschaut, ich werd das ganze mal ausprobieren und melde mich dann nächste Woche wieder und berichte mal wie ich voran komme .
Grüße, der ABAP_BEGINNER
Allerdings hab ich selbst noch kein Programm gesehen, was mehrere Tage läuft (maximal DB-Reorgs oder sowas).
Die Wahrheit ist, genau darum geht es eigentlich auch
.Das ganze soll dann so aussehen, dass wen der User ein Datum eingibt, das Programm die Selektion automatisch aufteilt und auf verschiedenen Servern ausführt.
Und vielen Dank für die schnellen Antworten, super Forum echt
.Die doku zum Fuba hab ich mir schon angeschaut, ich werd das ganze mal ausprobieren und melde mich dann nächste Woche wieder und berichte mal wie ich voran komme
.Grüße, der ABAP_BEGINNER
Hallo ABAP_BEGINNER,
schau Dir mal Transaktion WLCPAR bzw. Report RWLC_PROCESS_IN_PARALLEL bzw. die Programmdoku dazu an.
Damit kann man, wenn auch auf recht komplizierte Weise (Customizing/Entwicklung), auch 'normale' Reports parallelisieren.
MfG Jürgen
schau Dir mal Transaktion WLCPAR bzw. Report RWLC_PROCESS_IN_PARALLEL bzw. die Programmdoku dazu an.
Damit kann man, wenn auch auf recht komplizierte Weise (Customizing/Entwicklung), auch 'normale' Reports parallelisieren.
MfG Jürgen
Folgende Benutzer bedankten sich beim Autor JDO für den Beitrag:
ABAP_BEGINNER
Beitrag
von ABAP_BEGINNER (ForumUser / 12 / 9 /
0
)
»
Hallo,
die Transaktion WLCPAR bzw. Report RWLC_PROCESS_IN_PARALLEL war mir dann doch ein wenig zu kompleziert.
Ich habe aber auch den Tipp bekommen, dass es mit den Fubas: JOB_OPEN/JOB_SUBMIT/JOB_CLOSE gehen soll, wie hier schon erwähnt wurde .
Habs aber leider nicht hinbekommen.
Weiterhin wurde mir gesagt, dass man so vorgehen könnte:
Es wird ja nach einem Datum selektiert. Man könnte deshalb 12 Varianten anlegen(Für jeden Monat einen) und diese auf die Jobs verteilen(Oder so in der Art).
Relevant wäre hierfür aber irgent ein weiterer Funktionsbaustein für die Varianten.
Weiß jemand wie der heißt?
Also würden 4 Funktionsbausteine dann eine Rolle spielen.
Leider weiß ich aber auch nicht wie ich die Variante in einem Select verarbeiten kann, wahrscheinlich deshalb der Fuba.
Die Variante wurde im Selektionsbild angelegt.
Wichtig: Muss doch nicht auf verschiedene Server verteilt werden, da der Dispatcher die Jobs automatisch dann auf verschiedene Workprozesse verteil, so wie black_adept schon erwähnt hat.
Weis jemand etwas darüber?
Gruß, der ABAP_BEGINNER
die Transaktion WLCPAR bzw. Report RWLC_PROCESS_IN_PARALLEL war mir dann doch ein wenig zu kompleziert.
Ich habe aber auch den Tipp bekommen, dass es mit den Fubas: JOB_OPEN/JOB_SUBMIT/JOB_CLOSE gehen soll, wie hier schon erwähnt wurde
. Habs aber leider nicht hinbekommen.
Weiterhin wurde mir gesagt, dass man so vorgehen könnte:
Es wird ja nach einem Datum selektiert. Man könnte deshalb 12 Varianten anlegen(Für jeden Monat einen) und diese auf die Jobs verteilen(Oder so in der Art).
Relevant wäre hierfür aber irgent ein weiterer Funktionsbaustein für die Varianten.
Weiß jemand wie der heißt?
Also würden 4 Funktionsbausteine dann eine Rolle spielen.
Leider weiß ich aber auch nicht wie ich die Variante in einem Select verarbeiten kann, wahrscheinlich deshalb der Fuba.
Die Variante wurde im Selektionsbild angelegt.
Wichtig: Muss doch nicht auf verschiedene Server verteilt werden, da der Dispatcher die Jobs automatisch dann auf verschiedene Workprozesse verteil, so wie black_adept schon erwähnt hat.
Weis jemand etwas darüber?
Gruß, der ABAP_BEGINNER
Hola ABAP_BEGINNER,
was soll denn dein Programm machen? Du selektierst nach Datum und machst dann irgendwas? Musst du dann die Ergebnisse wieder zusammen prozessieren, oder kann jeder Job für sich alleine werkeln?
Wenn jeder Job allein weitermachen kann, dann lege Dir 12 Varianten an, schreibe einen Report, der die Tabelle VARID zu deinem Report ausliest und starte in einem LOOP AT für jede der relevanten Varianten einen Job per JOB_OPEN, JOB_SUBMIT und JOB_CLOSE. Den Varianten-Namen gibst du halt über den Parameter VARIANT im JOB_SUBMIT mit.
Wenn nach der Selektion nur zusammen weiter prozessiert werden kann, dann kannst du die JOB-Lösung vergessen.
was soll denn dein Programm machen? Du selektierst nach Datum und machst dann irgendwas? Musst du dann die Ergebnisse wieder zusammen prozessieren, oder kann jeder Job für sich alleine werkeln?
Wenn jeder Job allein weitermachen kann, dann lege Dir 12 Varianten an, schreibe einen Report, der die Tabelle VARID zu deinem Report ausliest und starte in einem LOOP AT für jede der relevanten Varianten einen Job per JOB_OPEN, JOB_SUBMIT und JOB_CLOSE. Den Varianten-Namen gibst du halt über den Parameter VARIANT im JOB_SUBMIT mit.
Wenn nach der Selektion nur zusammen weiter prozessiert werden kann, dann kannst du die JOB-Lösung vergessen.
Folgende Benutzer bedankten sich beim Autor casman für den Beitrag:
ABAP_BEGINNER
reden wir denn eigentlich über eine GROßE Tabelle, die deswegen so langsam abgearbeitet wird, weil sie eben so GROß ist, oder dauert die Berechnung von einzelnen Einträgen SOOOO lange?
Im ersteren Fall reicht evtl. schon ein Lesen und Verarbeiten in kleineren Paketen: http://tricktresor.de/content/index.php ... 30&aID=524
Im ersteren Fall reicht evtl. schon ein Lesen und Verarbeiten in kleineren Paketen: http://tricktresor.de/content/index.php ... 30&aID=524
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ABAP_BEGINNER
Beitrag
von ABAP_BEGINNER (ForumUser / 12 / 9 /
0
)
»
Hi@all,
die Tabelle hat um die Mio. einträge. Es handelt sich hierbei um ein Recovery-Pogramm. Es wir also ein leeres Feld gefüllt.
Ich habe jetzt mal ein wenig weiter rumprobiert.
Aber wie bekomme ich die Variante ins SELECT ?.
Im Einstiegsbield sieht man noch den Parameter select-options. Man soll dann aber einfach auf Programm -> Im Hintergrund ausführen gehen. Und mit der Variante arbeiten, die im Fuba(JOB_SUBMIT) angegeben ist.
Aber irgentwie arbeitet er nicht mit der Variante, sondern selektiert alles.
Info: Ich probier das ganze erstmal mit einer Beispiel-Tabell. Später wenn ich dann mal die Basics verstanden habe, würde ich das dann gerne in meinem richtigem Programm einabuen.
Würde es helfen, wenn ich mal mein Quellcode zeige?
Viele Grüße, der ABAP_BEGINNER
Achso und jeder Job kann eigentlich für sich alleine werkeln.
die Tabelle hat um die Mio. einträge. Es handelt sich hierbei um ein Recovery-Pogramm. Es wir also ein leeres Feld gefüllt.
Ich habe jetzt mal ein wenig weiter rumprobiert.
Aber wie bekomme ich die Variante ins SELECT ?.
Im Einstiegsbield sieht man noch den Parameter select-options. Man soll dann aber einfach auf Programm -> Im Hintergrund ausführen gehen. Und mit der Variante arbeiten, die im Fuba(JOB_SUBMIT) angegeben ist.
Aber irgentwie arbeitet er nicht mit der Variante, sondern selektiert alles.
Info: Ich probier das ganze erstmal mit einer Beispiel-Tabell. Später wenn ich dann mal die Basics verstanden habe, würde ich das dann gerne in meinem richtigem Programm einabuen.
Würde es helfen, wenn ich mal mein Quellcode zeige?
Viele Grüße, der ABAP_BEGINNER
Achso und jeder Job kann eigentlich für sich alleine werkeln.
Quellcode würde auf jeden Fall mal helfen.
Die "Variante" kriegst du gar nicht ins Select. Du hast eine Select-Option, die füllst du und speicherst die Variante. Wenn du den Report ausführst, macht dein Report irgendwas in der Art:
SELECT * FROM tabelle INTO itab WHERE feld IN select-option.
Damit hast dus dann doch.
Die "Variante" kriegst du gar nicht ins Select. Du hast eine Select-Option, die füllst du und speicherst die Variante. Wenn du den Report ausführst, macht dein Report irgendwas in der Art:
SELECT * FROM tabelle INTO itab WHERE feld IN select-option.
Damit hast dus dann doch.
Folgende Benutzer bedankten sich beim Autor casman für den Beitrag:
ABAP_BEGINNER
Beitrag
von ABAP_BEGINNER (ForumUser / 12 / 9 /
0
)
»
Hallo,
ich hab jetzt erstmal ein tesprogramm erstellt und versuche gerade es einfach mal zu schaffen mit einer variante zu arbetien.
Programm gibt jetzt eigentlich keinen Sinn, aber wenn ich des mal verstanden hab, glaube ich könnte ich mein Programm dann richtig umschreiben.
Des Programm soll so aussehen, dass ich eine Selections-krieterium eingebe und dann im Programm eine Variante erstellt wird, die das eingegebene Datum(Selections-kriterum) - 20 Tage rechnet.
Und das Programm soll dann mit der Variante arbeiten.
Würde im Ergebnis, auch Einräge auftauchen, die 20 Tage vorher erstellt wurden , so weiß ich ja dann dass mein Programm mit der Variante gearbeitet hat, das tuts aber nicht.
Hier mein Quellcode (Is bestimm ziemlich viel falsch,soory bin noch ein Beginner
):
Viele Grüße, und bitte helft mir 
ich hab jetzt erstmal ein tesprogramm erstellt und versuche gerade es einfach mal zu schaffen mit einer variante zu arbetien.
Programm gibt jetzt eigentlich keinen Sinn, aber wenn ich des mal verstanden hab, glaube ich könnte ich mein Programm dann richtig umschreiben.
Des Programm soll so aussehen, dass ich eine Selections-krieterium eingebe und dann im Programm eine Variante erstellt wird, die das eingegebene Datum(Selections-kriterum) - 20 Tage rechnet.
Und das Programm soll dann mit der Variante arbeiten.
Würde im Ergebnis, auch Einräge auftauchen, die 20 Tage vorher erstellt wurden , so weiß ich ja dann dass mein Programm mit der Variante gearbeitet hat, das tuts aber nicht.
Hier mein Quellcode (Is bestimm ziemlich viel falsch,soory bin noch ein Beginner
):
Code: Alles auswählen.
TABLES: zdfkkpao .
DATA: numb TYPE tbtcjob-jobcount,
jobname TYPE tbtcjob-jobname VALUE 'TEST',
repid TYPE sy-repid,
variant TYPE varit-variant VALUE 'TEST2',
test TYPE zdfkkpao-vmdat.
DATA: ld_varit TYPE varit,
ld_varid TYPE varid,
l_varit TYPE STANDARD TABLE OF varit,
ld_rsparams type rsparams,
l_rsparams_tt TYPE rsparams_tt.
DATA wa TYPE zdfkkpao.
SELECT-OPTIONS s_datum FOR zdfkkpao-vmdat.
repid = sy-repid.
test = s_datum-low - 20.
ld_varit-mandt = sy-mandt.
ld_varit-langu = sy-langu.
ld_varit-report = repid .
ld_varit-variant = variant.
ld_varit-vtext = 'T51'.
append ld_varit to l_varit.
clear: ld_rsparams.
ld_rsparams-selname = 'S_DATUM'.
ld_rsparams-kind = 'S'.
ld_rsparams-option = 'EQ'.
ld_rsparams-low = test.
append ld_rsparams to l_rsparams_tt.
ld_varid-mandt = sy-mandt.
ld_varid-report = repid .
ld_varid-variant = variant.
ld_varid-transport = 'F'.
ld_varid-environmnt = 'A'.
ld_varid-version = '1'.
ld_varid-ename = sy-uname.
ld_varid-edat = sy-datum.
ld_varid-etime = sy-uzeit.
ld_varid-mlangu = sy-langu.
ld_varid-xflag1 = '20'.
ld_varid-xflag2 = '00'.
call function 'RS_CREATE_VARIANT'
exporting
curr_report = repid
curr_variant = variant
vari_desc = ld_varid
tables
vari_contents = l_rsparams_tt
vari_text = l_varit
exceptions
illegal_report_or_variant = 1
illegal_variantname = 2
not_authorized = 3
not_executed = 4
report_not_existent = 5
report_not_supplied = 6
variant_exists = 7
variant_locked = 8
others = 9.
CALL FUNCTION 'JOB_OPEN'
EXPORTING
jobname = jobname
IMPORTING
jobcount = numb
EXCEPTIONS
cant_create_job = 1
invalid_job_data = 2
jobname_missing = 3
OTHERS = 4.
*IF ( sy-subrc IS INITIAL ) .
* add steps to the job
CALL FUNCTION 'JOB_SUBMIT'
EXPORTING
authcknam = sy-uname
jobcount = numb
jobname = jobname
report = repid
variant = variant
* extpgm_param = 'S_DATUM'
*IMPORTING
* step_number = numb2
EXCEPTIONS
bad_priparams = 1
bad_xpgflags = 2
invalid_jobdata = 3
jobname_missing = 4
job_notex = 5
job_submit_failed = 6
lock_failed = 7
program_missing = 8
prog_abap_and_extpg_set = 9
OTHERS = 10.
*ENDIF.
*IF ( sy-subrc IS INITIAL ) .
CALL FUNCTION 'JOB_CLOSE'
EXPORTING
jobcount = numb
jobname = jobname
EXCEPTIONS
CANT_START_IMMEDIATE = 1
INVALID_STARTDATE = 2
JOBNAME_MISSING = 3
JOB_CLOSE_FAILED = 4
JOB_NOSTEPS = 5
JOB_NOTEX = 6
LOCK_FAILED = 7
INVALID_TARGET = 8
OTHERS = 9.
*ENDIF.
SELECT * FROM zdfkkpao INTO wa WHERE vmdat in s_datum .
WRITE wa-vmdat.
ENDSELECT.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hi,
das mit dem JOB_SUBMIT kann man zwar machen - aber wenn man einen Report als Jobschritt einplanen möchte geht das doch viel einfacher mittels des normalen SUBMIT ,zumal man das dann ja auch schon mal in seinem Programm testen kann wenn man den Submit direkt macht und "via selection-screen" angibt.
Hier mal ein sehr einfaches Beispiel, wie man einen Report in einen Hintergrundjob einplant - der Vorteil ist hier eben, dass du alle Parameter und Selektionsoptionen direkt mitgeben kannst statt dieses seltsamen "RS_CREATE_VARIANT"-Codings...
das mit dem JOB_SUBMIT kann man zwar machen - aber wenn man einen Report als Jobschritt einplanen möchte geht das doch viel einfacher mittels des normalen SUBMIT ,zumal man das dann ja auch schon mal in seinem Programm testen kann wenn man den Submit direkt macht und "via selection-screen" angibt.
Hier mal ein sehr einfaches Beispiel, wie man einen Report in einen Hintergrundjob einplant - der Vorteil ist hier eben, dass du alle Parameter und Selektionsoptionen direkt mitgeben kannst statt dieses seltsamen "RS_CREATE_VARIANT"-Codings...
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Form start_new_mode
*&---------------------------------------------------------------------*
FORM start_new_mode USING p_mode TYPE ty_n2
gt_list TYPE fagl_t_kunnr.
DATA: wa_tbtcjob TYPE tbtcjob,
r_kunnr TYPE RANGE OF kunnr,
wa_r_kunnr LIKE LINE OF r_kunnr.
CONCATENATE 'MYJOBNAME - MODE:' p_mode INTO
wa_tbtcjob-jobname SEPARATED BY space.
CALL FUNCTION 'JOB_OPEN'
EXPORTING
jobname = wa_tbtcjob-jobname
IMPORTING
jobcount = wa_tbtcjob-jobcount
EXCEPTIONS
cant_create_job = 1
invalid_job_data = 2
jobname_missing = 3
OTHERS = 4.
wa_r_kunnr(3) = 'IEQ'.
LOOP AT gt_list INTO wa_r_kunnr-low.
APPEND wa_r_kunnr TO r_kunnr.
ENDLOOP.
SUBMIT zmyreportname
VIA JOB wa_tbtcjob-jobname NUMBER wa_tbtcjob-jobcount
AND RETURN
WITH p_mode = p_mode
WITH p_spart = p_spart
WITH so_kunnr IN r_kunnr
WITH so_vkorg IN so_vkorg
WITH so_vtweg IN so_vtweg.
CALL FUNCTION 'JOB_CLOSE'
EXPORTING
jobcount = wa_tbtcjob-jobcount
jobname = wa_tbtcjob-jobname
strtimmed = 'X'
EXCEPTIONS
cant_start_immediate = 1
invalid_startdate = 2
jobname_missing = 3
job_close_failed = 4
job_nosteps = 5
job_notex = 6
lock_failed = 7
OTHERS = 8.
ENDFORM. " start_new_modeServus ABAP_BEGINNER,
sorry, aber du hast hier etwas grundsätzlich falsch verstanden. Mit deinem gegenwärtigen Programm baust du dir eine Endlosschleife, da du es immer wieder selbst einplanst.
1. Du brauchst einfachheitshalber 2 Programme für die Joblösung: Prog 1 was deine Selektion macht und Prog 2 was die Einplanung übernimmt.
2. In Prog 1 baust du einen Selection-Screen und machst im Start-Of-Selection deine Selektion. Zu diesem Programm speicherst du dir manuell deine 12 Varianten, also Programm aufrufen, Werte eintragen und dann auf Speichern klicken.
3. In Prog 2 liest du die Namen der Varianten zu Prog 1 aus der VARID in eine interne Tabelle, dann loopst du über diese Tabelle und startest somit für jede Variante von Prog 1 einen Job per JOB_OPEN, JOB_SUBMIT, JOB_CLOSE.
4. Alternativ kannst du den Prog 1 auch mit SUBMIT direkt aufrufen, damit sparst du dir die Varianten.
Ergebnis ist: Prog 2 ist dann beendet und im Hintergrund laufen 12 Instanzen von Prog 1, jeweils mit unterschiedlichem Selektionsdatum. Achte aber hier darauf, dass du 12 Prozesse auf einmal dicht machst....an sich keine gute Idee. Idealerweise schaust du, wieviel Prozesse frei sind und steuerst deinen Loop noch danach.
PS: Mit einem SELECT ... ENDSELECT brauchst du wahrscheinlich zuviel Kommunikation mit der Datenbank. Nimm lieber ein SELECT .. INTO itab und mach im Anschluss ein LOOP AT... ASSIGNING. Das ist denke ich schneller.
sorry, aber du hast hier etwas grundsätzlich falsch verstanden. Mit deinem gegenwärtigen Programm baust du dir eine Endlosschleife, da du es immer wieder selbst einplanst.
1. Du brauchst einfachheitshalber 2 Programme für die Joblösung: Prog 1 was deine Selektion macht und Prog 2 was die Einplanung übernimmt.
2. In Prog 1 baust du einen Selection-Screen und machst im Start-Of-Selection deine Selektion. Zu diesem Programm speicherst du dir manuell deine 12 Varianten, also Programm aufrufen, Werte eintragen und dann auf Speichern klicken.
3. In Prog 2 liest du die Namen der Varianten zu Prog 1 aus der VARID in eine interne Tabelle, dann loopst du über diese Tabelle und startest somit für jede Variante von Prog 1 einen Job per JOB_OPEN, JOB_SUBMIT, JOB_CLOSE.
4. Alternativ kannst du den Prog 1 auch mit SUBMIT direkt aufrufen, damit sparst du dir die Varianten.
Ergebnis ist: Prog 2 ist dann beendet und im Hintergrund laufen 12 Instanzen von Prog 1, jeweils mit unterschiedlichem Selektionsdatum. Achte aber hier darauf, dass du 12 Prozesse auf einmal dicht machst....an sich keine gute Idee. Idealerweise schaust du, wieviel Prozesse frei sind und steuerst deinen Loop noch danach.
PS: Mit einem SELECT ... ENDSELECT brauchst du wahrscheinlich zuviel Kommunikation mit der Datenbank. Nimm lieber ein SELECT .. INTO itab und mach im Anschluss ein LOOP AT... ASSIGNING. Das ist denke ich schneller.
...ich weise noch mal darauf hin, dass ein einfaches paketweises lesen die Programmlaufzeit ggfs. ebenfalls drastisch reduzieren kann!!!
Bei der Verteilung auf unterschiedliche Prozesse besteht zudem das Problem, dass die Daten, die einem Prozess übergeben werden, empirisch ermittelt werden müssen und später evtl. schlecht anpassbar sind. Beispiel: Bei dem jetzigen Datenstand kommt heraus, dass eine monatsweise Abgrenzung super funktioniert, weil für jeden Monat ~100.000 Datensätze vorhanden sind. Jetzt kann es aber sein, dass ein Buchungskreis oder durch Zukauf oder Sonstiges jede Menge Kunden dazu kommen. Auf einmal hat man pro Monat 500.000 Datensätze und das Programm arbeitet wieder so langsam wie zuvor.
Beim Abarbeiten von Paketen, hat man die Gewissheit, dass das Datenvolumen immer gleich ist. Es ist dann ein Problem, wenn die Pakete nicht beliebig aufteilbar sind. Beispiel: Für die Analyse und Bearbeitung benötige ich immer alle Buchungen eines Monats. Beim paketweisen Lesen kann das nicht sichergestellt werden.
jm2c.
Bei der Verteilung auf unterschiedliche Prozesse besteht zudem das Problem, dass die Daten, die einem Prozess übergeben werden, empirisch ermittelt werden müssen und später evtl. schlecht anpassbar sind. Beispiel: Bei dem jetzigen Datenstand kommt heraus, dass eine monatsweise Abgrenzung super funktioniert, weil für jeden Monat ~100.000 Datensätze vorhanden sind. Jetzt kann es aber sein, dass ein Buchungskreis oder durch Zukauf oder Sonstiges jede Menge Kunden dazu kommen. Auf einmal hat man pro Monat 500.000 Datensätze und das Programm arbeitet wieder so langsam wie zuvor.
Beim Abarbeiten von Paketen, hat man die Gewissheit, dass das Datenvolumen immer gleich ist. Es ist dann ein Problem, wenn die Pakete nicht beliebig aufteilbar sind. Beispiel: Für die Analyse und Bearbeitung benötige ich immer alle Buchungen eines Monats. Beim paketweisen Lesen kann das nicht sichergestellt werden.
jm2c.
Vergleichbare Themen
0
Antw.
Antw.
1657
Views
Views
Währungskurse an mehrere SAP-Systeme verteilen
von SilkeZ » 30.03.2006 18:09 • Verfasst in ABAP® Core
von SilkeZ » 30.03.2006 18:09 • Verfasst in ABAP® Core
1
Antw.
Antw.
2381
Views
Views
1
Antw.
Antw.
3162
Views
Views
10
Antw.
Antw.
4062
Views
Views
BAPI_DOCUMENT_CHECKOUTVIEW2 erzeugt Massen von Unix-Prozesse
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
2
Antw.
Antw.
2839
Views
Views
Datei vom Appl Server auf Präsent. Server
von codierknecht » 29.04.2008 08:51 • Verfasst in ABAP® für Anfänger
von codierknecht » 29.04.2008 08:51 • Verfasst in ABAP® für Anfänger
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.