Tip: run 'New-SPODataConnectionSetting' as administrator

SharePoint 2013 Business Connectivity Service application also includes support for consumption of external REST OData services. The connectivity requires a ODataConnection. This can be created via the new PowerShell CmdLet New-SPODataConnectionSetting.

If you invoke this CmdLet under an 'ordinary' SharePoint account, you may encounter the error: The Web application at <ServiceContext URI> could not be found. Verify that you have typed the URL correctly. Typical cause is that the SharePoint account has insufficient rights to access the Central Admin web application. The simple resolution is then to run PowerShell via "Run as administrator".

Duet Enterprise 2.0 - installation troubleshooting

Initial, the installation of the first version (1.0) of Duet Enterprise was cumbersome and labour-intensive, and therefore also error prone. With the Duet Enterprise 1.0 installation wizard at SAP side, the installation already was substantially improved. And this has progressed on to the installation of the new version, Duet Enterprise 2.0. However, as the landscape is inherent complex (minimal one, but typically more SAP backends, a SAP Gateway system, and SharePoint 2013 farm), you still may face issues.

In this blog I describe some of the issues that I encountered during Duet Enterprise 2.0 installations, and share my resolutions.

Issue 1: ‘Add-on IW_DUETE Release 100 can only be installed in client 000’

Import of the Duet Enterprise 2.0 SAP Add-On via transaction SAINT gives the following error:

Resolution: Use client 000 to import the add-on via transaction SAINT.

Issue 2: ‘The remote certificate is invalid according to the validation procedure’.

This error can occur in multiple SharePoint-SAP scenarios: runtime invocation of Duet Enterprise service from SharePoint 2013 side, import of a Duet Enterprise 2.0 BDC Model: Application definition import failed. The following error occurred: The remote certificate is invalid according to the validation procedure.

Resolution: Typical the above error message is caused by mismatch of the SSL certificate used on SAP Gateway side to encrypt the traffic, versus the SAP SSL certificate that has been imported in SharePoint 2013 ‘Manage trust’. To repair, import the SSL certificate again. You can either ask again the SAP BASIS administrator to export from SAP Gateway STRUST. But a more convenient, and in my experiences also one with better results (was already so for Duet Enterprise 1.0) is to open on SharePoint web frontend the SAP service url, and then from SSL certificate warning export the SAP SSL certificate to file; and next add this to ‘Manage trust’.

Issue 3: ‘The root certificate that was just selected is invalid’

Importing in SharePoint 2013 ‘Manage Trust’ the SSL certificate of SAP NetWeaver Gateway results in error:

Resolution: import the SSL certificate via Internet Explorer (11) instead of Firefox.

Issue 4: ‘No service found for namespace /IWWRK/, name DUET_WORKFLOW_CORE

Manifest itself upon configuration of Duet Enterprise 2.0 Workflow solution.

Resolution: Add and activate the Duet Enterprise 2.0 Gateway REST service in MAINT_SERVICE.

Issue 5: DuetConfig: ‘The operation name is missing or invalid’

For instance occurs with the DuetConfig command to configure workflow, command with multiple operation parameters: DuetConfig.exe -importbdc -FeatureName Workflow -LsiUrl "https://tnvsrm.tnv.corp/sap/opu/odata/IWWRK/DUET_WORKFLOW_CORE;mo;c=SHAREPOINT_DE/" -BdcServiceApplication "Business Data Connectivity Service" -UserSubLsiUrl "https://tnvsrm.tnv.corp/sap/opu/odata/IWBEP/SUBSCRIPTIONMANAGEMENT; mo;v=2;c=SHAREPOINT_DE/"

Resolution: careful check the command line that the start character for each of the operation parameter names is indeed the minus (‘-‘) character. In case you copied the command line from the deployment guide, this may be ‘invisible’ the wrong character. To be sure, in the command line explicit (replace and) type the ‘-‘ character:

Issue 6: ‘Lobsystem (External System) returned authentication error'

For instance, occurs upon trying to import a Duet Enterprise 2.0 BDC Model into SharePoint 2013 Business Connectivity Services application:

Resolution 1: Check that the Duet Enterprise 2.0 generated ‘Duet Root Certificate Authority’ is added to SSL Server Standard in STRUST on the SAP Gateway system.

Resolution 2: Check the user mapping of the SharePoint account used to invoke the SAP Gateway service / import the Duet Enterprise 2.0 BDC Model. In particular check the extid that it contains the correct pattern (account name, comma + space, and then the domain name in small capitals):

Issue 7: Import of Duet Enterprise 1.0 BDC Model fails due missing ‘WSDL’ application definition.

Resolution: Add an “Duet Enterprise 1.0 WSDL” application definition in SharePoint 2013 Secure Store.

Issue 8: Invocation of Duet Enterprise 1.0 service fails due missing SSO

Browsing a SharePoint 2013 External List results in error ‘An unsecured or incorrectly secured fault was received from the other party’.

Inspect the SRT_UTIL ErrorLog:

Resolution: Besides the Duet Enterprise 2.0 SSO approach based on X.509 certificate, also enable Duet Enterprise 1.0 SAML2 approach. Use the Duet Enterprise 1.0 Deployment Guide for information how to enable SAML2 in the Duet Enterprise 2.0 (Gateway 2.0 + SharePoint 2013) landscape.

Epilogue

Compared to the excellent troubleshooting guide for Duet Enterprise 1.0, the above list of issues plus resolutions is much smaller. The Duet Enterprise product team of SAP plus Microsoft has clearly improved their delivery on this aspect.

Others that have been deploying Duet Enterprise 2.0 may have encountered other issues as I did so far. Still a general classification of all issues seen so far is that they are caused by manual error, indirect caused by the sometimes unclear, fragmented and even incorrect Duet Enterprise deployment guides.

Winner of SAP Microsoft Unite Partner Connection Customer Impact and Value Award with VIEW solution

I am very proud that The Next View has won the 2014 edition of the SAP Microsoft Unite Partner Connection Award for Customer Impact and Value with our VIEW solution!!

VIEW stands for Virtual Integrated Enterprise Workplace. For us, the VIEW concept is not new, I for instance already defined and published on this blog parts of the Conceptual Solution Architecture back in 2009. But it is only up to now with the advent of the modern integration technologies SAP NetWeaver Gateway, Duet Enterprise, Gateway for Microsoft (GWM), plus the availability of standard functional products from our partner Cordis Solutions, that we are enabled to actually realize the VIEW concept in a cost-effective manner.

So, what does VIEW stand for? VIEW is a new operating concept in which the central concept is that of an employee-centric mindset. In VIEW, we strive to optimally enable organization’s employees to perform their daily work-related activities. In current reality, this work execution often means that one must operate in (and switch to) multiple applications and systems, monitor multiple tasklists in different environments (SAP, SharePoint, Oracle, Outlook, ...), remember login credentials of the diverse systems. With VIEW, we relieve the employees from all this ‘IT landscape’ hashle. Instead that the employees must explicit go to all the different applications, in VIEW we collect all the work execution in a central place: the VIEW landing page.

And this VIEW landing page has multiple appearances: desktop and mobile, to fit in with the nowadays reality that employees are [willing to be] always connected to the business systems, to at minimum monitor and act on urgent matters.

Although the VIEW concept does not mandates this, the typical platform for the desktop appearance is SharePoint; as this is in majority of the organizations the declared [by Information Management, Enterprise Architecture] business webplatform. The VIEW landing page is merely added as new employee business application within the already present SharePoint-based intranet.

Also for the mobile appearance, SharePoint can be the platform [certainly SharePoint 2013 has made some big steps on enabling us to provide a proper mobile appearance, a.o. taking into account the diversity in mobile devices]. But the mobile landing page can also be hosted outside SharePoint, e.g. via SAP Mobile Platform [SMP], an hybrid App [HTML5/CSS/PhoneGap], and other alternatives. Again, the VIEW concept does not put strict restrictions on this.

If you want to learn more about the VIEW solution, check out the SAP Microsoft Unite Partner Collection solution brief.

GWPAM renamed into SAP Gateway for Microsoft, short GWM

‘SAP NetWeaver Gateway Productivity Accelerator voor Microsoft’, that is a mouthful. This long name arose in several variations of how the product is actually being called in the market and press, resulting in confusion and making it difficult to find product information. SAP product management has acknowledged this drawback effect, and they now have a more catchy product name assigned: SAP Gateway for Microsoft, abbreviated as GWM.

Other GWM news besides this name change is the availability of GWM Service Pack 02. Key parts of SP2 are alignment with Visual Studio 2012 [modern UI] look and feel, support for Microsoft Office 2013, support of SAP Fiori services consumption, and a project template for building your own Excel Add-In. Earlier versions of GWM already include the capability to link an Excel sheet to a Gateway REST/OData service for (mass) data management. This feature is aimed for business people who arrange their own (master)data management via Excel. The new Excel Add-in template is designed specifically for the developer, to build your own innovative solutions with Excel UI platform.

See also: SAP CodeTalk: GWPAM Update / Interview with Holger Bruchelt

Corrupt SharePoint account breaks Duet Enterprise workflow publishing

One of our Duet Enterprise customers where I had a.o. configured the workflow capability, requested my support as workflow tasks where no longer published from SAP workflow backend into SharePoint. I performed cause analysis in the combined SAP + SharePoint landscape, starting with inspecting the logs – SAP backend, SAP Gateway and SharePoint systems. The SAP Gateway log contained a recurring error log “logical port not found for routing url”.

I checked in SIMGH on the Gateway system, and found a valid routing url that referred to ‘LOGICALPORTFORWORKFLOW’; and in SOAMANAGER an active logical port with this name. But when I tried to ping the /IWTNG/CO_TASKFLOW_WEB_SERVICE consumer proxy, http error 405 was returned. The actual cause of the malfunctioning Workflow publishing from Gateway into SharePoint was the SharePoint service account that Gateway uses to authenticate against the Duet Enterprise webservice '/_vti_bin/OBAWorkflowService.asmx' on the SharePoint server. It had somehow become corrupted, and lacked the authorization to access the WSDL document of the Duet Enterprise service. After recreating/resetting the new service, account workflow publishing is working fine again.

Note: the logged message ‘No logical port found’ can be misleading; in the ABAP code it is the generic catch of whatever problem is encountered upon trying to propagate SAP task notifications from SAP Gateway to SharePoint.

HowTo send JSON data from WCF service with special characters

The manner to return special characters within the JSON response of a (SharePoint-based) WCF REST service, consists of 3 essential elements:

1. Define the method response as System.IO.Stream;
2. Set the charset of the JSON response to 'ISO-8859-1';
3. Apply UniCode encoding to the JSON response string.

Code example

 [ServiceContract(Namespace = "...")]
 public interface IRESTService
 {
    [WebInvoke(Method = "GET", 
     UriTemplate = "/RESTMethod?$parameter1={parameter1}&...",
     RequestFormat = WebMessageFormat.Json,
     ResponseFormat = WebMessageFormat.Json,
     BodyStyle = WebMessageBodyStyle.Bare)]
    System.IO.Stream RESTMethod(string parameter1, ...);
}

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class RESTService : IRESTService
{
   public Stream RESTMethod(string parameter1, …)
   {
       OutgoingWebResponseContext context = 
          WebOperationContext.Current.OutgoingResponse;
       context.ContentType = "application/json; charset=ISO-8859-1";
  
       string jsonData = ...;
       return new MemoryStream(UnicodeEncoding.Default.GetBytes(jsonData));
   }
}

Service Application Proxies runtime reported with locale-dependent TypeName

The SharePoint architecture enables shared usage of service applications across farms. A typical setup is a Shared Services farm that hosts the service applications, and multiple consumer / front-end farms that host the webapplications. In the consumer farm(s), each individual webapplication is associated with the service applications it requires. For instance, webapplication A is associated with Secure Store and Business Connectivity Services, and webapplication B is associated with Secure Store and Secure Token service applications.

In a distributed SharePoint architecture you cannot programmatically access the service applications in the local farm. Instead you must access via the service application proxy that is associated with the webapplication. The retrieval model of this is weakly-typed, you retrieve the desired service application proxy by string-comparision (!) on the proxy TypeName. This weakly-typed usage model is errorprone; you can easily make a typo error that goes unnoticed at compile time. But you will be immediately aware upon the first runtime test of the code.

However, this weakly-typed model incorporates another strange behavior: the reported TypeName is locale dependent! In my local SharePoint image, I tested against an EN-US sitecollection to retrieve the BCS service proxy, filtering on TypeName:

BdcServiceApplicationProxy proxy =
    webApplication.ServiceApplicationProxyGroup.Proxies.SingleOrDefault(
       p => p.TypeName == 
            "Business Data Connectivity Service Application Proxy" 
    ) as BdcServiceApplicationProxy;
 

With above code, I successfully retrieve the BCS service application proxy.

But the same code running against a webapplication in the integration-test farm does not select the BCS service application proxy. In Central Admin I verified that the webapplication is associated with the BCS service application. So what is the problem here? The cause rather surprised me: the sitecollection in the integration-test environment is provisioned via a Dutch-locale site definition. And as unexpected side-effect the TypeName of the associated service application proxies are now all reported in their Dutch localization name:

Fix for the above code is to make it locale-independent. For BCS this is possible by filtering on TypeName pattern ‘Business Connectivity Service’;

BdcServiceApplicationProxy proxy =
     webApplication.ServiceApplicationProxyGroup.Proxies.SingleOrDefault(
          p => p.TypeName.Contains("Business Data Connectivity")
     ) as BdcServiceApplicationProxy;
 

For other service application proxies it might be required to compare the TypeName against the established Resources value:

private static string _BCSApplicationProxyTypeName = null;

// Derived from Microsoft.SharePoint.CoreResource
static string BCSApplicationProxyTypeName
{
   get
   {
      if (String.IsNullOrEmpty(_BCSApplicationProxyTypeName))
      {
        Assembly _aIntl = Assembly.Load("Microsoft.SharePoint.intl, 
          Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
        ResourceManager _BusinessDataRM = 
          new ResourceManager("Microsoft.BusinessData.strings", _aIntl);
        _BCSApplicationProxyTypeName = _BusinessDataRM.GetString(       
          "ApplicationRegistry_BdcServiceApplicationProxy_TypeName");
      }

      return _BCSApplicationProxyTypeName;
   }
}


BdcServiceApplicationProxy proxy =
     webApplication.ServiceApplicationProxyGroup.Proxies.SingleOrDefault(
          p => p.TypeName == BCSUtility.BCSApplicationProxyTypeName
     ) as BdcServiceApplicationProxy;