Logic App - Coding

Logic Apps, a service provided by Microsoft Azure, primarily use a visual designer for creating workflows. However, you can extend their functionality using Azure Functions or Azure Web Apps.

Azure Logic Apps can be extended or customized using several programming languages, including:

1.    C#: Azure Functions, particularly with HTTP triggers, can be written in C#.
2.    JavaScript/Node.js: Azure Functions also support Node.js runtime, allowing you to write functions in JavaScript.
3.    Python: Azure Functions now support Python as a runtime, enabling you to write functions in Python.
4.    PowerShell: Azure Functions can also be written in PowerShell, which can be useful for automating various tasks within your Logic Apps.

These languages can be used within Azure Functions to integrate with Logic Apps and perform custom actions or handle specific events as part of your workflow.

Logic-App - Workflow can be coded using JSON workflow.

Azure Logic Apps workflows are typically designed using a visual designer in the Azure Portal. This designer allows users to create workflows by arranging and configuring predefined connectors and actions through a drag-and-drop interface.

While Logic Apps workflows are not written in a traditional programming language, they are defined using JSON-based workflow definition language called the Workflow Definition Language (WDL). This language specifies the structure and behavior of the Logic Apps workflow in a JSON format.

The Logic Apps designer abstracts the complexity of the underlying JSON definition, making it accessible to users without requiring them to directly interact with the JSON code. However, for advanced scenarios or specific requirements, you can also directly edit the JSON code representing the Logic Apps workflow.

In summary, Logic Apps workflows are visually designed in the Azure Portal using a drag-and-drop interface, but the underlying representation is in the form of JSON using the Workflow Definition Language (WDL).

 

What is stateful-workflow  & stateless-workflow ?

https://learn.microsoft.com/en-us/azure/logic-apps/single-tenant-overview-compare#stateful-stateless 

 

 

 

Comments

Post a Comment

Popular posts from this blog

APIM -- High Availability skipping DR and Geo-Redundancy

  Regional Redundancy : Deploy your APIM service in an Azure region that offers redundancy and fault tolerance. Azure regions consist of multiple data centers, ensuring resilience against data center failures within the region. Scale Units : Configure your APIM service with multiple scale units within the same region. Scale units are isolated instances of APIM infrastructure that handle incoming traffic independently. Distributing your API traffic across multiple scale units ensures redundancy and fault tolerance at the application layer. Define Terraform Configuration : Write Terraform configuration files (usually with a .tf extension) that describe the resources needed for your APIM deployment, including multiple instances representing scale units. Create Scale Units : Use Terraform to define multiple instances of the APIM service using the azurerm_api_management resource. Each instance represents a scale unit, capable of handling incoming traffic independently.   Availabi...
Read more

Working on Azure -- Terraform - connectivity

If you're using a service principal account to authenticate with Azure, you'll still need to install the Azure CLI on your VDI, but you'll also need to configure the CLI to use the service principal for authentication. Here's how you can do it: Install Azure CLI : Download and install the Azure CLI on your VDI by following the installation instructions provided by Microsoft. You can find the installation instructions for various operating systems here . Authenticate with Service Principal : Once the Azure CLI is installed, you'll need to authenticate with Azure using the service principal credentials. Run the following command and provide the necessary details:  
Read more