I am on 10.2.200
This call: /Erp.BO.JobOperSearchSvc/JobOperSearches(company, job, asm, op) seems to ignore the company. I pass this: (EPIC06,005096-1,0,10)
I receive back the proper job/asm/op but it is for company EPIC03. Is this intended or I am overlooking something? I havent tested the BO alone, just havent had the time yet.
I guess I just had the expectation that if the call explicitly passes the company as a parameter that it would have an effect.
Yes, company change works with headers only.
If you call the list of items, without () like
/Erp.BO.JobOperSearchSvc/JobOperSearches
you would not be able to set company as well, so some other consistent approach is required. And it is not done yet.
@Chris_Conn this is one of the oddities in the api flavor. If you do it in soap and bltester you’ll be scratching your head as well.
In India on my cell but if I have a breathe this week I’ll dig up an old doc on this from a decade ago when I first discovered the pattern in V8 and why it makes sense. But drives you nuts on discoverablity.
Use headers for now
Thanks for the feedback everyone. I did end up just using the headers which works well. Safe travels Bart, eat some curry for me (because I wont eat curry) 
I had a chance to glance at your example. The pattern is the same in many areas. The OData wrappers take some assumptions based upon the BO services that are ‘full’ BOs with the classic core methods. The OData method you mentioned maps to GetByID on cor emethods as indicated in the swagger page:
When you look at GetByID, it has the following API surface:
public JobOperSearchTableset GetByID(string jobNum, int assemblySeq, int oprSeq)
And all GetByID core methods have a similar pattern:
parameters.Add(“Company”, CallContext.Session.CompanyID);
parameters.Add(“JobNum”, jobNum);
parameters.Add(“AssemblySeq”, assemblySeq);
parameters.Add(“OprSeq”, oprSeq);
InnerGetByID(Db, 0, 0, out morePages, CurrentFullTableset, parameters);
So this is the oddity in ease of use that you stumble into when you look at the keys to the table versus the method signature:
Company handling is an interesting ease of use question we are investigating. Some methods take company, some don’t so the underlying methods being inconsistent caused the OData Wrapper to rely upon the key of the tables. There are some options and investigations on what’s the best approach.
#StayTuned
FWIW @Chris_Conn we are actively changing the apis for an upcoming version in a way that should make the context information passing much less murky. Company will just be a part of the route generally /company/apithing. Other context items will be settable without the header in querystring ?workstation=something
Awesome @bconner can you pretty please with a cherry on top leave V1 as is and keep it available?
Lotta code laying around !
