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 oder C__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 als device 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"

Thema ist erledigt, wurde durch ein Ticket vom i-doit Team gelöst durch einen Hotfix. Wird vermutlich im nächsten Update mit drin sein 🙂

Vielen Dank für die Rückmeldungen.

Das Dokumente AddOn kenne ich schon.

Aber auch dort kann ich nicht einfach Bilder über die Zwischenablage oder Drag&Drop einfügen, hat dort ja genau den vergleichbaren(?) HTML Editor.

Der Tipp von LFischer mit dem Weg über die "Bilder" Kategorie wäre ein Workaround.
Dann kann man zumindest die hierüber verfügbare Bilder-URL für andere Bereiche der Dokumentation mit den verwendeten HTML-Editor nutzen.
Wäre halt Prima wenn dies über eine, wie auch immer geartete und angesprochene Zwischenschicht transparent ablaufen würden.

Schöne Feiertage an alle und kommt gut und gesund ins neue Jahr 2022.

@michael-overkamp
Danke!

Hallo @matthias-0

ja das sollte möglich sein und zwar kann man über die Console.php den Command import-jdiscdiscovery verwenden. Diesen Aufruf kann man über die API via

{ "jsonrpc": "2.0", "method": "console.import.jdiscdiscovery", "params": { "options": { "user": "admin", "password": "admin", "deviceHostname": "mein-mainlappi.fritz.box" }, "apikey": "h3md6u3y", "language": "en" }, "id": 1 }

Ausführen.

Hey @willpmu

wir haben mit i-doit 1.17 die Konfiguration der benutzerdefinierten Kategorien umgebaut, das dürfte allerdings keine Auswirkungen auf die Kategorien innerhalb der Objekte haben 🤔 Was genau meinst du mit:

Das Problem ist, dass ich neuerdings keine Möglichkeit mehr habe, den Report zuzuweisen. Es kommt nur mehr ein Beschreibungsfeld, aber keine Auswahl mehr.

Bezieht sich das auf die Konfiguration oder die Kategorie im Objekt? Hast du ggf. Screenshots von "vorher" (ggf. via Snapshot / Sicherung)?

Viele Grüße
Leo

Hallo @shquinn4com,

kurz und schmerzlos 😆

cmdb.category.save = Key -> object
cmdb.category.create = Key -> objID

Hallo @skussmann

ich bin nun endlich dazu gekommen das Problem nachzustellen - es stellt sich raus das die Daten in deinem Request nicht korrekt übergeben werden. Normalerweise meldet i-doit sich in einem solchen Fall mit einer Fehlermeldung... Hast du ggf. die "API Validierung" abgeschaltet?

Die Fehlermeldung würde so aussehen:

Internal error: There was an validation error [isys_obj__id: (object_browser) Property has to be an array.; isys_catg_cards_list__id: (object_browser) Property has to be an array.]

Da hier mit "Objekt Referenzen" gearbeitet wird (im Frontend geschieht dies über Objekt-Browser) muss die ID folgendermaßen übergeben werden:

{ "version": "2.0", "method": "cmdb.category.save", "params": { "object": 21001, "data": { "isys_obj__id": { "id": 21001 }, "isys_catg_cards_list__id": { "id": 21003 } }, "category": "C__CATG__ASSIGNED_SIM_CARDS", "apikey": "<apikey>" }, "id": 1 }

Ich schätze bei C__CATS__LAYER2_NET_ASSIGNED_PORTS dürfte es ein ähnliches Problem sein 🙂

Ich hoffe ich konnte dir weiterhelfen!

Viele Grüße
Leo

edit

Ich schätze hier müssen wir unsere API Doku noch mal anpassen, da diese falsche Informationen liefert 😞

Hallo zusammen,

@MartinV hatte es richtig erkannt - um die zugewiesenen Standorte eines Objekts zu erhalten braucht man die Methode cmdb.location_tree.read hier kann man mittels Parameter id entscheiden wessen "children" man sehen möchte.

Also z.B.

{ "version": "2.0", "method": "cmdb.location_tree.read", "params": { "id": 1234, "apikey": "<key>" }, "id": 1 }

Im Ergebnis erhält man dann ein Array mit allen direkt zugewiesenen Objekten, die Daten schauen dabei so aus (pro Objekt):

[ { "id": 302, "title": "0.01 Office", "sysid": "ROOM_00000302", "type": 26, "type_title": "Room", "status": 2, "cmdb_status": 6, "cmdb_status_title": "in operation" }, { "id": 1073, "title": "pool.ntp.org", "sysid": "CLOUD_0001073", "type": 39, "type_title": "Host", "status": 2, "cmdb_status": 6, "cmdb_status_title": "in operation" }, ... ]

Viele Grüße
Leo

Hallo @baloo66

mir ist eine solch detaillierte Suche im Code nicht bekannt - ich fürchte das hat hauptsächlich damit zu tun das solche Suchen bei Referenz-Werten sehr schwierig zu implementieren sind.

Es wäre vermutlich besser ein eigenes kleines Add-on mit einem API Endpunkt zu schreiben, sofern das nötige Know-How verfügbar ist. Wir haben einige Artikel zu dem Thema in unserer Knowledge Base hinterlegt.

Wäre das eine Option?

Viele Grüße
Leo

Hallo @mig ,

die Kurzfassung ist ganz einfach "Nein" 😉 Es dient tatsächlich nur dazu Debug-Ausgaben zu machen die für die Entwickler nötig sind. Der "normale" User soll diese nicht dargestellt bekommen.

Das wird auch nur sehr selten genutzt, falls wir z.B. Patches oder Hotfixes ausliefern.

VG Leo

Hallo @lfischer,

nach mehreren Tagen Fehleranalyse konnte ich den Fehler jetzt endlich finden. Der Error-Log an mir an der Stelle den entscheidenden Hinweis gegeben. Das Problem war eine fehlerhaft eingebundene Klasse. Diese habe ich nun entfernt und schon werden auch die Reports wieder angezeigt.

Vielen Dank für die Unterstützung.

Beste Grüße
Oliver

Hey @cwrm,

entschuldige die späte Antwort - aber gut zu sehen das du eine Lösung gefunden hast. Der Add-on Packager übernimmt genau diese Aufgabe indem die Konstante (isys_report__const) zum identifizieren genutzt wird.

Über diese Konstante kann die ID gefunden und referenziert werden 🙂 Das geschieht ebenfalls mittels der install Logik, da die update_data.xml keinerlei Logik ausführen kann - lediglich SQL Queries.

Vielleicht konnte ich hiermit noch ein wenig weiterhelfen?

Viele Grüße
Leo

Ok das war dann ein Missverständnis auf meiner Seite. Die alte API funktioniert erstmal weiter auch im 2.0 nur einige Funktionen sind nur in der neuen API verfügbar.
Danke

Das ergibt sich direkt aus der JSON-RPC Spezifikation. Im Abschnitt darunter auf der Seite sind auch Beispiele.

@philipp-hörselmann
Danke für die Antwort. Ich habe jetzt einen Workaround für meine Anwendung.
Allerdings wäre der Verlust der impact Funktion ein ziemliches Desaster.

Evtl gibt es ja eine andere Methode, die ich nioch nicht gesehen habe?

Ich bekomme den Namen eines Objektes. Über die Suchfunktion suche ich mir die ID heraus.
Jetzt muss ich alle Objekte, im idealfall nur bestimmte Typen, die mit diesem Objekt verknüpft sind, zurück bekommen, damit ich die Verbindung bearbeiten kann.
Die IDs der Verknpüften Objeket habe ich nicht.
Oder gibt es eine Möglichkeit, einen Objekttyp abzufragen, welcher Eintrag mit einer bestimmten ID verknüpft ist?

Ich versuche mal ein Beispiel:

Ein Benutzer (Kontakt) hat einen Notebook, 2 Monitore und einen Drucker verknüpft.
Wenn der Benutzer sich nun an einem anderen Platz anmeldet, liefert mir ein System die SN der (neu) verknüpften Systeme.
Um das in idoit nach zu ziehen, suche ich die ID des Benutzers und lasse mir über impact.read die Liste der Objeket geben. dort löse ich die Verknüpfung.
Danach suche ich die neuen Objekte und verknüpfe sie mit dem Kontakt.

Wenn ich natürlich eine Möglichkeit hätte, alle Monitore nach einer Verknüpfung mit KontaktID zu durchsuchen und bei dem Ergebnis die Verknüpfung zu lösen, wäre das schon klasse.

Hallo @cojo

es ist derzeit tatsächlich nicht möglich diese Daten mittels API zu schreiben. Die API unterstützt die speziellen Feldtypen nicht 😞

Viele Grüße
Leo

Problem hat sich tatächlich durch ein Update auf 1.16.2 (i-doit) und 1.12.1 (API) aufgelöst.

Danke und Grüsse
Matthias

Filter werden immer mit einem logischen UND verknüpft.

Um mehrere Objekttypen abzufragen (mit einem logischen ODER) machst Du einfach mehrere cmdb.objects.read-Anfragen (z.B. auch als eine Abfrage mit einem Array von Requests, sogen. Batch Request) und wirfst die Ergebnisse zusammen.

Hallo @philipp-hörselmann
Okay danke für die Antwort!