Multi-level App Dependencies

So….I’m working through a new build process for our ISV solution. Why? Because we’re finally breaking it down into many extensions!! More on that another day…..

We’ve created a ‘library’ app which will house all of our common functionality. Each of our functional apps will have a dependency on the library app. Further to this, each of our functional apps will have its own test app. The test app of course has a dependency on the app that it is testing.

Like this:

So……you create your test app, add a dependency to the app you are testing and compile…..NOPE…..failure. 😦

In the above example, what needs to be done is the dependency to Library also needs to be added to Test App 1.

Like this:

Does this make sense? Maybe. This forces an assumption that because App 1 has direct access to the functions and entities within Library that Test App 1 also needs that access. In my example above, this direct access to Library was not something that we needed.

From the symbol perspective it perhaps makes a bit more sense. Adding the dependency forces the system to download the symbols for the dependent apps. If you just add the dependency for App 1‘ above, those symbols could be considered “incomplete” without also having the symbols for its dependencies, in this case Library.

I really (!!!) wish that we didn’t have to specify the extra dependencies. It would be nice if the compiler was able to figure out all of the downstream dependencies. An indirect dependency so to speak!?

The above scenario is fairly simple, but imagine this one:

  • ISV ‘AA’ creates a ‘app b’ that has a dependency on ‘app a’.
  • ISV ‘BB’ creates ‘app c’ that extends ‘app b’. 2 dependencies needed here (a, b).
  • ISV ‘BB’ sells ‘app c’ to a customer who then extends it even more with ‘app d’. This new app requires 3 dependencies (a, b, c).

…..look at all the apps now that have to be updated when ISV ‘AA’ releases a new version of ‘app b’? In an agile saas world, rapid small incremental releases are a reality. Is this also going to be magnified once Microsoft breaks down the main application into smaller (and perhaps dependent) apps?

Oh…in case you don’t know or don’t remember how to add dependencies to your app? It’s done in the app.json file in each app. See below for an example of what the app.json would look like in the ‘test app 1’ from the above example….

So how did I find this? As I mentioned, I’m working on a new build pipeline for our apps. My goal is that the pipeline will dynamically handle the dependencies so that it will update all of the versions in the app.json without the developer having to worry about that. After all, the build numbers are being generated from Azure DevOps so the developer is not going to know what the build numbers of the dependent apps will be. This little dependency hiccup caused a little bit of a wrench in my original plans.

More to come on the build pipeline later……..but spoiler alert…..it is working!!

Until next time…happy coding!

Dynamics 365 + Power Platform April 2019 Release Notes Now Available!

Microsoft announced today that the April 2019 release notes for Dynamics 365 and the Power Platform are now available for download. These notes cover all products within these platforms, but for readers of this blog, you’re likely most interested in what’s coming for Business Central.

You can get the release notes here.

A few highlights of new end-user functionality for Business Central are:

  • Base application as an app (!!)
    • Yes, one of the things I’m looking forward to most is that we’re getting the base application moved from CAL objects to 2 AL extensions – system and application. Yes, the end of C/Side is coming.
  • Add multiple items to a sales or purchase order at once.
  • Name and description fields on master/document/journal records increased from 50 to 100 characters.
    • Watch out for this one in your ISV solutions as you may need to increase your field sizes to match!
  • New Physical Inventory Order and Physical Inventory Recording interfaces to enhance physical inventory functionality.
  • Set an expiration date for your sales quotes.
  • Merge duplicate customer and vendor records (!!).
  • Configurable reports for warehouse documents.
  • Save your filtered list views (!!).
  • Document focus mode – expend the item section on documents to see more data for faster entry.
  • More keyboard shortcuts – show/hide fact box, add item, previous/next navigation, etc.
  • Adjust field importance via personalization.
  • Page inspection – See all data elements of the current page record…….think the old ‘page zoom’ but even better!

The April 2019 release also includes improvements for developers working with AL extensions, such as:

  • Optimizing the experience of using VS Code with large projects.
  • new Outline View to show the symbol tree in teh current editor.
  • The in-client designer no longer makes dependencies on all apps, only the ones that have been used in the designer.
  • Attach to an existing client session for debugging.
  • Code Actions – have VS Code suggest ways to improve your code.
  • More protection for ISV’s over their IP.
  • Standard web API moving out of beta. Will support webhooks, OAS 3.0, OData v4, and versioning.

As noted in the release notes, the above features are things that are slated to be released anywhere between April 2019 and September 2019. Some of the features may be available for preview as early as February 2019.

The above is just a highlight of what’s coming down the road for Business Central and as you can see we are in for quite a lot of new features and quite a few old features that are being resurrected in a new a better way.

Until next time, happy coding!