Einrichtungsanleitung

Bereitstellung

Voraussetzungen

• SAP BTP Subaccount mit aktivierter Cloud-Foundry-Umgebung und einem Space für Spend Lens. Installieren Sie Spend Lens einmal pro Subaccount: Der XSUAA-Name asapio-spendlens und die Role Collections SpendLens User / SpendLens Admin sind pro Subaccount eindeutig, eine zweite Installation (zum Beispiel ein Testsystem) gehört daher in einen eigenen Subaccount.
• CF CLI mit dem MultiApps-Plugin: cf install-plugin multiapps
• Cloud-Foundry-Laufzeitspeicher für zwei kleine Anwendungen und eine Deployment-Task (insgesamt etwa 1,2 GB).
• Für S/4HANA On-Premise: ein mit dem Subaccount verbundener Cloud Connector.
• Die folgenden Berechtigungen (Entitlements) im Subaccount. Die Serviceinstanzen legt die Bereitstellung selbst an:

Die Berechtigungen, einschließlich der für den verwendeten Credential-Store-Plan, müssen im Subaccount vorhanden sein, bevor Sie bereitstellen. Ohne sie schlägt die Bereitstellung fehl.

Datenbank

Seit Spend Lens 1.5.0 ist die Datenbank PostgreSQL on SAP BTP, hyperscaler option (Service postgresql-db). SAP HANA Cloud (hdi-shared) wird nicht mehr verwendet. Spend Lens hält seine Tabellen in einem eigenen Schema asapio_spendlens, daher kann eine PostgreSQL-Instanz mit anderen Anwendungen geteilt werden.

• Eigene Instanz (Standard). Die Bereitstellung legt die Instanz asapio-spendlens-postgres an. Ihr Plan wird mit dem MTA-Parameter postgresPlan festgelegt (Standard standard; cf marketplace -e postgresql-db listet die Pläne, für die Ihr Subaccount berechtigt ist). Der Plan free ist nur für nicht-produktive Nutzung und kann ablaufen (Planbedingungen im Subaccount prüfen).
• Bestehende Instanz. Statt eine eigene Instanz anzulegen, kann Spend Lens eine bestehende Instanz von PostgreSQL on SAP BTP, hyperscaler option verwenden, die im Ziel-Space verfügbar ist. Benennen Sie sie mit dem MTA-Parameter existingDbService in einem Extension-Deskriptor (siehe Optional: Standardwerte ändern) und schalten Sie die Resources um:

  parameters:
    existingDbService: <existing-instance-name>
  
  resources:
    - name: asapio-spendlens-postgres
      active: false
    - name: asapio-spendlens-db
      active: true

cf undeploy asapio-spendlens --delete-services löscht die von der Bereitstellung angelegte PostgreSQL-Instanz mit allen darin enthaltenen Daten. Führen Sie das Undeploy ohne --delete-services aus, um die Dienste zu behalten.

SAP Credential Store

Seit Spend Lens 2.0.0 erfordert jede Bereitstellung auf SAP BTP Cloud Foundry eine SAP-Credential-Store-Serviceinstanz (Service credstore) mit dem Namen asapio-spendlens-credstore. Sie enthält die Verschlüsselungsschlüssel (den Credential Key für gespeicherte S/4HANA-Passwörter einzelner Benutzer und den MCP-Token-Schlüssel) sowie das Gateway-Secret zwischen Approuter und Backend. Spend Lens legt diese Secrets beim ersten Start selbst im Namespace asapio-spendlens an. Die Produktion startet ohne Credential Store nicht.

Der Plan wird mit dem MTA-Parameter credstorePlan festgelegt:

• standard (Standard) — eine eigene Credential-Store-Instanz.
• proxy — ein Proxy auf eine zentrale Credential-Store-Instanz, die mit dem Ziel-Subaccount geteilt ist.

Gehen Sie nicht vom Plan free aus. Er ist auf eine Instanz pro Subaccount (und pro Space) begrenzt und funktioniert daher nur, wenn im Subaccount sonst nichts davon Gebrauch macht.

Zentrale Instanz verwenden (Plan proxy)

1. Teilen Sie die zentrale Instanz mit dem Ziel-Subaccount (SAP-Credential-Store-Handbuch, Abschnitt Share, Unshare, and Authorize a Service Instance). Im BTP Cockpit verwenden Sie dafür die Registerkarte Service Sharing der Instanz, oder führen cf update-service <instance> -c '{"share":{"subaccountGuid":"<target>"}}' aus. Beschränken Sie die Freigabe mit dieser Autorisierung auf den Spend-Lens-Namespace:

   {"namespace_permissions":{"asapio-spendlens":["create","delete","list","read","update"]}}

