ABAP · Performans

Saatler süren o işlem dakikalara inebilir!

ABAP'ta paralel işlemeye sade bir giriş: boş duran iş süreçlerini nasıl çalıştırırsınız?

Her ekipte bir tane vardır: gece başlayan, sabaha kadar süren ve bittiğinde herkesin rahatladığı o job. İçine baktığınızda genellikle suçlu tek bir desendir — milyonlarca satırı tek tek dönen kocaman bir LOOP.

İlginç olan şu: o sırada sunucudaki onlarca diyalog iş süreci boş boş bekliyordur. ABAP, bu boş kapasiteyi kullanmanız için yıllardır bir yol sunuyor. Adı asenkron RFC ile paralel işleme.

Fikir: böl, dağıt, topla

Devasa veriyi paketlere bölersiniz. Her paketi ayrı bir iş sürecine gönderip aynı anda çalıştırırsınız. Tek süreç 10 paketi sırayla bitirirken, 10 süreç hepsini neredeyse bir paket süresinde bitirir.

Tek dikkat edilecek nokta: bu süreçler birbirinden bağımsızdır. Aynı değişkeni paylaşmaz, aynı LUW'da çalışmazlar. Sonuç size yalnızca geri çağrı (callback) ile döner.

Klasik yöntem

Onlarca yıldır işi gören temel sözdizimi şudur:

LOOP AT lt_packages INTO DATA(ls_pkg).
  CALL FUNCTION 'Z_PROCESS_PACKAGE'
    STARTING NEW TASK |TASK_{ sy-tabix }|
    DESTINATION IN GROUP 'parallel_grp'
    PERFORMING handle_result ON END OF TASK
    EXPORTING iv_data = ls_pkg
    EXCEPTIONS resource_failure = 1 OTHERS = 2.

  " Boş süreç yoksa biraz bekle, sonra devam et
  IF sy-subrc = 1.
    WAIT UNTIL gv_done >= gv_started UP TO 5 SECONDS.
  ENDIF.
ENDLOOP.

WAIT UNTIL gv_done >= gv_started.   " hepsinin bitmesini bekle

Akılda tutulacak iki şey var:

• Boş süreç yoksa hata değil, trafik işaretidir. resource_failure geldiğinde bekleyip yeniden denersiniz; yoksa görevler kaybolur.
• Paylaşılan değişken yoktur. Veriyi içeri EXPORTING ile gönderir, dışarı yalnızca geri çağrıdaki RECEIVE RESULTS ile alırsınız.

Modern yöntem: CL_ABAP_PARALLEL

Klasik desen güçlüdür ama bekleme döngüsünü ve kaynak kontrolünü elle yazmak yorucudur. S/4HANA ve ABAP Cloud'da SAP bunu temiz bir sınıfın arkasına sakladı. Siz sadece işi tarif edersiniz; dağıtmak, beklemek ve toplamak çerçevenin görevidir.

" Görev sınıfı: tek yapması gereken DO metodunu doldurmak
CLASS lcl_task DEFINITION INHERITING FROM cl_abap_parallel.
  PUBLIC SECTION.
    METHODS do REDEFINITION.   " paralel çalışacak asıl mantık
ENDCLASS.

" Parçaları doldur ve çalıştır
DATA lt_tasks TYPE cl_abap_parallel=>t_in_inst_tab.
LOOP AT lt_packages INTO DATA(ls_pkg).
  INSERT NEW lcl_task( ls_pkg ) INTO TABLE lt_tasks.
ENDLOOP.

NEW cl_abap_parallel( p_num_tasks = 8 )->run_inst(
  EXPORTING p_in_tab  = lt_tasks
  IMPORTING p_out_tab = DATA(lt_done) ).

En güzel kısmı p_num_tasks: kaç süreç kullanılacağını siz belirlersiniz. Çerçeve, gerçek kullanıcılar için her zaman birkaç süreci yedekte tutar — yani "tüm sunucuyu kilitleme" riskini sizin yerinize yönetir.

Her şeyi paralelleştirmeyin

Veriyi başka bir sürece taşımanın kendi maliyeti vardır. Pratik kural: bir parça çok kısa sürede bitiyorsa (kabaca birkaç yüz milisaniyenin altı), paralelleştirmek faydadan çok zarar getirir. Bu araç; uzun süren, bağımsız ve çok sayıda iş için vardır. Bu üçü yoksa ihtiyacınız muhtemelen daha iyi bir SQL ya da CDS'tir.

Özet

• Bağımsızlık esastır: görevler bellek ve LUW paylaşmaz, sonuç sadece geri çağrı ile döner.
• Kaynağı yönetin: klasik yöntemde resource_failure'ı, modern yöntemde görev sayısını kontrol edin.
• Kısa işleri bırakın: taşıma maliyeti kazancı yutar.