This post was originally published here

If you come from BizTalk and have an integration background like me, you may remember that we had a Loopback Adapter in BizTalk Server.

The Loopback adapter is a two-way send adapter that, in essence, returns a copy of the outbound message back to the caller, in most cases, an orchestration. This capability can be used in several situations or scenarios:

  • One is to replace the need to call pipelines inside an orchestration. Calling pipelines inside orchestrations is a good option, but it complicates the logic of the orchestrations with loops and expressions. You’ll also end up repeating the “code” for each message type/orchestration.
  • Or have a way to invoke a party/agreement to get more details in the message.
  • Using Loopback adapter to subscribe NACKs off Web Services.
  • And so on.

However, while trying different implementation strategies using Azure Integration Services, I realize that the use of a Loopback API is also very handy.

Are you wondering where you can use this component or strategy?

In many different ways like:

  • If we need to do a liquid transformation inside Logic App Consumption, we need to have an Integration Account, which is expensive. Instead, we can expose an operation in API Management to perform a liquid transformation. For that, you will need the Loopback API.
  • Throwing an exception inside Logic Apps. There are many ways to archive these capabilities. One of the options is again exposing an operation in API Management to throw back the exception. For that, you will need the Loopback API.

And so on.

Soon I’m going to publish some of these implementation strategies.

For now, I leave you the Loopback API code for you to try and provide feedback.

Loopback API Azure Function

The Loopback API is simply an Azure Function that, in its essence, returns a copy of the inbound message/request back to the caller. We can say that this Azure Function mimics the Echo API, which comes by default in the API Management,

You can download the complete code for the function from GitHub. The link is below at the bottom of the blog post. Here is a small code snippet:

        public static async Task Run(
            [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            //dynamic data = JsonConvert.DeserializeObject(requestBody);

            string contentType = req.Headers["Content-Type"];

            return new ContentResult { Content = requestBody, ContentType = req.Headers["Content-Type"] };

Where can I download it

You can download the complete Azure Function source code here:

Once again, thank my team member Luis Rigueira for testing these concepts with me!

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira