如何在Graph API请求中动态添加邮件收件人（Azure Automation场景）

一、解决动态收件人问题 #

直接修改邮件Runbook的参数设计，用数组接收收件人，过滤无效值后再转换为Graph API要求的格式，彻底解决固定收件人数量的限制：

1. 调整邮件Runbook的参数定义
   把原来固定的$toAddress1、$toAddress2替换为数组类型的$ToRecipients，让调用方可以传入任意数量的收件人地址。

2. 过滤并转换收件人格式
   在邮件Runbook内先过滤空值、格式无效的地址，再将有效地址转换为Graph API要求的嵌套对象格式。

完整代码示例：

# 邮件Runbook的参数定义
param(
    [Parameter(Mandatory=$true)]
    [string[]]$ToRecipients,
    [Parameter(Mandatory=$true)]
    [string]$Subject,
    [Parameter(Mandatory=$true)]
    [string]$BodyContent,
    [Parameter(Mandatory=$false)]
    [string[]]$CcRecipients = @() # 可选：添加抄送参数
)

# 过滤无效收件人（保留符合邮箱格式的地址）
$validToRecipients = $ToRecipients | Where-Object { $_ -match "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$" }
$validCcRecipients = $CcRecipients | Where-Object { $_ -match "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$" }

# 校验有效收件人数量
if (-not $validToRecipients) {
    throw "未提供有效的收件人地址"
}

# 转换为Graph API要求的收件人结构
$graphToRecipients = $validToRecipients | ForEach-Object {
    @{
        emailAddress = @{
            address = $_
        }
    }
}

$graphCcRecipients = $validCcRecipients | ForEach-Object {
    @{
        emailAddress = @{
            address = $_
        }
    }
}

# 构建Graph API请求体
$mailRequest = @{
    message = @{
        subject = $Subject
        body = @{
            contentType = "Text" # 可改为"HTML"支持富文本
            content = $BodyContent
        }
        toRecipients = $graphToRecipients
        ccRecipients = $graphCcRecipients
    }
    saveToSentItems = $false
} | ConvertTo-Json -Depth 4

# 后续调用Graph API发送邮件的逻辑...

3. 调用方传参示例
   调用Runbook时直接传入收件人数组，数量可动态调整：

# 动态生成收件人列表（比如从自动化变量、配置文件读取）
$recipients = @("ops-team@contoso.com", "admin@contoso.com")

# 调用通用邮件Runbook
Start-AzAutomationRunbook -AutomationAccountName "Your-Account-Name" `
                          -Name "Send-Generic-Mail" `
                          -Parameters @{
                              ToRecipients = $recipients
                              Subject = "Runbook执行完成通知"
                              BodyContent = "XX任务已执行，状态：成功"
                          }

二、最佳方案分析 #

不建议让每个调用方构建Graph API请求参数，应该让邮件Runbook作为通用组件封装所有Graph调用细节：

• 如果让调用方构建Graph参数，相当于把邮件发送的逻辑分散到各个Runbook里，违背了“通用组件”的设计初衷——后续Graph API格式变更时，需要修改所有调用方的代码，维护成本极高。
• 正确的做法是：调用方只需要传递业务层面的简单参数（收件人数组、主题、正文等），邮件Runbook负责参数校验、格式转换、API调用、异常处理等底层逻辑。这种设计下，所有调用方无需了解Graph API的细节，组件的可维护性和复用性最强。

额外优化建议：

• 给邮件Runbook添加异常捕获逻辑，比如Graph API调用失败时自动重试或记录详细日志。
• 支持更多可选参数，比如邮件优先级、附件（如果需要），进一步提升组件的通用性。

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