Azure functions are based on a serverless execution model (it is the equivalent of Amazon Lambda) and extend the concept of a PaaS (which abstracts from the infrastructure details and facilitates auto-scaling). In addition, serverless has a pay-per-execution system.
In summary, the benefits of Serverless are as follows:
- Automatic scaling
- Reduction of time to market
- Agile deployment
- Pay-per-use
(Gartner) "Serverless architectures enable developers to focus on what they should be doing –writing code and optimizing application design– making way for business agility and digital experimentation."
In general, we want to solve scenarios where we want data processing to react to "events;" also, we want to pay only for the resources that are consumed. Data processing can be triggered as a cron, or react to a trigger. There are different types of triggers (e.g.: Timer, Queue, Service Bus, etc).
For more information, see Azure Functions triggers and binding concepts.
They are timed functions. One possible scenario is updating the merchandise stock or updating the redundancies of a DB.
They are not suitable for long-running batch procedures.
The time can be configured using an Ncrontab expression, or a TimeSpan expression.
The properties to configure the cron Time are Schedule Ttme format {"Time value expression","App setting property name and value"}. If the first option is selected, you have to configure "Schedule Time value" proeprty. Otherwise, configure the app setting name and value to be defined in the cloud, through "App setting property name" and "App setting property value" properties.
Depending on the function, it is preferable to be able to change some settings in the cloud. Those settings are configured at deployment time, and you have the option to tell the deployment engine to create an application setting in the cloud with the name and value you specify.
For example, for timer functions, you can specify a cron time, or an application setting (to be created in the cloud with the name and value that you wish).
For the last option, the advantage is that any changes can be done in the cloud (you don't need to deploy again for those changes).
The same happens with other function types like Queue or Service Bus, where the connection data is defined as an app setting.
For any function, you have to create a GeneXus procedure following some requirements in its parm rule.
parm(in:&EventMessages,out:&EventMessageResponse);
parm(in:&RawData,out:&EventMessageResponse); // RawData is a char parameter
For more information, see How to: create a GeneXus procedure to be deployed as an Azure Function.
- Install the requirements in the machine where you will run the deployment: you just need Azure CLI (version 2.12.1 or higher).
Otherwise, the deploy throws the error: 'az' is not recognized as an internal or external command, operable program or batch file.
- Create a Deployment Unit object with only one main procedure. Procedures have nothing particular in their logic, except considering the parameters they receive according to the function trigger.
- Use the Application Deployment tool to select the target of the Azure functions.
- Configure the properties in the property grid.
When the function is published on an existing function app, the function is updated.
The behavior of all functions within the App function can be configured globally. This is done in the host.json file. For example, in that file, you can configure the trace level for the app, Health Monitor, etc.
Azure functions have a default timeout, which can also be changed at the host.json file.
Important: The GeneXus user has to manage this file.
The Application Deployment Tool uploads one with the basic settings, but if you want to use another you can edit it and add it to the deployment unit (see here).
{
"version": "2.0",
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Trace",
"Host.Results": "Trace",
"Function": "Trace",
"Host.Aggregator": "Trace"
},
"applicationInsights": {
"samplingExcludedTypes": "Request",
"samplingSettings": {
"isEnabled": true
}
}
}
}
When publishing in the Linux Operating System, if the Function app is down, it throws the following error:
Error publishing to Azure Functions: ServiceError: Operation returned an invalid status code 'Bad Request'
Failed: Deploy Application
When publishing to Linux Operating System, for Timer trigger functions only, the upload operation in the cloud throws "ServiceError: Unknown error", despite it has finished successfully.
Since GeneXus 17 upgrade 3
- For now, it is possible to publish only one function at a time.
- Only Timer-Triggered, Queue Storage, and Service Bus functions are supported.
HowTo: Monitor Azure functions
|