JavaScript ist ausgeschaltet. Alle Kapitel sind lesbar. Für eine andere Sprache die entsprechende Datei aus dem vollständigen Anleitungspaket öffnen.Deutsch · English · Español

Vorbereitung der pony-Installation

Diese Anleitung beschreibt, was Ihre IT vor der Installation im Portal bereitstellen muss. Gehen Sie die Kapitel mit den zuständigen SAP-Administratoren durch. Die Einrichtungsschritte stehen jeweils unter „Einrichten“.

SAP Business Technology Platform (SAP BTP) stellt die Anwendungen und Datenbank bereit. SAP Identity Authentication Service (IAS) übernimmt die Anmeldung. Über eine Programmierschnittstelle (API) verbindet sich pony mit SAP Cloud ALM.

Zu beachten: Für eine Neuinstallation einen leeren Cloud-Foundry-Space verwenden. Bei Updates nichts leeren, löschen oder neu anlegen; vorhandene IDs, Services und Daten beibehalten. Den Updateablauf verwenden.

Begriffe und Beispiele

Die Beispiele beziehen sich auf die fiktive Musterfirma GmbH und deren Produktivsystem. Ersetzen Sie Platzhalter wie <app-name> vollständig, einschließlich der Klammern. Bei Updates bleiben vorhandene Namen erhalten. Operation bezeichnet die technische Verwaltung Ihrer pony-Installation, getrennt vom Zugang der Fachanwender.

Angabe	Bedeutung
App-Name `<app-name>`	Name der Anwendung im Cloud-Foundry-Space, z. B. pony-musterfirma-prod. Ein Space ist ein Bereich für Anwendungen und Services in SAP BTP.
Mandanten-ID `<tenant-id>`	Kennung dieser pony-Umgebung, z. B. musterfirma-prod. Nicht die ID des SAP-BTP-Subaccounts.
Mandantengruppe `<tenant-group>`	Fasst mehrere pony-Umgebungen zusammen, z. B. musterfirma für Test und Produktion. Keine IAS-Benutzergruppe.
Kunden-Hostname `<customer-host>`	Erster Teil der pony-Webadresse vor dem ersten Punkt, z. B. pony-musterfirma-prod. Nur diesen Namen eintragen, nicht die vollständige URL.
Operation-Hostname `<operation-host>`	Erster Teil der separaten Verwaltungsadresse, z. B. pony-musterfirma-prod-operation.
Cloud-Foundry-Routendomain `<cf-domain>`	Gemeinsamer Rest der Webadresse, z. B. cfapps.eu10-005.hana.ondemand.com. Den tatsächlichen Wert im BTP Cockpit unter Cloud Foundry → Domains übernehmen.
Kunden-URL `https://<customer-host>.<cf-domain>`	Vollständige Adresse für Fachanwender, z. B. https://pony-musterfirma-prod.cfapps.eu10-005.hana.ondemand.com.
Operation-URL `https://<operation-host>.<cf-domain>`	Vollständige Verwaltungsadresse, z. B. https://pony-musterfirma-prod-operation.cfapps.eu10-005.hana.ondemand.com.
IAS-Hostname für Kundenlogin `<ias-customer-host>`	Adresse des SAP-Anmeldedienstes, z. B. musterfirma.accounts.ondemand.com. Den echten Host aus Ihrer IAS-Adresse übernehmen, ohne https:// oder /admin. Nicht die pony-Webadresse.
IAS-Hostname für Operation `<ias-operation-host>`	Adresse des Anmeldedienstes für die technische Verwaltung. Darf derselbe IAS-Hostname sein; Anwendung und Zugangsdaten bleiben getrennt.
Destination-Präfix `<destination-prefix>`	Gemeinsamer Namensanfang der gespeicherten Verbindungen, z. B. PONY_MUSTERFIRMA_PROD. Daraus entsteht etwa PONY_MUSTERFIRMA_PROD_GRAPH für Mail.
Microsoft Entra Tenant-ID `<entra-tenant-id>`	Kennung Ihres Microsoft-Verzeichnisses. Aus dem Microsoft Entra Admin Center übernehmen; nicht selbst erfinden und nicht die pony-Mandanten-ID verwenden.
SAP Cloud ALM Authentifizierungs-Host `<sap-cloud-alm-auth-host>`	Hostname aus uaa.url des zugehörigen Service Keys, ohne https:// und Pfad. Von Ihrer Administration für SAP Cloud ALM bestätigen lassen.
SAP Cloud ALM Dependency `PONY_CALM`	Name der IAS-Verbindung zu SAP Cloud ALM. Bei Neuinstallation PONY_CALM verwenden; der Wert ponyCalmDependency muss genau gleich lauten.

