【问题标题】:Best way to store key value pairs in BizTalk在 BizTalk 中存储键值对的最佳方式
【发布时间】:2018-12-06 08:15:27
【问题描述】:

我们有需要存储键值对类型数据以便在 BizTalk Map 中快速检索的要求。

是否有我们可以存储它的最佳实践。存储的数据应易于维护,并应具有易于检索的缓存机制,因为要存储的键值对的数量可以在 1-100 或更多之间。

我们不需要存储机密信息,所以我不喜欢 SSO。但它仍然是一种更可取的方法吗?

我们需要在 BizTalk 地图中使用它,并且可能会针对每一行数据进行数据检索,因此也存在性能压力。

【问题讨论】:

  • 100 并不是很多。您预计会有多少个单独的查找,会有多少个不同的值表。
  • P.S.您可能希望编辑您的问题以删除“最佳方式”,因为这往往是在征求意见,这是题外话,除非您明确给出确定“最佳方式”是什么的可衡量标准。询问“最佳方式”的问题往往会吸引反对票和接近票
  • 语法修正
  • 100 不是很多,但我的来源是一个平面文件,它可以达到 20MB 并包含 60-70k 条记录。并且有 4 - 5 次值检索,总计 5*60000 次数据获取,这增加了大文件的性能下降。
  • 我给出了最佳方式 i 的标准。 e.快速检索、缓存值、多次取值、键值对存储

标签: biztalk biztalk-mapper


【解决方案1】:

为此,我将使用 Get Common Value 和 Get Application Value functoids XRef functiods。它既使您能够拥有键值对(带有一个附加元素,以便您可以根据应用程序对其进行限定),而且它们还可以进行缓存。

我写了一篇关于它的博文BizTalk Pattern: Translating Reference Data in a Map using Xref

【讨论】:

    【解决方案2】:

    您确实拥有 xRef Functoid,但它们在超出其原始设计要求的情况下有些难以维护和使用。

    我针对类似情况所做的是将查找表作为 SQL 表类型预先提取到编排中,然后使用多输入映射传递业务消息和查找表。这样,所有查找都在转换内部。

    在许多情况下,一次检索整个查找表比进行多次查找要少。

    【讨论】:

    • 我的地图已经将三个平面文件合并为一个,这就是文件变大并且映射需要大量时间的原因。
    • @SarojKumar 您可以随时使用多个地图。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-02-22
    • 1970-01-01
    • 2020-02-03
    • 2017-07-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多