Have you debugged into the code to see the results coming out of the SearchOrders method and ensuring they are correct at that point? If so, could there be some other caching in place affecting this? Donut cache or Request cache or something?
I cannot really debug live data, but doing it locally, the phone numbers are changed as soon as they are on the orders.
I also put up a test controller to output any unexported orders via the SearchOrdersmethod, and the phone numbers are changed on the two troublesome errors.
I'm thinking if it could be that Microsoft NAV have stored the orders, and aren't changing the information even though it's being sent new data, and thus reporting back the same error.
The client however tells me, that the orders are not in NAV.
But that almost has to be it. I'm 99.99% sure that the issue is not old data coming out of the SearchOrders method.
I'm thinking the client has to dig a bit deeper into their NAV.
We add name, address, phone and email to every orderline, as they are signups for classes.
When checking out, they can copy previously entered information from orderlines as their billing information.
But the editor config wasn't configured to show those informations in the backend, so I was only focused on the billing information, not the invalid information might have originated from the orderlines.
Added the fields to the editor config, then I could correct the phone numbers on the orderlines also, and then they were exported to NAV correctly. 👏😂
OrderService cache?
Hi
We're exporting orders to Microsoft NAV, getting them through the
OrderService.SearchOrdersmethodI have two orders that NAV won't accept, because the telephone number is in an invalid format.
I've corrected them on the orders, but the export still fails, because it's still the old invalid telephone numbers in the export.
Is there some kind of cache layer on the orderservice?
Umbraco v8.6.2 Vendr v1.2.3
Hi Michael,
Yes, there is a cache layer across all our services in order to save hitting the database constantly.
The cache is a static cache so will be invalidated on app pool recycle.
However, if you are using the
SearchOrdermethods these shouldn't actually be using the cache as those methods use direct DB access.Matt
Ok, but if
SearchOrderis using the DB, then I don't understand from where these old values are coming from?I've looked directly at the properties in the DB, and they are changed here.
Me neither.
Have you debugged into the code to see the results coming out of the SearchOrders method and ensuring they are correct at that point? If so, could there be some other caching in place affecting this? Donut cache or Request cache or something?
/Matt
I cannot really debug live data, but doing it locally, the phone numbers are changed as soon as they are on the orders.
I also put up a test controller to output any unexported orders via the
SearchOrdersmethod, and the phone numbers are changed on the two troublesome errors.I'm thinking if it could be that Microsoft NAV have stored the orders, and aren't changing the information even though it's being sent new data, and thus reporting back the same error.
The client however tells me, that the orders are not in NAV.
But that almost has to be it. I'm 99.99% sure that the issue is not old data coming out of the
SearchOrdersmethod.I'm thinking the client has to dig a bit deeper into their NAV.
Yea, it's definitely sounding that way to me if all tests are proving the various APIs are updated, then it must be there end.
Do keep me updated with what you find.
Matt
@#$%&! Found the error 🤦♂️
We add name, address, phone and email to every orderline, as they are signups for classes.
When checking out, they can copy previously entered information from orderlines as their billing information.
But the editor config wasn't configured to show those informations in the backend, so I was only focused on the billing information, not the invalid information might have originated from the orderlines.
Added the fields to the editor config, then I could correct the phone numbers on the orderlines also, and then they were exported to NAV correctly. 👏😂
Ahhhhhh, nice find!
Glad you were able to find the solution, that would have been a nightmare to try and debug remotely 😂
/Matt
is working on a reply...