Benötigte Services

Ihre SAP-BTP-Administration prüft die folgenden Services im vorgesehenen Subaccount. Ein Entitlement erlaubt dort die Nutzung eines Serviceplans. Eine Quota legt fest, wie viel Kapazität zur Verfügung steht.

Services und benötigte Kapazität

Die technischen Namen helfen beim Suchen im BTP Cockpit. Bereits vorhandene Services und Kapazitäten zuerst prüfen; fehlende Leistungen mit Ihrem SAP-Ansprechpartner klären.

Voraussetzungen für die Neuinstallation
Service / Plan	Vor der Installation bereitstellen
Cloud Foundry `cloudfoundry / standard` `APPLICATION_RUNTIME / MEMORY`	Cloud Foundry aktivieren und einen leeren Space anlegen. Arbeitsspeicher für pony und zusätzliche Kapazität für den Installationslauf zuweisen. Beispiel: 512 MB für eine laufende pony-Instanz, zuzüglich Reserve für Installation und Updates.
PostgreSQL on SAP BTP, hyperscaler option `postgresql-db / standard` `storage`	Datenbankplan und Speicherplatz zuweisen. Ausgangskonfiguration im Portal: PostgreSQL 16, 2 GB Arbeitsspeicher und 20 GB Speicherplatz, ohne öffentlichen Datenbankzugang. Die passende Größe mit Vostura abstimmen.
Authorization and Trust Management `xsuaa / application`	Den Plan für eine neue Serviceinstanz freischalten. Dieser Service unterstützt die Berechtigungsprüfung. Die Instanz und ihre Verbindung zur pony-App erstellt das Portal.
Destination `destination / lite`	Den Plan für eine neue Serviceinstanz freischalten. Hier werden die Verbindungen zu den anderen Systemen gespeichert. Serviceinstanz und beauftragte Verbindungen richtet das Portal ein.
SAP Cloud Identity Services / IAS	Eine nutzbare IAS-Umgebung und einen IAS-Administrator bereitstellen. Zwei Anmeldeanwendungen und ein technischer Zugang zur Benutzersuche werden im Kapitel „Zugänge vorbereiten“ eingerichtet.
SAP Cloud ALM API `standard`	Zugang zu Ihrem SAP Cloud ALM und dessen API bereitstellen. Der API-Zugang wird im Subaccount von SAP Cloud ALM eingerichtet, nicht im neuen pony-Space.
pony-Lizenz	Eine Lizenz für Ihre Umgebung bei Vostura anfordern. Sie ist von den SAP-Servicegebühren getrennt.

Arbeitsspeicher ist nicht Speicherplatz: Die 2 GB halten laufende Datenbankprozesse im Speicher; die 20 GB speichern Daten dauerhaft. Werden Speichereinheiten zu 5 GB angeboten, entsprechen 20 GB vier Einheiten. Für Cloud Foundry zählt der reservierte Arbeitsspeicher laufender Anwendungen, nicht nur die tatsächlich belegte Menge.

Für die Grundinstallation sind keine zusätzlichen Services für SAP HANA Cloud, SAP Build Work Zone, SAP Build Process Automation, HTML5 Application Repository oder Cloud Connector vorgesehen.

Services im BTP Cockpit zuweisen

BTP Cockpit öffnen und Ihren Global Account auswählen.
Entitlements → Entity Assignments öffnen, den pony-Subaccount auswählen und Edit → Add Service Plans wählen. Bei einem dazwischenliegenden Directory dort zuerst die benötigten Pläne zuweisen.
Die Servicepläne aus der Tabelle hinzufügen. Arbeitsspeicher und Speicherplatz zuweisen und mit Save speichern.
Im Subaccount unter Overview → Enable Cloud Foundry die Umgebung aktivieren, falls sie fehlt. Für die Neuinstallation unter Cloud Foundry → Spaces einen leeren Space anlegen.
Unter Services → Service Marketplace kontrollieren, ob die Pläne verfügbar sind. Mitgliedschaft, Space-Developer-Rechte sowie Quoten für Organisation und Space prüfen.

Zu beachten: Für die Neuinstallation keine Datenbank-, XSUAA- oder Destination-Instanzen im Ziel-Space von Hand anlegen. Diese erstellt das Portal nach Ihrer Startfreigabe. Bei Updates den bestehenden Space unverändert lassen.

SAP: Entitlements zuweisen

Kosten und Free Tier

