Direkt zu Hauptinhalt

Fehlerbehebung bei SAP OData V4 CDS Views, die in Package Studio fehlen

Nutzen Sie diese Anleitung, wenn eine erwartete SAP CDS-Extraktionsquelle über den CDI_CDS OData V4-Service nicht auffindbar oder in Nexus Package Studio auswählbar ist. Die Konfiguration auf SAP-Seite unterscheidet sich zwischen S/4HANA Cloud Public Edition und kundenseitig verwalteten Private Edition- oder On-Premise-Systemen. Bestätigen Sie zuerst das SAP-Produkt, die Edition, die Release-Version sowie den Ziel-Tenant/-Client. Fragen Sie Ihren SAP-Administrator, wenn Sie nicht sicher sind, welche Edition Sie einsetzen; das Fiori-Launchpad alleine zeigt die Edition nicht an.

Diese Anleitung behandelt CDS-basierte Extraktion über CDI_CDS. Ein CDS-View, der als separate External API oder über einen anderen Custom OData-Service bereitgestellt wird, ist eine andere Quelle und wird nicht automatisch von CDI_CDS gelistet.

Verstehen Sie die zwei Discovery-Ebenen​

Betrachten Sie Discovery als Prüfung zweier unterschiedlicher Listen:

  1. Der OData-Service-Katalog ist ein Verzeichnis veröffentlichter OData V4-Services. In der Public Edition ermöglicht die SAP_COM_0181-Konfiguration den Zugriff auf den Katalog. Dies gewährt jedoch keinen Zugriff auf die CDS-Daten.
  2. Das CDI-Anbieter-Verzeichnis listet CDS-Extraktionsquellen, die über CDI verfügbar sind. Dieses Verzeichnis enthält Anbieter, aber nicht zwangsläufig jeden View als eigenen Katalog-Service.

In Package Studio organisiert Nexus OData-Quellen als Servicegruppe → Service → Version → Entity Set. Ein Entity Set ist die Sammlung von Zeilen, die Nexus zu einem Paket hinzufügen kann und wie eine Tabelle behandelt wird. Für einen CDI-Anbieter ist der Name häufig Facts; verwenden Sie immer das Entity Set, das tatsächlich in den Metadaten des Providers angezeigt wird.

Starten Sie hier​

Befolgen Sie diese Prüfungen in der angegebenen Reihenfolge. Stoppen Sie, sobald eine Prüfung fehlschlägt; dies zeigt, welchen SAP- oder Nexus-Administrator Sie kontaktieren sollten.

  1. Wie wurde der View erstellt? Im Fiori-Tool Custom CDS Views oder in ABAP Development Tools (ADT) als ein Entwickler-Z*-View? Beginnen Sie mit den passenden Anweisungen unter Schritt 2.
  2. Ist der CDI-Service verfügbar? Wenn Package Studio die CDI-Servicegruppe nicht anzeigen kann, folgen Sie Schritt 1.
  3. Listet SAP den View auf? Testen Sie die CDI-Providers-Anfrage in Schritt 3 mit dem gleichen technischen Nutzer, den Nexus verwendet.
  4. Listet SAP den View auf, aber Package Studio kann ihn dennoch nicht hinzufügen? Prüfen Sie das Entity Set und die Metadaten in Schritt 4, anschließend folgen Sie Schritt 5.

Halten Sie diese Informationen bereit​

  • Den technischen Namen des CDS/Extractors exakt wie von SAP angezeigt. Ein geschäftlicher Bezeichner wie „Orders for Reporting“ reicht nicht aus. Der Extraktorname hängt vom CDS-View-Typ ab; siehe Schritt 3.
  • Die SAP-Edition und das genaue System bzw. den Tenant, den Sie prüfen (Entwicklungs-, Test- oder Produktivsystem).
  • Die für Nexus konfigurierte technische Kommunikationskennung. Dies ist nicht unbedingt Ihr persönlicher Fiori- oder SAP Logon-Benutzer.
  • Ihre Nexus-Version, angezeigt unter Einstellungen → Lizenz & Support.

Fügen Sie keine Passwörter, privaten Schlüssel oder Zertifikatsdateien einem Support-Ticket bei.

1. Prüfen Sie die Katalog- und CDI-Service-Verfügbarkeit​

