Parallel Prozzessen Starten

[autohandel7]

Hallo Experten,
ich habe ein grosse interne Tabelle, die ich mit dem Loop lese.
In loop rufe ich ein FUBAan, die gibt mir für alle in Itab MATNR ,meine Werte.
Di ganze prozzess läuft ganz langsam. Gibt es Möglichkeit es irgendwo schnelle machen oder paralle laufen lassen?
Oder gibt es andere optimirungs Möglichkeiten?
Loop at iTable
call function 'MD_STOCK_REQUIREMENTS_LIST_API'
endloop.
Danke

[nickname8]

Hi,
es gab mal ein SAP Inside Track (an dem ich leider nicht dabei war).
Da wurde Parallele Verarbeitung vorgestellt.
Hab ich schon mal selber probiert und funktioniert ganz gut.

Hier ein Link wo Infos zu finden sind:
https://www.dropbox.com/sh/acdyfiecqwoc ... pYtMa?dl=0

So als Idee: itab in mehrere itabs teilen, dem parallel-fuba übergeben und verarbeiten lassen.

Grüße

[wreichelt]

Hi,

es gibt zum einen den OSS-Hinweis 862337 - Order report performance: Parallel import

darüber hinaus könnte auch das was sein:
SAP hat den Bericht RMMD07DB geliefert, der auch einen ähnlichen Zweck erfüllt und dessen Ausgabe der Standardbildschirm von SAP MD07 ist.

Gruß Wolfgang

[Daniel]

Brauchst du wirklich die Bedarfs-/Bestandsliste für
eine große Anzahl von Materialien?
Ich habe den Verdacht daß hier der falsche Baustein
bemüht wird.

[DeathAndPain]

Den SAP-Server mit massiv paralleler Verarbeitung dicht zu machen, so dass derweil kein anderer Benutzer mehr sinnvoll darauf arbeiten kann, halte ich sowieso nicht für einen sinnvollen Ansatz.

Das Problem besteht letztlich darin, dass die SAP-FuBas zur Informationsbeschaffung quälend langsam zu sein pflegen und meist auch viel mehr Informationen lesen als notwendig.

Die Lösung, die sich in solch Fall für mich bewährt hat, besteht darin, die benötigten Informationen direkt aus den betreffenden Tabellen zu lesen. Damit ist man um Größenordnungen schneller und reduziert nebenbei auch die Systemlast. Nur bei wenigen Fubas, die Werte, die so nicht direkt in der Datenbank stehen, nach ganz speziellen Kriterien kombinieren und berechnen, muss man sich das gut überlegen, denn zu versuchen das nachzuprogrammieren ist ein riskantes Unterfangen, bei dem man in speziellen Fällen dann vielleicht mal falsche Werte bekommt. In fast allen Fällen aber liefern einem die SAP-Fubas nur Werte, die man sich per SELECT auch direkt und viel flinker selber aus der Datenbank lesen kann. Zumal man dann den SELECT genau auf den jeweiligen Anwendungsfall maßschneidern kann, um en bloc genau die benötigten Werte (und auch nicht mehr als diese) zu bekommen.

[Daniel]

Das mache ich -wenn es um grössere Datenmengen geht- nur so.
Allerdings setzt das auch eine kleine Portion Erfahrung voraus.

[ralf.wenzel]

Das mit der Erfahrung scheint auch Kunden zunehmend klar zu werden. Zumindest bei den Projektofferten, die ich so bekomme, wird Erfahrung deutlich stärker gefordert und auch hinterfragt als das früher der Fall war. Die Kunden wissen viel mehr, was sie wollen.

Statt SAP-Funktionsbausteinen nutze ich zunehmend eigene Routinen (zentralisiert, also aufrufbar), weil ich für mich festgestellt habe, dass bei einem Kunden dieselbe oder ähnliche Selektion häufiger gebraucht wird. Aber dann zumeist eben nur bei diesem Kunden.

Bei den SAP-Funktionsbausteinen stört mich insbesondere, dass viele Funktionen doppelt und dreifach umgesetzt sind. Statt mal im Repository zu suchen, schreibt man da wohl lieber was Neues. Dank kann ich mir den FuBau gleich schenken.


Ralf

PS: Sinnvoll sind FuBas, die ganze Funktionen abbilden, wie „Anlegen eines Materialstammsatzes“ oder so, denn das ist von Hand in der Tat nicht trivial, das Ändern eines Stammsatzes noch weniger. Da erzeugt man schnell Datenschiefstände, die man nicht wieder aus dem System bekommt. Außerdem sperren sie Funktionen, die man lieber nicht ausführen sollte. Sowas wie Ändern der Basismengeneinheit, was eigentlich gar nicht und uneigentlich bestenfalls mit massiven Nacharbeiten möglich ist.

[ewx]

Den SAP-Server mit massiv paralleler Verarbeitung dicht zu machen, so dass derweil kein anderer Benutzer mehr sinnvoll darauf arbeiten kann, halte ich sowieso nicht für einen sinnvollen Ansatz.

Deswegen kann man mit Transaktion RZ12 RFC-Servergruppen definieren, die genau sowas verhindern - so sie denn sinnvoll eingestellt werden... .

[DeathAndPain]

Sinnvoll sind FuBas, die ganze Funktionen abbilden, wie „Anlegen eines Materialstammsatzes“ oder so, denn das ist von Hand in der Tat nicht trivial, das Ändern eines Stammsatzes noch weniger. Da erzeugt man schnell Datenschiefstände, die man nicht wieder aus dem System bekommt.

Das sehe ich genauso, aber dabei geht es ja auch um das Ändern von Daten. Ändern sollte man (fast) immer nur mit SAP-Standardmitteln machen, da man nicht wissen kann, was es da noch alles an Konsistenzabhängigkeiten gibt und sich im Übrigen auch keine Fehler erlauben kann. Lesen von Daten ist da bedeutend unkritischer. Zum einen kann man über gelesene Werte nicht wirklich diskutieren - die sind richtig (im Sinne des Programms), denn es sind die Werte, die in der Datenbank stehen. Und wenn man da einen Fehler macht (egal ob Interpretationsfehler oder einen simplen Programmierfehler), dann hat man einen Bug in seinem eigenen Programm und dessen Werteausgabe, zerschießt damit aber nicht die Konsistenz der Datenbank. Im übrigen ist dabei auch gesichert, dass man sich nicht mit Verbucherpuffern und Sperrkonzepten des Standards ins Gehege kommt. Im ganz großen Stil Daten schreiben tut man ja auch nur selten. Das ist normalerweise nicht der Engpass bei der Performance. Aber große Datenmengen mit den Fubas des Standards zu lesen kann ein Programm bis zur Unbrauchbarkeit langsam machen.

[DeathAndPain]

Wofür ich zu Zeiten, als ich noch SD/MMler war, mal einen eigenen Report geschrieben habe, der Daten tatsächlich durch direktes Schreiben in die Datenbank ändert, ist die Materialinventur. Ich weiß nicht, ob sich das in den letzten 10 Jahren geändert hat, aber damals war das Programm, mit dem man die gezählten Inventurpapierbelege im System eingibt (Transaktion MI04), eine ergonomische Katastrophe (und meine Vermutung wäre, dass sich daran nichts geändert hat). Die Inventurbelege haben aber, nachdem sie angelegt worden sind, aber bevor sie verbucht werden, keinerlei Abhängigkeiten zu anderen Ecken des Systems. Man kann da also einfach hart Zählwerte (einschließlich der blöden Nullzählungshaken, was für eine furchtbare Konzession an die Tatsache, dass bei Dezimaldynprofeldern Null und leer das gleiche bedeuten) in die Datenbanktabellen schreiben. Also habe ich damals ein Programm geschrieben, das es erlaubt, die Inventurbelege ergonomisch zu erfassen (ohne Nullzählungshaken!). Ich würde schätzen, dass ich damit bei der Inventur ungefähr doppelt so schnell Zählungen erfasst habe wie mit der MI04.

Das ist kein Problem, nur anlegen muss man die Belege im Standard, und verbuchen muss man sie im Standard, sonst gibt es Stress mit FI. Den ungezählten Beleg zählen und auf "gezählt" setzen aber kann man problemlos direkt in der Datenbanktabelle machen.

[black_adept]

...Aber große Datenmengen mit den Fubas des Standards zu lesen kann ein Programm bis zur Unbrauchbarkeit langsam machen.

Willst du unserem OP mit seinem Wissensstand ( oder von mir aus auch mit deinem Wissensstand bei diesem nicht gerade trivialen Thema ) allen Ernstes empfehlen eine Bedarf-Bestandsliste nachzuprogrammieren oder selbständig aus den DB-Tabellen zusammenzuklauben anstatt sich des bewährten SAP-FB zu bedienen?

[ralf.wenzel]

Welche Alternative gibt es, wenn die FuBas zu langsam sind?


