Eine Datenquelle verbinden

Eine Datenquelle ist die Verbindung von Noreja zu einer Datenbank oder einem Geschäftssystem. Du richtest sie einmal ein; Entitäten lesen dann ihre Tabellen daraus. Noreja liest aus Datenquellen nur, es schreibt nie hinein.

Auf dieser Seite findest du:

• Die Schritte in Noreja, für Datenspezialistinnen und -spezialisten: die unterstützten Systeme, wie du eine Datenbank oder eine Schnittstelle verbindest, die Verbindung testest und die Datenquelle aktuell hältst.

• Die Vorbereitung des Quellsystems, für dessen Administration: was jedes System braucht, dann ein Abschnitt pro System mit seinen Besonderheiten: Microsoft SQL Server vorbereiten, PostgreSQL vorbereiten, Oracle vorbereiten (mit Oracle Gateway), SAP HANA 2 vorbereiten, IBM Db2 vorbereiten, Snowflake vorbereiten, ServiceNow vorbereiten und Über OData verbinden.

Zwei weitere Seiten helfen bei den Daten selbst: Quelldaten vorbereiten: Schlüssel, Zeitstempel, Indizes beschreibt, was die Tabellen für ein gutes Prozessmodell bieten sollten (stabile Schlüssel, verbindende Spalten, saubere Zeitstempel) und welche Indizes große Importe beschleunigen. Erweiterte Abfragen mit der ServiceNow-API erklärt die Encoded Queries, die begrenzen, welche Datensätze Noreja aus ServiceNow liest.

Berechtigungen: Feature Builder: Erstellen, um Datenquellen hinzuzufügen, Bearbeiten, um sie zu ändern, Löschen, um sie zu löschen. Das Löschen einer Datenquelle löscht auch alle darauf aufgebauten Entitäten und Perspektiven. Datenquellen lassen sich nicht teilen. Siehe Rollen erstellen und bearbeiten.

Bevor du anfängst

• Deine IT hat das System vorbereitet: einen Benutzer mit Lesezugriff und das Netzwerk für Noreja geöffnet. Der Abschnitt zu deinem System weiter unten auf dieser Seite beschreibt, was nötig ist; die Tabelle unten nennt ihn.

• Du brauchst eine Rolle, die das Erstellen im Builder erlaubt.

Unterstützte Systeme

Eine Datenbank verbinden

• Öffne Builder und wähle Datenquellen.

• Klicke auf Datenquelle hinzufügen und lass Datenbank ausgewählt.

• Gib unter Name der Datenquelle einen Namen ein, der sagt, um welches System es sich handelt, zum Beispiel „Purchasing ERP“.

• Wähle den Verbindungstyp.

• Gib den Datenbank-Host (Name oder IP-Adresse des Servers) und den Port ein. Es gibt keinen Standardwert; gib den Port ein, auf dem deine Datenbank lauscht (siehe Tabelle oben).

• Lass unter Authentifizierung die Option Benutzer & Passwort ausgewählt. Hake SSL verwenden für eine verschlüsselte Verbindung an.

• Gib den Benutzer und das Passwort ein, die deine IT für Noreja angelegt hat.

• Gib die Datenbank ein oder klicke auf das Aktualisieren-Symbol daneben, um aus den Datenbanken zu wählen, die dieser Benutzer öffnen darf. Bei Oracle heißt das Feld Service-Name. Bei IBM Db2, Oracle und Oracle Gateway gibt es kein Aktualisieren-Symbol; tippe den Namen ein.

• Gib unter Schema die Schemas ein, die deine Tabellen enthalten, oder wähle sie aus (bei IBM Db2, Oracle und Oracle Gateway tippst du sie ein). Für Oracle, Oracle Gateway, SAP HANA und Db2 sind sie Pflicht.

• Klicke auf Hinzufügen.

Einige Systeme haben zusätzliche Felder:

• Oracle: Hake bei einer Multitenant-Datenbank Multi-Tenancy? an und gib den Container ein. SSL verwenden schaltet die eigene Netzwerkverschlüsselung von Oracle ein.

