What I learned is, that there are 2 different approaches for mocking http calls now, depending on which way you choose to implement api calls Thanks a lot, also for the code sample which will be certainly helpful for me.

No issue, just watched the session with this new feature and asked myself if it also works with the Rest Client module. I cannot see why this should be an onprem feature

Most of us are experts in our field. I think it's not easy to ask things in public so as not to appear unknowing. And on the other hand what I'd like to say sometimes can't be written in a short message. But I'll take it as a hint to share my #msdyn365bc related findings more often again.

🙏

Nice 👍🏻

Thanks for clarification. I was already thinking something like that, because the current version unfortunately, was probably only enjoyed by a few people

and btw wouldn’t the rule be better placed in UICop?

Thanks for pointing that out, that's exactly the rule I need 🙏 Even if it is a pain to find out which rules are contra-productive for nonAppSource apps and to deactivate them individually.

I really like the AL Rest Client Module and have just used it for the first time in my actual API project effectively. So, many thanks for this contribution to our community.

Not really a design guideline, but for BC developers it is crucial to know the application really well. The modules, application areas, data model etc. So I would learn BC before doing any dev.

I wrote a blog post about this some time ago

somcom.at/2022/09/26/a...

Developers are relaxed people and you can get almost anything from them, but don't talk to them if they are looking for a bug

Thanks for summarizing this topic. I think we need conditional mandatory fields. Because a field can be mandatory or not, depending on data.

📌