So I have a BPM to set a UD field on part creation. Now I have another UD field that I’ve added that will need to be set as well, but with different logic. Is it best to have 2 separate BPM’s or is it better to run all of the paths back to the next condition and do it all in one BPM? I imagine both will work, but I didn’t know if there was better way from those two options.
In my opinion it’s less maintenance to have the code in one BPM provided you check for the appropriate error condition
Forgive my ignorance, but what does that mean? Is that just for custom code? For this example, I am simply creating some conditions and setting fields, so no custom code. Do I still need to check for error conditions?
You can have a general condition for the BPM to call the method and then an internal C# code with more condition(s) to execute the appropriate UD field code.
ok, makes sense. I don’t think I need that for this case. The basic conditions from the menu handle what I need. The conditions aren’t complicated, just different.
If you’re simply setting two values during part creation, there is probably a slight performance hit if you do two separate BPMs. That said, you also might WANT to have separate BPMs if you’re using Groups to keep things straight (one may belong to a Production group, and for future update/planning it’s grouped with a bunch of other Production things, the other may belong to a Quality or Finance group).
I’m not a programmer, but it would seem logical that calling two BPMs would involve more overhead than calling only a single one, but it probably isn’t significant.
There is a popular conversation amongst developers that you may or may not of heard of - premature optimization. Jumping through hoops on a design to optimize the heck out of something that ends up not being performance critical. Usually at the cost of adding complexity or making things harder to maintain.
This can manifest it numerous way - one of the ones I fight internally a ton is to write all the code in a single method or class instead of little byte sized pieces of logic that are easier to unit test.
I think you are falling into the same kind of issue.
Ask yourself what is easier to maintain - to version, to understand the logic, to deploy, etc. (Honestly don’t know because it’s your business and you’ll know better than any of us).
So once you can manage these modification easiest, is it causing pain that needs to change your process for performance or a bug or for some reason?
Then take on the increase in dev complexity for a good business reason.
my 2 cents…
3 Likes
In the C# code, you can use Case or if then else. You can then use the message command to echo a message just in case the code does not anticipate for all conditions. In this way you would trap and capture where in the code the issue is (UD 1 or UD 2).
I agree with Bart you have to balance simplicity and complexity against maintenance.
I tend to keep my solutions separate, so I have a deployable solution for splitting batches into uniform lots upon receipt and one for checking the expiry date. Even though they use BPMs on the same methods and some of the same tables, I keep them separate so that they can be clearly split into two solutions.
I know that many will probably not have such clear separation (I hear that some/many/most will only ever use a single solution for all customizations), but it just makes it easier for me to track what methods, UD fields, reports, etc are for each gap I am developing a solution for.
So it sounds like it’s mostly personal preference with an mostly insignificant performance consideration. Basically whatever helps us manage them easiest is probably the best solution. Thanks for the input guys.