SAP Fiori: Public Edition​

  1. Öffnen Sie im Fiori-Launchpad Kommunikationsvereinbarungen.
  2. Finden Sie die Vereinbarung für SAP_COM_0181. Öffnen Sie diese und überprüfen Sie, dass sie aktiv ist, das für Nexus erstellte Kommunikationssystem nutzt und einen Inbound-Service für den OData V4-Katalog zeigt. Diese Vereinbarung ermöglicht Nexus, verfügbare Services zu listen; sie erteilt jedoch keine Berechtigung zum Lesen eines CDS-Views.
  3. Finden Sie die separate Vereinbarung für SAP_COM_0531. Öffnen Sie Inbound Services und kopieren Sie die dort angegebenen CDI-URLs. Dies sind die Test-URLs—kopieren Sie nicht den Host aus dem Feld Host Name des Kommunikationssystems, der die Nexus-Seite repräsentiert.
  4. Notieren Sie in der SAP_COM_0531-Vereinbarung die Authorization Group ID. Vergleichen Sie diese später mit Gruppe und Allowlist, wie im nächsten Abschnitt beschrieben.
  5. Bestätigen Sie, dass der View samt Allowlist im gleichen Ziel-Tenant bereitgestellt wurde, den Sie testen. Ein in einem Entwicklungs-Tenant sichtbarer View ist nicht automatisch in Test- oder Produktiv-Tenants verfügbar.

Für die vollständige Public Edition-Konfiguration und Allowlist-Einrichtung siehe Connecting to S/4HANA Cloud Public Edition via OData V4.

SAP Logon: Kundenseitig verwaltete Systeme​

In SAP S/4HANA Private Edition oder On-Premise-Systemen, bei denen Sie SAP Gateway verwalten:

  1. Melden Sie sich am richtigen SAP System und Client im SAP Logon an.
  2. Geben Sie im Befehlsfeld /n/IWFND/V4_ADMIN ein und drücken Sie Enter. Dadurch öffnen Sie die OData V4-Administrationsoberfläche von SAP Gateway.
  3. Wählen Sie Publish Service Groups, dann Get Service Groups. Suchen Sie nach /IWFND/CONFIG (dem Katalogservice) und CDI_CDS (der CDS-Extraktions-Servicegruppe). Falls einer nicht veröffentlicht ist, folgen Sie dem Verfahren Ihres SAP-Administrators zur Veröffentlichung und Überprüfung des Systemalias/Routings. SAPs Gateway-Beispiel nutzt Alias LOCAL; für einen lokalen Gateway prüfen Sie zusätzlich die Local GW-Einstellung.
  4. Befolgen Sie die SAP-Anweisungen Ihrer Release-Version dazu, ob die Gruppe CDI ebenfalls veröffentlicht werden muss. Wenn SAP meldet, dass das Repository CDI_CDS der Gruppe CDI_CDS nicht zugeordnet ist, siehe SAP KBA 3339952 in SAP for Me.

Nutzen Sie /IWFND/V4_ADMIN nicht zur Administration von Public Edition-Tenants. In der Public Edition verwenden Sie die Kommunikationsvereinbarungen und Inbound-Service-URLs aus Fiori. Für Tests nutzen Sie einen HTTP-Client mit dem Communication User und der konfigurierten Authentifizierung.

Katalogzugriff testen​

Nutzen Sie die von SAP oder durch die Kommunikationsvereinbarung bereitgestellte Katalog-URL; raten Sie keinen Katalogpfad. Ein SAP Gateway V4-Katalog-URL hat beispielhaft diese Form:

https://<SAP-API-Host>/sap/opu/odata4/iwfnd/config/default/iwfnd/catalog/0002/ServiceGroups?$expand=DefaultSystem($expand=Services)&$top=5

Die Katalogversion (0002 hier) kann je nach SAP-Release variieren. In Public Edition kopieren Sie die genaue URL aus SAP_COM_0181 Inbound Services. In kundenseitig verwalteten Systemen muss die Katalog-Servicegruppe /IWFND/CONFIG für diesen Endpunkt veröffentlicht sein; dies ist separat von der Veröffentlichung von CDI_CDS.

Im kundenseitig verwalteten SAP Gateway-System prüfen Sie mit /IWFND/GW_CLIENT:

  1. Geben Sie den von SAP bereitgestellten relativen Request-Pfad ins Anfragefeld ein.
  2. Wählen Sie den HTTP-Methoden GET und führen Sie die Anfrage aus (meist F8).
  3. Lesen Sie den HTTP-Status und den Response-Body. Testen Sie zuerst den Katalog, dann die CDI-Providers-Anfrage und schließlich die $metadata-URL eines Providers.
  4. Wiederholen Sie den HTTP-Test mit der Nexus-Integrationskennung, sofern möglich. Ein erfolgreicher Aufruf als Ihr eigener SAP GUI-Nutzer beweist nicht, dass die technische Identität von Nexus denselben Zugriff hat.

