Funktionscode in Dynpro auslösen nach AMC, aRFC oder ähnlichem
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi.
Ich brauch mal wieder ein wenig Hilfe.
Gegeben sei eine SAPgui Applikation die eine UI5 Applikation in einem CL_GUI_HTML_VIEWER eingebunden hat. Aus diversen Gründen, auf die ich hier nicht näher eingehen möchte, ist es leider nicht anders umsetzbar.
Nun möchte ich beim Auslösen einer Funktion in der UI5 Applikaton Daten zur Weiterverarbeitung an die SAPgui Applikation schicken. Diese Weiterverarbeitung muss im SAPgui erfolgen, weil diverse ältere Programme mit Dynpros usw. ausgeführt werden müssen, die sich nicht so leicht in der WebGui-Darstellung ausführen lassen (Verwendung von CL_GUI_CFW, CL_GUI_FRONTEND_SERVICES usw.).
Das Senden der Daten habe ich über einen AMC gelöst. Das funktioniert auch soweit und die Daten landen korrekt in der SAPgui Applikation, aber dort liegen sie nur herum bis der Benutzer einen Funktionscode auslöst. Ich möchte nun irgendwie die Verabeitung "triggern". Die ganzen üblichen Verdächtigen habe ich schon durchprobiert:
Einen Vorschlag aus dem Netz, die AMC Verarbeitung in einen RFC Aufruf zu verpacken hab ich auch ausprobiert aber mit demselben Ergebnis.
https://stackoverflow.com/questions/484 ... p-sessions
Weiß jemand noch andere Möglichkeiten um einen Funktionscode im Dynpro bzw. SAPgui (call 'RFCControl' vielleicht) zu triggern? Oder wie ich mir eventuell den CL_GUI_HTML_VIEWER (z.B: SAPEVENT) im Zusammenspiel mit einer UI5 Applikation zu nutze machen kann?
Ich brauch mal wieder ein wenig Hilfe.
Gegeben sei eine SAPgui Applikation die eine UI5 Applikation in einem CL_GUI_HTML_VIEWER eingebunden hat. Aus diversen Gründen, auf die ich hier nicht näher eingehen möchte, ist es leider nicht anders umsetzbar.
Nun möchte ich beim Auslösen einer Funktion in der UI5 Applikaton Daten zur Weiterverarbeitung an die SAPgui Applikation schicken. Diese Weiterverarbeitung muss im SAPgui erfolgen, weil diverse ältere Programme mit Dynpros usw. ausgeführt werden müssen, die sich nicht so leicht in der WebGui-Darstellung ausführen lassen (Verwendung von CL_GUI_CFW, CL_GUI_FRONTEND_SERVICES usw.).
Das Senden der Daten habe ich über einen AMC gelöst. Das funktioniert auch soweit und die Daten landen korrekt in der SAPgui Applikation, aber dort liegen sie nur herum bis der Benutzer einen Funktionscode auslöst. Ich möchte nun irgendwie die Verabeitung "triggern". Die ganzen üblichen Verdächtigen habe ich schon durchprobiert:
- CALL FUNCTION 'SAPGUI_SET_FUNCTIONCODE' --> Funktioniert nicht
- CL_GUI_CFW=>SET_NEW_OK_CODE --> Funktioniert nicht
- SET USER-COMMAND --> Funktioniert nur im List-Prozessor
- CALL 'DYNP_OKCODE_SET' --> Funktioniert nicht
- SUBMIT --> Kurzdump
Einen Vorschlag aus dem Netz, die AMC Verarbeitung in einen RFC Aufruf zu verpacken hab ich auch ausprobiert aber mit demselben Ergebnis.
https://stackoverflow.com/questions/484 ... p-sessions
Weiß jemand noch andere Möglichkeiten um einen Funktionscode im Dynpro bzw. SAPgui (call 'RFCControl' vielleicht) zu triggern? Oder wie ich mir eventuell den CL_GUI_HTML_VIEWER (z.B: SAPEVENT) im Zusammenspiel mit einer UI5 Applikation zu nutze machen kann?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Hast du mal "WAIT FOR MESSAGING-CHANNELS" probiert? Habe das noch nie eingesetzt, aber dein Anwendungsfall hört sich prädestiniert hierfür an.
Alternativ könntest du im GUI-Programm auch eine cl_gui_timer-Instanz von Zeit zu Zeit nachschauen lassen, ob sich was ergeben hat. In dieser solltest du in der Lage sein mit CL_GUI_CFW=>SET_NEW_OK_CODE weiterzukommen, da dieser im GUI Workprozess die Aktion triggert.
Alternativ könntest du im GUI-Programm auch eine cl_gui_timer-Instanz von Zeit zu Zeit nachschauen lassen, ob sich was ergeben hat. In dieser solltest du in der Lage sein mit CL_GUI_CFW=>SET_NEW_OK_CODE weiterzukommen, da dieser im GUI Workprozess die Aktion triggert.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
WAIT FOR MESSAGING CHANNELS kann ich in der SAPgui Applikation leider nicht machen, weil dann das Programm "hängen" würde. Ich hab das wie auf Stackoverflow beschrieben im einen asynchronen RFC eingebaut, aber auch das hat nicht geholfen. Das Problem scheint der "state-less" Zustand des Programms (nach AMC oder aRFC) am Applikationsserver zu sein von dem aus keine GUI-Kommunikation getriggert werden kann.
Obwohl es, wie schon gesagt, beim List-Prozessor dann trotzdem irgendwie geht.
Obwohl es, wie schon gesagt, beim List-Prozessor dann trotzdem irgendwie geht.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn jemand probieren möchte, hier mein Testcode:
Das Programm benötigt zusätzlich noch einen GUI-Status AMC_TEST mit den Funktionscodes REFRESH und BACK.
Den Message-Channel ZAMC_TEST müsste man über die SE80 noch anlegen und die Programm(teil)e berechtigen.
Code: Alles auswählen.
FUNCTION-POOL zamc_test.
DATA:
gd_message TYPE string.
CLASS lcl_amc_test_text DEFINITION FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_amc_message_receiver_text .
ENDCLASS.
CLASS lcl_amc_test_text IMPLEMENTATION.
METHOD if_amc_message_receiver_text~receive.
gd_message = i_message.
ENDMETHOD.
ENDCLASS.Code: Alles auswählen.
FUNCTION zamc_test_receiver.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" EXPORTING
*" VALUE(ED_MESSAGE) TYPE STRING
*" VALUE(ED_EXCEPTION) TYPE STRING
*"----------------------------------------------------------------------
DATA:
lr_consumer TYPE REF TO if_amc_message_consumer,
lr_receiver_text TYPE REF TO lcl_amc_test_text.
CLEAR ed_message.
TRY.
lr_consumer = cl_amc_channel_manager=>create_message_consumer( i_application_id = 'ZAMC_TEST'
i_channel_id = '/ping' ).
lr_receiver_text = NEW #( ).
" start of message delivery
lr_consumer->start_message_delivery( i_receiver = lr_receiver_text ).
CATCH cx_root INTO DATA(lx_root).
ed_exception = lx_root->get_text( ).
ENDTRY.
WAIT FOR MESSAGING CHANNELS UNTIL gd_message IS NOT INITIAL.
ed_message = gd_message.
ENDFUNCTION.Code: Alles auswählen.
REPORT zamc_test_receiver.
DATA:
gd_task TYPE tw_task_id,
gd_message TYPE string.
PARAMETERS: pa_lis TYPE abap_bool RADIOBUTTON GROUP 1 DEFAULT 'X'.
PARAMETERS: pa_fub TYPE abap_bool RADIOBUTTON GROUP 1.
PARAMETERS: pa_cfw TYPE abap_bool RADIOBUTTON GROUP 1.
PARAMETERS: pa_dyn TYPE abap_bool RADIOBUTTON GROUP 1.
PARAMETERS: pa_sub TYPE abap_bool RADIOBUTTON GROUP 1.
START-OF-SELECTION.
SET PF-STATUS 'AMC_TEST'.
WRITE: 'Preparing Test Environment'.
SET USER-COMMAND 'REFRESH'.
AT USER-COMMAND.
CASE sy-ucomm.
WHEN 'REFRESH'.
PERFORM refresh_message.
ENDCASE.
FORM refresh_message.
DATA:
ld_continue TYPE abap_bool.
PERFORM cancel_receiver.
PERFORM register_receiver CHANGING ld_continue.
IF ld_continue EQ abap_true.
CLEAR sy-lsind.
WRITE: 'Message:', gd_message.
ELSE.
LEAVE PROGRAM.
ENDIF.
ENDFORM.
FORM register_receiver CHANGING cd_continue.
DATA:
ld_message TYPE text255.
CLEAR cd_continue.
gd_task = 'TEST_TASK'.
CALL FUNCTION 'ZAMC_TEST_RECEIVER'
DESTINATION 'NONE'
STARTING NEW TASK gd_task
PERFORMING receive_message ON END OF TASK
EXCEPTIONS
system_failure = 1 MESSAGE ld_message
communication_failure = 2 MESSAGE ld_message
resource_failure = 3
OTHERS = 4.
* TO-DO: Propper RFC-Error-Handling
cd_continue = abap_true.
ENDFORM.
FORM cancel_receiver.
CALL FUNCTION 'RFC_CONNECTION_CANCEL'
EXPORTING
taskname = gd_task
close_connection = abap_true
EXCEPTIONS
task_not_open = 1
OTHERS = 2.
CLEAR gd_task.
ENDFORM.
FORM receive_message USING ud_task TYPE clike.
DATA:
ld_exception TYPE string,
ld_result TYPE string,
ld_message TYPE text255.
CLEAR gd_task.
RECEIVE RESULTS FROM FUNCTION 'ZAMC_TEST_RECEIVER'
IMPORTING
ed_message = ld_result
ed_exception = ld_exception
EXCEPTIONS
system_failure = 1 MESSAGE ld_message
communication_failure = 2 MESSAGE ld_message
OTHERS = 3.
* TO-DO: Propper RFC-Error-Handling
IF ld_exception IS NOT INITIAL.
MESSAGE |EXCEPTION: { ld_exception }| TYPE 'S' DISPLAY LIKE 'E'.
ELSE.
gd_message = ld_result.
PERFORM output_message.
ENDIF.
ENDFORM.
FORM output_message.
DATA:
ld_fcode TYPE syucomm.
CASE abap_true.
WHEN pa_fub.
CALL FUNCTION 'SAPGUI_SET_FUNCTIONCODE'
EXPORTING
functioncode = 'REFRESH'
EXCEPTIONS
function_not_supported = 1
OTHERS = 2.
WHEN pa_cfw.
cl_gui_cfw=>set_new_ok_code( new_code = 'REFRESH' ).
cl_gui_cfw=>flush( ).
WHEN pa_lis.
SET USER-COMMAND 'REFRESH'.
WHEN pa_sub.
SUBMIT zamc_test_message
WITH pa_msg EQ gd_message
AND RETURN.
WHEN pa_dyn.
ld_fcode = 'REFRESH'.
CALL 'DYNP_OKCODE_SET' ID 'FCODE' FIELD ld_fcode.
ENDCASE.
ENDFORM.Code: Alles auswählen.
REPORT zamc_test_sender.
PARAMETERS pa_msg TYPE string LOWER CASE.
START-OF-SELECTION.
PERFORM send_message.
FORM send_message.
TRY.
CASE TYPE OF cl_amc_channel_manager=>create_message_producer( i_application_id = 'ZAMC_TEST'
i_channel_id = '/ping' ).
WHEN TYPE if_amc_message_producer_text INTO DATA(lr_producer_text).
lr_producer_text->send( i_message = pa_msg ).
ENDCASE.
CATCH cx_root INTO DATA(lx_root).
MESSAGE lx_root TYPE 'E'.
ENDTRY.
ENDFORM.Code: Alles auswählen.
REPORT zamc_test_message.
PARAMETERS: pa_msg TYPE string.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Und das mit dem cl_gui_timer geht auch nicht?
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Und wie wäre es mit einem DO... times. WAIT FOR MESSAGNING CHANNELS up to x seconds. ENDDO.a-dead-trousers hat geschrieben: ↑12.11.2024 14:59WAIT FOR MESSAGING CHANNELS kann ich in der SAPgui Applikation leider nicht machen, weil dann das Programm "hängen" würde.
Damit "hängt" das Programm nur so lange du möchtest.
Vielleicht damit:
Code: Alles auswählen.
CALL FUNCTION func STARTING NEW TASK task
[{CALLING meth}|{PERFORMING subr} ON END OF TASK].Mit diesem Zusatz kann entweder eine Methode meth oder ein Unterprogramm subr als Callback-Routine angegeben werden, die zur Ausführung registriert wird, nachdem der asynchron aufgerufene Funktionsbaustein beendet wurde.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Danke, aber das hab ich schon gemacht. Siehe Coding.tar hat geschrieben: ↑14.11.2024 05:55Vielleicht damit:
Code: Alles auswählen.
CALL FUNCTION func STARTING NEW TASK task [{CALLING meth}|{PERFORMING subr} ON END OF TASK].Mit diesem Zusatz kann entweder eine Methode meth oder ein Unterprogramm subr als Callback-Routine angegeben werden, die zur Ausführung registriert wird, nachdem der asynchron aufgerufene Funktionsbaustein beendet wurde.
Aber es "hängt" trotzdem.black_adept hat geschrieben: ↑13.11.2024 15:38Und wie wäre es mit einem DO... times. WAIT FOR MESSAGNING CHANNELS up to x seconds. ENDDO.a-dead-trousers hat geschrieben: ↑12.11.2024 14:59WAIT FOR MESSAGING CHANNELS kann ich in der SAPgui Applikation leider nicht machen, weil dann das Programm "hängen" würde.
Damit "hängt" das Programm nur so lange du möchtest.
Das ist IMHO auch nervig, wenn die Applikation immer wieder mal "nicht reagiert" (PAI/PBO Lauf) und dann wenn sie reagieren sollte, verspätet reagiert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
So wie es aussieht, kann der SAPgui nicht aktiv vom Applikationsserver getriggert werden (außer im Listprozessor).
Ich hab es dann auch noch mit dem SAPEVENT des CL_GUI_HTML_VIEWER versucht (Daten via. AMC schicken und dann SAPEVENT:DUMMY auslösen) aber das scheint mit "externen" Ressourcen nicht zu funktionierten (Protokollhandler SAPEVENT nicht bekannt).
Mit den Anwendern haben wir uns nun auf folgenden Ablauf geeinigt:
Beim Verlassen der SAPgui-Applikation werden die Arbeitsschritte aus der WEBgui-Applikation ausgelöst. Das passt am Besten in ihren Arbeitsfluss ohne unerwünschte Seiteneffekte.
Ich lass den Punkt mal als ungelöst offen, weil ich trotzdem noch herausfinden möchte warum die "Aktualisierung" beim Listprozessor funktioniert, während es bei einem Dynpro nicht funktioniert.
Ich hab es dann auch noch mit dem SAPEVENT des CL_GUI_HTML_VIEWER versucht (Daten via. AMC schicken und dann SAPEVENT:DUMMY auslösen) aber das scheint mit "externen" Ressourcen nicht zu funktionierten (Protokollhandler SAPEVENT nicht bekannt).
Mit den Anwendern haben wir uns nun auf folgenden Ablauf geeinigt:
Beim Verlassen der SAPgui-Applikation werden die Arbeitsschritte aus der WEBgui-Applikation ausgelöst. Das passt am Besten in ihren Arbeitsfluss ohne unerwünschte Seiteneffekte.
Ich lass den Punkt mal als ungelöst offen, weil ich trotzdem noch herausfinden möchte warum die "Aktualisierung" beim Listprozessor funktioniert, während es bei einem Dynpro nicht funktioniert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von jan.tschudy (ForumUser / 6 / 1 /
0
)
»
Was mir hier durch den Kopf geht wenn ich das lese wäre die "versteckte" Funktionalität mit der SET/GET-ParameterId SAPGUI_PUSH_CHANNEL zu verwenden.
DATA(dynclass) = `\PROGRAM=CL_AMC_CHANNEL_MANAGER========CP\CLASS=LCL_SAPGUI_CHANNEL_MANAGER`.
CALL METHOD (dynclass)=>create_message_consumer ...
Im Buch ABAP to the Future ist das vollständige Coding unter 14.3 ABAP Push Channels: SAP GUI Example zu finden.
DATA(dynclass) = `\PROGRAM=CL_AMC_CHANNEL_MANAGER========CP\CLASS=LCL_SAPGUI_CHANNEL_MANAGER`.
CALL METHOD (dynclass)=>create_message_consumer ...
Im Buch ABAP to the Future ist das vollständige Coding unter 14.3 ABAP Push Channels: SAP GUI Example zu finden.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Message Channel und Push Channel sind ziemlich ähnlich in ihrer Abarbeitung. Mein Problem liegt eher daran, dass man vom Applikationsserver aus den SAPgui nicht aktiv aus einem "ruhenden" (wartet auf Benutzereingaben) Zustand "aufwecken" kann. Da müsste man zum Beispiel mit SAPEVENT über das HTML-Viewer-Control oder etwas ähnlichem nachhelfen, um die Verarbeitung anzustoßen. Aber genau das scheint die WEBgui Anwendung zu unterbinden bzw. lässt sich das nur sehr umständlich einbinden. Ich hätte eher etwas robustes gesucht, das ich ich direkt nach Empfang der Nachricht ausführen kann um das PAI/PBO (oder von mir aus auch CFW-Flush) auslösen zu können.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Läuft die Dynpro-Oberfläche mit einem Fullscreen-SALV? Weil ich hatte gerade dasselbe Phänomen, dass ich lokal keinen PAI triggern konnte. Es ging dann mit dem FB "SAPGUI_SET_FUNCTIONCODE" (den du ja probiert hattest) und auch erst als ich ihm einen explizit vorhandenen Funktionscode (also keinen Dummy) mitgab.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Nein.
Leider, wie schon gesagt, wird kein Funktionscode bei mir ausgelöst. Der Funktionsbaustein wird in einem "normalen" Aufruf (PAI/PBO bzw, GUICFW-Dispatch) ja nur dafür verwendet direkt an die vorhandene Verarbeitung einen weiteren Funktionscode dranzuhängen. Wenn man in den Funktionsbaustein reinschaut, sieht man, dass dafür ein eigenes Control am Client instanziert wird. Daher funktioniert das sowohl im "stateless" Dispatch durch einen GUI-Event, als auch im PAI/PBO weil das Control von sich aus einen PAI/PBO-Lauf anstößt. Das Ganze läuft dann immer über den Client. Mein Problem ist, dass der SAPgui nach der Verarbeitung auf eine Eingabe durch den Benutzer wartet und es scheinbar keine Möglichkeit außer dem bereits erwähnten SAPEVENT (mit all seinen Problemen) gibt, um ihn wieder "aufzuwecken".
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Kleines Update:
Ich hab nun versucht mit einem Wrapper, bestehend aus einem IFRAME, die WEBgui Seite einzubeten um den SAPEVENT des GUI-Control irgendwie doch nutzbar zu machen. Nur können in diesem Fall die SSO Informationen nicht weitergereicht werden und die Webapplikation bringt die Anmeldemaske hoch. Was ich aber schon vermutet habe, weil es sich um eine andere "Domäne" handelt und der CORS-Mechanismus (oder irgendeine andere Sicherheitsbarriere) im Broswer anschlägt. Somit erklärt sich auch warum ich direkt aus der Webapplikation heraus nicht mit SAPEVENT arbeiten kann, weil das vom GUI-Control nur bei mit LOAD_DATA veröffentlichten URIs "aktiviert" wird.
Ich hab nun versucht mit einem Wrapper, bestehend aus einem IFRAME, die WEBgui Seite einzubeten um den SAPEVENT des GUI-Control irgendwie doch nutzbar zu machen. Nur können in diesem Fall die SSO Informationen nicht weitergereicht werden und die Webapplikation bringt die Anmeldemaske hoch. Was ich aber schon vermutet habe, weil es sich um eine andere "Domäne" handelt und der CORS-Mechanismus (oder irgendeine andere Sicherheitsbarriere) im Broswer anschlägt. Somit erklärt sich auch warum ich direkt aus der Webapplikation heraus nicht mit SAPEVENT arbeiten kann, weil das vom GUI-Control nur bei mit LOAD_DATA veröffentlichten URIs "aktiviert" wird.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
black_adept
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
9
Antw.
Antw.
14334
Views
Views
7
Antw.
Antw.
4596
Views
Views
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.