繁体   English   中英

BRE策略-Db事实的存储连接字符串的位置

[英]BRE Policy - Where to Store Connection Strings for Db Facts

使用BizTalk 2016 FP3 CU5。

我有一个BRE规则,它接受4个类型的xml文档和一个数据连接。 我已经设置了业务流程以使用调用规则形状执行该业务流程。

我正在使用BizTalk部署框架(BTDF)进行部署,这在部署BRE策略方面做得很好。 我的问题是,在策略的导出xml(名为NotificationService.xml)中,存在对规则中使用的数据库的硬编码引用-如下所示:

 <datarow ref="db_32" server="SDEIDBTI04\CrossRef" dataset="CrossRef" table="Lookups"

这引用了我的dev vm,但是随着解决方案通过测试升级并进入生产环境,服务器名称也需要相应更改。

我当前对这个问题的解决方案是使用BTDF的能力来预处理xml文件,并用来自SSO的EnvironmentSettings excel文件中的值替换。 因此,我创建了一个“ NotificationService.Dynamic.xml”,在其中将上一行更改为:

<!-- ifdef ${_xml_preprocess} -->
  <datarow ref="db_32" server="${Common.Components.CrossRefDbServer}\CrossRef" dataset="CrossRef" table="Lookups" instances="16" selectivity="1" isdataconnection="true" instance="0" />
  <!-- endif -->

(*有一个很好的理由我必须保留ifdefs!)

在我的deployment.btdfproj文件中,添加了以下内容以确保预处理的策略是要部署的策略:

<FilesToXmlPreprocess Include="NotificationService.Dynamic.xml" 
Condition="'$(Configuration)' == 'Server'">
  <LocationPath>..\</LocationPath>
  <OutputFilename>NotificationService.Dynamic_Processed.xml</OutputFilename>
</FilesToXmlPreprocess>

<FilesToXmlPreprocess Include="NotificationService.Dynamic.xml" Condition="'$(Configuration)' != 'Server'">
  <LocationPath>..\NotificationService\NotificationService.BRE</LocationPath>
  <OutputFilename>NotificationService.Dynamic_Processed.xml</OutputFilename>
</FilesToXmlPreprocess>

<RulePolicies Include="NotificationService.Dynamic_Processed.xml">
  <LocationPath>..\NotificationService\NotificationService.BRE</LocationPath>
</RulePolicies>

这是可行的,但我不禁认为我已经使解决方案复杂化了。 每次我导出策略的新版本时,现在都必须经历从导出的NotificationService.xml文件创建NotificationService.Dynamic.xml文件的麻烦。 人们在不使用BTDF时如何解决相同的问题?

如果事实证明我已经走了最好的道路,那么希望这个问题将来对其他人有所帮助-我找不到google的答案!

我将创建一个静态方法,在其中创建获得查找值的所有逻辑。

因此,在此方法中,您将使用SSOSettingsFileReader.dll获得SSO CrossRefDbServer设置,然后执行一些c#代码来调用您的lookuptable并返回该值。

如果将注册表设置StaticSupport设置为1则可以在BRE中调用此方法。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM