Hi there!
I have a custom dashboard with three UBAQs inside. Each UBAQ has its own BPM custom action. Each BAQ is grouped in the dashboard views based on part number. I just noticed that when I run my custom actions, the work only happens on a single part number group, even if multiple part numbers are flagged to be updated. It seems as though ttResults contains only the results from the group, not from the entire BAQ. Is that possible? Is there something else going on here?
In the image you can see a portion of my dashboard. I selected the checkboxes on the right to signify that some records need updates. However, when I ran my custom action, only the updates in the last part group were processed. (Thatās why there are no check boxes checked in the last part, the BPM unchecks them as they are processed.) Any ideas where I can look to figure this out? Is this a feature? If so, how can I have my custom actions step through all the records in the BAQ, not just the records in the active grouping?
For what itās worth, I access my BAQ results through my custom action starting with some code like this:
foreach (var row in (from ttResults_Row in ttResults where ttResults_Row.Calculated_UpdateRelease == true select ttResults_Row))
{ // yadda yadda...
By default the Epicor UI supports only a single dirty row and the UBAQ Dashboard is no exception. That said, you can specify that you want to support multiple dirty rows in the UBAQ DBD. That is set on the UBAQ - Update -> General Properties -> Allow Multiple Row Update. If that is not set, Save is automatically invoked on each dirty row on a Row Change or View Change and the row is then no longer dirty.
The Custom Action invoked from the Actions Menu of the DBD will send the Original Row and the Modified Row for each dirty row in the DBD Results table so you should be able to do what you are attempting.
After changing the Allow Multiple Row Update, you will have to at least regenerate the DBD and you may need to drop the UBAQ and then add back.
My UBAQs and DBD are both setup for multiple dirty rows. They were already set that way from the beginning. But I think you are on to something there. When I click a checkbox in one BAQ, then click a box in the second BAQ, sometimes it seems like the first BAQ row is āsavedā, thus changing the row to not be marked as dirty. I am testing a few variations to figure out how to get the dirty row definition to stay until the custom action has been run. For my purposes, the row should be considered dirty, until the custom action unchecks the checkbox that I checked to indicate the record should be processed.
Iāll keep playing around and post back when I have something.
Thanks!
Nate
In my experience, running an action doesnt affect just dirty rows, it gives you access to the entire resultset. You should be able to play with just dirty rows though:
ttResults.Where(r =>r.Updated())
Normally the action does run on the entire ttResults. But when I click boxes in one BAQ, then click boxes in another BAQ, sometimes the records in the first BAQ are āsaved?ā The checkboxes that I ticked stay ticked, and I can tick new checkboxes. But when I list out the rows in ttResults, only the (unsaved?) records with new checkboxes I checked are listed.
Here I am referring to āsavedā and āunsavedā because I am not sure of the correct terminology. It looks like when a BAQ loses focus, the Update() method runs. This doesnāt actually update anything (as the updates are all done in the custom action), but I think it is saving, and flagging my rows as (not dirty?)
Does this make sense to anyone? I am quite confused.
That makes sense. I know that if you do NOT have multiple dirty rows option, simply changing rows has this same effect so I am not surprised. Perhaps you can make your own field to denote dirty or perhaps you can catch those rows in PreProcessing and store them in CallContext to use later. The first piece of complexity I cant think of is what is the logic\event that will clear your dirty denoted fields.
I kind of am using my own custom dirty field flags. In fact I have two checkbox flags in each row. They are calculated fields that the user can click to denote that some action must be taken. My BAQs all begin processing based on the presence of these flags. As you can see in my first post, all actions take place within the foreach loop. That loop works great as long as I donāt move my focus out of one BAQ and into another (this triggering the Update() method).
I also placed a debugging message box in my BAQ. So as soon as it runs, it shows me a table query of the full ttResults. If I stick with just one part update at a time, the ttResults are correct. But, if I switch back and forth, checking boxes in both BAQs, then ttResults only displays the last part that I check boxes for. Not all the previous parts that I also checked boxes for. They should still be in ttResults.
If this bug occurs, then I also noticed that the rowmods for ttResults are set to U, but only if I switch between BAQs. Otherwise rowmod remains null.
It seems like the issue is with the update method that fires automatically when i switch between BAQ views within the dashboard. If I could stop that update method from firing, it may solve this issue. This goes back to a previously solved case:
The solution for this ended up being that I needed to add a custom Update method in the BPM. In my case it is an empty BPM with just an empty code block and a message box showing the contents of ttResults.
I donāt think this solution caused my issue, but I do think that there must be something else I can do.
Ah, youāre correct, there is no adapter.Okay, change direction. If you are ok with having to manually save, maybe you can do AfterField change and remove the RowMod (you said you denote dirty rows in your own way). Then BeforeTool click on save,use your logic to set the RowMod back to āUā. Just note that your AfterField change would need to recognize when to ignore clearing RowMod on your save click.
The great part about this is that I donāt need to save at all. The custom actions perform all the updates and saving. So if I could just stop the save action altogether it may work. I like the idea of removing the rowmod. Iāll have a look and see if i can get that working.
Thanks for your help!
Nate