Klären Sie vorab mit Ihrem SAP-Ansprechpartner, ob Ihr Vertrag die genannten Services und deren Nutzung abdeckt. Ein sichtbarer Service im Cockpit ist allein kein Nachweis dafür.

Der Datenbankplan standard ist kostenpflichtig. Der alternative Plan postgresql-db / free kommt nur infrage, wenn er in Ihrem Account verfügbar ist und seine Laufzeit-, Kapazitäts- und Backup-Grenzen zu Ihrem Einsatz passen. „Free“ allein bedeutet nicht, dass Ihre gesamte pony-Umgebung kostenlos ist. Ein persönlicher BTP-Trial-Account ist nicht für diese Kundeninstallation vorgesehen.

SAP: Free-Pläne · SAP: PostgreSQL-Free-Tier-Grenzen

Wenn eine Voraussetzung fehlt

Serviceplan fehlt: Account, Region, Entitlements und Quoten mit Ihrer SAP-BTP-Administration prüfen. Nicht auf einen anderen Plan ausweichen, ohne die Folgen zu klären.
Bestehende Installation: Deren Daten und technische Namen erhalten. Den Updateplan im Portal prüfen; eine unbekannte Installation nicht durch Löschen oder Neuanlegen „vorbereiten“.
Besondere Anforderungen: Andere Regionen, zusätzliche Ausfallsicherheit, Datensicherung und Wiederherstellung vorab mit Vostura abstimmen. Nicht jede Region oder Sonderdomain ist durch die vorhandenen Tests abgedeckt.

Servicepläne, Kapazitäten, Region und Kosten sind geklärt.

Zielumgebung festlegen

SAP-BTP-Subaccount, Cloud-Foundry-API-Adresse, Organisation und Space sind bekannt. Bei einer Neuinstallation ist der Space leer; bei einem Update wird der bestehende verwendet.
App-Name, Mandanten-ID und beide Webadressen sind festgelegt.Fiktives Beispiel Musterfirma GmbH, Produktion:
App: pony-musterfirma-prod · Mandanten-ID: musterfirma-prod
Kunden: https://pony-musterfirma-prod.cfapps.eu10-005.hana.ondemand.com
Operation: https://pony-musterfirma-prod-operation.cfapps.eu10-005.hana.ondemand.com
Operation ist die technische Verwaltung der Installation. Die Domain aus Ihrer Cloud-Foundry-Umgebung übernehmen.
Die ausführende Person besitzt Space-Developer-Rechte. Die Anmeldung erfolgt im Browser über Single Sign-On (SSO); Mehrfaktor-Anmeldung (MFA) bleibt aktiviert. Kein persönliches SAP-Passwort im Portal hinterlegen.

Zugänge vorbereiten

Ihre Administration richtet die folgenden Zugänge ein. Die Client-ID kennzeichnet einen technischen Zugang; das Secret ist dessen geheimes Kennwort. Beides wird später in den geschützten Feldern des Portals verwendet.

Kundenlogin: eigene IAS-App mit Verbindung zu SAP Cloud ALM.

Einrichten

Zugang 1 von 5

Kundenlogin: eigene IAS-App

Verantwortlich: IAS-/Security-Administration, für die Zuordnung zu SAP Cloud ALM gemeinsam mit der Administration von SAP Cloud ALM.

Diese App meldet Kundenbenutzer an und ermöglicht deren Weiterleitung in das richtige SAP Cloud ALM. Sie ist nicht die Operation-App und nicht der Directory-Systemclient.

IAS-Administration → Applications & Resources → Applications → Create

IAS-Beispiel: Trust zeigt OpenID Connect Configuration und Subject Name Identifier Email — 1 · Bestehendes pony-Demo-Beispiel: Unter **Trust** liegen OIDC und Subject Email. App-Typ „Bundled“ nicht ungeprüft übernehmen.

IAS-Beispiel: OIDC-Konfiguration mit einer Redirect URI auf /ias-callback — 2 · **Redirect URI**: Kundenadresse + `/ias-callback`. Der sichtbare Demo-Hostname ist ein Beispiel und muss ersetzt werden.

Eine neue eigene OpenID-Connect-App erstellen, beispielsweise pony-musterfirma-prod-login. Anwendungstyp, Organisation und Vertragszuordnung mit dem Kunden abstimmen; „Bundled“ ist keine allgemeine Lizenzzusage. Keine SAP-generierte Trust-App ersetzen.
In der App die Home URL setzen: https://<customer-host>.<cf-domain>/.
Trust → OpenID Connect Configuration öffnen. Einen Konfigurationsnamen und exakt diese Redirect URI speichern: https://<customer-host>.<cf-domain>/ias-callback. Keine Wildcard und keine fremde Route eintragen. Der Login verwendet Authorization Code mit einem geheimnisgeschützten Client, keinen Public Client.
Unter Trust → Subject Name Identifier den Wert Email wählen. Standardattribute beibehalten; keine zusätzliche E-Mail- oder Gruppen-Rollenbrücke improvisieren.
Trust → Client Authentication → Secrets → Add öffnen. Beschreibung und vereinbartes Ablaufdatum setzen. Beim API-Zugriff nur OpenID auswählen; vorgewählte Verwaltungszugriffe abwählen. Neue Client-ID und einmal sichtbares Secret direkt geschützt sichern.
Unter OpenID Connect Configuration → Authentication → Grant Types → Edit zusätzlich Token Exchange (RFC 8693) aktivieren. Anschließend unter Trust → Application APIs → Dependencies eine Dependency mit dem festen Namen PONY_CALM für den XSUAA-Provider der tatsächlichen Instanz von SAP Cloud ALM des Kunden mit Principal Propagation einrichten. Den genauen Provider durch die Administration von SAP Cloud ALM bestätigen lassen; nicht nach ähnlich klingenden Anwendungsnamen entscheiden.
Kundengruppe, Benutzerzugriff und MFA gemäß Kundenfreigabe einstellen. Für Kundenadministratoren muss Pony_Admin aus SAP Cloud ALM stammen; eine gleichnamige IAS-Gruppe ersetzt diese Rolle nicht.

Im Portal eintragen
Vorbereiteter Wert	Beschriftetes Feld
IAS-Hostname ohne https:// oder Pfad	IAS-Host für den Kundenlogin
Exakter Dependency-Name	Dependency `PONY_CALM` in der Kunden-IAS-App
Neue Client-ID und neues Secret	Kunden-IAS-Client-ID / Kunden-IAS-Client-Secret – aus der sicheren Ablage

Erledigt, wenn: Die erneut geöffnete App die richtige Kundenroute, Subject Email, OpenID-Zugang und die Dependency PONY_CALM zeigt und beide Credential-Werte gesichert sind. Der tatsächliche Kundenlogin mit Token Exchange wird erst nach der Installation abgenommen.

SAP: OIDC-App erstellen · Client-Secrets und OpenID-Zugriff · Token Exchange konfigurieren · API-Dependencies

Operation-Login: separate IAS-App.

Einrichten

Zugang 2 von 5

Operation-Login: separate IAS-App

Verantwortlich: IAS-/Security-Administration und BTP-Administration.

Dieser Zugang ist für das pony-Operation-Cockpit. Er benötigt keinen Login in SAP Cloud ALM des Kunden. Er ist auch nicht der technische BTP-API-Zugang aus Abschnitt 5.

IAS-Administration → Applications & Resources → Applications → Create

Eine zweite eigene OpenID-Connect-App erstellen, beispielsweise pony-musterfirma-prod-operation. Keine Client-ID und kein Secret aus der Kunden-App übernehmen. Derselbe IAS-Tenant ist möglich; die Apps bleiben getrennt.
Als Home URL https://<operation-host>.<cf-domain>/custom/operator.html setzen.
Unter Trust → OpenID Connect Configuration Konfigurationsname und https://<operation-host>.<cf-domain>/ias-callback als exakte Redirect URI speichern. Authorization Code verwenden; keinen Public Client einrichten.
Unter Trust → Subject Name Identifier ebenfalls Email wählen. Unter Client Authentication → Secrets → Add ein eigenes Secret mit vereinbartem Ablauf erzeugen, ausschließlich OpenID auswählen und Client-ID plus Secret direkt geschützt sichern.
Keine Dependency zur Instanz von SAP Cloud ALM des Kunden in dieser App einrichten. Die vorgesehenen Operation-Benutzer müssen im pony-Runtime-Subaccount der Role Collection Pony_Operator mit dem richtigen Identity Provider zugeordnet sein. BTP-Pfad: Security → Role Collections → Pony_Operator → Edit → Users. Eine fehlende Collection durch die zuständige Administration vorbereiten lassen.

Im Portal eintragen
Vorbereiteter Wert	Beschriftetes Feld
IAS-Hostname ohne Protokoll oder Pfad	IAS-Host für den Operation-Login
Eigene Operation-Client-ID und eigenes Secret	Operation-IAS-Client-ID / Operation-IAS-Client-Secret

