Azure Training TFT - Function App & Logic App

Your Trusted Analytics and Planning Partner
Function App & Logic Apps
TekLink International Confidential 1

Course Objectives
 Introduction to Azure Function App – Serverless Platform

 Understand Azure Functions and Function App
 Development of Function App & Azure Functions in portal and in
local environment
 Function App runtime
 Environment Variables in Azure Function
 Hosting Plans in Azure Function
 Triggers & Binding
 Understand Logic App

Unit 1:
What is Azure Function App & Azure
Function

Unit 1: Objective
After completing this unit, you will be able to:
 Understand Azure Function – A Serverless Application Platform

 Understand What is serverless
 Benefits of serverless compute
 Drawbacks of serverless compute
 Understand what is Azure Function
 Understand Azure Function Features
 Azure Function Components
 Understand when to use Azure Function
 Understand what is Function App

Azure Function – A Serverless Application Platform
 When designing a service with traditional enterprise architecture strategies, you would need to consider server
infrastructure and maintenance up front: scope out necessary hardware, plan to install it, coordinate with IT to
manage it, and so on. An alternative to all that work is serverless computing. With serverless computing, your
cloud provider manages the provisioning and maintenance of the infrastructure letting you focus completely on
building the app logic.
 Azure Functions is a key component of the serverless computing offering from Azure and enables you to run
pieces of code or functions, written in the programming language of your choice, in the cloud.

What is serverless compute?
 Serverless compute can be thought of as a function as a service (FaaS), or a microservice that is hosted on a
cloud platform. Your business logic runs as functions, and you don't have to manually provision or scale
infrastructure. The cloud provider manages infrastructure. Your app is automatically scaled out or down
depending on load.
 Azure has several ways to build this sort of architecture. The two most common approaches are Azure Logic
Apps and Azure Functions, which is the focus off our training.

Benefits of serverless compute?
 Avoids over-allocation of infrastructure

Suppose you've provisioned virtual machine (VM) servers and configured them with enough resources to handle your
peak load times. When the load is light, you're potentially paying for infrastructure you're not using. Serverless computing
helps solve the allocation problem by scaling up or down automatically, and you're only billed when your function is
processing work.
 Stateless logic
Stateless functions are great candidates for serverless compute; function instances are created and destroyed on demand.
If state is required, it can be stored in an associated storage service.
 Event driven
Functions are event driven. They run only in response to an event (called a "trigger"), such as receiving an HTTP request,
or a message being added to a queue. You configure a trigger as part of the function definition. This approach simplifies
your code by allowing you to declare where the data comes from (trigger/input binding) and where it goes (output
binding). You don't need to write code to watch queues, blobs, hubs, and so on. You can focus purely on the business
logic.
 Functions can be used in traditional compute environments
Functions are a key component of serverless computing, but they're also a general compute platform for executing any
type of code. Should the needs of your app change, you can take your project and deploy it in a non serverless
environment. That gives you the flexibility to manage scaling, run on virtual networks, and even completely isolate your
functions.
Drawbacks of serverless compute?
 Execution time
By default, functions have a timeout of five (5) minutes. This timeout is configurable to a maximum of 10 minutes. If your function
requires more than 10 minutes to execute, you can host it on a VM. Additionally, if your service is initiated through an HTTP
request and you expect that value as an HTTP response, the timeout is further restricted to 2.5 minutes. However, there's also an
option called Durable Functions that lets you orchestrate the executions of multiple functions without any timeout.
 Execution frequency
Another characteristic is execution frequency. If you expect clients executing your function continuously, it would be prudent to
estimate the usage and calculate the cost of using functions accordingly. It might be cheaper to host your service on a VM.
While scaling, only one function app instance can be created every 10 seconds, for up to 200 total instances. Keep in mind, each
instance can service multiple concurrent executions, so there's no set limit about how much traffic a single instance can handle.
Different types of triggers have different scaling requirements, so research your choice of trigger and investigate its limits.

What is Azure Function
 Azure Functions is a serverless solution that allows you to write less code, maintain less infrastructure, and save on
costs. Instead of worrying about deploying and maintaining servers, the cloud infrastructure provides all the up-to-
date resources needed to keep your applications running
 Azure Functions is a cloud-based compute service. Functions provide event-driven and scalable serverless compute
for Azure. In some cases, you’re only billed for the time your function code runs.
 You can use Azure Functions to run your code when you need it to run. For example, your code can run as the result
of an event or change, such as when a message arrives in a queue or when a stored object is updated. You can also
use CRON rules to define a scheduled interval for your code to run.

Features
 Use your preferred language:

Write functions in C#, Java, JavaScript, PowerShell, or Python, or use a custom handler to use virtually any other language.
 Flexible pricing options:
With the Consumption plan, you only pay while your functions are running, while the Premium and App Service plans offer
features for specialized needs.
 Dynamic scaling.
In most plans, functions are dynamically scaled based on load. When demand of execution increases, more resources are allocated
automatically to the service and when requests fall, resources and application instances drop off automatically. In Consumption
plan, you don’t pay at all for idle functions.
 Event based architecture.
Functions are meant to be small and focused and process incoming data and be done or raise a new event in turn. Some common
usage areas of Azure functions are sending emails, starting backup, order processing, task scheduling such as database clean-up,
sending notifications, messages, and IoT data processing.

Azure Function Components
Component Description
Function triggers Triggers are what cause a function to run. A trigger defines how a function is invoked and a function must
have exactly one trigger.
Function bindings Binding to a function is a way of declaratively connecting another resource to the function.
Function runtime Azure Functions currently supports several versions of the runtime host. Functions also support many
different runtimes such as .NET Core, Node.js, Java, PowerShell and Python. During development, you can
install the Functions runtime on your local computer and run functions locally by using the Azure
Functions Core Tools.
API Management APIM provides security and routing for your HTTP triggered function endpoints as a way to expose them
as a true REST API.
Deployment slots Azure Functions deployment slots allow your function app to run different instances called "slots". Slots
are different environments exposed via a publicly available endpoint. Slots provide a way for you to test a
new version of your functions in Azure in a safe environment and then seamlessly swap the new version
into production.
Function app configuration Connection strings, environment variables, and other application settings are defined separately for each
function app. The function app settings values can be read in the code as environment variables.

When to use Azure Function
As Azure Functions uses an event-based architecture, there are many interesting cases where such an architecture can
be applied. Here’s a non-exhaustive list of scenarios suited for it:
 Reminders and notifications.

Azure Functions has a trigger that can be instructed to run at certain intervals making it straight forward to implement such a
scenario. You might have scenarios were getting a notification can be business critical.
 Scheduled tasks.
Tasks that could use the same time-based triggers. In this case, there could be jobs that need to be done at certain intervals, for
example, data cleaning or look for a piece of data.
 Experimental APIs.
If you use the Consumption plan, with Functions, you can make millions of calls and pay very little. One thing to keep in mind is
that any type of storage incurs a cost.
An example is writing to a database with a function. This plan is ideal to use for prototyping or for Start-ups. In the latter case, if
you have so many calls to your functions that most likely means you have paying customers. Hence, Azure Functions scales with
your business. As your business grows, you might consider other hosting plans as well.

When to use Azure Function
 Irregular but important business flows.

Getting a new customer and onboarding that customer is an example where your code has a good reason to run. Such a
flow likely consists of operations like interacting with a data store, sending out emails, and more.
 Queue based.
You might have a ticket selling app and requests needs to be processed in a queue like fashion.
 Processing data in real-time.

If combined with Azure SignalR, Azure Functions can be made to process data on demand.
 Analyze IoT stream.

It’s possible to collect and process data from IoT devices.
 Process file uploads.

Run code when a file is uploaded or changed in a blob storage.
 Serverless workflow.
A series of functions can be chained together, and you can introduce state which makes it possible to devise complex long running
workflows via Durable Functions. Another choice for workflows is Logic apps that can monitor external events, perform branching
logic and invoke functions as a result.

