Opinion on Api strategy

jordi79
jordi79 Member Posts: 285
in NAV Three Tier

We are moving from nav to bc. Our solution is heavily integrated to other solutions. One of the challenges is that all our integration is build on soap. But this will be deprecated in bc. After looking at standard ui pages, custom ui pages and odatav4, I found that these 3 technologies have limitations and issues.

Odatav4 in bc does not support deep inserts. Therefore, multiple operations have to be done using $batch calls. And there is a limit of 100 operations per batch.

As for custom ui pages, it does support deep inserts, but it has a bug where duplicate inserts can happen.

As for standard ui pages, it did not have the duplicate insert issue in custom ui pages, but standard ui pages cannot be extended.

In all these respect, cannot help but feel that soap is better.

Comments

  • kriki
    kriki Member, Moderator Posts: 9,127

    You can also publish a codeunit as a webservice and call a function in it. This function can accept a text parameter and also a return-value. That text can contain anything you want (CSV-file(!), XML, JSON, YAML, …..) and you can handle it how you want but you do need to develop it. It is even possible to change the text parameter to an XML port.

    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!

  • RockWithNAV
    RockWithNAV Member Posts: 1,193

    We still have SOAP services, it's not deprecated. It's all about which route you want to go through. API pages are vey much easier to handle with JSON in picture. With the help of Bound actions you can trigger a piece of code as well like SOAP we normally use.

    https://rockwithnav.wordpress.com/2025/10/14/bound-action-business-central-api/

    Thanks

    Blog - rockwithnav.wordpress.com/
    Twitter - https://twitter.com/RockwithNav
    Facebook - https://facebook.com/rockwithnav/
  • jordi79
    jordi79 Member Posts: 285

    I have been testing this. In my opinion, when SOAP is deprecated, the way to go is still webservices with odatav4. APIPages is still broken. A lot of BC validation code is written with UI pages in mind not API pages.

    This is especially true because API pages only support:

    DelayedInsert = true;

    This property broke a lot of BC standard validation logic.

  • jordi79
    jordi79 Member Posts: 285


    kriki     Member, Moderator Posts: 9,1272025-10-16

    You can also publish a codeunit as a webservice and call a function in it. This function can accept a text parameter and also a return-value. That text can contain anything you want (CSV-file(!), XML, JSON, YAML, …..) and you can handle it how you want but you do need to develop it. It is even possible to change the text parameter to an XML port.

    Yes. We can do this. But, the benefit of using a webservice or uipage is because it is "self documenting" with $metadata. That method that you described will be a last resort when all else fails.

Categories