Erledigt, wenn: Operation-Route, OIDC-Client und gesicherte Zugangsdaten eindeutig von der Kunden-App getrennt sind, Subject Email gespeichert ist und die vorgesehene Operation-Zuordnung im richtigen Subaccount bestätigt wurde. Operation-Login und Rollen-Refresh werden nach dem „Go“ separat getestet.

SAP: Eigene OIDC-Anwendung · Authorization Code Flow · Client-Secrets

Benutzersuche: IAS-Systemzugang mit ausschließlich „Read Users“.

Einrichten

Zugang 3 von 5

Benutzersuche: Directory mit Read Users

Verantwortlich: IAS-/Security-Administration.

pony benötigt hierfür einen separaten technischen IAS-Systemclient für OAuth2ClientCredentials. Weder das Passwort eines Menschen noch einer der beiden Loginclients gehört in diesen Zugang. Der Installationsauftrag prüft vor Go ein Token über /oauth2/token und den lesenden Zugriff auf /scim/Users. Eine eindeutig zugeordnete ältere Basic-Destination wird im Updateplan ausgewiesen und erst nach Go kontrolliert umgestellt.

IAS-Administration → Users & Authorizations → Administrators → Add → System

Einen eigenen Systemnamen vergeben, beispielsweise pony-musterfirma-prod-directory.
Unter Configure Authorizations vor dem Speichern alle vorgewählten Manage-Berechtigungen ausschalten. Ausschließlich Read Users aktivieren. Keine Benutzer-, Gruppen-, Anwendungs- oder Tenantverwaltung und keine Provisionierungsrechte freigeben.
Unter Configure System Authentication → Secrets → Add ein eigenes Secret mit Beschreibung und Ablauf erzeugen. Die Client-ID dieses Systemclients und das einmal sichtbare Secret direkt in einer eigenen geschützten Ablage sichern.
Den gespeicherten Systemclient erneut öffnen und die Berechtigungen nachlesen. Die Administration bestätigt den freigegebenen lesenden Directory-Zugriff; dabei keine Benutzerlisten exportieren oder im Protokoll ausgeben.

Leserecht heißt nicht automatisch „nur pony-Benutzer“.

Read Users kann das gesamte IAS-Benutzerverzeichnis umfassen. Diese Reichweite muss der Kunde freigeben; sie darf nicht mit einer automatischen Mandantenfilterung verwechselt werden.

Im Portal eintragen
Vorbereiteter Wert	Beschriftetes Feld
Systemclient-ID und Secret	Directory-Client-ID / Directory-Client-Secret
IAS-Zuordnung	Das Verzeichnis gehört zum Kunden-IAS. Die Directory-Destination richtet der Installationsauftrag selbst ein.

Erledigt, wenn: Genau der neue Systemclient ausschließlich Read Users besitzt, seine Zuordnung zum Kunden-IAS bestätigt ist und Client-ID sowie Secret sicher vorliegen. Ein Loginclient oder ein Systemclient mit Manage-Rechten erfüllt diese Voraussetzung nicht.

SAP: Benutzerberechtigungen und Reichweite von Read Users · Sicherer Umgang mit neu erzeugten Secrets

SAP Cloud ALM: eigener API-Zugang mit freigegebenen Rechten und Anwendungs-/API-/Anmeldeadressen.

Einrichten

Zugang 4 von 5

Fachliche API: eigener SAP Cloud ALM-Zugang

Verantwortlich: Administration von SAP Cloud ALM; Service- und Kostenfreigabe durch den zuständigen Kundenverantwortlichen.

Hier zählt der Subaccount mit der tatsächlichen Subscription für SAP Cloud ALM, nicht automatisch der pony-Runtime-Subaccount. Den Ziel-Tenant und seine technische ID vor dem ersten Klick bestätigen.

BTP Cockpit → Subaccount für SAP Cloud ALM → Services → Instances and Subscriptions → freigegebene API-Instanz von SAP Cloud ALM

Die benötigten pony-Funktionen und die dafür erlaubten API-Scopes abstimmen. Der pony-Lieferverantwortliche stellt eine passende, freizugebende Parameterbasis bereit; dafür ist beim Kunden kein Repositoryzugang nötig.
Geeignete Instanz vorhanden? Diese konkrete Instanz für pony ausdrücklich freigeben lassen und gezielt auswählen. Vorhandene Bindings und Scopes unverändert lassen. Keine Credentials anderer Umgebungen übernehmen. Das neue eigene Binding entsteht einmalig in Schritt 4.
Keine geeignete Instanz vorhanden? Erst Service, Scopes und Kosten freigeben lassen. Danach im Subaccount für SAP Cloud ALM über Create den Service SAP Cloud ALM API, Plan standard, Runtime Other / Andere und einen eigenen Namen wählen. Die freigegebene kundeneigene Parameterdatei im Wizard hochladen. Weder bestehende Instanzen ungefragt aktualisieren noch einen CF-Service für SAP Cloud ALM im pony-Ziel-Space anlegen.
Auf die verwendbare Instanz warten. Dort Actions → Create Binding / Service-Binding anlegen wählen und einen eindeutigen eigenen Bindingnamen vergeben, beispielsweise pony-musterfirma-prod-sap-cloud-alm-api. Anschließend am neuen Binding Actions → View / Anmeldeinformationen anzeigen öffnen.
Nur dieses neue Binding geschützt sichern. Die Administration von SAP Cloud ALM bestätigt zusätzlich die SAP Cloud ALM-Anwendungs-URL, API-Basis-URL, den Authentifizierungs-Host und den expliziten Token-Endpunkt. Eine generische uaa.url nicht ungeprüft als Kunden-Authentifizierungs-Host von SAP Cloud ALM verwenden.

API von SAP Cloud ALM und Read-only-Operation-API sind verschieden.

Die dokumentierte breite pony-API-Baseline enthält auch Schreib- und Löschrechte. Sie ist keine bewiesene Minimal-Scope-Liste und kein read-only Zugang. Ein neues Binding auf einer Bestandsinstanz übernimmt deren freigegebene Berechtigungen; es macht diese nicht automatisch enger. Bei Abweichungen stoppen und die Freigabe klären, nicht Berechtigungen auf Verdacht ergänzen.

Im Portal eintragen
Vorbereiteter Wert	Beschriftetes Feld
Benutzeroberfläche des eigenen SAP Cloud ALM	SAP Cloud ALM-Anwendungs-URL
Bestätigter Authentifizierungs-Host von SAP Cloud ALM, nur Hostname	SAP Cloud ALM-Authentifizierungs-Host
API-Basis, im Binding typischerweise `endpoints.Api`	API von SAP Cloud ALM-Basis-URL
`https://<sap-cloud-alm-auth-host>/oauth/token`	SAP Cloud ALM-Token-URL; Host muss zum Authentifizierungs-Host passen
Neues Binding: `uaa.clientid` und `uaa.clientsecret`	SAP Cloud ALM-Client-ID / SAP Cloud ALM-Client-Secret – nur aus der eigenen sicheren Ablage

Erledigt, wenn: Eigenes Binding und eindeutige Zuordnung zu SAP Cloud ALM vorliegen, die Rechte ausdrücklich freigegeben sind und die Administration den technischen Tokenzugriff sicher geprüft hat. Keine Tokens oder Antwortinhalte protokollieren. Ein gültiges technisches Token beweist noch nicht den späteren Kundenlogin mit Benutzer-Token-Exchange.

SAP: API von SAP Cloud ALM und Binding im Cockpit vorbereiten · SAP Cloud ALM-Scopes verwalten · Felder der Binding-Credentials

BTP-Rollenprüfung: Read-only-API-Zugang zum pony-Subaccount.

Einrichten

BTP-Rollenprüfung vorbereiten

Dieser technische Zugang liest, wer die pony-Installation verwalten darf. Ihre SAP-BTP-Administration benötigt dafür einen eigenen Read-only-API-Zugang für den pony-Subaccount. Das IAS-Secret oder der API-Zugang zu SAP Cloud ALM ist dafür nicht geeignet.

Im BTP Cockpit die ID des pony-Subaccounts und die Zuordnung zur vorgesehenen Cloud-Foundry-Organisation prüfen.
Den API-Zugang ausschließlich mit Leserechten für diesen Subaccount anlegen. Die Einrichtung für die Administration beschreibt die manuelle Alternative.
Diese sechs Werte im geschützten Bereich des Portals hinterlegen:

Werte des Read-only-Zugangs
Feld	Bedeutung
`url`	Autorisierungsadresse
`tokenurl`	Adresse zum Anfordern eines Zugriffstokens
`apiurl`	Adresse der BTP-Rollenschnittstelle
`clientid`	Client-ID des technischen Zugangs
`clientsecret`	Zugehöriges Secret
`subaccountid`	ID des pony-Subaccounts

Erledigt, wenn: Subaccount-Zuordnung und Leserechte bestätigt sind und alle sechs Werte sicher vorliegen. Bei fehlenden Rechten keinen Vollzugriff als Ersatz vergeben.

Instanzschlüssel und DB-Passwort sind sicher aufbewahrt.
Vorgaben
Bei Erstinstallation beide Werte neu und zufällig erzeugen und sicher aufbewahren. Ein bestimmter Tresor ist nicht erforderlich:
- Instanzschlüssel: 64 Hex-Zeichen.
- Runtime-DB-Passwort: 43–128 Zeichen; erlaubt sind A–Z, a–z, 0–9, _ und -.
Keine Werte aus anderen Umgebungen übernehmen. Bei Wiederaufnahme und Update dieselben Werte verwenden. Prüfen Sie im Portal, ob Secrets nur für die laufende Sitzung freigegeben oder verschlüsselt gespeichert werden. Zugangsdaten weder in diese Checkliste noch in E-Mails oder Screenshots eintragen. Der gespeicherte Installationsstand ersetzt kein Datenbank-Backup.

Microsoft-365-Mail (optional)

Optional für die Installation, erforderlich für pony-Mailfunktionen. Ohne eigene GRAPH-Destination gibt es keinen Versand über ein gemeinsames Postfach und keinen SMTP-Fallback. Diese Anleitung gilt für Microsoft 365 Global Cloud, nicht für nationale Sonderclouds.

Entra-App, Exchange-Postfach und Portal Schritt für Schritt

Eigenes Postfach bestimmen: Ein für pony freigegebenes Exchange-Online-Postfach beziehungsweise Shared Mailbox im Kunden-Tenant bereitstellen. Adresse, Verantwortliche und Aufbewahrung festlegen. Nicht ohne Freigabe das persönliche Postfach eines Mitarbeiters verwenden.
Entra-App registrieren: Im Microsoft Entra Admin Center unter App-Registrierungen eine eigene Single-Tenant-App anlegen. Für den App-only-Client-Credentials-Flow ist keine Browser-Redirect-URI nötig. Verzeichnis-ID (Tenant-ID) und Anwendungs-ID (Client-ID) notieren.
Secret erstellen: Unter Zertifikate & Geheimnisse einen Client-Secret-Wert erstellen. Den Wert, nicht die Secret-ID, sicher aufbewahren; Ablaufdatum und Rotation terminieren. Keine Zugangsdaten in dieses Dokument oder Support-Screenshots schreiben.
Mailrechte auf das Postfach begrenzen: Die Exchange-Administration richtet vorzugsweise RBAC for Applications mit einem Scope für genau die freigegebenen Postfächer ein. Benötigt werden Application Mail.Send und Application Mail.ReadWrite. Den Service Principal der Unternehmensanwendung verwenden, nicht die Objekt-ID der App-Registrierung. Zuordnung mit Test-ServicePrincipalAuthorization für erlaubte und nicht erlaubte Postfächer prüfen. Gleichzeitig in Entra tenantweit erteilte Mailrechte sind additiv und werden durch einen RBAC-Scope nicht eingeschränkt. Bestehende Application Access Policies gesondert prüfen; keine pauschalen Vollzugriffsrechte als Ersatz.
Im Portal eintragen: Unter Microsoft-365-Mail „Eigene Mail-Verbindung einrichten / erhalten“ wählen. Entra-Tenant-ID, Client-ID, Secret-Wert und Postfachadresse eingeben. Token-Endpunkt und Scope werden daraus fest vorgegeben; keine URLs zusammensuchen.
Vorprüfung und Go: Der Installationsauftrag prüft Tokenabruf und einen minimalen lesenden Postfachaufruf. Erst nach Go legt er <destination-prefix>_GRAPH auf der eigenen Destination-Service-Instanz an. Eine bereits fremd/manuell angelegte Destination wird nicht überschrieben oder automatisch übernommen.
Speicherung prüfen: Im Portal auswählen, ob das Mail-Secret nur für die Sitzung freigegeben oder verschlüsselt für spätere Updates gespeichert wird. Secret-Wechsel, Postfachwechsel und Entfernen separat beauftragen.

