One of the key challenges that users face while using Logic Apps is managing secret values. This used to be handled by passing the secrets through ARM templates, which is not an out of the box solution.

Before the availability of the Key Vault connector in Logic Apps, one of the ideal workarounds was using an HTTP action available in logic apps and leveraging the Managed Identity authentication mode. Even this workaround has a few considerations as follows:

1. Logic App run history contains the secret values which cannot be hidden
2. Currently, we can only have 10 logic apps that have system-assigned managed identities

Let us explore how to better protect your secrets in your Logic Apps using the new Key Vault connector. Also, I will show you how the above issue can be addressed with the Key vault Connector.

Design your sample Logic App

Follow the steps below to create your sample logic app in the designer page.

1. Add an “Http request” trigger to the logic app. Later we will call this logic app via a rest client.

2. Then, search for the key vault actions and add the “Get Secret” action to the logic app. Now, you have a couple of options here to authenticate: either you can use Azure AD or Service Principal. In this example, I am going ahead with Azure AD service.

3. Sign-in with your account. This account should have enough permission to access your Key Vault. Otherwise you should manually provide access through Access policies.

4. Fill in the required field with the “”. If you don’t already have one in place, then you can create one by heading to the Key Vault menu. There you can find the “secrets” option in the left pane.

Note: If you are provisioning the Key Vault itself for the first time, then remember: sometimes you may need to register the Key Vault service to your Subscription manually. (I encountered this issue when I did it for the first time).

5. Now, add the “Http response” action to the logic app. Fill in the following fields as below:

Status Code: 200
Body:

6. Save the Logic App.

Testing the Logic App

Now, copy the HTTP post URL from the Logic App trigger and head to reqbin (online REST client). Paste the URL in the address field and change the default method from GET to POST and click Send.

The logic app would have gotten triggered and sent back the response code 200 along with the secret value as shown in the picture below.

Inspecting the Run History

On inspecting the run history of the logic app, we notice that the secret values are visible in plain text.

Do you remember the same problem we encountered in the classic method? As I have already said this can be easily addressed through the Key Vault connector settings by following the below steps:

1. Head back to the designer and click on the settings option under the “more options” menu in the Key Vault connector.

2. Now, in the settings for “Get Secret” action, enable the Secure Inputs and Outputs option and click Done.

3. Once again save the logic app and call it through the rest client (reqbin.com). You will get the same response in the Request Bin, but the run history doesn’t contain the secret values in the plain text format. Rather it shows as “Content not shown due to security configuration”.

We have now addressed the first concern in the classic method. The second concern was that we can only have 10 logic apps that have system-assigned managed identities.

We have also overcome this issue by not using the Managed Identity mode of authentication in the connector. Rather it authenticates through Azure Active Directory or Service Principal (which has a downside of rotating secrets, though).

Once the user gets enough permissions to the Key vault through Access Policy they will be able to access the Key Vault in any number of Logic Apps.

Expanded Feature Set

While digging more into the Logic Apps Key Vault actions, I found some more interesting use cases that can be achieved through Encryption and Decryption actions.

If the user is more concerned about their data, then they can use the Encryption and Decryption action to keep the values more secure.

To do this, create an encryption key in the Key Vault.

Using the Encrypt and Decrypt actions in the Key vault connectors you can encrypt the data and decrypt it again. As seen above, we can even enable the Secure Inputs and Outputs option in the settings to make it more securable.

Manage and Monitor Logic Apps using Serverless360

Serverless360 is one platform to manage and monitor all your Azure Serverless resources with focus to help your operations and support your team on a day to day basis.

Consider the above workflow of a business application defined using multiple Azure Logic Apps.

Different stakeholders of the business application will have different needs as they manage and monitor the Azure Logic Apps.

Some key requirements which are hard to achieve through the Azure portal are:

• auto-correcting the Logic App state when found to be not as expected
• instant reflection of the warning and error state of the Logic App in a service map view
• near real time detection of failure
• automation in re-submission of specific failed run actions
• end to end tracking on the message flowing through the Logic Apps, and
• evaluation on the consumption, performance and reliability.

These requirements cannot be achieved directly through the Azure portal. But Serverless360 can come in as a complement to the Azure portal, as it is crafted with capabilities to address the gaps in the Azure portal.

Service Map in Serverless360

Wrap-up

In this blog, we have seen the classic and latest methods of protecting your secrets in Logic Apps. Also, I hope this blog has given you a clearer understanding of the Key Vault connector that is now currently available.

Lastly, I have covered the extended feature sets of the Logic Apps Key Vault connector, Encryption and Decryption actions.

I hope you enjoyed reading this article. Happy Learning!

This blog gives an overview of how Azure Serverless technologies came to rescue when the custom-built integration system went down. Also, it shows the high-level architecture solution built using Azure Serverless services like Logic Apps, Service Bus Queue and Topics, etc to replace the legacy system.

This article was originally published at Serverless360.com

How it all Started?

About three years ago, Northwind, a company who runs their business in B2B space wanted to extend its business to B2C. So, the company wanted to open a Web Shop (SaaS). Since it was a B2B specialized company there were no warehouse and transport service to serve the customers effectively. The company chose to go ahead with LSP (Logistics Service Provider) instead. The legacy system was built using a middleware to connect the Web Shop and the LSP. Later, the legacy system was integrated with the email system. The complexity of the system increased as several branches (Web shops) opened across the globe.

One day, the whole system went down, and the company started losing hundreds of orders. Then, the company approached an expert team to fix their middleware.

Requirements to be considered

• Stability – the system needs to be stable enough to handle a lot of orders.
• Monitoring – the system should be monitored to alert the operation personnel when something goes wrong.
• To handle 10,000 orders per hour.
• New SaaS webshop