2. Setzen Sie im Extension-Deskriptor der Bereitstellung (<customer>.mtaext, kopiert aus customer.mtaext.template) credstorePlan: proxy und ergänzen Sie am Resource asapio-spendlens-credstore den Ursprung der zentralen Instanz:

   parameters:
     credstorePlan: proxy
   
   resources:
     - name: asapio-spendlens-credstore
       parameters:
         config:
           origin:
             serviceGuid: <central-instance-guid>
             landscape: cf-eu10

   serviceGuid ist die GUID der zentralen Instanz. landscape ist die Landscape dieser Instanz, zum Beispiel cf-eu10 für AWS Frankfurt.
3. Stellen Sie mit dem Extension-Deskriptor bereit: cf deploy <path-to-your-package>/asapio-spendlens_<version>.mtar -e <customer>.mtaext.

Fortgeschritten: Schlüssel überschreiben

Die MTA-Parameter slCredKey, mcpKey und gatewaySecret (jeweils 64 Hexadezimalzeichen) überschreiben die im Credential Store gehaltenen Werte. Lassen Sie sie normalerweise ungesetzt.

Bestehende Installation auf 2.0.0 aktualisieren

Die Bereitstellung benötigt nun zusätzlich den Credential Store: Richten Sie die Berechtigung und gegebenenfalls den credstorePlan ein, bevor Sie das neue Paket bereitstellen. Gespeicherte S/4HANA-Passwörter einzelner Benutzer sind mit dem Credential Key verschlüsselt. Ändert sich dieser Schlüssel (zum Beispiel weil ein neuer Credential Store verwendet wird), müssen Benutzer ihre S/4HANA-Passwörter erneut eingeben.

Download-Paket

ASAPIO stellt Spend Lens als Download asapio-spendlens_latest.zip bereit (für den Download registrieren). Er enthält:

App-Paket bereitstellen

Melden Sie sich bei Cloud Foundry an, wählen Sie den Space für Spend Lens und stellen Sie das Archiv aus dem Download-Paket bereit. Es müssen keine Parameter bearbeitet werden: Jeder MTA-Parameter hat einen funktionierenden Standardwert. Die Bereitstellung des Archivs über das BTP Cockpit funktioniert genauso.

Terminal

cf login -a https://api.cf.<region>.hana.ondemand.com --sso
cf target -o "<org>" -s "<space>"
cf deploy asapio-spendlens_<version>.mtar

Die Bereitstellung legt die oben aufgeführten Serviceinstanzen an und erstellt oder aktualisiert drei CF-Anwendungen (asapio-spendlens-approuter, asapio-spendlens-srv, asapio-spendlens-db-deployer). Zuerst läuft der Datenbank-Deployer, dann srv (legt beim ersten Start die Credential-Store-Secrets an), dann der Approuter. Die erste Bereitstellung legt zusätzlich die PostgreSQL-Instanz an und dauert daher länger als spätere Updates.

App-URL und Routen

Standardmäßig gibt es keinen festen Host. Der Approuter erhält die von Cloud Foundry generierte Route https://<org>-<space>-asapio-spendlens-approuter.<domain>, die pro Org und Space eindeutig ist, sodass Installationen auf einer gemeinsamen Domain nicht kollidieren. Die App wird unter <route>/app/spendlens/ ausgeliefert, wohin auch / führt. Die URL zeigt nach der Bereitstellung:

cf app asapio-spendlens-approuter

Die XSUAA-Login-Weiterleitung wird bei der Bereitstellung aus dieser Route abgeleitet und folgt ihr automatisch; es ist nichts zu konfigurieren.

Ein fester Host ist optional: Setzen Sie den Modul-Parameter host von asapio-spendlens-approuter in einem Extension-Deskriptor. Der Host muss auf der Domain frei sein (auf einer gemeinsamen Domain gilt er über alle Subaccounts hinweg); die Login-Weiterleitung folgt ihm automatisch.

modules:
  - name: asapio-spendlens-approuter
    parameters:
      host: spendlens-companyx

Der Approuter hat genau eine Route. Ordnen Sie keine weiteren Routen zu (zum Beispiel einen Alias neben host): Auf jeder Route, die nicht in den XSUAA-Redirect-URIs steht, schlägt die Anmeldung fehl. Eine eigene Domain benötigt zusätzlich den Parameter domain, und ihre URL muss dann in die redirect-uris der Resource asapio-spendlens-auth eingetragen werden.

Optional: Standardwerte ändern

