Multiple Module Development

Noisy_Van

Hello,

We are starting to dive into expanding our NAV integration to other modules, and will be selling these separately. To do this, we will be creating a granule for each integration module.

However, there are some stock objects that we modify that may contain code pertaining to multiple modules. For instance, let's say Codeunit 123 is to be modified by both of our integrating modules. For both modules, we must add a global variable which is points to one of our codeunits in that specific module's range. In addition, code is inserted to call a couple functions of our codeunits from within codeunit 123.

I can see a couple of ways to handle this problem, though I don't like either solution. The first option is to maintain two copies of codeunit 123 in our development environment, one for each module. When creating the FOB file for each module, the appropriate copy is first loaded and then exported with the rest of our objects. This will add some time to the coding process, but is fairly clean from the customer's perspective. The second option is to simply maintain a single copy of codeunit 123, and add a note to our user guide's installation section that explains what code to remove in the case that they only purchase one of our modules.

Are either of these solutions recommended, or is there a way to do this that I'm not seeing?

Thanks,
Greg

Karenh

The why that I have seen it done by 3rd parties is to modify the one codeunit to add multiple functions/variables, and to NOT provide a note.

rdebath

A third possibility is to put all the links you need into codeunit 12/3 but have it call a single codeunit 50123 to do the work. This codeunit is full of stubs that call your routines in other codeunits.

The advantage is that disconnecting one of the subsections should end up as just deleting a few variables and clearing the bodies of a few functions in cu 50123.

Or if you want you could probably arrange for cu 50123 to check which parts of the system are installed and only call them if they're present. It's not a problem if cu 50123 references missing objects because nobody normally needs to compile it; if it becomes a problem clearing functions is quick and easy.

lvanvugt

A fourth option is [which we are now into implementing] to use a source control system that allows you to make different branches for different verticals and define (hierarchical) dependencies betweem them and (mostly) automatically integrate (merge/inherit) changes from one to the other. In this setup you will have in each branch that codeunit 123 in the version relevant for that branch (i.e. vertical). Dependant branches will inherit your code from upper branches.
At this point in time we have to make the definite choice for the right tool, either (1) Visual Studio Team Foundation Server or (2) Perforce.
For VS TFS there is a good add-in to easily up- and download objects from VS TFS to NAV (and vice versa): NAV plugin for TFS Source Control.

Noisy_Van

Thanks for your replies. Both of those sound like good ideas, and we'll consider the options.

lvanvugt

Hi Greg,

Unfortunately we have not get TFS into place so I would like to know what came out of your investigation.