It is an exciting time in technology, the cloud offers many possibilities that were simply not possible a few years ago. Microsoft Azure enables the quick development of integrations and applications without the worry, cost and timescales of infrastructure and even without code.
Azure Service Overview
Azure offers the building blocks to build applications that can allow integration and reuse of functionality. Linking systems with customers, suppliers, Cloud and on-premise systems. Connections to PaaS and SaaS and offerings including Dynamics 365 with additional extensibility.
The difficulty is deciding which solution or combination of solutions to use and in which circumstances. This blog hopes to give a brief explanation of some of the different offerings, how they work, the advantages and dis-advantages.
We are going to discuss Logic Apps, the Azure App service, Azure functions, Webjobs/WebJobs SDK, PowerApps and MobileApps.
Azure Logic Apps
Logic apps are aimed at developers primarily for advanced integrations, they can be developed in Visual studio or within the browser using a visual designer. They allow server-less workflows which consist of a number of steps called actions, generally Azure logic apps are used to complete a complex task, for example processing a batch of invoices.
Apps are developed using a designer GUI , or code and are administered through the Azure portal. There is another product called Flow which is similar but aimed more at power users. Flow is built on Logic apps.
Logic Apps can talk to either Cloud or on-premise systems, via a data gateway.
Logic apps can connect to existing API’s & Web Apps.
Logic apps can be parameterised to allow deployment to multiple environments. This can be done via Visual studio, if they are developed in the Azure portal they will need to be exported prior to parameterisation, this can be done via a Logic App template creator which is available on Github, this exports them so they can be included in an Azure Resource Group project.
API Management can add telemetry and rules to handle requests.
There are many built in connectors, more are being released on a continuous basis:
There is also a section in Azure to request new ones.
Leveraging the Azure service bus messaging you can subscribe to or publish messages with topics. You can use Peek-Lock (Retrieves and locks a message so other receivers don’t try to process the same message), Auto-complete, with a high throughput and immediate triggering.
Messaging is Asynchronous over queues and handling capabilities allow for different contents, i.e JSON & XML, Validation. Built-in conversion from flat files, CSV delimited, EDI (X12, EDIFact – OOB Schemas), with batching capabilities. Mapping can be achieved via XSLT using Visual studio mapper. Error handling includes retry policy, run after and terminate.
There are a number of generic triggers available as well as a few Dynamics 365 Customer engagement entity change and service bus triggers. Dynamics 365 for operations triggers are not currently available.
There are a number of actions available for both Customer engagement and Operations as well as standard actions allowing to invoke services, retry policy, request handling, message composition and flow control.
Azure Web Services
The Azure app service is an offering from Microsoft allowing you to create applications without the worry of dealing with infrastructure issues, it can be developed using your preferred language (as long as it is .net, Node.js, PHP, Java, Python or HTML). It is supported in both Windows and Linux, offers scalability and deployment is possible using GitHub, VSTS or any GIT Repo.
Both Azure functions and WebJobs are built from the Azure App Service and although both have their place in certain circumstances they have different features and options.
Azure functions are built using Azure app Service and Webjobs SDK.
Work can be offloaded from Dynamics 365 which can help with sandbox limitations, this can either be done via published events or by a schedule.
With Visual studio 2017 functions can also be edited, also Nuget packages can be referenced..
Unlike Logic apps which can only be run in the cloud, they can be run in the cloud or locally using the Azure Function core tools.
Using the Durable functions extension you can write stateful functions in a server-less environment
Azure functions can be exported to PowerApps and Flow and you only pay for what you use.
Functions can be called from Dynamics 365 for Operations via a C# Proxy class library via X++ Code.
Webjobs, like Azure functions are built on the Azure app service, and run as a .net console application, they are aimed entirely at developers being a “code first” service.
The idea of WebJobs is that they are triggered by an event in Azure services. It is best to run WebJobs and WebJobs SDK together, but this is not essential, both can be used independently.
Flow, Logic apps, Azure functions, WebJobs & WebJobs SDK
It is not necessarily that one is better than the other, although Azure functions offer the most flexibility, options and pricing, developments written in one service or another can be called from either Functions, WebJobs Logic apps or Flow.
PowerApps is part of the Microsoft Office 365 offering allowing the creation of apps which can be used on mobiles as well as on the web. They are created with no code.
They are developed within PowerApps studio and published within the PowerApps Cloud, generally they are used within your organisation.
Different connections can be established within PowerApps, standard as well as customised, this means as well as standard connections such as Common Data Service (CDS), Sharepoint, SQL Server, Dynamics, Flow & Logic Apps (There are many more), you can also create custom connections such as using OpenAPI or the Postman collection.
When PowerApps is used in conjunction with CDS this is aimed at the power user, whereas when it is used in conjunction with an SQL Azure or other heterogenous database this is aimed a developer. In this case Business logic comes from Stored procedures
Data Integrator Architecture possibility with Common Data Service.
With the arrival of Power Query many more data sources are now available. Power Apps can call Azure Functions.
Dynamics 365 for Operations Mobile Apps
Mobile apps are an extension of Dynamics 365 for operations, they allow the quick design and deployment of apps that can be used to perform simple tasks or to get information from D365O.
There is a mobile shell application available in Android & IOS, where workspaces created within D365O can be published to.
Fields from a particular form can be selected for use in the app.
Actions can be recorded and added to the workspace such as Save, delete etc. The workspace is then published and is available on the Mobile shell app, Microsoft Dynamics 365 for operations Unified operations.
Once the user is connected to the environment URL all published workspaces are available within the app.
These workspaces can be exported as XML files for easy movement around environments.
There is support for offline working, the app will accept changes and then synchronise when a connection is available
PowerApps vs Dynamics 365 for Operations Mobile Apps
When developing apps specifically for D365O Mobile Apps has the advantage of understanding the D365O Schema, it can leverage business logic from D365O and provide very rapid design and deployment of workspaces within the shell app by Power users. It has Out of the box offline support and uses the D365O security framework to deal with user authentication as well as data access.
However, the functionality is limited and there are certain things that you cannot do, such as calling data or functions from other systems or Azure. Mobile Apps only really work as a mobile offering whereas PowerApps can be used on a mobile as well as the web.
This matrix shows some of the differences between D365O Mobile Apps and Power Apps.
Azure Web Apps
Azure web apps are a particularly good option when a customer/supplier facing site might be required that will interact with Dynamics 365. Web apps are not limited to integrations, they can be full on mission critical web applications run either in the cloud or on-premises, they still take advantage of Azure services such as security, performance, load balancing, scalability, connectors to 50 SaaS platforms & Data, templates, API , staging and serverless code.
Web Apps are aimed a developers, they are developed in Visual studio and can be .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python.
Azure web apps are developed in Visual studio, where live debugging, log streaming, provision and manage etc are available SSL and custom domains can be used.
There is a good development cycle with support from mobile back-end services.