What is Function App
 A Function App provides an execution context in Azure in which your functions run. As such, it is the unit of
deployment and management for your functions. A Function App is comprised of one or more individual
functions that are managed, deployed scaled together.
 Key Points About Function App:

• All the functions in Function App share the same pricing plan & deployment method & runtime version.
• All functions in Function App must be authored in same language.

Unit 2:
Development of Azure Function

Unit 2: Objectives
 Development of Azure Function from the Portal

 Development of Azure Function in Visual Studio Code
 Azure Function code

Development of Azure Function
You can develop Azure Function using Visual Studio, Visual Studio Code, any developer IDE or even in the Azure portal.
In this unit we are mainly focusing on developing Azure Function & Function App from the Azure Portal & Visual Studio
Code.
 Languages supported for Azure Function:
• C#
• Java
• Javascript
• PowerShell
• Python

Develop Azure Function In the Portal
 In-portal editing is only supported for JavaScript, PowerShell, Python, and C# Script functions.
 Python in-portal editing is only supported when running in the Consumption plan and using the Python v1
programming model.
 In-portal editing is currently only supported for functions that were created or last modified in the portal. When
you deploy code to a function app from outside the portal, you can no longer edit any of the code for that function
app in the portal. In this case, just continue using local development.

Develop Azure Function In the Visual Studio Code
 The Azure Functions extension for Visual Studio Code lets you locally develop functions and deploy them to Azure.
 The Azure Functions extension provides these benefits:
• Edit, build, and run functions on your local development computer.
• Publish your Azure Functions project directly to Azure.
• Write your functions in various languages while taking advantage of the benefits of Visual Studio Code.
 Prerequisites:
• Visual Studio Code installed on one of the supported platforms.

• Azure Functions extension.
• An active Azure subscription.

Develop Azure Function In the Visual Studio Code
 Run local requirements

These prerequisites are only required to run and debug your functions locally. They aren't required to create or publish projects to
Azure Functions.
• The Azure Functions Core Tools version 2.x or later. The Core Tools package is downloaded and installed automatically when you
start the project locally. Core Tools include the entire Azure Functions runtime, so download and installation might take some
time.
• Python, one of the supported versions.
• Python extension for Visual Studio Code.

Azure Function Code
Azure Function contains two important pieces

1.Your code, which can be written in a variety of languages
2.Function.json file which contains the configuration details

Function.json file
For compiled languages, this config file is generated automatically from annotations in your code. For scripting
languages, you must provide the config file yourself.
The function.json file defines the function's trigger, bindings, and other configuration settings.
Every function has one and only one trigger.
Azure Function runtime uses this config file to determine the events to monitor and how to pass data into and return
data from a function execution.

Function.json file example

Folder structure
The recommended folder structure for a Python functions project looks like the following example :

Folder structure
The main project folder, <project_root>, can contain the following files:
 local.settings.json: Used to store app settings and connection strings when running locally. This file doesn't get published to Azure.
 requirements.txt: Contains the list of Python packages the system installs when publishing to Azure.
 host.json: Contains configuration options that affect all functions in a function app instance. This file does get published to Azure.
Not all options are supported when running locally.
 .vscode/: (Optional) Contains the stored Visual Studio Code configuration.
 .venv/: (Optional) Contains a Python virtual environment used by local development.
 Dockerfile: (Optional) Used when publishing your project in a custom container.
 tests/: (Optional) Contains the test cases of your function app.
 .funcignore: (Optional) Declares files that shouldn't get published to Azure. Usually, this file contains .vscode/ to ignore your editor
setting, .venv/ to ignore the local Python virtual environment, tests/ to ignore test cases, and local.settings.json to prevent local
app settings from being published.
 Each function has its own code file and binding configuration file, function.json.

Unit 3:
Function App Settings

Unit 3: Objectives
 Function App Runtime

 App settings in Function App
 Environment variables in Azure Function
 Hosting Plans in Function App

Function App Runtime
Azure Function Runtime is a specific version runtime where your function app runs on top of it.
Azure Functions currently supports several versions of the runtime host. The following table details the available
versions, their support level, and when they should be used:

Function App Runtime
 Languages:
• All functions in a function app must share the same language. You chose the language of functions in your function app when
you create the app.
• The language of your function app is maintained in the FUNCTIONS_WORKER_RUNTIME setting and shouldn't be changed
when there are existing functions.
 Run on a specific version:

• The version of the Functions runtime used by published apps in Azure is dictated by the FUNCTIONS_EXTENSION_VERSION
application setting.
• By default, function apps created in the Azure portal, by the Azure CLI, or from Visual Studio tools are set to version 4.x. You
can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but
before you add any functions. Moving to a later version is allowed even with apps that have existing functions.
 Best way to migrate FunctionApp runtime version
• For the best migration results, you should create a new function app in a new version and port your existing version function
code to the new app.

App settings in FunctionApp
App settings in Function App contain global configuration options that affect all function for that function app.
 APPINSIGHTS_INSTRUMENTATION_KEY
The Application Insights instrumentation key if you are using Application Insights.
 AzureWebJobsStorage
The Azure function runtime uses this storage account connection string for all functions except for HTTP triggered functions.
 FUNCTIONS_EXTENSIONS_VERSIONS
The version of the function runtime to use this function app
 FUNCTIONS_WORKER_RUNTIME
The language worker runtime to load in the function app. This will correspond to the language being used in your
application(for example dotnet)
Dotnet(C#,F#), node(Javascript, Typescript), pwershell(Powershell) and python(Python)

App settings in FunctionApp
 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
For Consumption and Premium plans only. Connection string for storage account where the function app code and configuration
are stored.
 WEBSITE_CONTENTSHARE
For Consumption and Premium plans only. The file path to the function app code and configuration used with
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Default is a unique string that begins with the function app name .

Environment Variables in Azure Function
You may need to store custom settings for your Azure Function. One available option is to use environment variable.
You can manage these settings in the Application settings section of your function app in the Azure portal.

Hosting Plans in Azure Function App
 When you create a function app in Azure, you must choose a hosting plan for your app. There are three basic
Azure Functions hosting plans provided by Azure Functions:
• Consumption plan
• Premium plan
• Dedicated (App Service) plan
 These hosting plans are facilitated by Azure App Service infrastructure and are generally available (GA) on both
Linux and Windows virtual machines.
 The Azure Functions hosting plan you choose dictates the following behaviors:
• How your function app is scaled.

• The resources available to each function app instance.
• Support for advanced functionality, such as Azure Virtual Network connectivity.

Consumption Plan
 Scale automatically and only pay for compute resources when your functions are running.
 On the Consumption plan, instances of the Functions host are dynamically added and removed based on the
number of incoming events.
• Default hosting plan.
• Pay only when your functions are running.
• Scales automatically, even during periods of high load.

Premium Plan
 Automatically scales based on demand using pre-warmed workers, which run applications with no delay after
being idle, runs on more powerful instances, and connects to virtual networks.
 Consider the Azure Functions Premium plan in the following situations:
• Your function apps run continuously, or nearly continuously.
• You have a high number of small executions and a high execution bill, but low GB seconds in the Consumption plan.
• You need more CPU or memory options than what is provided by the Consumption plan.
• Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
• You require features that aren't available on the Consumption plan, such as virtual network connectivity.
• You want to provide a custom Linux image on which to run your functions .

Dedicated Plan
 Run your functions just like your webapps. If you use App service for your other applications, your
function can run on the same plan at no additional cost.

Unit 4: Trigger & Binding

Unit 4: Objectives
 Triggers
 Types of Triggers
 Bindings
 Types of Binding
 Types of supported bindings
 Binding properties
 Create a binding

Triggers
An Azure Functions app doesn't do work until something tells it to execute. For example, we could create an Azure
Function to send out a reminder text message to our customers before an appointment. If we don't tell the function
when it should run, our customers will never receive a message.
This unit describes triggers at a high level, explores the most common types of triggers, and uses bindings to connect a
trigger to a function.
What is a trigger?
A trigger is an object that defines how an Azure Function is invoked. For example, if you want a function to execute
every 10 minutes, you could use a timer trigger.
Every function must have exactly one trigger associated with it. If you want to execute a piece of logic that runs under
multiple conditions, you need to create multiple functions that share the same core function code.

Types of Triggers
Azure Functions supports a wide range of trigger types. Here are some of the most common types:
Type Purpose
Timer Execute a function at a set interval.
HTTP Execute a function when an HTTP request is received.
Blob Execute a function when a file is uploaded or updated in Azure Blob storage.
Queue Execute a function when a message is added to an Azure Storage queue.
Azure Cosmos DB Execute a function when a document changes in a collection.
Event Hub Execute a function when an event hub receives a new event.

Bindings
 Accessing and processing data are key tasks in many software solutions. Consider some of these scenarios:
• You've been asked to implement a way to move incoming data from Azure Blob Storage to Azure Cosmos DB.
• You want to post incoming messages to a queue for processing by another component in your enterprise.
• Your service needs to grab gamer scores from a queue and update an online scoreboard.
 All these examples are about moving data. The data source and destinations differ from scenario to scenario, but
the pattern is similar. You connect to a data source, and you read and write data. Azure Functions helps you
integrate with data and services by using bindings.

What is binding?
In Azure Functions, bindings provide a declarative way to connect to data from within your code. They make it easier
to integrate with data streams consistently in a function. You can have multiple bindings providing access to different
data elements. This is powerful because you can connect to your data sources without having to code specific
connection logic (like database connections or web API interfaces).

What is binding?
 In Azure Functions, bindings provide a declarative way to connect to data from within your code. They make it
easier to integrate with data streams consistently in a function. You can have multiple bindings providing
access to different data elements. This is powerful because you can connect to your data sources without
having to code specific connection logic (like database connections or web API interfaces).
 Types of bindings
There are two kinds of bindings you can use with functions:
• Input binding - Connects to a data source. Our function can read data from these input sources.
• Output binding - Connects to a data destination. Our function can write data to these output destinations.

Types of supported bindings
 The type of binding defines where we are reading or sending data. There is a binding to respond to web
requests, and a large selection of bindings to interact directly with various Azure services, as well as third-party
services.
 A binding type can be used as an input, an output, or both. For example, a function can write to a Blob Storage
output binding, but a Blob Storage update could trigger another function.
 Common binding types include:
• Blob Storage
• Azure Service Bus Queues
• Azure Cosmos DB
• Azure Event Hubs
• External files
• External tables
• HTTP endpoints
These types are just a sample. There are more, plus functions have an extensibility model to add more bindings.

Binding properties
 Three properties are required in all bindings. You may have to supply additional properties based on the type
of binding and storage you're using.
• Name - Defines the function parameter through which you access the data (for example, in a queue input binding, this is
the name of the function parameter that receives the queue message content).
• Type - Identifies the type of binding (for example, the type of data or service we want to interact with).
• Direction - Indicates the direction data is flowing (for example, is it an input or output binding)?
Additionally, most binding types also need a fourth property:
• Connection - Provides the name of an app setting key that contains the connection string. Bindings use connection strings
stored in app settings to keep secrets out of the function code. This makes your code more configurable and secure.

Create a binding?
Bindings are defined in JSON. A binding is configured in your function's configuration file, which is
named function.json and lives in the same folder as your function code.
Let's examine a sample input binding:

Create a binding
To create this binding, we:
1. Create a binding in our function.json file.
2. Provide the value for the name variable. In this example, the variable holds the blob data.
3. Provide the storage type. In the preceding example, we're using Blob Storage.
4. Provide the path, which specifies the container and the item name that goes in it. The path property is required when using
the blob trigger, and should be provided in the style shown here, with curly braces around the filename portion of the path. This
creates a binding expression that allows you to reference the blob's name in other bindings, and in your function's code. In this
example, a parameter on the function named filename would be populated with the filename of the blob that triggered the
function.
5. Provide the connection string setting name defined in the application's settings file. It's used as a key to find the connection
string to connect to your storage account.
6. Define the direction as in. It reads data from the blob.
Bindings are used to connect to data in your function. In this example, we used an input binding to connect user images to be
processed by our function as thumbnails.

Unit 5: Logic Apps: Automating Your
Business Process

Unit 5: Objectives
 Introduction to Logic Apps

 Key features

Introduction to Logic Apps
 Azure Logic Apps is a cloud-based service provided by Microsoft Azure that allows you to design, automate, and
orchestrate business workflows.
 It integrate systems, data, and services across different platforms and environments.
 It provides a visual designer that allows users to create workflows by connecting pre-built actions and triggers,
eliminating the need for complex coding.
 Logic Apps are especially useful for scenarios where you need to coordinate actions across multiple system and
services.

Key Features
 Visual workflow designer
 Connectors and triggers
 Data transformation and mapping
 Conditional logic and loops

Visual Workflow Designer
 Logic Apps provides a visual workflow designer that simplifies the creation and management of the workflow.
 The drag-and-drop interface allows users to easily design complex workflow with extensive coding.
 The designer enables you to connect pre-built actions, triggers and connectors using a graphical interface
 Each action and trigger is represented as a block, and the connections between them define the execution orders.
 You can easily configure the properties and parameters of each action and trigger directly within the designer.
 The designer supports error handling and exception flows withing the workflow.
 Logic Apps allows multiple team member to collaborate on the same workflow.
 It supports versioning and history tracking, allowing you to easily manage and roll back to previous version if
needed.

Connectors And Triggers
 Connectors
• Logic App offers a vast library of pre-built connectors, enabling seamless integration with a wide range of services and
system
• Connectors provide the necessary APIs and protocol to connect and interact with external systems.
• They abstract the complexity of integration with various services, allowing you to focus on building your workflow.
• Connectors provide configurable properties and parameters that can be set within the Logic Apps designer.
• Connectors support dynamic data binding, allowing you to pass data between actions and connectors within a workflow.
• This enables you to use output of one action as input to another, facilitating data transformation and flow control.
• In addition to pre-built connectors, Logic Apps allows you to create custom connectors using Azure API Management or
Azure Function.

Connectors And Triggers
 Triggers
• Triggers act as a starting point of Logic App workflow, defining the event or condition that initiates the workflow.
• Triggers can be based on time schedules, HTTP requests, file changes, message queues, email arrival, database updates, and
more.
• Triggers provide configurable properties and parameters that can be set within the Logic Apps designer.
• Triggers support dynamic data binding, that enables you to use the output of action or trigger as input of another.
• Triggers support error handling and retry policies.
• You can configure how the workflow handles errors, retries failed attempt, and handles exception encountered during
trigger execution.
• Logic Apps seamlessly integrates with various Azure services, such as Azure Service Bus, Azure Event Grid, and Azure Blob
Storage, allowing you to use their triggers as the starting point of your workflows

Data Transformation And Mapping
 Logic Apps provides built-in capabilities for transforming and manipulating data within your workflows.
 It enables you to convert data formats, extract and manipulate values, and apply various transformations.
 Logic Apps supports mapping and conversion functions to transform data between different formats and
structures.
• Examples of mapping and conversion functions:
• JSON to XML and vice versa.
• String concatenation, splitting, and manipulation.
• Date and time formatting.
• Conditional transformations and mapping.
 Logic Apps allows you to map and extract specific values from incoming data payloads.
 You can define mapping rules to extract data fields.

Data Transformation And Mapping
 Logic Apps provides functions and expressions for validating and filtering data based on specific criteria
 Logic Apps provides error handling and exception handling capabilities when performing data transformations.
 You can define error handling logic to handle errors, exceptions, or unexpected data scenarios during the
transformation process.

Conditional Logic And Loops.
 Conditional Logic in Logic Apps

• Logic Apps provides powerful conditional logic capabilities to make decision and control the flow of your workflow
• Conditional statements allow you to branch the workflow based on specific conditions and criteria.
• IF-ELSE Statements:
• Logic Apps supports IF-ELSE statements for conditional branching.
• You can define conditions based on data values, expressions, or results from previous actions, and specify different
actions or paths to follow based on the evaluation of those conditions.
• Switch Statements
• Logic Apps supports switch statements for multi-way branching based on different conditions.
• Switch statements allow you to evaluate multiple conditions and perform different actions or
paths based on the condition that matches.

 Comparison Operators and Expressions:

• Logic Apps offers a wide range of comparison operators and expressions for building conditional logic.
• Examples : equality, inequality, greater than, less than, logical AND, logical OR, and more.
 Loop statements
• Logic Apps provides various loop constructs to iterate over a collection or repeat actions multiple times
• Loops in Logic Apps support dynamic iteration and mapping capabilities.
 For Each Loop:
• Logic Apps support for each statement to iterates over each element in an array or collection.
• For Each statement is mostly used to repeat set of actions over each element in an array or collection.
 Do-Until Loop:
• Logic Apps support Do-Until statement for repeating set of actions until a specified condition is met.

• Break And Continue Statement.

• Logic Apps supports break and continue statements within loops.
• Break statements allow you to exit a loop prematurely.
• Continue statements allow you to skip the current iteration and move to the next iteration.
 Error Handling in Conditional logic and Loops
• Logic Apps provides error handling and exception handling capabilities within conditional logic and loops.
• You can define error handling logic to handle errors, exceptions, or unexpected conditions encountered during the execution
of conditional statements or loops

Your Trusted Analytics and Planning Partner

Azure Training TFT - Function App &amp; Logic App

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Training TFT - Function App &amp; Logic App

Uploaded by

Copyright:

Available Formats

Your Trusted Analytics and Planning Partner

Function App & Logic Apps

TekLink International Confidential 1

 Introduction to Azure Function App – Serverless Platform

TekLink International Confidential 2

TekLink International Confidential 3

After completing this unit, you will be able to:

 Understand Azure Function – A Serverless Application Platform

TekLink International Confidential 4

TekLink International Confidential 5

TekLink International Confidential 6

 Avoids over-allocation of infrastructure

TekLink International Confidential 8

TekLink International Confidential 9

 Use your preferred language:

TekLink International Confidential 10

TekLink International Confidential 11

 Reminders and notifications.

TekLink International Confidential 12

 Irregular but important business flows.

 Processing data in real-time.

 Analyze IoT stream.

 Process file uploads.

TekLink International Confidential 13

 Key Points About Function App:

TekLink International Confidential 14

TekLink International Confidential 15

After completing this unit, you will be able to:

 Development of Azure Function from the Portal

TekLink International Confidential 16

TekLink International Confidential 17

TekLink International Confidential 18

• Visual Studio Code installed on one of the supported platforms.

TekLink International Confidential 19

 Run local requirements

TekLink International Confidential 20

Azure Function contains two important pieces

TekLink International Confidential 21

Every function has one and only one trigger.

TekLink International Confidential 22

TekLink International Confidential 23

TekLink International Confidential 24

 .vscode/: (Optional) Contains the stored Visual Studio Code configuration.

 .venv/: (Optional) Contains a Python virtual environment used by local development.

 Dockerfile: (Optional) Used when publishing your project in a custom container.

 tests/: (Optional) Contains the test cases of your function app.

TekLink International Confidential 25

TekLink International Confidential 26

After completing this unit, you will be able to:

 Function App Runtime

TekLink International Confidential 27

TekLink International Confidential 28

 Run on a specific version:

 Best way to migrate FunctionApp runtime version

TekLink International Confidential 29

The version of the function runtime to use this function app

Dotnet(C#,F#), node(Javascript, Typescript), pwershell(Powershell) and python(Python)

TekLink International Confidential 30

TekLink International Confidential 31

TekLink International Confidential 32

• How your function app is scaled.

TekLink International Confidential 33

TekLink International Confidential 34

Azure Training TFT - Function App & Logic App

Azure Training TFT - Function App & Logic App