Ein Extension-Deskriptor ist nur nötig, um Standardwerte zu ändern. Kopieren Sie customer.mtaext.template aus dem Download-Paket nach <name>.mtaext, behalten Sie nur die benötigten Abschnitte und stellen Sie damit bereit:

cf deploy asapio-spendlens_<version>.mtar -e <name>.mtaext

Typische Gründe, jeweils in den Kommentaren der Vorlage erklärt:

• ein fester Host statt der generierten Route (Modul-Parameter host, siehe App-URL und Routen)
• eine bestehende PostgreSQL-Instanz (existingDbService, siehe Datenbank) oder ein anderer Datenbank-Plan (postgresPlan)
• ein Credential-Store-Proxy auf einen zentralen Store (credstorePlan: proxy, siehe SAP Credential Store)
• Cache-Einstellungen (cacheLookbackMonths, dbCacheTtlHours, siehe Daten-Caching)

Bewahren Sie einen ausgefüllten Extension-Deskriptor sicher auf: Er kann geheime Überschreibungen enthalten.

Updates

Stellen Sie das neue Archiv auf dieselbe Weise bereit, gegebenenfalls mit demselben Extension-Deskriptor. Daten und Einstellungen bleiben erhalten. Eine Installation, die mit einer bestehenden PostgreSQL-Instanz eingerichtet wurde, muss mit dem Extension-Deskriptor aktualisiert werden, der diese Instanz benennt; andernfalls legt die Bereitstellung eine neue, leere Datenbank an.

Update auf 2.0.0:

• Richten Sie zuerst die Berechtigung für den SAP Credential Store ein (siehe SAP Credential Store).
• Installationen auf SAP HANA Cloud (1.4.x und älter) lassen sich nicht direkt aktualisieren. Stellen Sie 2.0.0 als neue Installation bereit und erfassen Sie Einstellungen, Spend Limits und benutzerbezogene S/4HANA-Zugangsdaten erneut; die Bestell- und Rechnungs-Caches füllen sich wieder aus S/4HANA.
• Sofern der Extension-Deskriptor keinen host setzt, wechselt die App auf die generierte Route. Benutzer und MCP-Clients müssen die neue URL verwenden (cf app asapio-spendlens-approuter).
• Alte Lesezeichen der Form /app/spendlens/index.html#/<page> öffnen die Seite Total Spend. Die Seitenadressen lauten jetzt /app/spendlens/<page>; Benutzer sollten ihre Lesezeichen neu anlegen.
• Die Role Collections behalten ihre Namen (SpendLens User, SpendLens Admin); eine erneute Rollenzuweisung ist nicht nötig.

Checkliste für den ersten Start

Nach der Bereitstellung:

• Im BTP Cockpit: Weisen Sie die Role Collection SpendLens Admin mindestens einem Benutzer zu (siehe Rollen und Zugriff weiter unten)
• Melden Sie sich an der App an und öffnen Sie Settings → Connection Settings (der Tab ist nur für Benutzer mit der Admin-Rolle sichtbar)
• Wählen Sie die S/4HANA-BTP-Destination aus und klicken Sie auf Test Connection
• Stellen Sie den Auth Mode passend zu Ihrem Destination-Typ ein (siehe Anbindung an S/4HANA)
• Konfigurieren Sie in den User Settings bei Bedarf die Bezeichnungen der Organisationseinheiten
• Weisen Sie die Role Collection SpendLens User allen weiteren Benutzern zu, die Zugriff benötigen

Nach dem Zuweisen oder Ändern einer Role Collection im BTP Cockpit müssen sich Benutzer ab- und wieder anmelden, damit das neue Token (mit den aktualisierten Scopes) wirksam wird. Verwenden Sie Log out im Profilmenü des App-Headers.

Rollen und Zugriff

Spend Lens verwendet SAP BTP XSUAA für die gesamte Authentifizierung. Es gibt keine lokalen Benutzerkonten.

Role Collections

Verbindungseinstellungen (mit welchem S/4HANA-System verbunden wird, welche Destination verwendet wird) sind global und ausschließlich für Admins. Eine Änderung durch einen Admin wird sofort für alle Benutzer wirksam.

Rolle im BTP Cockpit zuweisen

1. Öffnen Sie das BTP Cockpit und navigieren Sie zu Ihrem Subaccount.
2. Gehen Sie zu Security → Role Collections.
3. Öffnen Sie SpendLens Admin (oder SpendLens User).
4. Klicken Sie auf Edit, dann auf Users → Add User.
5. Geben Sie die E-Mail-Adresse des Benutzers ein und wählen Sie den Identity Provider, mit dem sich der Benutzer tatsächlich anmeldet (siehe unten).
6. Speichern Sie. Die Rolle wird bei der nächsten Anmeldung des Benutzers wirksam (der Benutzer muss sich ab- und wieder anmelden).

Weisen Sie SpendLens Admin nur Benutzern zu, die für die Systemkonfiguration verantwortlich sind. Alle anderen Benutzer sollten SpendLens User erhalten.

Welcher Identity Provider?

Role-Collection-Zuweisungen sind pro Identity Provider abgegrenzt. Eine Rolle wird nur wirksam, wenn sie unter demselben Identity Provider zugewiesen ist, mit dem sich der Benutzer anmeldet — die Zuweisung unter einem anderen ist die häufigste Ursache für einen „403 — lacking required roles"-Fehler, obwohl die Rolle zugewiesen zu sein scheint.

Welcher Identity Provider zu wählen ist, hängt von der Trust-Konfiguration Ihres Subaccounts ab:

• Verfügt Ihr Subaccount über keinen eigenen Identity Provider, authentifizieren sich Benutzer über den Default Identity Provider (SAP Cloud Identity / SAP ID Service) — weisen Sie die Rollen dort zu.
• Verwendet Ihre Organisation einen eigenen SAP Cloud Identity Services (IAS) Tenant (optional föderiert mit einem Unternehmens-IdP wie Microsoft Entra ID oder Okta), authentifizieren sich Benutzer über den Business-User-Trust dieses Tenants — weisen Sie die Rollen dort zu, nicht unter „Default".

Um die Identity Provider Ihres Subaccounts anzuzeigen, öffnen Sie BTP Cockpit → Security → Trust Configuration (jeder Eintrag zeigt seinen Purpose — wählen Sie den für Business users, nicht für Platform users). Dieselbe Liste ist über die SAP BTP CLI mit btp list security/trust verfügbar.

Fehlerbehebung „403 — lacking required roles". Erhält ein Benutzer diesen Fehler, nachdem die Rolle zugewiesen wurde: (1) Stellen Sie sicher, dass die Zuweisung unter dem Business-User-Identity-Provider erfolgt, mit dem sich der Benutzer tatsächlich anmeldet — nicht unter „Platform users" und nicht unter einem anderen IdP; (2) lassen Sie den Benutzer sich ab- und wieder anmelden (eine frische Sitzung, z. B. im Inkognito-Modus), damit ein neues Token mit der Rolle ausgestellt wird.

Anbindung an S/4HANA

Spend Lens liest aus drei standardmäßigen SAP-OData-APIs — API_PURCHASEORDER_2 (OData v4, Bestellungen), API_SUPPLIERINVOICE_PROCESS_SRV (OData V2, Lieferantenrechnungen) und API_BUSINESS_PARTNER (OData V2, Lieferantenstammdaten). Es sind kein S/4HANA-Add-on und keine kundenspezifische Entwicklung erforderlich. Die APIs sind auf SAP S/4HANA 2022+ (On-Premise / Private Cloud) und S/4HANA Cloud Public Edition verfügbar, und alle drei nutzen dieselbe BTP-Destination.

Die Verbindung wird von einem Admin unter Settings → Connection Settings konfiguriert: Wählen Sie die BTP-Destination, wählen Sie einen Auth Mode und klicken Sie auf Test Connection. Folgen Sie dem Abschnitt unten, der zu Ihrer S/4HANA-Bereitstellung passt.

S/4HANA On-Premise / Private Cloud

BTP-Destination

BasicAuthentication: ein gemeinsam genutzter technischer SAP-Benutzer. Alle Spend-Lens-Benutzer greifen unter derselben SAP-Identität auf S/4HANA zu. Einfach einzurichten; setzen Sie den Auth Mode in Spend Lens auf Technical user.

PrincipalPropagation: Die Identität des angemeldeten BTP-Benutzers wird über die Trust-Konfiguration des Cloud Connectors an S/4HANA weitergeleitet. Erfordert einen System-Trust zwischen BTP und S/4HANA. Wenn die ausgewählte Destination Principal Propagation verwendet, zeigt Spend Lens den Auth Mode als Principal Propagation (schreibgeschützt) an und speichert keine Anmeldeinformationen.

Per-user Basic Auth (Auth Mode in Spend Lens): nur relevant für On-Premise-BasicAuthentication-Destinations, bei denen keine Principal Propagation konfiguriert ist. Jeder Benutzer meldet sich mit seinen eigenen SAP-Anmeldeinformationen an. Das Passwort wird verschlüsselt auf dem Server gespeichert (mit dem Credential Key aus dem SAP Credential Store) und nie im Browser behalten. Benutzer können ihre gespeicherte Anmeldung auf dem Tab Settings → User Settings ersetzen oder entfernen.

Erforderliche Berechtigungen

Die verwendete SAP-Identität (technischer oder propagierter Benutzer) benötigt Lesezugriff auf die drei APIs. Feldwert-Einschränkungen (z. B. die Beschränkung von EKORG auf bestimmte Einkaufsorganisationen) werden berücksichtigt — Spend Lens zeigt nur Daten an, für deren Lesen der SAP-Benutzer berechtigt ist.

API_PURCHASEORDER_2

API_SUPPLIERINVOICE_PROCESS_SRV

API_BUSINESS_PARTNER (Supplier Profiles — optional)

Speist das Lieferanten-Datenblatt (Stammdaten, Adressen, Kontakte) auf der Suppliers-Seite. Optional: Ist es nicht verfügbar, funktioniert der Rest der Suppliers-Seite weiterhin — nur das Datenblatt-Panel bleibt leer.

S/4HANA Cloud Public Edition

BTP-Destination

OAuth2ClientCredentials: ein gemeinsam genutztes Service-Konto. Alle Spend-Lens-Benutzer greifen unter derselben Service-Identität auf S/4HANA zu. Setzen Sie den Auth Mode in Spend Lens auf Technical user.

OAuth2SAMLBearerAssertion: Die Identität des BTP-Benutzers wird über einen SAML-Bearer-Token-Austausch gegenüber S/4HANA nachgewiesen. Erfordert ein Communication Arrangement in S/4HANA, das Ihren BTP-Subaccount als Identity Provider vertraut. Setzen Sie den Auth Mode in Spend Lens auf Technical user (das Cloud SDK führt den SAML-Assertion-Austausch automatisch durch).

Basic Auth wird mit S/4HANA Cloud Public Edition nicht verwendet.

Kommunikationsszenarien

Erstellen Sie für jedes der folgenden Szenarien ein Communication Arrangement (Communication Management → Communication Arrangements). Alle drei können demselben eingehenden Kommunikationsbenutzer und demselben Kommunikationssystem zugewiesen werden.

Es ist keine separate BTP-Destination pro API erforderlich — die vorhandene Bestellungs-Destination wird für alle drei wiederverwendet. API_BUSINESS_PARTNER / SAP_COM_0009 ist optional (nur das Lieferanten-Datenblatt nutzt es).

Funktionen

Alle Analysen sind schreibgeschützt. Spend Lens schreibt keine Beschaffungsdaten nach S/4HANA zurück.

Währungsumrechnung

Beschaffungsbelege umfassen häufig mehrere Währungen. Standardmäßig behält Spend Lens jeden Betrag in seiner Belegwährung und kennzeichnet jede gemischte Summe; optional können Sie Global Display Currency aktivieren, um alles in einer Währung zu berichten. Beide Verhaltensweisen werden unten beschrieben. Konfigurieren Sie die Währung auf dem Tab Settings → Currency (nur Admin).

Standard: Belegwährung mit Schutz vor gemischten Währungen

