Automic Automation Cloud Integration: Azure Functions Agent Integration

Instantly inherit the advanced capabilities of your enterprise solution, enabling you to deliver your digital transformation more quickly and successfully. This video explains the Automic Automation Azure Functions agent integration and its benefits. It presents its components and demonstrates how to install, configure, and use it.

Video Transcript

Welcome to this video on the Automic Automation Azure Functions integration solution. In this video, we will explain the Azure Functions cloud integration and what it brings to the Automic Automation user community.

Azure Functions is a serverless computing service that allows developers to build event-driven applications without managing infrastructure or servers. This service scales to meet demand, enabling development teams to focus on writing code and business logic rather than managing servers. As a result, it leads to faster innovation cycles and improved operational efficiency.

Integrating Automic Automation with Azure Functions allows you to run Azure Functions jobs in your workspace from Automic Automation. We'll provide some technical insights so that the integration components are clearly identified and the deployment sequence is understood. We'll focus on the configuration of the agent and the design of the two core object templates: connections and jobs. Finally, we'll run through a demo.

Automic Automation plays a central role in orchestrating operations across multiple environments, including the cloud. Automic Automation synchronizes these processes with other non-cloud operations. By integrating Azure Functions, we can configure process automation centrally in Automic Automation and then trigger, monitor, and supervise everything in one place. Azure Functions processes can then be synchronized with all other environments routinely supported by Automic Automation.

Azure Functions's role is reduced to executing the jobs. All other functions, especially those pertaining to automation, are delegated to Automic Automation. This means that we don't have to log into the Azure Functions environment and keep on refreshing it by ourselves. Automic Automation handles all the execution and monitoring aspects. The Automic Automation integration provides a simplified view to execute function jobs. Automic Automation lets us build configurations with intuitive interfaces like drag-and-drop workflows and supervised processes in simple dashboard tools designed natively for operations. Statuses are color-coded, and retrieving logs is done with a basic right-click.

From an operations perspective, Automic Automation highly simplifies the configuration and orchestration of Azure Functions jobs. Externalizing operations to a tool with a high degree of third-party integration means we can synchronize all cloud with non-cloud workload using various agents and job object types. We can build sophisticated configurations involving multiple applications, database packages, system processes like backups and data consolidation, file transfers, web services, and other on-premise workload.

A conventional architecture involves two systems: the Automic Automation host and a dedicated system for the agent. The agent is configured with a simple INI file containing standard values: system agent name, connection, and TLS. When we start the agent, it connects to the engine and it adds two new objects to the repository: a connection object to store the Azure Functions endpoint and login data, and a job template designed to trigger Azure Functions jobs.

Let's assume we're automating for four instances of Azure Functions. We create a connection object in Automic Automation for each instance by duplicating the "con" template for each of these instances. Lastly, we create the Azure Functions jobs in Automic Automation for each corresponding process in Azure Functions. The Automic Automation jobs include the connection object based on the target system. When we execute the jobs in Automic Automation, it triggers the corresponding process in Azure Functions. We're able to retrieve the successive statuses and finally generate a job report. In Automic Automation, this job can be incorporated in workflows and integrated with other non-cloud processes.

The procedure to deploy the Azure Functions integration is as follows: First, we download the integration package from Marketplace. This package contains all the necessary elements. We unzip this package which produces a directory containing the agent, the INI configuration files, and several other items like the start command. We use the appropriate INI file for our specific platform. Azure Functions is a standard Automic agent. It requires at least four values to be updated: agent name, Automic system, JCP connection and TLS port, and finally TLS certificate.

When the agent is configured, we start it. New object templates are deployed. We create a connection to every Azure Functions instance we need to support. For this, we use the template "con" object, which we duplicate as many times as we need. The "con" object references the Azure Functions endpoint. Finally, we use the Azure Functions template jobs to create the jobs we need. We match these Automic Automation jobs to the Azure Functions jobs, reference the connection object, and run them. We're able to supervise the jobs, generate logs, and retrieve the statuses. The jobs can then be incorporated into non-cloud workflows.

We install, configure, and start an agent to deploy the Azure Functions integration. The agent is included in the Azure Functions package which we download from Marketplace. We unzip the package which creates a file system: agents/azure functions/bin that contains the agent files. Based on the platform, we rename the agent configuration file UCXJCX and set a minimum of four values: the agent name, the AE system name, the host name and port connection to the automation engine's JCP, and finally the directory containing the TLS certificate. Finally, we start the agent by invoking the JR file via the Java command. The agent connects to the AE and deploys the object templates needed to support the integration: the "con" or connection object, and the Azure Functions job templates.

In our demo, we will create a connection object. Once we have established the connection to the Azure Functions environment, we'll create an execute functions job. Finally, we'll execute and supervise this job.

Let's explore the Azure Functions console which displays an application called "Function App." A Function App is the hosting environment where one or more functions are deployed and executed. When you open one, you can view different types of functions. You can also see that there are three types of authorizations for the functions in the Function App. Anonymous: publicly accessible without authentication, API keys, or tokens. The admin requires an admin key, granting access to all functions. The function requires a key for access, offering more control than anonymous mode. What you see here are various HTTP trigger functions. Although there are other trigger types, we're focusing on HTTP triggers which execute the function when an HTTP request is received. Select the HTTP trigger function with the anonymous authorization level. Here you can see various options for the selected function. "Code + Test" allows you to write and test your function code. "Integration" enables integration with other services. "Function keys" displays the keys required for function access. "Invocations" shows the success and error counts for function invocations. "Logs" provides logs of function executions. "Metrics" offers performance metrics for the function.

Go to the "Code + Test" option and click on "Test/Run the function" in the input section on the right side. There's no need to provide any details. They are set by default. Just specify the method and key if required. Then execute the function by clicking the "Run" button. To create a new function, just click the "Create" button. The Function App provides multiple trigger types for creating functions. While different triggers serve various purposes, our primary focus is on HTTP trigger functions. Select the HTTP trigger and click on "Next." Here you can view the template details and select the authorization level from the drop-down list based on your requirements. You can check the invocations of the previous functions for HTTP trigger anonymous functions. Go to the "Invocation" section to see the success count and error count from the past 30 days, indicating how many times the function was invoked.

Let's move on to the Automic system. Here we create a connection object with specific inputs to connect to Azure Functions. We must enter the endpoint. This is the URL of the Azure Functions environment. We must then specify an authentication type. We have three options: the service principal type, the OAuth 2 token type, and the token from file type. With the service principal type, you must define your Azure AD URL, a tenant ID, a client ID, and a client secret. With the OAuth 2 authentication method, depending on the version of the OAuth 2 authentication method you select, you must either define the resource or the scope. The OAuth 2 token authentication type requires you to specify a token which is a bearer token used to log into the Azure Functions environment. The third type is the token from file authentication type which requires you to specify the file in which the token is stored. If you are using a proxy in your environment, you can specify the proxy host name, port, username, and password in the proxy section.

Once the connection object is defined, you can create an execute function job. The connection drop-down list lets us select the appropriate connection object. Following the connection input, the job requires the Function App. Select the appropriate option from the picker dialogue. Next, the function parameter specifies the function type which you need to select from the picker dialogue. Then the optional query string parameter which refers to the part of a URL after the question mark which includes key-value pairs that send extra data to the function. Doing so allows you to dynamically modify the function's behavior based on the provided parameters in the URL itself. If you choose the anonymous function, you don't need to provide any details. Lastly, we need to provide the HTTP method. Select an appropriate method from the picker dialogue. For this demo, we have selected the GET HTTP method. Everything is configured now, so we can execute the job.

Let's go to the executions view. It shows the list of executions in Automic Automation. As you can see, this is the job we have created, and it ended OK.

If you go to the details, the details pane shows the status field which tracks the job status in the target environment. The job has been completed successfully. The details panel displays object variables and "response#" which provides the execution status of the particular function.

Let's have a look at the reports. The report captures the final response we received. The agent log lists all the connection details followed by the job inputs and execution logs. Finally, we see that the job was executed successfully. Let's check the invocation status in the Azure functions environment. Here you can see that the count has increased and it has completed successfully.

That wraps up the demo on how Atomic Automation can integrate with Azure Functions to run, execute, and monitor execute function jobs.

Note: This transcript was generated with the assistance of an artificial intelligence language model. While we strive for accuracy and quality, please note that the transcription may not be entirely error-free. We recommend independently verifying the content and consulting with a product expert for specific advice or information. We do not assume any responsibility or liability for the use or interpretation of this content.