> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/german/fur-entwickler/partner-studio-guide.md).

# Partner-Studio-Leitfaden

Dieser Leitfaden richtet sich an Start-ups, Technologieanbieter und Lösungspartner, die sich mit — oder auf — BuildingPro Suites (BPS) integrieren möchten. Er beschreibt vier Integrationspfade, von einer leichten Datenanbindung bis hin zu einem vollständig gemeinsam entwickelten nativen Modul, und hilft Ihnen dabei, den richtigen Weg für Ihr Produkt und Geschäftsmodell zu wählen.

***

### 1. Warum mit BuildingPro Suites zusammenarbeiten?

BuildingPro Suites ist eine cloud-first Smart-Building-Plattform mit einer mehrschichtigen Architektur:

* **Pflichtbasis** — Konnektivität, Asset-Modellierung, Identität und Governance
* **Plattform-Toolbox** — Dashboards, Regeln, Analysen, APIs und App-Framework
* **Suiten** — vertikale Module wie Energy & Sustainability Intelligence, Occupant Experience und Space & Assets Analytics

Als Partner binden Sie sich an eine bestehende Unternehmensplattform mit über 100 OT-Protokollintegrationen, einem Marketplace, einer globalen ABB-Vertriebsorganisation und einem Hardware-Ökosystem an — statt all das selbst aufzubauen.

**Das zentrale architektonische Prinzip:** *Die Struktur gehört den Suites; Datenpunkte werden darauf abgebildet.* BuildingPro Suites enthält das kanonische Asset- und Standortmodell (Gebäude, Etagen, Räume, Anlagen). Welchen Integrationspfad Sie auch wählen, Ihre Daten und Funktionen werden an dieses Modell angebunden.

***

### 2. Die vier Integrationspfade auf einen Blick

Es gibt vier Möglichkeiten zur Integration, geordnet nach dem typischen Weg eines Partners:

```mermaid
flowchart LR
    A["**Option A**<br/>Eingebettete<br/>Partner-UI"] --> B["**Option B**<br/>Nur Daten<br/>MQTT / OPC UA"]
    B --> C["**Option C**<br/>Suites App<br/>Auto-Modellierung + KPIs"]
    C --> D["**Option D**<br/>Vollständiges Modul<br/>Gemeinsame Entwicklung"]

    style A fill:#e8f4fd,stroke:#0f62fe
    style B fill:#d0e8fb,stroke:#0f62fe
    style C fill:#b8dcf9,stroke:#0f62fe
    style D fill:#ff000f,stroke:#a30005,color:#fff
```

Die Optionen sind **nicht gegenseitig ausschließend** — viele Partnerschaften beginnen mit Option A oder B, um schnell Wert zu demonstrieren, und entwickeln sich dann zu C oder D weiter.

|                             | **A — Eingebettete UI**                    | **B — Nur Daten**                             | **C — Suites App**                                     | **D — Vollständiges Modul**                             |
| --------------------------- | ------------------------------------------ | --------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------- |
| **Was es ist**              | Ihre bestehende UI läuft innerhalb von BPS | Ihr System streamt Daten in BPS               | Sie entwickeln eine Connector-App auf dem App SDK      | Gemeinsam entwickeltes natives BPS-Modul                |
| **Wer entwickelt**          | Partner + BPS (Einbettung)                 | Partner (Datenexport)                         | Partner (mit BPS SDK)                                  | BPS-Entwicklungsteam + Fachkompetenz des Partners       |
| **Aufwand für den Partner** | Tage bis Wochen                            | Tage bis Wochen                               | Wochen bis Monate                                      | Monate (laufend)                                        |
| **Benutzererlebnis**        | Look & Feel des Partners                   | BPS-nativ (generisch)                         | BPS-nativ (vorlagenbasiert)                            | Einheitliche BPS-UX                                     |
| **Analysen & KI**           | Begrenzt (bleibt in der Partner-UI)        | Grundlegend (Rohdaten)                        | Standard-KPIs & Regeln                                 | Vollständige BPS-Analysen & KI                          |
| **Marketplace-Eintrag**     | Optional                                   | Nein                                          | Ja                                                     | Ja — wird als BPS-Modul verkauft                        |
| **Geschäftsmodell**         | Projekt / OEM                              | Projektbasiert                                | App-Lizenzierung                                       | Umsatzbeteiligung                                       |
| **Am besten geeignet für**  | Reife Partnerprodukte mit starker UI       | Schneller Proof of Value, bestehende BMS/GRMS | Wiederholbare, skalierbare Geräte-/Systemintegrationen | Tiefgehende Domänenlösungen (ESG, Gastgewerbe, Netz, …) |

***

### 3. Option B — Nur-Daten-Integration (MQTT / OPC UA / Events)

#### Konzept

Der einfachste Weg: Ihr System — zum Beispiel eine GRMS-, BMS- oder IoT-Plattform — veröffentlicht Daten über Standard-Schnittstellen wie **MQTT** oder **OPC UA**. BuildingPro Suites konsumiert, normalisiert und speichert die Daten gemäß seinem Asset-Modell. Von dort aus gelten alle Standard-Plattformfunktionen: Dashboards, Alarme, Regeln, Trendanalysen und Berichte.

Es ist keine Entwicklung auf Partnerseite gegen die BPS-APIs erforderlich — nur ein konfigurierte Datenexport aus Ihrem System.

#### Architektur

```mermaid
flowchart LR
    subgraph Partner["Partnersystem"]
        PS["GRMS / BMS /<br/>IoT-Plattform"]
    end

    subgraph Transport["Standard-Schnittstellen"]
        MQTT["MQTT-Broker"]
        OPC["OPC-UA-Server"]
    end

    subgraph BPS["BuildingPro Suites"]
        ING["Konnektivitätsschicht<br/>(Ingestion & Normalisierung)"]
        AM["Asset-Modell<br/>(kanonische Struktur)"]
        TS["Zeitreihen-Speicher"]
        VIS["Dashboards, Alarme,<br/>Regeln, Berichte"]
    end

    PS -->|publish| MQTT --> ING
    PS -->|expose| OPC --> ING
    ING -->|map data points| AM
    ING --> TS
    AM --> VIS
    TS --> VIS

    style BPS fill:#f5f5f5,stroke:#ff000f
```

#### So funktioniert es

1. **Struktur zuerst:** Die Gebäudestruktur (Standorte, Etagen, Räume, Assets) wird in BuildingPro Suites angelegt — dies ist das kanonische Modell.
2. **Verbinden:** Ihr System veröffentlicht in einer MQTT-Topic-Struktur oder stellt einen OPC-UA-Adressraum bereit.
3. **Zuordnen:** eingehende Datenpunkte werden BPS-Assets und -Attributen zugeordnet (Mapping-Hinweise aus Ihrer Payload-Struktur beschleunigen dies).
4. **Verwenden:** Daten stehen sofort für Dashboards, Alarmierung, Regeln und Suite-Analysen zur Verfügung.

#### Was Sie bereitstellen / was wir bereitstellen

| Partner stellt bereit                               | BuildingPro stellt bereit             |
| --------------------------------------------------- | ------------------------------------- |
| Datenexport via MQTT oder OPC UA                    | Ingestion, Normalisierung, Persistenz |
| Payload-Dokumentation (Topics, Einheiten, Semantik) | Asset-Modellierung und Mapping-Tools  |
| Testumgebung oder Beispieldaten                     | Dashboards, Alarme, Regeln, Reporting |

#### Wann Sie Option B wählen sollten

* Sie möchten den Wert in einem Pilotprojekt **innerhalb von Tagen statt Monaten**
* Ihr System spricht bereits MQTT oder OPC UA
* Die Hauptanforderung des Kunden ist *Daten-Transparenz* — Monitoring, Alarmierung, Berichterstattung

📖 Dokumentation: [Geräte an BuildingPro Suites anbinden](/collection/german/verpflichtende-basis/platform-core/connect-hub/connectivity-as-a-service.md)

***

### 4. Option C — Suites App: Daten + Auto-Modell + Auto-KPIs

#### Konzept

Sie entwickeln eine **Suites App** (Connector) unter Verwendung des **BuildingPro Suites App SDK**. Anders als bei Option B liefert Ihre App nicht nur Daten — sie treibt die Plattform aktiv an:

* Verbindet sich mit Ihrem System über dessen **REST-API oder SDK**
* **Erstellt Assets und Attribute automatisch** aus Vorlagen (Continuous Asset Creation)
* **Stellt KPIs, Zielwerte und Regeln automatisch bereit**
* **Stellt Standard-Dashboards bereit** sodass Kunden sofort eine funktionierende Lösung erhalten

Das Ergebnis ist eine wiederholbare, produktisierte Integration: App installieren, Zugangsdaten eingeben, und die komplette Lösung konfiguriert sich selbst. Dies ist der Standardweg zu einem **Marketplace-Eintrag**.

#### Architektur

```mermaid
flowchart LR
    subgraph Partner["Partner-Cloud / System"]
        API["Partner-REST-API / SDK"]
    end

    subgraph App["Partner Suites App (Docker)"]
        CONN["Connector-Logik (Go)"]
        CAC["Kontinuierliche Asset-Erstellung<br/>(Assets, Attribute, Mapping)"]
        PROV["Bereitstellung<br/>(KPIs, Zielwerte, Regeln,<br/>Dashboard-Vorlagen)"]
        DB[("App-Schema<br/>PostgreSQL")]
        OAPI["App-API<br/>(openapi.yaml)"]
    end

    subgraph BPS["BuildingPro Suites"]
        CORE["BPS-Kern"]
        RAPI["BPS-REST-API +<br/>WebSockets"]
        AM["Asset-Modell"]
        DASH["Dashboards & KPIs"]
        MP["Marketplace"]
    end

    API <-->|abfragen / abonnieren| CONN
    CONN --> CAC & PROV
    CAC & PROV -->|API_TOKEN| RAPI --> CORE
    CORE --> AM --> DASH
    CONN <--> DB
    OAPI -.->|Konfigurations-UI| CORE
    App -.->|gelistet & installiert über| MP

    style BPS fill:#f5f5f5,stroke:#ff000f
    style App fill:#e8f4fd,stroke:#0f62fe
```

#### Technischer Rahmen (App SDK)

Apps laufen als **Docker-Container** innerhalb einer BuildingPro Suites-Umgebung und folgen einem definierten Vertrag:

* **Sprache:** Go (vorgefertigte Client-Bibliotheken verfügbar)
* **Plattformzugriff:** ausschließlich über die BPS REST API und WebSockets (`API_ENDPOINT`, `API_TOKEN`)
* **Persistenz:** app-spezifisches Schema in PostgreSQL (`CONNECTION_STRING`)
* **App-API:** eigene Funktionen, die über eine benutzerdefinierte API bereitgestellt werden, beschrieben in `openapi.yaml` (`API_SERVER_PORT`)
* **Lebenszyklus:** Aktivierung → Installation → Initialisierung → Updates/Migration → Deinstallation
* **Best Practice:** Kontinuierliche Asset-Erstellung (CAC) — die App erkennt neue Geräte in Ihrem System und erstellt/aktualisiert/entfernt die entsprechenden BPS-Assets automatisch, einschließlich Dashboard-Vorlagen

Eine Mock-Umgebung ermöglicht Ihnen Entwicklung und Tests ohne vollständige BPS-Installation, und ein App-Template-Repository hilft Ihnen in wenigen Stunden den Einstieg.

#### Was Sie bereitstellen / was wir bereitstellen

| Partner stellt bereit                                | BuildingPro stellt bereit                                 |
| ---------------------------------------------------- | --------------------------------------------------------- |
| App-Entwicklung (Go, gegen das SDK)                  | App SDK, Client-Bibliotheken, App-Template, Mock-Umgebung |
| Asset-Vorlagen, KPI-Definitionen, Dashboard-Vorlagen | Review, Zertifizierung, Marketplace-Eintrag               |
| Wartung und Versionierung der App                    | Bereitstellungs-Framework, Plattformbetrieb               |

#### Wann Sie Option C wählen sollten

* Sie möchten ein **wiederholbares Produkt**, keine Integration pro Projekt
* Ihr System hat eine gute API, und Sie haben (oder können beschaffen) Go-Entwicklungskapazität
* Sie möchten Marketplace-Sichtbarkeit und eine Installation in Minuten für Kunden

📖 Dokumentation: [App SDK](/collection/german/fur-entwickler/app-sdk.md) · 💻 GitHub: [github.com/eliona-smart-building-assistant](https://github.com/eliona-smart-building-assistant)

***

### 5. Option A — Eingebettete Partner-UI

#### Konzept

Wenn Sie bereits eine ausgereifte, differenzierte Benutzeroberfläche haben, können wir sie direkt in BuildingPro Suites einbetten — der Kunde arbeitet in einer Plattform, und Ihr Produkt erscheint als nativer Bestandteil davon. Es stehen drei Einbettungsmuster zur Verfügung:

* **iFrame** — schnellster Weg; Ihre Web-App wird in einem BPS-Frame angezeigt
* **Webkomponente** — tiefere Integration; Ihre UI-Komponenten werden in BPS-Ansichten gerendert
* **Reverse Proxy** — BPS stellt Ihre UI unter seiner eigenen Domain bereit für ein nahtloses Erlebnis

Optional übergibt BPS **Kontext** an Ihre UI — z. B. das aktuell ausgewählte Hotel, Zimmer oder Asset — sodass sich Ihre Oberfläche an der richtigen Stelle öffnet („Deep Linking mit Kontext“).

#### Architektur

```mermaid
flowchart LR
    subgraph User["Benutzer"]
        BR["Browser<br/>(eine einzelne BPS-Sitzung)"]
    end

    subgraph BPS["BuildingPro Suites"]
        SHELL["BPS-UI-Shell<br/>(Navigation, Identität)"]
        CTX["Kontextanbieter<br/>(Standort / Raum / Asset,<br/>Benutzer, Sprache)"]
        RP["Reverse Proxy<br/>(optional)"]
    end

    subgraph Partner["Partnerprodukt"]
        PUI["Partner-Web-UI"]
        PBE["Partner-Backend"]
    end

    BR --> SHELL
    SHELL -->|iFrame / Web Component| PUI
    SHELL --> RP --> PUI
    CTX -->|Kontextparameter /<br/>postMessage| PUI
    PUI <--> PBE

    style BPS fill:#f5f5f5,stroke:#ff000f
    style Partner fill:#e8f4fd,stroke:#0f62fe
```

#### Design-Aspekte

* **Single Sign-on:** Token- oder Sitzungsübergabe, damit sich Benutzer nicht zweimal anmelden müssen
* **Kontextübergabe:** URL-Parameter oder `postMessage` für Asset-/Raum-/Benutzerkontext
* **Visuelle Anpassung:** optionales „leichtes Visu“-Styling, um Farben und Typografie an BPS anzugleichen
* **Kombinieren mit Option B:** viele Partner betten ihre UI ein *als auch* streamen Daten in BPS, sodass ihre Informationen auch in bereichsübergreifenden Dashboards und Berichten erscheinen

#### Wann Sie Option A wählen sollten

* Die UI Ihres Produkts ist ein zentraler Differenzierungsfaktor und eine Neuentwicklung ergibt keinen Sinn
* Sie müssen in der täglichen Plattform des Kunden präsent sein, ohne tiefgreifende Neuentwicklung
* Als Brücke: Behalten Sie heute Ihre UI und migrieren Sie Funktionen im Laufe der Zeit nativ

***

### 6. Option D — Gemeinsame Entwicklung eines vollständigen Moduls

#### Konzept

Die tiefste Partnerschaft: Wir kombinieren **Ihre Fachkompetenz** (Raumlogik, Workflows, KPIs, operative Prozesse, Compliance-Know-how) mit **unserer Plattform und Entwicklungskapazität** um ein **nativen BuildingPro-Suites-Modul** mit:

* **Einheitliche UX** — auf dem BPS-Designsystem aufgebaut, nicht vom Kern der Suites zu unterscheiden
* **Analysen & KI** — voller Zugriff auf die ML/AI-Funktionen der Plattform
* **Standard-KPIs** — produktisierte Kennzahlen, Zielwerte und Benchmarks für die Domäne

Das Modul wird zu einer verkäuflichen Einheit innerhalb von BuildingPro Suites — verkauft über ABBs globale Vertriebsorganisation und das Partnernetzwerk, mit einer **Umsatzbeteiligung** für Sie.

#### Architektur

```mermaid
flowchart TB
    subgraph Inputs["Partnerbeitrag"]
        DOM["Fachwissen<br/>(Anwendungsfälle, KPIs, Workflows)"]
        MKT["Marktzugang &<br/>Kundenverständnis"]
        VAL["Validierung & QA<br/>(fachliche Korrektheit)"]
    end

    subgraph Module["Natives BPS-Modul"]
        UX["Einheitliche UX<br/>(BPS-Designsystem)"]
        LOGIC["Geschäftslogik,<br/>Regeln & Workflows"]
        AI["Analysen & KI/ML"]
        KPI["Standard-KPIs<br/>& Datenmodelle"]
    end

    subgraph Platform["BuildingPro-Beitrag"]
        DEV["Entwicklungsteam<br/>(Backend, Frontend, QA, DevOps)"]
        PLAT["Plattform: Konnektivität,<br/>Asset-Modell, Identität"]
        GTM["Marketplace + globaler<br/>ABB-Vertrieb & Partner"]
        HW["Hardware-Ökosystem<br/>(Edge, Gateways, Sensoren)"]
    end

    Inputs --> Module
    Platform --> Module
    Module -->|"als Teil von BPS verkauft<br/>→ Umsatzbeteiligung"| GTM

    style Module fill:#ff000f,stroke:#a30005,color:#fff
    style Inputs fill:#e8f4fd,stroke:#0f62fe
    style Platform fill:#f5f5f5,stroke:#666
```

#### Der Co-Entwicklungsprozess

```mermaid
flowchart LR
    P1["**1. Ideenfindung<br/>& Scoping**<br/>Anwendungsfall, Markt,<br/>MVP-Definition"] --> P2["**2. Produkt<br/>& Design**<br/>KPIs, Datenmodelle,<br/>UX-Konzepte"]
    P2 --> P3["**3. Entwicklung<br/>& Integration**<br/>BPS-Entwicklungsteam baut,<br/>Partner validiert"]
    P3 --> P4["**4. Verpackung<br/>& Preisgestaltung**<br/>Lizenzierung, Marketplace,<br/>Vertriebsmaterialien"]
    P4 --> P5["**5. Markteinführung**<br/>gemeinsame Vertriebsstrategie,<br/>Enablement,<br/>Feedback-Loop"]
```

| Phase                                | Wesentliche Aktivitäten                                                                                                | Ergebnis                                             |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| **1 — Ideenfindung & Scoping**       | Gemeinsame Definition des Anwendungsfalls, Marktproblem, Zielkunden, MVP vs. Erweiterungen, grober Business Case       | Modulvision, Umfang, grobe Roadmap                   |
| **2 — Produkt & Design**             | Gemeinsame Workshops: KPIs, Datenmodelle, Workflows, User Journeys, UX-Mockups                                         | Produktanforderungen, UX-Konzepte, klarer MVP-Umfang |
| **3 — Entwicklung & Integration**    | Implementierung durch das BPS-Entwicklungsteam, regelmäßige Reviews und Demos, fachliche Validierung durch den Partner | Funktionsfähiges Modul, von beiden Seiten abgenommen |
| **4 — Verpackung & Preisgestaltung** | Lizenzierungs- und Preismodell, Marketplace-Positionierung, Produktbeschreibungen, Demo-Szenarien                      | Verkäufliches, gelistetes Modul                      |
| **5 — Markteinführung & Vertrieb**   | Gemeinsame Vertriebsstrategie, Enablement für ABB-Vertrieb und Partner, Aktivierung des Partnernetzwerks               | Umsatz- und Markt-Feedback-Loop                      |

#### Rollen

**Sie (Partner)** können eine oder mehrere Rollen übernehmen: Domänenverantwortliche/r / Fachexpertin/Fachexperte, Product Owner für das Modul, Co-Designer (UX), Qualitäts- und Validierungspartner, Go-to-Market- und Vertriebspartner, Geräte-/Hardware-Domänenexpertin/-experte.

**Wir (ABB / BuildingPro)** besitzen die Plattform und Architektur und stellen Entwicklung (Backend, Frontend, DevOps, QA, KI/ML), das UX/UI-Designsystem, Marketplace-Verpackung und Bereitstellung, globalen Vertrieb und Distribution sowie Betrieb, Support und Skalierung bereit.

#### Geschäftsmodell & IP

* **Umsatzbeteiligung:** Sie erhalten einen Anteil an jedem verkauften Modul. Der Anteil spiegelt Ihren Beitrag zum Produkt (IP, Fachwissen, Produktdefinition), Ihren Beitrag zu Vertrieb und Marketing sowie Ihre langfristige Rolle bei Wartung und Weiterentwicklung wider. Das konkrete Modell wird individuell pro Partner und Modul vereinbart.
* **IP & Eigentum:** Das Modul ist Teil von BuildingPro Suites; ABB betreibt, verkauft und wartet es. Sie bringen Domänen-IP und Fachwissen ein. Details zur IP-Nutzung, Lizenzierung und zu Rechten werden vertraglich geregelt.

#### Was wir erwarten / was Sie erwarten können

| Wir erwarten von Partnern                     | Partner können von uns erwarten                 |
| --------------------------------------------- | ----------------------------------------------- |
| Tiefes Domänenwissen                          | Zugang zur BPS-Plattform und Architektur        |
| Aktiver Produktbeitrag — nicht nur eine Idee  | Professionelle Produkt- und Softwareentwicklung |
| Verfügbarkeit für Reviews, Tests und Feedback | UX/UI, QA, DevOps und Betrieb                   |
| Marktzugang oder fundierte Marktkenntnisse    | Marktplatz und globale Vertriebsreichweite      |
| Langfristiges Interesse am Erfolg des Moduls  | Skalierung in Unternehmensumgebungen            |

***

### 7. Welche Option ist die richtige für Sie?

```mermaid
flowchart TD
    START["Was möchten Sie<br/>erreichen?"] --> Q1{"Möchten Sie vor allem, dass Ihre<br/>Daten in BPS sichtbar sind?"}
    Q1 -->|Ja, schnell| B["**Option B**<br/>Nur Daten über<br/>MQTT / OPC UA"]
    Q1 -->|Nein, mehr als Daten| Q2{"Haben Sie eine ausgereifte UI<br/>, die Ihr Alleinstellungsmerkmal ist?"}
    Q2 -->|Ja| A["**Option A**<br/>Eingebettete Partner-UI<br/>(oft mit B kombiniert)"]
    Q2 -->|Nein / UI ist zweitrangig| Q3{"Möchten Sie ein wiederholbares,<br/>selbstinstallierbares Produkt<br/>im Marketplace?"}
    Q3 -->|Ja| C["**Option C**<br/>Suites-App mit<br/>automatischem Modell & automatischen KPIs"]
    Q3 -->|"Wir möchten ein<br/>gemeinsames Geschäft aufbauen"| D["**Option D**<br/>Vollständige Modul-<br/>Gemeinschaftsentwicklung"]

    B -.->|mit der Zeit wachsen| C
    A -.->|nativ migrieren| D
    C -.->|Partnerschaft vertiefen| D

    style D fill:#ff000f,stroke:#a30005,color:#fff
```

**Faustregeln:**

* **Wert in einem Pilotprojekt nächsten Monat nachweisen** → Option B
* **Ein wiederholbares Integrationsprodukt ausliefern** → Option C
* **Ihre UI ist das Produkt** → Option A (plus B für domänenübergreifende Daten)
* **Bauen Sie ein gemeinsames Geschäft auf Basis geteilter Umsätze auf** → Option D

Und denken Sie daran: Das sind Phasen, keine Silos. Ein typischer Partnerweg ist **B → C → D** oder **A → D**.

***

### 8. Erste Schritte

1. **Beschreiben Sie Ihren Anwendungsfall** — eine kurze Beschreibung der Modul- oder Integrationsidee und des Kundenproblems, das sie löst
2. **Beschreiben Sie Ihr Fachwissen in der Domäne** — was Sie einbringen, was sonst niemand hat
3. **Gemeinsamer Scoping-Workshop** — wir ordnen Ihre Idee gemeinsam der passenden Option (A–D) zu
4. **Legen Sie das Setup fest** — technischer Weg, Rollen und kommerzieller Rahmen
5. **Starten** — Pilotprojekt (A/B), App-Entwicklung (C) oder Konzept- und Designphase (D)

**Kurz gesagt:** Sie bringen die Domänenexpertise, die Anwendungsfälle und den Markt mit — wir bringen die Plattform, die Skalierung und die Vertriebsmaschine mit. Gemeinsam bauen wir ein Produkt, das beiden Seiten beim Wachsen hilft.

📩 Kontaktieren Sie das BuildingPro Suites-Partnerteam, um einen Scoping-Workshop zu vereinbaren.

***

### Ressourcen

* **Dokumentation:** [Willkommen zum ABB Ability™ BuildingPro Suites-Leitfaden!](/collection/german/vorwort/readme.md)
* **App-SDK:** [App-SDK-Dokumentation](/collection/german/fur-entwickler/app-sdk.md)
* **GitHub (SDK, App-Vorlage, Mock, Client-Bibliotheken):** [github.com/eliona-smart-building-assistant](https://github.com/eliona-smart-building-assistant)
* **API-Referenz:** [api.eliona.io](https://api.eliona.io/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.buildings.ability.abb/collection/german/fur-entwickler/partner-studio-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.