Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Overview | Guided Tour | Free Trial
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
When calling an API endpoint on api.businesscentral.dynamics.com from BizTalk, we are required to include what looks like an Odata filter on the uri:
&$filter=(documentDate ge 2020-07-01) and (documentDate le 2020-07-31)
In PostMan this returns records, but when the spaces are "encoded" it accepts the request but returns no records
At the moment its a real struggle to change the BizTalk send behaviour to stop the encoding, so I was wondering if this is a API config issue?
Very interesting question. I just did some tests and reviewed the OData V4 specifications, and here's my observation.
It appears that the filter "values" can be encoded, but the OData filter syntax itself cannot be encoded.
See section 2.2 URL Syntax on this page:
The examples provided are not great, but notice that the parentheses are not encoded--only the filter "values" inside the parentheses are encoded.
The OData standard appears to have some optional conventions, so I have found that Business Central doesn't support all of the specifications in that documentation, but seems to support most.
I did a test with the BC Web API, and here's what I found:
Unencoded filter works properly:
items?$filter=number eq '1896-S'
Fully encoded filter does not work (filter ignored):
Equals sign is NOT encoded, but everything after equals sign is encoded works:
Based on this last test, encoding spaces AND apostrophes works for me
I then tested with date ranges, which also worked:
This above example appears to be essentially the same as what you are using.
The one thing I notice is that you have & before your "$filter" keyword.
Can you try ? before the $filter? In my example above, I'm using purchaseInvoices?$filter...
Here's a full URL example:
Let me know if the & vs ? makes a difference.
Thanks Steve for these suggestions.
What you suggested is what we've already tried.
The only difference being that we have additional parameters on the call.
Ok, sorry, a quick update to say that the fully encoded url did in fact yield results.
This turned out to be an issue with the actual date parameters we were asked to test with!
The API quite happily returns results if you encode spaces with "%20" or "+" (even within the OData filter).
Excellent! Thanks for the update!
Business Applications communities