cmdb.category.save fehlende Datenübernahme bei [string]
-
Hallo zusammen,
ich versuche gerade zu verstehen, warum bei einem cmdb.category.save, Daten die zwar im API Aufruf zu finden sind, nicht in die CMDB übernommen werden.
curl -s --noproxy "*" --location --request POST 'https://FQDN/i-doit/src/jsonrpc.php' --header 'Content-Type: application/json' --header "X-RPC-Auth-Session: TOKEN" --header "Cookie: PHPSESSID= SESSIONID" --data-raw '{ "version": "2.0", "method": "cmdb.category.save", "params": { "object": "13217", "entry": "", "data": { "application": "5136", "application_type": "", "assigned_license": "", "assigned_license_key": "", "assigned_it_service": "", "assigned_variant": "", "assigned_version": "7.9", "assigned_databases": "", "description": "Auto created by API" }, "category": "C__CATG__OPERATING_SYSTEM", "apikey": "KEY", "language": "en" }, "id": 1 }' # Ergebnis "result":{"success":true,"message":"Category entry successfully saved","entry":582}}
Dieser Aufruf sollte eigentlich die OS Infos aktualisieren und hier neben dem OS selbst (application id) auch die Version 7.9 setzten. Der Doku nach kann für assigend_version sowohl ein String, passend zu einem Eintrag im Dialogfeld oder die ID des Eintrags im Dialogfeld angegeben werden.
Die Versionsnummer existiert eindeutig in der Liste der Versionsnummern, wie hier zu sehen ist wird diese jedoch nicht übernommen. Hat jemand eine Idee, woran das liegen könnte?
-
Ich habe ein ähnliches Problem. indem beim Erzeugen eines Serverobjekts mit der Kategorie C__CATG__OPERATING_SYSTEM der OS-Eintrag erzeugt wird, aber ohne Version.
Meine Vermutung ist, dass da noch ein Bug in der API existiert, und dass die Version in Wirklichkeit kein Dialog+ ist, sondern eine eigene Kategorie (C__CATG__VERSION). Gestützt wird dies auch durch das (veraltete) JSON-RPC API Manual: dort steht bei den Kategorien für Datenarrays, dass die Referenz für die assigned_version isys_catg_version_list__id ist.
-
@martinv
Das könnte natürlich sein, aber ich hab den Fehler schon an mehreren Stellen gefunden, ein anderes Beispiel wäre bei "drive" (bzw. Laufwerk) wo das on_device nicht gesetzt wird, obwohl die Übergabe korrekt ist und auch hier die Einträge existieren. Ein weiteres Beispiel wäre die Zuordnung bei virtual devices.Ich würde mir jedoch gerne die Suche nach den passenden ID's ersparen, sofern es auch ohne geht.
-
@lewando said in cmdb.category.save fehlende Datenübernahme bei [string]:
Ich würde mir jedoch gerne die Suche nach den passenden ID's ersparen, sofern es auch ohne geht.
Falls Du einen Weg findest, wäre ich sehr interessiert. Ich denke, die API hat Probleme, einen numerischen String von einer ID zu unterscheiden. Ich meine, ich hätte hier im Forum auch schon einen entsprechenden Post gelesen.
Ich habe es jetzt mit einer Suche zum Laufen bekommen.
-
-
@franknagel
Stimmt, ich hatte dazu mal eine ähnliche Frage gestellt (wobei, da fällt mir gerade ein, dass ich noch keine Info bekommen hatte, ob mein Bugreport auch geschlossen wurde), in diesem Fall ist es zwar ähnliches Beispiel, steht hier aber nur stellvertretend für mehrere Kategorien, wo dieses Problem existiert und vor allem auch bei Werten, die nicht als Int interpretiert werden. -
Vielleicht noch ein anderes Beispiel, was das Problem für eine andere Kategorie zeigt.
Hier der Eintrag aus dem Logbuch (also das Ergebnis des API Requests):
So schaut es im Objekt selbst aus:
-
In letzten Fall handelt es sich ja auch nicht um ein Dialog+ Feld, sondern ein 'einfaches' Dialog Feld. Hier wird eine Referenz auf einen bestehenden Kategorie-Eintrag des Typs C__CATG__STORAGE_DEVICE erwartet, entweder mittels Integer ID, oder (wahrscheinlich) als String über den Titel.
Nur Bei Dialog+ Feldern kann man Einträge implizit erzeugen, weil dahinter außer dem Bezeichner keine weiteren Daten stehen.
-
@franknagel
Genau darum geht es ja, der Eintrag /dev/mapper/fs02 existiert als Titel eines devices bereits, so dass hier die Zuordnung als String über den Titel erfolgen sollte. (In anderen Fällen klappt das auch, aber nicht in jedem Fall).Anders ausgedrückt, ich möchte mit dem Request zwar das drive anlegen, die notwendigen Abhängigkeiten wie device etc. existieren aber schon und müssen nur richtig verknüpft werden.
Wenn ich den gleichen Request absetzte, mit der ID des Device funktioniert es ja auch. Das ist jedoch umständlicher als den Titel zu verwenden, den ich bereits weiß.
-
Hallo @lewando
hier mal die Antwort darauf wie man Geräte unter Laufwerke zuweist:
Das in der Benutzeroberfläche angezeigte Feld mit der Bezeichnung "Auf Gerät" verwendet verschiedene Eigenschaften zusammen.
category_const
ist die Eigenschaft, die bestimmt, um welchen Typ es sich handelt. Sie kann sein
C__CATG__STORAGE
,C__CATG__RAID
oderC__CATG__LDEV_CLIENT
sein.Und für jede Konstante gibt es eine eigene Eigenschaft, die mit dem ausgewählten Object (device, raid bzw. ldev) verknüpft ist.
Der korrekte API-Aufruf wäre demnach:{ "version": "2.0", "method": "cmdb.category.save", "params": { "object": 13698, "category": "C__CATG__DRIVE", "data": { "mount_point": "/var", "title": "/dev/mapper/fs02-data", "system_drive": "0", "filesystem": "XFS", "capacity": 60, "unit": "GB", "device": 111, "category_const": "C__CATG__STORAGE", "description": "Auto created by API" }, "apikey": "beer", "language": "en" }, "id": 1 }
Wobei die
111
die ID des zuvor angelegten Gerätes in der Kategorie Lokaler Massenspeicher darstellt.
Du solltest nun auch die Bezeichnung des Gerätes alsdevice
verwenden können.Möchtest du ein RAID verknüpfen musst du dies in der Kategorie Lokaler Massenspeicher -> RAID-Verbund erstellen und dann via ID oder Bezeichnung verknüpfen:
"raid": 13, "category_const": "C__CATG__RAID"
oder
"raid": "Raid-1", "category_const": "C__CATG__RAID"
Für ein LDEV Client erstellst du einen Eintrag in der Kategorie Speichernetze -> Logische Geräte (Client) und dann via ID oder Bezeichnung verknüpfen:
"ldev": 6, "category_const": "C__CATG__LDEV_CLIENT"
oder
"ldev": "LDEV-Client", "category_const": "C__CATG__LDEV_CLIENT"