Parallele Workprozesse

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

Parallele Workprozesse

Beitrag von Smeagol (ForumUser / 1 / 0 / 0 ) »
Hallo,
ich würde gerne 2 Programme/Vorgänge gleichzeitig ablaufen lassen. Dazu habe ich im SAP-Programm RFREDSLOADGEN den Funktionsbaustein SPTA_PARA_PROCESS_START_2 gefunden , der das wohl als asynchronen RFC realisiert.
Ist das die einzige Möglichkeit, oder gibts vielleicht noch eine Einfachere? Der FuBau ist zwar dokumentiert, ich bräuchte aber doch ein kleines Bespiel, um da durchzublicken! Hat das mal jemand beispielhaft für 2 parallele Forms oder mit 2 parallel laufenden Programmen probiert?
Das Beispielprogramm SPTA_PARA_DEMO_1 der Funktionsgruppe SPTA nutzt mir leider nichts, da nur ein Funktionsbaustein parallel laufen gelassen wird. Ich würde gerne bestimmen, was bzw. welcher FuBau/Vorgang/Programm jeweils in den 2 Prozessen abläuft!
Gruß,
Smeagol.

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


Beitrag von dawns (ForumUser / 99 / 0 / 0 ) »
Hi zsm,
ich stehe bald vor dem selben Problem, daher wollte ich wissen ob hier wirklich keiner eine idee hat? Meine Aufgabe wird es sein mehrere Prozesse parallel ablaufen zu lassen. Diese Prozesse führen Berechnungen anhand Datenbanktabellen durch. Es sind mehrer Berechnungen zu verschiedenen Tabellen. Ev. soll man dann auch noch son Feld angeben können auf welchen Server ...

Habt ihr Rat?
thx im voraus
mfg dawns

Beitrag von edwin (Specialist / 300 / 9 / 68 ) »
Hallo,

aus den Angaben werden ich nicht ganz schlau,
willst Du verschiedene Programme im Batch parallel starten - dann kannst Du das mit Jobs realisieren FB: JOB_OPEN, JOB_SUBMIT, JOB_CLOSE.

oder willst Du asynchrone RFC' starten unter der Kontrolle Deines Programmes, dann musst Du RFC-FB's schreiben und
CALL FUNCTION 'XXXX' STARTING NEW TASK
PERFORMING <call_back> AT END OF TASK benutzen

oder asynchron ohne Kontrolle durch Dein Programm,
CALL FUNCTION 'XXXX' IN BACKGROUND TASK.

Gruss Edwin

Beitrag von edwin (Specialist / 300 / 9 / 68 ) »
Hallo,

aus den Angaben werden ich nicht ganz schlau,
willst Du verschiedene Programme im Batch parallel starten - dann kannst Du das mit Jobs realisieren FB: JOB_OPEN, JOB_SUBMIT, JOB_CLOSE.

oder willst Du asynchrone RFC' starten unter der Kontrolle Deines Programmes, dann musst Du RFC-FB's schreiben und
CALL FUNCTION 'XXXX' STARTING NEW TASK
PERFORMING <call_back> AT END OF TASK benutzen

oder asynchron ohne Kontrolle durch Dein Programm,
CALL FUNCTION 'XXXX' IN BACKGROUND TASK.

Gruss Edwin
*edit
UUPS - da habe ich wohl die Message 2-mal abgeschickt

Beitrag von dawns (ForumUser / 99 / 0 / 0 ) »
nein jobs nicht, die gibts ja schon, sap-standard.
die letzten dinge hörten sich gut an: asynchrone bearbeitung.

weiß du beispielprogramme oder hast ev. beispielsource?

Beitrag von edwin (Specialist / 300 / 9 / 68 ) »
Hi,
ein kleines Beispiel :
läuft unter R4.7 / ERP2004 / ERP2005
FB: Z_DUMMY_RFC - muss RFC-fähig sein

Code: Alles auswählen.

FUNCTION Z_DUMMY_RFC.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(LANGU) TYPE  SPRAS
*"  EXPORTING
*"     VALUE(T100) TYPE  T100
*"----------------------------------------------------------------------

* Damit das Ganze etws länger dauert
* lese den ganzen Schrott
select  * from t100
          into t100
          where sprsl = langu.
endselect.
* Da der FB einen Dialogprozess belegt
* unterliegt er auch der Zeitsteuerung (TIMEOUT)
* damit es nicht zu einem Abbruch kommt
* kann ein
WAIT up to 10 seconds.
* eingebaut werden
* Aber Achtung die Benutzer/ADMIN werden nicht erfreut sein
* wenn dauernd DIA-Prozesseb elegt werden !

* Keine Write !

ENDFUNCTION.
Jetzt noch das zugehörige Programm Z_DUMMY_RFC

Code: Alles auswählen.

*&---------------------------------------------------------------------*
*& Report  Z_DUMMY_RFC                                                 *
*&                                                                     *
*&---------------------------------------------------------------------*
*& Startet 2 WP parallell                                              *
*& der eigene Prozess wird auch mit einer Aufgabe betraut              *
*& liest T100                                                          *
*&---------------------------------------------------------------------*

REPORT  z_dummy_rfc MESSAGE-ID zdum.

TYPES : BEGIN OF ty_task,
           name(8) TYPE c.
TYPES : END  OF ty_task.

DATA new_taskname(8) TYPE c.

DATA it_tasks TYPE TABLE  OF ty_task.
FIELD-SYMBOLS <fs_task> TYPE ty_task.
DATA  wa_task           TYPE ty_task.

DATA it_t100 TYPE TABLE OF t100.

START-OF-SELECTION.
  PERFORM starte_rfc.

END-OF-SELECTION.
*&---------------------------------------------------------------------*
*&      Form  starte_rfc
*&---------------------------------------------------------------------*
FORM starte_rfc .
  DATA wa_t100 TYPE t100.

* Hier sollte jetzt zuerst eine Verarbeitung
* für die Ermittlung der zu verarbeitenden Pakete stehen
* und ein Loop statt der einzelnen Aufrufe
* Aber ! das System prüft ob es überhaupt freie WP
* und die Belastung nicht so hoch wird, ausserdem
* dürfen höchstens 5 Prozesse gestartet werden (ERP2004)

* 1.Task
  new_taskname = 'SPRAS=E'.

  CALL FUNCTION 'Z_DUMMY_RFC'
    STARTING NEW TASK new_taskname
    PERFORMING ende_rfc ON END OF TASK
    EXPORTING
      langu         = 'E'
* Importing geht hier nich, wird in end_rfc übergeben !
*    IMPORTING
*      T100          =
    EXCEPTIONS
         communication_failure = 1
         system_failure        = 2
         RESOURCE_FAILURE      = 3.

  IF sy-subrc EQ 0.
    wa_task-name = new_taskname.
    APPEND wa_task TO it_tasks.
  ELSE.
    MESSAGE e000 WITH 'ERROR:' sy-subrc.
  ENDIF.

* 2.Task
  new_taskname = 'SPRAS=D'.

  CALL FUNCTION 'Z_DUMMY_RFC'
    STARTING NEW TASK new_taskname
    PERFORMING ende_rfc ON END OF TASK
    EXPORTING
      langu         = 'D'
* Importing geht hier nich, wird in end_rfc übergeben !
*    IMPORTING
*      T100          =
    EXCEPTIONS
         communication_failure = 1
         system_failure        = 2
         RESOURCE_FAILURE      = 3.

  .
  IF sy-subrc EQ 0.
    wa_task-name = new_taskname.
    APPEND wa_task TO it_tasks.
  ELSE.
    MESSAGE e000 WITH 'ERROR:' sy-subrc.
  ENDIF.

* Jetzt sind 2-asynchrone Prozesse unterwegs,
* damit der eigentliche JOB auch noch etwas zu tun bekommt
* rufen wir den FB auch noch direkt auf
  CALL FUNCTION 'Z_DUMMY_RFC'
    EXPORTING
      langu = 'F'
    IMPORTING
      t100  = wa_t100.

  APPEND wa_t100 TO it_t100.

* Warte bis keine Tasks mehr in Tabelle
  WAIT UNTIL it_tasks IS INITIAL.

* Ergebnis ausgeben :
  LOOP AT it_t100 INTO wa_t100.
    WRITE : / wa_t100-sprsl,
              wa_t100-arbgb,
              wa_t100-msgnr,
              wa_t100-text.

  ENDLOOP.

