How to Run a Manufacturing Facility Using the One Microsoft Cloud

Thank you to April Dunnam, Greg Hurlman, and Matt Soucoup for their contributions to this post, Microsoft Learn Path and eBook.

Scenario

There is a factory that makes boxes. A key activity is cutting large sheets of cardboard into the standard sizes needed to make these boxes. The factory has several lathes doing this cutting work across several factories around the world. The company partners with a set of vendors to provide replacement blades and service the lathes when they need repair or replacement.

Everybody in the factory, from the tech team to the floor workers, collaborates and communicates using Microsoft Teams. The team also tracks the productivity of the cutting lathes using Power BI. The Power BI report shows production outputs from the last 24 hours – monitoring both good and reject boxes across the company and for each factory location.

A Standard Manufacturing Challenge

One day, the Chief Operations Officer notices a high number of rejects on one of the lathes. He assigns a work item to the Factory Floor Manager to investigate. The Floor Manager checks the machine and realizes the lathe will need to be serviced soon.

A New Kind of Solution

Rather than calling all the vendors the factory contracts with to gather quotes and schedule service, then manually keep track whether a lathe has been scheduled for service or not, and the service history the Floor Manager wonders if there’s a better way.

The Floor Manager sits down with the tech team and tells them her predicament:

Every time the Chief Operations Manager notices an issue with a lathe, he asks her to investigate. This could mean checking on the lathe directly or contacting a colleague via Teams to do it. Depending on the findings, she may end up calling many different vendors to schedule repairs for the lathe. She also must keep a log of the lathe repair service history. And coordinate with Floor Managers from factories around the world who do the same thing.

With all the hand-written work this process has introduced errors before.

The Floor Manager, and her counterparts in the other factories around the world, have an idea of what the application should look and act like to best fit into their day-to-day workflow.

The tech team tells the Floor Manager they can create a web API that interfaces with various vendor systems to schedule service. And APIs to record all service history and mark whether a lathe is currently in production or not.

Using that info, the Floor Manager knows she can create an app using Power Apps that will reside in the existing Power BI dashboard. That app will do exactly what she wants, and it will work exactly to her specific workflow – because she designed and created it for her exact needs.

This Fusion Development Team of high-code, or professional developers and low-code, or citizen developers get down to work.

High-Code / ProDev Architecture

The high-code or professional developer team will create a web API that performs the following actions:

• List all the company’s factories worldwide.
• List all the lathes at a single factory.
• List all the lathes of a particular type at a single factory.
• List all the vendors contracted to perform repairs.
• Schedule a repair for a lathe with a vendor.
• List repair history for an individual lathe.
• Mark an individual lathe as being out-of-service or in-service.

The tech team has decided the following cloud infrastructure will best suit their needs:

ASP.NET Core Web API to serve as a REST service for the actions listed above.

• Azure Cosmos DB
• Azure App Service
• Azure API Management
• A Custom Connector that facilitates communication between Azure API Management and Power Apps.

The team decided on ASP.NET Core because of the flexibility it gives them to build applications quickly using Visual Studio, .NET, and the entire .NET ecosystem. Including robustly documenting the APIs with OpenAPI, making it easier for downstream developers to use the app.

Azure Cosmos DB is a robust, globally scalable NoSQL database – perfect for the team’s needs to store lathe machine information from across the globe. And there’s a .NET SDK available so the ASP.NET Core web API can integrate smoothly with it.

Instead of hosting the ASP.NET Core web API locally, the team has decided to use Azure App Service. This gives them the ability to scale the app on demand, use the latest security technologies, and have enterprise-grade performance all without having to worry about infrastructure.

The team uses Azure API Management to bring their web API to the next level. It provides tools to monitor, secure, and most importantly share their APIs.

Azure API Management uses the ASP.NET Core web API deployed in Azure App Service and presents a public interface for all API requests.

And the Custom Connector is the way in which the tech team will share their ASP.NET Core web API with the citizen developers and Power Apps.

The Custom Connector is made by exporting an OpenAPI v2 (v3 not ready yet) document from Azure API Management and then importing it with the Power Apps tooling. Once done, the API is ready to use within Power Apps.

Low-Code / Citizen Dev Architecture

The low-code or citizen developer team will create an app with Power Apps that performs the following actions:

• Groups the machine data into locations for navigation.
• Allows the user to choose a particular machine and see that machine’s data.
• Lists the service order history for a machine.
• Allows the user to create a new service order from the machine detail screen.
• Allows the user to choose a vendor for the new service order from all the vendors contracted to perform repairs.

The team has decided the following data integrations and connections will best suit their needs:

• Gets all the initial data the app needs directly from the Power BI integration.
• Uses the custom connector to get the approved vendor list.
• Uses the custom connector to get service order history and create new service orders.

The team decided to use the built-in Power BI integration to prevent having to call the custom connector for data already loaded into the Power BI report, and doing so will allow the Power Apps app to actively filter the data it shows when the report user filters the page—for example, by clicking on another Power BI visualization.

The custom connector makes it easy to work with the internal systems, as it works just like the standard connectors. The team makes a few simple changes to the custom connector’s action names, so that they are more user friendly and present themselves with the same look and feel as the standard connectors.

Resources

Demo Video
The following video shows this scenario using Microsoft Teams with an embedded Power App using the custom connector to extend its capability.

Microsoft Learn Path
Learn how your software development skills apply in a low-code environment and how you can empower citizen developers using Power Apps, web APIs, and Azure API Management. (aka.ms/fusiondevpath)

FREE eBook 
The Fusion Development Approach to Building Power Apps  (aka.ms/fusiondevbook)