Biztalk和调用Web服务的最佳方法 [英] Biztalk and the best way to call web service

问题描述

我正在编写一个biztalk编排，它将需要调用一个Web服务，可能是多个Web服务，并且可能不止一次.我面前有两个选择.一种是在一个单独的代码项目中使用wsdl，然后以表达式的形式从代码中调用Web服务，第二种是从Biz中使用它，获取模式等，并通过请求/响应端口进行调用.这里的最佳做法是什么?一方面，如果更新了wsdl，则比模式和端口更容易更新代码，并且看起来很混乱并且需要为多个Web服务调用构建足够的端口.另一方面，您可以在端口级别进行所有调优(重试为一个)，因此可以强大地调用Web服务.

I am writing a biztalk orchestration that will need to call a web service, probably multiple web services, and probably more than once. I see two options before me; one, consume the wsdl in a separate code project, and call the web services from code in an expression shape, and two, consume it from Biz, get schemas, etc and call through request/response ports. What is the best practice here? On the one hand, if the wsdl is updated it will be easier to update the code than the schemas and ports, and it seems like a lot of clutter and work to build ports enough for multiple web service calls. On the other hand, all the tuning you can do at the port level(retries being one) makes it robust to call web service.

推荐答案

也请参见此问题

Also see this question here, which discusses a 3rd option, viz using add service reference in BizTalk as an alternative method to import XSD's.

IMO，通过使用.NET代理来处理集成，您将无法使用BizTalk.例如:

IMO you would be defeating the point of using BizTalk by using .NET proxies to handle integration. For example:

1. 您正在对协议(WCF)进行硬编码，现在需要将自定义代码中的请求和响应消息封送给/.使用发送端口，可以在部署时配置任何请求-响应机制-特别适用于单元测试和集成测试.
2. 您将失去BizTalk消息传递机制的所有好处，例如重试，备份传输，恢复挂起的消息，不同端口的不同映射以及整个pub子功能(例如，如果多个侦听器想要收听来自被调用的Web服务的响应?)
3. 您将在哪里存储WCF serviceModel配置设置，例如端点等?即您已经失去了绑定文件的灵活性.
   • 等

1. You are hard coding the protocol (WCF), and now need to marshal request and response messages to / from your custom code. With a send port, any request-response mechanism can be configured at deployment time - especially useful for unit and integrating testing.
2. You will be losing all of the benefit of BizTalk's message delivery mechanisms, such as retries, backup transports, resume suspended messages, different maps for different ports, and arguably the whole pub sub ability, (e.g. what if multiple listeners want to listen to the responses from the called web services?)
3. Where will you store the WCF serviceModel config settings, such as the endpoint etc? i.e. You've lost the flexibility of binding files.
   • etc.

因此，TL; DR始终在BizTalk中使用WCF适配器

不过，也就是说，如果所使用的服务发生更改，则更新生成的项目可能会造成混乱. FWIW，我们减轻了部分负担，如下:

However, that said, am in agreement that updating generated items if the consumed service changes can be messy. FWIW, we mitigate some of this as follows:

• 始终创建一个单独的空文件夹，在其中导入所有 导入生成的工件.
• 按原样"保留所有生成的项目，即不要尝试移动虚拟.odx或将其删除(因为它具有预先配置的端口类型)

• Always create a separate, empty folder in which to import all the imported generated artifacts.
• Leave all the generated items 'as-is', i.e. don't be tempted to move the dummy .odx, or delete it (since it has the preconfigured Port Types)

不幸的是，这留下了以下仍需要手动执行的操作:

Unfortunately this leaves the below actions which still need to be manually applied:

• 如果工件在业务流程的单独组件中，请记住将端口类型的可视性更改为public
• 需要重新应用导入模式上的提升属性和专有属性(例如，记住在进行任何更改后记录屏幕截图).可以通过在schma的<xs:annotation>部分中保存并重新粘贴来简化或自动化该操作.
• 如果在WCF服务中使用消息协定，并且在多个应用程序中重复使用相同的引用消息，则需要手动删除由添加生成的项目创建的重复项，然后重新引用现有的架构. (例如，我们有一条标准的响应"消息返回所有BizTalk呼叫)

• Remember to change the visibility of the Port Types to public if the artifacts are in a separate assembly to your orchestrations
• Promoted and distinguished properties on the imported schemas need to be reapplied (e.g. remember to document screen shots after any change). Possibly this can be simplified or automated by saving and re-pasting in the <xs:annotation> section of the schma.
• If you are using message contracts in your WCF service, and are reusing the same referenced messages across multiple applications, you will need to manually delete the duplicates created by the add generated items and then re-reference the existing schemas. (e.g. we have a standard 'response' message back to all BizTalk calls)

这篇关于Biztalk和调用Web服务的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！