I’ve got a BPM working well that creates a Sales Case entry and sets a number of values. By default a case gets a task set attached to it and the Assigned To field defaults to the value in the Task Set setup. We would like to change the assigned to field to be the case owner. Seems simple enough.
I ran a full trace on case creation and Task Assignment changes an have identified all the changed values.
When I run the BL Tester using Task.GetByID(“Hdcase”,casenum,10,TaskDataSet) i get the right task sequence row in the dataset. I then modify the dataset row, changing the SalesRepCode, SalesRepName and AllowUpdate fields (as shown in the client trace). When I run the Task.Update(TaskDataSet) method, the Task get a new person attached to it AND changes the Assigned To field.
When I do exactly the same thing in the BPM using the Execute BO Method and SetField widgets, nothing gets updated. The flow is the same - Task.GetByID, SetField, SetField, SetField, Task.Update - and no error is produced. If I pop up a message(widget), i can see all the fields are being set correctly.
I have tried everything I can think of and have sunk about 10 hours into this over the last week and a half. TIme to ask the group for help.
Yep, totally forgot that… been a hell of a day. I can’t post the BL Tester code of course, but here is the relevant BPM exports. Overall, the case creation and the subsequent Task Assignment BPMs are tied to the Quote.Update method BPM that starts this ball rolling. CaseCreator.bpm (151.5 KB)
3)These are the three value ‘setters’ for Sales Rep Code/Name and Allow update. The Name/Code come from the ttQuoteSR table that is in the current dataset open because ALL of this happens as part of Quote.Update.
Have you verified that you have values being stored in your local variables?
I ask because I see that you’re performing this process post-process on the Update method of your quote and gathering your values from the temp table rows.
I believe (unless I’m mistaken), that these temp table rows are cleared by the post processing phase of the BPM. What you might consider doing is verifying the data is actually existent in the post processing.
If it’s not, gather the values needed in the pre-processing using either callContextBPMData fields or define local variables and set them in pre-processing and then pass those values to post-processing.
Aaron,
The one widget I didn’t expound upon is a messagebox that shows the values collected in the previous BPM as well as the task dataset just before the update. It shows that all the values are there, and that the dataset is showing the same values (changed accordingly) that the BL tester has when issuing the update. The ttQSalesRP temp table isn’t cleared in the post-proc stage btw… I thought the same thing at first. I think it works that way for some things, but not here.
Ok I’m taking a closer look now. It’s good to eliminate the easy ones first!
One thing I didn’t see was a row mod field being set anywhere. Can you try setting the RowMod field of your UpdTaskDS to “U”?
Yes I’ve tried RowMod as U and M, but honestly, the BL tested method doesn’t require the RowMod to be set at all and it works. That’s how I found the AllowUpdate field…
Shoot, well I’m not entirely sure then. I do know that the Invoke BO method widget is notoriously frustrating to use, but it appears to me that you’re doing everything correctly i.e. filling the dataset with a getbyID method, modifying the appropriate fields (including rowmod as you stated) and then invoking the method.
The only other thing I’ve seen on here is filling the dataset using the “fill table by query” widget as it might be mapping the fields more appropriately.
I tend to do most things with code rather than widgets, so perhaps someone who’s more widget savvy might be able to guide you on this one. Sorry I’m not being more helpful!
No worries… I usually don’t post anything until I good and bloody from beating my head on the wall. I really try to do all of the obvious/documented stuff before asking for more help. thanks for the double-check on things anyway… The link is familiar, saw that a little while ago and have that BPM in my DEV install as an example…
I’ve been trying to stick with Tim Shoemaker’s mantra of “use only widgets” but I may just have to revert to code. Code has problems if I go to the cloud, widgets do not, or so I understand.
I concur that you will for sure need to set RowMod = “U”. Perhaps you can slap a quick Method BPM on Task.Update that just shows you are actually hitting it and what a couple of the key values are that are being passed.
Hmm, that’s not a bad idea Chris - adding a BPm to task update with a messagebox.
As for the RowMod - the BL Tester doesn’t require it, and I’ve tried R,M and blank in the update method with no change in function. That’s how I found AllowUpdate - it’s the field I needed to change to get the BL tester to work… It’s confusing for sure, because RowMod is the determining field for everything else…
@MikeGross
Not sure in E10, but in E9 if the user operating on the case is not an authorized user of the workforce (i.e. the case owner) you will never be able to assign it, so whatever the user context the BPM is being run as might be the issue.
Same goes for changing the owner of Call Logs.
Not sure if that’s your issue, but thought I’d mention it.
I think I recall having issues with rowmods values in service connect workflows for case management, some of the methods behaved unusually, same goes for time and expense entry.
Appreciate the input. Our territories/salesreps and authorized user setup is a bit convoluted and we thought it might be that as well. It ended up being what @Chris_Conn said. When doing the Invoke BO method, the dataset doesn’t have the row mod set automatically, so you have to do it manually in the ‘mapping’ of values. At least that is what I can remember from back then.
