Markt

​

Übersicht

Der Market ist FIM One’s Ressourcen-Marktplatz. Benutzer veröffentlichen Ressourcen, die sie erstellt haben, andere entdecken und abonnieren diese, und abonnierte Ressourcen erscheinen im Arbeitsbereich des Abonnenten, als wären sie ihre eigenen. Das gesamte System basiert auf einer einzigen architektonischen Erkenntnis: Der Market ist eine Organisation — eine vom System verwaltete Shadow-Org mit speziellen Vertrauensregeln. Diese Seite erläutert die interne Architektur des Market. Für einen benutzerorientierten Überblick über Veröffentlichung und Abonnement siehe Market (Features). Für die Frage, wie abonnierte Ressourcen in Werkzeugsätze geladen werden, siehe Agent & Resource Discovery.

​

Zwei-Ebenen-Klassifizierung

Der Marktplatz organisiert Ressourcen in zwei Kategorien basierend auf dem, was die Ressource tut, nicht auf ihrer Implementierung.

​

Lösungen

Lösungen sind Dinge, die für Sie funktionieren. Ein Benutzer abonniert eine Lösung und erhält eine einsatzbereite Funktionalität. Lösungen können von anderen Ressourcen abhängen. Ein Agent könnte einen bestimmten Connector für seine API-Aufrufe und eine Knowledge Base für seine Abruf-Pipeline benötigen. Der Market verwaltet diese Abhängigkeiten während des Abonnements automatisch (siehe Abhängigkeitsauflösung unten).

​

Komponenten

Komponenten sind wiederverwendbare Bausteine für Entwickler. Sie bieten Funktionen, die Lösungen nutzen. Komponenten sind einfacher zu abonnieren – sie haben keine internen Abhängigkeiten, nur Anforderungen an Anmeldedaten.

​

Warum Wissensdatenbanken nicht unabhängig aufgelistet werden

Wissensdatenbanken werden nicht als eigenständige Marktressourcen veröffentlicht. Sie sind interne Abhängigkeiten von Lösungen — eine Abruf-Pipeline eines Agenten oder Referenzmaterial einer Fähigkeit. Wenn ein Benutzer eine Lösung abonniert, die von einer Wissensdatenbank abhängt, wird die KB automatisch als schreibgeschützte Referenz eingebunden. Der Abonnent muss Wissensdatenbanken nie separat suchen, bewerten oder verwalten.

​

Einheitliche Architektur

​

Market als Schattenorganisation

Die wichtigste architektonische Entscheidung des Market ist, dass es kein separates Subsystem ist. Es ist eine Organisation — eine vom System verwaltete Org mit einer festen ID (MARKET_ORG_ID), die automatisch während der Plattforminitialisierung erstellt wird. Das bedeutet:

• Der gleiche Sichtbarkeitsfilter (build_visibility_filter()) verwaltet persönliche, Organisations- und Market-Ressourcen in einer einzigen Abfrage. Kein spezieller Code für Market-Lookups erforderlich.
• Der gleiche Abonnementmechanismus (ResourceSubscription) gilt für Organisations- und Market-Ressourcen. Das Abonnieren einer Organisationsressource und das Abonnieren einer Market-Ressource erstellen denselben Datensatz.
• Die gleiche Anmeldungsverwaltung (Fallback, Außerkraftsetzung pro Benutzer) funktioniert in beiden Kontexten. Das Flag allow_fallback auf Konnektoren und MCP-Servern verhält sich identisch, unabhängig von der Quelle.
• Der gleiche Überprüfungsprozess (apply_publish_status()) verwaltet sowohl Organisations- als auch Market-Überprüfungen. Der einzige Unterschied besteht darin, dass die Market-Organisation alle Überprüfungsflags auf true gesperrt hat.

Der Hauptunterschied zwischen einer regulären Organisation und der Market-Organisation:

​

Wie der Sichtbarkkeitsfilter damit umgeht

Niemand hat eine Mitgliedschaft in der Market-Organisation. Benutzer “treten” nicht dem Market bei — sie abonnieren einzelne Ressourcen. Das bedeutet, dass MARKET_ORG_ID nie in der user_org_ids-Liste eines Benutzers vorhanden ist, und die Sichtbarkeitsbedingung für die Organisationsmitgliedschaft wird für Market-Ressourcen natürlicherweise übersprungen. Stattdessen fließen abonnierte Market-Ressourcen durch den subscribed_ids-Pfad in build_visibility_filter(): Diese Drei-Bedingungen-OR-Klausel ist das gesamte Sichtbarkeitsmodell. Persönliche Ressourcen, organisationsübergreifend freigegebene Ressourcen und Market-abonnierte Ressourcen werden in einer Abfrage aufgelöst, ohne dass eine Verzweigungslogik für verschiedene Ressourcenursprünge erforderlich ist.

​

Bereichsbasiertes Durchsuchen

Die Market-Seite bietet einen Bereichsselektor, der zwischen zwei Browsing-Kontexten wechselt: Die gleiche Benutzeroberfläche, die gleichen Registerkarten (Solutions / Components) und der gleiche Abonnement-Ablauf gelten in beiden Bereichen. Das Wechseln des Bereichs ändert nur den org_id-Filter in der Browse-Abfrage. Aus Benutzersicht ist die Erfahrung identisch – sie durchsuchen einen Katalog und wählen aus, was installiert werden soll.

​

Abonnement-Ablauf

​

Durchsuchen und Entdeckung

Benutzer durchsuchen den Markt durch einen paginierten Katalog. Jede Ressource zeigt ihren Namen, Beschreibung, Symbol, Benutzernamen des Herausgebers und eine Abonnieren-Schaltfläche an. Ressourcen, die der Benutzer bereits abonniert hat, werden entsprechend gekennzeichnet. Die Browse-API (GET /api/market) schließt die eigenen Ressourcen des Benutzers aus — Sie können nicht etwas abonnieren, das Sie veröffentlicht haben.

​

Abonnement einer Lösung

Das Abonnement einer Lösung (Agent, Skill oder Workflow) umfasst eine Abhängigkeitsanalyse:

1. Das System analysiert die Abhängigkeiten der Lösung — welche Konnektoren, Wissensdatenbanken, MCP-Server und Skills erforderlich sind.
2. Inhaltsabhängigkeiten (KB, Skill) werden automatisch und stillschweigend abonniert. Der Benutzer sieht oder verwaltet diese nicht.
3. Verbindungsabhängigkeiten (Konnektor, MCP-Server) werden als Anforderungen aufgelistet. Ein Onboarding-Assistent erfasst Anmeldedaten.
4. Der ResourceSubscription-Datensatz wird erstellt, und die Ressource wird im Sichtbarkeitsfilter des Benutzers angezeigt.

​

Abonnement für eine Komponente

Komponenten (Konnektoren und MCP-Server) haben einen einfacheren Ablauf – es ist keine Abhängigkeitsanalyse erforderlich. Der Benutzer abonniert, konfiguriert optional Anmeldedaten, und die Komponente ist einsatzbereit.

​

Anmeldedaten-Konfiguration

Anmeldedaten folgen einem Hybrid-Modell, das Benutzerfreundlichkeit mit Flexibilität verbindet:

• Während des Abonnements angeboten. Wenn eine Verbindungstyp-Abhängigkeit Anmeldedaten erfordert, präsentiert der Onboarding-Assistent das Anmeldedatenformular sofort.
• Überspringbar. Der Benutzer kann “Überspringen, später konfigurieren” wählen. Die Ressource wird abonniert, aber Tools, die diese Anmeldedaten benötigen, geben eine Meldung “Bitte konfigurieren Sie Ihre Anmeldedaten” zurück, wenn sie aufgerufen werden.
• Aufgeschobene Konfiguration. Benutzer können Anmeldedaten jederzeit auf ihrer Einstellungsseite konfigurieren oder aktualisieren.

Dies ist derselbe allow_fallback-Mechanismus, der in Organisationen verwendet wird. Wenn der Herausgeber das Fallback aktiviert hat und einen Standard-Anmeldedatensatz festgelegt hat, können Abonnenten die Ressource sofort nutzen, ohne ihren eigenen Schlüssel bereitzustellen. Wenn das Fallback deaktiviert ist, muss jeder Abonnent seinen eigenen Schlüssel bereitstellen.

​

Abmelden

Das Abmelden entfernt den ResourceSubscription-Datensatz. Die Ressource verschwindet aus dem Sichtbarkeitsfilter des Benutzers und wird nicht mehr in Tool-Sets geladen. Bei Lösungen mit automatisch abonnierten Abhängigkeiten werden die abhängigen Ressourcen (KBs, Skills) ebenfalls bereinigt. Benutzerkonfigurierte Anmeldedaten für die Ressource werden entfernt.

​

Abhängigkeitsauflösung

Wenn eine Lösung veröffentlicht oder abonniert wird, analysiert das System ihren Abhängigkeitsbaum. Abhängigkeiten fallen in zwei Kategorien mit unterschiedlichen Behandlungsstrategien.

​

Inhaltstyp-Abhängigkeiten

Wissensdatenbanken und Fähigkeiten, auf die eine Lösung verweist, sind Inhaltstyp-Abhängigkeiten. Sie stellen schreibgeschützte Daten bereit — Abrufdokumente, SOP-Verfahren — die die Lösung nutzt.

• Bei Abonnement: automatisch im Hintergrund abonniert. Der Benutzer sieht keinen separaten Abonnementschritt für jede Wissensdatenbank oder Fähigkeit.
• Zugriffsmodell: schreibgeschützter Verweis auf die Ressource des ursprünglichen Autors. Der Abonnent kann den Inhalt nicht ändern.
• Bei Kündigung des Abonnements: automatisch bereinigt, wenn die übergeordnete Lösung abgemeldet wird.

​

Verbindungstyp-Abhängigkeiten

Konnektoren und MCP-Server, auf die eine Lösung verweist, sind Verbindungstyp-Abhängigkeiten. Sie benötigen Anmeldedaten zum Funktionieren.

• Bei Abonnement: aufgelistet als Anforderungen im Onboarding-Assistent. Der Benutzer wird aufgefordert, Anmeldedaten zu konfigurieren (oder zu überspringen).
• Intelligente Zuordnung: Wenn der Benutzer bereits über einen kompatiblen Konnektor verfügt (gleicher Typ, gleiche Basis-URL), bietet das System an, ihn wiederzuverwenden, anstatt ein neues Abonnement zu erstellen.
• Bei Kündigung des Abonnements: Das Abonnement wird entfernt, aber von Benutzern erstellte Anmeldedaten werden beibehalten (der Benutzer kann denselben Konnektor an anderer Stelle verwenden).

​

Veröffentlichung

​

Eine Lösung veröffentlichen

Wenn ein Autor einen Agent, eine Skill oder einen Workflow auf dem Markt veröffentlicht:

1. Das System setzt visibility: "org" und org_id: MARKET_ORG_ID auf die Ressource.
2. Das System analysiert die Abhängigkeiten der Lösung und erstellt ein Manifest — das erforderliche Konnektoren, Wissensdatenbanken und MCP-Server auflistet.
3. Das Manifest wird dem Autor zur Bestätigung angezeigt.
4. apply_publish_status() setzt die Ressource auf pending_review (die Market-Organisation hat alle Review-Flags auf true gesperrt).
5. Ein Systemadministrator überprüft und genehmigt oder lehnt die Ressource ab.

​

Veröffentlichung einer Komponente

Die Veröffentlichung eines Connectors oder MCP-Servers ist einfacher:

1. Das System legt Sichtbarkeit und org_id wie oben fest.
2. Das Credential-Schema wird extrahiert (welche Felder Abonnenten ausfüllen müssen).
3. Die Ressource wechselt in den Status pending_review und wartet auf die Genehmigung durch einen Administrator.

​

Überprüfungsprozess

Der Überprüfungsprozess ist derselbe Mechanismus, der von Organisationen verwendet wird, mit einem kritischen Unterschied: Die Marktplatz-Org wird mit allen sechs Überprüfungs-Flags auf true initialisiert, und diese Konfiguration kann nicht geändert werden. Jede Ressource, die auf dem Marktplatz veröffentlicht wird, muss die Admin-Überprüfung bestehen, bevor sie im Browse-Katalog sichtbar wird. Wenn eine genehmigte Ressource von ihrem Autor bearbeitet wird, setzt check_edit_revert() automatisch den publish_status auf pending_review zurück. Dies stellt sicher, dass Änderungen an Live-Marktplatz-Ressourcen erneut überprüft werden, bevor sie für Abonnenten sichtbar werden.

​

Implementierungshinweise

​

Die Shadow-Organisation

Die Market-Organisation hat eine bekannte feste ID (00000000-0000-0000-0000-000000000001) und einen Slug (market). Sie wird von ensure_market_org() während der Plattforminitialisierung erstellt — typischerweise beim ersten Login des Admin-Benutzers. Die Funktion ist idempotent; das mehrfache Aufrufen ist sicher.

​

ResourceSubscription

Die ResourceSubscription-Tabelle ist die zentrale Datenstruktur für den Marketplace-Zugriff: Eine eindeutige Einschränkung auf (user_id, resource_type, resource_id) verhindert doppelte Abonnements. Die org_id-Spalte verfolgt, woher das Abonnement stammt, und ermöglicht bereichsbewusstes Abmelden.

​

Sichtbarkeitsfiltter-Integration

Die Funktion resolve_visibility() führt zwei Abfragen in einem einzigen Aufruf durch:

1. Ruft die Organisationsmitgliedschaften des Benutzers ab (user_org_ids)
2. Ruft die Abonnements des Benutzers ab (subscribed_ids)

Diese werden an build_visibility_filter() übergeben, die eine einzelne SQL WHERE-Klausel erzeugt, die alle drei Sichtbarkeitsstufen kombiniert (eigene, organisationsweit freigegeben, abonniert). Diese Funktion wird überall dort verwendet, wo Ressourcen abgefragt werden — Agentenlisten, Konnektordropdowns, Skill-Injektion, Auto-Discovery-Modus — und gewährleistet so konsistente Sichtbarkeit auf der gesamten Plattform.

​

Anmeldedaten-Verschlüsselung

Anmeldedaten, die während des Abonnements (oder später in den Einstellungen) konfiguriert werden, werden im Ruhezustand mit dem Verschlüsselungsschlüssel der Plattform verschlüsselt. Die Market API gibt niemals Anmeldedatenwerte in Browse-Antworten preis — nur Metadaten (Name, Beschreibung, Symbol, Typ) werden in den _*_market_info()-Hilfsfunktionen zurückgegeben.

​

Siehe auch

• Organization & Market — Freigabe- und Vertrauensmodell auf Organisationsebene
• Agent & Resource Discovery — wie abonnierte Ressourcen in Tool-Sets geladen werden
• Connector Architecture — Connector-Design, Auth-Injection und Audit
• System Overview — die einheitliche Tool-Abstraktion, in die alle Ressourcen konvergieren