I did a “little” boo-boo: I totally misunderstood something from the overly documented AppSource world, which has quite an impact for us to go forward. I’d like to apologize beforehand for the rant I’m about to embark – I just wanted to make sure this only happens to us and not you ;-).
We’re in the process of uploading all our apps to AppSource. In total about 45 apps, but packaged in a few offerings. They have been thoroughly tested at multiple customers now, and we feel comfortable to put them in the cloud for the big public.
So – we’re doing just that, and all seems to be going just fine.
Validation process – ✅
App published – ✅
But when installing the offering at a customer tenant, only a few apps of the entire offering is getting installed.
We had the idea of packaging multiple apps in one offering .. just because it makes sense. For example, we don’t “just” want to offer a limited “Finance” app – we want to have a Finance offering that includes a set of apps .. some of which simply don’t have any dependency to other apps. Or other apps that are meant to be “Framework apps”, but we just want them part of the offering, simply to prepare for PTE development. Or we have (what we call) “connected apps”, apps that NEED to be in place from the moment 2 apps are installed in some environment to smooth out the user experience. Or we might have a coded dependency, and not a compiled dependency (yes, Gunnar 😉).
Sure, I’m able to create all kind of different AppSource offerings of all of them .. but does it really make sense? I’ll tell you: no it doesn’t in the slightest make sense in many of the cases. It would be overcomplicating things .. we just don’t want to create useless offerings with our name on it🙄. I’m starting to understand why Microsoft has +2200 apps in AppSource, to be honest …
Then again – I seem to be in the wrong here. +2200 apps, and we seem to be the only one encountering this limitation.. 🤔.
The cause is my misinterpretation of the words “offering” and “library apps”.
An offering is not an offering of multiple apps that would make sense to be offered as a whole, but simply an app that might have dependencies. So why do we call it an “offering” again? 🤔
And one could assume “Library apps” is a library of apps .. or a collection of apps .. which I thought it was (especially in combo with the name “offering”) .. but which couldn’t be further from the truth. It’s simply the dependencies (all levels deep), starting from that “main app”. You can put hundreds of apps in there – validation won’t fail – won’t warn you about the unnecessary apps – it will only look at the ones that have anything to do with the dependency-tree of the main app (and ignore the rest).
So that’s how you should treat it. And I don’t know about you – but that just adds another complexity in our case.
I’m not going to call it “THE” solution .. just something that we will do in our case (we didn’t yet, but are in the process). It’s simple: we will just (try to) create yet extra apps (let’s call them “offering apps”) and have dependencies to all apps in the offering-app.
If you do that yourself, be warned: I did notice that it’s not enough to just have that dependency in the app.json, and no code. You really need some code that implements the dependency as well! You really do .. yes you do. If I didn’t put some dummy code in it, it simply didn’t want to validate my offering (it did validate with BcContainerHelper, but not in the online validation), complaining that it didn’t find the dependent extension (which was part of the library app). When adding some kind of dummy subscriber, that problem was solved… .
So, time to put on my dummy-head, and implement some useless dummy-code to fake dependencies to be able to actually create offerings in stead of just apps.
Some documentation that I was pointed to:
- Create a Dynamics 365 Business Central offer on Microsoft AppSource (Azure Marketplace) | Microsoft Docs
- Technical Validation FAQ – Business Central | Microsoft Docs
And yes – I’m very aware of this paragraph … at least now I am 🙈.