Enqueue - keine automatische Entsperrung
Hallo zusammen,
ich habe ein kleines Problem, bei dem mir nicht klar ist, ob es überhaupt geht.
Und zwar möchte ich eine Sperre solange setzen (kundeneigenes Sperrobjekt), bis ich sie explizit wieder aufhebe.
Hintergrund ist folgender. Ich möchte per Webservice, ein Objekt sperren und zu einem späteren Zeitpunkt dieses wieder entsperren. Dafür habe ich einen Fuba (Webservice), der nur für das Sperren und Entsperren des Objektes da ist. Mein Problem ist jedoch, dass wenn der Fuba des Webservice durchlaufen wurde, die Sperre automatisch wieder gelöscht wird.
Kann man dies irgendwie verhindern? Die Sperre soll erst dann wieder gelöscht werden, wenn ich dies explizit sage, z.B. durch den Aufrufs des DEQUEUE-Fubas o.ä..
An den Scope-Parametern habe ich auch schon herum experimentiert. Leider ohne Erfolg.
Hat dazu vielleicht jemand eine Idee?
Vielen Dank im Voraus.
Viele Grüße,
Ferum
ich habe ein kleines Problem, bei dem mir nicht klar ist, ob es überhaupt geht.
Und zwar möchte ich eine Sperre solange setzen (kundeneigenes Sperrobjekt), bis ich sie explizit wieder aufhebe.
Hintergrund ist folgender. Ich möchte per Webservice, ein Objekt sperren und zu einem späteren Zeitpunkt dieses wieder entsperren. Dafür habe ich einen Fuba (Webservice), der nur für das Sperren und Entsperren des Objektes da ist. Mein Problem ist jedoch, dass wenn der Fuba des Webservice durchlaufen wurde, die Sperre automatisch wieder gelöscht wird.
Kann man dies irgendwie verhindern? Die Sperre soll erst dann wieder gelöscht werden, wenn ich dies explizit sage, z.B. durch den Aufrufs des DEQUEUE-Fubas o.ä..
An den Scope-Parametern habe ich auch schon herum experimentiert. Leider ohne Erfolg.
Hat dazu vielleicht jemand eine Idee?
Vielen Dank im Voraus.
Viele Grüße,
Ferum
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Tja dafür wirst du dir höchstwahrscheinlich eine eigene Sperrlogik mit einer eigenen Tabelle bauen müssen. Ist ein Eintrag vorhanden, dann ist das Objekt gesperrt.
Die ENQUEUE und DEQUEUE Bausteine von SAP sind an eine SAP Transaktion gebunden und sobald diese beendet wird, werden auch die Sperren wieder aufgehoben. Bei Webservices ist jeder Aufruf grundsätzlich eine eigene Transaktion.
Vergleichbar mit einem normalen HTTP-Server wo auch jeder Seitenaufruf einen neuen Prozess bewirkt. Hier ist es nur mit einem "externen" Session-Mangement (z.B. via PHP) möglich einen Login und weitere Informationen (z.B. Warnkorb) über mehrere Seiten hinweg zu erhalten. Der HTTP-Server (= auch eine Art Webservice) kennt das alles nicht.
Leider kenn ich mich bei den SAP Webservices nicht so genau aus und es ist vielleicht möglich den "Abbau" der Transaktion zu verhindern.
Bei den RFC-Verbindungen kann man das normalerweise einstellen, bzw. man muss explizit den sofortigen Abbau mit RFC_CLOSE auslösen.
Aber ich würde hier doch eher zur eigenen Lösung raten, da man so auch einige andere Probleme umgehen kann:
- Man muss nicht ständig mit dem SAP-System in Verbindung stehen. (Offline-Modus)
- Die Sperren können von unterschiedlichen Usern angelegt / aufgehoben werden.
- Die Timeouts der Verbindung spielen keine Rolle mehr
usw.
lg ADT
Tja dafür wirst du dir höchstwahrscheinlich eine eigene Sperrlogik mit einer eigenen Tabelle bauen müssen. Ist ein Eintrag vorhanden, dann ist das Objekt gesperrt.
Die ENQUEUE und DEQUEUE Bausteine von SAP sind an eine SAP Transaktion gebunden und sobald diese beendet wird, werden auch die Sperren wieder aufgehoben. Bei Webservices ist jeder Aufruf grundsätzlich eine eigene Transaktion.
Vergleichbar mit einem normalen HTTP-Server wo auch jeder Seitenaufruf einen neuen Prozess bewirkt. Hier ist es nur mit einem "externen" Session-Mangement (z.B. via PHP) möglich einen Login und weitere Informationen (z.B. Warnkorb) über mehrere Seiten hinweg zu erhalten. Der HTTP-Server (= auch eine Art Webservice) kennt das alles nicht.
Leider kenn ich mich bei den SAP Webservices nicht so genau aus und es ist vielleicht möglich den "Abbau" der Transaktion zu verhindern.
Bei den RFC-Verbindungen kann man das normalerweise einstellen, bzw. man muss explizit den sofortigen Abbau mit RFC_CLOSE auslösen.
Aber ich würde hier doch eher zur eigenen Lösung raten, da man so auch einige andere Probleme umgehen kann:
- Man muss nicht ständig mit dem SAP-System in Verbindung stehen. (Offline-Modus)
- Die Sperren können von unterschiedlichen Usern angelegt / aufgehoben werden.
- Die Timeouts der Verbindung spielen keine Rolle mehr
usw.
lg ADT
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
Hallo ADT,
Vielen Dank für die Info.
Eine eigene Sperrlogik wäre theoretisch denkbar. Das Sperrobjekt wird jedoch nicht nur im Zusammenhang mit dem Webservice gesperrt, sondern auch durch diverse Transaktionen im SAP-System.
Daher wäre eine eigene Logik schon sehr komplex. Auch bezüglich gleichzeitiger Sperranfragen.
Das mit dem "Abbau" der Transaktion verhinden wäre schon ein denkbarer Weg. Hat da vielleicht jemand ne Idee, wie man das macht?
Ich verarbeitet den Webservice mit einem C#-Programm, im Prinzip wie es im SAP-Buch "SAP-Schnittstellen" im Kapitel 6.6 beschrieben ist.
Vielleicht gibt es ja die Möglichkeit hier das Coding anzupassen.
Gruß,
Ferum
Vielen Dank für die Info.
Eine eigene Sperrlogik wäre theoretisch denkbar. Das Sperrobjekt wird jedoch nicht nur im Zusammenhang mit dem Webservice gesperrt, sondern auch durch diverse Transaktionen im SAP-System.
Daher wäre eine eigene Logik schon sehr komplex. Auch bezüglich gleichzeitiger Sperranfragen.
Das mit dem "Abbau" der Transaktion verhinden wäre schon ein denkbarer Weg. Hat da vielleicht jemand ne Idee, wie man das macht?
Ich verarbeitet den Webservice mit einem C#-Programm, im Prinzip wie es im SAP-Buch "SAP-Schnittstellen" im Kapitel 6.6 beschrieben ist.
Vielleicht gibt es ja die Möglichkeit hier das Coding anzupassen.
Gruß,
Ferum
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Client-seitig (in deinem C# Programm) kann man da vermutlich wenig machen.
Bei einer normalen SAP-Transaktion die über RFC abläuft ist meist ein GUI oder Batch-Prozess beteiligt der für die Dauer der Verarbeitung, auch über mehrer Bildschirmmasken hinweg, die Verbindung aufrecht erhält. Das denke ich ist der entscheidende Punkt.
Der Server (SAP) muss beim ersten Verbindungsaufbau eine Session-ID (z.B. via Cookie) zurückmelden und diese musst du dann bei allen weiteren Anfragen ebenfalls mitschicken. Das ist das einzige was man hier am Client eigentlich noch machen muss. SAP seitig muss dann noch gewährleistet sein, dass diese "Session" einer Transaktion entspricht welche dann den Status eines Sperrobjektes aufrecht erhalten kann. In wie weit die SAP Webservices dies bereits unterstützen kann ich nicht sagen. Vielleicht schaust du mal in der SAP-seitigen Einstellung des Webservice nach. Möglich dass da irgendwo nur ein Häckchen z.B. "SAP-Transaktion aufrechterhalten" zu setzen ist.
Ein anderer Tipp wäre noch nach zu schauen, welche Daten SAP über den Webservice zurückmeldet (HTTP-Header usw.). Vielleicht steht da ja bereits eine Session ID dabei.
lg ADT
Bei einer normalen SAP-Transaktion die über RFC abläuft ist meist ein GUI oder Batch-Prozess beteiligt der für die Dauer der Verarbeitung, auch über mehrer Bildschirmmasken hinweg, die Verbindung aufrecht erhält. Das denke ich ist der entscheidende Punkt.
Der Server (SAP) muss beim ersten Verbindungsaufbau eine Session-ID (z.B. via Cookie) zurückmelden und diese musst du dann bei allen weiteren Anfragen ebenfalls mitschicken. Das ist das einzige was man hier am Client eigentlich noch machen muss. SAP seitig muss dann noch gewährleistet sein, dass diese "Session" einer Transaktion entspricht welche dann den Status eines Sperrobjektes aufrecht erhalten kann. In wie weit die SAP Webservices dies bereits unterstützen kann ich nicht sagen. Vielleicht schaust du mal in der SAP-seitigen Einstellung des Webservice nach. Möglich dass da irgendwo nur ein Häckchen z.B. "SAP-Transaktion aufrechterhalten" zu setzen ist.
Ein anderer Tipp wäre noch nach zu schauen, welche Daten SAP über den Webservice zurückmeldet (HTTP-Header usw.). Vielleicht steht da ja bereits eine Session ID dabei.
lg ADT
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
)
»
hi!
Hab heute noch mal mit meinem Kollegen gequatscht der sich da besser auskennt und es geht definitiv nicht, dass man bei Webservices die Sperrobjekte über mehrere Aufrufe hinweg beibehalten kann. Das kann man wirklich nur mittels eigener Sperrlogik umsetzen.
Das einzige was geht ist, dass man bei einem Webservice mehrere Methoden definiert z.B. ENQUEUE -> EXECUTE -> DEQUEUE und diese auch direkt hintereinander aufruft, quasi in einem Aufruf verpackt.
lg ADT
Hab heute noch mal mit meinem Kollegen gequatscht der sich da besser auskennt und es geht definitiv nicht, dass man bei Webservices die Sperrobjekte über mehrere Aufrufe hinweg beibehalten kann. Das kann man wirklich nur mittels eigener Sperrlogik umsetzen.
Das einzige was geht ist, dass man bei einem Webservice mehrere Methoden definiert z.B. ENQUEUE -> EXECUTE -> DEQUEUE und diese auch direkt hintereinander aufruft, quasi in einem Aufruf verpackt.
lg ADT
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
Hi ADT,
Vielen Dank für die Info. Auch wenn es blöd ist, dass es nicht so einfach klappt.
Mit einger eigenen Sperrlogik meinst du aber wohl auch eigene Sperrtabelle usw.
Ein Zugriff auf die Sperrtabelle an sich, ist wahrscheinlich nicht möglich oder?
Gruß,
Ferum
Vielen Dank für die Info. Auch wenn es blöd ist, dass es nicht so einfach klappt.
Mit einger eigenen Sperrlogik meinst du aber wohl auch eigene Sperrtabelle usw.
Ein Zugriff auf die Sperrtabelle an sich, ist wahrscheinlich nicht möglich oder?
Gruß,
Ferum
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
ne.
Bei der "Sperrtabelle" in SAP hadelt es sich nicht um eine Tabelle im eigentlichen Sinn, sondern wird auf der Zentralinstanz (App.Server) des SAP-Systems eine Liste im Speicher geführt wo je SAP-Tabelle Einträge mit den ENQUEUE/DEQUEUE-Bausteinen angelegt/entfernt werden können.
Du brauchst eine echte DB-Tabelle in der du Daten ablegen kannst und die somit auch über mehrer Transaktionen/Aufrufen erhalten bleiben.
Alternativ könnte ich mir auch noch eine Lösung über das Dateisystem vorstellen. Man legt je zu sperrenden Eintrag eine Datei in einem bestimmten Verzeichnis ab. Das ist aber nur sinnvoll, wenn es sich nur um wenige Daten handelt die gesperrt werden sollen und auch nur ein Appl.Server im Einsatz ist, weil die Daten ja nur lokal auf dem jeweiligen Appl.Server abgelegt werden. Außerdem muss man evtl. noch die Berechtigungen der Benutzer anpassen.
Vorteil ist eben, dass man die DB "schont"
Alle anderen SAP Lösungen wie MEMORY oder Set-/Get-Parameter sind leider abhängig von der Transaktion.
lg ADT
Bei der "Sperrtabelle" in SAP hadelt es sich nicht um eine Tabelle im eigentlichen Sinn, sondern wird auf der Zentralinstanz (App.Server) des SAP-Systems eine Liste im Speicher geführt wo je SAP-Tabelle Einträge mit den ENQUEUE/DEQUEUE-Bausteinen angelegt/entfernt werden können.
Du brauchst eine echte DB-Tabelle in der du Daten ablegen kannst und die somit auch über mehrer Transaktionen/Aufrufen erhalten bleiben.
Alternativ könnte ich mir auch noch eine Lösung über das Dateisystem vorstellen. Man legt je zu sperrenden Eintrag eine Datei in einem bestimmten Verzeichnis ab. Das ist aber nur sinnvoll, wenn es sich nur um wenige Daten handelt die gesperrt werden sollen und auch nur ein Appl.Server im Einsatz ist, weil die Daten ja nur lokal auf dem jeweiligen Appl.Server abgelegt werden. Außerdem muss man evtl. noch die Berechtigungen der Benutzer anpassen.
Vorteil ist eben, dass man die DB "schont"
Alle anderen SAP Lösungen wie MEMORY oder Set-/Get-Parameter sind leider abhängig von der Transaktion.
lg ADT
Zuletzt geändert von a-dead-trousers am 07.01.2013 11:23, insgesamt 1-mal geändert.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Ferum
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 / 4089 / 127 /
940
)
»
Hallo Ferum,Ferum hat geschrieben:Ein Zugriff auf die Sperrtabelle an sich, ist wahrscheinlich nicht möglich oder?
das Problem ist, dass SAP herausfinden können muss, ob ein sperrender Prozess noch aktiv ist.
Bei Hintergrundverarbeitung ist das recht einfach, da ja ein aktiver Job hierzu existieren muss. Bei Onlinezugriff via SAPGUI kann das System die Gui anpingen, ob sie noch aktiv ist. Falls nicht kann davon ausgegangen werden, dass der auslösende User keine Kontrolle mehr über die Sperre hat und diese kann abgebaut werden.
Bei Webzugriff hingegen ist genau dies nicht mehr der Fall - es gibt einfach keine Möglichkeit zu testen ob der User seinen Browser einfach zugemacht hat oder nicht.
Somit gilt auch die Aussage von adt.
Wenn du nun die Standardsperrlogik weiterverwenden möchtest müsstest du schon einen Ansatz wählen, der SAP erlaubt zu schauen, ob die Sperre noch benötigt wird.
Die einfachste Lösung die mir als Nicht-Webdynproentwickler so einfällt wäre, dass du im Fall einer benötigten Sperre einen Job im Hintergrund startet, der deine Sperre aufrechterhält - solange bis du diese gezielt aufhebst oder mit einem voreingestellten Timeout.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Ferum
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Äußerst Kreativ.black_adept hat geschrieben:Die einfachste Lösung die mir als Nicht-Webdynproentwickler so einfällt wäre, dass du im Fall einer benötigten Sperre einen Job im Hintergrund startet, der deine Sperre aufrechterhält - solange bis du diese gezielt aufhebst oder mit einem voreingestellten Timeout.
Laut meinem Kollegen, der auch schon öfters dieses Problem hatte, wäre das eine sehr brauchbare und vor allem mit ein wenig "dynamischer Programmierung" sogar eine universell einsetzbare Lösung.
lg ADT
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
Hi,
bzgl. der Idee mit dem Job:
Vielleicht kannst Du das ja mit einem Event triggern?!
Jobs können ja auch über Events gestartet werden. Vielleicht kannst Du den Job dann auch mit einem anderen Ereignis abbrechen?!
Gruß und viel Erfolg.
bzgl. der Idee mit dem Job:
Vielleicht kannst Du das ja mit einem Event triggern?!
Jobs können ja auch über Events gestartet werden. Vielleicht kannst Du den Job dann auch mit einem anderen Ereignis abbrechen?!
Gruß und viel Erfolg.
Hallo zusammen,
Vielen Dank für die guten Ideen.
Ich habe es inzwischen mit dem Job gelöst.
Ich rufe einen eigenen RFC-FM auf der zuerst kontrolliert ob die Sperre schon da ist. Wenn nicht startet er einen Job mit einem Z-Programm, welches die Sperre anlegt und in einer Endlosschleife kontrolliert ob die Sperre noch vorhanden ist. Ist die Sperre nicht mehr vorhanden, wird das Programm beendet.
Zur Kontrolle nutze ich den ENQUEUE_READ, da der Standard-ENQUEUE-FM immer gleiche ne Sperre setzt, wenn er keine findet.
Die Sperre kann ich mit einem RFC-FM aufheben. Hier konnte ich jedoch nicht den Standard-DEQUEUE-FM nutzen, sondern arbeite statt dessen mit einer Kombination aus ENQUEUE_READ und ENQUE_DELETE.
Funktioniert wunderbar. Einziger Nachteil sind die Jobs die ich dabei bekomme.
Nochmal Vielen Dank.
Gruß,
Ferum
Vielen Dank für die guten Ideen.
Ich habe es inzwischen mit dem Job gelöst.
Ich rufe einen eigenen RFC-FM auf der zuerst kontrolliert ob die Sperre schon da ist. Wenn nicht startet er einen Job mit einem Z-Programm, welches die Sperre anlegt und in einer Endlosschleife kontrolliert ob die Sperre noch vorhanden ist. Ist die Sperre nicht mehr vorhanden, wird das Programm beendet.
Zur Kontrolle nutze ich den ENQUEUE_READ, da der Standard-ENQUEUE-FM immer gleiche ne Sperre setzt, wenn er keine findet.
Die Sperre kann ich mit einem RFC-FM aufheben. Hier konnte ich jedoch nicht den Standard-DEQUEUE-FM nutzen, sondern arbeite statt dessen mit einer Kombination aus ENQUEUE_READ und ENQUE_DELETE.
Funktioniert wunderbar. Einziger Nachteil sind die Jobs die ich dabei bekomme.
Nochmal Vielen Dank.
Gruß,
Ferum
Hallo Ferum,
Oder hast Du das so gelöst, dass Du immer nur einen Job startest und der baut dann so viele Sperren auf, wie Du gerade brauchst und bleibt dann eben so lange aktiv bis auch die letzte Sperre wieder gelöscht ist?
Viele Grüße
Chris
Naja, je nach Anwendungsszenario ist das ein durchaus nennenswerter Nachteil... bei einer Anwendung, die maximal 5 User gleichzeitig aufrufen, da sie nur für ein paar Admins gedacht ist, da mag das mit den Jobs ja noch ganz gut klappen. Aber was machst Du, wenn die Anwendung plötzlich für die ganze Firma freigegeben wird (so ESS mäßig) oder wenn der Bedarf sogar eine Art Webshop-Anbindung ist, wo potentiell mehrere Hundert Benutzer gleichzeitig aktiv sind? Ich kenne jetzt Eure SAP-System nicht… aber ich denke mal, da freut sich die ABAP-Instanz so richtig, wenn sie mit so vielen Jobs klar kommen sollFerum hat geschrieben:Einziger Nachteil sind die Jobs die ich dabei bekomme.
Oder hast Du das so gelöst, dass Du immer nur einen Job startest und der baut dann so viele Sperren auf, wie Du gerade brauchst und bleibt dann eben so lange aktiv bis auch die letzte Sperre wieder gelöscht ist?Viele Grüße
Chris
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
ChrisB hat geschrieben:...nur einen Job startest und der baut dann so viele Sperren auf, wie Du gerade brauchst und bleibt dann eben so lange aktiv bis auch die letzte Sperre wieder gelöscht ist?
a-dead-trousers hat geschrieben:...mit ein wenig "dynamischer Programmierung" sogar eine universell einsetzbare Lösung.
Ich würde da eher mit Semaphoren arbeiten. Also im Grunde eine eigene Sperrlogik abbilden.
Am besten mit Zeitstempel, damit periodisch Einträge reorganisiert werden können.
Die Semaphore könnte einfach per "EXPORT timestamp = timestamp TO DATABASE indx(ZZ) ID object_id" realisiert werden könnte.
Wobei man wohl auch den Zeitstempel der Tabelle verwenden könnte (Zusatz FROM ...). Wäre wahrscheinlich sogar einfacher für die Reorganisation nicht aufgelöster Sperren.
Am besten mit Zeitstempel, damit periodisch Einträge reorganisiert werden können.
Die Semaphore könnte einfach per "EXPORT timestamp = timestamp TO DATABASE indx(ZZ) ID object_id" realisiert werden könnte.
Wobei man wohl auch den Zeitstempel der Tabelle verwenden könnte (Zusatz FROM ...). Wäre wahrscheinlich sogar einfacher für die Reorganisation nicht aufgelöster Sperren.
Vergleichbare Themen
2
Antw.
Antw.
2368
Views
Views
ENQUEUE beim VIEW_MAINTENANCE_CALL
von michael.schoeffer » 26.10.2006 12:51 • Verfasst in ABAP® für Anfänger
von michael.schoeffer » 26.10.2006 12:51 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
261
Views
Views
2
Antw.
Antw.
1602
Views
Views
0
Antw.
Antw.
1071
Views
Views
automatische Rechnungssperre
von Flo » 20.06.2006 15:50 • Verfasst in Material Management & Produktionsplanung
von Flo » 20.06.2006 15:50 • Verfasst in Material Management & Produktionsplanung
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1145
vor 2 Tagen von DeathAndPain 4 / 1145
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1145
vor 2 Tagen von DeathAndPain 4 / 1145