modal-dsl / modal Goto Github PK

A Domain Specific Language for AL Extension Development

License: Apache License 2.0

Xtend 91.32% Java 8.63% Dockerfile 0.06%

mdal xtext dsl domain-specific-language mdd model-driven-development al-language dynamics-365-business-central dynamics-365-bc dynamics-365

modal's Introduction

`mdAL`: A DSL for AL Extension Development

This repository contains the implementation of the Domain Specific Language (DSL) mdAL. mdAL enables a Model-Driven approach to extension module development for the ERP System Microsoft Dynamics 365 Business Central. mdAL stands for model-driven AL.

Features

mdAL is a descriptive language used to define the needed core entities and views of an AL solution. In addition, the data flow between entities can be specified. General features and integrations which have to be provided in an AL solution (e. g. comment line table and pages, source code and navigate integration) and features that can be derived from the entity and view specification are added automatically.

Thus, mdAL provides AL code generation for:

Tables
- Setup
- Master
- Supplemental
- (Posted) Document Header and Line
- Document Comment Line
- Journal Line
- Ledger Entry
- Register
Enums
- From specified table fields
Pages
- Master
  - Card and List Page
- Supplemental
  - List Page
- (Posted) Document
  - Document and List Page
- Ledger Entry
  - List Page
Codeunits
- Post
- Post (Yes/No)
- Jnl. Check Line
- Jnl. Post Line
- Reg.-Show Ledger

Moreover, these customizations to standard objects are generated:

Event subscribers implementing the Navigate functionality for the specified Posted Document Header
Source Code Setup table extension
Comment Line table extension
Comment Line Table Name enum extension

Specific code that cannot be generated from a mdAL model file can be integrated by subscribing to the various event publishers available in the generated AL code. Hence, you can use mdAL to automatically generate a base AL extension and create an additional AL extension that depends on the base extension and adds your specific code. This way you do not have to change generated code in order to do customizations. Take a look at the demo projects to see how this could be done. For more information on mdAL visit mdal-lang.github.io.

If you need additional event publishers or find errors in the generated code, please open an issue.

Repository Structure

This repository consists of the following projects:

de.joneug.mdal contains the language implementation and AL code generator.
de.joneug.mdal.ide implements a language server complying to the Language Server Protocol (LSP). It is used in the mdAL VS Code extension to add language support and IDE features like commands, code actions, content proposals and documentation hovers.
de.joneug.mdal.standalone implements a standalone CLI tool that can be used to generate AL code from a mdAL model file. This tool is useful for CI/CD pipelines. It can be used conveniently with the docker image mdal/cli which is available for Unix and Windows systems. If you use GitHub Actions also consider using the mdAL action for your workflows.

Demo Projects

To see mdAL in action take a look at the following demo projects which implement a seminar management solution (cf. Microsoft official training material: Course 80437 — C/SIDE Solution Development in Microsoft Dynamics® NAV 2013):

mdal-lang/mdal-demo contains the mdAL model file used to generate the base AL extension.
mdal-lang/mdal-demo-extension contains the AL extension that adds specific features to the base extension that are too specific to be generated (e. g. completing the generated posting routines through event subscribers).

Development

All projects are built using the build tool Gradle. If the Java JDK is installed, you can use the bundled Gradle wrapper and build all projects with this single command:

$ ./gradlew build

A list of all available Gradle tasks can be obtained with this command:

$ ./gradlew tasks

License

Apache 2.0 (c) Jonathan Neugebauer

modal's People

Contributors

Stargazers

Watchers

Forkers

rstefanetti hugoasouza tbenko

modal's Issues

Short names

When I would use short names for documents like this:

it gives me compile errors:

Full mdal:

solution "Name" {
    Prefix = "PRE";

    master "Container" {
        ShortName = "Cont.";
        
        fields {
            template("Name"; Name)            
            template("Dimension"; Dimensions)
        }
        cardPage {
            group("General") {
                field("Name")
            }
        }
        listPage {
            field("Name")
        }


    }

    document "Shipment" {
        ShortName = "Ship";
        
        header "Shipment Header" {
            ShortName = "Ship Header";
            StatusCaptions = ["Open", "Released"];
            fields {
                include("ContainerNo"; "Container"."No.")
            }
        }
        
        line "Shipment Line" {
            ShortName = "Ship Line";
            
            fields {                
                field("Quantity"; Decimal)
            }
            listPartPage {
                field("Quantity")
            }
        }
    }
    
    ledgerEntry "Container Ledger Entry" {
        ShortName = "Cont. Ledger Entry";
        
        fields {
            include("ContainerNo"; "Container"."No.")            
            field("Quantity"; Decimal)
        }
        listPage {
            field("Quantity")
        }
    }
    
    
}

Journal template instead of Document to create ledgers

Hello Jonathan,

First of all I must admit this project is impressive. I hope Microsoft will take some interest regarding your work because it can be an huge time saving for designing Business central.

I give it a try and it it's working like a charm
I've only a wonder, about model schema "Item->Document->Ledger". That is more like an enhancement tought than an issue :

I've created an "Investment" master table but I want to pass it through a journal instead of a document, in order to post ledger entries.
Allowing to set the ledger template without the document template, or add a simple "journal template" capability would be very great (althrough you already made the journal line table and codeunit for check and post) 👍

Regards

Exception in thread "Thread-0" com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 741562 path $

Good morning, I tried to run the demo project and generate AL-objects from the seminar.management.mdal file. I used the latest BC version and installed JRE8 as mentioned.
But when I click to "Generate AL File" I get following error:
Exception in thread "Thread-0" com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 741562 path $

Attached the full Error Output
Error.txt

Can somebody help?

Should I use all Categories (e. g. Master, Supplemental, (Posted) Document Header, (Posted) Document Line, Setup).

Is it mandatory to use all categories when creating a new solution. It seems so!

I get an error when I try this example:


solution "Seminar Management" {
    Prefix = "SEM";

    master "Seminar" {
        ShortName = "Sem.";

        fields {
            template("Description"; Description)
            field("Duration Days"; Decimal)
            field("Minimum Participants"; Integer)
            field("Maximum Participants"; Integer)
            field("Language Code"; Code[10]) {
                TableRelation = "Language";
            }
            field("Seminar Price"; Decimal)
            field("Gen. Prod. Posting Group"; Code[20]) {
                TableRelation = "Gen. Product Posting Group";
            }
            template("Dimensions"; Dimensions)
        }

        cardPage {
            group("General") {
                field("Description")
                field("Duration Days")
                field("Minimum Participants")
                field("Maximum Participants")
                field("Language Code")
            }
            group("Posting Details") {
                field("Gen. Prod. Posting Group")
                field("Seminar Price")
                field("Dimensions")
            }
        }

        listPage {
            field("Description")
            field("Duration Days")
            field("Minimum Participants")
            field("Maximum Participants")
            field("Seminar Price")
            field("Language Code")
        }
    }
}

Using spaces in Master-Name generates problems in setup page

When using a master like :

master "Real Estate Unit" {
ShortName = "REUnit";

This will generate a setup table definition with :
field(2; "RealEstateUnit Nos."; Code[20])
{
Caption = 'RealEstateUnit Nos.';
TableRelation = "No. Series";

But in the page definition you will get :
field("Real Estate Unit Nos."; "Real Estate Unit Nos.")
{
ApplicationArea = All;
}

Resolve "Implicit with" Issues in Pages and Codeunits

With the NoImplicitWith feature enabled in the app.json file there are some "Implicit with" issues in generated pages and codeunits.

See: Referece

CodeCop warnings

I see that the models don't take the implicit and explicit withs into account:

rule ruleSolution failed predicate: {getUnorderedGroupHelper().canLeave(grammarAccess.getSolutionAccess().getUnorderedGroup_3())}?

Hello, when i try to create a .mdal file (yours demo file is working) - i get following Error :

rule ruleSolution failed predicate: {getUnorderedGroupHelper().canLeave(grammarAccess.getSolutionAccess().getUnorderedGroup_3())}?

Hopefully you can help
BR

Use of Flowfields

Hi Jonathan,

Great job, do you have further plans to add Flowfields to the model ?

Would it be an option to be able to define the srcgen -path. or always use the dir-structure.
So I would be able to create several mdal-files with different "Master" tables in one repo. eg. In your solution I would like to add a "Seminar School", which at his own turn have some suplementary tables (headmaster, ...). But I would like to use the automatic No. series possibility on this table.
So if I could create a directory structure in my repo like :

Seminar (top level)
seminar\seminar (master = seminar)
seminar\seminar\src (mdal file for seminar)
seminar\seminar\srcgen (generated source code for seminar)
seminar\school (master = school)
seminar\seminar\src (mdal file for school)
seminar\seminar\srcgen (generated source code for school)