• Snowflake: Warehouse ist optional; ohne Angabe wird das Standard-Warehouse des Benutzers verwendet. Noreja arbeitet mit der Standardrolle des Benutzers. Hake SSL verwenden an; Snowflake verlangt es, und es ist standardmäßig nicht angehakt.

Der Abschnitt zu jedem System weiter unten beschreibt seine Werte im Detail.

Eine Schnittstelle verbinden

• Klicke auf Datenquelle hinzufügen und wähle API.

• Gib unter Name der Datenquelle einen Namen ein und wähle den Verbindungstyp.

• Gib den Server-Host mit https:// ein, zum Beispiel die Adresse deiner ServiceNow-Instanz oder die Service-Adresse des OData-Service. Port ist optional; bei ServiceNow und OData lässt du ihn leer.

• Wähle die Authentifizierung und fülle ihre Felder aus (siehe unten).

• Klicke auf Hinzufügen.

Die zwei Arten der Authentifizierung:

• Basic Auth: ein Benutzer und ein Passwort.

• OAuth2: Token URL, Client Id und Client Secret eines für Noreja registrierten Clients sowie Scopes, falls dein System sie braucht. Noreja meldet sich als dieser Client an (Client Credentials Grant), ohne Benutzer.

Die Verbindung testen

Eine neue Datenquelle ist Nicht getestet. Klicke in der Liste in ihrer Zeile auf Testen. Der Test prüft zwei Verbindungen: vom Builder aus und von Neo4j aus, das den Import ausführt. Nur getestete Datenquellen lassen sich für neue Entitäten verwenden.

Schlägt eine Prüfung fehl, öffnet Noreja die Datenquelle mit dem Fehler:

• Importer Verbindungsfehler: Der Builder konnte die Quelle nicht erreichen oder sich nicht anmelden.

• Neo4j Verbindungsfehler: Der Import von Noreja konnte die Quelle nicht erreichen. Der Import läuft getrennt vom Builder, daher muss das Netzwerk beides erlauben.

Prüfe Host, Port und Zugangsdaten und frag deine IT, ob das Netzwerk für Noreja geöffnet ist.

Der Status kann Getestet anzeigen, obwohl die Neo4j-Prüfung fehlgeschlagen ist. Importe aus einer solchen Datenquelle schlagen fehl. Verwende eine Datenquelle erst dann für Entitäten, wenn ein Test keinen der beiden Fehler zeigt.

Eine Datenquelle aktuell halten

• Bearbeiten: ändert die Verbindungsdaten. Danach ist die Datenquelle wieder Nicht getestet; teste sie.

• Cache erneuern: Noreja merkt sich die Liste der Tabellen und Spalten einer Datenquelle. Wurden in der Quelle Tabellen oder Spalten hinzugefügt oder geändert, erneuere sie, damit der Builder den aktuellen Stand zeigt.

• Löschen: löscht die Datenquelle zusammen mit allen darauf aufgebauten Entitäten und Perspektiven. Die Bestätigung listet sie auf.

Was jedes Quellsystem braucht

Dieser Teil und die Abschnitte danach richten sich an die Administratorinnen und Administratoren, die das Quellsystem für Noreja vorbereiten. Die Datenspezialistin oder der Datenspezialist trägt die Verbindung dann wie oben beschrieben in Noreja ein.

• Netzwerkzugang: Noreja verbindet sich mit deinem System, nicht umgekehrt; dein System muss Noreja nicht erreichen. Zwei Teile von Noreja verbinden sich mit einer Datenbank: die Noreja-Dienste (für den Test, die Tabellenliste und Testabfragen) und der Neo4j-Server, der die Importabfragen ausführt. Öffne den Datenbank-Port in der Firewall für Verbindungen von Noreja; läuft Neo4j auf einem eigenen Host, erlaube beide Hosts. Testen prüft beide Verbindungen. Schnittstellen (ServiceNow, OData) werden über HTTPS erreicht; wenn du den Zugriff nach IP-Adresse beschränkst, erlaube die Adressen von Noreja. Läuft dein Noreja in der Cloud von Noreja, frag bei Noreja nach den Adressen, die du erlauben musst.

