Virtual Tables and Application Lifecycle Management

Generally, I will say that Virtual Tables aren’t yet all the way there when it comes to ALM, and for now we’ll explore some of the reasons behind that opinion.
First, navigate to the solution that contains the objects. I generally like to use the Advanced option of adding required objects.

In this scenario, that will enrich our solution with two objects that the model-driven app depend on. The actual table that we’re reading from and writing to, as well as the Site Map of the Model-Driven App itself.

From here, we’ll export the solution as a managed solution, and change environments with the purpose of simulating a deployment process. Generally, I will always recommend using deployment pipelines for this, since they’re very easy to setup, and they’re a great way to reduce headaches.

As we import our solution on a separate environment, we don’t get any hiccups, except we have to provide the connection to our SQL Database. However, when it attempts to import the solution, we will indeed be met with an error message.

And that is due to the fact that the virtual table definition is not really in the solution, despite us having added dependencies.
Let’s navigate back to our development environment, and add the required objects of the table, so we can proceed without errors.

Adding dependencies

The odd part is, that this action has no effect on the content of our solution. It simply does not do anything. We can repeat the action for both the Site Map and the Connection Reference, but it will have no effect. This is the first point of Virtual Tables immaturity from an ALM perspective.

What we can do however, is we can add the dependency manually, as shown below we want to Add existing, inside Developer and select Virtual table data source.

From here, we’ll highlight the source that we are interested in, add it to our solution, and do the export part all over again.

Changing virtual table sources

Now when importing, it will actually succeed. So, the missing dependency was the Virtual table data source all along. Often, when we deploy from one environment to another we also need to change our source though, and while we’re able to change the connection as we deploy, we don’t actually change the definition of the Virtual table data source. So even though the deployment is a success, it still does not work, assuming we’re actually changing our source. On top of that it gives a lovely generic error message, that does not really solve anything.

The fix however, is quite simple, and another example of immaturity of virtual tables and ALM.
Navigate to the Solutions pane, and Switch to classic.

Once in here, click on the Display Name of the solution, highlighted as a URL.

Once the new window opens, you’ll have to double click your Virtual Entity Data Source – since we’re in the classic view, the naming has also been changed to classic names, at least partially.

Here you need to alter the Dataset Value to follow the syntax <SQL Server Name>,<DB Name>, so that it matches the information of your data source connection in this environment.

Closing thoughts

So there we have it, one minor reason and one somewhat major reason as to why ALM for virtual tables still is a bit immature. The cool part though, is that it is easily fixed, with the above steps. My personal suggestion for dealing with the issues is to deploy the Virtual table data sources in a separate solution, so they’re not overwritten every single time.