After using DuetConfig.exe with the -ImportBdc command to import models into SharePoint, you may see the following error in the SAP logs when trying to use Duet Enterprise functionality:

"Property 'SAP__Origin' is invalid"

Cause:

The LsiUrl value used when importing the model into SharePoint was not correct. The LsiUrl was missing the required multi-origin ( ;mo ) identifier which routes the request to the SAP service that expects the 'SAP__Origin' property that is being sent with the Duet Enterprise request from SharePoint.

Resolution:

Remove and re-import the models using the correct LsiUrl syntax as documented in "Table 2" of the Duet Enterprise 2.0 SAP Configuration Guide:

For example, here are the URLs for Workflow:

LSI URL for Workflow:

https://<host>:<port>/sap/opu/odata/IWWRK/DUET_WORKFLOW_CORE;mo;c=SHAREPOINT_DE/

LSI URL for Subscription:

https://<host>:<port>/sap/opu/odata/IWBEP/SUBSCRIPTIONMANAGEMENT;mo;v=2;c=SHAREPOINT_DE/

Here is an example of a correct ImportBbc command for Workflow:

DuetConfig.exe -ImportBdc -FeatureName Workflow -LsiUrl https://SAPGATEWAY.domain.com:8001/sap/opu/odata/IWWRK/DUET_WORKFLOW_CORE;mo;c=SHAREPOINT_DE -BdcServiceApplication "Business Data Connectivity Service" -UserSubLsiUrl https://SAPGATEWAY.domain.com:8001/sap/opu/odata/IWBEP/SUBSCRIPTIONMANAGEMENT;v=2;mo;c=SHAREPOINT_DE

"The user does not exist or is not unique."

In the ULS logs you may see one or both of these entries:

1. "ServiceContext for the <sharepointserver:port>/ context is null"

     Where sharepointserver and port are replaced with values from your environment.

     For example:
     "ServiceContext for the https://litware.litware.com:9000/ context is null"

2. System.Runtime.InteropServices.COMException: The user does not exist or is not unique.  
     at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, …   
     at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, …

Cause:

The Duet Claims Provider, like most SharePoint functionality, requires a root site collection. The error "ServiceContext for the sharepointserver:port/ context is null" means that a root site collection could not be found.

For more information about limitations and supportability when no root site collection exists for your SharePoint Web Application, see the following articles:

SharePoint 2010: Supportability of unprovisioned root site in a SharePoint web application

SharePoint: Office client integration errors when no root site exists

Error message when you try to access a UNC Path of a Windows SharePoint Services 3.0 or in SharePoint Server 2007 if no site collection is mapped to the root of the web application: "The network path was not found"

Resolution:

You can confirm if a root site collection exists by navigating to the sharepointserver:port/ site in a browser and then see if a SharePoint site is displayed.  If there is no site at that URL, then you will need to create a SharePoint site collection at sharepointserver:port/ to resolve this issue. The site template used to create the root site is not important and it can be a blank site.

Error while crawling LOB contents. ( CX_WS_SECURITY_FAULT:An exception occurred: No mapping for SAML authentication found (Issuer SharePoint) )

We logged on to SharePoint as the service account being used to do the crawl and tried to display a list based on the Duet External Content Type and the same basic error was displayed:

CX_WS_SECURITY_FAULT:An exception occurred: No mapping for SAML authentication found (Issuer SharePoint)

When logged on to SharePoint as a different user the list displayed correctly, so our problem seemed to be user-specific. Based on my experience this typically means that there is a problem with the user mapping table (VUSREXTID) in SAP.

To troubleshoot this we started by turning on a Payload Trace on the SAP Duet server so we could see the requests coming in from SharePoint and could see the SAML Issuer and NameIdentifier being used.  This information is in the first entry (Request Step:1) in the payload data.  You can click the Original XML button to see it as XML.  Here is an example of what this should look like:

Next we looked at the entries in the VUSREXTID table in SAP to verify that we had a mapping for this user. To do this you can run transaction SM30 and enter VUSREXTID as the Table/View name.  In the External ID type dialog that appears enter SA  (for SAML NameIdentifier) and press enter.

We could see the correct entry in our list but we noticed that the case did not match. The VUSERXTID table is case sensitive, so we created the correct entry by using Copy As… to create a copy of the original and change the case to match the value seen in the SAML data in the payload trace. NOTE:  Creating New Entries directly in the VUSREXTID table is not supported because it bypasses some SAP logic that needs to be applied to the entries.  But you can use Copy As… to create entries based off of a working entry. 

With the case fixed, we re-tested but got the same error.

We realized that what had happened was that someone had added the entry to the VUSREXTID table directly without using Copy As… (which is not supported). The current entry and the copy we made from it were both invalid.  So, we removed them and used Copy As… to create a new entry based on an entry that we knew worked. We also could have used the implementation guide (transaction SIMGH) to execute the proper role mapping steps.   The problem was resolved and the account could now be successfully mapped to the SAP user.

Here are the steps to enable a Payload trace (you can also enable Functional and Performance traces at the same time if you wish)

1. Use SAPGUI to logon to the SAP NetWeaver system.

2. Run transaction SRTUTIL (or SRT_UTIL)

3. Right-click on "Users & Terminals & Request URI" and then click on "Add User, Terminal or Request URI".

4. Choose the "Request URI" option and leave the default path "/sap/bc/srt/" and click the green check mark button.

5. On the "Configuration" tab select "Active" in the "Payload Trace" dropdown and then click the "Save Configuration" button lower on the page.

6. Switch to the "Payload Trace" tab and reproduce the issue (or just display a working Duet Enterprise list) to see the request and response data between SharePoint and SAP.

NOTE: In the image above I added the "Operation Name" column to make the list easier to read.

7. Double-click on an entry to see more details.

8. In the Type column click on Request or Response to see the details of each step. NOTE: There should be Request and Response for each Step # in the "Step" column.

9. Click the "Original XML"  button to view the Request or Response as XML:

Problem:

We recently encountered an interesting problem with a configuration of a SharePoint 2010 farm where the profile sync farm is not the same as the services farm. In the services farm, the BCS models connect to SAP.  In the profile sync farm, the imports occur. The STS's are not the same therefore, the SAP endpoint has to be configured with basic auth. The basic authentication  approach with the STS to SAP fails.

You might see the following error logged in the ULS logs:

OWSTIMER.EXE (0x0A5C) 0x0914 Duet Enterprise ProfileSync h31g Unexpected Finder method call failed.. The exception message is 'Connection manager did not return valid connection. (Proxy creation failed. Default context not found.) Stack Trace: at Microsoft.SharePoint.BusinessData.SystemSpecific.Wcf.WcfSystemUtility.ExecuteStatic(IMethodInstance methodInstance, ILobSystemInstance lobSystemInstance, Object[] args, IExecutionContext context) at Microsoft.SharePoint.BusinessData.Runtime.DataClassRuntime.ExecuteInternalWithAuthNFailureRetry(ISystemUtility systemUtility, IMethodInstance methodInstanceToExecute, IMethod methodToExecute, ILobSystemInstance lobSystemInstance, ILobSystem lobSystem, IParameterCollection nonReturnParameters, Object[] overrideArgs) at Microsoft.SharePoint.BusinessData.Runtime.DataClassRuntime.ExecuteInternal(IDataClass thisDataClass, ILobSystemInstance lobSystemInstance, ILobSystem lobSystem, IMethodInstance methodInstanceToExecute, IMethod methodToExecute, IParameterCollection nonReturnParameters, Object[]& overrideArgs) at Microsoft.SharePoint.BusinessData.Runtime.EntityRuntime.ExecuteInternal(IDataClass thisDataClass, ILobSystemInstance lobSystemInstance, ILobSystem lobSystem, IMethodInstance methodInstanceToExecute, IMethod methodToExecute, IParameterCollection nonReturnParameters, Object[]& overrideArgs, IFilterCollection filters) at Microsoft.SharePoint.BusinessData.Runtime.EntityRuntime.ExecuteFiltered(IEntity this, IFilterCollection filterCollection, IMethodInstance methodInstanceToExecute, ILobSystemInstance lobSystemInstance) at Microsoft.SharePoint.BusinessData.Runtime.EntityRuntime.<FindFiltered>b__3(IEntity e, IMethodInstance mi, IFilterCollection fc, ILobSystemInstance lsi) at Microsoft.SharePoint.BusinessData.Runtime.BatchableEntityInstanceEnumerator..ctor(IEntity entity, IMethodInstance methodInstance, IFilterCollection filters, ILobSystemInstance lobSystemInstance, ExecutionCallBack executionCallBack, Boolean isBatchingEnabled) at Microsoft.SharePoint.BusinessData.Runtime.EntityInstanceEnumeratorFactory.CreateEntityInstanceEnumerator(IEntity entity, IMethodInstance methodInstance, IFilterCollection filters, ILobSystemInstance lobSystemInstance, ExecutionCallBack executionCallBack) at Microsoft.SharePoint.BusinessData.MetadataModel.Static.Entity.FindFiltered(IFilterCollection filterCollection, ILobSystemInstance lobSystemInstance) at OBA.Server.ProfileSync.RoleSync.GetUsersPropertiesFromBackend()

