-1

I'm trying to figure out how internal development environments were implemented and how they work. Particulary, in early days at the beginnging of its era (1980-2000). Let's try to keep it simple.

For instance, in most today's ERP systems you can device your own functions and depict business logic. In SAP you write ABAP code and Dynamics NAV uses C/AL.

First of all, how is such an internal development environment within the core application created? You can directly compile and run your implemented features. Is it a kind of dynamic load of DLLs through interfaces?

Secondly, how is the code loaded? What I know is that Dynamics NAV converts CAL into C# code (could be seen in previous versions) and loads it (how is this topic designated?)

The source code is stored in the database and you can't extract it. Probably it is encrypted and then directly loaded out of database.

I am just wondering if you create few new objects, compile and load it, how are they visible to other objects? I mean if you create a simple application which loads DLLs you can't access them from other DLLs on the fly. This feature is though available in ERP applications.

You can see same principle in other software where customers can use internal scripting language to extend the core application.

Thanks!

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Wheelspin
  • 1
  • 1
    I think you should ask two distinct questions, because the answers will be either for ABAP or for C/AL, if all are mixed, that will be a mess. – Sandra Rossi Aug 08 '20 at 16:04
  • To give a proper answer one would need to know why you are asking this. – Mak Sim Aug 09 '20 at 07:42
  • The answers for Dynamics NAV and Dynamics Business Central will also be very different. – JeffUK Oct 02 '20 at 12:24
  • I wrote part of that code for Dynamics Nav 2009. We took out a patent on the method. I don't how descriptive it is, but you can see it [here](https://patents.justia.com/patent/8281292). – Palle Due Nov 08 '22 at 08:59

1 Answers1

2

The answer for the newest versions of Dynamics NAV (now called Business Central) is very different to C/AL versions of the product, but it's an easier answer as the system is much more transparent.

When an extension is created, the app.json file defines which other extensions are dependencies; the developer will then download the 'Symbol Files' associated with these dependencies from a BC Environment where it is installed. This gives us access to events, and public functions within those other extensions.

Public functions effectively give us an API for the other extensions, and we call those functions like in any object-oriented programming language.

Events are handled via the central event-management system, our extension subscribes to events that the other extension is going to trigger (Identified by the GUID associated with the other extension, and a event name); and the event management processes call our function when those events happen, handling any parameters and/or return values.

In Business Central we also interact with the 'Base Application' in the same manner, i.e. we 'depend on' and extend the base application just like any other 3rd party extension.

JeffUK
  • 4,107
  • 2
  • 20
  • 34