Wenn während eines SharePoint-Requests Fehler auftreten, versucht Intrexx die Fehlermeldungen
aus der Antwort des Services zu ermitteln und im Browser anzuzeigen. Dies ist nicht immer in allen Fällen möglich.
Für eine detailliertere Fehleranalyse bietet es sich deshalb an, das Request-Tracing im Intrexx-Portal-Sserver zu aktivieren.
1.1.2. Request-Tracing und Fehlerprotokollierung
Bei aktiviertem Request-Tracing werden sowohl die HTTP-Requests als auch Responses im Detail
in die Intrexx-Portal-Logdatei geschrieben. Für Requests besteht ein Eintrag aus der HTTP-Aktion,
der URL, den Query-Options, den Request-Headern und dem XML-Body. Bei Antworten werden die
HTTP-Header und der Response-XML-Body ausgegeben. Aktiviert wird das Tracing wie folgt:
Für SSL-Verbindungen zwischen dem Intrexx-Portalserver und einem SharePoint-Server muss das
Zertifikat der Certificate-Authority, die das Service-Zertifikat ausgestellt hat, dem
Zertifikatsspeicher des Intrexx-Portalservers hinzugefügt worden sein. Eine Ausnahme bilden selbstsignierte Zertifikate,
die nicht von einer bekannten Certificate-Authority ausgestellt wurden. Um SSL-Verbindungen zu
Diensten mit selbstsignierten Zertifikaten zu ermöglichen, muss in diesem Fall im Intrexx-Server
die Prüfung der Certificate-Chain deaktiviert werden. Dies ist auf Service-Ebene über eine System-Property möglich.
Öffnen Sie die Datei portal.cfg im Portalverzeichnis internal/cfg
mit einem Texteditor und fügen Sie dem Abschnitt <environment> einen neuen <systemProperty>-Eintrag hinzu:
<systemProperty name = "de.uplanet.lucy.server.odata.consumer.ssl.allowSelfSignedCerts.<SERVICE_GUID>" value="true"/>
Der Platzhalter <SERVICE_GUID> ist mit der GUID des OData-Services zu ersetzen.
Die GUID können Sie der Service-Konfigurationsdatei im Portalverzeichnis internal/cfg/odata entnehmen.
Nach dem Speichern der portal.cfg-Datei muss der Intrexx-Portalserver-Dienst neu gestartet werden, damit die Änderungen wirksam werden.
2. Anhang
2.1. Intrexx-Kerberos-Token-Provider
2.1.1. Allgemeines
Der Intrexx-Kerberos-Token-Provider ist ein Webservice, der ein Intrexx-Portal-Server-Kerberos-Token zur
Single-Sign-On-Authentifizierung der Portalbenutzer mit externen Systemen anfordern kann.
Dieser Dienst wird vor allem dann benötigt, wenn während der Verarbeitung einer Benutzeranfrage
im Portal-Server mehrere Zugriffe auf ein externes System benötigt werden, wobei jeder einzelne
Zugriff ein Kerberos-Ticket zur Authentifizierung benötigt. Dem Portal-Server selbst steht pro Web-Request
nur ein Ticket pro externem System zur Verfügung. Mit diesem kann sich der Portal-Server am Intrexx-Kerberos-Token-Provider
im Kontext des Portalbenutzers anmelden und erhält dann für das externe System mehrere Tokens für die Verarbeitung der jeweiligen Requests.
2.1.2. Systemvoraussetzungen
Die Integrierte Windows-Authentifizierung
muss für das Intrexx-Portal und den Connector für Microsoft SharePoint aktiviert sein.
Außerdem wird Microsoft Windows Server ab Version 2008 unterstützt. Auf dem Intrexx-Portal-Server müssen der
Internet Information Server und .Net 4.5 installiert sein.
2.1.3. Installation und Konfiguration
Die Webanwendung für den Kerberos Token Service befindet sich als ZIP-Datei ixkrbtokenservice.zip im
Portalverzeichnis adapter/odata/kerberos.
Entpacken Sie die Dateien in einem beliebigen Verzeichnis auf dem Server, z.B. in c:/inetpub/wwwroot/ixkrbtokenservice.
Erstellen Sie nun eine neue Web-Anwendung im IIS mit folgenden Einstellungen:
Wählen Sie dabei als Anwendungspool einen Pool aus, der die .NET Framework Version 4.0 unterstützt.
Anschließend muss die Ansicht "Authentifizierung" für die Anwendung geöffnet werden.
Deaktivieren Sie dort alle Methoden bis auf "Windows-Authentifizierung". Als Provider muss
"Negotiate" eingestellt werden und die Kernel-Mode Authentication muss ebenfalls aktiviert sein.
Nun kann der Service im Browser getestet werden. Rufen Sie dazu im Browser die URL
http://localhost/ixkrbservice/api/Token auf. Zusätzlich kann über den Query-Parameter "spn" direkt der
Service-Prinicpal-Name des Microsoft SharePoint-Servers angegeben werden, um die Ticket-Anforderung
für diesen zu testen. Es sollte im Browser eine Meldung wie unten erscheinen:
Je nach Browser kann die Darstellung des Ergebnisses als XML- oder JSON-Dokument erfolgen.
Die Anzahl der zu erzeugenden Tickets kann in der web.config-Datei im Service-Verzeichnis
über den Parameter maxTokenCount eingestellt werden. Standardmäßig werden pro Anfrage 5 Tickets erstellt.
2.2. SharePoint-Abfragen in Groovy-Skripten
Derzeit gibt es noch keine öffentliche Intrexx-Groovy-API für den Zugriff auf Microsoft SharePoint
in Groovy-Skripten. Es ist allerdings möglich, die interne Intrexx-SharePoint-API für Groovy freizuschalten.
Diese garantiert allerdings nicht Kompatibiltät zu zukünftigen Intrexx-Versionen und sollte daher nur nach
Absprache mit Ihrem United Planet Kundenberater verwendet werden. Um den Zugriff auf die internen Klassen
zu aktivieren, editieren Sie die Datei scripting.cfg im Portalverzeichnis internal/cfg/scripting
und tragen die untenstehende Zeilen ein:
Anschließend muss der Portal-Server-Dienst neu gestartet werden. Die Klassen aus den oben
aufgeführten Packages können nun in Groovy importiert werden. Im Folgenden wird beispielhaft die
Microsoft SharePoint-Volltextsuche aus Groovy ausgeführt. Es ist auch möglich, direkte OData- oder
HTTP-Requests zu erzeugen und auszuführen.
import de.uplanet.lucy.server.odata.consumer.cfg.ODataConsumerRegistry
import de.uplanet.lucy.server.odata.consumer.jersey.*
import de.uplanet.lucy.server.odata.consumer.sharepoint
import org.odata4j.core.*
// SharePoint Konfiguration
def l_cfg = ODataConsumerRegistry.getInstance().getConsumerConfiguration('4F9C5FCE6D0160451C336C4E8FDC9C6E7362B00D') //l_cfgGuid
// SharePoint Service Klasse
def l_sharePointService = SharePointService.getInstance()
// Suche in SharePoint (Ergebnis ist ein JSON String)
def l_result = l_sharePointService.search(l_cfg,
'86BDB920D3B8A7E8AA20F42F3F3459DE1E0EDCF3', //serviceGuid,
'7312F993D0DA4CECCA9AE5A9D865BE142DE413EA', //userGuid
'Suchausdruck')
// OData Consumer Client für OData Requests:
def l_strDgGuid = '...' // DG Guid der SharePoint Datengruppe
def l_strUserGuid = '...' // Intrexx User GUID mit statischem SP Login
def l_odataConsumer = l_sharePointService.getConsumer(l_strDgGuid, l_strUserGuid)
//Jersey Client für direkte HTTP Aufrufe im User Kontext
def l_httpClient = ODataConsumerFactory.INSTANCE.createJerseyClient(l_cfg, '86BDB920D3B8A7E8AA20F42F3F3459DE1E0EDCF3', //serviceGuid
'7312F993D0DA4CECCA9AE5A9D865BE142DE413EA') //userGuid
2.3. Dynamischer Zugriff auf mehrere SharePoint-Sites
Üblicherweise werden für jede anzubindende SharePoint-Site eigene Service-URIs
in der SharePoint-Dienste-Konfiguration erfasst. Pro Datengruppe kann aber nur auf eine
Service-Definition zugegriffen werden. Soll auf Listen/Bibliotheken in unterschiedliche
Sites zugegriffen werden, so muss für jede Site/Liste/Bibliothek eine eigene Datengruppe
erstellt werden. Dies kann vereinfacht werden, wenn auf die gleichen Listen/Bibliotheken in
unterschiedlichen Sites zugegriffen werden soll. Voraussetzung dafür ist, dass die betroffenen Listen und
Felder in allen Sites genau die gleichen Bezeichnungen haben. Ist dies der Fall, kann in der Service-URI
eine Platzhalter-Variable definiert werden, die zur Laufzeit von Intrexx mit dem Site-Name ersetzt wird.
Dabei ist zu beachten, dass pro Intrexx-Session nur eine Site angesprochen werden kann.
Eine Service-URI mit Platzhalter kann wie folgt aussehen: