Automatic access verification for AOAI services to develop and run on CAPI/managed AI resources #2764
Conversation
…erification for AOAI services to develop and run on CAPI/managed AI resources
…ces using new method
…ess-verification-rebranch
…access-verification-rebranch
…access-verification-rebranch
…rganized function
christian-andersen-msft
changed the title
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Outdated
Show resolved
Hide resolved
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Show resolved
Hide resolved
| /// This will send the Azure OpenAI call to the deployment specified in <paramref name="ManagedResourceDeployment"/>, and will use the other parameters to verify that you have access to Azure OpenAI. | ||
| /// </summary> | ||
| /// <param name="ModelType">The model type to set authorization for.</param> | ||
| /// <param name="AOAIAccountName">Azure OpenAI account name)</param> |
There was a problem hiding this comment.
Minor: In case of parameters that are not super obvious, I like to add a sample of how they look like in the documentation comment. For example here you could do: An Azure OpenAI account name. For example, if your Azure OpenAI endpoint is "contoso.openai.azure.com", use "contoso" for this parameter.
| end; | ||
|
|
||
| [NonDebuggable] | ||
| procedure SetMicrosoftManagedAuthorization(AOAIAccountName: Text; NewApiKey: SecretText; NewManagedResourceDeployment: Text) |
There was a problem hiding this comment.
Mmmm I suggest we keep the pattern that this file was using before (=> the Set... functions are just setting values, and then we check that the values are valid inside IsConfigured).
This saves us from possible bugs if some other part of the code is changing the authorization variables (and also delays checking the access and the validity of the values until they are actually needed).
Which means, here you just need to set the values for RecourceUtilization, ManagedResourceDeployment, and AOAIAccountName to some global variable. And then you can move the call to VerifyAOAIAccount to inside IsConfigured instead, and you don't need the three boolean variables.
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Show resolved
Hide resolved
| TruncatedAccountName := CopyStr(AOAIAccountName, 1, 100); | ||
|
|
||
| if IsAccountVerifiedWithinPeriod(TruncatedAccountName, CachePeriod) then begin | ||
| Message('Verification skipped (within cache period).'); |
There was a problem hiding this comment.
I guess messages here are also for testing purposes. I think it's still a good idea to log this to telemetry though, so later you can add some Session.LogMessage instead of the Messages.
src/System Application/App/AI/src/Azure OpenAI/AOAIAccountVerificationLog.Table.al
Outdated
Show resolved
Hide resolved
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Outdated
Show resolved
Hide resolved
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Outdated
Show resolved
Hide resolved
src/System Application/App/AI/src/Azure OpenAI/AOAIAuthorization.Codeunit.al
Show resolved
Hide resolved
| ContentHeaders: HttpHeaders; | ||
| Url: Text; | ||
| IsSuccessful: Boolean; | ||
| UrlFormatTxt: Label 'https://%1.openai.azure.com/openai/models?api-version=2024-06-01', Locked = true; |
There was a problem hiding this comment.
Would it make sense to handle this part of the request in platform? We handle other things there like ensuring the calls are aligned on api-version (I know we spoke about this previously so just wondering if there was a better reason for doing this in sys app)
Now we will have to remember to maintain both app and platform when moving to a newer api-version (and in app we would have to HF all minor releases).
Additionally, the verification log could be a system table so all the tracking and gating could be handled there
…uggable, Updated table name with spaces
Fixes AB#535826