Development in Business central - what cannot be achieved?

thomastthomast Member Posts: 102
Hello folks,

Since we will not be able to modify the source code in business central online, what developments will we not be able to achieve? For example, can we add a standard field to a page?

Love to hear your thoughts!

Thomas.

Answers

  • dborgdborg Member Posts: 3
    Hey, still early days to the BC thing but here are my thoughts:

    Agreed, you cannot modify source code. If you need to create a new field in a standard table you need to create a "table extensions" (a new object type) in VSCode (using AL). this still, does not modify the underlying standard table but creates what is known as "companion tables". These are seamless at runtime.

    Likewise, if you need to add a field on a standard page, you use a page extension (new type of object) and add the field there. This will "extended" the standard page and not modifying any standard object.

    You can obviously create new tables, new pages, code units etc to extended (not customize) NAV functionality.

    Keep in mind with BC on the cloud you need to work only with events (live, breath, think only in events). So any modifications to source code should be done by subscribing to events (events raised by the platform i.e. triggers or events raised by Microsoft in the standard code).

    Ideally, when creating new functions in codeunits you should also prepare your code with this in mind. By raising events before your logic and after your logic (onBeforeYourLogic, onAfterYourLogic) if that makes sense.

    There are good sources and videos online to get you started.

    Good luck!
    Dave
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    edited 2018-10-01
    dborg wrote: »
    ..but creates what is known as "companion tables". These are seamless at runtime.
    Well, to the point when your data becomes massive and you need a decent filtering performance on it...

    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • thomas_barbutthomas_barbut Member Posts: 19
    @BlackTiger
    To be 100% honest I like the new approach and my gut feeling tells me that it will be a great success.

    As of right now, some things are missing. But Microsoft is working on those. Like Permissions, Report Dataset extension, some missing events and non-external procedures, etc. . .

    best regards,
    Thomas Barbut
  • ara3nara3n Member Posts: 9,255
    BlackTiger wrote: »
    It's impossible to develop anything big and serious in BC without modifying source code. It's impossible to do everything only using "events". Microsoft don't get it. 99.999% of NAV implementations are about amending standard business logic, not just "extending" it. BC has no future.

    One of the Strengths of NAV is Open Source/Shared Source. And MS is taking it away.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • dborgdborg Member Posts: 3
    I understand these concerns as I too, come from a background of large projects. I am always thinking about how we can achieve such large projects with events, something which as of now seems quite difficult.

    I have to agree with @thomas_barbut, I have a strong feeling that things will improve and it will be a great success. In my honest opinion it is still in its early days and we need to wait for a couple of releases (in fact, I would not suggest to implement any large project with BC right now).

    Also, there were some big announcements tonight at Directions on this topic. We have to wait and see i guess :) just my 2 cents.

    Regards
    Dave
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    edited 2018-10-01
    BlackTiger wrote: »
    IMicrosoft don't get it. 99.999% of NAV implementations are about amending standard business logic, not just "extending" it. BC has no future.

    In my opinion, Microsoft gets it very well, it is just that they do not want it. There is someting better - for them, They simply prefer the app + cloud as this is far, far better money making scheme for them as the owner of both software and computing environment.

    The scalability is there, but it is rather "vertical" imho - thousands of relatively small customers, with not very big databases. This model requires just this architecture - sealed core + relatively thin extension layer.

    Also by owning the software and the cloud resources they are in full control, of partners, and their customers. Should some performance problem occur in one of core module the only way out will be to pay MS more money for better-performing cloud environment, rather than getting a freelancer, or having a specialist in-house who could address the issue at the root of it - in the source code.

    My feeling is that BC has the future, very bright, but it is us, the 'old style' partners who do not have a future - not unless we go with the flow. And the majority will, they race already who will jump as the first onto the new BC wagon, making the most money.

    I guess however that even if we "join the crowd" partners future will not be as bright as BC's. The money pot will shrink significantly over time. This is due to limitations of what you can do using extensions. Limited possibilities will make apps more and more overlapping - functionality wise.

    Customer will be able to jump easily from one solution to another, from partner to another, therefore the app prices will go down - but not the core - as this has only one owner and no viable competition.

    Just look at what is going on the Android market app - for every matter you can think of there are dozens, if not hundreds of apps. Lots of them free or paid by adverts. I guess it won't be long before someone will come up with this payment model for BC app, lowering incredibly the price bar, and newcomers revenue stream.

    With revenues shrinking and no customers commitment, small partners will not be able to grow (and grow their solutions) organically, as this will require a massive upfront capital investment. Big partners will become bigger, medium or smaller partners will stay small struggling, the smallest ones will simply die out.

    Many small apps with overlapping functionality will give Microsoft un proportionally big power. If one partner goes below, there will be another with another app having similar functionality

    It is a bit pessimistic vision, unfortunately small 'ripples in matrix fabric', like, for example, just today's Microsoft promise that by 2020 there will be no RTC anymore, indicates just that. Thinking of it just a half a year ago Microsoft was talking about BC being available on premise for at least 5 years, now, well, it is still going to be available, it's just a small part of it, the RTC, is going to disappear in 2 years time. Every Directions new directions :smile:


    My 0.02£
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • thomas_barbutthomas_barbut Member Posts: 19
    @Slawek_Guzek . You've hit the needle on the head.

    @BlackTiger You really hate Business Central. At least give it a try. :D


    best regards,
    Thomas Barbut
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    BlackTiger wrote: »
    If standard posting routine does something I don't want to do how can I change code flow using "events" system?

    Easy.

    Static subscribers to on before/on after insert to all ledger tables, then in OnAfterPost you delete all inserted entries and create new ones. Simples! :wink:

    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    @BlackTiger seriously?

    First - what is the point of changing code flow if you don't want to change output? It is all about having different output from posting routine, not changing the code for the sake of changing the code, (with the exception of adressing performance problem), right?

    Secondly - have you noticed a wink at the end of my post?. If not - re-read my post carefully please- it's there. If you did noticed then you apparently you did not understand its meaning, so here it is the explanation - proposed solution was a joke.
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • rickyl76rickyl76 Member Posts: 25
    Seems a strange move by Microsoft. The biggest reason Nav has grown to where it is in my opinion, is due to it's flexibility and ease of customisation. Take that away and it has no particular USP and therefore I don't see people choosing it as their solution in the future.
  • ara3nara3n Member Posts: 9,255
    MS doesn't care about existing clients. They are trying to compete against Quickbooks. All the anual maintenance companies have given is gone to a product they won't be able to use.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • swpoloswpolo Member Posts: 80
    edited 2018-10-04
    Most of customer's databases have ISV solution implemented.
    We will see perspectives of BC once any medium or big ISV solution be upgraded to extensions.
    At the moment i do not know any ISV with such solution.
    Lets see.

    Nav Upgrades and DEV outsourcing
    Reports transformation to RDLC
    List -1h , Complex List -3h, Document -4h (dev hours)
    navisionupgrade.com
  • ara3nara3n Member Posts: 9,255
    edited 2018-10-05
    What will end up happening is that all the ISV and partners will find workaround. The ISV solutions will be less tightly integrated.
    As for changing Existing code in CU 80 a partner will copy CU 80 and create a new Posting Routine and call that. And that will create new problems for upgrades.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    What we see is "McDonaldization" of (what used to be) NAV.

    At the moment NAV is a very good and not expensive restaurant:
    - What would you like?
    - A steak please.
    - How would you like it?
    - medium-rare please.. etc

    BC is like Mc Donald:
    - What would you like?
    - A steak please.
    - Well errr, the closest you can have is a chicken burger, but wait! You still have a great choice: a tee or pepsi or coffee, and you can choose 0, 1 or 2 sugar cubes!!

    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • JuhlJuhl Member Posts: 724
    Good one Slawek 😂
    Follow me on my blog juhl.blog
  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    It turns out that it is not going to be that bad!

    Many thanks to Arend-Jan Kauffmann for sharing this.

    <joke> With a dedication to @BlackTiger :) </joke>
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • MattHMattH Member Posts: 15
    Can anyone explain what the following is really saying?

    "Any data from tables with code customizations cannot be be carried forward from Dynamics NAV."

    As found in this link.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    What is the BC version of customizing T36 Sell-To Customer No. OnValidate to copy a new field on the Customer to a new field on T36? Event? there is no such event. OnBeforeModify and suchlike are too late as one needs to see it right after exiting the field.
  • JuhlJuhl Member Posts: 724
    OnValidate Event
    Follow me on my blog juhl.blog
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    BlackTiger wrote: »
    @Slawek_Guzek I have a task for you - implement "precise item net/gross weight accounting" using events only. Input:
    - same item unit can have slightly different actual weight
    - item can be either purchased or manufactured (assembly/production)
    - every outbound item ledger should have actual net/gross weight
    - actual weight can be specified in sales document (overriding calculated on posting)
    - weight application should work similar to quantity - FIFO/reserved/apllied

    I think ara3n nailed it. You will end up copying CU22, CU80 int your add-on range (or customization) and you will end up with a different kind of maintenance problem - automatic updates will change the standard CU22, CU80, yours is not changed. The big problem here is that it can be absolutely breaking without any previous warning.
Sign In or Register to comment.