Deploy Duet Enterprise in production infra landscape

Duet Enterprise PoC in sandbox environments

Organizations that evaluate Duet Enterprise for the added value it brings typically do so via a proof of concept. Mostly, these PoC’s are executed in an isolated sandbox, a laboratory environment. Naturally also in the sandbox all the minimal prerequisites must be present in order to rightfully test the effect and operation of the SAP-SharePoint interoperability. Thus (an element of) SAP Business Suite, a server hosting SAP NetWeaver Gateway 2.0 with the Duet Enterprise SAP Add-On installed, and a server hosting SharePoint 2010 with the Duet Enterprise SharePoint Add-On installed. But for cost reasons, the sandbox infra is typical less extensive as in the regular production environment. Thus no load-balancer, SharePoint 2010 farm in the single-server setup, no proxy server, no firewall, et cetera. Infrastructure elements that are regurlarly present in nowadays mature infra architectures.

Note: to facilitate organizations that quickly want to inspect and evaluate Duet Enterprise, without spending effort in installing it within own landscape; the Duet Enterprise team has prepared a fully installed Microsoft Hyper-V image: SAP NetWeaver Duet Enterprise Trial System.

Deploy Duet Enterprise in production landscape

At a client organization we also started with a Duet Enterprise PoC, in a sandbox environment. On basis of the succesful outcome, Enterprise Architecture has mandaded the application of Duet Enterprise as the organization standard interoperability approach when it concerns SAP-SharePoint business scenarios. Next logical, and a required step, is to make Duet Enterprise available for generic utilization in the regular IT landscape. Via the Duet Enterprise wizard a lot of the Duet Enterprise deployment effort on SAP side is automated, largely transparent to the specifics of the SAP landscape. For SharePoint side, there is no wizard. But the installation effort there is far less as on the SAP side.

Duet Enterprise deploy differences sandbox versus production landscape

During deployment of Duet Enterprise in the production landscape, we experienced a number of effects resulting from differences in the production versus sandbox landscapes.

SAP side

• Starting from NetWeaver 7.31, the consumer proxies for Duet Enterprise workflow are configured via transaction SOAMANAGER. The proxies configuration in LPCONFIG, although still present and possible, no longer has effect.
• For design-time, the ESR Builder must be associated with the Software Component Version and namespace in the Gateway system where custom development will reside. It is not feasible in production landscape to create Gateway DataModel and business scenarios as Local Objects.

SharePoint side

• At the external boundary from end-user to SharePoint, the infrastructure contains a Load Balancer with SSL-offloading to the internal network. Duet Enterprise however requires SSL enabled on the SharePoint 2010 server that is in direct connection with the SAP NetWeaver Gateway server, hosting the Duet Enterprise SAP Add-on. And the SSL certificate of the SharePoint server must be imported within SAML2 transaction of SAP Gateway system.
• For shared resource usage, and for security, the SharePoint infra is partitioned over 2 separate SharePoint farms: a SharePoint Service Applications farm with also a Central Admin webapplication; and a consuming SharePoint farm that hosts all the end-user SharePoint webapplications. Also SharePoint BCS Service Application is thus on the Service Applications farm. As BCS is the SharePoint consuming side in Duet Enterprise architecture, it seems logical to exchange the Security Token Service (STS) certificate of this farm to Gateway; to configure the SAML based Duet Enterprise Single Sign-On behaviour (see Execution flow of Duet Enterprise Single Sign-On). However, when we configured the Duet Enterprise landscape with the STS certificate of the Service Applications farm, the Single Sign-On derivation at Duet Enterprise connection time failed. In SRT_UTIL the infamous error message ”SSFW_KRN_VERIFY failed with: verification failed, see decrypted digest” was logged. Further analysis of the logged information in SRT_UTIL displayed that the REMOTE_ADDRESS in the runtime SAML connection is that of the consuming farm. After consultation with SAP Support we tried to use the STS certificate of this farm instead. And indeed this resolved the invalid certificate signature issue. The explanation for this behaviour is that the end-user that starts the Duet Enterprise request flow is authenticated within the consuming farm; thus also the secure token identifying the user must be taken from this farm.

Filter on current datetime in BCS::ReadList upon Search Crawling

SharePoint Business Connectivity Services plus SharePoint Enterprise Search and/or SharePoint FAST is a powerful combination. With them you can unlock selective data from external repositories and bring into SharePoint context to realize search-driven applications. The external data is retrieved at Search Crawl time, and administrated in the search index file.

The SharePoint Indexing Engine first invokes the Finder method of the external content type(s) that is tagged as ‘RootFinder’ in the BDC Metadata Model. And second per returned entity the SpecificFinder to retrieve more details. If all required entity details are already returned by the Finder method, the latter can be skipped for better crawl performance and throughput.

Via the Finder method thus the set of relevant entities of external content type is retrieved. The decision what is relevant is made from perspective of the external repository upon the moment of invoking the Finder/ReadList method. A typical filter here is that of current datetime: only return active external entities.

Current datetime is a dynamic value to be determined at Finder invocation time. A consequence is that this filter value cannot be a priori included in the BDC model. This leaves 3 options: derive and specify the dynamic value from either the context of the BCS::Finder consumer, from within the BCS::Finder provider as integration layer, or from the data access operation (web service, ADO.NET or custom connector) within the external repository.

BCS::Finder consumer context

In content crawling context the SharePoint Indexing Engine is the consumer. It is not possible the augment its the standard behaviour of invoking the Finder method.

BCS::Finder provider context

This option requires that the Finder execution invoke the associated access point of the external repository with DateTime.Now as filter parameter. This option is not supported for BCS no-code solutions, but requires the utilization of a custom BCS .Net Assembly Connector. If already a custom .Net Connector is used for retrieving data from the external repository, it is probably a minor change to extend it with this dynamic derived filter value. But if not, introducing the usage of a dedicated BCS .Net connector merely to filter on the current DateTime is somewhat of an overweighted solution approach.

DataAccess operation within external repository context

So that leaves as only option to apply the current datetime filter value within the interoperability point of the external repository. For example in Duet Enterprise scenarios to unlock SAP data to SharePoint: The invoked Query operation of the Gateway webservice must then self apply the system datetime. SAP NetWeaver supports this via the concept of default value for input parameters.
Sadly it is not possible to specify this at the level of the Gateway Data Model, so it must be specified in the invoked ABAP Function Module (RFC).

Note: avoid specifying application-specific default value in the RFC. Systemtime satisfies this guideline, but a concrete default value for DateTime input parameter typically does not.

See also MSDN forum thread on this subject: Invoke BCS::ReadList operation with 'today' as default value for datetime input parameter.