Ralf

[4byte]

Welche Alternative gibt es, wenn die FuBas zu langsam sind?
Ralf

• Die Datenmenge in der ITAB verkleinern?
• Auslagern in einen nächtlichen Job der die Bedarfe ermittelt und die geforderten Infos in eine separate Z Tabelle schreibt. Hier dann einfach ein "Auswerte Report" schreiben ?
  

Grüße 4Byte

[autohandel7]

Hi,

es gibt zum einen den OSS-Hinweis 862337 - Order report performance: Parallel import

darüber hinaus könnte auch das was sein:
SAP hat den Bericht RMMD07DB geliefert, der auch einen ähnlichen Zweck erfüllt und dessen Ausgabe der Standardbildschirm von SAP MD07 ist.

Gruß Wolfgang

Danke Wolfgang,
mein Job werden immer in der Nacht gestartet, deshalb kein grosse Einfluss für User.
Kannst du mir kurz klären , wie arbeitet diese Paralele Bearbeitung. z.Bp. ich habe interne tabele mit 10 Sätzen.
Ich starte Loop über diese Tabelle, dann call Transaktion.... niemt FUBA erstmal ersten Satz, liest und paralel startet zweite Satz? oder wird mein Tabellle automatisch auf 2 gruppe verteilt(1-5 und 6-10)?
Oder es kann mehr als 2 paralele Prozzese sein?
Danke .

[nickname8]

Schau mal den Link, den ich im 2. Beitrag eingefügt habe. Da gibts viele Infos dazu.

Hier aber mal ein vereinfachtes Beispiel (stark angelehnt an das Beispiel aus der Präsentation):

Code: Alles auswählen

*&---------------------------------------------------------------------*
*& Report ZPARALLEL
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zparallel NO STANDARD PAGE HEADING.

***********************************************************************
LOAD-OF-PROGRAM.
***********************************************************************

  TYPES: BEGIN OF t_data,
           key     TYPE char1,                    " This is the key, needed later to find the right entry to store result. This can also be a material or customer number
           time    TYPE i,                        " Just needed in the demo to get different runtimes
           o_class TYPE REF TO zcl_parallel_demo, " Store the instances
         END OF t_data.

* Some global variables to make the test report easier to read...
  ##needed
  ##no_text
  DATA: g_group        TYPE rzllitab-classname
                    VALUE 'parallel_generators', " Logon group of RZ12
        g_wp_available TYPE i,                   " Number of available dialog processes
        g_snd_jobs     TYPE i VALUE 1,           " Jobs started
        g_rcv_jobs     TYPE i VALUE 1.           " Jobs finished
  ##needed
  DATA: git_data   TYPE STANDARD TABLE OF t_data.

***********************************************************************
INITIALIZATION.
***********************************************************************
  SELECTION-SCREEN BEGIN OF BLOCK s_alpha WITH FRAME TITLE TEXT-t01.
  PARAMETERS: pa_ser RADIOBUTTON GROUP radi DEFAULT 'X',
              pa_par RADIOBUTTON GROUP radi.
  SELECTION-SCREEN END   OF BLOCK s_alpha.

***********************************************************************
START-OF-SELECTION.
***********************************************************************
  GET TIME STAMP FIELD DATA(l_time).
  WRITE / l_time.

  PERFORM initialize.
  PERFORM do_simulation.

  GET TIME STAMP FIELD DATA(l_time2).
  WRITE / l_time2.

  DATA(seconds) = cl_abap_tstmp=>subtract(
      tstmp1 = l_time2
      tstmp2 = l_time ).

  WRITE / seconds.

***********************************************************************
END-OF-SELECTION.
***********************************************************************
  WRITE : / 'Report ends...'(003).

***********************************************************************
* S u b r o u t i n e s
***********************************************************************
FORM initialize.
* Fill ITAB with 5 values (which run in the end in parallel...)
  git_data = VALUE #( ( key = 'A'  time = 3 )
                      ( key = 'B'  time = 1 )
                      ( key = 'C'  time = 2 )
                      ( key = 'D'  time = 10 )
                      ( key = 'E'  time = 2 ) ).

ENDFORM.                    "initialize

***********************************************************************
FORM do_simulation.
***********************************************************************
  IF pa_ser EQ abap_true.
    PERFORM do_simulation_serial.
  ELSE.
    PERFORM do_simulation_parallel.
  ENDIF.

  COMMIT WORK AND WAIT.
ENDFORM.                    "do_simulation

***********************************************************************
FORM do_simulation_serial.
***********************************************************************
*  Loop over the itab and run the worker method one after the other...

  WRITE: / 'No of serial jobs:', lines( git_data ).
  LOOP AT git_data ASSIGNING FIELD-SYMBOL(<fs>).
    CREATE OBJECT <fs>-o_class.
    <fs>-o_class->worker( pi_time = <fs>-time ).
  ENDLOOP.
ENDFORM.                    "do_simulation_serial

***********************************************************************
FORM do_simulation_parallel.
***********************************************************************
  DATA l_msg TYPE char80 VALUE space.


* Initialize the "Parallel Background Tasks" enviroment
  CALL FUNCTION 'SPBT_INITIALIZE'
    EXPORTING
      group_name   = g_group
    IMPORTING
      free_pbt_wps = g_wp_available.

  WRITE: / 'No of max. parallel jobs:', g_wp_available.

*  Loop the itab (3 values) and run the worker method parallel in seperate tasks
  LOOP AT git_data ASSIGNING FIELD-SYMBOL(<fs>).
    CALL FUNCTION 'Z_RFC_PARALLEL'
      STARTING NEW TASK <fs>-key                 " will be taskname in return_info
      DESTINATION IN GROUP g_group
      PERFORMING z_rfc_parallel_return ON END OF TASK
      EXPORTING
        pi_time               = <fs>-time
      EXCEPTIONS
        communication_failure = 1 MESSAGE l_msg
        system_failure        = 2 MESSAGE l_msg
        resource_failure      = 3 .
    IF sy-subrc NE 0.
      WRITE: / l_msg.
      EXIT.
    ENDIF.
    ADD 1 TO g_snd_jobs.                         " Increment no. of started jobs
  ENDLOOP.

* Continue, after all started jobs are finished.
  WAIT UNTIL g_rcv_jobs >= g_snd_jobs.
ENDFORM.                    "do_simulation_parallel


##perf_no_type
***********************************************************************
FORM z_rfc_parallel_return USING taskname. "do not use 'type xxxx' here.
***********************************************************************
  DATA: l_string TYPE string,
        l_msg    TYPE char80 VALUE space.

* Import the FM export parameters (here: serialized instance)
  RECEIVE RESULTS FROM FUNCTION 'Z_RFC_PARALLEL'
     IMPORTING pe_string = l_string
        EXCEPTIONS
        communication_failure = 1 MESSAGE l_msg
        system_failure        = 2 MESSAGE l_msg
        resource_failure      = 3 .

  IF sy-subrc EQ 0.
    ADD 1 TO g_rcv_jobs.                         " Increment no. of received jobs

    READ TABLE git_data WITH KEY key = taskname ASSIGNING FIELD-SYMBOL(<fs>).
    IF sy-subrc EQ 0.
      CALL TRANSFORMATION id                     " Deserialize string to instance
      SOURCE XML l_string
      RESULT model = <fs>-o_class.
    ELSE.
      WRITE: / l_msg.
      EXIT.
    ENDIF.
  ENDIF.
ENDFORM.                    "do_simulation_parallel

FUBA Z_RFC_PARALLEL:

Code: Alles auswählen

FUNCTION z_rfc_parallel.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(PI_TIME) TYPE  I
*"  EXPORTING
*"     VALUE(PE_STRING) TYPE  STRING
*"----------------------------------------------------------------------

  data:
    ls_logtable TYPE zlog.

  DATA(lo_myclass) = NEW zcl_parallel_demo( ).
  lo_myclass->worker( pi_time = pi_time ).

  ls_logtable-pname = 'Z_RFC_PARALLEL'.
  ls_logtable-datum = sy-datlo.
  ls_logtable-uzeit = sy-timlo.


  IF zcl_parallel_demo=>table IS INITIAL.
    ls_logtable-text = 'NICHT GEFÜLLT'.
    ls_logtable-lfnum = 1.
    SELECT *
      FROM sflight
      INTO TABLE zcl_parallel_demo=>table.
  ELSE.
    ls_logtable-text = 'GEFÜLLT'.
    ls_logtable-lfnum = 2.
  ENDIF.

  MODIFY zlog FROM ls_logtable.

*  Serialize instance to string.
  CALL TRANSFORMATION id
         SOURCE model = lo_myclass
         RESULT XML pe_string.



ENDFUNCTION.
 

Im fuba Z_RFC_PARALLEL müstest du quasi nur dein SD... FUBA aufrufen.