In Public Edition haben Sie üblicherweise keinen SAP Logon-Zugriff auf diese Gateway-Transaktionen. Verwenden Sie die URLs aus den Fiori-Kommunikationsvereinbarungen im Browser oder einem HTTP-Client mit den Credentials des Communication User.

Falls CDI_CDS fehlt, beheben Sie zuerst Katalogzugriff oder Servicegruppen-Veröffentlichung, bevor Sie die individuelle CDS-Definition analysieren.

2. Prüfen Sie, ob SAP den CDS-View zur Extraktion freigibt​

SAP Fiori: View und Berechtigung verifizieren​

  1. Suchen Sie im View Browser nach dem technischen CDS-Namen. Filtern Sie wo möglich nach Data Extraction Enabled Views oder der Analytics.dataExtraction.enabled-Annotation.
  2. Für einen im Custom CDS Views-Tool erstellten View öffnen Sie diese App, prüfen das Szenario Data Extraction, führen die Prüfung aus und veröffentlichen den View. Ein Entwurf oder nicht veröffentlichter View ist nicht zur Extraktion bereit.
  3. Suchen Sie in der Zielkonfigurationsumgebung nach Define Allowlists for CDS View Extraction. Öffnen Sie die Berechtigungsgruppe, deren ID Sie in der SAP_COM_0531-Vereinbarung notiert haben. Prüfen Sie, ob der technische CDS-Name gelistet ist. Wenn die Vereinbarung beispielsweise die Gruppe NEXUS_READ nennt, gilt die Berechtigung nicht, wenn der View zu einer anderen Gruppe hinzugefügt wurde—das gewährt Nexus keinen Zugriff.
  4. Gleichen Sie die Authorization Group ID der Vereinbarung exakt ab. Beim Transport von Konfigurationen zwischen Tenants prüfen Sie, ob sowohl die Gruppe als auch die Einträge im Ziel-Tenant angekommen sind.

Zeigt SAP Authorization Group muss gepflegt werden an, siehe SAP KBA 3118974 in SAP for Me. Entfällt die Allowlist-Konfiguration in Public Edition, kann das an einem inaktiven Scope Item Data Protection and Privacy (5LE) liegen; siehe SAP KBA 3781796 in SAP for Me.

Entwickler-erstellte Z* CDS-Views​

Für einen vom Entwickler erstellten ABAP CDS-View lautet die Extraktionsannotation:

@Analytics.dataExtraction.enabled: true

Prüfen Sie die Definition in ABAP Development Tools (ADT), aktivieren Sie sie und stellen Sie sicher, dass die Annotation für die ABAP-Sprachversion des Systems zulässig ist. Diese Annotation bedeutet „SAP kann diesen View zur Datenextraktion bereitstellen“; sie veröffentlicht keinen OData-Service oder garantiert, dass Nexus ihn automatisch entdecken kann.

Hinweis zur Public Edition: Gehen Sie nicht davon aus, dass ein Entwickler die Annotation beliebig zu jedem Custom Z*-Objekt hinzufügen kann. Einschränkung durch ABAP-Sprachversion und freigegebene APIs können dies verhindern. Für Key-User-Custom-Views nutzen Sie stattdessen das unterstützte Szenario Custom CDS Views → Data Extraction. SAP dokumentiert Annotation-Release-Fehler bei Custom ABAP CDS-Views unter KBA 3404120 in SAP for Me.

Beispielsweise kann ein Entwickler einen aktiviert View mit Namen ZC_ORDER_EXTRACT erstellen, aber Nexus findet ihn nicht allein wegen des Namens Z. Der View muss für SAP-Extraktion geeignet, über CDI_CDS bereitgestellt und für die Integrationskennung zugänglich sein. In Public Edition erstellt ein Key User den Extraction-View im Custom CDS Views-Tool, ohne zwingend direkt die ABAP-Annotation zu bearbeiten.

3. CDI Provider Discovery direkt abfragen​

Nutzen Sie den CDI-Endpunkt aus der SAP-Vereinbarung oder Systemkonfiguration und authentifizieren Sie sich mit der Nexus-Integrationskennung. Für die Public Edition dokumentiert SAP folgendes Verzeichnis-Muster:

https://<SAP-API-Host>/sap/opu/odata4/sap/cdi/default/sap/cdi/0001/Providers

Identifizieren Sie zuerst den Extractor-Namen​

Der CDS-Definitionsname, ODP-Extractor-Name, CDI-Provider-URL und OData-Entity-Set sind unterschiedliche Kennungen. Suchen Sie nach dem technischen Extractor-Namen, den SAP vergibt — nicht nur nach dem Geschäftsnamen:

  • Classic CDS-View (DEFINE VIEW): Der ODP-Extractor-Name ist der generierte SQL-View-Name aus @AbapCatalog.sqlViewName, inklusive Suffix für die Datenkategorie.
  • CDS View Entity (DEFINE VIEW ENTITY): Verwenden Sie den CDS-Entity-Namen; View Entities erhalten keinen generierten SQL-View-Namen.
  • Key-User CDS-View: Nutzen Sie den technischen Namen aus Custom CDS Views oder View Browser.

Beispiel: SQL View CMMPURORDHIST mit Kategorie #FACT hat den ODP-Extractor-Namen CMMPURORDHIST$F (Fakt/Transaktionsdaten). Weitere Kategorisierungssuffixe sind $P (Stammdaten-Attribute), $T (Text), $H (Hierarchie), $E (andere Datenkategorien). SAPs CDS Extraktions Namensleitfaden beschreibt diese Suffixe.

Bei einer CDS View Entity mit Namen ZI_OrderItem ist der Extraktionsname der Entity-Name, da kein SQL-View-Name generiert wird.

SAP-Example, der CDI-Pfad zeigt eine weitere Namens-Ebene:

KennungBeispiel
CDS-View-Name wie in SAP-DokumentationC_BillingDocItemBasicDEX_1
Provider-Pfadsegment von CDI zurückgegebenc_billingdocitembasicdex_1
OData-Entity-Set innerhalb des ProvidersFacts

Das kleingeschriebene Provider-Segment ist Teil der Provider-URL; Facts ist das tabellenartige Entity Set, das Sie in Package Studio auswählen. CDS-Name, Extractor-Name, Provider-Pfad und Entity Set sind nicht austauschbar.

$ in einem ODP-Kategorisierungssuffix ist unabhängig von OData-Systempfaden wie $metadata und Query-Optionen wie $expand.

Senden Sie die Providers-Anfrage​

Nutzen Sie die Providers-URL aus dem oben genannten Muster. In einem kundenseitig verwalteten System können Sie die Anfrage in /IWFND/GW_CLIENT senden, indem Sie den Pfad nach dem Host eingeben, GET wählen und F8 drücken. In Public Edition verwenden Sie die vollständige URL in Postman oder einem anderen genehmigten HTTP-Client:

  1. Erstellen Sie eine Anfrage und wählen Sie GET.
  2. Fügen Sie die vollständige Providers-URL ein, ersetzen Sie <SAP-API-Host> durch den Host aus den SAP_COM_0531 Inbound Services.
  3. Unter Authorization verwenden Sie die konfigurierte Methode für den Communication User (z. B. Basic Auth mit Nutzername und Passwort oder das zugewiesene Clientzertifikat).
  4. Wählen Sie Send. Suchen Sie in der Antwort nach dem oben identifizierten Extractor-Namen. Eine 200 OK Antwort zeigt einen erfolgreichen Request; das bedeutet jedoch nicht, dass jeder CDS-View verfügbar ist.

Nutzen Sie niemals Ihr persönliches Fiori-Passwort, außer es handelt sich explizit um die konfigurierte Credential des Communication User; und fügen Sie niemals Credentials oder Zertifikatsdaten in einen Screenshot oder ein Support-Ticket ein.

Enthält die Antwort @odata.nextLink, rufen Sie diese URL ebenfalls ab und wiederholen Sie den Prozess, bis keine weiteren Seiten vorhanden sind. Ist der Extractor in keiner Seite enthalten, hat SAP ihn für diesen Nutzer nicht durch CDI bereitgestellt; prüfen Sie Extraktionsfähigkeit, Aktivierung/Veröffentlichung, Ziel-Tenant/Client, Berechtigungsgruppe/Allowlist, Release-Unterstützung und Servicegruppen-Verfügbarkeit. Sobald SAP den Provider zurückliefert, verwenden Sie dessen exakte URL für die folgenden Schritte. Gibt SAP einen ODP/Provider-Fehler zurück, notieren Sie den genauen Fehler und Zeitpunkt für den SAP-Administrator; dies kann ein Problem mit dem Extraction Provider und nicht der Nexus-Katalog sein.

4. Untersuchen Sie die $metadata des Providers​

Fordern Sie den Service Root und dessen $metadata über die von SAP gelieferte Provider-URL an. $metadata ist das Schema des Services: Es zeigt Nexus, welche Entity Sets und Felder existieren und welche Operationen angeboten werden. Prüfen Sie, ob die erwartete Service-Version, Felder, Keys und Entity Set enthalten sind. CDI-Extraktionsprovider geben typischerweise das Facts-Entity Set frei; benutzen Sie den tatsächlich vom Zielservice angegebenen Namen.

Beispiel: Wenn Providers diesen Service Root zurückgibt:

https://<SAP-API-Host>/sap/opu/odata4/sap/cdi_cds/cdi_cds/sap/c_billingdocitembasicdex_1/0001/

hängen Sie /$metadata an, um die Metadata-URL abzurufen:

https://<SAP-API-Host>/sap/opu/odata4/sap/cdi_cds/cdi_cds/sap/c_billingdocitembasicdex_1/0001/$metadata

Die Entity Data-URL ist in diesem Beispiel der gleiche Service Root gefolgt von /Facts. $metadata liefert das Schema; dies ist weder der Provider noch das Entity Set.

Prüfen Sie den Leserechtezugriff auf das Entity Set:

  • Org.OData.Capabilities.V1.ReadRestrictions darf Readable nicht als false deklarieren; falls Restriktion oder Property fehlt, definiert OData standardmäßig Lesbarkeit.

Damit Nexus das Entity Set als CDC-fähig erkennt, prüfen Sie Org.OData.Capabilities.V1.ChangeTracking mit Supported=true. Falls Change Tracking fehlt oder falsch ist, kann das Entity Set für vollständige Extraktion wählbar sein, aber Package Studio wird es nicht als CDC-fähig einstufen.

Schematisches Beispiel der relevanten Metadata-Annotierungen. Kopieren Sie den Wert von Target nicht wortwörtlich; verwenden Sie den Zieldenamen des Service-eigenen $metadata:

<Annotations Target=".../Facts">
  <Annotation Term="Org.OData.Capabilities.V1.ReadRestrictions">
    <Record>
      <PropertyValue Property="Readable" Bool="true" />
    </Record>
  </Annotation>
  <Annotation Term="Org.OData.Capabilities.V1.ChangeTracking">
    <Record>
      <PropertyValue Property="Supported" Bool="true" />
    </Record>
  </Annotation>
</Annotations>

Metadaten zeigen eine Fähigkeit an; sie garantieren nicht, dass eine Delta-Ausführung erfolgreich ist. Für Laufzeitvalidierung führen Sie die Erst-Anfrage/-Ausführung durch und bestätigen, dass SAP einen @odata.deltaLink zurückliefert. Das Key-User-Szenario Data Extraction im Custom CDS Views-Tool unterstützt ausschließlich vollständige Extraktion; CDC ist für diesen View-Typ nicht zu erwarten.

5. Prüfen Sie Package Studio und SAP Gateway-Fehler​

Ist der Provider im Providers-Response von SAP sichtbar und dessen $metadata lesbar:

  1. Prüfen Sie, ob die Nexus-Verbindung auf den richtigen SAP-Host und OData V4-Konfiguration zeigt.
  2. In Package Studio erweitern Sie Servicegruppe, Service und Version, anschließend wählen Sie das Entity Set aus. Suchen Sie nach dem Entity Set-Namen oder nutzen Sie den vollständigen Provider/Entity Set-Pfad von SAP, nicht nur den Geschäftsnamen oder Z*.
  3. Bestätigen Sie, dass die eingesetzte Nexus-Version SAP OData-Extraktion unterstützt. OData-Extraktionssupport wurde in Nexus 1.20.425 eingeführt; SAP S/4HANA Cloud Public Edition wird ab Nexus 1.21 unterstützt.
  4. Sendet SAP Fehler, nutzen Sie /IWFND/ERROR_LOG und ggf. /IWBEP/ERROR_LOG im SAP Logon zur Analyse von Gateway-/Backend-Fehlermeldungen. /IWFND/GW_CLIENT kann Metadaten- und Provider-Anfragen reproduzieren. Diese Logs sind für kundenseitig verwaltete Systeme; Public Edition-Nutzer sollten SAP Support die Request-URL, Zeitstempel, Response, Tenant und Kommunikationsvereinbarung-Details bereitstellen.

Funktionieren Service und Metadaten mit der Integrationskennung, aber Package Studio blendet das Entity Set dennoch aus, erfassen Sie den exakten Service Root, Entity Set-Pfad, Nexus-Version und Response-Metadaten für den Nexus-Support.

Referenzen​