Add support enabling multiple virtual tables at a time

[aariste]

For the cmdlets Set-BapEnvironmentVirtualEntity and Update-BapEnvironmentVirtualEntityMetadata, could it be possible to add support to pass a list of entities with their full names, so we modify the properties for all of them?

Is there any API limitation preventing this?

[FH-Inway]

Hey @aariste , glad to see you here 😄

Thanks for the suggestion. I'm not sure if the API can handle multiple entities at once, @Splaxi can probably answer that.

But even if the API cannot, our cmdlets sure could and then just call the API in the background separately for each entity name.

You could probably already right now do something like

$entityNames = ("entity1","entity2")
foreach ($entity in $entityNames) {
    Set-BapEnvironmentVirtualEntity -Name $entity -EnvironmentId 00000000-00...
}

[Splaxi]

Hi @aariste

Thanks for the feedback - we welcome all perspectives and suggestions.

As @FH-Inway points out, by wrapping the current implementation in a loop - you get what you're looking for. But that said...

I was in doubt whether or not to support an array on entities or not.

We are using the Organization.svc SOAP endpoint (😬) - which is fairly new territory for me personally. Because of your question, I found the following blog post:

https://softchief.com/2020/12/22/execute-vs-executemultiplerequest-vs-executetransactionrequest-in-dynamics-365/

Where I just learned about the ExecuteMultipleRequest - which requires a bit more investigation on my side.

[Splaxi]

And we get some cool stuff out of the box it seems:

https://learn.microsoft.com/en-us/power-apps/developer/data-platform/org-service/execute-multiple-requests

https://learn.microsoft.com/en-us/power-apps/developer/data-platform/org-service/execute-multiple-requests#specify-run-time-execution-options

Both ContinueOnError and ReturnResponses seems like something that would make sense, when handling an array of entities.

[Splaxi]

https://blogs.infosupport.com/ms-crm-2015-bulk-update-data-using-powershell/

And here we can learn how to load the DLL files and make it easier in the discovery phase of things. I suggest staying away from the DLL files, as I don't know if we are allow to redistribute these along with the module. So for now we can just use them, to map out how the raw data structure for the SOAP is - and do the implementation based on that.

[Splaxi]

https://github.com/Capgemini/powerapps-specflow-bindings/blob/15f32875846753be8fb25ed754157a3f475baf6a/scripts/Set-AllUserLocalesToUk.ps1#L37

[aariste]

About using the DLLs... I understand the reason to not use them, but I just checked another tool like xrmToolbox and they include them in their package. I'm also using a modified version of AXUtil.dll (which maybe is even worse than using the original DLL 🤣) for the ISVLicenseGenerator tool. I guess that as long as they're used on community-like tools MS is fine with that, but of course they can decide against that at-will.

I'll investigate the PowerShell module from the last comment!