.png)
Azure Functions Integration Guide
Azure Functions integrates with enterprise systems through HTTP endpoints, Azure service events, messaging triggers, storage bindings, and durable serverless orchestration.
Azure Functions integration options at a glance
Azure Functions supports HTTP-triggered endpoints, Azure management REST APIs, event-driven triggers, messaging integrations, Blob Storage processing, and database access through bindings or SDKs. HTTP endpoints can receive requests from Martini or call a Martini API, while Event Grid, Service Bus, Event Hubs, Queue Storage, Blob Storage, Cosmos DB change feed, and timers can start function execution. Durable Functions adds asynchronous orchestration, retries, checkpoints, and fan-out/fan-in processing. Martini can consume these endpoints, expose APIs for Azure Functions, map and validate payloads, coordinate long-running workflows, and externalize function keys, OAuth credentials, and other secrets.
| Integration point | Supported by Azure Functions? | Common use cases | How Martini supports it |
|---|---|---|---|
| HTTP and REST APIs | Yes | HTTP-triggered functions expose REST-style operations, webhook receivers, callbacks, and synchronous custom processing. Azure management REST APIs can manage Function Apps, functions, configuration, and deployment slots. | Martini can consume an HTTP-triggered function or expose a REST API for Azure Functions to call. Workflows can map payloads, handle status codes, and apply reusable error policies. |
| Webhooks and outbound callbacks | Limited | HTTP-triggered functions can receive webhook-style requests, and Azure Event Grid can deliver events to HTTP endpoints. Azure Functions does not provide a universal webhook catalog for every function or resource. | Martini can receive HTTP event deliveries through an exposed API or call a function callback endpoint, with validation, deduplication, and routing in a workflow. |
| Events and messaging | Yes | Functions can be triggered by Event Grid, Service Bus, Event Hubs, Queue Storage, Blob Storage, Cosmos DB change feed, and timers, subject to runtime and extension configuration. | Martini can consume HTTP notifications from functions, invoke function endpoints, and orchestrate workflows around event or messaging-driven processing where the relevant endpoint is accessible. |
| Bulk, asynchronous, and batch processing | Limited | Durable Functions supports stateful orchestration, retries, checkpoints, fan-out/fan-in processing, and asynchronous status polling. It is not a general-purpose bulk API. | Martini can start an orchestration, store a correlation ID, poll a status endpoint, or receive a completion callback while coordinating enterprise-side processing. |
| File and storage processing | Limited | Blob triggers and bindings allow functions to read and write files, exports, documents, and other binary content stored in Azure Blob Storage. | Martini can process accessible files or invoke a function that retrieves them, then validate, transform, and route CSV, JSON, XML, or Excel content. |
| Database and service access | Limited | Bindings and SDKs support services including Azure Cosmos DB, Azure SQL, Azure Table Storage, Azure Cache for Redis, and Azure Storage. The precise model depends on the service and extension. | Martini can call a function that performs Azure resource operations or connect directly to a supported database when the required Martini configuration is available. |
| Authentication | Yes | Function endpoints can use anonymous access, function or host keys, Microsoft Entra ID, OAuth 2.0, OpenID Connect, and network restrictions. Management APIs generally use Entra ID bearer tokens. | Martini can externalize keys, tokens, client credentials, and endpoint configuration through secured environment configuration and secrets management. |
| SDKs and custom code | Yes | Functions support runtimes including .NET, Java, JavaScript or TypeScript, Python, and PowerShell, with Azure SDKs and third-party libraries subject to hosting and runtime compatibility. | Martini can delegate Azure-specific or custom processing to a function and orchestrate the resulting request, response, validation, and downstream integration logic. |
How Azure Functions exposes data and business events
Azure Functions HTTP APIs
HTTP-triggered functions expose HTTPS endpoints that can implement REST-style operations, synchronous processing, custom callbacks, or controlled webhook receivers. Azure also provides management REST APIs for Function Apps and related resources.
Martini implementation pattern
Martini implementation pattern: Martini consumes the function endpoint with an API workflow, externalizes the endpoint and credentials, maps the request to the function contract, evaluates the HTTP response, and routes successful or failed outcomes.
Implementation sequence
Azure Functions events and messaging
Functions can start from Event Grid, Service Bus, Event Hubs, Queue Storage, Blob Storage, Cosmos DB change feed, or timer triggers, depending on runtime and extension configuration. Event availability is determined by the source service rather than by a universal Functions webhook catalog.
Martini implementation pattern
Martini implementation pattern: an HTTP-triggered function can normalize or filter the source event and call a Martini API, allowing Martini to validate event identifiers, apply business rules, and coordinate downstream systems.
Implementation sequence
Azure Functions webhooks and callbacks
An HTTP-triggered function can receive webhook-style requests, and Azure Event Grid can deliver notifications to HTTP endpoints. Functions does not automatically publish webhook events for every function or Azure resource.
Martini implementation pattern
Martini implementation pattern: Martini can expose an authenticated REST endpoint for an Azure Function or Event Grid delivery, then acknowledge or process the request according to the source contract while preventing duplicate business actions.
Implementation sequence
Durable Functions orchestration
Durable Functions supports stateful orchestration, activity functions, timers, retries, checkpoints, fan-out/fan-in processing, and asynchronous status polling for long-running work.
Martini implementation pattern
Martini implementation pattern: Martini starts or requests an orchestration, stores the correlation identifier, and either polls a status endpoint or receives a completion callback before mapping the final result to enterprise systems.
Implementation sequence
Azure Blob Storage processing
Blob triggers and bindings allow a function to process files and binary content stored in Azure Blob Storage. This is a storage-binding capability rather than a general-purpose attachment API.
Martini implementation pattern
Martini implementation pattern: a Blob-triggered function can notify Martini about a file event, after which Martini retrieves or processes the accessible file, validates its structure, maps its contents, and routes the result.
Implementation sequence
Common Azure Functions integration patterns
Pattern 1: Invoke a custom Azure Function from Martini
When to use this pattern
Use this pattern when enterprise workflows need Azure-specific SDK functionality, custom document processing, organization-specific logic, or access to resources that are not directly exposed to Martini. Martini remains responsible for request validation, orchestration, and downstream handling.
Integration direction
Example Mapping
| Azure Functions Field | Canonical Field | Target Field |
|---|---|---|
| requestId | correlationId | correlationId |
| payload | inputData | functionInput |
| operation | processingType | operation |
| requestedBy | initiator | caller |
Martini implementation pattern
A Martini workflow receives the source request, validates required fields, transforms the canonical payload into the function contract, and invokes the HTTP endpoint. It evaluates status codes, applies bounded retries only to transient failures, and routes successful results or terminal errors using the correlation ID.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Send Azure events into an enterprise workflow
When to use this pattern
Use this pattern when Event Grid, Service Bus, Blob Storage, Cosmos DB change feed, or another supported Azure source should initiate centralized validation, enrichment, synchronization, or routing.
Integration direction
Example Mapping
| Azure Functions Field | Canonical Field | Target Field |
|---|---|---|
| id | eventId | externalEventId |
| eventType | eventType | sourceEventType |
| subject | resourceReference | sourceReference |
| data | eventPayload | businessPayload |
Martini implementation pattern
The Azure trigger processes or normalizes the source event and calls a secured Martini API. Martini validates the event contract, checks the event ID or message ID for duplicates, enriches the payload when needed, applies routing rules, and performs an idempotent target write.
Martini capabilities used
- API exposure
- workflows
- data mapping
- validation
- business rules
- error handling
Pattern 3: Process files through Blob-triggered functions
When to use this pattern
Use this pattern for CSV, JSON, XML, Excel, document, or other file workflows where Azure Blob Storage is the durable file location and Martini must validate, transform, and distribute the content.
Integration direction
Example Mapping
| Azure Functions Field | Canonical Field | Target Field |
|---|---|---|
| blobPath | fileReference | sourceFile |
| contentType | fileFormat | format |
| eTag | sourceVersion | fileVersion |
| content | fileData | mappedPayload |
Martini implementation pattern
A Blob-triggered function sends Martini a file reference or accessible payload. Martini verifies the source version or blob identifier, retrieves the content when required, parses and validates the file, maps rows or document fields, and routes valid results while isolating malformed files for review.
Martini capabilities used
- workflows
- file processing
- JSON handling
- XML handling
- data mapping
- validation
- error handling
Pattern 4: Coordinate Durable Functions with Martini
When to use this pattern
Use this pattern when Azure-specific work is long-running, requires checkpoints or fan-out/fan-in execution, and enterprise systems must be coordinated through centralized mappings, business rules, and error routing.
Integration direction
Example Mapping
| Azure Functions Field | Canonical Field | Target Field |
|---|---|---|
| workflowRequestId | correlationId | orchestrationInstanceId |
| status | processingStatus | workflowStatus |
| result | completedData | businessResult |
| failure | errorDetails | integrationError |
Martini implementation pattern
Martini submits the orchestration and stores its correlation identifier. A scheduled workflow polls status or receives a completion callback, then maps the final result to the target application. Transient communication failures are retried with limits, while failed orchestration instances are routed for operational handling.
Martini capabilities used
- workflows
- API consumption
- scheduling
- correlation management
- data mapping
- error handling
Applications commonly integrated with Azure Functions
Azure Functions commonly participates in event-driven architectures alongside Azure services and Microsoft workflow products. Martini can coordinate these endpoints, normalize event payloads, apply enterprise rules, and route results to downstream systems without placing all orchestration logic inside individual functions.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Azure Event Grid | Deliver resource and application events to serverless handlers and route selected events into enterprise workflows. | Azure Event Grid → Azure Functions → Martini | Martini can receive a normalized callback from an HTTP-triggered function, validate the event ID, transform the event payload, and route it to downstream applications with idempotency controls. |
| Azure Service Bus | Process queues and topics for reliable, decoupled enterprise messaging and asynchronous commands. | Azure Service Bus → Azure Functions → Martini | A Function can consume or publish Service Bus messages while Martini manages enterprise validation, enrichment, routing, retries, and calls to external APIs. |
| Azure Blob Storage | Process uploaded files, exports, documents, and generated artifacts through triggers and bindings. | Azure Blob Storage → Azure Functions → Martini | A Blob-triggered function can notify Martini of a new file; Martini retrieves or receives the file, validates its format, maps its contents, and routes the result to target systems. |
| Azure Cosmos DB | React to document changes and execute serverless processing around NoSQL data. | Azure Cosmos DB → Azure Functions → Martini | Cosmos DB change-feed processing can invoke a function that sends normalized changes to Martini, where business rules, deduplication, and downstream synchronization are applied. |
| Azure SQL Database | Support database-backed processing, synchronization, and access to relational application data. | Azure SQL Database → Azure Functions → Martini | A function can perform Azure SQL operations and call Martini, or Martini can invoke the function over HTTPS and map the response into an enterprise workflow. |
| Azure Logic Apps | Combine Logic Apps workflow actions and service integrations with custom serverless processing in Functions. | Azure Logic Apps → Azure Functions → Martini | Logic Apps can call an HTTP-triggered function for custom processing, while Martini can centralize validation, transformation, routing, and integration with systems outside the Azure workflow. |
| Microsoft Power Automate | Expose custom serverless operations to business workflows through HTTP endpoints or custom connector configurations. | Microsoft Power Automate → Azure Functions → Martini | Power Automate can invoke a secured function endpoint, which can then call a Martini API for canonical processing and controlled access to enterprise systems. |
How to build a Azure Functions integration in Martini
Objective
Establish access to the Azure Functions endpoint, management API, or Martini API using the authentication model appropriate to the integration.
Instructions in Martini
- Identify whether the flow uses an HTTP-triggered function, Azure management API, event delivery, or a Martini API.
- Configure HTTPS endpoints and externalize function keys, OAuth credentials, Entra ID settings, and other secrets.
- Use least-privilege permissions and avoid administrative keys in workflow parameters or logs.
Objective
Select the event, API, callback, or schedule that should start the integration workflow.
Instructions in Martini
- Use an API request for synchronous invocation.
- Use an HTTP callback when an Azure Function or Event Grid delivers an event to Martini.
- Use a scheduler for polling Durable Functions status or reconciling missed events.
- Define the expected acknowledgment and timeout behavior.
Objective
Obtain the function response, event payload, file reference, or orchestration result required by the workflow.
Instructions in Martini
- Receive the HTTP request or callback and validate its source.
- Retrieve a referenced Blob Storage file or call the function for the current result when required.
- Store correlation IDs, event IDs, message IDs, blob versions, or orchestration instance IDs.
Objective
Coordinate Azure processing with enterprise applications, services, and business rules in a maintainable Martini workflow.
Instructions in Martini
- Separate transport handling from transformation and business decisions.
- Route events or results to the appropriate downstream process.
- Use asynchronous execution or queues when work should not remain on a synchronous HTTP request.
Objective
Convert the Azure-specific payload into a canonical model and validate it before downstream writes.
Instructions in Martini
- Map function request and response fields to the canonical integration model.
- Validate required fields, schema versions, file formats, and event identifiers.
- Apply conditional routing and enrichment rules before calling target systems.
Objective
Persist or publish the transformed result in the required enterprise applications, databases, files, or APIs.
Instructions in Martini
- Perform idempotent writes where the source can redeliver events.
- Return or publish the required response to Azure Functions when the flow is synchronous.
- Record the target identifier and correlation information for later reconciliation.
Common Azure Functions data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Function App | Azure resource hosting one or more functions with shared configuration, scaling, identity, and deployment settings. | Azure Resource Manager, deployment pipelines, monitoring platforms | Martini can consume management APIs to inspect or manage Function App information when the calling principal has appropriate Azure permissions. |
| Function | An individual executable operation exposed through a trigger, often as an HTTP endpoint or event handler. | Enterprise APIs, Azure services, workflow platforms | Martini can invoke an HTTP-triggered function, pass mapped payloads, process responses, and expose an API that a function calls. |
| Trigger | The request, timer, event, or message that starts function execution, such as an HTTP request, Event Grid event, or Service Bus message. | Event Grid, Service Bus, Event Hubs, Queue Storage, Blob Storage, Cosmos DB | Martini can receive normalized HTTP deliveries from a function or initiate workflows based on scheduled and API-driven integration events. |
| Binding | A declarative connection between a function and an input or output resource such as Blob Storage, Cosmos DB, Azure SQL, Queue Storage, or Service Bus. | Azure Storage, Azure Cosmos DB, Azure SQL, Service Bus | Martini treats binding-produced payloads as integration inputs or outputs, applying validation, mapping, transformation, and downstream routing. |
| Deployment slot | A separate Function App deployment environment used for staging and controlled promotion. | Azure Function App, deployment pipelines, release management | Martini can call management endpoints involved in deployment workflows and coordinate post-deployment validation where the required Azure permissions are available. |
| Durable orchestration instance | A stateful long-running workflow instance with checkpoints, activities, timers, retries, or fan-out/fan-in execution. | Azure Functions, enterprise applications, Martini workflows | Martini can start an orchestration, retain its correlation identifier, poll status, receive completion callbacks, and route failures for review or retry. |
Authentication and security considerations
Use identity-based access where appropriate
Microsoft Entra ID, OAuth 2.0, and managed identities provide stronger identity-based controls than shared keys for suitable production integrations. Function keys remain available for scenarios where their security model is appropriate.
Protect secrets and network paths
- Store function keys, client secrets, tokens, and endpoint configuration in secured Martini environment configuration and secrets management.
- Do not expose admin or master keys in workflows, URLs, or logs.
- Use HTTPS, least-privilege Azure roles, network restrictions, private endpoints, and IP controls where required.
Operational considerations for Azure Functions integrations
Plan for delivery and scale behavior
- Account for hosting-plan limits, cold starts, concurrency, HTTP timeouts, downstream throttling, and source-service delivery behavior.
- Use bounded retries for transient failures and avoid retrying non-transient HTTP errors.
- Use event IDs, message IDs, blob versions, or business keys to make downstream writes idempotent.
- Define pagination explicitly for collection responses and use Blob Storage or another durable store for large payloads.
Manage contracts and observability
Function request and response schemas are application-defined, while event schemas, binding extensions, and runtime versions can change independently. Use versioned contracts, confirm runtime compatibility, and carry correlation IDs across Martini and Azure Functions. Monitor invocation IDs, event identifiers, response codes, workflow logs, and retry outcomes without logging credentials or sensitive payloads.
Why use Martini instead of scripts or point-to-point integrations?
Centralize orchestration around serverless code
Scripts can invoke a function, but Martini provides a maintainable workflow layer for authentication, validation, mapping, business rules, routing, retries, and downstream API coordination. This keeps Azure-specific execution in Functions while making enterprise integration behavior visible and reusable.
Separate platform execution from enterprise integration
Martini can expose a stable API façade for Azure Functions, consume function responses, coordinate Durable Functions status, and process event or file notifications. This reduces point-to-point coupling and supports consistent monitoring, error handling, and environment-specific configuration.
- Reuse workflows and mappings across multiple functions and Azure services.
- Apply consistent idempotency, correlation, and retry policies.
- Change target systems or business rules without rewriting every function.
Frequently asked questions
Azure Functions can integrate through HTTP-triggered REST-style endpoints, Azure management APIs, Event Grid and messaging triggers, Blob Storage processing, database bindings or SDKs, and Durable Functions orchestration. Enterprise systems can call functions directly, or functions can call a Martini API for centralized validation, transformation, routing, and synchronization.
Yes. Martini can consume an Azure Functions HTTP endpoint, process responses and status codes, receive HTTP-based event deliveries through an exposed Martini API, and coordinate Durable Functions, files, and Azure service events using workflows and APIs.
No. A dedicated Azure Functions connector is not required. Martini can use Azure Functions HTTP endpoints, management APIs, HTTP-based event delivery, Blob Storage references, authentication mechanisms, and other confirmed Azure service endpoints.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Azure Functions. The integration is subject to the provisioned capacity of the Martini environment. Separate Azure, infrastructure, hosting, execution, storage, networking, or other third-party charges may apply.
Use HTTP-triggered functions for request-response operations and controlled callbacks, event or messaging triggers for decoupled processing, Blob Storage bindings for file workflows, and Durable Functions for long-running or stateful Azure-side work. Azure management APIs are appropriate for controlled Function App administration using Entra ID permissions.
HTTP-triggered functions can receive webhook-style requests, and Azure Event Grid can deliver notifications to HTTP endpoints. However, Azure Functions does not automatically publish webhook events for every function or Azure resource; event coverage depends on the source service and its event-subscription support.
Use Durable Functions, queues, or a submit-and-status pattern for long-running work. Martini can store a correlation ID, poll status, or receive a completion callback. Event IDs, message IDs, blob versions, or stable business keys should be used for idempotency because retries and event delivery can produce duplicates.
Yes. Martini can expose a secured REST API that Azure Functions call after an event, timer, queue message, or custom operation. The API can provide a stable enterprise contract while Martini handles authentication, validation, mapping, routing, downstream calls, and error responses.
Related Martini documentation
Workflows
Data
Connect Azure Functions with Martini
Use Martini to orchestrate Azure Functions endpoints, events, files, and durable processing with secure configuration, reusable workflows, enterprise data mapping, and consistent operational controls.