If errors occur during a SharePoint request, Intrexx will attempt to ascertain the error message from the service's response and then display it in the browser. This isn't possible in every single case. You can therefore activate request tracing in the Intrexx Portal Server for a detailed error analysis.
1.1.2. Request tracing and error logging
When request tracing is activated, both the HTTP requests and the responses will be written in detail in the Intrexx portal log file. For requests, the entry consists of the HTTP action, the URL, the query options, the request headers and the XML body. For responses, the HTTP header and the response XML will be delivered.
For SSL connections between the Intrexx portal server and a SharePoint server, the certificate from the certificate authority, that issued the service certificate, must be added to the Certificate Store of the Intrexx portal server.
Self-signed certificates, which weren't issued by a known certificate authority, are an exception. To enable SSL connections to services with self-signed certificates, the examining of the certificate chain needs to be deactivated in the Intrexx server in this case. This is possible on the service level by using a system property.
<systemProperty name = "de.uplanet.lucy.server.odata.consumer.ssl.allowSelfSignedCerts.<SERVICE_GUID>" value="true"/>
The placeholder <SERVICE_GUID> needs to be replaced by the GUID of the OData service. The GUID can be retrieved from the service configuration file in the portal directory internal/cfg/odata.
After saving the "portal.cfg" file, the Intrexx portal service must be restarted so that the changes take effect.
2.1. Intrexx Kerberos Token Provider
The Intrexx Kerberos Token Provider is a Web service which an Intrexx Portal server can use to request Kerberos tokens for Single Sign On authentication for portal users with external systems. This service is especially needed if it's necessary to access an external system multiple times while a user enquiry is being processed; every access, however, requires a Kerberos ticket for authentication. Per Web request, only one ticket for each external system is available to the portal server. The portal server can use this to log in to the Intrexx Kerberos Token Provider in the context of a portal user and will then receive multiple tokens for processing each request for the external system.
2.1.2. System requirements
The Integrated Windows Authentication must be activated for the Intrexx portal and the Connector for SharePoint, as is described in capital 2.1.4.
This feature is supported by Windows Server version 2008 and upwards. The Internet Information Server and .NET 4.5 must be installed on the Intrexx server.
2.1.3. Installation and configuration
The Web application for the Kerberos Token Service is located as a ZIP file "ixkrbtokenservice.zip " in the portal directory /adapter/odata/kerberos. Unpack the files to a folder of your choice on the server e.g. "C:\inetpub\wwwroot\ixkrbtokenservice". Now create a new Web application in IIS with the following settings:
Select an application pool which supports .NET Framework Version 4.0.
Subsequently, you need to open the "Authentication" overview for the application. Deactivate all methods apart from "Windows Authentication". "Negotiate" must be set as the provider and Kernel-mode authentication also needs to be activated.
The service can now be tested in the browser. To achieve this, open the URL "http://localhost/ixkrbservice/api/Token" in the browser. Additionally, the query parameter "spn" can be used to directly provide the Service Principal Name of the SharePoint server to test the ticket request. A message like the one below should appear in the browser:
Depending on the browser, the result can either appear as an XML or JSON document. The number of tickets to be created can be setup in the "web.config" file in the service directory with the parameter "maxTokenCount. " As a default, 5 tickets are generated per request.
2.2. SharePoint requests in Groovy scripts
Currently, there isn't a published Intrexx Groovy API for accessing SharePoint in Groovy scripts. It is however possible to enable the internal Intrexx SharePoint API for Groovy. Be that as it may, it isn't guaranteed that this will be compatible with future versions of Intrexx and should therefore only be implemented after discussing it with your United Planet customer consultant.
To activate access to the internal classes, edit the file scripting.cfg
in the portal directory internal/cfg/scripting
and add the following lines:
The portal service needs to be restarted afterwards. The classes from the packages executed above can now be imported into Groovy. As an example, the SharePoint full-text search will be performed using Groovy below. It is also possible to generate and perform OData or HTTP requests directly.
// SharePoint configuration
def l_cfg = ODataConsumerRegistry.getInstance().getConsumerConfiguration('4F9C5FCE6D0160451C336C4E8FDC9C6E7362B00D') //l_cfgGuid
// SharePoint service class
def l_sharePointService = SharePointService.getInstance()
// Search in SharePoint (Result is a JSON String)
def l_result = l_sharePointService.search(l_cfg,
// OData Consumer Client for OData Requests:
def l_strDgGuid = '...' // DG GUID of the SharePoint data group
def l_strUserGuid = '...' // Intrexx User GUID with static SP login
def l_odataConsumer = l_sharePointService.getConsumer(l_strDgGuid, l_strUserGuid)
//Jersey Client for direct HTTP requests within the user context
def l_httpClient = ODataConsumerFactory.INSTANCE.createJerseyClient(l_cfg, '86BDB920D3B8A7E8AA20F42F3F3459DE1E0EDCF3', //serviceGuid
2.3. Dynamic access to multiple SharePoint sites
Usually, individual service URIs are specified in the SharePoint service configuration for each SharePoint site that is connected to. Only one service definition can be accessed per data group. If it's required that lists/libraries are accessed in different sites, then an individual data group needs to be created for each site/list/library. This can simplified if the same lists/libraries can be accessed in different sites. This is under the condition that the lists and fields involved have the exact same labels in every site. If this is the case, a placeholder variable can be defined in the service URI, this is replaced with the site name by Intrexx in runtime. It should be noted however that only one site can be addressed per Intrexx session.
A service URI with a placeholder could look something like this: