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 is not possible in every single case. You can therefore activate
request tracing in the Intrexx
Portal Server for a detailed
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
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 is 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
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 is not 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 is not guaranteed
that this will be compatible with future versions of Intrexx and should
therefore only be implemented after discussing it with your United Planet
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 is 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: