REST-API Konferenzen updaten schlägt merkwürdig fehl

  • Hallo,


    ich versuche momentan über die REST API in Anlehnung an den automatisch generierten Swagger Client Konferenzen zu verwalten.


    Server Version: 6.7.0.24


    Was funktioniert:
    - User anlegen und löschen
    - Konferenz per REST anlegen und per REST löschen
    - Konferenz per REST anlegen und per REST retrieven
    - Konferenz per REST anlegen und in Web Interface löschen
    - Konferenz per REST anlegen und in Web Interface bearbeiten


    Was nicht funktioniert:
    - Konferenz in Web Interface anlegen und per REST (GET) retrieven
    - Konferenz per REST anlegen (POST) und per REST updaten (PUT)


    Im letzteren Fall ist das Verhalten sehr merkwürdig. Sobald der Eintrag per PUT mit erfolgreicher Rückmeldung bearbeitet wurde, taucht er nicht mehr im Web Interface auf. Trotzdem ist der Eintrag noch über REST (GET) zu sehen, lässt sich von nun an aber auch nicht mehr löschen. Weder per REST noch per Web Interface ("No managed conference with the given conferenceId <id> could be found").


    Obwohl im Web Interface keine einzige Konferenz mehr sichtbar ist für User 1000, sind angeblich über den Endpunkt /users/1000/managedConferences noch zahlreiche Einträge vorhanden..


    Verwendet jemand diese Version mit der REST API erfolgreich was das Verwalten der Konferenzen angeht?


    Danke.


    Update: Updaten der Einträge per REST klappt plötzlich nachdem ich ein Diagnostic Log aufgezeichnet habe.. Merkwürdig. Das Problem, dass neue Einträge vom Webinterface nicht per GET sichtbar sind aber viele Einträge (wohl durch Problem bei PUT verursacht) nur per REST sichtbar sind aber nicht im Webinterface bleibt nach wie vor.


    Update 2: Scheinbar triggert das Vorhandensein des Konferenz Parameters participantId (unter Participants) das merkwürdige Verhalten. Wenn es gesetzt ist mit z. B. 1000 schlägt das PUT fehl (..Eintrag verschwindet im Web Interface aber via GET ist die Änderung sichtbar, Eintrag zudem wie erwähnt nicht löschbar)

    4 Mal editiert, zuletzt von opensource ()

  • Hallo Wolfgang,


    danke für deine Antwort.


    Für neue Teilnehmer setze ich die ParticipantId auf 0.


    Okay mit participantId = 0 (oder weglassen) klappt es auch und der Eintrag wird korrekt geupdated und lässt sich anschließend auch weiterhin ansprechen (delete, update, ..)


    - Das Problem, dass ich die Einträge die ich über das Web Interface erstellt habe nicht gesehen habe lag nur daran, dass ich die normale Login ID als userId verwendet hatte im Request. Das ist mir nur nicht gleich aufgefallen, da ja natürlich auch die Konferenzen erstellt von userId=1 mit userId=1000 als participant bei dem ersten User mit id=1 auftauchen im Web Interface.


    - Solange ich wie von dir angemerkt die participantId auf 0 setze oder den Parameter einfach komplett weglasse verhält sich nun auch alles so wie gewünscht.


    Jedoch finde ich es nach wie vor sehr merkwürdig, dass ein Setzen auf participantId=1000 oder einen anderen Wert außer 0 den Eintrag beim Update im Nirvana verschwinden lässt, bzw. ihn nicht mehr ansprechbar macht.


    Hast Du Dir schon das restfull Log auf dem Server angesehen?


    Habe mal ein paar Logs meiner Requests generiert mit participantId=2.


    1. Konferenz erstellen:


    2. Konferenz retrieven:


    3. Konferenz updaten (gleiche Daten wie bei POST)
    (Output ist quasi "identisch" mit output bei welchem im PUT keine participantId gesetzt wurde oder participantId=0, also kein offensichtlicher Error auf dem Server)


    4. Konferenz (versuchen) zu löschen
    (wenn ich kein PUT gemacht hätte vorher ODER im POST davor participantId=0 (oder omitted) hätte, wäre DELETE hier erfolgreich)


    5. Konferenz retrieven (immer noch vorhanden..):


    Welchen use-case hat denn die participantId? Sie bezieht sich ja scheinbar nicht einfach auf die ID eines Kontakts welcher kein lokales Benutzer Konto hat? Identifiziert die participantId einfach nur jeden Benutzer einer Konferenz, also ist pro Konferenz für jeden Teilnehmer eindeutig, ob mit Konto oder ohne? Dann sollte ja auch eine participantId von z. B. 2 in Ordnung sein?


    Zusammenfassend: Es funktioniert alles solange ich die participantId weglasse oder auf Null setze. Mich würde trotzdem interessieren, ob das obige Verhalten ein Bug oder ein Feature ist, da ich aktuell auch diese toten Konferenz Einträge nicht gelöscht bekomme - egal mit welcher userId.


    Vielen Dank!

  • Die ParticipantId ist die ID für einen Konferenzteilnehmer-Eintrag und entspricht keiner Login ID, account ID oder so.


    Der Windows Client behalt beim Bearbeiten einer Konferenz bei den schon vorhandenen Teilnehmern die ParcipantId bei und setzt für neue Teilnehmer die ParticipantId auf 0.


    Die Fehlermeldung aus dem Log erscheint mir falsch. Vielleicht ist hier eher das Problem, dass der Participant Eintrag nicht gelöscht (wg. der Id) und in der Folge die Konferenz nicht entfernt werden kann.


    Gruß Wolfgang

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!