Biggest thing is what I never wanted to admit was true, but I always knew it. From that first post I linked to:
But with the tracer, it’s survivable. Just know that you need to fill in the parameters AND possibly do some field setting. But not always - a lot of the diffs are done by the methods without you telling it, like job part number. But then some need your help, like labor hours.
@JasonMcD if I have a TableSet and I want to get one of its values after it runs through a business logic call, do you know how to do that?
i.e. I created a variable InvTranDataSet as type InvTransferTableSet.
I have been passing this along through the different business object methods (that I saw in a trace) as the dataset param and I am trying to verify that the dataset is indeed changing after every call as I see in the trace.
How would I extract a value from the table set? I keep trying to get a row from it, but it says:
EDIT I was able to assign it to a variable and then use LINQ to get it from there…
I’ve just finished making a customization that updates all labor details associated with an operation when one labor detail is updated so that split burden is correct when a labor record is corrected through time management so I know how much of a pain these labour details are.
I think mine would have been impossible with no code though, so respect!
I mean, I am sure you tried this with the expression editor in the Set Variable widget. I used that to return the LaborDtlSeq (just for curiosity) and it worked fine. You know, for my situation yesterday it worked. Today I’ll try something else and it probably won’t work…
I gather the issue is, what if you have multiple rows in the dataset? Just a guess.
Also, here is where it gets muddy (muddier) for me. The post I used as a guide had this block of code:
But I used: MyDataset.LaborDtl.RowMod= "U";
I tried Brandon’s code and got an error in the designer.
So I used a format more like Jose’s Trace Parser showed (there’s no “LaborData” portion):
I finished a BPM on ABCCode.Update Post processing that transfers 10 units of inventory from one warehouse bin to another. I hardcoded everything that would normally be put in by a user (dynamic data) such as part number, warehouse, lot, etc… I am still learning how it all fits together. I also don’t think I am doing the row mod update correctly, do I really need to add it before each call?
What I wanted to ask you @JasonMcD is what you do with some of the business logic calls where the methods don’t make changes to the dataset, but rather they return a message (which usually would result in an exception being thrown)? When you trace something there will be methods called that just return a message, or they are doing some type of check… If those were ran natively in the application some sort of warning message or even exception pops up. Did you have any of those calls when you traced the labor method? What did you do with those, did you handle them like the application does?
This is where some experience comes into play about knowing what you can and can’t skip. A lot of the checks are going to be checks to make sure someone didn’t fat finger something. But if your data is coming from a database lookup, there isn’t anyway for the data to get typed in wrong. So some of those things you can skip. But you have to think about why the check is happening to know if you can skip it or not. There aren’t really any hard and fast rules on that unfortunately.
Thanks Brandon. I have heard this from many people. Is there any way to help aid in the process of “thinking about why the check is happening” other than assuming or taking a guess at it? Could you decompile with ILSpy to get a better look? Maybe it is just best guess.
And say you skip over those methods Brandon, could something still pop up in a later method call as a result of skipping over the data validation calls?
@JasonMcD did you end up using any of the calls that were checking data?
But that’s what I deduced, too, is all of these BOReader calls seem to be for generating a dropdown and that sort of thing. Like you said, if you are preventing that in your own UI, then it should be clean.
Possibly. Remember, all of this code is written by people, so it’s not perfect, and not all possibilities are taken into account all of time, and it’s not 100% consistent from one method to another. In theory, the Update method should prevent you from shooting yourself in the foot. But it doesn’t always work out.
And yes, decompiling and testing with things like the BL tester are all things that can help you understand what’s going on. It’s not too often then you will get through all of the testing and have nothing blow up and create time bombs for later.
The other thing I see in all of this - and this should be no surprise - is that a trace is only as good as the scenario you trace.
So, like Tuesday, I traced a labor entry with quantity, then Wednesday I tried it with an operation that prevents quantity, and it failed, because, why was I calling a DefaultQty method with a zero quantity?
So I guess my point - again, an obvious one - is that the trace doesn’t explain the logic tree. It’s just a record of the path you went down that day.