ENDFORM.                    " starte_rfc

*&---------------------------------------------------------------------*
*&      Form  ende_rfc
*&---------------------------------------------------------------------*
* Diese Routine wird aus dem Baustein gerufen !
FORM ende_rfc USING taskname.
  DATA wa_t100 TYPE t100.
* Hole die Rückgabe aus dem WP
  RECEIVE RESULTS FROM FUNCTION 'Z_DUMMY_RFC'
     IMPORTING  t100 = wa_t100
     EXCEPTIONS
        communication_failure = 1
        system_failure        = 2.

*  WRITE : / taskname.    "<<< geht nicht, kommt nciht raus !
* Ergebnis in globale Tabelle zurückliefern
  APPEND wa_t100 TO it_t100.

* Lösche die Task aus der Tasktabelle
  DELETE it_tasks WHERE name = taskname.
ENDFORM.                    "ende_rfc
Siehe auch die Hilfe zu CALL FUNCTION STARTING NEW TASK !

Der Einsatz sollte gut überlegt sein, bei Kunden, die sehr viel
Batchverarbeitung haben, wird ein Teil der Arbeit auf Dialogprozesse verteilt,
das ist dann auch gewollt, bei viel Dialogbetrieb -> Vorsicht, da DIA-WP für lange Zeit belegt werden.

Gruss Edwin

Beitrag von dawns (ForumUser / 99 / 0 / 0 ) »
danke sehr :).
hmmm ich hätte da noch eine frage zur umsetzung:
meine aufgabe besteht ja nun darin meine gesamten berechnungen/prozesse parallel laufen zu lassen. damit ihr einen überblick bekommt:

Code: Alles auswählen.

* copy plan_id
  PERFORM plan_id USING    gt_in_plan
                  CHANGING gt_out_plan.

  LOOP AT gt_out_plan ASSIGNING <fs_plan>.
*   number of all shipping order
    PERFORM pl_soko USING    gt_in_ship
                    CHANGING <fs_plan>.

*   number of all resources
    PERFORM pl_res USING    gt_in_res
                   CHANGING <fs_plan>.

*   number of all resources assigned to a tour
    PERFORM pl_res_ass USING    gt_in_res
                       CHANGING <fs_plan>.

*   number of all resources with tours having violation
    PERFORM pl_res_vio USING    gt_in_res
                       CHANGING <fs_plan>.
...
...
  ENDLOOP.
zuerst fülle ich meine ausgabetabelle mit ids/keys. dann loope ich über diese ids (siehe obigen sourceausschnitt) und führe dann zu diesen ids ensprechende weitere operationen aus.
da ich mir das ganze noch nich so richtig vorstellen kann, frage ich euch: wie setzte ich nun die parallele verarbeitung am besten um?
ich hab überhaupt keinen plan :P

ideen/fragen allerdings schon... :
- müsste ich nun alle forms in funktionsbausteine umschreiben und dann im loop einfach ne prozessvariable und ne tasknamenvariable hochzählen?
- dann bräucht ich aber für jedes form ein eigenes "ende-rfc" also commit_back, da ich ja immer andere rückgabewerte habe oder?
- oder sogar alle berechnungen zu dieser ausgabetabelle/zu diesem loop in einen funktionsbaustein?

oder wie würdet ihr das umsetzen?
thx im voraus
mfg dawns[/code]

Beitrag von dawns (ForumUser / 99 / 0 / 0 ) »
so hab mich ma hingesetzt und eine lösung gefunden:

Code: Alles auswählen.

 
  DATA: ls_out_plan       TYPE zplan,
             lv_taskindex(8) TYPE n.
  FIELD-SYMBOLS: <fs_plan> TYPE zplan.

LOOP AT gt_out_plan ASSIGNING <fs_plan>.
    IF para IS INITIAL.
*     calculate planning data syn
      CALL FUNCTION 'ZCALC_PLANNING'
        EXPORTING
          s_in_plan  = <fs_plan>
        IMPORTING
          s_out_plan = ls_out_plan
        TABLES
          t_ship     = gt_in_ship
          t_res      = gt_in_res
          t_tour     = gt_in_tour
          t_tourdoc  = gt_in_tourdoc
          t_stop     = gt_in_stop
          t_soko     = gt_in_soko.
    ELSE.
      ADD 1 TO gv_running.
      ADD 1 TO lv_taskindex.

*     calculate planning data asyn
      CALL FUNCTION 'ZCALC_PLANNING'
        STARTING NEW TASK lv_taskindex
        DESTINATION IN GROUP srv_grp
        PERFORMING come_back ON END OF TASK
        EXPORTING
          s_in_plan = <fs_plan>
        TABLES
          t_ship    = gt_in_ship
          t_res     = gt_in_res
          t_tour    = gt_in_tour
          t_tourdoc = gt_in_tourdoc
          t_stop    = gt_in_stop
          t_soko    = gt_in_soko.

*     max. number of processes is active => wait
      WAIT UNTIL gv_running < max_jobs.
    ENDIF.
  ENDLOOP.
  WAIT UNTIL gv_running IS INITIAL.


FORM come_back USING taskname.
  DATA: lv_plan TYPE zplan.
  RECEIVE RESULTS FROM FUNCTION 'ZCALC_PLANNING'
        IMPORTING s_out_plan    = lv_plan
        EXCEPTIONS
           communication_failure = 1
           system_failure        = 2
           OTHERS                = 3.
* Anzahl der genutzten Tasks um 1 reduzieren
  SUBTRACT 1 FROM gv_running.
  IF sy-subrc = 1.
    MESSAGE s013(/lot/vl) WITH taskname.
  ELSE.
    MESSAGE s014(/lot/vl) WITH taskname.
  ENDIF.
ENDFORM.                    " come_back
im come_back ist der sy-ucomm immer auf 2 -> fehler -> workarea ist nicht gefüllt.... habt ihr eine idee warum?

thx im voraus
mfg dawns

Beitrag von edwin (Specialist / 300 / 9 / 68 ) »
Hallo,
sy-ucomm ? Meinst Du vielleicht sy-subrc ?
Beim Call Function solltest Du noch die Exceptions aufnehmen ,
communication_failure/system_failure/RESOURCE_FAILURE.
Tritt der Fehler vielleicht schon beim Call auf ?
Ist Deine Servergruppe richtig definiert ?
Hast Du es mal ohne den Destination Zusatz versucht ?

Fragen über Fragen :wink:

Gruss Edwin

Beitrag von dawns (ForumUser / 99 / 0 / 0 ) »
Hi,
hehe, das doch gut :)
hab deine fragen abgearbeitet:
1) ja hatte mich verschrieben: sy-subrc
2) Habe Exceptions nun so wie du vorgeschlagen hast im "Call Function..." sowie im "RECEIVE RESULTS..." eingebaut.
3) nein: sy-subrc = 0
4) habe ich gar nicht definiert, was muss da rein :P?
5) Habe den die servergruppe komplett weggelassen, sprich "CALL FUNCTION 'SPBT_INITIALIZE'" sowie den destination zusatz, allerdings bekomme ich beim "RECEIVE RESULTS FROM FUNCTION..." immer noch den rückgabe wert 2 für "system failure" und somit keine ausgefüllte workarea.

Wenn ich den Funktionsbaustein aber ohne die parallele Verarbeiutng laufen lasse, funktioniert er...

Habt ihr noch mehr Ideen worans liegen könnte?

edit: wundert mich das das keiner wusste...
Mein herausgefundene Lösung: Funktionsbaustein muss remotefähig sein ;)

Seite 1 von 1

Vergleichbare Themen

3
Antw.
2825
Views
Workprozesse
von A6272 » 12.06.2018 16:19 • Verfasst in Basis
2
Antw.
554
Views
Remote Function Call und Workprozesse
von JohnLocklay » 28.10.2019 08:25 • Verfasst in ABAP® Core
4
Antw.
2515
Views
Parallele Aufrufe verhindern?
von cbe » 06.06.2019 14:35 • Verfasst in SAP - Allgemeines
1
Antw.
2409
Views
Kurstyp - parallele Währung - Buchungskreiswährung
von Gast » 06.07.2005 19:19 • Verfasst in Financials
0
Antw.
1715
Views
SAP Query: verschiedene parallele Zweige
von Skydizer » 08.05.2007 14:52 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

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