Ablauf-Schwierigkeiten SOAP-API

    Guten Nachmittag zusammen,



    das hier ist der erste Thread (neben dem "Bump" bei "Kontakte löschen") einer kleinen Reihe an Problemen, die in den letzten Tagen insbesondere mit der SOAP-API aufgetreten sind.



    Die Installation lief verdammt angenehm durch, meinen herzlichen Dank dafür. Im Vergleich zu anderen Systemen macht das richtig Spass.


    Ein einziges Mini-Improvement habe ich für die Installation des Repositories:


    Code
    sudo wget -O/etc/apt/sources.list.d/liveconfig.list http://repo.liveconfig.com/debian-test/liveconfig.list


    (oder gab es einen Grund für die Aufteilung auf 2 Befehle (cd; sudo wget)?)



    Background-Infos zum Einsatzzweck: wir haben einen Server mit LiveConfig am Laufen, der zukünftig für Demo-Accounts genutzt wird.


    Interessent meldet sich auf einer Webseite an. Danach verwendet ein Cronjob die Daten, um den Interessenten im LiveConfig anzulegen sowie unsere Demo-Application im Account zu installieren. Der Interessent darf LiveConfig dabei nicht verwenden, sondern soll nur die Application einsetzen dürfen.



    Folgender vereinfachter Ablauf der Kommunikation mit LiveConfig:


    - ContactAdd
    - CustomerAdd
    - HostingSubscriptionAdd (mit "Demo" als Hosting-Angebot)
    - HostingDomainAdd
    - HostingSubdomainAdd (http://www.-Subdomain)
    - HostingDatabaseAdd


    Klappt alles gut, von kleineren (oder größeren) Problemen abgesehen:


    - beim Anlegen des Vertrages wird die Angabe der Server-Namen gefordert, obwohl überhaupt nur einer (Standard-Lizenz) vorhanden ist. Macht jetzt nicht soo viel aus, da zukünftig ja expandiert werden könnte bzw. es eh in der API so dokumentiert ist. Sinn macht es aber trotzdem bei einem einzigen vorhandenem Server nur wenig :)
    - Im Angebot ist "FTP: nein" definiert. Nach dem Anlegen des Vertrages per SOAP steht aber in der GUI "FTP-Zugänge: 1 (max. 0)" mit einem grünen Balken. Der Auslastungsbalken bei Datenbanken "1 (von max 1)" ist hingegen rot gefärbt.
    - Auch wird trotz "FTP: nein" der Systembenutzer so angelegt (muss für den Apachen / das Linux logischerweise eh), dass sich der Kunde, wenn ihm das Passwort bekannt wäre, per FTP anmelden könnte (das soll widerrum nicht). Habe ich nun dahingehend gelöst, dass beim Anlegen des Vertrages ein Zufallspasswort gesetzt wird. Per GUI ist die Passwort-Änderung eh nicht möglich, das passt letztendlich doch irgendwie.
    - Dadurch, dass der Kunde ohne LiveConfig-Benutzer-Account angelegt wird, wird die Steuerung des Accounts deutlich schwieriger. Es lässt sich im Nachhinein im LiveConfig für diesen Kunden unter Kunden -> Details -> "Übersicht" kein neuer Benutzer anlegen, so dass auch die Verwaltung der Domains/Datenbanken nicht mehr möglich ist. Der Button "Verbindung starten" fehlt ohne Benutzer ja komplett. Wurde dahingehend gelöst, dass zusätzlich noch "UserAdd" mit einem Random-Passwort aufgerufen wird.
    - Nach Ablauf der Demo-Phase kann zwar per SOAP-API der Hosting-Vertrag gelöscht werden, aber der Kunde nicht. Auch die Kontakte verbleiben als Leiche im System. Der Kunde könnte sich also noch weiterhin anmelden, sieht nur keine Daten mehr. Löschung müsste also per GUI manuell abgeschlossen werden.


    Bei den Kontakten wäre IMHO eine Übersicht, ähnlich der Kunden oder der Benutzer, recht vorteilhaft. Das würde dann "neuer Kontakt", "Kontakt editieren" sowie "Kontakt löschen" erleichtern - genau wie eine Detail-Anzeige, bei welchen Kunden bzw. Benutzern dieser Kontakt nun genau im Einsatz ist.




    Für 2014 hoffe ich eher auf Bugfixes statt auf neue Features. Wenn ich mir die Ticket-Liste unter liveconfig.com/dev so anschaue, wären die Bugfixes wichtiger als das nächste neue Feature mit u.U. noch mehr Bugs.



    Keep going! :)



    VG,
    Anton

    Zitat von antondollmaier


    Bei den Kontakten wäre IMHO eine Übersicht, ähnlich der Kunden oder der Benutzer, recht vorteilhaft. Das würde dann "neuer Kontakt", "Kontakt editieren" sowie "Kontakt löschen" erleichtern - genau wie eine Detail-Anzeige, bei welchen Kunden bzw. Benutzern dieser Kontakt nun genau im Einsatz ist.


    Für 2014 hoffe ich eher auf Bugfixes statt auf neue Features. Wenn ich mir die Ticket-Liste unter liveconfig.com/dev so anschaue, wären die Bugfixes wichtiger als das nächste neue Feature mit u.U. noch mehr Bugs.


    Dem schließe ich mich an :)

    Würde ich auch befürworten!


    Ich habe das Problem so gelöst/bin derzeit an der Umsetzung (bei mir haben die Kunden ebenfalls keinen Zugriff auf LiveConfig), dass ich nur einen neuen Hosting-Vertrag anlege unter einem "globalen" Benutzer. Somit kann ich durch Löschen des Vertrags das Löschen automatisieren. Ist aber sicher nicht für jedes Anwendungsszenario so umsetzbar.

    Zitat von bfal

    Es ist somit ein würdiger Confixx Nachfolger. Denn dort habe ich auch selten erlebt das es eine Antwort gab :D


    Nun mal langsam... wir können sicher nicht jeden einzelnen Forumsbeitrag individuell kommentieren; wir lesen aber jeden Beitrag, und alle offenen Themen sind bei uns intern auch markiert. Dringende Anliegen werden jederzeit über den Support (support@liveconfig.com bzw. Telefon) bearbeitet. Das müssten Sie eigentlich auch schon mitbekommen haben.

    Ja im Moment hängt es leider wieder etwas. Einige Fragen hier im Forum und auch per E-Mail bleiben leider unbeantwortet und den aktuellen Entwicklungsstand erfährt man leider auch nicht, 1.7.1 wurde ja für vor Weihnachten angekündigt. Was ich leider etwas unglücklich finde, da man mit seinen Kunden ja auch irgendwie planen muss. Ich würde mir eine etwas offenere Kommunikation wünschen. Es sollte sich nach dem Update 1.7.0 ja ändern, leider hat es sich das bisher nicht.

    Zitat von antondollmaier

    Ein einziges Mini-Improvement habe ich für die Installation des Repositories:


    Code
    sudo wget -O/etc/apt/sources.list.d/liveconfig.list http://repo.liveconfig.com/debian-test/liveconfig.list


    (oder gab es einen Grund für die Aufteilung auf 2 Befehle (cd; sudo wget)?)


    Ist etwas übersichtlicher in zwei Zeilen; außerdem ist mit dem "cd" sichergestellt, dass man keinen Tippfehler im Pfad hat.


    Zitat

    - beim Anlegen des Vertrages wird die Angabe der Server-Namen gefordert, obwohl überhaupt nur einer (Standard-Lizenz) vorhanden ist. Macht jetzt nicht soo viel aus, da zukünftig ja expandiert werden könnte bzw. es eh in der API so dokumentiert ist. Sinn macht es aber trotzdem bei einem einzigen vorhandenem Server nur wenig :)


    Die API ist an sich auf das Maximum - also den Multi-User-Betrieb - ausgelegt. Im Falle einer Standardlizenz den Servernamen wegzulassen wäre eine sinnvolle Optimierung.


    Zitat

    - Im Angebot ist "FTP: nein" definiert. Nach dem Anlegen des Vertrages per SOAP steht aber in der GUI "FTP-Zugänge: 1 (max. 0)" mit einem grünen Balken. Der Auslastungsbalken bei Datenbanken "1 (von max 1)" ist hingegen rot gefärbt.
    - Auch wird trotz "FTP: nein" der Systembenutzer so angelegt (muss für den Apachen / das Linux logischerweise eh), dass sich der Kunde, wenn ihm das Passwort bekannt wäre, per FTP anmelden könnte (das soll widerrum nicht). Habe ich nun dahingehend gelöst, dass beim Anlegen des Vertrages ein Zufallspasswort gesetzt wird. Per GUI ist die Passwort-Änderung eh nicht möglich, das passt letztendlich doch irgendwie.


    Bei Webspace ist technisch bedingt immer ein Systemaccount (und somit implizit ein "FTP-User" im weitesten Sinne) erforderlich. Ich verstehe aber Ihr Einsatzszenario; ich denke es dürfte keine große Sache sein, in so einem Fall einen gesperrten FTP-Account einzurichten. Wird aufgenommen.[/quote]


    Zitat

    - Dadurch, dass der Kunde ohne LiveConfig-Benutzer-Account angelegt wird, wird die Steuerung des Accounts deutlich schwieriger. Es lässt sich im Nachhinein im LiveConfig für diesen Kunden unter Kunden -> Details -> "Übersicht" kein neuer Benutzer anlegen, so dass auch die Verwaltung der Domains/Datenbanken nicht mehr möglich ist. Der Button "Verbindung starten" fehlt ohne Benutzer ja komplett. Wurde dahingehend gelöst, dass zusätzlich noch "UserAdd" mit einem Random-Passwort aufgerufen wird.


    Das ist auch das normale Vorgehen: erst CustomerAdd(), dann UserAdd(). Accounts ohne LiveConfig-User sind bislang nicht vorgesehen.


    Zitat

    - Nach Ablauf der Demo-Phase kann zwar per SOAP-API der Hosting-Vertrag gelöscht werden, aber der Kunde nicht. Auch die Kontakte verbleiben als Leiche im System. Der Kunde könnte sich also noch weiterhin anmelden, sieht nur keine Daten mehr. Löschung müsste also per GUI manuell abgeschlossen werden.


    CustomerDelete() und ConactDelete() stehen bereits auf der ToDo-Liste. Diese setzen aber noch den Abschluß der Kontaktverwaltung vorraus (LC muss schließlich vor dem Löschen eines Kontaktes erst noch prüfen, ob dieser noch in irgendeinem Objekt (z.B. Vertrag oder Kunde) verwendet wird).


    Zitat

    Bei den Kontakten wäre IMHO eine Übersicht, ähnlich der Kunden oder der Benutzer, recht vorteilhaft. Das würde dann "neuer Kontakt", "Kontakt editieren" sowie "Kontakt löschen" erleichtern - genau wie eine Detail-Anzeige, bei welchen Kunden bzw. Benutzern dieser Kontakt nun genau im Einsatz ist.


    S.o. - genau das befindet sich derzeit in Entwicklung (zum Thema "Kontakte verwalten" gibt es schon einige Wünsche hier im Forum).


    Viele Grüße


    -Klaus Keppler

    Danke für die umfangreiche Antwort :)


    Zitat von kk

    Ist etwas übersichtlicher in zwei Zeilen; außerdem ist mit dem "cd" sichergestellt, dass man keinen Tippfehler im Pfad hat.


    Dank Copy'N'Paste sollten Tippfehler egal sein. Aber stimmt schon, wichtig ist es jetzt nicht :)


    Zitat

    Bei Webspace ist technisch bedingt immer ein Systemaccount (und somit implizit ein "FTP-User" im weitesten Sinne) erforderlich.


    Klar, ist mir bewusst.


    Mir geht es nur um die Darstellung in der Web-GUI:


    - wird der Kunde mit einem Hosting-Angebot ohne FTP im Panel angelegt, wird kein FTP-Account angezeigt (System-Account existiert natürlich)
    - wird der Kunde mit einem Hosting-Angebot ohne FTP via SOAP-API angelegt, wird dem Kunden ein FTP-Account angezeigt, obwohl nur 0 FTP-Accounts inklusive sind.


    Zitat

    Ich verstehe aber Ihr Einsatzszenario; ich denke es dürfte keine große Sache sein, in so einem Fall einen gesperrten FTP-Account einzurichten. Wird aufgenommen.


    Perfekt.


    Zitat

    Das ist auch das normale Vorgehen: erst CustomerAdd(), dann UserAdd(). Accounts ohne LiveConfig-User sind bislang nicht vorgesehen.


    Ok.


    Dann würde ich darum bitten, dass das Handbuch an diesen Stellen ergänzt wird: CustomerAdd() erfordert offenbar zwingend den darauf folgenden Aufruf von UserAdd.


    Zitat

    CustomerDelete() und ConactDelete() stehen bereits auf der ToDo-Liste. Diese setzen aber noch den Abschluß der Kontaktverwaltung vorraus (LC muss schließlich vor dem Löschen eines Kontaktes erst noch prüfen, ob dieser noch in irgendeinem Objekt (z.B. Vertrag oder Kunde) verwendet wird).


    Yeah :)



    Dann hoffe ich auf die nächsten Versionen :)



    VG,
    Anton Dollmaier

    Guten Abend,


    muss mich leider erneut mit Fehlern in der SOAP-API melden.


    Diesmal leider keine Ablaufschwierigkeiten, sondern ganz klare Bugs.


    Betrifft komplett die SOAP-API-Funktion "HostingSubscriptionEdit()" bzw. "HostingSubscriptionAdd()".



    Am oben skizzierten Ablauf hat sich nichts geändert.


    Bei den Demo-Accounts gibt es nur Webspace. Keine Mailadressen, keine Datenbanken, kein FTP, keine Cronjobs. Kunde kann sich im LiveConfig einloggen, dort zwar Daten einsehen und bisschen rumklicken, aber ansonsten somit nichts machen.



    Über die iFrame-API gibt es nun die Möglichkeit, einen Tarifwechsel durchzuführen.



    Per SOAP wird, wenn der Kunde alle Daten angegeben hat, dann folgendes durchgespielt:


    - ContactEdit mit den Daten aus dem Formular (das läuft)
    - HostingSubscriptionEdit: gemäß API reicht es, neben der Auth den Subscriptionname sowie den neuen "plan" mitzugeben. Theoretisch tut das auch.


    Praktisch sieht es aber wie folgt aus:


    - da im Demo-HostingPlan keine Mailadressen und keine DBs mit dabei sind, fehlt nun die Zuordnung zum entsprechenden Server. Die SPalten in der DB ("HC_MAILSERVERID", "HC_DBSERVERID") sind einfach auf "null" gesetzt und bleiben nach dem HostingSubscriptionEdit auch auf null! Es ist außerdem nicht möglich, die entsprechenden Hostnames zusätzlich mitzugeben, da das beim Edit schlichtweg nicht vorgesehen ist. Der Bug tritt also schon beim HostingSubscriptionAdd auf, da ich dort die Server-Namen tatsächlich übergebe. Für die GUI ist das kein Problem, weil das Dropdown ja eh keine leere Auswahl zulässt.
    - im neuen HostingPlan sind auch Cronjobs sowie LiveConfig-Benutzer mit dabei. Beides wird NICHT übernommen. Der Benutzer kann diese Leistungen erst nutzen, wenn ich manuell(!) in der GUI den Hosting-Tarif NOCHMAL zuweise.


    Nach dem SubScriptionEdit wird noch die gebuchte Domain sowie die www-Subdomain angelegt, die bisher außerhalb von LC angelegte DB hinzugefügt ("create=0") und eine Mail verschickt.
    Der Teil klappt aber ohne Bugs.



    Wäre super, wenn bei diesen doch exotischen, aber realen und für uns nervigen, Bugs zeitnah ein Fix käme.


    PHP-Skripte kann ich notfalls zur Verfügung stellen.



    Viele Grüße,


    Anton Dollmaier

    Ergänzung:


    Nach einem "HostingSubscriptionEdit" mit einem neuen Plan wird neben den Cronjobs auch FTP nicht berücksichtigt. Das der Abschnitt "FTP-Benutzer" fehlt, bis per GUI erneut der Hosting-Plan gesetzt wird.


    Etwas ungünstig, eine Automatisierung per SOAP ist somit nicht möglich. Schade.



    VG,
    Anton

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden