ENTSSO issues come in all sizes and shapes. While they differ in magnitude and longevity, it is quite imperative that you understand its design implementation and know how BizTalk leverages on this component to stay operational.
Lately, I had an encounter with such an issue that gave me a run for my money. A few receive locations in the BizTalk administration console would fail to start with the below error.
Could not retrieve transport type data for Receive Location ‘<Receive location name>’ from config store. Both SSO Servers (Primary='<Server name>’ and Backup='<Server name>’) failed. Backup server failure: The mapping does not exist. For Config Store applications, the config info has not been set. (Microsoft.BizTalk.ExplorerOM)
It may be noted that there are numerous articles on this error but none seemed to solve my problem. I tried ENTSSO service restart, restored the master secret etc. but to no avail. And that’s when I decided to dig deep into the BizTalk databases and know things for real.
I collected a SQL profiler for starters and woot!! – The query was right in there. BizTalk throws in the below query on the BizTalk Management database to retrieve receive location configuration data.
rl.ReceivePipelineData, — Custom Pipeline configuration data
d.uidGUID, — Receive Port ID
d.nvcName, — Receive Port Name
e.Name, — Protcol Name, e.g. FILE
rl.SendPipelineData, — Custom Pipeline config (req-resp)
CASE WHEN (bam.uidPortId) IS NULL THEN CAST(0 as int) ELSE CAST(1 as int) END AS IsBamEnabled
INNER JOIN adm_ReceiveHandler b ON b.Id = rl.ReceiveHandlerId
INNER JOIN adm_Adapter e ON b.AdapterId = e.Id
INNER JOIN adm_Server2HostMapping f ON b.HostId = f.HostId
INNER JOIN adm_HostInstance g ON g.Svr2HostMappingId = f.Id
INNER JOIN bts_pipeline h ON h.Id = rl.ReceivePipelineId
INNER JOIN bts_receiveport d ON d.nID = rl.ReceivePortId
LEFT JOIN bts_pipeline i ON i.Id = d.nSendPipelineId
LEFT JOIN bts_pipeline j on j.Id = rl.SendPipelineId
LEFT JOIN (SELECT DISTINCT(uidPortId) FROM bam_TrackPoints) bam ON d.uidGUID = bam.uidPortId
g.UniqueId = @AppInstanceID
Look again and you will notice a column namely bSSOMappingExists whose value by default is 1. This implies that the runtime will look for an associated mapping in SSOX_IndividualMapping in SSODB. Further research revealed that uidCustomCfgID column in adm_ReceiveLocation correlates with the im_ntu or im_xu columns in the
SSOX_IndividualMapping table in SSODB.
All I had to do was to throw in the below query to see if such a mapping existed for the receive location that was failing.
set @myid = ’24EAFA61-DDDE-4D1E-86D9-D22D2F089454′–uidCustomCfgID of the receive location
select * from BizTalkMgmtDb.dbo.adm_ReceiveLocation where uidCustomCfgID = @myid
select * from SSODB.dbo.SSOX_IndividualMapping
where im_ntu = @myid
or im_xu = @myid
And quite expectedly, it yielded no rows from the SSOX_IndividualMapping table.
Quite likely, this may have happened whilst an incomplete / incorrect database back up restoration on the BizTalk databases or worse, a manual deletion.
The workaround as we know it is quite easy. Create an identical receive location configured with the same URI and credentials. Consequently, you will have mappings freshly created in the SSODB. You may delete the old ones eventually.
Microsoft GTSC India.