• Ein Benutzer, der nur lesen kann: mit Passwort und Lesezugriff auf die Tabellen, die die Entitäten verwenden werden (bei einer Datenbank in einer Datenbank). Gib ihm keinen Schreibzugriff; Noreja braucht ihn nicht.

• Nur lesende Abfragen: Noreja schickt an Datenbanken nur SELECT-Abfragen, erzeugt aus den Einstellungen der Entität, und an Schnittstellen nur GET-Anfragen. Als Sicherheitsnetz blockiert Noreja zusätzlich gängige Anweisungen, die Daten ändern; deine Daten schützt aber der Benutzer mit reinen Leserechten.

• Gespeicherte Zugangsdaten: Passwörter und Client Secrets werden verschlüsselt gespeichert.

• Werte in Noreja: Verbindungstyp und Port stehen in der Tabelle unter Unterstützte Systeme; Host, Benutzer und Passwort sind dein Server und der Benutzer, den du angelegt hast. Der Abschnitt zu deinem System nennt die übrigen Werte.

• Tabellengrößen: Der Builder zeigt die Größe jeder Tabelle. Ohne das Recht, die Größeninformationen des Systems zu lesen, schätzt Noreja sie; alles andere funktioniert. Der Abschnitt zu deinem System nennt die Berechtigung.

• Passwörter mit Sonderzeichen: Bei einigen Datenbanken schlägt der Test mit bestimmten Zeichen im Passwort fehl, obwohl die Zugangsdaten stimmen. Der Abschnitt zu deinem System nennt sie; versuche es mit einem Passwort ohne diese Zeichen.

• Indizes: Importe lesen seitenweise. Indizes auf den Schlüssel-, Join- und Zeitstempelspalten helfen bei großen Importen. Siehe Quelldaten vorbereiten: Schlüssel, Zeitstempel, Indizes.

• Zeitlimit für Anfragen an Schnittstellen: Jede Anfrage an ServiceNow oder einen OData-Service wartet bis zu 50 Sekunden und wird einige Male wiederholt, bevor der Import einen Fehler meldet.

Microsoft SQL Server vorbereiten

Noreja verbindet sich mit einem Host und einem festen Port; den SQL Server Browser oder Instanznamen verwendet es nicht. Es meldet sich mit einem SQL-Server-Login und einem Passwort an; Windows-Authentifizierung wird nicht unterstützt.

1. Netzwerkverbindungen erlauben

• Aktiviere im SQL Server Configuration Manager TCP/IP für die Instanz.

• Gib einer benannten Instanz einen festen TCP-Port statt eines dynamischen. Die Standardinstanz verwendet 1433.

• Öffne diesen Port in der Firewall für Verbindungen von Noreja (siehe Was jedes Quellsystem braucht oben).

• Stelle sicher, dass der Server SQL-Server-Authentifizierung erlaubt (gemischter Modus).

2. Einen Login nur mit Leserechten anlegen

CREATE LOGIN noreja_reader WITH PASSWORD = '<strong password>';
USE purchasing;
CREATE USER noreja_reader FOR LOGIN noreja_reader;
-- Lesezugriff auf ein Schema:
GRANT SELECT ON SCHEMA::dbo TO noreja_reader;
-- optional: damit der Builder Tabellengrößen zeigt
GRANT VIEW DATABASE STATE TO noreja_reader;

Statt der Berechtigung auf das Schema kannst du den Benutzer der Rolle db_datareader hinzufügen, für Lesezugriff auf die ganze Datenbank. Ohne VIEW DATABASE STATE schätzt Noreja die Tabellengrößen.

3. Werte für Noreja

• Verbindungstyp: MSSQL Server.

• Datenbank: die Datenbank mit den Tabellen; gib sie von Hand ein oder wähle sie aus der Liste, die das Aktualisieren-Symbol lädt.

• Schema: optional; die Schemas mit den Tabellen, zum Beispiel dbo.

• SSL verwenden: anhaken, um die Verbindung zu verschlüsseln.

• Passwort: Schlägt der Test fehl, obwohl die Zugangsdaten stimmen, prüfe, ob das Passwort ; enthält, und versuche eines ohne.

PostgreSQL vorbereiten

Noreja braucht eine Rolle mit Passwort und Lesezugriff auf die Tabellen, in einer Datenbank, und eine TCP-Verbindung zum PostgreSQL-Port, meist 5432.

1. Netzwerkverbindungen erlauben

• Stelle sicher, dass der Server auf einer Netzwerkadresse lauscht (listen_addresses in postgresql.conf).

• Füge in pg_hba.conf eine Zeile für Noreja hinzu, zum Beispiel host purchasing noreja_reader <Noreja address>/32 scram-sha-256, und lade die Konfiguration neu. Dieses Beispiel erlaubt nur die Datenbank purchasing. Das Aktualisieren-Symbol in Noreja, das die Datenbanken auflistet, verbindet sich zuerst mit der Datenbank postgres; erlaube also entweder auch postgres oder gib die Datenbank in Noreja von Hand ein.

• Öffne den Port in der Firewall für Verbindungen von Noreja. Läuft Neo4j auf einem eigenen Host, erlaube beide Hosts in der Firewall und in pg_hba.conf.

2. Eine Rolle nur mit Leserechten anlegen

CREATE ROLE noreja_reader LOGIN PASSWORD '<strong password>';
GRANT CONNECT ON DATABASE purchasing TO noreja_reader;
-- verbunden mit der Datenbank purchasing:
GRANT USAGE ON SCHEMA public TO noreja_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO noreja_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO noreja_reader;

Wiederhole die Schema-Zeilen für jedes Schema, das Noreja lesen soll. Die letzte Zeile deckt auch später angelegte Tabellen ab, aber nur die, die von der Rolle angelegt werden, die sie ausführt. Legt eine andere Rolle die Tabellen an, zum Beispiel der Eigentümer der Anwendung, ergänze FOR ROLE <owner> nach ALTER DEFAULT PRIVILEGES.

3. Werte für Noreja

• Verbindungstyp: Postgres.

• Datenbank: die Datenbank mit den Tabellen. Gib sie von Hand ein oder nutze das Aktualisieren-Symbol, das die Datenbanken auflistet, mit denen sich die Rolle verbinden darf, sofern pg_hba.conf auch die Datenbank postgres erlaubt.

• Schema: optional; die Schemas mit den Tabellen. Ohne Angabe werden alle Schemas außer den Systemschemas verwendet.

• SSL verwenden: anhaken, um die Verbindung zu verschlüsseln; auf dem Server muss SSL aktiviert sein.

Oracle vorbereiten

Noreja braucht:

• Netzwerkzugang: eine TCP-Verbindung zum Listener-Port, meist 1521.

• Den Service-Namen der Datenbank (nicht die SID). Bei einer Multitenant-Datenbank: die Pluggable Database, aus der gelesen werden soll.

• Einen Benutzer mit Passwort, CREATE SESSION und SELECT auf den Tabellen, die die Entitäten verwenden werden.

Einen Benutzer nur mit Leserechten anlegen

CREATE USER noreja_reader IDENTIFIED BY "<strong password>";
GRANT CREATE SESSION TO noreja_reader;
-- für jede Tabelle, die Noreja lesen soll:
GRANT SELECT ON purchasing.bestellung TO noreja_reader;
GRANT SELECT ON purchasing.bestellposition TO noreja_reader;

Berechtigungen pro Tabelle halten den Zugriff minimal. Werden viele Tabellen gebraucht, erlauben deine Richtlinien vielleicht stattdessen eine Rolle mit diesen Berechtigungen.

Werte für Noreja

• Verbindungstyp: Oracle.

• Service-Name: der Service-Name der Datenbank.

• Multi-Tenancy? und Container: Hake die Option bei einer Multitenant-Datenbank an und gib den Service-Namen der Pluggable Database ein. Noreja verbindet sich dann mit ihr statt mit dem Service-Namen oben.

• Schema: Pflicht; die Schemas, denen die Tabellen gehören, zum Beispiel PURCHASING.

• SSL verwenden: schaltet die native Netzwerkverschlüsselung und Integritätsprüfung von Oracle ein; der Server muss sie akzeptieren (SQLNET.ENCRYPTION_SERVER und SQLNET.CRYPTO_CHECKSUM_SERVER mindestens ACCEPTED). Bekanntes Problem: Mit angehaktem SSL verwenden können Importe fehlschlagen, auch wenn Testen erfolgreich ist. Wenn du eine verschlüsselte Verbindung brauchst, wende dich an Noreja.

• Passwort: Schlägt der Test fehl, obwohl die Zugangsdaten stimmen, prüfe, ob das Passwort @ oder / enthält, und versuche eines ohne.

Der Builder zeigt Tabellengrößen nur für Tabellen, die dem verbindenden Benutzer gehören; für andere schätzt er sie.

Oracle Gateway

Der Verbindungstyp Oracle Gateway liest die Tabellen eines SAP-Systems über eine Oracle-Datenbank, die SAP über einen Database Link erreicht. Er erwartet eine bestimmte Einrichtung auf der Oracle-Seite; wende dich an Noreja, bevor du ihn verwendest.

SAP HANA 2 vorbereiten

Noreja braucht eine TCP-Verbindung zum SQL-Port der Tenant-Datenbank und einen Datenbankbenutzer mit Passwort und SELECT auf den Schemas mit den Tabellen. Der Port hängt von der Instanznummer und dem Tenant ab; deine HANA-Administration kennt ihn. Um SAP-Daten stattdessen über OData-Services zu lesen, siehe Über OData verbinden unten.

Einen Benutzer nur mit Leserechten anlegen

CREATE USER NOREJA_READER PASSWORD "<strong password>"
  NO FORCE_FIRST_PASSWORD_CHANGE;
GRANT SELECT ON SCHEMA SAPHANADB TO NOREJA_READER;

Ersetze SAPHANADB durch die Schemas, die Noreja lesen soll. Optional gibst du dem Benutzer Lesezugriff auf die Monitoring-Views M_CS_TABLES und M_RS_TABLES, damit der Builder Tabellengrößen zeigen kann; ohne ihn werden die Größen geschätzt.

Werte für Noreja

• Verbindungstyp: SAP HANA 2.

• Datenbank-Host und Port: der HANA-Host und der SQL-Port der Tenant-Datenbank.

• Datenbank: der Name der Tenant-Datenbank; gib ihn von Hand ein. Das Aktualisieren-Symbol listet dann ihre Schemas auf.

• Schema: Pflicht; die Schemas mit den Tabellen.

• SSL verwenden: anhaken, um die Verbindung zu verschlüsseln; auf dem Server muss TLS aktiviert sein.

• Passwort: Schlägt der Test fehl, obwohl die Zugangsdaten stimmen, prüfe, ob das Passwort & enthält, und versuche eines ohne.

IBM Db2 vorbereiten

Noreja braucht eine TCP-Verbindung zum Db2-Port, standardmäßig 50000 (oder der SSL-Port, wenn du Verschlüsselung verwendest), und einen Benutzer, den Db2 per Passwort authentifiziert, mit CONNECT auf der Datenbank und SELECT auf den Tabellen.

Lesezugriff gewähren

GRANT CONNECT ON DATABASE TO USER NOREJA;
-- für jede Tabelle, die Noreja lesen soll:
GRANT SELECT ON TABLE PURCH.BESTELLUNG TO USER NOREJA;
GRANT SELECT ON TABLE PURCH.BESTELLPOSITION TO USER NOREJA;

Db2 authentifiziert Benutzer meist über das Betriebssystem oder LDAP; lege den Benutzer zuerst dort an. Für Tabellengrößen im Builder muss der Benutzer SYSIBMADM.ADMINTABINFO lesen dürfen; ohne dieses Recht werden die Größen geschätzt.

Werte für Noreja

• Verbindungstyp: IBM Db2 11.

• Datenbank: der Datenbankname; gib ihn von Hand ein.

• Schema: Pflicht; die Schemas mit den Tabellen, zum Beispiel PURCH.

• SSL verwenden: anhaken, um die Verbindung zu verschlüsseln; verwende den SSL-Port des Servers.

• Passwort: Schlägt der Test fehl, obwohl die Zugangsdaten stimmen, prüfe, ob das Passwort ; enthält, und versuche eines ohne.

Snowflake vorbereiten

Noreja verbindet sich über HTTPS (Port 443) mit deinem Snowflake-Konto. Wenn du den Zugriff mit Network Policies beschränkst, erlaube die Adressen beider Teile von Noreja (siehe Was jedes Quellsystem braucht oben). Noreja braucht:

• Einen Benutzer mit Passwort, dessen Default Role die Tabellen lesen darf. Noreja arbeitet immer mit der Standardrolle des Benutzers; ein Feld für eine andere Rolle gibt es nicht.

• Ein Warehouse, das die Rolle verwenden darf, als Standard-Warehouse des Benutzers oder in Noreja eingetragen.

Eine Rolle und einen Benutzer anlegen

CREATE ROLE NOREJA_READER;
GRANT USAGE ON WAREHOUSE ANALYTICS_WH TO ROLE NOREJA_READER;
GRANT USAGE ON DATABASE PURCHASING TO ROLE NOREJA_READER;
GRANT USAGE ON SCHEMA PURCHASING.ERP TO ROLE NOREJA_READER;
GRANT SELECT ON ALL TABLES IN SCHEMA PURCHASING.ERP
  TO ROLE NOREJA_READER;
GRANT SELECT ON FUTURE TABLES IN SCHEMA PURCHASING.ERP
  TO ROLE NOREJA_READER;

CREATE USER NOREJA PASSWORD = '<strong password>'
  DEFAULT_ROLE = NOREJA_READER DEFAULT_WAREHOUSE = ANALYTICS_WH;
GRANT ROLE NOREJA_READER TO USER NOREJA;

Noreja meldet sich mit Benutzer und Passwort an. Verlangt dein Konto für alle Benutzer Multi-Faktor-Authentifizierung oder Schlüsselpaare, sprich mit Noreja, bevor du die Verbindung einrichtest.

Werte für Noreja

• Verbindungstyp: Snowflake.

• Datenbank-Host und Port: der Hostname deines Kontos, zum Beispiel xy12345.eu-central-1.snowflakecomputing.com, und 443.

• Datenbank: die Datenbank; das Aktualisieren-Symbol listet die Datenbanken auf, die die Rolle verwenden darf.

• Schema: die Schemas mit den Tabellen.

• Warehouse: optional; das Warehouse, das statt des Standard-Warehouse des Benutzers verwendet wird.

• SSL verwenden: anhaken. Bei einer neuen Datenquelle ist es nicht angehakt, und ohne die Option funktioniert die Verbindung mit einem Snowflake-Konto nicht.

Importe führen ihre Abfragen auf dem Warehouse aus und verbrauchen dessen Credits. Dimensioniere es passend zur Datenmenge und lass es automatisch pausieren. Siehe auch Performance-Tipps für große Importe.

ServiceNow vorbereiten

Noreja liest ServiceNow-Tabellen über die REST-Schnittstelle und schreibt nie.

Was Noreja liest

Noreja schickt nur GET-Anfragen an diese Schnittstellen:

1. Einen Integrationsbenutzer anlegen

• Lege einen Benutzer für Noreja an, zum Beispiel noreja.integration, und kennzeichne ihn als Web-Service-Benutzer, wenn deine Richtlinien das vorsehen.

• Gib ihm Lesezugriff auf sys_db_object, sys_dictionary und die zu analysierenden Tabellen sowie das Recht, die Table API und die Aggregate API zu nutzen. Welche Rollen das gewähren, hängt von den Zugriffsregeln deiner Instanz ab.

• Gib ihm keinen Schreibzugriff.

2. Wählen, wie Noreja sich anmeldet

• Basic Authentication: Noreja meldet sich mit Name und Passwort des Integrationsbenutzers an. Wähle in Noreja Basic Auth.

• OAuth2: Registriere in der Application Registry einen OAuth-Client für Noreja mit dem Client Credentials Grant, verknüpft mit dem Integrationsbenutzer. Die Token-Adresse ist https://<instance>.service-now.com/oauth_token.do. Je nach Release muss der Client Credentials Grant erst aktiviert werden; siehe die Dokumentation von ServiceNow.

3. Werte für Noreja

• Art: API.

• Verbindungstyp: Service Now.

• Server-Host: https://<instance>.service-now.com. Lass Port leer.

Große Tabellen werden seitenweise gelesen. Begrenze sie mit WHERE-Klauseln in der Entität, zum Beispiel auf aktuelle Datensätze; siehe Objekte und Beziehungen konfigurieren.

Über OData verbinden

Noreja kann Daten aus OData-Services lesen, zum Beispiel aus SAP-Gateway-Services, und schickt nur lesende Anfragen. Es braucht:

• Einen OData-Service in Version 2 oder 4. Noreja erkennt die Version selbst aus den Metadaten des Service.

• Netzwerkzugang über HTTPS (siehe Was jedes Quellsystem braucht oben).

• Einen Benutzer oder einen OAuth2-Client mit dem Client Credentials Grant, der die Entity Sets des Service lesen darf. Bei SAP-Gateway-Services muss der Service aktiviert sein, und der Benutzer braucht die Berechtigungen, ihn aufzurufen.

Um SAP HANA 2 stattdessen direkt über SQL zu lesen, siehe SAP HANA 2 vorbereiten oben.

Was Noreja liest

• Metadaten: das Metadaten-Dokument des Service mit den Entity Sets, ihren Eigenschaften, Schlüsseln und Beziehungen. Noreja nutzt die Beziehungen für Vorschläge im Entitäten-Builder; siehe Eine Entität erstellen, manuell oder mit Vorschlägen.

• Anzahlen: die Zahl der Datensätze pro Entity Set.

• Datensätze: seitenweise, mit den üblichen OData-Abfrageoptionen (select, filter, top, skip, orderby und expand).

Werte für Noreja

• Art: API.

• Verbindungstyp: OData.

• Server-Host: die Stammadresse des Service, mit https://, zum Beispiel https://sap.example.com:44300/sap/opu/odata/sap/ZPURCHASING_SRV.

• Port: leer lassen. Verwendet der Service einen besonderen Port, nimm ihn wie im Beispiel in die Adresse auf.

Wenn du die Datenquelle testest, liest Noreja die Metadaten des Service. Schlägt der Test mit einem Statuscode fehl, prüfe die Adresse und die Berechtigungen des Benutzers.

Die Entity Sets erscheinen im Entitäten-Builder wie Tabellen. Ihre Namen werden als Bezeichnungen verwendet. Bei Schnittstellenquellen haben Objekte keine Einstellung für den eindeutigen Schlüssel und verwenden eine Join-Tabelle statt einer JOIN-Klausel; siehe Objekte und Beziehungen konfigurieren.

Verwandte Artikel

• Quelldaten vorbereiten: Schlüssel, Zeitstempel, Indizes

• Erweiterte Abfragen mit der ServiceNow-API

• Eine Entität erstellen, manuell oder mit Vorschlägen

• Von der Datenquelle zur Perspektive: Wie der Builder funktioniert und wer was macht

• Fehlerbehebung bei Importen