|
|
1
0
如果您的团队对整个MS堆栈感到满意,那么我建议您使用Biztalk而不是Jitterbit,并且我建议您在2006年使用2009年,主要是因为更新了平台支持(与2008年的.NET 3.5、MS SQL 2008、MSBuild相比)。 如果需要管理和监视工具的附加值,则使用Biztalk是正确的。如果您只想构建一个低级别的EAI平台,那么Biztalk可能太贵了,而且您可以更好地使用自制的WCF+WF解决方案。 我承认我有偏见,因为我到目前为止还和Biztalk2002联系在一起,而且无可否认我被Biztalk2009的可能性所压倒。 |
|
|
2
1
微软在构建一个强大的、可扩展的产品方面做得很好。因此,它可以避免编写处理消息传输所需的所有管道。不过,这的确是要付出代价的。您不仅必须了解.NET(有很多这样的功能),还需要具备XML(因为所有消息都是XML的转换器)、XSLT(即映射)和专业知识,了解Biztalk的语言和体系结构。这些知识和经验需要时间来建立。对于企业级系统来说,如果不是实时的话,至少每天都要通过大量(或大型)消息发送,那么Biztalk可能是一个救命稻草。 -克里普 |
|
|
user1104946 · 从BizTalk动态发送端口执行SP 8 年前 |
|
|
Dev · 在BizTalk发送端口中生成两条消息(来自一条输入消息) 8 年前 |
|
Rob Bowman · BizTalk 2016缺少Sql管理工具 8 年前 |
|
|
Wookoai · BizTalk C#Functoid生成动态日期 8 年前 |
|
|
Bee · 三层BizTalk体系结构是否可行? 8 年前 |