Funktion	Voraussetzung und Abschlussprüfung
Versand, Workflow- und Freigabemails, Testmail	App-only `Mail.Send`, korrektes Postfach, passende pony-Lizenz (`mail-outbound` und jeweilige Fachfunktion), eingerichtete Vorlagen/Empfänger/Workflows. Eine ausdrücklich freigegebene Testmail im Kunden-Admin senden und tatsächlichen Eingang bestätigen. Ein erfolgreicher Tokenabruf beweist keine Zustellung.
Posteingang und Antwortverarbeitung	`Mail.ReadWrite` für Lesen und Markieren verarbeiteter Nachrichten. Im Kunden-Admin die eingehende Verarbeitung bewusst aktivieren (`graph_inbound_enabled`); sie bleibt standardmäßig aus. Absender-Allowlist (`graph_inbound_allowlist`) und Workflow für eingehende Mail konfigurieren. Leere Allowlist akzeptiert alle Absender; daher vor Aktivierung bewusst festlegen. Lizenzfunktion `mail-inbound` prüfen.
Kontrollierter Ende-zu-Ende-Test	Nur nach Freigabe eine Testanfrage und passende Antwort verwenden; Verarbeitung, Zuordnung und Lesemarkierung prüfen. Manuelles Polling kann Nachrichten verarbeiten und verändern – es ist kein lesender Verbindungstest. Der Installationsauftrag führt weder Polling noch Versand aus und aktiviert keine Workflows.

Technischer Vertrag: OAuth2ClientCredentials · URL https://graph.microsoft.com/v1.0 · Token https://login.microsoftonline.com/<entra-tenant-id>/oauth2/v2.0/token · Scope https://graph.microsoft.com/.default · Additional Property pony.mailbox. Der Runtime-Dienst bezieht das Token ausschließlich über die mandanteneigene Destination.

Grenzen der Vorprüfung: Ein Leseerfolg belegt weder Mail.Send noch Schreibrechte oder die vollständige Eingrenzung auf dieses Postfach. Die Administration prüft die Rechte/Scopes; Versand und Schreibverhalten brauchen separat freigegebene Funktionstests. Ein Secret allein kann diese Freigaben nicht ersetzen.

Microsoft: Client-Credentials-Flow · Exchange RBAC for Applications · Mail.Send · Nachrichten markieren

Lizenz vorbereiten

Fordern Sie bei Vostura eine pony-Lizenz für den vorgesehenen Mandanten und Funktionsumfang an. Einen bereits eingetragenen gültigen Schlüssel bei Updates beibehalten.

Lizenz nach der Installation aktivieren

Bei einer Neuinstallation den ausgestellten Lizenzschlüssel in pony Operation beim passenden Mandanten eintragen.
Im Portal die Prüfung der eingetragenen Lizenzen und Aktivierung der Lizenzdurchsetzung beauftragen. Lizenz ausstellen, eintragen und Prüfung aktivieren sind getrennte Schritte.
Die Prüfung muss für alle aktiven Mandanten erfolgreich sein. Bei fehlender, ungültiger oder abgelaufener Lizenz stoppt der Ablauf vor dem Wechsel der Anwendung. Danach bleibt die Lizenzprüfung bei Updates aktiv.

„Prüfung inaktiv“ bedeutet nicht, dass die Lizenz fehlt, sondern dass ihre Durchsetzung noch ausgeschaltet ist. Technische Einstellung nach erfolgreicher Aktivierung: PLM_ENFORCE=on. Die Prüfung verändert keine gespeicherten Lizenzschlüssel.

Rollen zuweisen

Pony_Admin für Kundenadministratoren in SAP Cloud ALM.
Pony_Operator für Operation-Benutzer im pony-BTP-Subaccount; passender IAS-Trust.

Vorbereitung abschließen

Prüfen Sie, ob Services, Zielumgebung, Zugänge, Rollen und Lizenz vorbereitet sind. Wenn Sie Mailfunktionen nutzen möchten, muss auch die Microsoft-365-Verbindung vorbereitet sein.

Öffnen Sie anschließend Ihren freigegebenen Link zum pony-Installationsportal. Dort wählen Sie die Kundeninstallation aus, tragen die vorbereiteten Angaben ein und führen die Vorprüfung aus. Lesen Sie den angezeigten Plan, bevor Sie mit Go starten.

Das Portal wird im Browser verwendet; auf Ihrem Rechner ist keine lokale Installation nötig. Eine erfolgreiche Vorprüfung ersetzt nicht den Funktionstest nach der Installation.

Nach der Installation prüfen

Kundenlogin und Operation-Login funktionieren.
Die vorgesehenen Personen haben die richtigen Rollen.
Verbindung zu SAP Cloud ALM, Kundenkonfiguration und Lizenz sind geprüft.
Optionale Mailfunktionen werden erst nach Ihrer Freigabe getestet und aktiviert.

Den Ablauf im Portal beschreibt der Deployment Guide.

Anleitung zur Vorbereitung Ihrer pony-Installation. PONY_CALM ist der feste Dependency-Name für neue Installationen. Bestehende technische Namen nicht ungeprüft ändern.