Summary:
We just jumped from 2021.2.10 to 2023.1.9 and we spent a lot of time on test break fix process. Still we missed quite a few things because we didn’t know exactly which business objects or endpoints changed (signature or behavior)
We (the royal we) use a lot of BAQs, Functions, BPMs etc which make use of the existing SOA Architecture to invoke existing methods, as these methods change (both in signature and behavior) it would be incredibly useful to know that it happens and what the change was (again signature and behavior) so that when we upgrade we can more easily discern why our BPM or Function might be behaving strangely.
Signature changes are easier to find cause they will generally cause a compile or syntax error. However behavior changes in a public method are much more difficult to find and sometimes requires a few days of running Live before these read their ugly heads.
For example in 2023 PCID for WIP was introduced, we use PCID heavily but not on WIP. The Report Qty BO used to return “EnablePCID” response only on final operations and we relied on this to determine whether or not to spit out a PCID label. Well this change in 2023 means that EnablePCID is almost always TRUE for all ReportQty functions as long as you use PCID in the plant. This means that our intermediate operations started spitting out PCID labels randomly and nobody knew why or how to stop it. We eventually found and corrected the offending BPM to check itself for “Last Operation” before a label was generated but since there wasn’t a signature change on the method nobody noticed until 3 days into go live process and we have a handful of PCIDS now sitting in WIP that we’ll have to find a way to extricate.
For some reason I assumed you and the other greats like the one typing right now (@jgiese.wci )had some way of knowing this using tools y’all developed.
Thanks for sharing, I will take this back to the team and do some discovery! In the mean time if anyone else thinks this idea would be helpful, please be sure to vote in Epicor Ideas!
Sorry that happened to you Jose, that’s a tough one and I think we’ve all been bitten by that. I think it’s hard for Epicor to know what to detail in BO changes and what not to detail in BO changes because after all, how many people are doing what you’re doing ?
Without a compare on the actual source that wouldn’t be possible. Best you could do is compare signatures but like @josecgomez said in this case the logic was changed but the signature stayed the same. A list of modified BOs/Methods would be great because you could compare that to your BPMs and such.
Problem lies in how do you handle a jump over 2022 and minors and patches? Epicor would have to include a starting and ending version number and list all changes to BOs/Methods between those versions. Would have to be a tool of some sort not just documentation or it would only be so/so helpful.
Normally, I would beat the DevOps drum, but this is different since we are not the ones changing the code. The only thing I can see is using Integration Tests. This would test behavior and blow up on bad signatures as well. The question is: how would one organize a test suite like this?
Before you click the reaction, you already are doing these integration tests. Just in production…
I don’t think that’s a good reason at all. The scale here might be unusual, but many, many users have some customizations and it’s still nice to know ahead of time what is absolutely going to break.
I think it’s difficult for any developer. I voted for this. However, even if Epicor captures each and every change in the documentation, we are now relying on each of us to ingest it and determine whether or not it affects our business. This is why I still lean toward testing, even with improved documentation.
Just include them with the release notes like they show the PRB problems. Every time a method changes notate it and release it with the release make it “my job” to look through those release notes to see what changed.
Testing framework would be great, or even a testing harness but without a lot of external tooling and a few prayers it seems impossible or nearly impossible in Epicor.
The amount of Setup required to test out something as simple as a Job Report Qty BO is nay insurmountable in any automated fashion.
You’d need demand, and a job, and that job has to meet specific criteria and be in the “right” plant with PCID enable and have more than 1 operation there’s so so so so much Domain Knowledge and Pre-Setup required I don’t know how we could ever do that with Epicor. At least not until they introduce some better DevOps tools and compatibility.
Exactly I don’t even need to know what changed exactly, just know that the method was changed so that then I can go test anything that I use which uses that method. This could even be automated on their side, post git merge hook, for every method that changed add it to a read me as Modified
reaction, you already are doing these integration tests. Just in production… 
it was a logic change so wouldn’t matter 
