Making scheduling extensions extensible: new scheduling flexibility

A few weeks ago, we released version 1.10 of both the Visual Production Scheduler and the Visual Jobs Scheduler as well as version 1.5 of the Visual Advanced Production Scheduler for Microsoft Dynamics 365 Business Central. So far, we have been following the practice that every release version included the following: (a) new features, (b) bug fixes, and (c) some "under-the-hood"-improvements (merely targeting further improved stability and performance). 

With the current release, we enhanced this practice. We added events and functions to that list. In other words: we made the first steps to make our scheduling extensions extensible. Continue reading to learn about the why, the what, and the how of making extensions extensible.

Why making scheduling extensions extensible?

As of now, our product strategy was exactly this. A strategy to build products. Precisely: visual scheduling extensions for Microsoft Dynamics 365 Business Central.

Products differ from solutions

• by a higher degree of standardization
• by a higher focus on pre-defined out-of-the-box functionality
• by the much bigger aspiration of repeatability
• by a lower purchase price
• ... and in turn by somehow less flexibility. 

For a long while, we have been adding capabilities to our products so that users could individualize them. Examples are:

• the editor to change the tooltips
• the editor to change the bar labels
• the editor to change the left-hand table
• the always growing setup page options 

However, we still oftentimes face the situation that customers want this, and partners request that. And, of course, the typical answer to this has been: "Well, we can do this. But, this is non-standard and hence we need to develop customizations for you."

Honestly?

Customizations feel a bit "old school"... especially as Microsoft actually built the entire Business Central system in a way that customers and partners can enhance it by extensions. These extensions obviously can become repeatable and standardized, and hence they do not create any road blockers in terms of future upgrades. (by the way: In my humble view, the lack of upgradability has been proved to be THE core problem with customizations).

Consequently, we decided to follow the example that Microsoft gave. We make our extensions extensible so that we can support achieving customized user experiences while keeping standardization and upgradability.

Or, to say it with the words of my colleague Klaus:

"This is the first step from being a product to becoming a tool."

What did we do to make our scheduling extensions extensible?

Well, to say it as short as I can: We started to build a documented API for our scheduling extensions:

1. We provide events that partners/customers can subscribe to. This basically means: partners or customers can build some functionality into their apps with which they can listen to what is happening in the visual scheduler.
   For example, an event can tell another extension: "hey, that specific operation from that production order got moved."
2. We also provide functions that partners/customers can use. This basically means: partners or customers can build functionality into their apps that controls what happens in the visual scheduler. 
   Let's stay in the above example. A function reacting to the above event could be: "Hey, the user changed that operation. She might be interested in seeing all operations that belong to production orders from the same sales order. Let's color all of them green."

With this, partners and customers can build extensions based on our extensions … and provide extended (and/or customized) user experiences. And by the way. the example above may sound silly. However, with the just-released new version of the Visual Production Scheduler, you can develop an extension that exactly does this :-)

If you are interested in more examples, have a look at the recorded webinar (as of 29 April 2021). Going forward, we enhance the scope of our regular product releases. From now on, every release should contain:

• New features
• New events & functions (NEW ;-)
• Fixed bugs
• Under-the-hood-improvements

How did we start to make our extensions extensible?

Rome was not built in one day. Hence, versions 1.10 of VPS and VJS and version 1.5 of the VAPS mark the first step of making our scheduling extension extensible. We decided to start and pilot this new approach with the Visual Production Scheduler.

Here is what we released:

• VPS – version 1.10
  • Number of new functions: 6
  • Number of new events: 6
  • Learn more in the VPS knowledge base
• VJS – version 1.10
  • Number of new functions: 2
  • Number of new events: 1
  • Learn more in the VJS knowledge base
• VAPS – version 1.5
  • Number of new functions: 0
  • Number of new events: 1
  • Learn more in the VAPS knowledge base 

All in all, I am pretty excited about the new capabilities that these events and functions bring. In addition to this, the concept of making our extensions extensible allow us, on the one hand, to continue developing products (with all the advantages for us and our customer). On the other hand, this approach opens the way to interesting individualization and customizations of our extensions ... while still keeping them upgradable. 

The first - and important - step is made, and many more are to follow.