Dynamics User Group
Dynamics User Group
  • User
  • Site
  • Search
  • User
Dynamics 365 Business Central/NAV User Group
Dynamics 365 Business Central/NAV User Group

Mark Brummel

  • Forums
  • Blogs
  • Resources
  • Wikis
  • Events
  • Leaderboards
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Dynamics 365 Business Central/NAV User Group requires membership for participation - click to join
Mark Brummel
By Mark Brummel - Author of Microsoft Dynamics NAV 2013 Application Design

  • Home
  • About
  • Contact author
  • Subscribe by email
  • More
  • Cancel
  • Posts RSS
  • Atom
  • More
  • Cancel

-

-
 
Monthly archive list
  • April 2018 (5)
  • March 2018 (6)
  • December 2017 (2)
  • July 2017 (1)
  • May 2017 (3)
  • April 2017 (3)
  • March 2017 (1)
  • February 2017 (1)
  • November 2016 (5)
  • October 2016 (1)
  • September 2016 (6)
  • August 2016 (2)
  • July 2016 (2)
  • June 2016 (4)
  • May 2016 (1)
  • April 2016 (1)
  • March 2016 (2)
  • December 2015 (12)
  • November 2015 (12)
  • October 2015 (8)
  • September 2015 (8)
  • August 2015 (7)
  • July 2015 (6)
  • May 2015 (2)
  • April 2015 (3)
  • March 2015 (3)
  • February 2015 (5)
  • January 2015 (10)
  • December 2014 (12)
  • November 2014 (9)
  • October 2014 (1)
  • March 2014 (1)
  • November 2013 (1)
  • October 2013 (1)
  • September 2013 (6)
  • June 2013 (2)
  • April 2013 (2)
  • December 2012 (3)
  • November 2012 (3)
  • October 2012 (4)
  • September 2012 (5)
  • August 2012 (2)
  • March 2012 (3)
  • January 2012 (2)
  • November 2011 (8)
  • October 2011 (2)
  • September 2011 (2)
  • August 2011 (1)
  • May 2011 (2)
  • April 2011 (1)
  • March 2011 (1)
  • February 2011 (2)
  • January 2011 (3)
  • October 2010 (3)
  • September 2010 (12)
  • August 2010 (4)
  • June 2010 (3)
  • May 2010 (4)
  • March 2010 (1)
  • January 2010 (2)
  • December 2009 (14)
  • November 2009 (17)
  • October 2009 (4)
  • September 2009 (5)
  • August 2009 (1)
  • June 2009 (14)
  • May 2009 (2)
  • April 2009 (7)
  • December 2008 (1)
  • September 2008 (3)
  • August 2008 (1)
  • June 2008 (1)
  • May 2008 (1)
  • December 2007 (1)
  • October 2007 (1)
  • September 2007 (1)
  • August 2007 (2)
  • July 2007 (1)
  • June 2007 (1)
  • May 2007 (1)
  • April 2007 (2)
  • October 2006 (1)
  • July 2006 (1)
  • June 2006 (6)
Related
Related Tags
  • Azure
  • Book
  • design patterns
  • Design Patterns - General
  • Directions
  • Directions USA 2009
  • Dynamics NAV
  • Events
  • General
  • NAV 2009
  • NAV 2009 SP1
  • NAV 2013
  • NAV2016
  • Pages
  • Performance
  • Product News
  • PRS
  • Role Center
  • RTC
  • SQL
  • SQL Server
  • Tip
  • Tips & Tricks
  • Tips and tricks
  • Upgrade
Blog post list
  • Tags
  • About
  • Contact author
  • Subscribe by email
  • More
  • Cancel
  • And then there are “Object Numbers”??

    Marq
    Marq

    Walk with me through the learning curve of a developer who is new to Business Central. We’ll assume he/she is familiar with modern web development.

    Wow!

    I’ll give Microsoft the WOW effect. When you spin up Business Central you get more than you bargained for. Where other frameworks show you a hello world and an example of how to call a web service and display the results in a table Microsoft really gives you an incredible experience to start with.

    First, there were “Pages”

    When you start customizing the User Interface of Business Central you’ll probably, sooner or later, end up with an extension that has some page extensions. If you look at them you’ll probably expect some HTML and some JavaScript.

    This is not entirely true, but it’s not that far off. The way pages are constructed using metadata is not that much different from Razor or Angular and if you are familiar with JavaScript you can probably figure out how to read AL code.

    So pages are approved. For a good reason because pages were designed as a first class three-tier citizen about a decade ago.

    Now to add some custom code

    Next thing you want to do is to add some logic. Being a good developer you don’t want to add too much code to the UI so you start looking for the “back-end” system. Where do I write C# and how to I map this to these “pages”.

    You’ve noticed that pages map to something that is called a “table”. This is weird, but ok, what’s in a name, it kinda looks like a class and there is mapping between this “table” and these “pages”.

    A table looks like a class. It has properties, although they are called “fields” and there are methods which are called “procedures”.

    Then you browse further in the documentation and discover a “codeunit” object. Now you are completely confused because a table and a page can be mapped somewhat to what you are familiar with, but this “codeunit” only allows for some procedures. There is no constructor, no properties.

    What are these numbers anyway?

    By now you’ve probably bumped into the fact that all “objects” in Business Central need to have a number and to understand why you need to understand how things work after you’ve completed your extension.

    But we are NAV developers!

    I was probably wasting your time because there are no developers who are new to Business Central, there are only NAV dino’s trying to do what Microsoft asks them to do. Move to Extensions.

    Off all the heritage that Business Central gets from NAV, object numbers are probably the most awkward one, especially if you take away C/Side where they make a lot of sense.

    I’ve always tried to use Object Numbers to group my objects together that belong together. True, it’s not easy because you always have more pages than tables, but with a little help of Statical Prism and Upgrade Codeunits you can keep a clean schema.

    What Would You Expect?

    Modern developers expect namespaces and true objects, not a file that is called an object because in the legacy system this file was stored in an Object table.

    Most of you have probably given up by now but object numbers are important in combination with C/Side but they become extremely cumbersome in Business Central. Especially now that Microsoft is allowing the world to code for free in any object between 50.000 and 99.999. Who the f*ck is ever going to go through AppSource if you can sell your solutions for free!

    But who is going to make sure object numbers are not already taken? How do you manage renumbering and updates?

    I give up…

    In Dutch we have a saying, it’s neither meat or fish. Without C/Side object numbers don’t make sense and in an object-oriented world a table and a class are the same with the difference of not writing data to the database.

    So why are these numbers important Mark?

    I promised you to explain it, didn’t I?

    Many of you, or most of you, think that Microsoft wrote a new compiler for Visual Studio Code, but this is not true. It’s more of a pre-compiler or syntax checking tool that you run in the fancy modern world of VSCode where everyone can write a compiler.

    When you publish your extension the real compiling begins and this is where “not much has changed”. This is not 100% true, but behind the scenes Business Central still generates C# code and these C# files get named with the object number.

    If you manage to mess up the compiler, something I did last week when trying to create a Matrix Page, you’ll get a weird error message that C50000.cs does not allow to convert a NAVInt to a NAVDecimal or something along those lines.

    Now, I’m not going to explain to all you kids what a Matrix Page is and where that came from, that is a bedtime story for another time.

    OCC

    • 2018-4-23
    • Mirror post
    • Dynamics NAV
    • 141 views
    • 0 comments
    • 11 hours ago
    • More
    • Cancel
  • Why C/Side deserves one more round. At least…

    Marq
    Marq

    I use Extensions and Visual Studio Code in my daily life. Or at least for a while, nowadays it’s more something in my weekly life. I try to avoid them when I can.

    Not because they are bad or evil but because they slow down my productivity, and because I have legacy software.

    Almost everyone I talk to agrees that programming extensions is slower and more clumbersome than C/Side. Not just the first few weeks.

    The Differences

    When Extensions were first shipped I was stronly against the way they were architected. Microsoft simply slapped to existing pieces of technology together with a PowerShell sauce and sold it as the best thing since sliced bread.

    It was even sold as being the only way to have decoupled code.

    This, my friends, is where I think it went wrong.

    With C/Side it is possible to have decoupled code, but it is not possible to have decoupled tables and pages. Only if you keep the delta files, which is the artifact Microsoft used as one of the ingredients for Extensions.

    If Microsoft would support Table Extensions and Page Extensions in C/Side and if they would disable access to existing objects C/Side would have the same technical capabilities as Visual Studio Code.

    It would in fact be capable of doing much, much more… I’ll get back to that.

    Visual Studio Code has native Git integration. True. I’ll give you that. I’ve used it a lot but I have yet to find the true value compared to exporting text files from C/Side and moving them to Git manually.

    With Visual Studio we cannot debug a live system, or look at an existing object. There is no solution for XMLPort Extensions or Report Extensions nor can you simply replace existing objects with new ones.

    Legacy & Monoliths

    The true difference between Visual Studio Code and C/Side is how the solution is managed. Both tools have intellisense and can handle thousands of objects. If you create and maintain an Angular project in VSCode you’ll see that your project easily contains more objects than you can oversee.

    Which is where the value of C/Side is imminent. Where Visual Studio Code expects you to only edit a handful, maybe up to 100 files, C/Side allows you to easily navigate accross every file in the solution and change everything.

    Visual Studio Code is designed for modern decoupled applications that take dependencies on packages.

    This is where we get challenged because NAV, Business Central or Navision (I don’t care how you call it) Is not a decoupled application. It’s a monolitical dinosaur that requires years to master and was never designed with decoupling in mind.

    ISV Solutions

    Most ISV solutions are also monolitical applications because we took the habbits from Microsoft and designed our solutions in an identical way. Microsoft must do it right, so let’s do it like they do.

    WRONG!

    I don’t blame you for making that choice. I did the same and it is the very reason I decided to keep working in C/Side. The solution I work with every day has over 2000 objects. Even though these objects are not depending on the Microsoft objects it is very hard to manage them in Visual Studio Code. You actually realise how smart object numbers are and how easy they make C/Side work once you don’t have them anymore.

    Visual Studio Code & Decoupling

    VSCode is designed for smaller, decoupled projects. You can work with multiple projects open at the same time, but they work best when separated.

    To get the most out of the VS Code experience you need to refactor your solution in multiple extensions and figure out the dependency schema.

    Which is a shitload of work and who has time for that.

    The Other Difference…

    There is another difference between Visual Studio Code and C/Side that makes it valid for Microsoft in my opinion to keep C/Side alive.

    Imagine the scenario a few paragraphs ago. Imagine C/Side with a Table Extension object type and a Page Extension object type. That would make both environments identical rithg?

    No… actually it would give C/Side a huge competitive advantage to Visual Studio Code.

    Financials Object Files…

    Aka Fobs… Tell me how many times you only change two objects in a database that has 8.000 objects or more. Or just one.

    How do you ship them? Exactly, you just export the file using C/Side.

    If my solution with 2.000 objects were one big extension shipping small changes would become a nightmare. We all have a DTAP system but how often do you make a fix in Test so the tester can continue? How many of you have a Hotfix database? More scary; how many of you just make a change to a report or a page in Production?

    Microsoft Keep C/Side Alive!

    For Microsoft to make Business Central in the Cloud succesful they don’t need to do away with C/Side.

    The new generation of Cloud developers (if they exist, I only see NAV partners jump on it) never see C/Side.

    On the other hand, if Microsoft would move base-NAV to Visual Studio Code we would all take a huge step back.

    Navigating in 5.000 or 10.000 file project in Visual Studio Code is a freaking nightmare and compiling and shipping the whole monolith for one report would make customers run away to the competition in a fraction of a second.

    Great, so now what…

    So Mark, you say Microsoft has to keep C/Side because of the way NAV is designed, because it is not decoupled. Yes, that is what I am saying.

    And this is where it becomes freakingly dangerous what I am about to say.

    Let’s be the devils advocate…

    If you are forced to refactor or redesign your monolithical applications into decoupled microservices, why would you per-se do it in AL?

    That my friends, is where and how we will continue this blog series by talking about things like the API, CDS, PowerApps, Asp.Net Core and Angular.

    Yes, I choose to stay with Microsoft, but you are correct if you think you might as well switch to any other framework as long as it is a web-framework. The latter is important if you want to embed with Business Central, the best cloud solution out there today.

    • 2018-4-22
    • Mirror post
    • Dynamics NAV
    • 293 views
    • 0 comments
    • 1 day ago
    • More
    • Cancel
  • Using Business Central as Microservice

    Marq
    Marq

    Upgrading software is hard. Not because merging software is hard. It’s hard because people are creatures of habits.

    Let me give you an example. We recently upgraded from NAV 2016 to NAV2018. This means big changes to the Customer Card. I’m fine with that. While in the process I moved my customizations to a Page Extension and I was a happy IT manager/developer.

    Few days/weeks later one of our users comes to our service desk with a posted sales invoice in a currency code we’ve never used before. After some investigation the guy handling the support call figures out that since the upgrade new customers are created wrongly.

    Someone at Microsoft (I love saying that) decided it was a great idea to move the Currency Code to another tab or a promoted field, I can’t remember what it was.

    The person who creates new customers could not find the field and just thought not to care anymore. However it turns out that in the old version she would always change the currency to euro. When “we” were implemented 12 years ago my predecessor decided to create customer templates with currency codes and they were wrong. Nobody ever reported it. Changing to Euro was just part of the procedure.

    Business Central is a monolithic application and therefore hard to upgrade. It has more than 5.000 C# files that are created from C/Side or AL Extensions. The way this all works behind the scenes is pure genius.

    Mark, wait a minute… Mololithic? Microservice? What the f…?

    Ok, if you are not familiar with these terms you should read at least this article and probably a few more. It’s by Martin Fowler so you cannot go wrong.

    The idea behind Microservices is that you break up your architecture into individual components that communicate using API’s. There you go in a nutshell.

    Even though Business Central has a brilliant API it is not used by Microsoft itself. When a Production Order needs to post something to the General Ledger it does not use the API but everything internally is written tightly connected.

    It makes a lot of sense if you consider that Business Central is based on Navision which was designed 30 years ago.

    One of the fundamental design principles of Business Central is transaction integrity. As a developer you should not be able to break that. Well, not unless you put COMMIT everywhere in your event subscribers.

    On top of that Business Central has transaction isolation to prevent users to post to the General Ledger at the same time.

    All of this is fine until you want to grow with the application and this is where Microservices get interesting.

    It’s the API stupid

    With microservices you can create several applications that all work together. These applications can be existing software that you buy or subscribe to.

    At the company I work for we decided to stop trying to put everything in NAV several years ago. Back then I was against that decision but now I am a big fan.

    Because different departments use different software they can all individually upgrade, have small changes done (Extensions in Business Central are brilliant for that) as long as they respect the API.

    Most of the API’s I work with respect versioning. If a new version of the software is released the old API works for quite a while until you get notified that it will be depreciated. Giving you time to upgrade.

    New Design Paradigm

    If you’ve used NAV as a development platform you’ve probably created your own monolithic application and you should reconsider that architecture.

    I would encourage every partner if possible to investigate if it is possible to use the API and seperate your IP from Business Central.

    In the next set of blog posts I am going to explain how to connect the bits together. Personally I’ve decided to replace NAV with other Microsoft Tech. We’ve chosen Asp.Net Core II with Angular giving us a C# server and a TypeScript front end. So far it is an interesting journey and I’ve created a strategy that will allow us to move bit by bit.

    Since I am not yet sure what will happen with CDS/CDM we’ve decided not to choose a database yet. Uncle Bob has learned us never to start with choosing a database. Always make sure you can switch databases.

    I LOVE Business Central

    Don’t miss interpret me. We are NOT moving away from NAV or Business Central. In fact, part of the bigger strategy is to move to the Microsoft hosted option so we can benefit from continuous upgrades and interesting apps from AppSource, CDS, CRM etc.

    I just want to move away from Monolithic design into Microservices and Business Central is my financial Microservice of choice every day of the week.

    • 2018-4-11
    • Mirror post
    • Dynamics NAV
    • BusinessCentral
    • 626 views
    • 0 comments
    • 12 days ago
    • More
    • Cancel
  • Project Green – The final battle? (CDS 2.0)

    Marq
    Marq

    Opinion, by Mark Brummel

    When Microsoft closes a door, they open a window. Sure I miss working with the classic client where I could make forms look however the customer wanted them to look. All the colors available withing the RGB pallette, a simple report designer and the database is one file.

    If NAV, pardon me, Business Central, was still “that” we would have been out of business for sure even though someone told me 75% of NAV installs are still classic.

    We live in a connected world with Web Services, Machine Learning & Serverless Computing. Windows is no longer the dominating operating system.

    So Business Central is running cross platform and is a cloud first citizen. Microsoft invested millions of dollars/euro’s to make that happen.

    Back to the title of the blog. Project Green… again.

    Two weeks ago I managed to get the whole Great Plains community against me. Boy I can tell you these people are well organized. So in this blog I am not going to talk again about Great Plains and where they are in this stage.

    Let’s talk about CRM and AX, oh, and Common Data Services.

    NAVTechDays 2017

    Last year Michael Nielsen challenged me to co-present at NAVTechDays about PowerApps and Common Data Services. For me that was an eye opener. We agreed I would do PowerApps and he would do CDS.

    A good thing from presenting something you know *** about is that unless you want to look like a fool you better learn it. Did not help me though, I stil looked like a fool.

    I ended up connecting Navision 1.1 to PowerApps and Michael showed CDS 1.0. I was told, but this can be wrong, that CDS 1.0 was based on AX technology. I think the concept is great but if you watch the video you probably agree that it was not ready for prime time yet.

    CDS 2.0

    Word reached me that Microsoft was not happy with CDS 1.0 and was looking for something better. The concept is great.

    The CRM people got a shot at it and last week I was reading on LinkedIN that the marriage between xRM and CDS is no longer a secret. Aparently the CRM experts also have different opinions about their new baby.

    Yes, XRM Is The New Common Data Service

    No, Common Data Service is not the new XRM

    I did not have time to read it yet and don’t have an opinion. Last thing I want is the CRM community all over me.

    What is Common Data Services Anyway?

    In essence what I know about it, CDS comes together with Common Data Model. You get a pre-defined database with a service that runs transactions. CDS 1.0 did not have the latter. I’ve been told CDS2.0 supports transactions.

    On top of CDS and CDM you can use PowerApps as a front end. PowerApps is a cross platform WYSIWYG UI tool.

    Wait Mark, can you please repeat that?

    No, that would be silly, you can read it again. But if you are smart enough you can guess that this is not that much different than the idea of Business Central. You get a pre-defined database, a service and a front end.

    Isn’t it a bit silly? Why would Microsoft do the same thing twice? Well, you have to wait a minute, because we have not talked about AX just yet. Or Dynamics 365 for Finance and Operations.

    D365FO is also a pre-defined database with a service and a front end. But than in the size of an elephant. Just like Business Central it uses extensions to be customized.

    So what will Microsoft do next?

    How would I know. It just sounds a bit silly that Microsoft spends millions of dollars maintaining similar platforms. I am not in the Microsoft Board but you can guess consolidation will continue right?

    Sidenote to my Great Plains readers. You are still there, no worries. You are just not part of the consolidation. I am a bit jealous.

    For now I guess everyone will just keep on rowing in the boat they know. If you are a NAV developer it is quite easy to learn how to make extensions and if you are a CRM developer you can now do CDS and CDM. It’s just ever more confusing for those poor recruiteters who can send their emails to even more candidates hoping they hit something.

    It took “us” 15 years to get here. The first decade or so was spent making mistakes and trying stuff that technology wasn’t ready for yet. The last few years things are getting more serious.

    Wat is the big break throug?

    The Business Central team has to integrate with CDS and CDM. That is not a question, but an order. If you run BC, you will be able to access your data through the CDS API.

    This means you can probably customize NAV, shoot, Business Central, also via more ways. You can build PowerApps.

    You can probably also migrate back and forth from BC to FO or the other way around as they are both connected to CDM. If more stuff is connected to CDM your life will be easier.

    CDM is probably something you will want to keep an eye on if you make a living doing EDI.

    What about AppSource

    If you build IP for Business Central it can only be used by BC users, not by AX users. If you build for FO it’s the same story.

    But, if you build IP on top of CDM everyone can use your solution. Even a NetSuite customer because no-doubt someone will create a CDM connector to NetSuite.

    Think about this for a moment… and then decide what your monday is going to look like. What are you going to learn tomorrow?

    At this time not much information other than the links I’ve shared is available. Please share linked in the comments.

    To be continued…

     

    • 2018-4-8
    • Mirror post
    • Dynamics NAV
    • 1355 views
    • 0 comments
    • 15 days ago
    • More
    • Cancel
  • Business Central, ERP or Development Platform?

    Marq
    Marq

    Sometimes you need an external signal to rethink your strategy. This morning I read this tweet on my timeline.

    @markbrummel Thx for sharing your thoughts around business central. In your opinion… if your are looking at competing products. What might be a better option than D365BC? Say 50 concurrent users, multi currency, cloud only, easy to extend… sapB1?netsuite? Acumatica? D365FO?

    — Kim Kopowski (@KimKopowski) April 2, 2018

    Funny to me because I don’t see NAV or Business Central as an ERP first, I see it as a Development Platform first with some ERP for free. One that I know inside out better than almost anyone else.

    How do you see it? Should we expect Microsoft to take a new approach with ERP first and Development Platform second? For years, or maybe even a decade, everything around NAV was about technology and developers.

    With the API present and other development platforms superior it would not surprise me that Microsoft changes this strategy.

    Should this old dog learn new tricks? What is the learning curve? Which other platforms? Share your opinion please!

    Don’t forget to register for today’s webinar and let’s see if we can find out what happens to C/Side and Object Files. To Fob or not to Fob, that’s the question.

    • 2018-4-3
    • Mirror post
    • Dynamics NAV
    • 2322 views
    • 0 comments
    • 21 days ago
    • More
    • Cancel
>
  • DUG Home
    • Contact DUG
  • Dynamics 365 for Finance and Operations/AX User Group
    • Forums
    • Blogs
    • Events
    • Documentation, videos and downloads
    • AX Partners Group
  • Dynamics 365 Business Central/NAV User Group
    • Forums
    • Blogs
    • Wikipedia
    • Events
    • Books
    • NAV partners group
    • NAV freelancers group
  • Dynamics 365 Sales/CRM User Group
    • General Discussion Forum
    • Blogs
  • Dynamics GP User Group
    • GP Discussion Forum
    • Blogs
  • Microsoft Dynamics 365 User Group
    • Forums
    • Blogs
    • Documentation, videos and downloads
  • About DUG
    • Announcements
    • Frequently asked questions about DUG
    • Suggestions to DUG
    • Membership service
    • Advertise on DUG
    • Become a DUG sponsor
    • Follow us on LinkedIn
    • Follow us on Facebook
    • Follow us on Twitter
  • More
  • Cancel
  • Microsoft Dynamics 365 User Groups

  • Dynamics 365 User Group
  • Dynamics 365 for Finance and Operations User Group
  • Dynamics 365 Business Central User Group
  • Dynamics 365 for Sales User Group
  • Microsoft Dynamics User Groups

  • Dynamics AX User Group
  • Dynamics NAV User Group
  • Dynamics GP User Group
  • Dynamics CRM User Group
  • About DUG
  • Terms of use
  • Privacy Policy
  • Frequently asked questions
Copyright 1995-2018 Dynamics User Group, all rights reserved.