{"id":166898,"date":"2026-09-29T16:00:00","date_gmt":"2026-09-29T14:00:00","guid":{"rendered":"https:\/\/e3mag.com\/?p=166898"},"modified":"2026-09-29T15:01:52","modified_gmt":"2026-09-29T13:01:52","slug":"green-abap-fuer-die-sap-welt","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/green-abap-fuer-die-sap-welt\/","title":{"rendered":"Green Abap f\u00fcr die SAP-Welt"},"content":{"rendered":"\n

Jedes digitale System ben\u00f6tigt im Betrieb Energie. Hardware wird zwar kontinuierlich effizienter, aber ineffiziente Software zwingt Server trotzdem zu unn\u00f6tigen H\u00f6chstleistungen. Gro\u00dfe Unternehmen steuern ihre Gesch\u00e4ftsprozesse meist mit komplexen SAP-Systemen. Die Programmiersprache Abap bildet das Herzst\u00fcck dieser Anwendungen. Fr\u00fcher schrieben Entwicklerinnen und Entwickler Abap-Code oft nur mit Blick auf die reine Funktion. In der heutigen Zeit lohnt es sich, auch auf den Energieverbrauch zu achten. Denn schlechter Code treibt den Stromverbrauch k\u00fcnstlich in die H\u00f6he.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Green Abap und Clean Code<\/h2>\n\n\n\n

Hier setzt der Ansatz \u201eGreen Abap\u201c an. Diese Methode verkn\u00fcpft Nachhaltigkeitsziele direkt mit der Softwareentwicklung. \u201eClean Code\u201c spielt dabei eine riesige Rolle. Dieser Begriff beschreibt gut lesbaren und wartbaren Code. Sauberer Code reduziert Fehler und vereinfacht sp\u00e4tere Optimierungen in der Programmierung. Gut lesbarer Code verhindert technische Schulden, spart langfristig Hardware-Ressourcen und tr\u00e4gt zum Erreichen der Klimaziele bei.<\/p>

\"\"<\/a><\/div><\/div>\n\n\n\n
<\/div>\n\n\n\n

So wurde getestet: Die Methodik<\/h2>\n\n\n\n

Wir haben den Energiehunger von Abap-Code in einer empirischen Analyse untersucht. Wir f\u00fchrten die Tests in einer standardisierten SAP-S\/4-Hana-Umgebung in einem Schulungssystem durch. Der SAP Workload Monitor (ST03N) zeichnete die Leistungswerte pr\u00e4zise auf.<\/p>\n\n\n\n

Dabei verglichen wir stets alte, ineffiziente Programme mit optimierten Versionen. Der Vergleich erfolgt anhand von vier wichtigen Werten: die CPU-Zeit, die Datenbank-Antwortzeit, die gesamte Antwortzeit und die angeforderte Datenmenge.<\/p>\n\n\n\n

Jeder Test lief genau zehnmal ab, um zuf\u00e4llige Schwankungen in den Messwerten zu verhindern. Direkter Stromverbrauch l\u00e4sst sich in einem SAP-System nicht einfach in Joule messen. Die ermittelten CPU- und Datenbank-Zeiten gelten allgemein aber als verl\u00e4ssliche Anzeiger f\u00fcr den Energiebedarf. Je weniger Rechenzeit ein Programm ben\u00f6tigt, desto weniger Strom verbraucht der Server. Neun typische Programmierf\u00e4lle wurden untersucht, zu denen wir die Erkenntnisse und die dazugeh\u00f6rigen Code-Beispiele im Folgenden darstellen.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Fall 1: Datenbank-Abfragen in Schleifen vermeiden<\/h2>\n\n\n\n

Wir identifizierten wiederholte Datenbankabfragen als ein massives Performance-Problem. Die ineffiziente Version liest Datens\u00e4tze Zeile f\u00fcr Zeile aus der Datenbank aus.<\/p>\n\n\n\n

Ineffizienter Code:<\/strong><\/p>\n\n\n\n

REPORT zthesis_ineff_select_loop.\n\nDATA: lt_flights TYPE TABLE OF sflight,\n      ls_flight  TYPE sflight,\n      lv_carrname TYPE scarr-carrname.\n\n\" Load all flight records\nSELECT * FROM sflight INTO TABLE lt_flights.\n\n\" Inefficient: SELECT inside the loop\nLOOP AT lt_flights INTO ls_flight.\n\n  SELECT SINGLE carrname INTO lv_carrname\n    FROM scarr\n    WHERE carrid = ls_flight-carrid.\n\n  WRITE: \/ ls_flight-carrid, ls_flight-connid, lv_carrname.\n\nENDLOOP.<\/code><\/pre>\n\n\n\n
Als Optimierung werden alle Daten vorab in den Arbeitsspeicher geladen. Das Programm nutzt danach schnelle interne Tabellen f\u00fcr den Datenabgleich.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_eff_select_loop.\n\nDATA: lt_flights TYPE TABLE OF sflight,\n      lt_scarr   TYPE TABLE OF scarr,\n      ls_flight  TYPE sflight,\n      ls_scarr   TYPE scarr.\n\n\" Load both tables once\nSELECT * FROM sflight INTO TABLE lt_flights.\nSELECT * FROM scarr INTO TABLE lt_scarr.\n\n\" Efficient: in-memory lookup\nLOOP AT lt_flights INTO ls_flight.\n\n  READ TABLE lt_scarr INTO ls_scarr WITH KEY carrid = ls_flight-carrid.\n\n  IF sy-subrc = 0.\n    WRITE: \/ ls_flight-carrid, ls_flight-connid, ls_scarr-carrname.\n  ENDIF.\n\nENDLOOP.<\/code><\/pre>\n\n\n\n
Die Datenbankzeit sank durch diese Optimierung um fast 99 Prozent.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 2: Ineffiziente L\u00f6schung von Duplikaten<\/h2>\n\n\n\n
Wir testeten den ABAP-Befehl zum L\u00f6schen von Duplikaten. Ohne vorheriges Sortieren der Daten entfernt das System nur direkt benachbarte Duplikate.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_delete_dupl.\n\nDATA: lt_data TYPE TABLE OF sbook,\n      ls_data TYPE sbook.\n\nSELECT * FROM sbook INTO TABLE lt_data\n  WHERE customid = '00001234'.\n\n\" No sorting before deleting duplicates\nDELETE ADJACENT DUPLICATES FROM lt_data\n  COMPARING carrid connid.\n\nLOOP AT lt_data INTO ls_data.\n  WRITE: \/ ls_data-carrid, ls_data-connid.\nENDLOOP.<\/code><\/pre>\n\n\n\n
In der optimierten Version f\u00fcgten wir einen einfachen Sortierbefehl vor der L\u00f6schung ein.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_delete_dupl.\n\nDATA: lt_data TYPE TABLE OF sbook,\n      ls_data TYPE sbook.\n\nSELECT * FROM sbook INTO TABLE lt_data\n  WHERE customid = '00001234'.\n\n\" Efficient: Sorting before deleting duplicates\nSORT lt_data BY carrid connid.\n\nDELETE ADJACENT DUPLICATES FROM lt_data\n  COMPARING carrid connid.\n\nLOOP AT lt_data INTO ls_data.\n  WRITE: \/ ls_data-carrid, ls_data-connid.\nENDLOOP.<\/code><\/pre>\n\n\n\n
Diese kleine Anpassung verbesserte die Antwortzeit des Systems um fast 47 Prozent. Das System vergleicht die Eintr\u00e4ge so viel effizienter.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 3: Datenmengen radikal an der Quelle reduzieren<\/h2>\n\n\n\n
Wir untersuchten das Verhalten von ungefilterten Datenbankabfragen. Die ineffiziente Version l\u00e4dt unbedacht die komplette Datentabelle in den Speicher.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_select_where.\n\nSELECT * FROM sflight INTO TABLE @DATA(lt_flights).\n\nLOOP AT lt_flights INTO DATA(ls_flight).\n  \" process all flights, even when not needed\n  WRITE: \/ ls_flight-carrid, ls_flight-connid.\nENDLOOP.<\/code><\/pre>\n\n\n\n
Wir verlagerten den Filterprozess in der Optimierung direkt auf die Datenbankebene, indem wir eine gezielte “WHERE”-Bedingung einsetzten.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_select_where.\n\nSELECT * FROM sflight\n  WHERE carrid = 'LH'\n  INTO TABLE @DATA(lt_flights_filtered).\n\nLOOP AT lt_flights_filtered INTO DATA(ls_flight).\n  \" process only relevant flights\n  WRITE: \/ ls_flight-carrid, ls_flight-connid.\nENDLOOP.<\/code><\/pre>\n\n\n\n
Die abgerufene Datenmenge schrumpfte dadurch sofort um \u00fcber 73 Prozent.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 4: Tabellen clever vergleichen<\/h2>\n\n\n\n
Verschachtelte Schleifen verursachen bei gro\u00dfen Datenmengen oft exponentielle Rechenzeiten. Wir verglichen dieses Vorgehen mit effizienten Schl\u00fcsseltabellen.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_nested_loop.\n\nDATA: lt_conn    TYPE TABLE OF spfli,\n      lt_flights TYPE TABLE OF sflight.\n\nSELECT * FROM spfli INTO TABLE lt_conn.\nSELECT * FROM sflight INTO TABLE lt_flights.\n\nLOOP AT lt_conn INTO DATA(ls_conn).\n\n  LOOP AT lt_flights INTO DATA(ls_flight).\n\n    IF ls_conn-carrid = ls_flight-carrid AND\n       ls_conn-connid = ls_flight-connid.\n\n      WRITE: \/ ls_conn-carrid, ls_conn-connid, ls_flight-fldate.\n\n    ENDIF.\n\n  ENDLOOP.\n\nENDLOOP.<\/code><\/pre>\n\n\n\n
Wir wandelten die zweite Tabelle f\u00fcr die Optimierung in eine “Hashed Table” um, so dass das Programm passende Eintr\u00e4ge ohne gro\u00dfe Suchvorg\u00e4nge findet.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_hashed_lookup.\n\nTYPES: BEGIN OF ty_flight_map,\n         carrid TYPE sflight-carrid,\n         connid TYPE sflight-connid,\n         fldate TYPE sflight-fldate,\n       END OF ty_flight_map.\n\nDATA: lt_conn       TYPE TABLE OF spfli,\n      lt_flight_map TYPE HASHED TABLE OF ty_flight_map\n                    WITH UNIQUE KEY carrid connid.\n\nSELECT * FROM spfli INTO TABLE lt_conn.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights_small).\n\nLOOP AT lt_flights_small INTO DATA(ls_flight).\n  INSERT ls_flight INTO TABLE lt_flight_map.\nENDLOOP.\n\nLOOP AT lt_conn INTO DATA(ls_conn).\n\n  READ TABLE lt_flight_map INTO DATA(ls_match)\n    WITH KEY carrid = ls_conn-carrid\n             connid = ls_conn-connid.\n\n  IF sy-subrc = 0.\n    WRITE: \/ ls_conn-carrid, ls_conn-connid, ls_match-fldate.\n  ENDIF.\n\nENDLOOP.<\/code><\/pre>\n\n\n\n
Die CPU-Zeit konnte so um \u00fcber 71 Prozent reduziert werden.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 5: Modularisierung von Logik<\/h2>\n\n\n\n
Wir pr\u00fcften die Auswirkungen von gut strukturiertem Code im Detail. Eine direkt im Programm ausgef\u00fchrte Logik l\u00e4uft linear ab.<\/p>\n\n\n\n
Ineffizienter Code (Inline):<\/strong><\/p>\n\n\n\n
REPORT zthesis_no_function.\n\nDATA: lv_sum TYPE i VALUE 0,\n      lv_i   TYPE i.\n\n\" Calculate the sum of the first 10,000 numbers\nDO 10000 TIMES.\n  lv_sum = lv_sum + sy-index.\nENDDO.\n\nWRITE: \/ 'Sum of first 10,000 numbers:', lv_sum.<\/code><\/pre>\n\n\n\n
Wir lagerten diese Rechenlogik anschlie\u00dfend in einen eigenen Funktionsbaustein aus. Das erzeugt minimale Strukturkosten im System.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_with_function.\n\nDATA: lv_result TYPE i.\n\nCALL FUNCTION 'ZTHESIS_CALC_SUM'\n  EXPORTING\n    p_limit = 10000\n  IMPORTING\n    p_sum   = lv_result.\n\nWRITE: \/ 'Sum of first 10,000 numbers (Function Module):', lv_result.<\/code><\/pre>\n\n\n\n
Der zugeh\u00f6rige Funktionsbaustein:<\/strong><\/p>\n\n\n\n
FUNCTION zthesis_calc_sum.\n\n  DATA lv_index TYPE i.\n\n  p_sum = 0.\n\n  DO p_limit TIMES.\n    lv_index = sy-index.\n    p_sum = p_sum + lv_index.\n  ENDDO.\n\nENDFUNCTION.<\/code><\/pre>\n\n\n\n
Die modulare Version lieferte praktisch identische Leistungswerte. Der gro\u00dfe Gewinn liegt hier in der besseren Wartbarkeit f\u00fcr k\u00fcnftige Anpassungen.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 6: Prozedural vs. Objektorientiert<\/h2>\n\n\n\n
Wir stellten eine einfache Z\u00e4hlschleife einem objektorientierten, rekursiven Ansatz gegen\u00fcber, um den Ressourcenaufwand f\u00fcr die Objektorientierung zu messen.<\/p>\n\n\n\n
Iterativer Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_factorial_iterative.\n\nSTART-OF-SELECTION.\n\nDATA: lv_number TYPE i VALUE 10,\n      lv_result TYPE i VALUE 1.\n\nDO lv_number TIMES.\n  lv_result = lv_result * sy-index.\nENDDO.\n\nWRITE: \/ 'Iterative factorial (loop) of', lv_number, ':', lv_result.<\/code><\/pre>\n\n\n\n
Objektorientierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_factorial_oop.\n\nCLASS lcl_factorial DEFINITION.\n\n  PUBLIC SECTION.\n\n    METHODS: calculate\n      IMPORTING iv_number TYPE i\n      RETURNING VALUE(rv_result) TYPE i.\n\nENDCLASS.\n\nCLASS lcl_factorial IMPLEMENTATION.\n\n  METHOD calculate.\n\n    IF iv_number <= 1.\n      rv_result = 1.\n    ELSE.\n      rv_result = iv_number * calculate( iv_number - 1 ).\n    ENDIF.\n\n  ENDMETHOD.\n\nENDCLASS.\n\nSTART-OF-SELECTION.\n\nDATA(lo_factorial) = NEW lcl_factorial( ).\n\nDATA(lv_result) = lo_factorial->calculate( 10 ).\n\nWRITE: \/ 'Recursive factorial (OOP) of 10:', lv_result.<\/code><\/pre>\n\n\n\n
Die objektorientierte Variante verbrauchte rund 22 Prozent mehr CPU-Zeit und lohnt sich bei solch simplen Operationen energetisch nicht. Bei gro\u00dfen Architekturen \u00fcberwiegt langfristig aber der Vorteil der Skalierbarkeit.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 7: Vermeidung von “SELECT “<\/h2>\n\n\n\n
Viele Entwicklerinnen und Entwickler nutzen aus Bequemlichkeit den Datenbankbefehl “SELECT *”. Das System l\u00e4dt dabei blind s\u00e4mtliche Spalten einer Tabelle.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_select_star.\n\nSELECT * FROM sflight\n  INTO TABLE @DATA(lt_flights).\n\nLOOP AT lt_flights INTO DATA(ls_flight).\n  WRITE: \/ ls_flight-carrid, ls_flight-connid, ls_flight-fldate.\nENDLOOP.<\/code><\/pre>\n\n\n\n
Wir passten den Code an und fragten nur noch exakt die drei ben\u00f6tigten Spalten explizit ab.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_select_fields.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights_reduced).\n\nLOOP AT lt_flights_reduced INTO DATA(ls_flight).\n  WRITE: \/ ls_flight-carrid, ls_flight-connid, ls_flight-fldate.\nENDLOOP.<\/code><\/pre>\n\n\n\n
Diese minimale Reduzierung sparte \u00fcber 73 Prozent des abgerufenen Datenvolumens ein.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 8: \u00dcbersichtlicher Kontrollfluss<\/h2>\n\n\n\n
Sauberer Code ben\u00f6tigt einen klaren und vorhersehbaren Ablauf. Wir analysierten eine Schleife mit vielen verteilten Abbruchbedingungen.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_control_flow.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights).\n\nDATA(lv_found) = abap_false.\n\nLOOP AT lt_flights INTO DATA(ls_flight).\n\n  IF ls_flight-carrid IS INITIAL.\n    CONTINUE.\n  ENDIF.\n\n  IF ls_flight-connid IS INITIAL.\n    CONTINUE.\n  ENDIF.\n\n  IF ls_flight-fldate IS INITIAL.\n    CONTINUE.\n  ENDIF.\n\n  IF ls_flight-carrid = 'XX'.\n    CONTINUE.\n  ELSEIF ls_flight-carrid = 'YY'.\n    CONTINUE.\n  ENDIF.\n\n  IF ls_flight-connid = '9999'.\n    lv_found = abap_true.\n    EXIT.\n  ENDIF.\n\n  WRITE: \/ ls_flight-carrid, ls_flight-connid, ls_flight-fldate.\n\nENDLOOP.\n\nIF lv_found = abap_true.\n  WRITE: \/ 'Special connection found.'.\nENDIF.<\/code><\/pre>\n\n\n\n
Als Optimierung fassten wir die vielen Spr\u00fcnge in einer einzigen, sauberen Kontrollabfrage zusammen.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_control_flow.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights).\n\nDATA(lv_found) = abap_false.\n\nLOOP AT lt_flights INTO DATA(ls_flight).\n\n  IF ls_flight-carrid IS INITIAL\n     OR ls_flight-connid IS INITIAL\n     OR ls_flight-fldate IS INITIAL\n     OR ls_flight-carrid = 'XX'\n     OR ls_flight-carrid = 'YY'.\n\n    CONTINUE.\n\n  ENDIF.\n\n  IF ls_flight-connid = '9999'.\n    lv_found = abap_true.\n    EXIT.\n  ENDIF.\n\n  WRITE: \/ ls_flight-carrid, ls_flight-connid, ls_flight-fldate.\n\nENDLOOP.\n\nIF lv_found = abap_true.\n  WRITE: \/ 'Special connection found.'.\nENDIF.<\/code><\/pre>\n\n\n\n
Die Laufzeit ver\u00e4nderte sich durch diese Ma\u00dfnahme kaum. Der Code ist nun aber wesentlich lesbarer und leichter zu verstehen.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fall 9: Unn\u00f6tige Speicherbelegung reduzieren<\/h2>\n\n\n\n
Manche Programme kopieren gro\u00dfe Datentabellen mehrfach im Arbeitsspeicher. Sie bauen zudem riesige Textpuffer auf.<\/p>\n\n\n\n
Ineffizienter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_ineff_memory.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights).\n\nDATA(lt_copy1) = lt_flights.\nDATA(lt_copy2) = lt_copy1.\n\nDATA lv_buffer TYPE string.\n\nLOOP AT lt_copy2 INTO DATA(ls_flight).\n\n  CONCATENATE lv_buffer\n              ls_flight-carrid\n              ls_flight-connid\n              ls_flight-fldate\n    INTO lv_buffer\n    SEPARATED BY space.\n\nENDLOOP.\n\nWRITE: \/ lines( lt_copy2 ).<\/code><\/pre>\n\n\n\n
Wir verarbeiteten die Originaldaten in der optimierten Version direkt und verzichteten auf unn\u00f6tige Zwischenkopien.<\/p>\n\n\n\n
Optimierter Code:<\/strong><\/p>\n\n\n\n
REPORT zthesis_opt_memory.\n\nSELECT carrid, connid, fldate\n  FROM sflight\n  INTO TABLE @DATA(lt_flights).\n\nDATA lv_count TYPE i.\n\nlv_count = 0.\n\nLOOP AT lt_flights INTO DATA(ls_flight).\n  lv_count = lv_count + 1.\nENDLOOP.\n\nWRITE: \/ lv_count.<\/code><\/pre>\n\n\n\n
Die CPU-Zeit fiel durch diesen direkten Zugriff um \u00fcber 33 Prozent.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\u00dcbersicht \u00fcber die Einsparungen<\/h2>\n\n\n\n
Die Ergebnisse der Optimierungsexperimente sind teilweise deutlich. Der Verzicht auf Datenbankabfragen in Schleifen senkte die Datenbankzeit um nahezu 99 Prozent. Die CPU-Zeit fiel bei diesem speziellen Test um fast 94 Prozent.<\/p>\n\n\n\n
Das Filtern per \u201eWHERE\u201c-Bedingung reduzierte die abgerufene Datenmenge am Server um \u00fcber 73 Prozent. Auch der Verzicht auf das bequeme \u201eSELECT *\u201c sparte mehr als 73 Prozent der angeforderten Daten ein. Clevere Hashed Tables senkten die CPU-Last beim Vergleichen von Tabellen um beachtliche 71 Prozent.<\/p>\n\n\n\n
\u00dcber alle neun untersuchten F\u00e4lle hinweg reduzierte sich die CPU-Zeit meistens um beachtliche 20 bis 90 Prozent. Die Datenbankzeiten schrumpften ebenfalls massiv um 30 bis fast 99 Prozent. Eine vollst\u00e4ndige \u00dcbersicht zeigt Tabelle 1.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fazit<\/h2>\n\n\n\n
Green Abap ist noch wenig beachtet, aber es ist eine handfeste Strategie f\u00fcr eine weitaus bessere Softwarearchitektur. Optimierter Code senkt den Stromverbrauch eines Systems drastisch. Er entlastet die Hardware, senkt im Unternehmen Energiekosten und ist gut f\u00fcr die Umwelt. Entwicklerteams m\u00fcssen die eine oder andere alte Gewohnheit ablegen. Datenbankabfragen geh\u00f6ren strikt geb\u00fcndelt und \u00fcbertragene Datenmengen m\u00fcssen gezielt klein gehalten werden. Tools wie der SAP Code Inspector helfen bei der systematischen Umsetzung.<\/p>\n\n\n\n
Seit Einf\u00fchrung der Hana-Datenbanktechnologie propagiert SAP ohnehin den Code-Pushdown, also das systematische Auslagern von Rechenaufgaben in die Datenbankebene. Nachhaltiges Programmieren verbindet technische Exzellenz mit wichtigem Klimaschutz. Jeder optimierte Codeblock leistet so einen sp\u00fcrbaren Beitrag zu einer gr\u00fcneren Informationstechnologie.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\"\"
Tabelle 1: \u00dcbersicht der Einsparungen der verschiedenen Kennzahlen<\/em><\/figcaption><\/figure>\n","protected":false},"excerpt":{"rendered":"
Software verbraucht Strom. Besonders in riesigen SAP-Systemen summieren sich ineffiziente Codezeilen zu gigantischen Energieverschwendern. Das Konzept \u201eGreen Abap\u201c zeigt konkrete Wege zu einer nachhaltigen und gleichzeitig performanten Systemlandschaft auf.<\/p>\n","protected":false},"author":5881,"featured_media":166899,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5,45071],"tags":[453,45244,45240,45246,45237,45249,45238,45245,45241,45239,65,38402,45248,45242,45250,236,45247,5959,45243,953],"coauthors":[45234,45236,45235],"class_list":["post-166898","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","category-mag-26-10","tag-abap","tag-clean-code","tag-code-pushdown","tag-code-optimierung","tag-cpu-zeit","tag-datenbankoptimierung","tag-datenbankperformance","tag-energieeffizienz","tag-green-abap","tag-green-it","tag-hana","tag-nachhaltigkeit","tag-performance-optimierung","tag-programmierung","tag-ressourceneffizienz","tag-sap","tag-sap-code-inspector","tag-sap-s4-hana","tag-softwarearchitektur","tag-softwareentwicklung","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-400x180.jpg",400,180,true],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-768x346.jpg",768,346,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-100x45.jpg",100,45,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-480x216.jpg",480,216,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-640x288.jpg",640,288,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-720x324.jpg",720,324,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-960x432.jpg",960,432,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-18x8.jpg",18,8,true],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku.jpg",1000,450,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-600x270.jpg",600,270,true],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-600x450.jpg",600,450,true],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2026\/09\/2610_it_rku-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"
Software verbraucht Strom. Besonders in riesigen SAP-Systemen summieren sich ineffiziente Codezeilen zu gigantischen Energieverschwendern. Das Konzept \u201eGreen Abap\u201c zeigt konkrete Wege zu einer nachhaltigen und gleichzeitig performanten Systemlandschaft auf.<\/p>\n","category_list_v2":"IT-Management<\/a>, MAG 26-10<\/a>","author_info_v2":{"name":"Sven Treutler, RKU","url":"https:\/\/e3mag.com\/de\/author\/sven-treutler\/"},"comments_num_v2":"0 comments","_links":{"self":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/166898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/users\/5881"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/comments?post=166898"}],"version-history":[{"count":2,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/166898\/revisions"}],"predecessor-version":[{"id":166925,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/166898\/revisions\/166925"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media\/166899"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media?parent=166898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/categories?post=166898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/tags?post=166898"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/coauthors?post=166898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}