One of the newer commands added to the #d365fo.integrations module is the Invoke-D365ODataEntityAction, which can call OData actions. This is neat, because it allows us to automate more. In this post I’ll briefly describe how to use it.
Be mindful of case-sensitivity on entity names, actions etc. when using the modules.
In order to find entities with actions, use the Get-D365OdataPublicEntity and filter the results down to one that you want to take action on:
|
1 2 |
$entities = Get-D365ODataPublicEntity $entities | Where-Object {$_.Actions -ne $null} | Format-Wide |
I’ll use the DualWriteProjectConfigurations as an example and dive into that:
|
1 2 3 4 |
#1. Find the entity: Get-D365ODataPublicEntity -EntityNameContains DualWriteProjectConfigurations #2. List the actions: Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Format-Wide |
The DualWriteProjectConfigurations entity has the following actions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
PS C:\> Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Format-Wide ValidateCurrentUserRole WriteToEntityBatch ValidateAppUsers UpdateDualWriteSetupParameters GetPrimaryCompanyContextForDWEntity ResolveManualReconciliationData GetDualWriteSetupParameters SetupDualWriteReconciliation ApiVersion StopDualWriteReconciliation ReconcileTransaction RunDocumentAction GetTransactionsToReconcile RemoveTransactionBreadCrumb RebuildCache GetManualReconciliationData ScheduleDualWriteAutoResume ClearCacheForDWProject StopDualWriteAutoResume ClearAllCache WriteToEntity |
Lets expand two of the actions, ValidateCurrentUserRole and ValidateAppUsers
|
1 2 3 4 5 6 7 8 |
#3. Expand one of the actions: Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Where-Object {$_.Name -eq "ValidateCurrentUserRole"} #4. Expand the parameters on this action: Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Where-Object {$_.Name -eq "ValidateCurrentUserRole"} | Select -ExpandProperty Parameters #5. Lets check out another action that does have a parameter: Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Where-Object {$_.Name -eq "ValidateAppUsers"} #6. and check out the parameters: Get-D365ODataPublicEntity -EntityName DualWriteProjectConfigurations | Select -ExpandProperty Actions | Where-Object {$_.Name -eq "ValidateAppUsers"} | Select -ExpandProperty Parameters |
The ValidateCurrentUserRole does not have any parameters. What you will see in PowerShell is a default parameter that you do not have supply in your payload. The second action I expanded does have 1 parameter, but still shows the default one. In our payload to the ValidateAppUsers action, we only have to supply 1 parameter, the appIds.
Lets try out the new commands from #d365fo.integrations: Invoke-D365ODataAction with these two actions
Here’s the small test I did.
|
1 2 3 4 5 |
$disabled_appid = '{ "appIds" : "00000000-0000-0000-0000-000000000000"}' Invoke-D365ODataEntityAction -EntityName DualWriteProjectConfigurations -Action ValidateAppUsers -Payload $disabled_appid #The below app id is one of the DualWrite app ids that must be set up: $enabled_appid = '{ "appIds" : "2e49aa60-1bd3-43b6-8ab6-03ada3d9f08b"}' Invoke-D365ODataEntityAction -EntityName DualWriteProjectConfigurations -Action ValidateAppUsers -Payload $enabled_appid |
I hope Microsoft adds more endpoints we can use to validate, verify and set up configuration through automation, so that we can spend less time doing non-value-adding tasks.
Remember, you can find the #d365fo.integrations module here: https://github.com/d365collaborative/d365fo.integrations.
Stay safe out there.