When we work for a service integration project for a customer’s information systems, not all systems use cutting-edge technologies. Rather, still many information systems use legacy ways to get integration works done. For example, some legacy applications still drop files to a designated folder so that other applications pick up those files periodically. On the other hand, other legacy applications support SOAP (Simple Object Access Protocol) based webservices. In .NET world, we can easily handle those SOAP webservices through WCF by creating service references. Now, everything has changed. We use Azure API Management, Logic Apps and Functions for service integration more than ever.

SOAP over API Management and Logic Apps

API Management supports SOAP out-of-the-box using WSDL. However, we have to know that API Management has some restrictions of using WSDL. In other words, some SOAP-based webservices having complex structure might not be suitable for using API Management.

What about Logic Apps? If we create a custom connector and import WSDL through it, we can use SOAP webservices directly from the Logic App instances. However, there are still concerns around Logic Apps using SOAP-based webservices. As it uses API Management behind the scene, it has same restrictions that API Management has. Moreover, Logic Apps’ customer connector itself has limitations. Therefore, this also needs to be considered, when we design our integration architecture.

Then we have the last one standing – Azure Functions. It’s basically C# code, so we can easily refer to service references, which looks perfect. Let’s have a look.

The sample code used for this post can be found here.

Analysing Service References

When we create a service reference proxy, it contains service client class inheriting ClientBase. It also has several constructors taking no parameter, string parameters and instance parameters.

Except the first and last constructors, all other constructors take string parameters for binding and endpoint information, which are stored at Web.config or App.config. In fact, the configuration file looks like:

Both basicHttpBinding and endpoint nodes are used for setting up the WCF service client. That’s actually not possible for Azure Functions, because it doesn’t have Web.config file! Wow, that’s a kind of critical to use WCF in our Azure Function code, yeah?

Fortunately, the last constructor of the service client accepts both Binding instance and EndpointAddress instance for its parameters. In other words, as long as we can create both instances and pass them to the service client as dependencies, we can still use WCF service references without the Web.config file.

SOAP over Azure Functions

Let’s have a look a the function code. We should note that there are binding and endpoint instances to instantiate WCF service client. This doesn’t require the system.serviceModel node at Web.config, but only needs the actual endpoint URL that is defined in the application settings blade of the Azure Functions instance (equivalent to local.settings.json at our local development environment).

Based on the connection type, both binding instance and an appropriate BasicHttpSecurityMode value should be carefully chosen. In addition to this, if necessary, user credentials like username and password should be provided from app settings.

Once we implement this and run it, we can get an expected result like:

Service Client as Singleton Dependency

Now, we can send requests to SOAP webservices through Azure Functions. There’s one more thing to keep in mind, from the implementation design perspective. As we can see, the WCF service client is just a proxy and majority of SOAP applications are monolithic. In other words, the service client is reusable over time so that it’s always a good idea to register it within an IoC container, as a singleton instance. I have written many posts for dependency management in Azure Functions and this is the most recent one that is worth checking. Therefore, with this approach, the service client instance can be registered as a singleton and injected to functions, if necessary.

Which One to Choose?

So far, we have discussed which Azure service is good to handle SOAP webservices. Here’s a simple chart for comparison:

• Azure Logic Apps has a connector limitation – number of connectors and number of requests per connector. So frequent access to SOAP webservice through Logic App wouldn’t be ideal.
• Azure API Management has restrictions on complex SOAP message structure. As Azure Logic Apps relies on API Management, it also has the same restrictions.
• Azure Functions doesn’t have a concept of connector and can directly use WCF proxy libraries, so it has virtually no limitation but requires heavy-lifted coding efforts.

From these perspective, we can choose an appropriate one for our integration application structure. So, have you decided what to choose?

This has been cross-posted to Dev Kimchi.

After posting this, Darrel Miller from Microsoft left comments worth noting:

Therefore, hopefully in January 2018, we might be able to expect something very exciting stuff around API Management and Logic Apps!