Universal Code Initiative Program: Cloud-optimized extensions

Universal Code Initiative Program: Cloud-optimized extensions

Approach to the initiative

Write ‘Cloud’ target code – Cloud Ready Software

In general, Microsoft wants to reward those who develop cloud ready software and increasingly try to limit customizations of 1st party extensions (typically Base Applications).

This is the main purpose, the driver, which guides the Universal Code initiative; to date many ISVs and VARs already appreciate this initiative.

Internal working groups – Go.to Cloud! many partners create internal groups to do internal reviews of pre-existing code.


Advantages in rewriting the code with a ‘Cloud’ target

Code rewriting in cloud ready software format, for typical on-premise procedures, could be a significant economic advantage (short and long term)

If you find easy and flexible solutions (eg barcode printing) you can resell them on AppSource., these could also cover your development costs.

What will happen

Simply translated, all Per Tenant Extensions (PTEs) that are developed will have a different cost if the target within the extension is set to ‘OnPrem’ or ‘Cloud’.

If Scope = ‘OnPrem’

Review file logic and dotnet usage

When the scope is OnPrem, you typically have to review all the file management logic and calls to .NET variables; these are the major obstacles to overcome.

Change the Scope OnPrem where possible for compilation In addition to this, it is a matter of modifying the OnPrem scope to make compilation possible or starting to start a discourse of new libraries (utilities) that can wrap around .NET libraries deployed on cloud servers.

APPs as Dev frameworks

Internal approval for Library Deploy

These latter statements are obviously secondary to an internal approval by the product group of what is required and require their time (e.g. probably the most conspicuous implementations will require the next major).

APPs as Dev frameworks

Obstacles on writing Cloud Ready Software

Learn from existing modules

You do not reinvent the wheel, always look at standard, perhaps what we need has already been done.

Look in ‘Modules\System’

Fonts question – can they be used?

For fonts, to date, there is no check on the font family in RDL report nor a check on the font of the Word Layouts.

These can be safely used with Cloud targets by reporting the Font installed On-premise. The important factor is that they don’t have to call custom assemblies to create the necessary encoding (as “IDAutomation” does); this falls into the aforementioned no support for dotnet variable for scope Cloud.

Search for ‘OnPrem’

… Example …

If I don’t follow the new guidelines … and write and resell ‘NON-UNIVERSAL’ code and continue to do so …

I can do it, but I have to pay some fees …

Timeline Summary

How should a modern and cloud-compatible solution be made?

  • AL extensions used only for the management of business processes (ERP processes)
  • Integrations with serverless services (Power Apps, Automate, Azure Functions etc.)
  • APIs and OData to read \ write data
  • Files stored in the cloud (Azure storage)
  • Create wrappers based on standard components \ technologies to then propose to Microsoft, they could implement them, unlock them, integrate them in new product releases

Before it was: asking for events, now it is: asking for Cloud technologies.

Documentation and links

Best References – posts & blogs



How I Manage My Team for Product and Customer Development? – YouTube





Upgrade to SaaS: Overcoming file management Limitations (simplanova.com)

Yammer Thread – Universal Code