Remember that REST was just a technical preview in 10.1.500 so you should expect some issues like this to occur. And staying current, while challenging at times, is working well in 10.2 so far for us.
Mark W.
Yeah, I was going to go straight from 10.1.400.19 to 10.2, but it showed issues in Accounting. And with needing to get this integration done, I figured 10.1.500.38 would be a decent stop. Well, now I have to decide, do I go full 10.2 or do I work around the issues in 10.1.500.38?
Iâm curious what issues you have seen in accounting? (my accounting âtestersâ are not super thoroughâŚ)
The BAQ solution will upgrade well from 10.1.500, so if you have to solve the accounting issues then you could stop there. But I have to say that the smaller upgrades are easier than the bigger jumpsâŚFWIW.
Mark W.
I just got through the workbench and it showed to check everything related to accounting. I was going to check into everything when this came up and I wiped the VM and put it to 10.1.500.38 for testing to go live. Sorry I donâ have much more of an answer.
@Mark_Wonsil Ok, if the BAQ route will work and transfer in upgrades well, I am happy with that. Underlying question, by doing everything through the BAQ everything that is supposed to update will and everything that is supposed to be affected will be as well, correct? Note: I am assuming I selected the right pieces to update.
I donât know the specs so I canât really speak to âeverything will workâ. 
What I can tell you is the REST calling of BAQs is pretty solid. @josecgomez uses it too, so youâll be in good company. Might the UBAQ have some changes because it is calling the Business Objects? Maybe - but youâre reducing the upgrade surface with the BAQ route. Youâll only have to fix that one BAQ and all REST code will still work. If you put the logic in many REST calls, youâd have to update each of those.
Mark W.
Gotcha, makes sense. Besides, for me, I think it be easier to write a BAQ than to mess with all the REST! And yes, UBAQ would be the only way to go in this case.
A 50K ft view on REST optionsâŚ
- If you need quick and easy API surface for doing a GetByID / Update go through the OData Get / Post access.
- If you need 100% fidelity with what the client is doing similar to âxâ form, the custom methods are there and SHOULD be identical to existing WCF calls.
- If you have a âsimpleâ need for querying data similar to a dashboard, BAQ is easily the way to go in REST as well. Depending on your opinion of UBAQs, etc then you can take advantage of that as well thru the REST BAQ endpoint.
The trade offs between calling the full API versus BAQ/UBaq in WCF are the same for REST. Full datasets queried for versus targeted queries, etc.
Also, the trade offs in REST approaches custom vs OData should have been called out elsewhere between the options. If you have further questions or review needed, please speak up
1 Like
Quick background, we are trying to integrate third party shipping software with Epicor 10.1.500.38. The above in this post didnât pull the individual lines/releases so I was thinking of going the UBAQ way. In your opinion is this a good option or would you update to 10.2 and use REST? The software company originally wanted to go with a direct DB interface but in E9, the UI didnât update correctly and I am no fan direct DB.
In 500 REST is still officially a beta so take that into account. I have not had the time to look over your query (Recovering from a âholidayâ where my daughter got married so still digging out). I wonder if you are running into one of the key issues we had back then on some queries. I would heavily recommend jumping forward to a newer version if possible. I know I sound like that guy saying itâs all fixed in the next release but see if you can get those accounting quirks overcome âŚ
1 Like