Sounds simple, except for the fact that, more often that not even if you follow the steps to the letter, one might come across the following error message:
How to track that down?
Listen to the network: well, one of the things you can do it to see what's going on is using the good old network sniffing tools. I suggest to you the Network Monitor, but feel free to use what ever you want. By listening to the traffic flowing from SharePoint to SAP you will have a clue it the connection is established.
If you can browse, the issue is likely security. Check the security configuration of the Duet accounts involved. Check the SSO accounts.
If you can not browse, check if there are any firewall blocks between the SharePoint farm and the SAP gateway servers.
if there are no devices or security rules blocking the network connection then we must go to the mythic land of the SAML.
You see…for Duet Enterprise to work , the endpoint requires that the SAML issuer configured in the SAP side must be correct. If it is not, this will result in a token issued incorrectly, which will then reflect in the BDC schemas exported from SAP, and since the schemas are going to be generated with different keys, the BCS models and calls to endpoint won't work. The fix is in the middleware, the SCL.
This used (maybe still is...) a very tricky thing because the only way to fix this is dealing with XML manually (I know...sorry for you in advance). On a positive note, I understand that in Duet Enterprise FP1 there is an automated tool, but I haven’t be able to work with FP1 yet.
If you don't have access to this XML tool to “spot the not-right”, I suggest you to try these steps:
- If you see the KeyType element, try to change to PublicKey. (check the WSDL endpoint exposed by the SAP)
- Remove all BCS definitions from SharePoint
- In SAP, regenerate all BDC definitions.
- Reimport them all into SharePoint
By Edge Pereira