Problem Creating ECT’s in SharePoint Designer with SAP NetWeaver Gateway

[former_member186439]

I’m basically following the instructions from this MSDN article: http://msdn.microsoft.com/en-us/library/ff963722(v=office.14).aspx (How To: Create a BDC Model for Duet Enterprise).

Steps to Create the Problem

Step 1 – Create a new ECT in SharePoint Designer 2013.

Step 2 – Give the ECT a name and select ‘click here…’

Step 3 – Select ‘Add Connection’.

Step 4 – Type is WCF Service.

Step 5 – Fill in connection details and press ‘OK’.

Step 6 – Respond to Basic Authentication prompts.

Error Analysis

Error Message Received.

Fiddler Traffic Capture

The traffic capture from Fiddler demonstrates the two minor problems that added up together make one major issue.

Problem 1: In NetWeaver Gateway, there appears to be no way to turn off CSRF token validation for the $metadata URL.

Ever since NetWeaver Gateway 2.0/SP03, the CSRF check has become the default behavior for all modifying requests.  In our scenario, we have disabled this check on the /sap/opu/odata/sap/Z_PURCHASE_ORDER_SRV node.  However, the check still appears to be occurring for the /sap/opu/odata/sap/Z_PURCHASE_ORDER_SRV/$metadata node.  Since $metadata is somewhat of a virtual node, there is no placed to go to within transaction SICF to turn off the CSRF behavior.  In effect, CSRF is always on and cannot be turned off.  In SAP’s defense, doing an update operation against $metadata makes no logical sense, so this condition should never arise without Problem 2, below.

Problem 2: SharePoint Designer is retrieving $metadata with a POST request instead of a GET request.

In the OData standard, a POST is considered an update.  SharePoint Designer should be performing a GET request to retrieve the $metadata.  Doing an update against $metadata makes no real sense.  Obviously, Microsoft’s internal implementations of OData must be allowing POST requests as a means to retrieve $metadata.  In Microsoft’s defense, since updating $metadata using HTTP is not really part of the OData standard, all HTTP traffic (GET or POST) could be assumed to be a ‘read’ operation.   

Has anyone else seen this behavior?  Any ideas of something I could try next?

[Former Member · Accepted solution]

Hi Steven,

The MSDN article you are following is geared towards Duet Enterprise 1.0, which assumes that you are using SOAP web services (not OData services).

To create an ECT for an OData service you will need to do this through Visual Studio 2012. Please take a look at this document (and other docs):

http://msdn.microsoft.com/en-us/library/jj163967.aspx

Cheers, Alex

[former_member186439 · Accepted solution]

Thanks for the response.

Yes, I have tried that approach.  I keep running into an authentication problem.  My OData service is secured using Basic Authentication.  Visual Studio keeps forcing a Windows Domain Name into the authentication.  To me, it seems that Visual Studio is prompting for Windows credentials when it should be prompting for Basic Auth credentials.

Specifying the OData Source:

Logon Prompt (note the Domain name):

Fiddler shows that the Domain is part of the Authentication Header:

At least SharePoint Designer seemed to understand Basic Authentication. 

I'm stuck.  Any ideas?

[Former Member · Accepted solution]

Hi Steven,

To get VS to ignore the domain try to enter it like this "\someuser" (adding a backslash at the beginning).

I hope this workds.

Cheers, Alex

[former_member186439 · Accepted solution]

Alexander,

The backslash worked great! 

However, this creates an ECT with 'PassThrough' authentication.

   <Property Name="ODataServiceAuthenticationMode"  
   Type="System.String">PassThrough</Property>

When I change this to 'Credentials' so that I can use the Secure Store, I start getting the error:

   "Connection manager did not return valid connection.  Error Message:'The Property with Name

   'SsoProviderImplementation' is missing on the LobSystemInstance (External System Instance).'."

I have added the SsoProviderImplementation tag to the LobSystemInstance, but the error does not go away.  Here is a screen shot of my latest (failed) tag combination:

Any ideas?

Thanks,

Steve

[Former Member · Accepted solution]

Hi Steve,

I am not quite sure how to fix this. Please take a look at this document - maybe there is some helpful information there: http://scn.sap.com/docs/DOC-39771

Cheers, Alex

[former_member186439 · Accepted solution]

Alex,

I have made some progress.  Still not solved.  I have learned that you have to use PowerShell and the New-SPODataConnectionSetting cmdlet to create the connection.

Once you do that, you can reference that connection in your .ect file using the ODataConnectionSettingsId property.

However, when I test the App, I get an "Access denied. You do not have permission to perform this action or access this resource." error.  When I look in the ULS log I see a “does not have permissions to use the connection” error.  I need to figure out how the security on these ODataConnectionSettings objects in handled.

Regards,

Steve

[former_member186439 · Accepted solution]

Turns out the "Access Denied" was not for the user but was for the SharePoint Hosted App.  The Application needed to request permissions to use the Business Connectivity Services (BCS) Connection using the AppManifest.xml file.

Once that was done, the next time I ran the App, I was asked to "trust" the application's use of the external connection that I created previously using PowerShell and referenced in the ECT.

And, now it works!

Alex, Thanks for all the help!

[Former Member · Accepted solution]

Hi Steve,

Congratulations! Happy to hear you got it working. Thanks for reporting back how you solved the problem.

Cheers, Alex