AL
AL copied to clipboard
microsoft
Official Dynamics NAV SDK
After I read again No. #276 I find the an Adequate solution for NAV adjustments the enlargement by a own webservice represents.
So the apps for NAV are limited to a minimum.
For me, analogous to the CRM SDK, would be a suitable NAV SDK quite beautiful. The best would be in my opinion in this case one or more dll's in the DotNet standard or as a DotNet core solution. So you could use the SDK directly in a DotNet core webservice.
In addition, would be, but is really very optional, also an alternative communication protocol such as ssh very beautiful.
However, in my opinion for a good SDK the NAV API would have to be improved a bit.
That sounds really very good! This would make me think I can implement many solutions much better. But what I think nowadays very important here is that the community has a right of co-determination. From my point of view, an SDK will only be successful if it meets the requirements of the community.
@FSharpCSharp yes the opinion I am synonymous. One could if the general NAV API implemented well is the SDK here on GitHub open source develop. Then everyone could contribute and at the same time we get a SDK faster because the NAV team the NAV team gets support from the community...
Currently on the online SaaS offering we support add-ons (extensions) and a new REST based APIs (connect apps).
The new REST APIs are simplified versions of main entities in Financials, e.g., accounts, customers, vendors, invoices etc. They mainly allow external services, such as expense, payroll, web store, order management, or payment processors to look up information in Financials and post data into Financials. See beta documentation here https://msdn.microsoft.com/en-us/dynamics-nav/fin-graph/index
To make life simpler for service providers with no knowledge of Financials, these APIs have much less fields than the corresponding entities in Financials, typically because these are used only when inside Financials. As time progress, we will most likely add more and more, but always strive for not surfacing internals.
Should the APIs not be enough, the add-ons allow you to create custom business logic including UI in Financials. They can also be used to create any custom web service functionality for consumption in external services, should the standard APIs not be enough - and any custom APIs deployed through an extension could be combined with standard APIs as well.
Now, above APIs do not have any .net SDK planned as of now. To understand your requirements better
- What are typical integration scenarios you would want to support?
- Do the scenarios mainly involve data movement (as in payrol or expense scenarios), or deep integration with new business logic in Financials?
- Is the aim to do "real" Financials development, but from .net rather than C/AL?
- Are you doing REST API calls from your .net services today, and if so, do you handle this without SDKs?
Cheers, Peter (Microsoft)
OK to the idea behind it.
My problem is the use of Azure functions which I do not want to use / may / should / allow etc. At the same time I can not use CSharp features more or I should use them no longer.
In the previous development I have a lot of development in dll's outsourced or directly c # files inserted into the object table.
A problem in the future is that I do not achieve platform independence (On premise, CLoud etc.).
The plan thus looked so that I can control NAV from out. Just as it does with CRM.
I would as a NAV Extension only minimal absolutely necessary changes to the API or the gui and programm all other relevant code into a .NET core service.
Where the customer would run the service is equal to me then.
What do I want to do with it and what I've already done:
- Eg the automatic processing of files by CSharp (Documents, PDF, MD etc..) and Cognitiv Services (LUIS small test but very cool) or translating or grammar check after that i insert this as a new record in NAV.
- Customers who register on the website inserted and qulified automaticly to nav.
- Own user rights management (with groups and power system like in team speak).
- Image processing (Graphics, Profile pictures), Video Processing etc.
- Large data evaluations (for testing predictiv analytics), nav is for very big data to slow.
- Bulk inserts (ok this thing i do directly to the database)
- Mathematical calculations (probabilities for new products, or Customer behave, Conversion time for machines )
- Encryption and signing (pgp and more) plus compressing etc..
- Extremely many APIs (control machines from nav, get data from other software, converting data, Push data to other software etc..) and windows apis to show windows notification or run async process without the service
- Data anonymize
- Bank api call etc.
All these things were a good thing for Navision and our customers appreciate these tailor-made programming. It would be cool if this advantage still existed in the future.
I would love to get data, insert, delete and update. For each table. or e.g. Via webhooks or regular calling , get events to react to it.
My goal is to be able to use CSharp simply as a second possibility of development.
In addition, it is easier to use the calls in an SDK than writing the API calls down each time.
So yes I want to develop with .NET and not with C / AL. Even if you do a very good job here. Thats very nice. And I like your work here. Great praise to the whole team.
Also, I think the one SDK with REST API would be a nice compromise. Especially since otherwise .NET falls away and my hopes and also the some colleagues slowly disappear the CSharp in Navision official second or first language. I also write a compiler to develop directly in CSharp but I believe the Microsoft will never be officially supported.
With the new model and in view of the current development and the other d365 products, I would find a good and fully usable SDK a consequent further development. That fits with the present separation from the original and adjustment very well pure.
The more I think about it the better I like the SDK :)
Thank you for reading :)
Heey @FSharpCSharp
Are you interested in tackling this issue without MS?
If you're there, we'll simply launch a community-driven open source SDK and / or library with tools that extend NAV really cool. I would also be willing to provide my C# to C/AL compiler as a tool for the project.
here was more or less a suggestion: Microsoft/cal-open-library/#4
Feel free to contact me by mail:
@Gallimathias Personally, I would prefer Microsoft to publish an official SDK or something similar. The "C/AL Open Library" project you mentioned seems to be a very good start. The reason for this is relatively simple. The world of Microsoft Dynamics NAV has undergone a major upheaval in recent years. As soon as the world changes, you are not able to maintain an SDK managed by the community.
Regarding your tool for compiling C# to C/AL. Is it possible to simply transfer existing code to C/AL, or what is it for? Sometimes it would be not bad if you could use existing algorithms directly in C/AL. You could then also add them directly to the "C/AL Open Library".
@FSharpCSharp I would also prefer an MS-driven SDK, but I don't think that's going to happen so fast. I am young and have no desire for this stiff business world, I prefer to develop for the sake of passion and progress. I want to develop things that help people move forward, make everything a little better and fun. For myself, C/AL is dead. AL is good and a proper and important step, but MS simply does things to avoid throwing away partners.
As long as Navision remains a WPF application and not a pure cloud solution, there will always be SDK and modding possibilities. Officially supported or not.
Yes, the open library is good and I will participate, but I want to do more.
My compiler (a transcompiler) is not finished yet but it will allow you to customize Navision with C# as soon as it is. He can convert the compiled C# code to a nicer C# format, and he will also be able to use AL and of course he can pack extensions. This means it will support all NAV versions. Of course I will write a VS and VS code extension, everything will be available via nuget and completely open source.
The current version is that the code units are coming out as clean C# code. It's still a hard way to the goal set but I will reach it, at any price.
@Gallimathias I want to get back to you on the subject. I know it's been some time now, but I still find it exciting and very important for future developments. Yesterday I found your described project on your account by chance. The goals you're planning there sound really tempting. But unfortunately the last commit was half a year ago. Is the project still being developed, or what is the state of affairs here? I think it would have potential. But unfortunately the current version is not really usable, because the functionality is rather rudimentary and only contains parts that have been started so far. Something really usable or ready to use is unfortunately not yet included. I would just like to know what you would like to do here. Have you finished the project yet, or are there other things in the pipeline? Please bring me up to date here!
@FSharpCSharp
First of all, thank you for your interest.
Yes, the project is still under development. I just took a little break because I'm still in my final exams until July 24th.
So far the project was more of a project for myself from the first year of apprenticeship so there was no urge to finish quickly.
My original plan was to replace C/AL with C# until Microsoft with AL came before me. Until four months ago, I was also planning to continue this plan and simply add AL.
My current plan, however, is not to focus on classic development for the time being and to concentrate on app development.
That means my compiler is an alternative to the Microsoft compiler. It should be possible to develop AL, a community AL version and in C#.
At the same time I want to make it possible to extend the Navision Server on the OnPremise site so that I can offer my own app format. With this own app format it will be possible e.g. to use inheritance. Since I really appreciate the discussion with @rdebath, I also think about supporting something like inlining in the Community AL variant.
(Furthermore I want to ensure with this own AppFormat and the own compiler that the language version is separated from the Navision version. For me these are two pairs of boots that should be as little dependent on each other as possible. I don't want to have to update Navision for a language update and not the language or compiler for a Navision update.)
Furthermore I wanted to build up my own database. So an alternative to Cronus which is exemplary normalized and there are a few other things that bother me in Cronus.
The current state of things is of course very experimental because I am mainly doing research or using parts of the project for customer problems. Currently it is only possible to convert a C/Al code unit in the database with empty methods into reasonable C# to do something there and get it back into the database.
Furthermore there is a small object explorer which can download the original C# files of code units compiled from C/AL from the database. At my local level of development it also supports AL apps and manual manipulations.
So the GitHub Repo was not up to date. Since I've only developed for myself so far, I wasn't so proper at commits.
What I develop how and when depends on the interest of the people. So far I was the only one interested so I only developed things for myself. If others, for example you, are interested in the project I can make it more professional.
It's easier to motivate yourself for something when you realize that other people want what you're doing ^^.
@Gallimathias Wow, that sounds really impressive. That's some big plans you're making here. I think your idea about inhertiance is great because I think that's what many here want, and the current AL stand doesn't really have an adequate solution for that. If you want to develop something meaningful, then I think it would be a good approach to mainly take care of the topic reports. It is almost impossible to expand the current reports, and the DataSet is always very inflated. If you could create a simple extensible solution here, I think it would help a lot of people. The solution should be easy to integrate with Business Central, not run externally like many of the reporting tools. This is the only way it can run in the long term.
Maybe that'll give you a clue. But I also think that people would like a solution maintained by the community to be able to map classic where-used scenarios in C/AL and AL objects. So far, all solutions are proprietary, and incredibly expensive. Many of the solutions offer an alleged community version. In my opinion, however, this is more marketing than real community work. Therefore such a tool would be very important for future developments from my point of view.
These are two ideas that come to my mind spontaneously, where Microsoft does not offer good solutions. I'm curious to see how your project develops. I am always open to community projects because I simply like the spirit behind them. A product is only as strong as its community.
@FSharpCSharp Thank you for the kind words.
Yes, I have so many visions. And I think my current project structure is also quite practicable, so this could be something good for the future ^^.
As can be read in many issues, I am convinced that we cannot avoid the topic of inheritance. I believe that heredity is exactly what it takes to keep NAV powerfull. After consultation with many of our old colleagues in our company i'm even more convinced of it. You're absolutely right that there is no publicly communicated solution to this.
As far as the reports are concerned, it should be no problem to act directly on the database as soon as the inheritance and the code units are available. With inheritance it will be super easy to customize reports.As far as I've tried it, it is also quite easy to introduce new object types. I could imagine HTML reports in addition to the RDLC reports.
The cool thing about Advanced AL is of course that it runs with NAV and not somewhere external. This is also one of my goals because I don't want to scare away my old colleagues with the most modern features possible, I just want to go a different way than Microsoft.
I am also a very big fan of community projects. I love the creative collaboration and the spirit behind community and open source projects. I firmly believe that such work creates added value for everyone and thus ultimately also advances society as such.
If people want to join, I'm willing to start a group here at GitHub and, among other things, hand over my project to this group for further development. Let's manifest the community just like one the mono project did.
Hi! This issue is beyond the scope of the AL language and development tools. Please go ahead and post this to our Ideas forum at https://aka.ms/BusinessCentralideas, or vote up the idea if its already there. We're constantly monitoring top Ideas and will consider them for a future release.