Cause:

The service context is not being properly called when using the BCS Finder methods.

Resolution:

The following update will address this issue along with some additional configuration steps that are noted below:

Duet Enterprise for Microsoft SharePoint and SAP hotfix package 2597130 – support.microsoft.com/kb/2597130 , contains the fix that resolves this issue.  In addition to applying the fix the following steps need to be performed to resolve the issue:

1.) Reset the SharePoint Timer Job on all servers in the farm
2.) Modify the UserRoles BDC Model that’s exported from the SAP/SCL layer.  The UserRoles model must be altered with the following highlighted changes:

            <Property Name="WcfAuthenticationMode" Type="System.String">Credentials</Property>
            <Property Name="SsoApplicationId" Type="System.String">WSDL</Property>
            <Property Name="SsoProviderImplementation" Type="System.String">Microsoft.Office.SecureStoreService.Server.SecureStoreProvider, Microsoft.Office.SecureStoreService, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
            <Property Name="UseStsIdentityFederation" Type="System.Boolean">false</Property>

3.) Import the manually modified model to the BDC on the Services Farm.

03/16/2012 11:01:57.50    w3wp.exe (0x1548)    0x1858    Business Connectivity Services    Business Data    f6pq    Unexpected

CommunicationException exception executing : System.ServiceModel.Security.SecurityNegotiationException: SOAP security negotiation failed. See inner exception for more details. ---> System.Security.Cryptography.CryptographicException: The system cannot find the file specified.     
at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)   
at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)   
at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()   
at System.IdentityModel.Tokens.RsaSecurityToken..ctor(RSACryptoServiceProvider rsa, Boolean ownsRsa)   
at System.IdentityModel.Tokens.RsaSecurityToken.CreateSafeRsaSecurityToken(Int32 keySize)   
at System.ServiceModel.Security.Tokens.IssuedSecurityTokenProvider.CoreFederatedTokenProvider.CreateAndCacheRsaSecurityToken()   
at System.ServiceModel.Security.Tokens.IssuedSecurityTokenProvider.CoreFederatedTokenProvider.CreateNegotiationState(EndpointAddress target, Uri via, TimeSpan timeout)   
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)     -
-- End of inner exception stack trace ---    Server stack trace:    
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)   
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.GetTokenCore(TimeSpan timeout)   
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)   
at System.ServiceModel.Security.Tokens.IssuedSecurityTokenProvider.GetTokenCore(TimeSpan timeout)   
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)   
at System.ServiceModel.Security.SecurityProtocol.TryGetSupportingTokens(SecurityProtocolFactory factory, EndpointAddress target, Uri via, Message message, TimeSpan timeout, Boolean isBlockingCall, IList`1& supportingTokens)   
at System.ServiceModel.Security.TransportSecurityProtocol.SecureOutgoingMessageAtInitiator(Message& message, String actor, TimeSpan timeout)   
at System.ServiceModel.Security.TransportSecurityProtocol.SecureOutgoingMessage(Message& message, TimeSpan timeout)   
at System.ServiceModel.Security.SecurityProtocol.SecureOutgoingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)   
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)   
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)   
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)   
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)   
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)    Exception rethrown
at [0]:    
at Microsoft.SharePoint.BusinessData.SystemSpecific.Wcf.WcfSystemUtility.Execute(Object[] args)

I did some debugging and found that a call to lookup the user storage location was setting the error: "The system cannot find the file specified" as a result of not being able to open the profile registry keys for the user.  The code made 3 attempts looking for these 3 keys:

1. HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-17
2. HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-17.bak
3. HKCU\S-1-5-17

NOTE: S-1-5-17 is the SID for the NT AUTHORITY\IUSR account.

I had already collected a Process Monitor log so I used it to easily see the 3 registry requests resulting in NAME NOT FOUND:

NOTE: Creating a filter in Process Monitor where "Path contains \Windows NT\CurrentVersion\P" will allow you to easily find this.

In the working test environments we were looking for and successfully finding the ProfileList registry key for the SID of the user configured as the AppPool identity.

For example:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-123456789-123456789-123456789-123456

We would then use information from the registry to build a path to the RSA directory for the user:

"C:\Users\<AppPoolUserID>\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-123456789-123456789-123456789-123456\"

So, the issue here was that on the production server we were not actually running as the AppPool Identity, we were running as the IUSR account and there is no Windows profile that exists for the IUSR account.  This brings up the next key question which is why is one server running as IUSR while the other working one is running as the Application Pool Identity?

The answer to this lies in a hotfix/update that is applied on the production server that isn't on the test servers.

----------------------------------------------------------------------------------------------------------------

SharePoint impersonates the IUSR account and is denied access to resources states:

This hotfix makes a new application setting available in ASP.NET 2.0. The new application setting is aspnet:AllowAnonymousImpersonation. You can enable this setting by adding the following section to the Web.config file:

    <appSettings>

        <add key="aspnet:AllowAnonymousImpersonation" value="true" />

    </appSettings>

To enable this setting, you must have IIS 7 or IIS 7.5 running in Integrated mode. When this setting is enabled, the application runs under the security context of the IUSR identity.

----------------------------------------------------------------------------------------------------------------

Article 979917 shows that the new setting of running as IUSR was introduced in System.web.dll version 2.0.50727.5007

Our working test servers had an older build and our failing production server had a newer build.

By setting the value to "false" SharePoint will use the older less restrictive security setting that allows the code to run as the AppPool identity. 

I just worked with a customer that had Duet Enterprise configured and they were setting permissions in SharePoint based on their SAP Roles as described in Using SAP roles to access SharePoint objects . Everything looked good, but users with the SAP Roles defined were not able to access the SharePoint sites that were permissioned with the SAP Roles.

The first thing we did was confirm that the SAP Roles were actually on the user profiles.  To do this we went to Central Administration selected Manage Service Applications and then clicked on our User Profile Service Application. Under People we chose Manage User Profiles and then searched for one of our users. Once found we selected the user and chose Edit My Profile and we could see in the list that the SAP Roles property existed and that it was populated as expected:

The next step was to verify that the user's Claims token on SharePoint actually contained the Roles. I didn't find a simple way to do this so I used the Windows Debugger (windbg.exe) to dump out the Claims and could see that the SAP Roles were not included.  Instead of using windbg you could create a simple web part to dump out claims based on the sample on MSDN.

So at this point I knew that the User Profiles had the SAP Roles populated, but the user's Claims were not being augmented with the SAP Roles.  I debugged the Security Token Service and found that the Duet claims provider successfully retrieved the User Profile but the SAP Roles property (actually named OBACore-SAP-Roles) was empty so the Duet claims provider didn't have any roles to add.

We then realized that the issue was related to the permissions on the User Profile Application. The SAP Roles property that gets added by Duet Enterprise is added with the Default Privacy Setting set to Only Me which is visible in the image above. The problem was that the customer had configured a new identity for the SecurityTokenServiceApplicationPool but this identity didn't have any special rights on the User Profile Application. So when the Duet claims provider code running in the SecurityTokenService retrieved the user profile, it was running as the identity of the SecurityTokenServiceApplicationPool and therefore could not see any fields that had the privacy setting configured to Only Me. 

Resolution:

To fix this we went to Central Administration selected Manage Service Applications and then clicked next to the User Profile Service Application to select it without opening. On the menu we clicked on Administrators and then we added the identity from the SecurityTokenServiceApplicationPool and gave it the Manage Profiles permission.

Another solution would be to use Manage User Properties in the User Profile Service Application to change the Default Privacy Setting on the SAP Roles property to be Everyone instead of Only Me.

Connection to the WCF service that has connection name <Name> cannot be established.

Error Details

Cannot compile Web Service proxy.

This error isn't very detailed, so to get more information I collected a BCS client-side trace  from the machine where I was using SharePoint Designer. In the BCS trace I could see a series of error entries similar to this:

Error during Windows Communication Foundation Proxy compile: c:\Users\waltwa\AppData\Local\Temp\1\v4akfd3i.0.cs(563,60) : error CS0120: An object reference is required for the nonstatic field, method, or property 'BCSServiceProxy.ZduetWaltTestClose.System.get'

Error during Windows Communication Foundation Proxy compile: c:\Users\waltwa\AppData\Local\Temp\1\v4akfd3i.0.cs(563,67) : error CS0117: 'string' does not contain a definition for 'Xml'

In the WSDL (from the Service Metadata URL) I could see that in the ZduetWaltTestClose complex type there is an element named "System".

If you look at the WSDL you will see an element named "System" in the complexType "ZduetWaltTestClose":

<xsd:complexType name="ZduetWaltTestClose">
    <xsd:sequence>
        <xsd:element name="Type" type="n0:char1" /> 
        <xsd:element name="Id" type="n0:char20" /> 
        <xsd:element name="Number" type="n0:numeric3" /> 
        <xsd:element name="Message" type="n0:char220" /> 
        <xsd:element name="Row" type="xsd:int" /> 
        <xsd:element name="Field" type="n0:char30" /> 
        <xsd:element name="System" type="n0:char10" /> 
    </xsd:sequence>
</xsd:complexType>

So at this point, we know that the compiler is failing when trying to work with 'BCSServiceProxy.ZduetWaltTestClose.System.get'.

Cause

The problem here is that during the creation of the Connection, a proxy DLL is generated based on the WSDL that is specified in the "Service Metadata URL" field of the WCF Connection dialog box.  The first step is to convert the WSDL to a C# .NET source file (a .cs file) and this works fine.  The next step is that the C# Compiler (CSC.EXE) tries to compile the .cs file into a DLL but this fails due to the method named "System".  To see the problem outside of SharePoint Designer, if you have Visual Studio, you can use the WSDL.EXE (note SvcUtil.exe is a better choice – see Update below) and CSC.EXE tools.

1. Save your WSDL to disk and give it a .wsdl extension.

2. In a Visual Studio Command Prompt, run wsdl.exe and pass it your .wsdl file.
    For example:
           WSDL.EXE C:\Temp\WaltsTest.wsdl

    You should get output similar to:
    Writing file 'C:\Temp\Z_WALT.CS'.

3. Next, run:   CSC.EXE /t:library C:\TEMP\Z_WALT.cs

    This should result in the same series of errors that you see in the BCS Client trace:

error CS0120: An object reference is required for the nonstatic field, method, or property 'BCSServiceProxy.ZduetWaltTestClose.System.get'

To fix this we renamed the "System" field to "SystemName" on the SAP side and then it imported without any problems.

Update

I worked on another “Cannot compile Web Service proxy” issue recently and the steps above to use WSDL.EXE to generate the .cs file were not sufficient to show the problem as both wsdl.exe and csc.exe commands completed without error.  I found that using the Windows SDK tool SvcUtil.exe is a better representation of what SharePoint Designer is doing to generate proxies for WCF services and using SvcUtil.exe I was able to see the compiler error outside of SPD.

1. Save your WSDL to disk and give it a .wsdl extension.

2. In a Visual Studio Command Prompt, run SvcUtil.exe and pass it your .wsdl file
    For example:  
          SvcUtil.exe C:\Temp\WaltsTest.wsdl

    You should see output similar to:
          Generating Files…
          C:\Temp\Z_WALT.CS
          C:\Temp\output.config

3. Next, run:   CSC.EXE /t:library C:\TEMP\Z_WALT.cs

This resulted in the following error:

Z_WALT.cs(219,22): error CS0101: The namespace '<global namespace>' already contains a definition for 'Walt'
Z_WALT.cs(17,18): (Location of symbol related to previous error)

In this case, the WSDL contained both a ComplexType and a PortType with the same name ‘Walt’.  The PortType ‘Walt’ from the WSDL had resulted in an Interface named ‘Walt’ on line 17 of the Z_WALT.cs file and the ComplexType ‘Walt’ from the WSDL had resulted in a Class named ‘Walt’ on line 219 which resulted in the compiler error.

To fix this we renamed the PortType ‘Walt’ on the SAP side.

Resolution

To test the resolutions before making the changes SAP side, you can make changes to the downloaded .wsdl and then use the SvcUtil.EXE and CSC.EXE steps mentioned above to confirm that the .cs code can be compiled without error.

After deploying Duet Enterprise you find that the Duet Enterprise Site template is missing when creating a new Site Collection in Central Admin.  The template highlighted below is the template that is missing in this scenario.

Cause:

You are deploying Duet Enterprise into a multi-server farm.  The proper templates, specifically the ones required for the “Duet Enterprise Sites” site template are not deployed to the app server that is hosting Central Admin.

Resolution:

You will need to use DuetConfig.exe to configure all of the Duet Solutions to the Central Admin Web Application.  To do this, go to another server in the farm that already has Duet installed and deploy the solutions and portal but point to the Central Admin webapp URL.  The commands that are needed are as follows (Run from an Administrator command prompt):

DuetConfig /configuresolution "<Solution being deployed>" /webappurl "<URL of the Web application hosting Central Admin>"

The steps above need to be done for all of the dependencies of the Portal and then followed up by the portal solution:

- Reporting

- Workflow

- ProductWorkspace

- OrdertoCash

- CustomerWorkspace

- Portal (This needs to be done after all of the other solutions have been successfully deployed)

These Duet Site templates along with more information and steps are also discussed and outlined at the location below in the Deployment Guide.

Create a site collection by using the Duet Enterprise Sites template

Once you have gone through these steps, you should see the Duet Enterprise Site Templates visible in Central Admin.

“Error: The size necessary to buffer the XML content exceeded the buffer quota.”

You may also see the following errors in the ULS log on the SharePoint server:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ServiceModel.QuotaExceededException: The size necessary to buffer the XML content exceeded the buffer quota.    Server stack trace:     
 at System.ServiceModel.Channels.BufferedOutputStream.WriteCore(Byte[] buffer, Int32 offset, Int32 size)    
 at System.Xml.XmlStreamNodeWriter.FlushBuffer()    
 at System.Xml.XmlBinaryNodeWriter.FlushBuffer()    
 at System.Xml.XmlStreamNodeWriter.GetBuffer(Int32 count, Int32& offset)    
 at System.Xml.XmlBinaryNodeWriter.UnsafeWriteText(Char* chars, Int32 charCount)    
 at System.Xml.XmlBinaryNodeWriter.WriteText(Char[] chars, Int32 offset, Int32 count)    
 at System.Xml.XmlBaseWriter.WriteChars(Char[] chars, Int32 offset, Int32 count)    
 at System.Xml.XmlBinaryWriter.WriteTextNode(XmlDictionaryReader reader, Boolean attribute)    
 at System.Xml.XmlDictionaryWriter.WriteNode(XmlDictionaryReader reader, Boolean defattr)    
 at System.ServiceModel.Channels.ReceivedFault.CreateFault12Driver(XmlDictionaryReader reader, Int32 maxBufferSize, EnvelopeVersion version)    
 at System.ServiceModel.Channels.MessageFault.CreateFault(Message message, Int32 maxBufferSize)    
 at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.TryGetSecurityFaultException(Message faultMessage, Exception& faultException)    
 at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)    
 at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)    
 at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)    
 at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)    
 at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)    
 at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)    Exception rethrown
at [0]:     
 at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)    
 at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)    
 at BCSServiceProxy.IWXRead_UserRoles_in.employeeGetAll(employeeGetAllRequest request)    
 at BCSServiceProxy.WXRead_UserRoles_inClient.BCSServiceProxy.IWXRead_UserRoles_in.employeeGetAll(employeeGetAllRequest request)    
 at BCSServiceProxy.WXRead_UserRoles_inClient.employeeGetAll(GetAllRequest GetAllRequest)     -
-- End of inner exception stack trace ---    
 at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)    
 at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)    
 at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)    
 at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)    
 at Microsoft.SharePoint.BusinessData.SystemSpecific.Wcf.WcfSystemUtility.Execute(Object[] args)

The error we see above in the ULS log is a SharePoint side generated WCF error because the error text that we received from the SAP system is larger than our buffer size.  Keep in mind that this is not the real error that we are looking for, this is a generic error that is displayed on the SharePoint server due to the large error being returned by SAP.  The real error is found by executing SAP transaction SRT_UTIL, SAP’s Tracing Utilities for Web Services, and looking at the captured information in the payload trace.  In this case the following errors were logged:

If you drill down into the Error text from the above exceptions you will see the following, which is the real error that allows us to determine the root cause of this issue.

“CX_SEC_SXML_ERROR:An exception has occurred. An exception occurred:Error in ST program SEC_SAML_ASSERTION_IN when importing XML data. Error in ST program SEC_SAML_ASSERTION_IN when importing XML data. SSFW_KRN_VERIFY failed with: verification failed, see decrypted digest.”

Cause:

The system time on the SharePoint Server and the SAP system are not in sync or in the allotted window of time difference.

Resolution:

Ensure that the SharePoint and SAP systems have their system time in-sync with each other.  Additionally, you may also want to verify that the system time for each of the servers is correct for the location of the server and that they are not being set incorrectly to a different timezone/offset.