Jira Service Management Verbindungsdetails

Einführung

Connector-Version

Diese Dokumentation basiert auf Version 21.0.8662 des Connectors.

Erste Schritte

Jira Service Desk-Versionsunterstützung

Der Connector nutzt die Jira Service Desk-API, um einen bidirektionalen Zugriff auf Jira Service Desk zu ermöglichen.

Der Connector funktioniert sowohl mit Jira Service Desk Cloud-Konten als auch mit Jira Service Desk Server-Instanzen.

Atlassian Jira Service Management hieß früher Jira Service Desk und erhielt seinen neuen Namen ab der Version 4.14. Es gibt jedoch viele Verweise auf Service Desk in dieser Dokumentation, der Atlassian-Dokumentation und den Atlassian REST APIs. Siehe die Versionshinweise zu Atlassian Service Management 4.14.x für Einzelheiten.

Herstellen einer Verbindung

Mit Jira Service Desk verbinden

Sie können eine Verbindung zu jedem Jira Service Desk Cloud-Konto oder Jira Service Desk Server-Instanz herstellen. Um eine Verbindung herzustellen, legen Sie die folgende Eigenschaft fest:

• URL (zum Beispiel: https://IhrSitename.atlassian.net).

Authentifizieren Sie sich beim Jira Service Desk

Grundlegende Authentifizierung

Authentifizierung mit einem Cloud-Konto

Um eine Verbindung mit einem Cloud-Konto herzustellen, müssen Sie zunächst ein abrufen APIToken. Um eins zu generieren, melden Sie sich bei Ihrem Atlassian-Konto an und navigieren Sie zu API tokens > Create API token. Das generierte Token wird angezeigt.

Geben Sie Folgendes ein, um eine Verbindung zu den Daten herzustellen:

• AuthScheme: Legen Sie diese Basis fest.
• User: Setzen Sie dies auf den Benutzernamen des authentifizierenden Benutzers.
• APIToken: Setzen Sie dies auf das zuvor gefundene API Token.

Authentifizierung mit einem lokalen Serverkonto

Zur Authentifizierung mit einem lokalen Serverkonto müssen Sie die folgenden Verbindungseigenschaften angeben:

• AuthScheme: Legen Sie diese Basis fest.
• User: Setzen Sie dies auf den Benutzernamen des authentifizierenden Benutzers.
• Password: Setzen Sie dies auf das Passwort des authentifizierenden Benutzers.
• URL: Setzen Sie dies auf die URL, die mit Ihrem Jira Service Desk-Endpoint verknüpft ist. Beispiel: https://yoursitename.atlassian.net.

Authentifizieren mit einer benutzerdefinierten OAuth-App (3LO)

Sie können die „dreibeinige“ OAuth 2.0-Unterstützung (3LO) von Jira Service Desk nutzen, um eine Verbindung zu Daten herzustellen, ohne Ihre Anmeldeinformationen anzugeben. Siehe OAuth-Authentifizierung verwenden für eine Anleitung zur Authentifizierung.

Authentifizierung mit OAuth1.0

Um eine Verbindung mit Jira Service Desk herzustellen, müssen Sie die folgenden Schritte ausführen:

• Generieren Sie zunächst ein öffentliches/privates RSA-Schlüsselpaar. Führen Sie in Ihrem Terminal die folgenden Befehle aus:
  -openssl genrsa -out jira_privatekey.pem 1024
  -openssl req -newkey rsa:1024 -x509 -key jira_privatekey.pem -out jira_publickey.cer -days 365
  -openssl pkcs8 -topk8 -nocrypt -in jira_privatekey.pem -out jira_privatekey.pcks8
  -openssl x509 -pubkey -noout -in jira_publickey.cer -out jira_publickey.pem
  
• Erstellen Sie Anwendungslinks in Ihrem Konto. Gehen Sie zu Einstellungen -> Anwendungen -> Anwendungslinks.
• Geben Sie eine Test URL für das URL Feld ein und klicken Sie auf „Neuen Link erstellen“.
• Ignorieren Sie den Fehler und klicken Sie auf „Weiter“. Wir möchten nur eingehende Anrufe konfigurieren (von der App zum Jira Service Desk).
• Füllen Sie im Fenster „Anwendungen verknüpfen“ die Felder nach Belieben aus, da sie nicht relevant sind. Aktivieren Sie jedoch unbedingt „Eingehenden Link erstellen“. Klicken Sie auf „Weiter“, um zur nächsten Seite zu gelangen.
• Füllen Sie die erforderlichen Felder aus:
  -Consumer Key: Füllen Sie diesen nach Belieben aus. Sie werden ihn später als OAuthClientId verwenden.
  
  • Name des Verbrauchers: Füllen Sie dies nach Belieben aus.
    -Öffentlicher Schlüssel: Geben Sie den Schlüssel in die zuvor generierte Datei „jira_publickey.pem“ ein. Und klicken Sie auf „Weiter“.

Legen Sie zum Herstellen der Verbindung die folgenden Eigenschaften fest:

• URL (zum Beispiel: https://IhrSitename.atlassian.net).
• OAuthClientId zum Consumer Key Ihrer Anwendung.
• OAuthClientSecret auf einen beliebigen Wert (z. B. „testClientSecret“).
• OAuthJWTCert zum Speicherort Ihrer privaten Schlüsseldatei.
• OAuthJWTCertType auf die entsprechende Option basierend auf der verwendeten privaten Schlüsseldatei. Wenn Sie die generierte PEM-Schlüsseldatei verwenden, setzen Sie OAuthJWTCertType zu PEMKEY_FILE.
• InitiateOAuth zu GETANDREFRESH.

Authentifizieren mit Crowd

Setzen Sie die AuthScheme Zu Crowd. Die folgenden Verbindungseigenschaften werden zur Verbindung mit Crowd verwendet:

• User: Das CROWD-Benutzerkonto.
• Password: Das mit dem Crowd-Konto verknüpfte Passwort.
• SSOLoginURL: Die mit dem Crowd-Konto verknüpfte Anmelde URL. Sie finden die IDP- URL, indem Sie zu navigieren your application -> SSO -> SSO information -> Identity provider single sign-on URL.
• SSOAppName: Der Name der Anwendung, in der SSO aktiviert ist.
• SSOAppPassword: Das Passwort der Anwendung, in der SSO aktiviert ist.
• SSOExchangeUrl: Die URL, die zum Austausch des SAML -Tokens gegen JiraServiceDesk-Cookies verwendet wurde. Diese URL kann die folgenden Formate haben:
  • https://<authority der JiraServiceDesk-Instanz>/plugins/servlet/samlconsumer
  • https://<authority der JiraServiceDesk-Instanz>/plugins/servlet/samlsso

Das Folgende ist ein Beispiel für eine Verbindungszeichenfolge:

AuthScheme=Crowd;Url=https://yoursitename.atlassian.net;SSOLoginURL='https://<authority>/crowd/console/secure/saml/sso.action';User=crowdUserName;Password=crowdPassword;SSOExchangeUrl=https://<authority of JiraServiceDesk instance>/plugins/servlet/samlconsumer;SSOAppName=CrowdAppName;SSOAppPassword=CrowdAppPassword;

Authentifizieren mit Okta

Setzen Sie die AuthScheme Zu Okta. Die folgenden Verbindungseigenschaften werden zum Herstellen einer Verbindung mit Okta verwendet:

• User: Stellen Sie dies auf den Okta-Benutzer ein.
• Password: Legen Sie hier das Okta-Passwort für den Benutzer fest.
• SSOLoginURL: Legen Sie dies auf die vom SSO-Anbieter verwendete Anmelde URL fest.
• SSOExchangeUrl: Die URL, die zum Austausch des SAML -Tokens gegen JiraServiceDesk-Cookies verwendet wurde. Diese URL kann die folgenden Formate haben:
  • https://<authority der JiraServiceDesk-Instanz>/plugins/servlet/samlconsumer
  • https://<authority der JiraServiceDesk-Instanz>/plugins/servlet/samlsso

Folgendes SSOProperties werden zur Authentifizierung bei Okta benötigt:

• APIToken (optional): Legen Sie hier das API Token fest, das der Kunde aus der Okta-Organisation erstellt hat. Es sollte verwendet werden, wenn ein Benutzer über eine vertrauenswürdige Anwendung oder einen Proxy authentifiziert wird, der den OKTA-Client-Anforderungskontext überschreibt.
• MFAType (optional): Legen Sie dies nur fest, wenn Sie einen MFA-Flow konfiguriert haben. Derzeit unterstützen wir nur die folgenden Typen: OktaVerify, Email und SMS.
• MFAPassCode (optional): Legen Sie dies nur fest, wenn Sie einen MFA-Flow konfiguriert haben. Wenn dies auf leer/ungültig gesetzt ist, gibt der Treiber zunächst eine MFA-Herausforderung aus, die die Plattform dazu veranlasst, Ihnen basierend auf dem konfigurierten MFA-Typ ein Einmalkennwort an Ihr Gerät oder Email zu senden. Sie müssen eine weitere Verbindung erneut herstellen, bei der der abgerufene Einmalkennwortwert an die Verbindungseigenschaft MFAPassCode übergeben wird.

Nachfolgend sehen Sie ein Beispiel für eine Verbindungszeichenfolge:

AuthScheme=Okta;Url=https://yoursitename.atlassian.net;SSOLoginURL='https://example.okta.com/home/appType/0bg4ivz6cJRZgCz5d6/46';User=oktaUserName;Password=oktaPassword;SSOExchangeUrl=https://<authority of JiraServiceDesk instance>/plugins/servlet/samlconsumer;

Zugriff auf benutzerdefinierte Felder

Standardmäßig zeigt der Connector nur Systemfelder an. Um auf die benutzerdefinierten Felder für Probleme zuzugreifen, setzen Sie IncludeCustomFields.

OAuth-Authentifizierung verwenden

OAuth erfordert, dass der authentifizierende Benutzer über den Browser mit Jira Service Desk interagiert. Der Connector erleichtert dies auf verschiedene Weise, wie unten beschrieben.

Benutzerdefinierte Anmeldeinformationen

Sobald Sie Ihre App erstellt haben, können Sie sich mit Benutzerdefinierten Anmeldeinformationen verbinden.

Erstellen einer benutzerdefinierten OAuth-App

Siehe Erstellen einer benutzerdefinierten OAuth-App für das Verfahren. Ihre neue App enthält die OAuthClientId Und OAuthClientSecret erforderlich, um eine Verbindung herzustellen.

Benutzerdefinierte Anmeldeinformationen

In diesem Abschnitt wird die Desktop-Authentifizierung mithilfe der Anmeldeinformationen für Ihre benutzerdefinierte OAuth-App beschrieben. Siehe Erstellen einer benutzerdefinierten OAuth-App für weitere Informationen.

Holen Sie sich ein OAuth-Zugriffstoken

Nachdem Sie Folgendes eingestellt haben, können Sie eine Verbindung herstellen:

• OAuthClientId: Stellen Sie die Client-ID in Ihren App-Einstellungen ein.
• OAuthClientSecret: Stellen Sie das Client-Geheimnis in Ihren App-Einstellungen ein.
• CallbackURL: Stellen Sie die Weiterleitungs URL in Ihren App-Einstellungen ein.
• OAuthVersion: Auf setzen 2.0.
• URL: Die URL zu Ihrem JIRA Service Desk-Endpoint; zum Beispiel https://yoursitename.atlassian.net.
• InitiateOAuth: Auf setzen GETANDREFRESH. Sie können InitiateOAuth verwenden, um die Wiederholung des OAuth-Austauschs und das manuelle Festlegen der zu vermeiden OAuthAccessToken.

Wenn Sie eine Verbindung herstellen, öffnet der Connector den OAuth-Endpoint in Ihrem Standardbrowser. Melden Sie sich an und erteilen Sie der Anwendung Berechtigungen. Der Connector führt dann den folgenden OAuth-Prozess aus:

1. Extrahiert das Zugriffstoken aus der Rückruf URL und authentifiziert Anfragen.
2. Erhält einen neuen Zugriffstoken, wenn der alte abläuft.
3. Speichert OAuth-Werte in OAuthSettingsLocation soll über Verbindungen hinweg bestehen bleiben.

Kopflose Maschinen

Um Jira Service Desk-Datenquellen auf Headless-Servern oder anderen Maschinen zu erstellen, auf denen der Connector keinen Browser öffnen kann, müssen Sie sich von einer anderen Maschine aus authentifizieren. Die Authentifizierung erfolgt in zwei Schritten.

1. Anstatt den Connector auf einem anderen Computer zu installieren, können Sie die folgenden Schritte ausführen, um den OAuthVerifier-Wert. Oder Sie können den Connector auf einem anderen Computer installieren und die OAuth-Authentifizierungswerte übertragen, nachdem Sie sich über den üblichen browserbasierten Ablauf authentifiziert haben.
2. Anschließend können Sie den Connector so konfigurieren, dass das Zugriffstoken vom Headless-Computer automatisch aktualisiert wird.

Sie können dem Headless-OAuth-Authentifizierungsablauf mit den eingebetteten OAuth-Anmeldeinformationen des Connectors oder mit den OAuth-Anmeldeinformationen für Ihre benutzerdefinierte OAuth-App folgen.

Verwenden der Anmeldeinformationen für eine benutzerdefinierte OAuth-App

Erstellen einer benutzerdefinierten OAuth-App

Siehe Erstellen einer benutzerdefinierten OAuth-App für ein Verfahren. Dieser Abschnitt beschreibt das Verfahren zur Authentifizierung und Verbindung mit Daten.

OAuth 2.0

Erhalten Sie einen Verifier-Code

Legen Sie zunächst die folgenden Eigenschaften auf der Headless-Maschine fest:

• InitiateOAuth: Auf setzen OFF.
• OAuthClientId: Auf die App-ID in Ihren App-Details einstellen.
• OAuthClientSecret: Stellen Sie das App-Geheimnis in Ihren App-Details ein.
• OAuthVersion: Auf setzen 2.0.

Authentifizieren Sie sich anschließend von einem anderen Computer aus und erhalten Sie die OAuthVerifier Verbindungseigenschaft:

1. Rufen Sie die GetOAuthAuthorizationURL auf gespeicherte Prozedur mit dem CallbackURL-Eingabeparameter, der auf die genaue Umleitungs-URI eingestellt ist, die Sie in Ihren App-Details unter angegeben haben APIS AND FEATURES -> OAuth 2.0 (3LO).
2. Öffnen Sie die zurückgegebene URL in einem Browser. Melden Sie sich an und erteilen Sie dem Connector Berechtigungen. Sie werden dann zur Callback-URL weitergeleitet, die den Prüfcode enthält.
3. Speichern Sie den Wert des Prüfcodes. Sie müssen diesen in der OAuthVerifier Verbindungseigenschaft.

Legen Sie abschließend auf der Headless-Maschine die folgenden Verbindungseigenschaften fest, um die OAuth-Authentifizierungswerte zu erhalten:

• OAuthClientId: In den Details Ihrer App auf den Consumer-Schlüssel setzen.
• OAuthClientSecret: Stellen Sie es in den Details Ihrer App auf das Verbrauchergeheimnis ein.
• OAuthVerifier: Auf den Prüfcode setzen.
• OAuthSettingsLocation: Festlegen, um die verschlüsselten OAuth-Authentifizierungswerte in der angegebenen Datei zu speichern.
• InitiateOAuth: Auf setzen REFRESH.

OAuth 1.0

Erhalten Sie einen Verifier-Code

Legen Sie zunächst die folgenden Eigenschaften auf der Headless-Maschine fest:

• InitiateOAuth: Auf setzen OFF.
• OAuthClientId: Auf die App-ID in Ihren App-Details einstellen.
• OAuthClientSecret: Stellen Sie das App-Geheimnis in Ihren App-Details ein.
• OAuthVersion: Auf setzen 1.0.
• Speichern Sie den Wert des zurückgegebenen AuthToken und AuthKey. Sie werden im nächsten Schritt verwendet.
• Öffnen Sie die zurückgegebene URL in einem Browser. Melden Sie sich an und erteilen Sie dem Connector Berechtigungen. Sie werden dann zur Rückruf-URL weitergeleitet, die den Prüfcode enthält.

Als nächstes authentifizieren Sie sich von einem anderen Rechner aus und erhalten die OAuthVerifier Verbindungseigenschaft:

1. Rufen Sie die GetOAuthAuthorizationURL auf gespeicherte Prozedur mit dem CallbackURL-Eingabeparameter, der auf die genaue Umleitungs-URI eingestellt ist, die Sie in Ihren App-Details unter angegeben haben APIS AND FEATURES -> OAuth 2.0 (3LO).
2. Öffnen Sie die zurückgegebene URL in einem Browser. Melden Sie sich an und erteilen Sie dem Connector Berechtigungen. Sie werden dann zur Callback-URL weitergeleitet, die den Prüfcode enthält.
3. Speichern Sie den Wert des Prüfcodes. Sie müssen diesen in der OAuthVerifier Verbindungseigenschaft.

Legen Sie abschließend auf der Headless-Maschine die folgenden Verbindungseigenschaften fest, um die OAuth-Authentifizierungswerte zu erhalten:

• OAuthClientId: In den Details Ihrer App auf den Consumer-Schlüssel setzen.
• OAuthClientSecret: Stellen Sie es in den Details Ihrer App auf das Verbrauchergeheimnis ein.
• OAuthVerifier: Auf den Prüfcode setzen.
• AuthToken: Setzen Sie dies auf den AuthToken.
• AuthKey: Setzen Sie dies auf den AuthKey.
• OAuthSettingsLocation: Festlegen, um die verschlüsselten OAuth-Authentifizierungswerte in der angegebenen Datei zu speichern.
• InitiateOAuth: Auf setzen REFRESH.

Mit Daten verbinden

Nachdem die OAuth-Einstellungsdatei generiert wurde, legen Sie die folgenden Eigenschaften fest, um eine Verbindung zu Daten herzustellen:

• OAuthSettingsLocation: Auf die Datei mit den verschlüsselten OAuth-Authentifizierungswerten setzen. Stellen Sie sicher, dass diese Datei dem Anbieter Lese- und Schreibberechtigungen erteilt, um die automatische Aktualisierung des Zugriffstokens zu ermöglichen.
• InitiateOAuth: Auf setzen REFRESH.
• OAuthVersion: Auf setzen 2.0.
• URL: Die URL zu Ihrem JIRA Service Desk-Endpoint; zum Beispiel https://yoursitename.atlassian.net.

OAuth-Einstellungen übertragen

Um den Connector auf einem anderen Computer zu installieren, authentifizieren Sie sich und übertragen Sie dann die resultierenden OAuth-Werte:

1. Installieren Sie den Connector auf einem zweiten Computer und stellen Sie eine Verbindung mit den folgenden Eigenschaften her:
   • OAuthSettingsLocation: Auf eine beschreibbare Textdatei einstellen.
   • InitiateOAuth: Auf setzen GETANDREFRESH.
   • OAuthClientId: Auf die Client-ID in Ihren App-Details einstellen.
   • OAuthClientSecret: Stellen Sie es in den Details Ihrer App auf das Client-Geheimnis ein.
   • CallbackURL: Legen Sie die Rückruf-URL in Ihren App-Details unter fest APIS AND FEATURES -> OAuth 2.0 (3LO).
2. Testen Sie die Verbindung zur Authentifizierung. Die resultierenden Authentifizierungswerte werden verschlüsselt in den durch angegebenen Pfad geschrieben OAuthSettingsLocation. Nachdem Sie die Verbindung erfolgreich getestet haben, kopieren Sie die OAuth-Einstellungsdatei auf Ihren Headless-Computer. Legen Sie auf dem Headless-Computer die folgenden Verbindungseigenschaften fest, um eine Verbindung zu Daten herzustellen:
   • InitiateOAuth: Auf setzen REFRESH.
   • OAuthSettingsLocation: Legen Sie den Pfad zu Ihrer OAuth-Einstellungsdatei fest. Stellen Sie sicher, dass diese Datei dem Connector Lese- und Schreibberechtigungen erteilt, um die automatische Aktualisierung des Zugriffstokens zu ermöglichen.
   • OAuthVersion: Auf setzen 2.0.
   • URL: Die URL zu Ihrem JIRA Service Desk-Endpoint; zum Beispiel https://yoursitename.atlassian.net.

Erstellen einer benutzerdefinierten OAuth-App

Wenn Sie keinen Zugriff auf den Benutzernamen und das API Token haben oder diese nicht benötigen, können Sie die OAuth-Authentifizierung verwenden. Jira Service Desk verwendet den OAuth-Authentifizierungsstandard, der erfordert, dass der authentifizierende Benutzer über den Browser mit Jira Service Desk interagiert. Der Connector erleichtert den OAuth-Austausch auf verschiedene Weise, wie in diesem Abschnitt beschrieben. Bitte beachten Sie, dass OAuth 2.0 nur für Jira Service Desk Cloud unterstützt wird.

Erstellen einer OAuth-App

So erhalten Sie die OAuth-Clientanmeldeinformationen, den Consumer-Schlüssel und das Consumer-Geheimnis:

1. Melden Sie sich bei Ihrer JIRA Service Desk Cloud-Site an.
2. Navigieren Sie zu Ihrer App-Verwaltung ( Entwickler ).
3. Wählen Sie Create new app, dann benennen Sie die App. Die App wird nun erstellt.
4. Falls sie fehlt, fügen Sie Ihrer App die OAuth 2.0-Funktionalität hinzu, indem Sie zu APIS UND FUNKTIONEN -> + Hinzufügen -> OAuth 2.0 hinzufügen (3LO) navigieren.
5. Von APIS AND FEATURES -> + Add, fügen Sie hinzu JIRA Service Desk platform REST API zu Ihrer App. Bitte beachten Sie, dass Sie auch die JIRA-App hinzufügen müssen, um alle Funktionen des Treiber zu erhalten.
6. Ab APIS AND FEATURES -> + JIRA Service Desk platform REST API, fügen Sie Ihrer App die gewünschten Bereiche hinzu.
7. Sie müssen zusätzlich Ihre Rückruf-URL einrichten. Navigieren Sie zu APIS AND FEATURES -> OAuth 2.0 (3LO). Geben Sie eine URL ein, auf die Ihre App zugreifen kann, und speichern Sie die Änderungen.

Authentifizierung beim Jira Service Desk über eine Desktop-Anwendung

Nachdem Sie die folgenden Verbindungseigenschaften festgelegt haben, können Sie eine Verbindung herstellen:

• OAuthClientId: In den Details Ihrer App auf den Consumer-Schlüssel setzen.
• OAuthClientSecret: Stellen Sie es in den Details Ihrer App auf das Verbrauchergeheimnis ein.
• CallbackURL: Legen Sie die Rückruf URL fest, die Sie in den Details Ihrer App unter finden APIS AND FEATURES -> OAuth 2.0 (3LO).
• InitiateOAuth: Auf setzen GETANDREFRESH. Sie können InitiateOAuth verwenden, um die Wiederholung des OAuth-Austauschs und das manuelle Festlegen der zu vermeiden OAuthAccessToken Verbindungseigenschaft.
• OAuthVersion: Auf setzen 2.0.
• URL: Die URL zu Ihrem JIRA Service Desk-Endpoint; zum Beispiel https://yoursitename.atlassian.net.

Wenn Sie eine Verbindung herstellen, öffnet der Connector den OAuth-Endpoint in Ihrem Standardbrowser. Melden Sie sich an und erteilen Sie der Anwendung Berechtigungen. Der Connector führt dann den folgenden OAuth-Prozess aus:

1. Ruft die Rückruf URL ab und legt den Zugriffstoken und die OAuth-Server-URL fest, um Anforderungen zu authentifizieren.
2. Speichert OAuth-Werte in OAuthSettingsLocation soll über mehrere Verbindungen hinweg bestehen bleiben.
3. Tauscht das zurückgegebene Aktualisierungstoken gegen ein neues, gültiges Zugriffstoken aus.

Authentifizierung beim Jira Service Desk über eine Webanwendung

Um das Zugriffstoken zu erhalten, legen Sie die folgenden Verbindungseigenschaften fest:

• OAuthClientId: In den Details Ihrer App auf den Consumer-Schlüssel setzen.
• OAuthClientSecret: Stellen Sie es in den Details Ihrer App auf das Verbrauchergeheimnis ein.
• CallbackURL: Legen Sie die Rückruf-URL in Ihren App-Details unter fest APIS AND FEATURES -> OAuth 2.0 (3LO).
• URL: Die URL zu Ihrem JIRA Service Desk-Endpoint; zum Beispiel https://yoursitename.atlassian.net.
• OAuthVersion: Auf setzen 2.0.

Wenn Sie eine Verbindung über eine Webanwendung herstellen oder der Connector nicht berechtigt ist, ein Browserfenster zu öffnen, müssen Sie temporäre Überprüfungswerte gegen das Zugriffstoken austauschen:

1. Rufen Sie GetOAuthAuthorizationURL auf. Die gespeicherte Prozedur gibt die URL zum OAuth-Endpoint zurück.
2. Melden Sie sich an und autorisieren Sie die Anwendung. Sie werden zurück zur Callback URL geleitet. Wenn Sie den Parameter GrantType auf setzen Implicit, die CallbackURL enthält die OAuthAccessToken und oauthserverurl in einem Abfrage. Wenn Sie den Parameter GrantType auf setzen code, die Callback URL enthält den Prüfcode im Abfrage mit dem Namen „code“. Extrahieren Sie den Prüfcode und rufen Sie GetOAuthAccessToken auf.

Um eine Verbindung zu Daten herzustellen, legen Sie die folgenden Verbindungseigenschaften fest:

• OAuthAccessToken
• OAuthVersion
• OAuthClientId
• OAuthClientSecret
• OAuthAccessToken
• URL

Optimieren des Datenzugriffs

Optimieren des Datenzugriffs

Sie können die folgenden Eigenschaften verwenden, um mehr Kontrolle über die von Jira Service Desk zurückgegebenen Daten zu erhalten:

• ServiceDeskID: Die ID des spezifischen Service Desks, mit dem Sie sich verbinden möchten.
  Standardmäßig erhalten wir die erste ID, die von einem zusätzlichen Aufruf zurückgegeben wird, um alle Service Desks abzurufen. Sie können die ServiceDeskId abrufen, indem Sie eine Select-Abfrage für die ServiceDesks-Ansicht ausführen.
• IncludeCustomFields: Ob benutzerdefinierte Felder in Abfragen an die Tabelle „Anfragen“ einbezogen werden sollen oder nicht.
• RequestLanguage: Stellen Sie dies auf eine beliebige in Jira installierte Sprache ein, um die Anzeigespaltennamen in die angegebene Sprache zu übersetzen.
  Geben Sie ein IETF BCP 47-Sprachkennzeichen wie hier beschrieben an: https://tools.ietf.org/html/bcp47.

Wichtige Hinweise

Konfigurationsdateien und ihre Pfade

• Alle Verweise auf das Hinzufügen von Konfigurationsdateien und deren Pfaden beziehen sich auf Dateien und Speicherorte auf dem Jitterbit-Agenten, auf dem der Connector installiert ist. Diese Pfade sind je nach Agent und Operationssystem entsprechend anzupassen. Wenn mehrere Agenten in einer Agentengruppe verwendet werden, werden auf jedem Agenten identische Dateien benötigt.

Erweiterte Funktionen

In diesem Abschnitt wird eine Auswahl erweiterter Funktionen des Jira Service Desk-Connectors beschrieben.

Benutzerdefinierte Ansichten

Der Connector ermöglicht Ihnen die Definition virtueller Tabellen, sogenannter benutzerdefinierter Ansichten, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese Ansichten sind nützlich, wenn Sie die an die Treiber gesendeten Abfragen nicht direkt steuern können. Siehe Benutzerdefinierte Ansichten für einen Überblick über das Erstellen und Konfigurieren benutzerdefinierter Ansichten.

SSL-Konfiguration

Verwenden Sie SSL-Konfiguration, um anzupassen, wie der Connector TLS/SSL-Zertifikatsverhandlungen handhabt. Sie können aus verschiedenen Zertifikatsformaten wählen; siehe SSLServerCert-Eigenschaft unter „Verbindungszeichenfolgenoptionen“ für weitere Informationen.

Proxy

So konfigurieren Sie den Connector mit privaten Agent-Proxy-Einstellungen, wählen Sie die Use Proxy Settings Kontrollkästchen auf dem Verbindungskonfigurationsbildschirm.

Benutzerdefinierte Ansichten

Mit dem Jitterbit Connector für Jira Service Desk können Sie eine virtuelle Tabelle definieren, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese werden als benutzerdefinierte Ansichten bezeichnet und sind in Situationen nützlich, in denen Sie die an den Treiber gesendete Abfrage nicht direkt steuern können, z. B. wenn Sie den Treiber von Jitterbit verwenden. Die benutzerdefinierten Ansichten können verwendet werden, um Prädikate zu definieren, die immer angewendet werden. Wenn Sie in der Abfrage an die Ansicht zusätzliche Prädikate angeben, werden diese mit der bereits als Teil der Ansicht definierten Abfrage kombiniert.

Es gibt zwei Möglichkeiten, benutzerdefinierte Ansichten zu erstellen:

• Erstellen Sie eine Konfigurationsdatei im JSON-Format, die die gewünschten Ansichten definiert.
• DDL-Anweisungen.

Definieren von Ansichten mithilfe einer Konfigurationsdatei

Benutzerdefinierte Ansichten werden in einer JSON-formatierten Konfigurationsdatei namens UserDefinedViews.json. Der Connector erkennt die in dieser Datei angegebenen Ansichten automatisch.

Sie können auch mehrere Ansichtsdefinitionen haben und diese mit steuern UserDefinedViews Verbindungseigenschaft. Wenn Sie diese Eigenschaft verwenden, werden vom Connector nur die angegebenen Ansichten angezeigt.

Diese Konfigurationsdatei für benutzerdefinierte Ansichten ist wie folgt formatiert:

• Jedes Stammelement definiert den Namen einer Ansicht.
• Jedes Stammelement enthält ein untergeordnetes Element namens query, das die benutzerdefinierte SQL- Abfrage für die Ansicht enthält.

Zum Beispiel:

{
    "MyView": {
        "query": "SELECT * FROM Requests WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Verwenden Sie UserDefinedViews Verbindungseigenschaft zur Angabe des Speicherorts Ihrer JSON-Konfigurationsdatei. Beispiel:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Schema für benutzerdefinierte Ansichten

Benutzerdefinierte Ansichten werden im angezeigt UserViews Schema standardmäßig. Dies geschieht, um zu vermeiden, dass der Name der Ansicht mit einer tatsächlichen Entität im Datenmodell kollidiert. Sie können den Namen des für UserViews verwendeten Schema ändern, indem Sie festlegen UserViewsSchemaName Eigentum.

Arbeiten mit benutzerdefinierten Ansichten

Beispielsweise eine SQL-Anweisung mit einer benutzerdefinierten Ansicht namens UserViews.RCustomers listet nur Kunden in Raleigh auf:

SELECT * FROM Customers WHERE City = 'Raleigh';

Ein Beispiel für eine Abfrage an den Treiber:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Daraus ergibt sich die effektive Abfrage an die Quelle:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Dies ist ein sehr einfaches Beispiel für eine Abfrage an eine benutzerdefinierte Ansicht, die tatsächlich eine Kombination aus der Abfrage und der Ansichtsdefinition ist. Es ist möglich, diese Abfragen in viel komplexeren Mustern zusammenzustellen. Alle SQL-Operationen sind in beiden Abfragen zulässig und werden bei Bedarf kombiniert.

SSL-Konfiguration

Anpassen der SSL-Konfiguration

Standardmäßig versucht der Connector, SSL/TLS auszuhandeln, indem er das Zertifikat des Servers mit dem vertrauenswürdigen Zertifikatspeicher des Systems vergleicht.

Um ein anderes Zertifikat anzugeben, siehe SSLServerCert Eigenschaft für die verfügbaren Formate, um dies zu tun.

Client-SSL-Zertifikate

Der Jira Service Desk-Connector unterstützt auch das Festlegen von Client-Zertifikaten. Legen Sie Folgendes fest, um eine Verbindung mithilfe eines Client-Zertifikats herzustellen.

• SSLClientCert: Der Name des Zertifikatspeichers für das Client-Zertifikat.
• SSLClientCertType: Der Typ des Schlüsselspeichers, der das TLS/SSL-Clientzertifikat enthält.
• SSLClientCertPassword: Das Passwort für das TLS/SSL-Client-Zertifikat.
• SSLClientCertSubject: Der Betreff des TLS/SSL-Client-Zertifikats.

Datenmodell

Überblick

Dieser Abschnitt zeigt die verfügbaren API Objekte und bietet weitere Informationen zur Ausführung von SQL für Jira Service Desk-APIs.

Hauptmerkmale

• Der Connector modelliert Jira Service Desk-Entitäten wie Dokumente, Ordner und Gruppen als relationale Ansichten, sodass Sie SQL schreiben können, um Jira Service Desk-Daten Abfrage.
• Gespeicherte Prozeduren ermöglichen die Ausführung von Vorgängen am Jira Service Desk
• Die Live-Konnektivität zu diesen Objekten bedeutet, dass alle Änderungen an Ihrem Jira Service Desk-Konto bei Verwendung des Connectors sofort berücksichtigt werden.

Tabellen

Tabellen beschreibt die verfügbaren Tabellen. Tabellen werden statisch definiert, um Jira Service Desk-Entitäten wie RequestApprovals, RequestComments und RequestParticipants zu modellieren.

Ansichten

Ansichten beschreibt die verfügbaren Ansichten. Ansichten werden statisch definiert, um Jira Service Desk-Entitäten wie Benutzer, Organisationen und ServiceDesks zu modellieren.

Gespeicherte Prozeduren

Gespeicherte Prozeduren sind funktionsähnliche Schnittstellen zu Jira Service Desk. Gespeicherte Prozeduren ermöglichen Ihnen die Ausführung von Vorgängen in Jira Service Desk, einschließlich des Herunterladens von Dokumenten und des Verschiebens von Umschlägen.

Kollaborative Abfrageverarbeitung

Der Connector verlagert die Verarbeitung der SELECT-Anweisung so weit wie möglich auf Jira Service Desk und verarbeitet den Rest der Abfrage dann im Speicher. „API Einschränkungen und-Anforderungen“ sind ebenfalls in diesem Abschnitt dokumentiert.

Sehen SupportEnhancedSQL für weitere Informationen dazu, wie der Connector API Einschränkungen durch die clientseitige In-Memory-Verarbeitung umgeht.

Tabellen

Der Connector modelliert die Daten in Jira Service Desk in einer Liste von Tabellen, die mit Standard-SQL-Anweisungen abgefragt werden können.

Im Allgemeinen ist das Abfragen von Jira Service Desk-Tabellen dasselbe wie das Abfragen einer Tabelle in einer relationalen Datenbank. Manchmal gibt es Sonderfälle, beispielsweise kann das Einfügen einer bestimmten Spalte in die WHERE-Klausel erforderlich sein, um Daten für bestimmte Spalten in der Tabelle abzurufen. Dies ist normalerweise in Situationen erforderlich, in denen für jede Zeile eine separate Abfrage erfolgen muss, um bestimmte Spalten abzurufen. Diese Arten von Situationen sind oben auf der unten verlinkten Tabellenseite klar dokumentiert.

Jitterbit-Connector für Jira Service Desk-Tabellen

Kundenübergänge

Gibt eine Liste der Übergänge zurück, die Kunden auf Anfrage durchführen können.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• RequestID unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM CustomerTransitions WHERE RequestID = '10001'

Spalten

Genehmigungen anfordern

Diese Ressource stellt eine Anfragegenehmigung dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• Id unterstützt den folgenden Operator: =.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestApprovals WHERE RequestID = '10001' AND ID = '10002'

Spalten

AnfrageKommentare

Diese Ressource stellt Anfragekommentare dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• Id, Public unterstützt den folgenden Operator: =.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestComments WHERE RequestID = '10001' AND Id = '10002'
SELECT * FROM RequestComments WHERE RequestID = '10001' AND Public = 'true'

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Teilnehmer anfordern

Diese Ressource stellt Anfrageteilnehmer dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• RequestID unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestParticipants WHERE RequestID = '10001'

Spalten

Ansichten

Ansichten bestehen aus Spalten und Pseudospalten. Ansichten ähneln Tabellen in der Art und Weise, wie Daten dargestellt werden; Ansichten unterstützen jedoch keine Aktualisierungen. Entitäten, die als Ansichten dargestellt werden, sind normalerweise schreibgeschützte Entitäten. Oft ist eine gespeicherte Prozedur verfügbar, um die Daten zu aktualisieren, wenn eine solche Funktionalität auf die Datenquelle anwendbar ist.

Abfragen können für eine Ansicht ausgeführt werden, als wäre sie eine normale Tabelle, und die zurückgegebenen Daten sind in dieser Hinsicht ähnlich. Um mehr über Tabellen und gespeicherte Prozeduren zu erfahren, navigieren Sie bitte zu den entsprechenden Einträgen in diesem Hilfedokument.

Jitterbit-Connector für Jira Service Desk-Ansichten

KundenCloud

Diese Ressource stellt einen Kunden dar.

Spalten

KnowledgeBaseArtikel

Die Artikel, die in allen Service Desks der angegebenen Abfrage entsprechen.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Organisationen

Diese Ressource stellt eine Organisation dar.

Wählen

Spalten

WarteschlangeIntern

Diese Ressource stellt einen Benutzer dar.

Spalten

AnfragenIntern

Diese Ressource stellt eine Anfrage dar.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

AnfrageSLACycles

Diese Ressource stellt die SLAs (Service Level Agreements) auf Kundenanfrage dar.

Spalten

AnforderungStatusÄnderungsprotokoll

Diese Ressource stellt die Statusübergänge für eine Kundenanfrage dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• RequestID unterstützt die = Betreiber.
• RequestKey unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestStatusChangelog WHERE RequestID = '10001'
SELECT * FROM RequestStatusChangelog WHERE RequestKey = 'TEST-1'

Spalten

Anforderungstypfelder

Die Felder für den Kundenanfragetyp eines Service Desks.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Anfragetypgruppen

Diese Ressource stellt eine Anfragetypgruppe dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• ServiceDeskId unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestTypeGroups WHERE ServiceDeskId = '1'

Spalten

Anforderungstypen

Diese Ressource stellt einen Anfragetyp dar.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• ServiceDeskId unterstützt die = Betreiber.
• ID unterstützt die = Betreiber.
• GroupIds unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM RequestTypes WHERE ServiceDeskId = '1'
SELECT * FROM RequestTypes WHERE Id = '10012'
SELECT * FROM RequestTypes WHERE GroupIds = '12'

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

ServiceDesks

Diese Ressource stellt einen Service Desk dar. Ein Service Desk basiert auf einem Projekt in der JIRA-Plattform und wird zur Verwaltung von Kundenanfragen verwendet.

Wählen

Der Connector verwendet die Jira Service Desk API, um WHERE-Klauselbedingungen zu verarbeiten, die mit den folgenden Spalten und Operatoren erstellt wurden. Der Rest des Filters wird clientseitig innerhalb des Connectors ausgeführt.

• Id unterstützt die = Operator.

Beispielsweise wird die folgende Abfrage serverseitig verarbeitet:

SELECT * FROM ServiceDesks WHERE ID = '1'

Spalten

Benutzer

Diese Ressource stellt einen Benutzer dar.

Wählen

Spalten

Gespeicherte Prozeduren

Gespeicherte Prozeduren stehen zur Ergänzung der im Datenmodell verfügbaren Daten zur Verfügung. Es kann erforderlich sein, die in einer Ansicht verfügbaren Daten mithilfe einer gespeicherten Prozedur zu aktualisieren, da die Daten keine direkten, tabellenartigen, bidirektionalen Aktualisierungen ermöglichen. In diesen Situationen erfolgt der Abruf der Daten mithilfe der entsprechenden Ansicht oder Tabelle, während die Aktualisierung durch Aufruf einer gespeicherten Prozedur erfolgt. Gespeicherte Prozeduren verwenden eine Liste von Parametern und geben einen Datensatz zurück, der die Sammlung von Tupeln enthält, die die Antwort bilden.

Jitterbit-Connector für gespeicherte Prozeduren im Jira Service Desk

Anhang hinzufügen

Erstellt einen temporären Anhang oder weist einer Anfrage einen temporären Anhang zu.

Eingang

Ergebnissatzspalten

Temporäre Datei anhängen

Diese Methode fügt einem Service Desk einen oder mehrere temporäre Anhänge hinzu, die dann mithilfe der gespeicherten Prozedur AddAttachment dauerhaft an eine Kundenanfrage angehängt werden können.

Eingang

Ergebnissatzspalten

Kunde erstellen

Erstellt einen neuen Kunden.

Eingang

Ergebnissatzspalten

Schema erstellen

Erstellt eine Schema für die angegebene Tabelle oder Ansicht.

Eingang

Ergebnissatzspalten

GetOAuthAccessToken

Holt ein Authentifizierungstoken von JIRA.

Eingang

Ergebnissatzspalten

GetOAuthAuthorizationURL

Ruft die Autorisierungs URL ab, die vom Benutzer separat geöffnet werden muss, um Zugriff auf Ihre Anwendung zu gewähren. Wird nur bei der Entwicklung von Web-Apps benötigt. Sie fordern das Authentifizierungstoken von dieser URL an.

Eingang

Ergebnissatzspalten

Aktualisieren Sie das OAuthAccessToken

Aktualisiert den OAuth-Zugriffstoken, der für die Authentifizierung bei JiraServiceDesk verwendet wird.

Eingang

Ergebnissatzspalten

Systemtabellen

Sie können die in diesem Abschnitt beschriebenen Systemtabellen Abfrage, um auf Schema, Informationen zur Datenquellenfunktionalität und Statistiken zu Operation Charge.

Schematabellen

Die folgenden Tabellen geben Datenbankmetadaten für Jira Service Desk zurück:

• sys_catalogs: Listet die verfügbaren Datenbanken auf.
• sys_schemas: Listet die verfügbaren Schemata auf.
• sys_tables: Listet die verfügbaren Tabellen und Ansichten auf.
• sys_tablecolumns: Beschreibt die Spalten der verfügbaren Tabellen und Ansichten.
• sys_procedures: Beschreibt die verfügbaren gespeicherten Prozeduren.
• sys_procedureparameters: Beschreibt Parameter gespeicherter Prozeduren.
• sys_keycolumns: Beschreibt die Primär- und Fremdschlüssel.
• sys_indexes: Beschreibt die verfügbaren Indizes.

Datenquellentabellen

Die folgenden Tabellen enthalten Informationen dazu, wie eine Verbindung zur Datenquelle hergestellt und diese Abfrage wird:

• sys_connection_props: Gibt Informationen zu den verfügbaren Verbindungseigenschaften zurück.
• sys_sqlinfo: Beschreibt die SELECT-Abfragen, die der Connector an die Datenquelle auslagern kann.

Abfrageinformationstabellen

Die folgende Tabelle gibt Abfrage für Datenänderungsabfragen zurück:

• Systemidentität: Gibt Informationen zu Charge oder einzelnen Updates zurück.

Sys_catalogs

Listet die verfügbaren Datenbanken auf.

Die folgende Abfrage ruft alle durch die Verbindungszeichenfolge ermittelten Datenbanken ab:

SELECT * FROM sys_catalogs

Spalten

Sys_schemas

Listet die verfügbaren Schemas auf.

Die folgende Abfrage ruft alle verfügbaren Schemata ab:

SELECT * FROM sys_schemas

Spalten

Sys_tables

Listet die verfügbaren Tabellen auf.

Die folgende Abfrage ruft die verfügbaren Tabellen und Ansichten ab:

SELECT * FROM sys_tables

Spalten

Sys_tablecolumns

Beschreibt die Spalten der verfügbaren Tabellen und Ansichten.

Die folgende Abfrage gibt die Spalten und Datentypen für die Tabelle „Requests“ zurück:

SELECT ColumnName, DataTypeName FROM sys_tablecolumns WHERE TableName='Requests'

Spalten

Sys_procedures

Listet die verfügbaren gespeicherten Prozeduren auf.

Die folgende Abfrage ruft die verfügbaren gespeicherten Prozeduren ab:

SELECT * FROM sys_procedures

Spalten

Sys_procedureparameters

Beschreibt Parameter gespeicherter Prozeduren.

Die folgende Abfrage gibt Informationen zu allen Eingabeparametern für die gespeicherte Prozedur SampleProcedure zurück:

SELECT * FROM sys_procedureparameters WHERE ProcedureName='SampleProcedure' AND Direction=1 OR Direction=2

Spalten

Sys_keycolumns

Beschreibt die Primär- und Fremdschlüssel.

Die folgende Abfrage ruft den Primärschlüssel für die Tabelle „Requests“ ab:

SELECT * FROM sys_keycolumns WHERE IsKey='True' AND TableName='Requests'

Spalten

Sys_foreignkeys

Beschreibt die Fremdschlüssel.

Die folgende Abfrage ruft alle Fremdschlüssel ab, die auf andere Tabellen verweisen:

SELECT * FROM sys_foreignkeys WHERE ForeignKeyType = 'FOREIGNKEY_TYPE_IMPORT'

Spalten

Sys_indexes

Beschreibt die verfügbaren Indizes. Durch das Filtern nach Indizes können Sie selektivere Abfragen mit schnelleren Abfrage schreiben.

Die folgende Abfrage ruft alle Indizes ab, die keine Primärschlüssel sind:

SELECT * FROM sys_indexes WHERE IsPrimary='false'

Spalten

Sys_connection_props

Gibt Informationen zu den verfügbaren Verbindungseigenschaften und den in der Verbindungszeichenfolge festgelegten Eigenschaften zurück.

Bei der Abfrage dieser Tabelle sollte die Konfigurationsverbindungszeichenfolge verwendet werden:

jdbc:cdata:jiraservicedesk:config:

Mit dieser Verbindungszeichenfolge können Sie diese Tabelle ohne eine gültige Verbindung Abfrage.

Die folgende Abfrage ruft alle Verbindungseigenschaften ab, die in der Verbindungszeichenfolge festgelegt oder über einen Standardwert gesetzt wurden:

SELECT * FROM sys_connection_props WHERE Value <> ''

Spalten

Sys_sqlinfo

Beschreibt die SELECT- Abfrage, die der Connector an die Datenquelle auslagern kann.

Gemeinsame Abfrageverarbeitung

Wenn Sie mit Datenquellen arbeiten, die SQL-92 nicht unterstützen, können Sie die Ansicht sys_sqlinfo Abfrage, um die Abfrage der zugrunde liegenden APIs in SQL-Syntax zu ermitteln. Der Connector verlagert so viel wie möglich von der Verarbeitung der SELECT-Anweisung auf den Server und verarbeitet den Rest der Abfrage dann im Speicher.

Entdecken der SELECT-Funktionen der Datenquelle

Nachfolgend sehen Sie einen Beispieldatensatz mit SQL-Funktionen. Der folgende Ergebnissatz zeigt die SELECT-Funktionalität an, die der Connector auf die Datenquelle oder die Prozessclientseite auslagern kann. Ihre Datenquelle unterstützt möglicherweise zusätzliche SQL-Syntax. Einige Aspekte der SELECT-Funktionalität werden in einer durch Kommas getrennten Liste zurückgegeben, sofern sie unterstützt werden; andernfalls enthält die Spalte NO.

Die folgende Abfrage ruft die Operatoren ab, die in der WHERE-Klausel verwendet werden können:

SELECT * FROM sys_sqlinfo WHERE Name='SUPPORTED_OPERATORS'

Beachten Sie, dass einzelne Tabellen unterschiedliche Einschränkungen oder Anforderungen an die WHERE-Klausel haben können; siehe Datenmodell Abschnitt für weitere Informationen.

Spalten

Systemidentität

Gibt Informationen zu versuchten Änderungen zurück.

Die folgende Abfrage ruft die IDs der geänderten Zeilen in einer Operation Charge:

SELECT * FROM sys_identity

Spalten

Erweiterte Konfigurationseigenschaften

Die erweiterten Konfigurationseigenschaften sind die verschiedenen Optionen, die zum Herstellen einer Verbindung verwendet werden können. Dieser Abschnitt enthält eine vollständige Liste der Optionen, die Sie konfigurieren können. Klicken Sie auf die Links, um weitere Einzelheiten zu erfahren.

Authentifizierung

SSO

OAuth

SSL

Schema

Verschiedenes

Authentifizierung

Dieser Abschnitt enthält eine vollständige Liste der Authentifizierungseigenschaften, die Sie konfigurieren können.

AuthScheme

Der Authentifizierungstyp, der bei der Verbindung mit Jira Service Desk verwendet werden soll.

Mögliche Werte

Auto, OAuth, Basic, Crowd

Datentyp

string

Standardwert

Auto

Hinweise

• Automatisch: Lässt den Treiber automatisch basierend auf den anderen von Ihnen festgelegten Verbindungseigenschaften entscheiden.
• OAuth: Legen Sie diese Option fest, um eine OAuth-Authentifizierung durchzuführen.
• Basic: Legen Sie dies fest, um die BASIC-Authentifizierung mit Benutzer/Passwort oder Benutzer/ApiToken zu verwenden.
• Crowd: Legen Sie dies fest, um eine Crowd-SSO-Authentifizierung durchzuführen.

URL

Die URL zu Ihrem JIRA Service Desk-Endpoint.

Datentyp

string

Standardwert

""

Hinweise

Die URL zu Ihrem JIRA Service Desk Endpoint, zum Beispiel https://yoursitename.atlassian.net.

Benutzer

Das zur Authentifizierung verwendete Jira Service Desk-Benutzerkonto.

Datentyp

string

Standardwert

""

Hinweise

Zusammen mit Passwort, wird dieses Feld zur Authentifizierung gegenüber dem Jira Service Desk-Server verwendet.

Passwort

Das zur Authentifizierung des Benutzers verwendete Passwort.

Datentyp

string

Standardwert

""

Hinweise

Der Benutzer Und Password werden zusammen zur Authentifizierung beim Server verwendet.

APIToken

APIToken des aktuell authentifizierten Benutzers.

Datentyp

string

Standardwert

""

Hinweise

APIToken des aktuell authentifizierten Benutzers. Sie können einen API Token unter diesem Link abrufen: https://id.atlassian.com/manage/api-tokens

SSO

Dieser Abschnitt enthält eine vollständige Liste der SSO-Eigenschaften, die Sie konfigurieren können.

SSOLoginURL

Die Anmelde-URL des Identitätsanbieters.

Datentyp

string

Standardwert

""

Hinweise

Die Anmelde-URL des Identitätsanbieters.

SSO-Eigenschaften

Zusätzliche Eigenschaften, die für die Verbindung mit dem Identitätsanbieter erforderlich sind, in einer durch Semikolon getrennten Liste.

Datentyp

string

Standardwert

""

Hinweise

Zusätzliche Eigenschaften, die für die Verbindung mit dem Identitätsanbieter erforderlich sind, in einer durch Semikolon getrennten Liste. wird in Verbindung mit der SSOLoginURL verwendet.

Die SSO-Konfiguration wird weiter unten erläutert.

SSOExchangeUrl

Die URL, die zum Verwenden der SAML -Antwort und zum Austauschen mit Jira Service Desk-spezifischen Anmeldeinformationen verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Der Jitterbit-Connector für Jira Service Desk verwendet die hier angegebene URL, um eine SAML -Antwort zu verarbeiten und Jira Service Desk-spezifische Anmeldeinformationen abzurufen. Die abgerufenen Anmeldeinformationen sind das letzte Element während der SSO-Verbindung, das zur Kommunikation mit Jira Service Desk verwendet wird.

SSOAppName

App-Name, der mit SSO für IdPs verwendet wird, die dies erfordern.

Datentyp

string

Standardwert

""

Hinweise

Zusammen mit SSOAppPassword, kann zur Identifizierung und Authentifizierung gegenüber Ihrer im SSO-IdP konfigurierten App angegeben werden. Derzeit wird dies nur von Crowd unterstützt.

SSOAppPassword

App-Passwort, das mit SSO für IdPs verwendet wird, die es benötigen.

Datentyp

string

Standardwert

""

Hinweise

Zusammen mit SSOAppName, kann zur Identifizierung und Authentifizierung gegenüber Ihrer im SSO-IdP konfigurierten App angegeben werden. Derzeit wird dies nur von Crowd unterstützt.

OAuth

Dieser Abschnitt enthält eine vollständige Liste der OAuth-Eigenschaften, die Sie konfigurieren können.

OAuth initiieren

Legen Sie diese Eigenschaft fest, um den Prozess zum Abrufen oder Aktualisieren des OAuth-Zugriffstokens beim Herstellen einer Verbindung zu starten.

Mögliche Werte

OFF, GETANDREFRESH, REFRESH

Datentyp

string

Standardwert

OFF

Hinweise

Folgende Optionen stehen zur Verfügung:

1. OFF: Gibt an, dass der OAuth-Flow vollständig vom Benutzer gehandhabt wird. Zur Authentifizierung ist ein OAuthAccessToken erforderlich.
2. GETANDREFRESH: Gibt an, dass der gesamte OAuth-Flow vom Connector verarbeitet wird. Wenn derzeit kein Token vorhanden ist, wird es durch eine entsprechende Aufforderung an den Benutzer über den Browser abgerufen. Wenn ein Token vorhanden ist, wird es bei Bedarf aktualisiert.
3. REFRESH: Gibt an, dass der Connector nur das Aktualisieren des OAuthAccessToken übernimmt. Der Benutzer wird vom Connector nie aufgefordert, sich über den Browser zu authentifizieren. Der Benutzer muss zunächst das Abrufen des OAuthAccessToken und des OAuthRefreshToken übernehmen.

OAuthVersion

Die verwendete OAuth-Version.

Mögliche Werte

1.0, 2.0

Datentyp

string

Standardwert

1.0

Hinweise

Die verwendete OAuth-Version. Folgende Optionen sind verfügbar: 1.0,2.0

OAuthClientId

Die Client-ID, die zugewiesen wird, wenn Sie Ihre Anwendung bei einem OAuth-Autorisierungsserver registrieren.

Datentyp

string

Standardwert

""

Hinweise

Im Rahmen der Registrierung einer OAuth-Anwendung erhalten Sie die OAuthClientId-Wert, manchmal auch Consumer-Schlüssel genannt, und ein Client-Geheimnis, das OAuthClientSecret.

OAuthClientSecret

Das Client-Geheimnis, das zugewiesen wird, wenn Sie Ihre Anwendung bei einem OAuth-Autorisierungsserver registrieren.

Datentyp

string

Standardwert

""

Hinweise

Im Rahmen der Registrierung einer OAuth-Anwendung erhalten Sie die OAuthClientId, auch Consumer-Schlüssel genannt. Sie erhalten außerdem ein Client-Geheimnis, auch Consumer-Geheimnis genannt. Legen Sie das Client-Geheimnis im OAuthClientSecret Eigentum.

OAuth-Zugriffstoken

Der Zugriffstoken für die Verbindung per OAuth.

Datentyp

string

Standardwert

""

Hinweise

Der OAuthAccessToken Eigenschaft wird für die Verbindung über OAuth verwendet. Die OAuthAccessToken wird im Rahmen des Authentifizierungsprozesses vom OAuth-Server abgerufen. Es hat ein serverabhängiges Timeout und kann zwischen Anfragen wiederverwendet werden.

Das Zugriffstoken wird anstelle Ihres Benutzernamens und Passworts verwendet. Das Zugriffstoken schützt Ihre Anmeldeinformationen, indem es sie auf dem Server speichert.

OAuthSettingsLocation

Der Speicherort der Einstellungsdatei, in der OAuth-Werte gespeichert werden, wenn InitiateOAuth auf GETANDREFRESH oder REFRESH eingestellt ist. Alternativ können Sie diesen Speicherort im Speicher halten, indem Sie einen Wert angeben, der mit beginnt 'memory://'.

Datentyp

string

Standardwert

%APPDATA%\CData\Acumatica Data Provider\OAuthSettings.txt

Hinweise

Wenn InitiateOAuth ist auf gesetzt GETANDREFRESH oder REFRESH, der Treiber speichert OAuth-Werte, damit der Benutzer die OAuth-Verbindungseigenschaften nicht manuell eingeben muss und die Anmeldeinformationen über Verbindungen oder Prozesse hinweg gemeinsam genutzt werden können.

Anstatt einen Dateipfad anzugeben, können Sie auch den Speicherort angeben. Speicherorte werden durch einen Wert angegeben, der mit 'memory://' gefolgt von einer eindeutigen Kennung für diesen Satz von Anmeldeinformationen (z. B. memory://user1). Die Kennung können Sie frei wählen, sie sollte jedoch für den Benutzer eindeutig sein. Im Gegensatz zur dateibasierten Speicherung, bei der die Anmeldeinformationen über Verbindungen hinweg bestehen bleiben, werden die Anmeldeinformationen bei der Speicherspeicherung in den statischen Speicher geladen und die Anmeldeinformationen werden für die Dauer des Prozesses unter Verwendung derselben Kennung zwischen Verbindungen geteilt. Um die Anmeldeinformationen außerhalb des aktuellen Prozesses beizubehalten, müssen Sie die Anmeldeinformationen vor dem Schließen der Verbindung manuell speichern. Auf diese Weise können Sie sie in der Verbindung festlegen, wenn der Prozess erneut gestartet wird. Sie können OAuth-Eigenschaftswerte mit einer Abfrage an abrufen sys_connection_propsSystemtabelle. Wenn mehrere Verbindungen mit denselben Anmeldeinformationen bestehen, werden die Eigenschaften aus der zuvor geschlossenen Verbindung gelesen.

Der Standardspeicherort ist „%APPDATA%\CData\ Acumatica Data Provider\OAuthSettings.txt“ mit %APPDATA% auf das Konfigurationsverzeichnis des Benutzers gesetzt. Die Standardwerte sind

• Windows: "register://%DSN"
• Unix: "%AppData%..."

wobei DSN der Name des aktuellen DSN ist, der in der offenen Verbindung verwendet wird.

Die folgende Tabelle listet den Wert von auf %APPDATA% nach Operationssystem:

Umfang

Dadurch werden die Bereiche bestimmt, die die OAuth-Anwendung vom Jira Service Desk anfordert.

Datentyp

string

Standardwert

""

Hinweise

Geben Sie den Bereich an, um den ersten Zugriff und das Aktualisierungstoken zu erhalten.

Standardmäßig fordert der Connector den Benutzer auf, alle verfügbaren Bereiche zu autorisieren. Wenn Sie dies überschreiben möchten, können Sie diese Eigenschaft auf eine durch Leerzeichen getrennte Liste von OAuth-Bereichen setzen.

CloudId

Die Cloud-ID für die autorisierte Atlassian-Site.

Datentyp

string

Standardwert

""

Hinweise

Dies wird während der OAuth 2.0-Authentifizierung automatisch ermittelt und vom GetOAuthAccessToken zurückgegeben gespeicherte Prozedur. Legen Sie keinen Wert für CloudId fest, wenn Sie InitiateOAuth verwenden.

OAuthVerifier

Der von der OAuth-Autorisierungs URL zurückgegebene Prüfcode.

Datentyp

string

Standardwert

""

Hinweise

Der von der OAuth-Autorisierungs URL zurückgegebene Prüfcode. Dieser kann auf Systemen verwendet werden, auf denen kein Browser gestartet werden kann, z. B. auf Headless-Systemen.

Authentifizierung auf Headless-Maschinen

Siehe, um die zu erhalten OAuthVerifier Wert.

OAuthSettingsLocation festlegen zusammen mit OAuthVerifier. Beim Verbinden tauscht der Connector die OAuthVerifier für die OAuth-Authentifizierungstoken und speichert sie verschlüsselt in der angegebenen Datei. Setzen Sie InitiateOAuth, um den Austausch mit GETANDREFRESH zu automatisieren.

Sobald die OAuth-Einstellungsdatei generiert wurde, können Sie entfernen OAuthVerifier aus den Verbindungseigenschaften und verbinden Sie sich mit OAuthSettingsLocation festgelegt.

Um die OAuth-Tokenwerte automatisch zu aktualisieren, legen Sie OAuthSettingsLocation fest und setzen Sie zusätzlich InitiateOAuth zum AKTUALISIEREN.

AuthToken

Das Authentifizierungstoken, das zum Anfordern und Abrufen des OAuth-Zugriffstokens verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Diese Eigenschaft ist nur erforderlich, wenn eine Headless-Authentifizierung in OAuth 1.0 durchgeführt wird. Sie kann aus der gespeicherten Prozedur GetOAuthAuthorizationUrl abgerufen werden.

Sie kann zusammen mit dem AuthKey bereitgestellt werden in der gespeicherten Prozedur GetOAuthAccessToken, um den OAuthAccessToken abzurufen.

Authentisierungsschlüssel

Das Authentifizierungsgeheimnis, das zum Anfordern und Abrufen des OAuth-Zugriffstokens verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Diese Eigenschaft ist nur erforderlich, wenn eine Headless-Authentifizierung in OAuth 1.0 durchgeführt wird. Sie kann aus der gespeicherten Prozedur GetOAuthAuthorizationUrl abgerufen werden.

Sie kann zusammen mit dem AuthToken bereitgestellt werden in der gespeicherten Prozedur GetOAuthAccessToken, um den OAuthAccessToken abzurufen.

OAuthRefreshToken

Das OAuth-Aktualisierungstoken für das entsprechende OAuth-Zugriffstoken.

Datentyp

string

Standardwert

""

Hinweise

Der OAuthRefreshToken Eigenschaft wird verwendet, um den OAuthAccessToken zu aktualisieren bei Verwendung der OAuth-Authentifizierung.

OAuthLäuftAbIn

Die Lebensdauer des OAuth AccessToken in Sekunden.

Datentyp

string

Standardwert

""

Hinweise

Mit OAuthTokenTimestamp kombinieren, um zu bestimmen, wann der AccessToken abläuft.

OAuthTokenTimestamp

Der Unix-Epochenzeitstempel in Millisekunden, als das aktuelle Zugriffstoken erstellt wurde.

Datentyp

string

Standardwert

""

Hinweise

Kombinieren Sie es mit OAuthExpiresIn, um zu bestimmen, wann das AccessToken abläuft.

Zertifikatspeichertyp

Der Typ des Zertifikatspeichers, der mit der privaten Anwendungsauthentifizierung von Jira Service Desk verwendet wird.

Mögliche Werte

USER, MACHINE, PFXFILE, PFXBLOB, JKSFILE, JKSBLOB, PEMKEY_FILE, PUBLIC_KEY_FILE, PUBLIC_KEY_BLOB, SSHPUBLIC_KEY_BLOB, P10BFILE, SSHPUBLIC_KEY_FILE, PPKFILE, XMLFILE, XMLBLOB

Datentyp

string

Standardwert

USER

Hinweise

Der Name des Zertifikatspeichers für das Client-Zertifikat, das bei der privaten Anwendungsauthentifizierung von Jira Service Desk verwendet wird. Die private Anwendungsauthentifizierung von Jira Service Desk verwendet eine SSL-Client-Authentifizierung mit digitalen Zertifikaten.

Angeben des Zertifikatspeichertyps

Der CertificateStoreType Eigenschaft kann einen der folgenden Werte annehmen:

Zugehörige Verbindungseigenschaften

Um das private Zertifikat anzugeben, müssen Sie möglicherweise zusätzlich zu die folgenden Eigenschaften festlegen CertificateStoreType:

• Zertifikatsspeicher: Legen Sie hier den Namen des Zertifikatspeichers fest. Beispielsweise „MY“ für einen Windows Zertifikatspeicher oder den Dateinamen eines Dateispeichers.
• Zertifikatspeicherkennwort: Wenn der Store passwortgeschützt ist, geben Sie hier das Passwort ein.
• CertificateSubject: Legen Sie dies auf den Betreff des Zertifikats fest. Um das Zertifikat im Speicher zu finden, führt der Connector eine Suche basierend auf dem angegebenen Betreff durch. Weitere Informationen finden Sie unter CertificateSubject-Feld für Details.

Zertifikatsspeicher

Der Zertifikatsspeicher, der für die JIRA Service Desk-Authentifizierung verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Der Speicherort des Zertifikatspeichers für das Client-Zertifikat, das bei der Jira Service Desk-Anwendungsauthentifizierung verwendet wird.

CertificateStorePassword

Das Kennwort des Zertifikatspeichers, der mit der Jira Service Desk-Authentifizierung verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Wenn der Zertifikatspeicher von einem Typ ist, der ein Passwort erfordert, wird diese Eigenschaft verwendet, um dieses Passwort anzugeben, damit der Zertifikatspeicher geöffnet werden kann.

Zertifikatsthema

Der Betreff des Zertifikats, das mit der privaten Jira Service Desk-Anwendungsauthentifizierung verwendet wird.

Datentyp

string

Standardwert

""

Hinweise

Der Betreff des Client-Zertifikats, das bei der privaten Anwendungsauthentifizierung von Jira Service Desk verwendet wird.

Informationen zum SSL-Authentifizierungsablauf für den Jira Service Desk-Client

Die private Anwendungsauthentifizierung von Jira Service Desk verwendet eine SSL-Client-Authentifizierung mit digitalen Zertifikaten.

Laden eines Zertifikats

Beim Laden eines Zertifikats wird das Betreff verwendet, um das Zertifikat im Speicher zu finden.

• Wenn keine genaue Übereinstimmung gefunden wird, wird der Speicher nach Betreffs durchsucht, die den Wert der Eigenschaft enthalten.
• Wenn immer noch keine Übereinstimmung gefunden wird, wird kein Zertifikat ausgewählt.
• Der spezielle Wert „*“ wählt das erste Zertifikat im Zertifikatspeicher aus.

Angeben des Betreffs

Der Zertifikatsbetreff ist eine durch Kommas getrennte Liste von Distinguished Name-Feldern und-Werten. Zum Beispiel „CN=www.server.com, OU=test, C=US, E=example@jbexample.com“. Allgemeine Felder und ihre Bedeutungen werden unten angezeigt.

Hinweis: Wenn ein Feldwert ein Komma enthält, muss es in Anführungszeichen gesetzt werden.

Zusätzliche Verbindungseigenschaften

Um das private Zertifikat anzugeben, müssen Sie festlegen CertificateSubject und die folgenden zusätzlichen Eigenschaften:

• CertificateStore
• Zertifikatsspeichertyp
• Zertifikatsspeicherkennwort

SSL

Dieser Abschnitt enthält eine vollständige Liste der SSL-Eigenschaften, die Sie konfigurieren können.

SSLClientCert

Der TLS/SSL-Client-Zertifikatspeicher für die SSL-Client-Authentifizierung (bidirektionales SSL).

Datentyp

string

Standardwert

""

Hinweise

Der Name des Zertifikatspeichers für das Client-Zertifikat.

Der SSLClientCertType Feld gibt den Typ des durch angegebenen Zertifikatspeichers an SSLClientCert. Wenn der Store kennwortgeschützt ist, geben Sie das Kennwort in SSLClientCertPassword an.

SSLClientCert wird in Verbindung mit SSLClientCertSubject verwendet, um Client-Zertifikate anzugeben. Wenn SSLClientCert hat einen Wert und SSLClientCertSubject gesetzt ist, wird eine Suche nach einem Zertifikat eingeleitet. Siehe SSLClientCertSubject für weitere Informationen.

Die Bezeichnungen der Zertifikatsspeicher sind plattformabhängig.

Nachfolgend sind die Bezeichnungen der gebräuchlichsten Benutzer- und Maschinen-Zertifikatspeicher in Windows aufgeführt:

In Java ist der Zertifikatsspeicher normalerweise eine Datei, die Zertifikate und optionale private Schlüssel enthält.

Wenn der Zertifikatsspeichertyp PFXFile ist, muss diese Eigenschaft auf den Namen der Datei gesetzt werden. Wenn der Typ PFXBlob ist, muss die Eigenschaft auf den binären Inhalt einer PFX-Datei gesetzt werden (z. B. PKCS12-Zertifikatsspeicher).

SSLClientCertType

Der Typ des Schlüsselspeichers, der das TLS/SSL-Clientzertifikat enthält.

Mögliche Werte

USER, MACHINE, PFXFILE, PFXBLOB, JKSFILE, JKSBLOB, PEMKEY_FILE, PEMKEY_BLOB, PUBLIC_KEY_FILE, PUBLIC_KEY_BLOB, SSHPUBLIC_KEY_FILE, SSHPUBLIC_KEY_BLOB, P7BFILE, PPKFILE, XMLFILE, XMLBLOB

Datentyp

string

Standardwert

USER

Hinweise

Diese Eigenschaft kann einen der folgenden Werte annehmen:

SSLClientCertPassword

Das Passwort für das TLS/SSL-Client-Zertifikat.

Datentyp

string

Standardwert

""

Hinweise

Wenn der Zertifikatspeicher von einem Typ ist, der ein Passwort erfordert, wird diese Eigenschaft verwendet, um dieses Passwort zum Öffnen des Zertifikatspeichers anzugeben.

SSLClientCertSubject

Der Betreff des TLS/SSL-Client-Zertifikats.

Datentyp

string

Standardwert

*

Hinweise

Beim Laden eines Zertifikats wird der Betreff verwendet, um das Zertifikat im Speicher zu lokalisieren.

Wenn keine genaue Übereinstimmung gefunden wird, wird der Speicher nach Betreffs durchsucht, die den Wert der Eigenschaft enthalten. Wenn immer noch keine Übereinstimmung gefunden wird, wird die Eigenschaft auf eine leere Zeichenfolge gesetzt und kein Zertifikat ausgewählt.

Der spezielle Wert „*“ wählt das erste Zertifikat im Zertifikatspeicher aus.

Der Betreff des Zertifikats ist eine durch Kommas getrennte Liste von Distinguished Name-Feldern und-Werten. Beispiel: „CN=www.server.com, OU=test, C=US, E=support@company.com“. Die allgemeinen Felder und ihre Bedeutungen werden unten angezeigt.

Wenn ein Feldwert ein Komma enthält, muss es in Anführungszeichen gesetzt werden.

SSLServerCert

Das vom Server zu akzeptierende Zertifikat bei einer Verbindung über TLS/SSL.

Datentyp

string

Standardwert

""

Hinweise

Bei Verwendung einer TLS/SSL-Verbindung kann diese Eigenschaft verwendet werden, um das vom Server zu akzeptierende TLS/SSL-Zertifikat anzugeben. Jedes andere Zertifikat, dem der Computer nicht vertraut, wird abgelehnt.

Diese Eigenschaft kann folgende Formen annehmen:

Wenn nicht angegeben, wird jedes vom Computer vertrauenswürdige Zertifikat akzeptiert.

Zertifikate werden vom Computer basierend auf dem Trust Store des Systems als vertrauenswürdig validiert. Der verwendete Trust Store ist der für das System angegebene Wert „javax.net.ssl.trustStore“. Wenn für diese Eigenschaft kein Wert angegeben ist, wird der Standard-Trust Store von Java verwendet (z. B. JAVA_HOME\lib\security\cacerts).

Verwenden Sie „*“, um anzugeben, dass alle Zertifikate akzeptiert werden. Beachten Sie, dass dies aus Sicherheitsgründen nicht empfohlen wird.

Schema

Dieser Abschnitt enthält eine vollständige Liste der Schema, die Sie konfigurieren können.

Standort

Ein Pfad zum Verzeichnis, das die Schema enthält, die Tabellen, Ansichten und gespeicherte Prozeduren definieren.

Datentyp

string

Standardwert

%APPDATA%\JiraServiceDesk Data Provider\Schema

Hinweise

Der Pfad zu einem Verzeichnis, das die Schema für den Connector enthält (.rsd-Dateien für Tabellen und Ansichten, .rsb-Dateien für gespeicherte Prozeduren). Der Ordnerspeicherort kann ein relativer Pfad vom Speicherort der ausführbaren Datei sein. Der Location Eigenschaft wird nur benötigt, wenn Sie Definitionen anpassen möchten (z. B. einen Spaltennamen ändern, eine Spalte ignorieren usw.) oder das Datenmodell mit neuen Tabellen, Ansichten oder gespeicherten Prozeduren erweitern möchten.

Wenn nicht angegeben, ist der Standardspeicherort „%APPDATA%\JiraServiceDesk Data Provider\Schema“ mit %APPDATA% wird auf das Konfigurationsverzeichnis des Benutzers eingestellt:

DurchsuchbareSchemas

Diese Eigenschaft beschränkt die gemeldeten Schemata auf eine Teilmenge der verfügbaren Schemata. Beispiel: BrowsableSchemas=SchemaA,SchemaB,SchemaC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Schemata aus Datenbanken kann aufwändig sein. Die Bereitstellung einer Liste von Schemata in der Verbindungszeichenfolge verbessert die Leistung.

Tabellen

Diese Eigenschaft beschränkt die gemeldeten Tabellen auf eine Teilmenge der verfügbaren Tabellen. Beispiel: Tabellen=TabelleA,TabelleB,TabelleC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Tabellen aus einigen Datenbanken kann teuer sein. Die Bereitstellung einer Liste von Tabellen in der Verbindungszeichenfolge verbessert die Leistung des Connectors.

Diese Eigenschaft kann auch als Alternative zum automatischen Auflisten von Ansichten verwendet werden, wenn Sie bereits wissen, mit welchen Sie arbeiten möchten, und es sonst zu viele wären.

Geben Sie die gewünschten Tabellen in einer durch Kommas getrennten Liste an. Jede Tabelle sollte ein gültiger SQL-Bezeichner sein, wobei alle Sonderzeichen mit eckigen Klammern, Anführungszeichen oder Backticks maskiert werden. Beispiel: Tables=TableA,[TableB/WithSlash],WithCatalog.WithSchema.`TableC With Space`.

Beachten Sie, dass Sie beim Herstellen einer Verbindung zu einer Datenquelle mit mehreren Schemata oder Katalogen den vollqualifizierten Namen der Tabelle in dieser Eigenschaft angeben müssen, wie im letzten Beispiel hier, um Mehrdeutigkeiten zwischen Tabellen zu vermeiden, die in mehreren Katalogen oder Schemata vorhanden sind.

Ansichten

Beschränkt die gemeldeten Ansichten auf eine Teilmenge der verfügbaren Tabellen. Beispiel: Ansichten=AnsichtA,AnsichtB,AnsichtC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Ansichten aus einigen Datenbanken kann teuer sein. Die Bereitstellung einer Liste von Ansichten in der Verbindungszeichenfolge verbessert die Leistung des Connectors.

Diese Eigenschaft kann auch als Alternative zum automatischen Auflisten von Ansichten verwendet werden, wenn Sie bereits wissen, mit welchen Sie arbeiten möchten, und es sonst zu viele wären.

Geben Sie die gewünschten Ansichten in einer durch Kommas getrennten Liste an. Jede Ansicht sollte ein gültiger SQL-Bezeichner sein, wobei alle Sonderzeichen mit eckigen Klammern, Anführungszeichen oder Backticks maskiert werden. Beispiel: Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space`.

Beachten Sie, dass Sie beim Herstellen einer Verbindung zu einer Datenquelle mit mehreren Schemata oder Katalogen den vollqualifizierten Namen der Tabelle in dieser Eigenschaft angeben müssen, wie im letzten Beispiel hier, um Mehrdeutigkeiten zwischen Tabellen zu vermeiden, die in mehreren Katalogen oder Schemata vorhanden sind.

Verschiedenes

Dieser Abschnitt enthält eine vollständige Liste verschiedener Eigenschaften, die Sie konfigurieren können.

Benutzerdefinierte Felder einschließen

Ein Boolescher Wert, der angibt, ob Sie benutzerdefinierte Felder in die Spaltenliste aufnehmen möchten.

Datentyp

bool

Standardwert

false

Hinweise

Wenn Sie dies auf „true“ setzen, werden benutzerdefinierte Felder in die Spaltenliste aufgenommen. Um die benutzerdefinierten Felder aufzunehmen, müssen wir für jedes benutzerdefinierte Feld eine individuelle Anfrage stellen, was zu Leistungseinbußen beim Auflisten von Metadaten führen kann.

MaxRows

Begrenzt die Anzahl der zurückgegebenen Zeilen, wenn in der Abfrage keine Aggregation oder Gruppierung verwendet wird. Dadurch werden Leistungsprobleme zur Entwurfszeit vermieden.

Datentyp

int

Standardwert

-1

Hinweise

Begrenzt die Anzahl der zurückgegebenen Zeilen, wenn in der Abfrage keine Aggregation oder Gruppierung verwendet wird. Dadurch werden Leistungsprobleme zur Entwurfszeit vermieden.

Andere

Diese versteckten Eigenschaften werden nur in bestimmten Anwendungsfällen verwendet.

Datentyp

string

Standardwert

""

Hinweise

Die unten aufgeführten Eigenschaften sind für bestimmte Anwendungsfälle verfügbar. Für normale Anwendungsfälle und Funktionen von Treiber sollten diese Eigenschaften nicht erforderlich sein.

Geben Sie mehrere Eigenschaften in einer durch Semikolon getrennten Liste an.

Integration und Formatierung

Pseudospalten

Diese Eigenschaft gibt an, ob Pseudospalten als Spalten in die Tabelle aufgenommen werden sollen oder nicht.

Datentyp

string

Standardwert

""

Hinweise

Diese Einstellung ist besonders hilfreich im Entity Framework, da Sie dort keinen Wert für eine Pseudospalte festlegen können, es sei denn, es handelt sich um eine Tabellenspalte. Der Wert dieser Verbindungseinstellung hat das Format „Tabelle1=Spalte1, Tabelle1=Spalte2, Tabelle2=Spalte3“. Sie können das Zeichen „*“ verwenden, um alle Tabellen und alle Spalten einzuschließen, z. B. „*=*“.

AnfrageSprache

Verwenden Sie requestLanguage, um Spaltennamen in eine bestimmte Sprache übersetzen zu lassen.

Datentyp

string

Standardwert

""

Hinweise

Verwenden Sie requestLanguage, um Spaltennamen in eine bestimmte Sprache übersetzen zu lassen. Standardmäßig werden Spaltennamen basierend auf der Spracheinstellung des anfordernden Benutzers oder der Standardsprache der Jira Site (bei anonymen Benutzern) übersetzt. Die verfügbaren Sprachen basieren auf den in Jira installierten Sprachen. Geben Sie ein IETF BCP 47-Sprachtag an, wie unter diesem Link beschrieben: https://tools.ietf.org/html/bcp47.

ServiceDeskID

Service Desk-ID des aktuell authentifizierten Benutzers.

Datentyp

string

Standardwert

""

Hinweise

Service Desk-ID des aktuell authentifizierten Benutzers. Standardmäßig erhalten wir die erste ID, die von einem zusätzlichen Aufruf zurückgegeben wird, um alle Service Desks abzurufen. Sie können die ServiceDeskId abrufen, indem Sie eine Select Abfrage für die ServiceDesks-Ansicht ausführen.

Zeitüberschreitung

Der Wert in Sekunden, bis der Timeout-Fehler auftritt und der Operation abgebrochen wird.

Datentyp

int

Standardwert

60

Hinweise

Wenn Timeout = 0, Operationen werden nicht abgebrochen. Die Operationen werden ausgeführt, bis sie erfolgreich abgeschlossen sind oder bis ein Fehler auftritt.

Wenn Timeout abläuft und der Operation noch nicht abgeschlossen ist, löst der Connector eine Ausnahme aus.