Remove Connection Checks For Start-Up of Identity Broker
Currently the SharePoint Broker causes the startup of Identity Broker to fail if a connection can not be established to sharepoint (see error below).
This is not ideal behaviour as it places a dependency of Identity Broker on the SharePoint server being available. Realistically, even if SharePoint is not available, other systems may be and the inability to connect to SharePoint should not prevent data synchronization between HR, SQL or any other systems.
The issue is documented already, but I think if possible we should at least allow Identity Broker to start, as we do with other systems. https://unifysolutions.jira.com/wiki/display/IDBSP305/Identity+Broker+Service+fails+to+start+or+a+full+import+fails+due+to+a+permissions+error
The current work around is to remove/comment out the connector and any adapters completely.
Service cannot be started. Unify.Framework.UnifyServerInitializeException: Could not connect to http://sharepoint/_vti_bin/unify/userprofile.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80. ---> System.ServiceModel.EndpointNotFoundException: Could not connect to http://sharepoint/_vti_bin/unify/userprofile.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80 at System.Net.Soc...
Customer support service by UserEcho
Update: This is version 3.0.5 of the connector when used in conjunction with IdB 3.0.6
Note: This hit me while doing client work, however currently I do not perceive this as being a show stopper and unless advised otherwise, this is a "nice-to-have".
A better stack trace is
Raising priority.
This issue caused a problem at QDET where the Identity Broker service wouldn't start due to the unavailability of the SharePoint instance.
An interim workaround for this issue is to change the SharePoint connector to a placeholder connector during the SharePoint outage if the Identity Broker service is also disabled in this time.
I would like to add a comment supporting this issue as a major issue. It is a major issue that the Identity Broker service in its entirety fails if there is an error on the sharepoint end. All the rest of the IdB Connectors and adapters are totally offline which is a major issue. If a resolution to this could be achieved I would appreciate it.
Also, I would recommend the documentation (somewhere central) of the Placeholder workaround.
thanks,
Craig Gilmour
QDET has noted again this issue will become important as their SharePoint instance goes live in Production.
This was because the connector would attempt to retrieve the types available in the SharePoint instance when first constructed. I have moved this behaviour to do this when it is first needed if it hasn't been done already (before it needs to convert data). Marked as resolved.
Behaviour confirmed in a SharePoint instance. The Identity Broker service starts up when SharePoint is unavailable, and imports behave as normal. Issue closed.