forum.opsi.org

Hallo,

aus einem WInst-Skript auf OPSI-Objekte zuzugreifen ist eine muehsame Sache, obwohl man doch erwarten wuerde, dass man von einem Tool aus einfach die eigenen Datenstrukturen abrufen kann. Fuer die OPSI-Methoden gibt es den OpsiServiceCall, der aber (Handbuch Kapitel 8.12.2 "Sektionsformat ") nur fuer die alten OPSI 3-Methoden funktionert. Andererseits sind diese als "Legacy"-Methoden deklariert und werden u.U. irgendwann verschwinden.

So oder so ist - IMHO! - die Syntax dieser Methoden und der JSON-Objekte schwierig, fehleranfaellig und unuebersichtlich. Viel einfacher zu benutzen waeren z.B. Funktionen wie

GetObject(type, filter, returnvalue)
GetObjectList(type, filter, returnvalue)

Z.b. Das Abrufen des Status des Produktes A auf Host B: GetObject("product", product.id="A";host.name="B", "installationStatus"). Oder die Liste aller Hostnamen, auf denen Produkt "A" installiert ist: GetObjectList("host", product.id="A";productOnClient.installationStatus="installed", "hostname").

Das ist relativ unausgegoren, soll aber einfach die Richtung anzeigen, die ich mir wuenschen wuerde.

Gruss
frank

mir sind die OPSI4 methoden auch ein Dorn im Auge viel zu kompliziert zu nutzen hab ich aber schon häufig kritisiert

OPSI3 Methoden sind überall einfach nutzbar. Lassen sich sogar einfach in PHP Scripte integrieren ohne großartig Ahnung von JSON-RPC haben zu müssen.
OPSI4 Methoden bekomme ich grade mal, dank Beispiele, in WINST Script integriert.
Für alles andere greifen wir (ich weis nicht supportet - aber deutlich einfacher zu realisieren) direkt auf das MySQL Backend zurück....

tobias hat geschrieben:OPSI4 Methoden bekomme ich grade mal, dank Beispiele, in WINST Script integriert.

Wie? Aus dem Handbuch: "Die opsiservicecall Sektionen sind für opsi 3.x Methoden entwickelt worden und für die opsi 4.x Methoden häufig nicht verwendbar. So sind *_getIdents Aufrufe zwar möglich, *_getObjects Aufrufe aber nicht." Oder verwendest Du einfach nur die kompatiblen Aufrufe? Ich braeuchte aktuell [viewtopic.php?f=7&t=5649] natuerlich genau eine *_getObjects-Funktion

Für alles andere greifen wir (ich weis nicht supportet - aber deutlich einfacher zu realisieren) direkt auf das MySQL Backend zurück....

Hier kein MySQL, sondern File-Backend. Arbeite gerade an einem Perlskript, welches es direkt verwendet.

embl-structures hat geschrieben:

tobias hat geschrieben:OPSI4 Methoden bekomme ich grade mal, dank Beispiele, in WINST Script integriert.

Wie? Aus dem Handbuch: "Die opsiservicecall Sektionen sind für opsi 3.x Methoden entwickelt worden und für die opsi 4.x Methoden häufig nicht verwendbar. So sind *_getIdents Aufrufe zwar möglich, *_getObjects Aufrufe aber nicht." Oder verwendest Du einfach nur die kompatiblen Aufrufe? Ich braeuchte aktuell [viewtopic.php?f=7&t=5649] natuerlich genau eine *_getObjects-Funktion

Ich schreibe nur aus einem Paket in das OPSI Backend per OPSI-Webservice - ich lese da nix aus das ist einfacher....

Hallo zusammen,

erst mal ein frohes neues Jahr.

Uns ist bewusst, dass die opsi 4 Methoden nicht trivial zu bedienen sind. Wir haben uns aber bei opsi 4 bewusst für dieses Design entschieden, weil es aus Maintainance-Sicht unheimlich schwer wurde, den Code mit vertretbarem Aufwand zu pflegen. Da wir damals und heute wahrscheinlich auch, im Backend und in den tiefen des opsi-Kerns schneller mit der Implementierung waren/sind haben wir die "alten" Methoden von opsi 3 auf die neuen opsi 4 Methoden gemapped. Diese Methoden, sind die berühmten Legacy-Methoden.

Das offizielle opsi 4 Release ist ja nun schon einige Tage her. Das heißt, wir hatten Gelegenheit die Vor- und Nachteile dieses Umbaus zu untersuchen. Das Hauptproblem mit den opsi4-Methoden ist, dass man zwar bequemen Zugriff auf die Objekte von opsi hat, aber keine Business-Logik. Das war von Anfang an so gewünscht. Das heißt, bei jedem Task, müssen die Admins nicht nur Wissen, wie Sie an diese Methoden rankommen und damit umgehen müssen, sondern es muss auch einiges an Hintergrundwissen da sein, um die arbeit zu erledigen.

Ein einfaches Beispiel um das zu verdeutlichen:

setProductActionRequest

Diese Methode allein auf opsi 4 Methoden angewendet funktioniert nicht mit einem einzigen Call. Sondern man muss mehrere Calls abschicken und die Daten dann später logisch miteinander verbinden.

Zum einen muss man das Hostobjekt haben (checken, ob es den Host überhaupt gibt) und die Depotzugehörigkeit klären.
Dann muss man checken, ob das Paket auf dem Depot vom Client überhaupt zur Verfügung steht.
Dann muss noch geprüft werden, ob es schon eine Konfiguration für diese Software, für diesen Client gibt.
Dann muss der eigentliche Task ausgeführt werden.

Und da sind jetzt noch keine Dependencies berücksichtigt.

Diese Methoden werden zwar als Legacy zusammengefasst, werden aber nach jetziger Planung nicht aussortiert. Vielmehr wird es wahrscheinlich so ablaufen, dass die Bezeichnung legacy in einer der nächsten größeren Releases umbenannt wird. Wir sind stetig dabei, diese Methoden auch zu erweitern. Und hier kommt das nächste Problem, es ist schwierig, wenn man sich selber versucht durch den Methoden-Dschungel zu kämpfen.

Die Tatsache, dass der opsi-Webservice beliebig erweiterbar ist, ist auch so ein offenes Geheimnis. Es ist dokumentiert, aber die meisten opsi Anwender kommen mit diesen Features nicht in Kontakt, was im Grunde zwar nicht schlimm ist, aber auch leider sehr schade ist, weil man die Flexibilität von opsi dadurch nicht nutzt. Wir bauen ständig Webservice-Erweiterung für Kunden, die spezielle Anforderungen des Kunden auf bequeme Weise lösen. Wenn diese neuen Methoden allgemeingültig und von öffentlichem Interesse sind, werden diese Methoden mit in die Pakete eingebaut. Ein Beispiel dafür sind die groupAction-Methoden, die vor kurzem eingeführt wurden. Diese Methoden stellen eine Erweiterung der setProductActionRequest Methode dar: setProductActionRequestForHostGroup,...., etc.

Wir arbeiten momentan daran einen Fortgeschrittenen Kurs für opsi an zu bieten. Ein zentraler Schwerpunkt soll auch der Umgang mit Webservice-Methoden und die Webservice-Erweiterung sein. Da kann man noch viele andere Dinge mit bauen. Der Post von meinem Kollegen Niko aus dem Link zeigt auf einfache Weise, wie man sich das Leben um einiges erleichtern kann, anstatt die opsi 4 Objekte direkt zu verwenden, baut man sich eine kleine neue Methode, die genau das tut und zurückliefert, was man möchte.

Grüße
E. Ueluekmen

OK das klingt gut das die Legacy Methoden nicht verschwinden !!!

Das Funktionen wie der OPSI-Webservice von den Leuten ungerne angefasst werden liegt denke ich an der Komplexität dieser Funktionen - hat nicht jeder Zeit & Lust sich damit länger auseinander zu setzen und am Ende hat das (durch Lohnkosten) nicht weniger gekostet als wenn man das von euch basteln lassen würde und vor allem wäre ein Selfmade dann evtl. auch nicht so professionel, gut integriert und getestet.
(Ich denk da nur an meine Methode um den client-agent zu pushen wobei ich da selbst überrascht war wie einfach das umzusetzen war)


Aber schön das die Legacy Methoden bleiben ! Das beruhigt

ueluekmen hat geschrieben:erst mal ein frohes neues Jahr.

Danke. Dir natuerlich auch.

ueluekmen hat geschrieben:Uns ist bewusst, dass die opsi 4 Methoden nicht trivial zu bedienen sind. Wir haben uns aber bei opsi 4 bewusst für dieses Design entschieden, weil es aus Maintainance-Sicht unheimlich schwer wurde, den Code mit vertretbarem Aufwand zu pflegen. Da wir damals und heute wahrscheinlich auch, im Backend und in den tiefen des opsi-Kerns schneller mit der Implementierung waren/sind haben wir die "alten" Methoden von opsi 3 auf die neuen opsi 4 Methoden gemapped. Diese Methoden, sind die berühmten Legacy-Methoden.

Ich habe kein Problem mit durchstrukturiertem API-Design, klarer Nomenklatur etc. Ganz im Gegenteil. Was ich im Moment suboptimal finde ist, dass man aus einem WInst-Skript nicht auf alle verfuegbaren Methoden zurueckgreifen kann (siehe mein Fall mit der Abfrage der "Description" des aktuellen Clients). Intuitiv verstaendliche, einfache Syntax ist eines, dass die Informationen ueberhaupt zur Verfuegung gestellt werden, ein anderes.

ueluekmen hat geschrieben:Diese Methoden werden zwar als Legacy zusammengefasst, werden aber nach jetziger Planung nicht aussortiert. Vielmehr wird es wahrscheinlich so ablaufen, dass die Bezeichnung legacy in einer der nächsten größeren Releases umbenannt wird. Wir sind stetig dabei, diese Methoden auch zu erweitern. [...]

Das ist sehr gut. Danke.

ueluekmen hat geschrieben:Die Tatsache, dass der opsi-Webservice beliebig erweiterbar ist, ist auch so ein offenes Geheimnis. Es ist dokumentiert, aber die meisten opsi Anwender kommen mit diesen Features nicht in Kontakt, was im Grunde zwar nicht schlimm ist, aber auch leider sehr schade ist, weil man die Flexibilität von opsi dadurch nicht nutzt.[...]

Fuer mich war das bisher neu. Ich finde das auch nur sehr, sehr rudimentaer in Kapitel 5.3 (Backend-Erweiterungen) dokumentiert. Das Backend selber zu erweitern ist natuerlich eine Moeglichkeit, aber sehr zeitaufwendig und nicht jeder hat die Zeit, sich in noch eine weiter Technologie/Programmiersprache/... einzuarbeiten. Das hat ja auch Thomas schon angedeutet.

ueluekmen hat geschrieben:Wir arbeiten momentan daran einen Fortgeschrittenen Kurs für opsi an zu bieten.[...]

Ich hoffe, der Kurs wird in der News-Mailliste angekuendigt?

Gruss
frank

Hallo,

tobias hat geschrieben:

embl-structures hat geschrieben:

tobias hat geschrieben:OPSI4 Methoden bekomme ich grade mal, dank Beispiele, in WINST Script integriert.

Wie? Aus dem Handbuch: "Die opsiservicecall Sektionen sind für opsi 3.x Methoden entwickelt worden und für die opsi 4.x Methoden häufig nicht verwendbar. So sind *_getIdents Aufrufe zwar möglich, *_getObjects Aufrufe aber nicht." Oder verwendest Du einfach nur die kompatiblen Aufrufe? Ich braeuchte aktuell [viewtopic.php?f=7&t=5649] natuerlich genau eine *_getObjects-Funktion

kleiner Einwurf: es gibt ein *_getHashes, welches die Objekte in JSON-Notation zurückliefert. Direkt an die Objekte zu kommen ist Sprachübergreifend leider nicht ganz so einfach, aber die JSON-Objekte enthalten all die Information, die auch an den "normalen" Objekten zu finden ist.


Gruß

NW

n.wenselowski hat geschrieben:[...] kleiner Einwurf: es gibt ein *_getHashes, welches die Objekte in JSON-Notation zurückliefert. Direkt an die Objekte zu kommen ist Sprachübergreifend leider nicht ganz so einfach, aber die JSON-Objekte enthalten all die Information, die auch an den "normalen" Objekten zu finden ist.[...]

Vielen Dank. Ich werde alles beruecksichtigen . Die m.E. aber einfachste Loesung hat dkoch in viewtopic.php?f=7&t=5649 publiziert.

Gruesse und schoenes Wochenende
frank