New type: subscription

[MartinM85]

Suggestion
I would suggest to add subscription type.

Value
When using Azure Event Grid, I can subscribe to Microsoft Graph API events.

To create a Partner Topic, I need to create a Graph API subscription. the notificationUrl property specifies Partner Topic name, resource group name in which the partner topic is created, region (location) and Azure subscription.

To be able to create a subscription and de facto Partner Topic via Bicep file, will simplify the configuration of Azure Event Grid. Once Partner Topic is created, I can continue with creating event subscriptions for Partner Topic.

Microsoft Graph API REST reference
https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0
https://learn.microsoft.com/en-us/azure/event-grid/subscribe-to-graph-api-events?tabs=http

[dkershaw10]

Thanks for this submission. We'll use to help prioritize this work with the Graph subscription API owners.
@MartinM85 Can you help us understand the value of this operation via Bicep a little more please...

I can see why, with Bicep, there would be one place where you could configure both the Graph events subscription and Azure Event Grid. Since Graph events subscriptions need regular "renewing", would you be looking to redeploy the Bicep file each time the Graph event subscription needs renewing (just with a different expirationDateTime)?

[MartinM85]

Hi @dkershaw10 When the subscription is created with a notificationUrl which defines Event Grid Partner Topic details (Azure subscription, resource group, topic name) then the Event Grid Partner Topic will raise the event microsoft.graph.subscriptionReauthorizationRequired before the subscription is expired.

It's expected that Event Grid Event Subscription (event handler) is created for microsoft.graph.subscriptionReauthorizationRequired event and handler (e.g. Azure Function) will send request to the Graph API to renew the subscription (just with a different expirationDateTime).

[dkershaw10]

Sorry I'm coming back to this late @MartinM85 - so this request is just to support Bicep for the initial subscription creation?

I'm asking because typically folks redeploy Bicep template files on a regular basis - the subscription resource declaration in the Bicep file should represent what is deployed in infrastructure. However, for this resource, expirationDateTime is a required property. When redeploying, you would need to be careful to update this property, or you would either get an error or invalidate the subscription.

Are you sure this is still appropriate for your needs via Bicep? If so, I will put the ask in with the resource owner team.

[andrewconnell]

@dkershaw10 said:

typically folks redeploy Bicep template files on a regular basis

agreed 👆...

but not with this 👇...

the subscription resource declaration in the Bicep file should represent what is deployed in infrastructure

Bicep (and ARM) doesn't represent what is deployed in infrastructure, rather it expresses what the desired state should be in infrastructure. IOW, it represents the desired state config (DSC).

For instance, a Bicep file that represents an Azure Function app should be - the DSC. The first time I run it, I expect it will create the missing resource. If I modify the Bicep file to add/remove environment variable settings, I expect Azure deployment to update the existing resource that's defined... and Azure deployment does exactly that.

So for a subscription, I expect I should be able to define it and it's created. If during my deployment, I include a GUID (for an existing subscription) and a new expiry date, the execution of that template will update the existing subscription with the new expiry.

EDIT: maybe I'm misunderstanding the conversation as I reread your reply and the message you were responding to. Maybe I'm saying what you're saying, just in a different way?

[MartinM85]

So for a subscription, I expect I should be able to define it and it's created. If during my deployment, I include a GUID (for an existing subscription) and a new expiry date, the execution of that template will update the existing subscription with the new expiry.

I agree with this behavior.

[dkershaw10]

Sorry - yes - the declarative file represents the desired state configuration for the infra - my bad.
My point was more that you would need to update the expiryDateTime each time the Bicep file is run (unless you have a variable that can calculate this based on the current date + some offset), otherwise the service is likely to error, because of an invalid expiry time.