At this moment, I’m working on an Extension for Dynamics 365. One of the requirements is basically “publish an interface to an external packet”. In other words: “publish a bunch of web services”.
Now, I’m always trying to find the “best practice” for different circumstances. That’s also why I’m so deep into PowerShell – I think we should automate these “Best Practices” as much as possible ;-).
But in this case – handling web services for Extensions – I still haven’t found one – so it has become kind of a workaround instead of a best practice.
A WebService should be part of the codebase
As said, we are developing an extension. And part of this extension is a bunch of web services. The way to make this possible in an extension is to export the webservices to a package with the PowerShell cmdlet “Export-NAVAppTenantWebService“.
In the background, it’s going to export some data from the “Web Service” table (well .. not really that table, but that’s not important for this blogpost) to an xml file. In short: it’s going to do an export, based on data in the DEV environment.
Now .. this “data” should be part of the code. Why? Well, just assume when someone “forks” into the codebase, he probably needs to set up a new DEV environment, apply the deltas, .. and generate the Web Services .. . Because they need to exist at the moment he’s going to build and test the extension.
In a way, I always try to do this with PowerShell (as you might have figured…), because basically I build a DEV environment with PowerShell – and the scripts that are responsible for that, are part of the source code management of my Extension – so the creation of data like this is still “sourcecontrolled” (if that’s a word at all).
How can we generate these web services?
Well, we have the “New-NAVWebService” PowerShell CmdLet that comes out of the box. Unfortunately, this doesn’t give us what we want. Because what we want, is to be able to generate a “tenant”-webservice .. basically a webservice where the “App Tenants” flag is “false”, like:
The “New-NAVWebService” cmdlet doesn’t do this.. . It creates a normal webservice. And that’s not good. We would have to manually change the flags to be able to export it to the xml.. .
Is there a solution?
Well, I didn’t solve this in a way I feel comfortable with, because I just can’t think of a decent way on how to work around this. In C/AL, it is possible to create the Web Services with code like this:
Where the “WebServiceAggregate” is a variable of the Record “Web Service Aggregate” which is temporary (important!)!
So how can I create this is in PowerShell – well, I would be able to:
But really .. that’s not cool, right? Anyway, you can find a raw version on my github.. . I tested it .. it does work .. but it really feels like it shouldn’t ;-).
So my actual (current) workaround is a simple one. Publish the web services (based on a certain prefix), and open the web service page. Then you should manually de-select the “All Tenants” checkmark for all concerning web services.
I made this into a PowerShell script that I include in every single Extension:
In my opinion, this is a part where Microsoft shoud come in and foresee a “New-NAVTenantWebService” CmdLet or whatever.. . Should be easy.
If anyone has a better solution – please share :-).