Ist Global Display Currency deaktiviert, zeigt jede KPI-Kachel die dominierende Währung und ihren Anteil an der Ergebnismenge (z. B. „EUR 62%"). Deckt die dominierende Währung weniger als 80% der Gesamtsumme ab, zeigt die Kachel „Mixed (top: EUR 62%)", um zu kennzeichnen, dass die Zahl mehr als eine Währung bündelt und nicht als Summe einer einzelnen Währung gelesen werden sollte. Beträge in Tabellen werden als reine Zahlen dargestellt (z. B. 1.2M) mit einer separaten CCY-Spalte für den Belegwährungscode — in der Betragszelle ist kein Währungssymbol eingebettet, sodass ein USD-Wert niemals fälschlich mit einem €-Zeichen versehen werden kann.

Global Display Currency

Aktivieren Sie Global Display Currency, um alle Beträge in einer einzigen Währung zu berichten, sodass Dashboard, Diagramme, Top Suppliers, Purchase Orders und Invoices alle eine Währung ohne „Mixed"-Warnung anzeigen.

Wechselkurse von der EZB. Kurse für die 29 EZB-Referenzwährungen (USD, GBP, CHF, JPY, SEK, DKK, NOK, PLN, CZK, HUF, RON, ISK, TRY, AUD, CAD, CNY, HKD, INR, MXN, ZAR und weitere) werden vom ECB Data Portal mit EUR als Basis abgerufen.

ECB API & Netzwerk-Egress. „Pull from ECB" löst einen ausgehenden HTTPS-Aufruf vom Spend-Lens-Backend an die öffentliche Data API der Europäischen Zentralbank (SDMX-JSON) aus — kein Schlüssel und keine Registrierung erforderlich:

https://data-api.ecb.europa.eu/service/data/EXR/D.<currencies>.EUR.SP00.A?lastNObservations=1&format=jsondata

Die BTP-Umgebung (und jeder Egress-Proxy/jede Firewall) muss ausgehenden Zugriff auf data-api.ecb.europa.eu zulassen. Die Währungsumrechnung ist optional — wenn Sie Global Display Currency nie aktivieren, wird niemals ein ECB-Aufruf ausgeführt.

Die Einrichtung erfolgt in zwei Schritten:

1. Klicken Sie auf „Pull from ECB", um Live-Kurse für die 29 EZB-Referenzwährungen abzurufen.
2. Aktivieren Sie den Umschalter und wählen Sie die Anzeigewährung. Das Dropdown der Anzeigewährung listet nur Währungen auf, für die ein Kurs gespeichert ist, sodass Sie niemals eine Währung auswählen können, in die die App nicht umrechnen kann.

Für jede Belegwährung in Ihren Daten muss ein Kurs vorhanden sein; Zeilen in einer Währung ohne Kurs werden aus den umgerechneten Summen ausgeschlossen, und auf dem Dashboard erscheint ein „missing rates"-Banner.

Eigene Währungen & manuelle Kurse. Die Add / Update-Zeile der Exchange-Rates-Tabelle hat ein Feld für den Währungscode — geben Sie einen beliebigen Code (bis zu 5 Zeichen) und seinen Kurs (1 EUR = X) ein. Codes, die die EZB nicht veröffentlicht, zeigen eine Warnung, dass „Pull from ECB" sie nicht aktualisiert, sodass Sie deren Kurs manuell pflegen. Bearbeiten Sie einen vorhandenen Kurs direkt in der Zeile und klicken Sie auf Save oder entfernen Sie ihn mit der Schaltfläche ✕. „Pull from ECB" aktualisiert jede bereits in der Tabelle enthaltene, von der EZB abgedeckte Währung und lässt manuelle Einträge unberührt.

Eine Änderung anwenden

Nach dem Aktivieren von Global Currency oder dem Wechsel der Anzeigewährung bietet ein Banner eine Schaltfläche Sync Now — ohne dass Sie die Settings verlassen müssen. Die Summen sind sofort korrekt, auch für Daten, die vor dem Einschalten der Funktion synchronisiert wurden.

Die Tabellen lesen. Bei aktiviertem Global Currency fügen Tabellen neben dem Betrag in Belegwährung und seinem CCY-Code eine Converted-Spalte in der Anzeigewährung hinzu, sodass Sie stets sowohl den Original- als auch den umgerechneten Wert sehen.

Daten-Caching

Spend Lens fragt S/4HANA nicht bei jeder Interaktion ab. Es liest die relevanten Beschaffungsbelege aus den standardmäßigen OData-APIs, cacht sie und liefert das Dashboard aus diesem Cache. Dies begrenzt, wie oft Spend Lens Ihr S/4HANA-System aufruft. Alle Kennzahlen werden aus den gecachten Quellbelegen abgeleitet, sodass sie mit dem übereinstimmen, was Sie direkt in S/4HANA berechnen würden. Spend Lens ist schreibgeschützt und schreibt niemals zurück.

Aktualisierung und Time-to-Live

Gecachte Daten werden automatisch nach Ablauf einer Time-to-Live (TTL) aktualisiert sowie bei Bedarf, sobald Sie auf Refresh drücken. Purchase Orders und Supplier Invoices teilen sich ein einziges Lookback-Fenster, sodass kombinierte Ansichten und der Ausgabentrend niemals nicht übereinstimmende Zeiträume vermischen. Sowohl die TTL als auch das Lookback-Fenster sind pro Bereitstellung konfigurierbar:

Das Lookback-Fenster vs. Ihr Datumsfilter. Der Cache enthält Belege innerhalb des Lookback-Fensters (z. B. der letzten 25 Monate). Der Datumsfilter auf dem Dashboard grenzt ein, was Sie innerhalb der gecachten Daten sehen — er wird auf den Cache angewendet und löst keinen S/4HANA-Aufruf aus. Setzen Sie den Filter weiter zurück, als der Cache abdeckt, sind die älteren Belege noch nicht geladen, und das Dashboard zeigt ein Informationsbanner, das Sie zu einem Refresh auffordert, wodurch bis zum Startdatum Ihres Filters erneut aus S/4HANA geladen wird. Ein Datum innerhalb des Fensters verkleinert den Cache niemals.

Ist Global Display Currency aktiviert, werden Beträge für jede KPI, jedes Diagramm und jede Tabelle in Ihre gewählte Währung umgerechnet — siehe Währungsumrechnung.

Claude AI / MCP Access

Überblick

Spend Lens implementiert das Model Context Protocol (MCP) und ermöglicht Benutzern, Claude AI (claude.ai) mit ihrer Spend-Lens-Instanz zu verbinden und Beschaffungsdaten in natürlicher Sprache abzufragen. Benutzer authentifizieren sich mit ihren eigenen Anmeldeinformationen und sehen Daten gemäß ihren bestehenden Spend-Lens-Berechtigungen — es ist keine neue Rolle erforderlich. Alle Interaktionen sind schreibgeschützt; Claude kann keine Daten schreiben oder ändern.

Standardzustand: deaktiviert. Wenn Sie Spend Lens erstmals bereitstellen, ist der MCP-Zugriff ausgeschaltet und muss von einem Admin auf der Settings-Seite ausdrücklich aktiviert werden.

Einrichtung

1. Admin aktiviert MCP. Gehen Sie in Spend Lens zu Settings → Connection → AI / MCP Access und aktivieren Sie „Enable MCP Access". Dies ist ein globales Feature-Flag; das Deaktivieren trennt sofort alle aktiven Claude-Sitzungen.
2. MCP-URL finden. Es ist die App-URL mit angehängtem /mcp — z. B. https://<org>-<space>-asapio-spendlens-approuter.<domain>/mcp für die generierte Route. Um Ihren eigenen Host zu finden, führen Sie cf app asapio-spendlens-approuter aus und verwenden Sie dessen Route.
3. Benutzer verbindet den MCP-Client. Öffnen Sie in Claude (Desktop oder Web, mit einem Plan, der eigene Connectors erlaubt) Settings → Connectors → Add custom connector, geben Sie die MCP-URL ein und bestätigen Sie. Claude startet einen OAuth-2.1-Login-Flow mit PKCE. Andere MCP-Clients (z. B. Microsoft Copilot / Copilot Studio, VS Code) verbinden sich auf dieselbe Weise — siehe Unterstützte Clients unten.
4. Einmalige Anmeldung. Claude öffnet ein Anmeldefenster; der Benutzer meldet sich mit seinen SAP/IAS-Anmeldeinformationen an (derselbe Identity Provider wie die Spend-Lens-Oberfläche). Spend Lens führt seinen eigenen OAuth-Authorization-Code-Flow direkt gegen IAS aus — es verwendet nicht den App-Router-Login, sodass der Flow innerhalb des Pop-up-Fensters von Claude funktioniert.
5. Autorisierung. Nach der Anmeldung stellt Spend Lens Claude ein opakes Access-Token und ein Refresh-Token aus. Diese sind Stellvertreter für die zugrunde liegenden XSUAA-Tokens — Claude sieht die SAP-Identitätstokens niemals direkt. Die Verbindung bleibt 30 Tage gültig und erneuert den S/4HANA-Zugriff automatisch im Hintergrund; danach autorisiert der Benutzer einmal erneut.
6. Claude fragt Spend Lens ab. Jede Anfrage enthält das Access-Token; der MCP-Server entschlüsselt das gespeicherte XSUAA-Token und ruft die internen CAP-OData-Services auf. Der bestehende asapio.spendlens.user- / asapio.spendlens.admin-Scope des Benutzers wird durchgesetzt — es ist keine spezielle MCP-Rolle erforderlich.

Was Claude leisten kann

Nach der Verbindung verfügt Claude über diese schreibgeschützten Tools. Jede analytische Antwort enthält zudem einen Deep Link zurück in die relevante Spend-Lens-Ansicht.

Zeitraum. Jedes analytische Tool deckt standardmäßig die letzten 90 Tage ab und gibt einen period-Block zurück, der genau angibt, welchen Bereich die Zahlen abdecken, sodass eine Antwort niemals mehrdeutig ist. Andere Bereiche sind über einen vordefinierten range-Parameter (mtd, lastMonth, qtd, lastQuarter, ytd, lastYear, allTime) oder ein explizites dateFrom/dateTo-Fenster verfügbar — passend zu den Datums-Presets des SpendLens-Dashboards.

Unterstützte Clients & Verbindung

Sie konfigurieren nur die eine MCP-URL (/mcp); alle OAuth-Endpunkte werden automatisch aus den Well-Known-Metadaten ermittelt (/.well-known/oauth-protected-resource und /.well-known/oauth-authorization-server). Der Server identifiziert Clients auf zwei Arten und wählt jene, die der Client verwendet:

• Client ID Metadata Document (CIMD) — verwendet von Claude, dessen client_id eine URL ist (claude.ai). Der Origin ist auf der Allowlist.
• Dynamic Client Registration (RFC 7591) — verwendet von Clients wie Microsoft Copilot / Copilot Studio und VS Code, die sich am registration_endpoint (/oauth/register) registrieren und eine generierte client_id erhalten. Nur öffentliche Clients (PKCE, kein Secret).

Die Registrierung ist eingegrenzt: Eine Redirect-URI wird nur akzeptiert, wenn ihr Host auf der Allowlist steht (claude.ai, copilot.microsoft.com, copilotstudio.microsoft.com, teams.microsoft.com, vscode.dev, insiders.vscode.dev, global.consent.azure-apim.net für Custom Connectors in Copilot Studio) oder es sich um eine http(s)://127.0.0.1-/localhost-Loopback-Adresse handelt (Desktop / VS Code). Jeder andere Host wird abgelehnt. Verwendet ein neuer MCP-Client einen anderen Callback-Host, wenden Sie sich an ASAPIO.

Sicherheit

• OAuth 2.1 mit PKCE S256. Jeder Login-Flow verwendet eine PKCE-Code-Challenge zum Schutz vor dem Abfangen des Authorization Codes.
• Token-Verschlüsselung. Die XSUAA-Access- und -Refresh-Tokens werden in der Datenbank mit AES-256-GCM verschlüsselt gespeichert. Der Verschlüsselungsschlüssel wird via HKDF aus dem MCP-Token-Schlüssel im SAP Credential Store abgeleitet.
• Refresh-Token-Rotation. Wenn Claude sein Access-Token erneuert, wird das alte Refresh-Token invalidiert und ein neues ausgestellt.
• Kill-Switch. Ein Admin kann den MCP-Zugriff jederzeit unter Settings → Connection → AI / MCP Access deaktivieren. Das Deaktivieren der Funktion liefert allen aktiven Claude-Sitzungen sofort HTTP 401 zurück und löscht alle gespeicherten Sitzungen aus der Datenbank.
• Audit-Log. Jede MCP-Aktivierungs-/Deaktivierungsaktion wird im unveränderlichen Audit Log mit der Benutzer-ID des Admins und einem Zeitstempel aufgezeichnet.
• Keine Schreibvorgänge. Die MCP-Tools rufen nur schreibgeschützte CAP-OData-Funktionen auf. Claude kann keine Spend-Lens-Daten erstellen, aktualisieren oder löschen.
• Redirect-URI-Allowlist. Die Authorize- und Registrierungs-Endpunkte akzeptieren nur den CIMD-claude.ai-Callback oder Redirect-URIs, deren Host auf der Allowlist steht / eine Loopback-Adresse ist, und ein dynamisch registrierter Client darf nur eine von ihm registrierte Redirect-URI verwenden — was Open-Redirect-/SSRF-Angriffe verhindert.

Architekturhinweis: Spend Lens agiert als OAuth Authorization Server gegenüber claude.ai (Proxy-Modus) und zugleich als OAuth Client gegenüber XSUAA/IAS (mit einem eigenen Authorization-Code-Flow). Die tatsächliche Identität des Benutzers bleibt stets erhalten; Claude sieht dieselben Daten, die der Benutzer in der Spend-Lens-Oberfläche sehen würde.

Lizenz

ASAPIO Spend Lens wird unter den ASAPIO Free License Terms bereitgestellt, veröffentlicht unter https://asapio.com/terms. Sie gelten für jede Installation und Nutzung von Spend Lens. Spend Lens enthält Open-Source- und SAP-Komponenten unter eigenen Lizenzen; die Hinweise stehen in THIRD-PARTY-LICENSES.md im Download-Paket und in der In-App-Hilfe.

Markenrechte

SAP, S/4HANA, SAP Fiori, SAP BTP und andere hier genannte SAP-Produkte sind Marken oder eingetragene Marken der SAP SE (oder eines mit SAP verbundenen Unternehmens) in Deutschland und anderen Ländern. Claude und Anthropic sind Marken von Anthropic, PBC. Das Model Context Protocol (MCP) ist ein von Anthropic eingeführtes offenes Protokoll. Microsoft und Microsoft Copilot Studio sind Marken der Microsoft-Unternehmensgruppe. Alle anderen Produkt- und Firmennamen sind Marken ihrer jeweiligen Inhaber.

ASAPIO Spend Lens ist ein eigenständiges Produkt der ASAPIO GmbH und steht in keiner Verbindung zu SAP SE, Anthropic, PBC oder Microsoft, wird von diesen weder unterstützt noch gesponsert. Marken werden ausschließlich zu Identifikations- und Beschreibungszwecken verwendet.