FTP加密CSV文件转Azure Blob存储的最优方案咨询

Great question! Let's break this down step by step to find the optimal solution for your workflow.

First: Is Logic Apps a Suitable Choice? #

Absolutely. Logic Apps is perfect for this scenario:

• You already have an FTP trigger set up, which aligns perfectly with its event-driven, low-code integration model.
• It handles the orchestration of your entire workflow (trigger → process → store) without needing to manage server infrastructure.
• You can easily add error handling, retries, or notifications (e.g., alert if decryption/upload fails) with built-in actions.

Comparing Your Processing Options: The Winner is Azure Function #

Let's evaluate each option to see why Azure Function stands out:

1. Azure Function (Optimal Choice) #

This is the best fit for your requirements, and here's why:

• Event-Driven & Serverless: It integrates seamlessly with Logic Apps via the built-in Azure Function connector. Your FTP trigger in Logic Apps can directly invoke the function as soon as a new file is detected, with pay-as-you-go pricing (you only pay for compute time used, which is minimal for small MB-sized files).
• Simplified Decryption & Routing: You can write clean, focused code to decrypt only the specified CSV columns, parse column1 to determine the Blob folder path, and use the Azure.Storage.Blobs SDK to upload directly to the correct container hierarchy (e.g., your-container/{column1-value}/decrypted-file.csv).
• Low Maintenance: No servers to manage, auto-scaling based on load, and easy integration with Azure services like Key Vault (to securely store your decryption keys, avoiding hardcoding).
• Extensibility: If you need to add future enhancements (like CSV validation, logging, or transforming other fields), you can update the function without reworking your entire Logic Apps orchestration.

2. Web Job (Not Recommended) #

Web Jobs are tied to an App Service plan, making them a poor fit here:

• They require either continuous running (wasting resources when no files are processed) or scheduled triggers (which don't align with your "FTP file added" event model). You'd have to build custom logic to listen for new files, adding unnecessary complexity.
• Higher cost: Even idle Web Jobs consume App Service resources, which is inefficient for an event-driven workflow like yours.
• Integration with Logic Apps is clunkier compared to Azure Functions—you'd need to set up HTTP endpoints or queue triggers manually.

3. HttpRequest (Custom API) #

If you're considering building a custom HTTP API (e.g., on App Service), this is less ideal than Azure Functions:

• You'd have to manage server scaling, security, and maintenance for the API, which adds overhead that serverless Functions eliminate.
• While you could call the API from Logic Apps, Functions provide a more streamlined, purpose-built solution for short-lived, event-triggered tasks like your decryption/routing step.

Recommended Workflow #

Here's the step-by-step setup to implement this:

1. Keep your existing Logic Apps FTP trigger: Configure it to monitor the correct FTP folder and filter for CSV files.
2. Create an Azure Function:
   • Choose a runtime (C#, Python, or Node.js—pick what you're most comfortable with).
   • Write logic to:
     • Receive the CSV file content/stream from Logic Apps.
     • Decrypt only the specified columns (ensure decryption keys are stored in Azure Key Vault).
     • Parse column1 to define the target Blob folder path.
     • Upload the decrypted CSV to the Azure Blob Storage container at the constructed path.
3. Connect Logic Apps to the Function: Use the "Azure Function" action in Logic Apps to pass the FTP file data to your function.
4. Add error handling: In Logic Apps, add actions like "Send Email" or "Create Blob in Error Folder" if the function call or upload fails.

内容的提问来源于stack exchange，提问作者Haithem KAROUI