Infrastructure as Code (IaC) has become a cornerstone of modern DevOps practices, enabling teams to provision and manage cloud infrastructure through code. In the Azure ecosystem, two primary tools for implementing IaC are Azure Resource Manager (ARM) templates and Bicep. While both serve similar purposes, they differ significantly in syntax, usability, and functionality. This blog will compare these tools to help you decide which one to use for your Azure infrastructure needs. Azure Resource Manager Templates ARM templates have been the backbone of Azure IaC for many years. Written in JSON, they define the infrastructure and configuration for Azure resources declaratively. Key Features: Advantages: Challenges: Bicep Bicep is a domain-specific language (DSL) introduced by Microsoft to simplify the authoring of Azure IaC. It is designed as a more user-friendly alternative to ARM templates. Key Features: Advantages: Challenges: Comparing ARM Templates and Bicep Feature ARM Templates Bicep Syntax Verbose JSON Concise DSL Modularity Limited Strong Support Tooling Mature Rapidly Improving Resource Support Full Full Ease of Use Challenging Beginner-Friendly Community Support Extensive Growing When to Use ARM Templates ARM templates remain a solid choice for: When to Use Bicep Bicep is ideal for: To conclude, both ARM templates and Bicep are powerful tools for managing Azure resources through IaC. ARM templates offer a mature, battle-tested approach, while Bicep provides a modern, streamlined experience. For teams new to Azure IaC, Bicep’s simplicity and modularity make it a compelling choice. However, existing users of ARM templates may find value in sticking with their current workflows or transitioning gradually to Bicep. Regardless of your choice, both tools are fully supported by Azure, ensuring that you can reliably manage your infrastructure in a consistent and scalable manner. Evaluate your team’s needs, skills, and project requirements to make the best decision for your IaC strategy. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

When deploying applications on Azure App Service, certain environment variables play a pivotal role in ensuring smooth operation and efficient resource management. One such variable is WEBSITE_CONTENTSHARE. In this blog, we will explore what WEBSITE_CONTENTSHARE is, why it matters, and how you can work with it effectively. What is WEBSITE_CONTENTSHARE? The WEBSITE_CONTENTSHARE environment variable is a unique identifier automatically generated by Azure App Service. It specifies the name of the Azure Storage file share used by an App Service instance when its content is deployed to an Azure App Service plan using shared storage, such as in a Linux or Windows containerized environment. This variable is particularly relevant for scenarios where application code and content are stored and accessed from a shared file system. It ensures that all App Service instances within a given plan have consistent access to the application’s files. Key Use Cases How WEBSITE_CONTENTSHARE Works When you deploy an application to Azure App Service: Example Value: This value points to a file share named app-content-share1234 in the configured Azure Storage account. Configuring WEBSITE_CONTENTSHARE While the WEBSITE_CONTENTSHARE variable is automatically managed by Azure, there are instances where you may need to adjust configurations: Troubleshooting Common Issues 1. App Service Cannot Access File Share 2. Variable Not Set 3. File Share Quota Exceeded Best Practices To conclude that, The WEBSITE_CONTENTSHARE variable is a crucial part of Azure App Service’s infrastructure, facilitating shared storage access for applications. By understanding its purpose, configuration, and best practices, you can ensure your applications leverage this feature effectively and run seamlessly in Azure’s cloud environment. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

Application Insights is a powerful monitoring tool within Azure that provides insights into application performance and diagnostics. Logic Apps, on the other hand, enable workflow automation for integrating various Azure services. By combining these tools, you can automate querying Application Insights logs and take actions based on the results. This blog explains how to set up this connection step-by-step. Prerequisites Before proceeding, ensure you have the following: Step 1: Enable Logs in Application Insights To ensure Application Insights data is accessible: Step 2: Create a KQL Query KQL (Kusto Query Language) is used to query Application Insights logs: Step 3: Set Up a Logic App Create a Logic App that will query Application Insights: Step 4: Configure Logic App Actions To execute and process the query: 2. Add a Body for the request: “`json { “query”: “traces | where timestamp >= ago(1h) | summarize Count=count() by severityLevel” } 3. Add actions to handle the response, such as sending an email or creating an alert based on the query results. Step 5: Test the Workflow Use Cases Conclusion Integrating Application Insights logs with Logic Apps is a straightforward way to automate log queries and responses. By leveraging the power of KQL and Azure’s automation capabilities, you can create robust workflows that monitor and react to your application’s performance metrics in real-time. Explore these steps to maximize the synergy between Application Insights and Logic Apps for a more proactive and automated approach to application monitoring and management. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

In modern development workflows, maintaining consistency across build pipelines is crucial. A well-organized build process ensures reliability and minimizes repetitive configuration. For developers using YAML-based pipelines (e.g., Azure DevOps or GitHub Actions), template extension is a powerful approach to achieve this. This blog explores how to use YAML templates effectively to manage build stages for multiple functions in your project. What is Template Extension in YAML? Template extension allows you to define reusable configurations in one place and extend them for specific use cases. Instead of repeating the same build steps for every function or service, you can create a single template with customizable parameters. Why Use Templates in Build Pipelines? – Scalability: Add new services or functions without duplicating code. – Maintainability: Update logic in one place instead of modifying multiple files. – Consistency: Ensure uniform processes across different builds. Step-by-Step Implementation Here’s how you can set up a build pipeline using template extension. 1. Create a Reusable Template A template defines the common steps in your build process. For example, consider the following file named buildsteps-template.yml: parameters: – name: buildSteps # the name of the parameter is buildSteps type: stepList # data type is StepList default: [] # default value of buildSteps stages: – stage: secure_buildstage pool: name: Azure Pipelines demands: – Agent.Name -equals Azure Pipelines x jobs: – job: steps: – task: UseDotNet@2 inputs: packageType: ‘sdk’ version: ‘8.x’ performMultiLevelLookup: true – ${{ each step in parameters.buildSteps }}: – ${{ each pair in step }}: ${{ pair.key }}: ${{ pair.value }} 2. Reference the Template in the Main Pipeline This is your main pipeline file: trigger: branches: include: – TEST {Branch name} paths: include: – {Repository Name}/{Function Name} variables: buildConfiguration: ‘Release’ extends: template: ..\buildsteps-template.yml {Template file name} parameters: buildSteps: – script: dotnet build {Repository Name}/{Function Name}/{Function Name}.csproj –output build_output –configuration $(buildConfiguration) displayName: ‘Build {Function Name} Project’ – script: dotnet publish {Repository Name}/{Function Name}/{Function Name}.csproj –output $(build.artifactstagingdirectory)/publish_output –configuration $(buildConfiguration) displayName: ‘Publish {Function Name} Project’ – script: (cd $(build.artifactstagingdirectory)/publish_output && zip -r {Function Name}.zip .) displayName: ‘Zip Files’ – script: echo “##vso[artifact.upload artifactname={Function Name}]$(build.artifactstagingdirectory)/publish_output/{Function Name}.zip” displayName: ‘Publish Artifact: {Function Name}’ condition: succeeded() Benefits in Action 1. Simplified Updates When you need to modify the build process (e.g., change the .NET SDK version), you only update the template.yml. The changes automatically apply to all functions. 2. Customization Each function can have its own build configuration without duplicating the pipeline logic. 3. Improved Collaboration By centralizing common configurations, teams can work independently on their functions while adhering to the same build standards. Best Practices Final Thoughts YAML template extension is a game-changer for developers managing multiple services or functions in a project. It simplifies pipeline creation, reduces duplication, and enhances scalability. By adopting this approach, you can focus on building great software while your pipelines handle the heavy lifting. If you haven’t already, try applying template extension in your next project—it’s a small investment with a big payoff. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction Azure Blob Storage Lifecycle Management allows you to manage and optimize the storage lifecycle of your data. You can define policies that automate the transition of blobs to different access tiers or delete them after a specified period. This can help reduce costs and manage the data efficiently. This Blog shows how to set up and manage lifecycle policies: Steps to Create a Lifecycle Management Policy Access the Azure Portal: Sign in to your Azure account and navigate to the Azure Portal. Navigate to Your Storage Account: – Go to “Storage accounts”. – Select the storage account where you want to apply the lifecycle policy. Configure Lifecycle Management: – In the storage account menu, under the “Blob service” section, select “Lifecycle management”. Add a Rule: – Click on “+ Add rule” to create a new lifecycle management rule. – Provide a name for the rule. Define Filters: You can specify filters to apply the rule to a subset of blobs. Filters can be based on: – Blob prefix (to apply the rule to blobs with a specific prefix). – Blob types (block blobs, append blobs, page blobs). Set Actions: – Define the actions for the rule, such as moving blobs to a cooler storage tier (Hot, Cool, Archive) or deleting them after a certain number of days. – You can specify the number of days after the blob’s last modification date or its creation date to trigger the action. Review and Save: – Review the policy settings. – Save the policy. Key Points to Remember – Access Tiers: Azure Blob Storage has different access tiers (Hot, Cool, Archive), and lifecycle policies help optimize costs by moving data to the appropriate tier based on its access patterns. – JSON Configuration: Policies can be defined using JSON, which provides flexibility and allows for complex rules. – Automation: Lifecycle management helps automate data management, reducing manual intervention and operational costs. Conclusion By setting up these policies, you can ensure that your data is stored cost-effectively while meeting your access and retention requirements. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction Integrating Salesforce with InforLN is a critical task for organizations looking to streamline their sales and billing processes. With the AIS Interface, businesses can efficiently manage data flow between these two platforms, reducing manual effort, enhancing visibility, and improving overall organizational performance. In this Blog, it shows the detailed information for integration between Salesforce to InforLN. The AIS Interface is intended to Extract, Transform and Route the data from Salesforce to InforLN. The steps for integration would be same for different entities. Many organizations need Salesforce to InforLN integration because of the below reasons: Event Scenario Pre-Requisites: Process Steps: On Demand Load Scenario Pre-Requisites: Process Steps: Conclusion Based on the above Integration scenarios Azure Developer can easily navigate for the integration implementation and they can choose between Event Driven or On-Demand based on the business requirement. This integration not only simplifies complex processes but also eliminates redundant tasks, allowing teams to focus on more strategic initiatives. Whether your organization requires event-driven or on-demand integration, this guide equips you with the knowledge to implement a solution that enhances efficiency and supports your business goals. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

High-level steps to start building B2B logic app workflows: Creating a Key Vault for Certificate and Private Key Create an Azure Key vault. In the next step, Select Vault access policy and select the Users. Select Review + Create. Add the access policy and assign it to Azure Logic App. Create Certificate Click the Certificate and Download Create a Key and attach the .pfx format file. Creating two Integration Account for adding Partners, Agreements and Certificates Create 2 integration accounts, one for sender and one for receiver. Add the Sender and Receiver Partners in both the integration accounts. Add a public certificate in sender integration account and a private certificate in receiver integration account. Now we need to add the agreement in both sender and receiver integration account. Sender Agreement Send Settings Receiver Agreement Receive Settings Creating two Logic Apps, one for Sending (Encoded Message) and one for Receiving (Decoded Message) Create two logic apps and add the integration account in respective logic apps. Logic App for Sender (Encoding Message) Logic App for Receiver (Decoding Message)

In this Blog, it shows the detailed information for integration between SAP B1 to Salesforce. The AIS Interface is intended to Extract, Transform and Route the data from SAPB1 to Salesforce. The steps for integration would be same for different entities. Event Scenario Pre-Requisites: Process Steps: On Demand Load Scenario Pre-Requisites: Process Steps Based on the above Integration scenarios Azure Developer can easily navigate for the integration implementation and they can choose between Event Driven or On-Demand based on the business requirement. We are just getting started with Azure Integration Services and stay tuned for more in this series.

If we have a json data whose objects have one or more key value pairs also known as properties and we need to separate them into individual objects then Serializing and Deserializing method can be used in C#. Sample Json data :      {                                 “FirstName”:”Aditya”,                                 “MiddleName”:”Ashok”,                                 “LastName”:”Somwanshi”,                                 “Phone”:[“9004802526″,”34304235”],                                 “Address”:{“Primary”:”Panvel”, “Secondary”:”Cloudfronts”}                             } Desired Output: {   “FullName”: “Aditya Ashok Somwanshi”,   “Primary Phone”: “9004802526”,   “Secondary Phone”: “34304235”,   “Primary Address”: “Panvel”,   “Secondary Address”: “Cloudfronts” } First open Visual Studio and create new project in Console application template. Give your Project a name and click next, you will be directed to a new page where you can start with your code. Now we need to install some packages into our project to use it in our code. So at top in the tools section select NuGet Package Manager and in that select Manage Nuget Packages for Solution Now search for Newtonsoft.Json and install the package The purpose for installing this package is to access serialize and deserialize functions in our code. To add a class to main program you need to right click on your project and then select and choose add new item Select class and name the class and add. Now to write the code we need to use Convert JSON to C# Classes Online – Json2CSharp Toolkit for formatting the json to C# and knowing the classes to be used. using System.Collections.Generic; using Newtonsoft.Json; namespace Human {     public class Address     {         public string Primary { get; set; }         public string Secondary { get; set; }     }     public class Person     {         public string FirstName { get; set; }         public string MiddleName { get; set; }         public string LastName { get; set; }         public List<string> Phone { get; set; }         public Address Address { get; set; }     }     public class Root     {         public string FullName { get; set; }         [JsonProperty(“Primary Phone”)]         public string PrimaryPhone { get; set; }         [JsonProperty(“Secondary Phone”)]         public string SecondaryPhone { get; set; }         [JsonProperty(“Primary Address”)]         public string PrimaryAddress { get; set; }         [JsonProperty(“Secondary Address”)]         public string SecondaryAddress { get; set; }     } } Now the main program using Newtonsoft.Json; using System; namespace Human {     public class Program     {         public static void Main(string[] args)         {             string json = @”{                                 “”FirstName””:””Aditya””,                                 “”MiddleName””:””Ashok””,                                 “”LastName””:””Somwanshi””,                                 “”Phone””:[“”9004802526″”,””34304235″”],                                 “”Address””:{“”Primary””:””Panvel””, “”Secondary””:””Cloudfronts””}                             }”;//Defining Json             Person human = JsonConvert.DeserializeObject<Person>(json);//Deserializing Json             Root rt = new Root();             rt.FullName = human.FirstName + ” ” + human.MiddleName + ” ” + human.LastName;  //Concatenating Names             rt.PrimaryPhone = human.Phone[0];             rt.SecondaryPhone = human.Phone[1];             rt.PrimaryAddress = human.Address.Primary;             rt.SecondaryAddress = human.Address.Secondary;             string output = JsonConvert.SerializeObject(rt, Formatting.Indented);//Serializing Json             Console.WriteLine(output);         }     } } OUTPUT: