Biztalk and the best way to call a web service

Question

I am writing a biztalk orchestration that will have to invoke a web service, possibly several web services, and possibly more than once. I see two options in front of me; one, consumes wsdl in a separate code project and calls web services from code in the form of an expression, and two, consumes it from Biz, receives schemas, etc. and calls through the request / response ports. What is the best practice here? On the one hand, if wsdl is updated, it will be easier to update the code than circuits and ports, and this seems like a lot of interference and the work of creating ports sufficient for several calls to web services. On the other hand, all the settings that you can do at the port level (try again) make it reliable for calling a web service.

Answer 1

Also see this question here , which discusses the third option, namely: add service reference in BizTalk as an alternative XSD import method.

IMO, you would defeat BizTalk's point of use by using .NET proxies to handle integration. For instance:

• You hardcode the protocol (WCF), and now you need to marshal requests and response messages to / from your user code. Using the send port, any request-response mechanism can be configured during deployment — especially useful for installation and test integration.
• You will lose all the benefits of BizTalk message delivery mechanisms, such as retries, standby transports, resumed paused messages, different maps for different ports, and possibly the entire collection of pubs (for example, what if several listeners want to listen to answers from called web services? )
• Where will you store WCF serviceModel configuration serviceModel , such as endpoint, etc.? those. You have lost the flexibility of linking files.
  • etc..

So TL; DR Always use WCF adapters in BizTalk

However, I agree that updating the generated items occurs if the consumed service changes can be messy. FWIW, we soften this a bit:

• Always create a separate empty folder into which you want to import all imported artifacts.
• Leave all the generated elements “as is”, that is, do not try to move the dummy .odx or delete it (since it has pre-configured port types).

Unfortunately, this leaves the following actions that still need to be applied manually:

• Remember to change the port types to public if the artifacts are in a separate assembly for your orchestrations
• The advanced and highlighted properties of imported circuits must be reapplied (for example, remember to print screen shots after any changes). Perhaps this can be simplified or automated by saving and re-pasting in the <xs:annotation> section of the shift.
• If you use messaging contracts in your WCF service and reuse the same referenced messages in multiple applications, you need to manually remove duplicates created by adding the generated elements, and then re-link to existing schemas. (for example, we have a standard response message to all BizTalk calls)

Answer 2

Interestingly, you can have a mixture of both infact. Mark this one from Saravana Kumar !!!

It uses end-to-end reception and consumes a web service using a DLL on the send port, without the pain of creating diagrams and websites.

This gives all the power of Biztalk (response to routing, port forwarding configuration, etc.) and still the flexibility to change the circuit without any problems.