Continuing the discussion from How to properly throw an Exception in BPM:
In the previous portion of this discussion, I was trying to figure out why I keep getting 2 Exceptions thrown when I use the “Raise Exception” block, or if I use:
throw new Ice.BLException();
in a Custom Code block.
I have tried everything in my power to eliminate one (or both) of the exceptions, while still having the end-goal met, which I have not been able to successfully do. So, I decided to take a step back and see if there is another way that I can go about this.
OBJECTIVE:
On the Issue Material screen, I need to catch when a user enters a LotNumber and run some logic against the entered/selected value.
I would think that a Method Directive BPM for this would be the proper plan of attack, so I started a trace and saw that OnChangeLotNum method was being called from Erp.Proxy.BO.IssueReturnImpl when a new LotNum was entered/selected. Using that knowledge, I created a Pre-Processing BPM on Erp.IssueReturn.OnChangeLotNum.
That BPM has a few blocks:
- Start
- Condition Check to ensure RowMod is “U”
- Custom Code block
The custom code block has some code in it that does the following:
- Creates a handful of variables and stores relevant data in them
a. prevHeatNum ← Holds the previous HeatNum for the last material that was issued (this is obtained via a query to the PartTran and PartLot tables)
b. currLotNum ← Holds the LotNum for the current transaction
c. currJobNum ← Holds the JobNum for the current transaction
d. currPartNum ← Holds the PartNum for the current transaction
e. currHeatHum ← Holds the HeatNum of currLotNum (this is obtained via a query to the PartLot table)
f. currJobCode ← Holds the JobCode for this transaction - Using the data collected, a few conditional checks are made:
a. Check to see if currJobCode contains a specific string which indicates we need to check HeatNum’s. If that string does not exist, bail out of the BPM without any further actions.
•••• This part works as expected.
b. Check to see if there has been any previous materials issued to this job. If this is the first material transaction, bail out of the BPM without any further actions.
•••• This part works as expected. - If we are at this point, we know that we have a transaction taking place where we need to compare currHeatNum to prevHeatNum.
if ((currHeatNum != null) && (prevHeatNum != null))
{
/* currHeatNum and prevHeatNum both hold values */
if (currHeatNum != prevHeatNum)
{
/* prevheatNum and currHeatNum are NOT a match.
Hard stop this transaction and clear the
HeatNum field on the form */
throw new Ice.BLException("some error text here");
}
}
All of that works absolutely flawlessly. WIth one exclusion, which can be found in my original post, here. Long story short, 2 different exceptions are being thrown, and that is not desired.
So, my question is: is there a better way to basically ‘revert’ everything that happened in OnChangeLotNum? I tried setting the pcLotNum to null and “” with no avail, that causes a box to appear saying that a Valid Lot Number is required.
I have also tried to set any relevant fields in ttIssueReturn back to their previous values, and nothing seems to do the trick. I have tried doing the logic strictly using conditional blocks in the BPM Workflow Designer, and my results are the same as when I did it all in the Custom Code block.
Any advise as to how I can ease this headache and get that LotNum field back to a blank state?