The Solution

The expert team replaced the middleware using Azure serverless technologies. Predominantly, Logic Apps and other Serverless entities like Azure Functions, Service Bus Queues and Topics were used. The stateful middleware was changed to stateless using event-based approach.

What is Serverless?

The abstraction of server, platform, and runtime – There is no need to provision or maintain any servers. There is no software or runtime to install, maintain, or administer.

Event-driven scaling – This is one of the important characteristics of Serverless, you shouldn’t worry about scaling your solution if demand arises.

Micro-billing – When your code is executed you pay per execution. Typically, the vendors calculate this based on memory consumption and the time it takes for the execution.

Advantages

Manage apps not servers – The significant advantage of serverless is that the user does not manage the servers, but the cloud service providers do.

Reduced DevOps – It reduces the DevOps cost as the infrastructure is maintained by CSP.

Faster time to Market – It reduces the time to market as serverless technology screens the ground works and lets the developer focus on the logic.

Azure Logic Apps

You can run a business workflow in Azure using the Logic App service.

The Logic App is a logical container for one workflow you can define using triggers and actions. A trigger can instantiate a workflow, which can consist of one or many activities (actions). For instance, you can trigger a workflow by sending an HTTP request or schedule a workflow every hour to retrieve data from a public website. There are 200+ out-of-the-box connectors available for enterprise integration.

Benefits

• Out-of-the-box connector reduces the integration challenges
• Connect and Integrate data from the cloud to on-premises
• B2B and enterprise messaging in the cloud
• A powerful web-based workflow designer

Pricing of Azure Logic Apps

The pricing is very simple. It works on the pay-as-you-go model, it would cost you only a few nickels. For instance, if you process 1000 service bus messages a day, with a workflow of five actions it would cost you EUR 4.62 approx. To execute a normal action, it would cost $ 0.000025 and for a Standard connector, it would cost you $0.000125. Even, the Enterprise connector would cost you only $0.001. For more information see the pricing page here.

Basic Architecture Solution

Initially, there is a webshop connected to Webshop publisher Logic App through Webhook. The Webshop publisher Logic Apps act as the orchestrator for the workflow. The data from the Webshop is converted into Canonical entity and passed to the Canonical Order Mapper Logic App. Subsequently, the control flows to the CE publisher where the translation of the object happens. Then, the translated object is sent to Service Bus Topic. Topic Subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. Get to know about Topic Subscription rules here. Based on the filter, the orders are sent to LSP Subscriber and MS (Marketing System) Subscriber.

Impressive Scalability of Azure Logic Apps

On running the above workflow, it could process 73,120 orders in 20 min. Every order would get processed in less than 3 seconds and the success rate was above 98 percent. The above log shows that there were 73,120 runs completed and out of which 72,972 runs were accomplished and 148 runs were failed.

View of Entities in a Resource Group

The above picture represents how the entities will be listed in a Resource Group. For better management of the entities use the Display Name tag. It helps the user to debug the workflow in case of failure.

Webshop Publisher Logic App

Out-of-the-box, there is an HTTP trigger which initiates the Logic App and sends 201 response directly for the received message. 201 response represents that request has been fulfilled and has resulted in one or more new resources being created. Subsequently, sends the order message to the other Logic App (Map order to Canonical order) and to Publish canonical order.

Tracked properties

In “Response 201 directly” action, the following properties are tracked

• Customer Email
• Flow
• Order ID
• Shop ID

Canonical Order Mapper

The Logic App gets triggered by receiving the HTTP request. Then, the message would be passed to Data Operation actions to compose canonical order items and create shop reference data. Subsequently, composes the canonical order using Data Operation action and sends back the response.

Service Bus Explorer

For easy management of the entities use Service Bus Explorer. It provides filter option for Service Bus Topic using which the message can be sent to the defined subscriptions (LSP). The message will be filtered based on the properties defined in the Service Bus Topic. Here is how Serverless360 makes a better option for Service Bus Explorer.

Monitoring

The above picture shows the Log Analytics dashboard. It provides a graphical representation and monitoring capability for the entities associated with the Log analytics. Inside the Log Analytics, the user can run powerful quires and inspect the database if something goes wrong.

Demo – order paid

To test the new solution architecture, send the test order, use the Postman tool to send a POST message to the Logic App. On sending the successful order, you can see the 201 response at the bottom left corner of the Postman tool. On receiving the order, the Logic Apps gets triggered and finally, the order message would reach any one of the respective LSP.

CI/CD pipeline

The above picture represents the CI/CD pipeline architecture. There are three blocks namely Developer context, Azure DevOps and Azure subscription. The Developer context contains PowerShell, IDE’s, etc. Once the developer checks in the code, it commits to the repository. On switching the Build option, build pipeline deploys the code to the Blob storage. Once Build pipeline is done with the work, Release pipeline kicks off and tells the ARM to reflect the changes in Development, Testing, and Production environment.

Benefits

• No manual steps required to deploy the code.
• Quality control can be done
• The organization can have a bigger development team

Challenges

• A lot of housekeeping is required around ARM templates.
• Things get complex if any ARM template goes down. Because the failure can be spotted only during release.
• The rhythm of the service changes rapidly

Key Takeaways from the Above Solution

• Faster time to market: There were only three developers and they could get the project done within 3 months.
• Resilient and scalable: As we saw above the application was highly scalable. It could handle about 73 thousand orders in 20 minutes.
• It is best suitable for business-critical systems

This blog is an extraction of the session “Black Friday? Logic Apps to the rescue” presented by Aarjan Meirink at MSBuild 2019.