通过

BIZTALK ENTSSO FAILURE – “THE MAPPING DOES NOT EXIST” ERROR

  • 项目

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.

SELECT rl.Name,
  dbo.admsvr_GetLastestDate(rl.DateModified,d.DateModified),  
  rl.ActiveStartDT,
  rl.ActiveStopDT,
  rl.StartDTEnabled,
  dbo.adm_fnConvertLocalToUTCDate(rl.SrvWinStartDT),
  rl.StopDTEnabled,
  dbo.adm_fnConvertLocalToUTCDate(rl.SrvWinStopDT),
  rl.Disabled,
  rl.uidCustomCfgID,
  rl.bSSOMappingExists,
  rl.InboundTransportURL,
  rl.OperatingWindowEnabled,
  rl.ReceivePipelineData, -- Custom Pipeline configuration data
  h.PipelineID,
  d.uidGUID, -- Receive Port ID 
d.nvcName, -- Receive Port Name
  e.Name, -- Protcol Name, e.g. FILE
  e.InboundEngineCLSID,
  i.PipelineID,
  d.bTwoWay,
  d.nAuthentication,
  rl.SendPipelineData, -- Custom Pipeline config (req-resp)
  d.nTracking,
  b.uidReceiveLocationSSOAppID,
  rl.CustomCfg,
  dbo.admsvr_CheckForMapOnReceivePort(d.nID),
  j.PipelineID,
  rl.EncryptionCertThumbPrint,
  d.bRouteFailedMessage,
  CASE WHEN (bam.uidPortId) IS NULL THEN CAST(0 as int) ELSE CAST(1 as int) END AS IsBamEnabled
FROM 
  adm_ReceiveLocation rl
  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
WHERE 
  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. 

declare @myid
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. 

Happy BizTalking!

 

Written By
Rajkumar Damodaran

Reviewed By
Jainath Ramanathan

Microsoft GTSC India.

Comments

  • Anonymous
    September 08, 2015
    The comment has been removed
  • Anonymous
    February 06, 2017
    Thanks it helped me.