This appears to be the answer.
Postman using the RPC GetByID method and only the orderNum for a parameter returns SalesOrder, all OrderDtls, all OrderRels, and oodles of other information that I may or may not need. It took 1800 ms - not lightning fast but better than the 3500 I was getting with parallel async HTTP calls.
Thanks for the info to @klincecum, @TomAlexander, and @Mark_Wonsil. I’m sure I will be back with more questions but for now I have a tankerload of C# refactoring to do.
While I don’t recommend direct access SQL, my personal preference would have been to use GraphQL but RPC is not terrible ether. In order to solve your immediate challenge, you could use something like this below.
/api/v2/odata/WW/Erp.BO.SalesOrderSvc/SalesOrders(‘Company’,123800)?$expand=OrderDtls&$select=OrderNum
Refer to @jbooker 's nested expand
I was wondering if this was possible. Thanks for the hint - this will also help tremendously.
I did initially go this route. The performance for a moderately sized order was not acceptable - something on the order of 6000-7000ms for just the SalesOrder expanded to OrderDtls, and I still needed to get the Releases, Jobs, and POs. I will of course retry that through Postman now.
let us know the benchmarks on the slimmed down version. I suspect your long wait times were data-over-wire rather than server-side processing related to $expand. Epicor is a bandwidth hog.
Urm. On prem devs/users learning to work with cloud-based applications might have a little to do with that.
“I want to download the whole part master so I can filter in place.”
“I’ll use select * from < twelve linked tables with ten outer joins >”
This is amazing. I’m now down to 1659ms for that same order. Thanks again for the hint.
We got so into the weeds I forgot to ask.
What all are you doing this for?
Live look at my desk
Are you sure that’s not my desk?
I’m curious how fast @klincecum can get it down to…
including Epicor devs too. I mean look at the ds on every screen. No wonder they’re eliminating landing pages, egress-fees-straight-to-profit.
I’m the baboon…you’re the chimp, much higher on the evolutionary scale than me
We’re getting close…
We could use the Db context to bypass the bo and territory checks etc, but don’t know what the gain would be.
Rewriting a legacy VB.NET system that uses the adapter DLLs. I’m modernizing the architecture to DDD. These queries are the reads for a SalesOrder domain API.
I already have it pulling OrderHed, OrderDtl, OrderRel, JobProd, JobHead, JobMtl, and JobOper. It takes about ~8-ish seconds to pull all that. 1659ms will be a superb increase in performance from 8000ms.
btw, today I’m taking a day off from hog implementation to deal with repercussions of ISP change necessitated by implementing hog. 
No cigar so it’s not you.