search

microsoft / Dynamics365Commerce.Solutions

Repository for hosting the Dynamics 365 Commerce end to end sample solutions
Other
58 stars 26 forks source link

Single installer for multiple extensions for POS #63

Closed emishura closed 1 year ago

emishura commented 1 year ago

Will it be implemented later? e.g. company that was creating in RetailSDK separate extensions for every feature (and currently has 100+ extensions already) has just 2 options now:

madyke commented 1 year ago

Hi @emishura - unless I'm misunderstanding your question, this should already be implemented. Individual extensions can be combined into extension packages, which are bundled up and installed with a single installer (see POS extension basics | Terminology for more info). These extension packages are meant to include all of the extensions that will function together to provide a new end-to-end functionality for POS.

Ultimately, it will be up to the customer to determine which of their individual extensions can be combined into an extension package, based on how they work together and how they want to control serviceability. Combining more extensions into a single extension package will make it easier to deploy changes and updates by reducing the number of packages that have to be managed and the number of installers that have to be created.

For the re-using of code from one project by other extensions, you should be able to consume the "core" project just like any other third-party library (see Consume external or third party libraries like Knockout.js in POS extensions).

emishura commented 1 year ago

@madyke thank you for the comment. But do I get it right that "Combining more extensions into a single extension package will make it easier to deploy changes and updates by reducing the number of packages that have to be managed and the number of installers that have to be created." means that in this case, we should have just 1 installer and 1 csproj with all of our extensions put together? So in POS on the settings page, we will see just 1 extensions package, right? let me show you in standard SDK So, from what I understand. Each 'folder' from old SDK image should become a separate project in new SDK (like this one) image But as far as I understood from other issues. 1 installer project (like bellow) can't have a reference to multiple extension projects image

So this means that we have 2 options. create 100+ installers or have 1 extensions project with everything we have - and it will be displayed as 1 extension and we won't be able to enable/disable single extensions(folders) inside that 1 project (like we did before with tsconfig.json) Am I right?

Also the question here is - if we combine everything in 1 project. won't it be a problem if we had x PostLogOnTriggers(for example) in separate folders in retail SDK (scr below) and how we should specify them in that single combined project's manifest.json file image

madyke commented 1 year ago

Hi @emishura, I've tried to cover all of your topics below, let me know if this addresses all of your questions or if you have other concerns.

But do I get it right that "Combining more extensions into a single extension package will make it easier to deploy changes and updates by reducing the number of packages that have to be managed and the number of installers that have to be created." means that in this case, we should have just 1 installer and 1 csproj with all of our extensions put together? So in POS on the settings page, we will see just 1 extensions package, right?

Not necessarily, that comment was just meant to explain that there are benefits to combining some related extensions into the same extension package, namely that it reduces the number of installers you need to create. It is one option to combine all of your extensions into a single project (.csproj file) with a single installer. In that case, you would see only one extension package on the settings page. But it doesn't mean that you have to do that. Another option (as you call out later) is to create a separate extension package for each installer. In that case each extension would have its own extension package, which makes it easy to deploy changes to a single extension without having to worry about affecting all of the other extensions. The downside to this approach is that each extension package would need to have its own installer. The third option (which is what we recommend) is somewhere in the middle - that you should combine all extensions with related functionality into a single extension package, with its own installer, which can be updated and deployed as a single unit.

So, from what I understand. Each 'folder' from old SDK should become a separate project in new SDK (like this one)

This is correct for the example you're showing here (it looks like the old Retail SDK samples). In this case, each of those folders was a separate sample that we had written to be independent of each other. If these were to be migrated to Commerce SDK, then each of them would be created as a separate extension package (with their own installer). That's because they are each distinct samples with their own use cases. (In fact, this migration is what we're planning on doing at some point so that people can see more examples of how extensions exist in Commerce SDK).

But as far as I understood from other issues. 1 installer project (like bellow) can't have a reference to multiple extension projects

Correct - each extension package (aka .csproj project) needs its own installer.

So this means that we have 2 options. create 100+ installers or have 1 extensions project with everything we have - and it will be displayed as 1 extension and we won't be able to enable/disable single extensions(folders) inside that 1 project (like we did before with tsconfig.json) Am I right?

Those are two options, but they aren't your only options. As I touched on in the first section above, you can also group your extensions into extension packages, but that doesn't mean it's an all or nothing proposal. Say you have 20 extensions now, 10 of which are all related to cart management. You can group all 10 of those extensions into a single extension project, and it would only need one installer for those 10 extensions. Say another 8 of the extensions are related to adding some custom checkout flow. Those 8 extensions can be grouped into a separate extension project with its own installer. If the remaining two extensions are separate extensions that don't have anything to do with the other scenarios or extensions, then they can each have their own extension project with its own installer. In this case then, you would have four extension projects in all (each with its own installer) - one with the 10 cart management extensions, one with the 8 custom checkout flow extensions, and one each for the last two unrelated extensions. So you have more options than just creating a single extension package with all 20 of your extensions, or twenty extension packages each with a single extension and its own installer.

We recommend that you combine any related extensions into a single extension package. Then you can enable/disable these extension packages by running/not running the installer when you're setting up your devices, rather than through the tsconfig.json file. For an example, you can take a look at the GasStationSample, which combines several extensions into a single extension package with a single installer.

Also the question here is - if we combine everything in 1 project. won't it be a problem if we had x PostLogOnTriggers(for example) in separate folders in retail SDK (scr below) and how we should specify them in that single combined project's manifest.json file

This depends on the type of extension used. For triggers we support multiple instances at each extension point it would not be a problem. However, for other types of extensions like request handler overrides, only a single instance is allowed in an extension package.

emishura commented 1 year ago

@madyke thanks a lot, Matt! :)