> 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-leitfaden.md). # Partner-Studio-Leitfaden Dieser Leitfaden richtet sich an Startups, Technologieanbieter und Lösungspartner, die sich mit BuildingPro Suites (BPS) integrieren oder darauf aufbauen möchten. Er beschreibt vier Integrationspfade, von einer leichtgewichtigen Datenanbindung bis hin zu einem vollständig gemeinsam entwickelten nativen Modul, und hilft Ihnen, den richtigen 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: * **Verpflichtende Basis** — Konnektivität, Asset-Modellierung, Identität und Governance * **Plattform-Werkzeuge** — Dashboards, Regeln, Analytik, APIs und App-Framework * **Suites** — vertikale Module wie Energy & Sustainability Intelligence, Occupant Experience und Space & Assets Analytics Als Partner binden Sie sich an eine bestehende Enterprise-Plattform 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, Geräte). Unabhängig davon, welchen Integrationspfad Sie wählen, werden Ihre Daten und Funktionen an dieses Modell angehängt. *** ### 2. Die vier Integrationspfade auf einen Blick Es gibt vier Möglichkeiten zur Integration, geordnet nach zunehmender Tiefe der Integration und Partnerschaft: ```mermaid flowchart LR     A["**Option A**
Nur Daten
MQTT / OPC UA"] --> B["**Option B**
Suites App
Auto-Modell + KPIs"]     B --> C["**Option C**
Eingebettet
Partner-UI"]     C --> D["**Option D**
Vollständiges Modul
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 C, um schnell Wert zu demonstrieren, und entwickeln sich dann in Richtung B oder D weiter. | | **A — Nur Daten** | **B — Suites App** | **C — Eingebettete UI** | **D — Vollständiges Modul** | | --------------------------- | --------------------------------------------- | ------------------------------------------------------ | ------------------------------------------ | ------------------------------------------------------- | | **Was es ist** | Ihr System streamt Daten in BPS | Sie bauen eine Connector-App auf dem App SDK | Ihre bestehende UI läuft innerhalb von BPS | Gemeinsam entwickeltes natives BPS-Modul | | **Wer entwickelt** | Partner (Datenexport) | Partner (mit BPS SDK) | Partner + BPS (Einbettung) | BPS-Entwicklungsteam + Domänenexpertise des Partners | | **Aufwand für den Partner** | Tage–Wochen | Wochen–Monate | Tage–Wochen | Monate (fortlaufend) | | **Benutzererlebnis** | BPS-nativ (generisch) | BPS-nativ (vorlagenbasiert) | Look & Feel des Partners | Einheitliche BPS-UX | | **Analytik & KI** | Basis (Rohdaten) | Standard-KPIs & Regeln | Begrenzt (bleibt in der Partner-UI) | Vollständige BPS-Analytik & KI | | **Marketplace-Eintrag** | Nein | Ja | Optional | Ja — wird als BPS-Modul verkauft | | **Geschäftsmodell** | Projektbasiert | App-Lizenzierung | Projekt / OEM | Umsatzbeteiligung | | **Am besten geeignet für** | Schneller Proof of Value, bestehende BMS/GRMS | Wiederholbare, skalierbare Geräte-/Systemintegrationen | Ausgereifte Partnerprodukte mit starker UI | Tiefgehende Domänenlösungen (ESG, Hospitality, Netz, …) | *** ### 3. Option A — 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 in Bezug auf sein Asset-Modell. Von dort aus gelten alle Standardfunktionen der Plattform: Dashboards, Alarme, Regeln, Trendanalyse und Berichte. Es ist keine Entwicklung auf Seiten des Partners gegen BPS-APIs erforderlich — nur ein konfigurierte Datenexport aus Ihrem System. #### Architektur ```mermaid flowchart LR     subgraph Partner["Partnersystem"]         PS["GRMS / BMS /
IoT-Plattform"]     end     subgraph Transport["Standard-Schnittstellen"]         MQTT["MQTT-Broker"]         OPC["OPC-UA-Server"]     end     subgraph BPS["BuildingPro Suites"]         ING["Konnektivitätsschicht
(Ingestion & Normalisierung)"]         AM["Asset-Modell
(kanonische Struktur)"]         TS["Zeitreihenspeicher"]         VIS["Dashboards, Alarme,
Regeln, Berichte"]     end     PS -->|veröffentlichen| MQTT --> ING     PS -->|bereitstellen| OPC --> ING     ING -->|Datenpunkte zuordnen| 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 erstellt — das 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 (Hinweise zur Zuordnung aus Ihrer Payload-Struktur beschleunigen dies). 4. **Nutzen:** Daten sind sofort für Dashboards, Alarmierung, Regeln und Suite-Analytik verfügbar. #### 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) | Werkzeuge für Asset-Modellierung und Zuordnung | | Testumgebung oder Beispieldaten | Dashboards, Alarme, Regeln, Berichte | #### Wann Option A wählen * Sie wollen in einem Pilotprojekt Wert demonstrieren **innerhalb von Tagen, nicht Monaten** * Ihr System spricht bereits MQTT oder OPC UA * Das Hauptbedürfnis des Kunden ist *Datenübersicht* — Überwachung, Alarmierung, Berichterstattung 📖 Dokumentation: [Geräte mit BuildingPro Suites verbinden](/collection/german/pflichtbasis/platform-core/connect-hub/connectivity-as-a-service.md) *** ### 4. Option B — 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 A 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, Ziele 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 vollständige 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
(Assets, Attribute, Zuordnung)"]         PROV["Bereitstellung
(KPIs, Ziele, Regeln,
Dashboard-Vorlagen)"]         DB[("App-Schema
PostgreSQL")]         OAPI["App-API
(openapi.yaml)"]     end     subgraph BPS["BuildingPro Suites"]         CORE["BPS-Core"]         RAPI["BPS REST API +
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** in 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 Entwicklung und Tests ohne vollständige BPS-Installation, und ein App-Template-Repository bringt Sie in Stunden zum Start. #### Was Sie bereitstellen / was wir bereitstellen | Partner stellt bereit | BuildingPro stellt bereit | | ---------------------------------------------------- | --------------------------------------------------------- | | App-Entwicklung (Go, basierend auf dem 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 Option B wählen * Sie wollen ein **wiederholbares Produkt**, keine projektspezifische Integration * Ihr System hat eine gute API und Sie verfügen über Go-Entwicklungskapazitäten (oder können diese beschaffen) * 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 C — 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 Teil davon. Drei Einbettungsmuster stehen zur Verfügung: * **iFrame** — schnellster Weg; Ihre Web-App ist in einer BPS-Seite eingebettet * **Web Component** — tiefere Integration; Ihre UI-Komponenten werden in BPS-Ansichten gerendert * **Reverse-Proxy** — BPS stellt Ihre UI unter seiner eigenen Domain für ein nahtloses Erlebnis bereit Optional übergibt BPS **Kontext** an Ihre UI — z. B. das aktuell ausgewählte Hotel, Zimmer oder Asset — sodass Ihre Oberfläche an der richtigen Stelle öffnet ("Deep Linking mit Kontext"). #### Architektur ```mermaid flowchart LR     subgraph User["Benutzer"]         BR["Browser
(eine einzelne BPS-Sitzung)"]     end     subgraph BPS["BuildingPro Suites"]         SHELL["BPS UI Shell
(Navigation, Identität)"]         CTX["Kontext-Provider
(Standort / Raum / Asset,
Benutzer, Sprache)"]         RP["Reverse-Proxy
(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 /
postMessage| PUI     PUI <--> PBE     style BPS fill:#f5f5f5,stroke:#ff000f     style Partner fill:#e8f4fd,stroke:#0f62fe ``` #### Designüberlegungen * **Single Sign-on:** Token- oder Sitzungsübergabe, damit sich Benutzer nicht zweimal anmelden * **Kontextübergabe:** URL-Parameter oder `postMessage` für Asset-/Raum-/Benutzerkontext * **Visuelle Passung:** optional ein „lightweight visu“-Styling, um Farben und Typografie an BPS anzupassen * **Mit Option A kombinieren:** viele Partner betten ihre UI ein *und* streamen Daten in BPS, sodass ihre Informationen auch in domänenübergreifenden Dashboards und Berichten erscheinen #### Wann Option C wählen * Die UI Ihres Produkts ist ein zentrales Differenzierungsmerkmal, und ein Neuaufbau ergibt keinen Sinn * Sie müssen in der täglichen Plattform des Kunden präsent sein, ohne tiefgreifendes Re-Engineering * Als Brücke: behalten Sie Ihre UI zunächst bei und migrieren Sie die Funktionalität im Laufe der Zeit nativ *** ### 6. Option D — Gemeinsame Entwicklung eines vollständigen Moduls #### Konzept Die tiefste Partnerschaft: Wir kombinieren **Ihr Fachwissen im Anwendungsbereich** (Raumlogik, Workflows, KPIs, operative Prozesse, Compliance-Know-how) mit **unserer Plattform und Entwicklungskapazität** um ein **natives BuildingPro-Suites-Modul** zu entwickeln mit: * **Einheitliche UX** — basiert auf dem BPS-Designsystem und ist von den Kern-Suites nicht zu unterscheiden * **Analytik & KI** — voller Zugriff auf die ML/AI-Funktionen der Plattform * **Standard-KPIs** — produktisierte Metriken, Ziele und Benchmarks für die Domäne Das Modul wird zu einer verkaufbaren Einheit innerhalb von BuildingPro Suites — verkauft über die globale Vertriebsorganisation von ABB und das Partnernetzwerk, mit einer **Umsatzbeteiligung** für Sie. #### Architektur ```mermaid flowchart TB     subgraph Inputs["Beiträge des Partners"]         DOM["Domänen-Know-how
(Anwendungsfälle, KPIs, Workflows)"]         MKT["Marktzugang &
Kundenverständnis"]         VAL["Validierung & QA
(fachliche Korrektheit)"]     end     subgraph Module["Natives BPS-Modul"]         UX["Einheitliche UX
(BPS-Designsystem)"]         LOGIC["Geschäftslogik,
Regeln & Workflows"]         AI["Analytik & KI/ML"]         KPI["Standard-KPIs
& Datenmodelle"]     end     subgraph Platform["BuildingPro-Beitrag"]         DEV["Entwicklungsteam
(Backend, Frontend, QA, DevOps)"]         PLAT["Plattform: Konnektivität,
Asset-Modell, Identität"]         GTM["Marketplace + globaler
ABB-Vertrieb & Partner"]         HW["Hardware-Ökosystem
(Edge, Gateways, Sensoren)"]     end     Inputs --> Module     Platform --> Module     Module -->|"als Teil von BPS verkauft
→ Umsatzbeteiligung"| GTM     style Module fill:#ff000f,stroke:#a30005,color:#fff     style Inputs fill:#e8f4fd,stroke:#0f62fe     style Platform fill:#f5f5f5,stroke:#666 ``` #### Der Co-Development-Prozess ```mermaid flowchart LR     P1["**1. Ideenfindung
& Abgrenzung**
Anwendungsfall, Markt,
MVP-Definition"] --> P2["**2. Produkt
& Design**
KPIs, Datenmodelle,
UX-Konzepte"]     P2 --> P3["**3. Entwicklung
& Integration**
BPS-Entwicklungsteam baut,
Partner validiert"]     P3 --> P4["**4. Verpackung
& Preisgestaltung**
Lizenzierung, Marketplace,
Vertriebsmaterialien"]     P4 --> P5["**5. Markteinführung
& Vertrieb**
gemeinsame Vertriebsstrategie,
Enablement,
Feedback-Schleife"] ``` | Phase | Hauptaktivitäten | Ergebnis | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | **1 — Ideenfindung & Abgrenzung** | 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** | Umsetzung durch das BPS-Entwicklungsteam, regelmäßige Reviews und Demos, fachliche Validierung durch den Partner | Funktionierendes Modul, von beiden Seiten akzeptiert | | **4 — Verpackung & Preisgestaltung** | Lizenz- und Preismodell, Marketplace-Positionierung, Produktbeschreibungen, Demoszenarien | Verkaufbares, gelistetes Modul | | **5 — Markteinführung & Vertrieb** | Gemeinsame Vertriebsstrategie, Enablement für ABB-Vertrieb und Partner, Aktivierung des Partnernetzwerks | Umsatz- und Markt-Feedback-Schleife | #### Rollen **Sie (Partner)** kann eine oder mehrere Rollen übernehmen: Domänenverantwortlicher / Fachexperte, Product Owner für das Modul, Mitgestalter (UX), Qualitäts- & Validierungspartner, Go-to-Market- & Vertriebspartner, Geräte-/Hardware-Domänenexperte. **Wir (ABB / BuildingPro)** besitzen die Plattform und Architektur und stellen die Entwicklung (Backend, Frontend, DevOps, QA, KI/ML), das UX/UI-Designsystem, das Marketplace-Packaging und -Deployment, den weltweiten Vertrieb und die Distribution sowie den Betrieb, den Support und die 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 für jeden Partner und jedes Modul individuell vereinbart. * **IP & Eigentum:** das Modul ist Teil von BuildingPro Suites; ABB betreibt, verkauft und wartet es. Sie bringen domänenspezifische IP und Know-how ein. Details zur IP-Nutzung, Lizenzierung und zu den 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, Feedback | UX/UI, QA, DevOps und Betrieb | | Marktzugang oder starkes Marktverständnis | Marketplace 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
erreichen?"] --> Q1{"Möchten Sie vor allem,
dass Ihre Daten in BPS sichtbar sind?"}     Q1 -->|Ja, schnell| A["**Option A**
Nur Daten via
MQTT / OPC UA"]     Q1 -->|Nein, mehr als Daten| Q2{"Haben Sie eine ausgereifte UI,
die Ihr Differenzierungsmerkmal ist?"}     Q2 -->|Ja| C["**Option C**
Eingebettete Partner-UI
(oft kombiniert mit A)"]     Q2 -->|Nein / UI ist sekundär| Q3{"Möchten Sie ein wiederverwendbares,
selbstinstallierendes Produkt
im Marketplace?"}     Q3 -->|Ja| B["**Option B**
Suites App mit
automatischem Modell & automatischen KPIs"]     Q3 -->|"Wir möchten ein gemeinsames
Geschäft aufbauen"| D["**Option D**
Vollständige Modul-Co-Entwicklung"]     A -.->|mit der Zeit wachsen| B     C -.->|nativ migrieren| D     B -.->|Partnerschaft vertiefen| D     style D fill:#ff000f,stroke:#a30005,color:#fff ``` **Faustregeln:** * **Im nächsten Monat den Wert in einem Pilotprojekt belegen** → Option A * **Ein wiederverwendbares Integrationsprodukt liefern** → Option B * **Ihre UI ist das Produkt** → Option C (plus A für domänenübergreifende Daten) * **Ein gemeinsames Geschäft auf Basis gemeinsamer Umsätze aufbauen** → Option D Und denken Sie daran: Das sind Phasen, keine Silos. Eine typische Partnerreise ist **A → B → D** oder **C → D**. *** ### 8. Einstieg 1. **Beschreiben Sie Ihren Anwendungsfall** — eine kurze Skizze des Moduls oder der Integrationsidee und des Kundenproblems, das es löst 2. **Beschreiben Sie Ihr Domänenwissen** — was Sie mitbringen, das sonst niemand hat 3. **Gemeinsamer Scoping-Workshop** — wir ordnen Ihre Idee gemeinsam der richtigen Option (A–D) zu 4. **Legen Sie das Setup fest** — technischer Weg, Rollen und kommerzieller Rahmen 5. **Start** — Pilot (A/C), App-Entwicklung (B) oder Konzept- und Designphase (D) **Kurz gesagt:** Sie bringen das Domänenwissen, die Anwendungsfälle und den Markt mit — wir bringen die Plattform, die Skalierung und den Vertriebsmechanismus. Gemeinsam bauen wir ein Produkt, das beiden Seiten beim Wachstum hilft. 📩 Kontaktieren Sie das BuildingPro Suites-Partnerteam, um einen Scoping-Workshop zu vereinbaren. *** ### Ressourcen * **Dokumentation:** [Willkommen im Leitfaden zu ABB Ability™ BuildingPro Suites!](/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-leitfaden.md?ask=&goal= ``` `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.