A lot of companies are thinking about moving their BizTalk implementations into Logic Apps. Microsoft recently unveiled a BizTalk migrator tool which can be used to generate the equivalent Azure iPaas components. One common scenario used in most BizTalk implementation is that the BizTalk schemas/orchestrations are published as wcf services and exposed to the outside world.

Now, there is a stark contrast between what BizTalk does and what Logic app does when we expose a service.

You can publish a BizTalk schema/orchestration as a service which supports SOAP or REST. By default, when you create a Logic App with a Http trigger, it publishes an API based on REST. However, you can send SOAP messages to a logic app endpoint by setting the Content-Type to application/soap+xml.

Exposing the BizTalk service to the outside world.

It’s pretty usual that BizTalk services are published via a load balancer as we will have multiple receive host instances. A load balancer can distribute the load and provide a single entry point into/out of the company network which can then be used in the firewall config to allow access outside of the network.

In the azure world, we can use Azure API management to expose the Logic apps to the outside world and thereby securing direct access to the logic apps.

Where is the wsdl?

To bring down the project implementation cost, some companies would not prefer making any changes to the other systems (which consume the BizTalk service) as a result of changing the middleware from BizTalk to Logic Apps. If the source system is either based on .net or java for instance, they would have already generated boiler plate code using the BizTalk wsdl. Now, to make this all work, the integration project team has to do just this

  • Create a logic app
  • Create azure APIM and add the logic app created in the previous step as an API.
  • Provide the API path to the source system
  • The source system changes the endpoint in their application config.
  • And, voila it’s that simple. They never need to consume the wsdl as the boiler plate code is already generated for them.

But sometimes things are not really easy. In my case, the source which consumed the BizTalk wcf service was coded using apache cxf framework. Instead of using the boiler plate code which was generated using the previous biztalk wsdl, it tried to access the wsdl from the api management endpoint. But hold on! The Logic App exposed via APIM doesn’t have a wsdl underneath.

If you see the below java code, it tries to build the run time components using the wsdl from the api endpoint, which doesn’t exists. As a result, the code will fail.

public final static QName WSHttpBindingITwoWayAsync = new QName("http://tempuri.org/", "WSHttpBinding_ITwoWayAsync");
    static {
        URL url = null;
        try {
            url = new URL("https://xxxx.azure-api.net/api/oasis/salesinvoice?wsdl");
        } catch (MalformedURLException e) {
            System.err.println("Can not initialize the default wsdl from https://xxxx.azure-api.net/api/oasis/salesinvoice?wsdl");
            // e.printStackTrace();
        }
        WSDL_LOCATION = url;

So, how should we go about resolving this? In our case, the project team didn’t want to make any changes on the source system other than changing the endpoint. To resolved this, I put in an additional GET route on the API which would render the wsdl data.

A GET operation was added to the existing api. I added a mock response data on this operation. Finally, I enabled mocking on this operation and linked this response.

Now, when you send a HTTP get on the endpoint, the API would return the wsdl response.

Conclusion

I am pretty sure, a lot of folks out there would soon be in a pretty similar situation like mine. So, hopefully this post would help them resolve this in a way where you wouldn’t need to write any code.

Visits: 297

0 0 vote
Article Rating
Subscribe
Notify of
guest
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Aastha K

Glad to see an article on BizTalk migrations to Azure Logic Apps. We are in the process of migrating to Logic Apps as well. So looking forward to reading more of these.

2
0
Would love your thoughts, please comment.x
()
x