The WCF – Custom receive location “….” is shutting down. The Messaging Engine failed while notifying an adapter of its configuration.

Recently after a new deployment on production the WCF-Custom receive location for SAP binding got shut down with the following error:

ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_LOGON_FAILURE. SapErrorMessage=Incomplete logon data..  AdapterErrorMessage=. —> Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_LOGON_FAILURE. SapErrorMessage=Incomplete logon data.

We also noticed that when the error happened, there was no password present at the Adapter settings.

image.png

Once the password was given the issue was resolved and have not happened till now. But we were trying to know the root cause for the shutting down of the receive location. As per the error message it seems to be due to the missing password. But we had set the credentials properly and we had received few transaction through this receive location successfully.

REASONS:

On further analysis we found that, the receive locations are designed in such a way that if there are configuration issues then the receive locations are supposed to get shutdown.

Generally receive location get disabled because of couple of reasons:

  • Host cannot find the address / location in case of File, FTP or SQL
  • Permission issue – host does not have appropriate right

I our case (WCF-custom) it got disabled because of missing password. Since missing password was a bad configuration, therefore the receive location shutdown is completely legitimate.

Regarding the fact that the adapter is not able to store the password and loses them time to time, the password is stored encrypted within SSO as one binary blob that also includes the other connection details – the likelihood of just the password being lost while all the other connection details are still there is extremely low.

In our case, we created
a new receive handler (RH2) for WCF-Custom  adapter
moved the existing receive location to run under new receive handler(RH2)
did not recycle the existing receive handler (RH1) from where the existing receive location moved

So here  since the existing receive handler has not been restarted it still has the receive location loaded within it.

Due to this, whenever the existing receive location is invoked within host RH1 we get the error since the receive location configuration for this host no longer exists.

There can be one more scenario where someone go to the RL transport properties and clicked the password property and then OK’d out rather than hitting Cancel.

References:

https://social.msdn.microsoft.com/Forums/en-US/0a1f0cd0-eb0f-4084-9072-466340ab3113/the-messaging-engine-failed-while-notifying-an-adapter-of-its-configurationthe-receive-locations?forum=biztalkgeneral

https://social.msdn.microsoft.com/Forums/en-US/9b4a8dd3-7198-479f-8c93-214f09a3d9f7/biztalk-receive-location-with-file-adapter-is-getting-disabled-frequently?forum=biztalkgeneral

Loved this? Spread the word


BizTalk Server Monitoring

Gautam

Follow me here

About the Author

My name is Gyanendra Kumar Gautam. I am Solution Consultant, who basically works to hook the stuff together using Microsoft technologies like Azure PaaS, Azure Serverless Services, Microsoft BizTalk Server, and Azure DevOps Services.

You may also like

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
turbo360

Never miss a good story!

 Subscribe to my blog to keep up with the latest news!