I have been playing with the following rest call for a few hours. I am trying to get a list of all distinct ForeignTableName records in the SysTagSvc table. I know I could just create a BAQ and consume it via Rest but this is something I should be able to do without creating more custom elements.
https://myservername/epicortrain/api/v2/odata/epic06/Ice.BO.SysTagSvc/List?$apply=groupby((ForeignTableName), aggregate($count as Count))
According to the odata v4 specs, this is supported: Supported OData functions and clauses - Azure DevOps | Microsoft Learn
Any ideas?
This is a popular sentiment that I hear quite a bit - most recently at the latest Midwest Users Group meeting. It seems to go against the more popular software architecture ideas like MVC or Domain Driven Development. A client shouldn’t know nor care about the details of a repository. Programming in these modern methods, one abstracts away the implementation details to protect the client from changes in the service. If a BAQ can do the job quickly, great. I wouldn’t call the BAQSvc though, but would take advantage of Epicor Functions (once you get to 10.2.500+) and make up your own API. If someday the company replaces Epicor, you just have to implement the API service in the new ERP system and all your clients would still run. If the SysTagSvc changed drastically or if you decided to use Azure Cognitive search to return tagged data, you could change the implementation without disturbing the clients. Letting server implementations leak into the client code makes integrations much more fragile.
Just a thought…
2 Likes