Status Bar in BAQ/BPM

Epicor ERP 10
,
1

Hi All!
I know I can update the status bar text from a customization. Is there any way to do it from a BPM?
Thanks!
Nate

2

I doubt it.

3

Depends on how you want it to work. I mean you could send data back from a bpm in call context grab that set the status bar text. Probably hook it on after adapter methods?

4

I am looking to give the user some kind of feedback during a long custom action. The action runs ok, but the program looks frozen during the process. Is there a good way to let the user know we are still working? Is there any other kind of status screen I can display while my custom action does its magic? It would be great to show a custom form with a progress bar, but that might be asking a bit much.

What do you all think?

5

Anything you do server side wonā€™t update the client (even the toolbar) until it is done.
You could display a fake progress bar just to show the user it is ā€œworkingā€ however that would require you to invoke your BPM on a Thread which isnā€™t trivial.

6

Hereā€™s a thought, I cant say itā€™s a good oneā€¦

If you were to write to some other Db field (maybe a UD etc) of the progress within the BPM, you could potentially use threading as Jose suggests and use that to drive a progress bar.

The caveat here is that youā€™d probably need to create the aforementioned field change in a seperate transaction or at least use a targeted Db.Valdate(tablename) to seperate the commits from the normal BPM work.

7

Whew! That all sounds terribly complicated. :stuck_out_tongue:

I am using the status bar through a customization now to at least let the user know that something is happening.

Maybe a lower tech approach is best here.
Is there a way to estimate how long an operation will take? Then I could tell the user how long to expect to wait.

8

Short answer, no, longer answer maybe but it is also (terribly complicated)
Perhaps the better question is why is this taking so long? What are you doing?

9

show a static message box showing the operation could take up to x minutes before it is executed.

10

This is part of my updatable query to change resource group ids for part master methods. The custom action does a lot of thinking, but essentially it gets a list of parts that contain a resource group id that you want to change to another RGID. Then it moves those part/revs into a ECO group so that I can make the updates. I checkout the part, unapprove the rev, change the RGID (and a few descriptions), then reapprove and check the part back in.

All this happens relatively quickly given the number of steps. If I run it on a handful of part/revs the process is only a few seconds. But when I run it on the big list (about 600 part/revs in my case), the action takes many minutes, and sometimes seems to be completely frozen. In these cases I close the application, and see a ā€˜server not respondingā€™ error. As long as I let the action go long enough the records all seem to be updated correctly, even with the server error.

I had thought that I could trace my custom action, then add up the roundtrip times for all the resulting methods, then multiply that by the number of records to get a total estimated time. However this approach doesnā€™t really know how long the action will take. I assume if the server is under load then these roundtrip times can inflate quite a bit. There are other complicating factors that may throw off such a time estimate, like multiple operations to update in a single part/rev.

Anyway, there it isā€¦ Iā€™ll patiently wait for you to tell me to use the DMT. :stuck_out_tongue_closed_eyes:

1 Like
11

Iā€™ve used BackgroundWorker class client side for long running operations and I like it. Obviously this would require your process to be client side, but it frees up the UI thread to be able to report progress. BackgroundWorker Class (System.ComponentModel) | Microsoft Learn

2 Likes
12

Yes, That is my current solution. Just curious if I could get a more time accurate estimate for the user.

I used the tracing to determine that 4 records took about 6000 ms to process. So I estimated that it takes 1.5 seconds to update each record. Here is my little time estimate formula:

minutes = (edv1.dataView.Count * 0.025)
13

Could this be ran async so the user does not have to sit waiting?

14

Interesting idea! I am not sure what async will do to my BPM. I will test it out and see what happens.

15

Neat! I like the look of this. I will have to do some research to figure out how to implement it. But if it does work it looks like a handy tool to have in my bag of tricks!

1 Like
16

Well I had a look at my BPM, and I am not entirely sure how to implement async. I see that async is an option for my custom code blocks, but not for any other widgets. I donā€™t think my custom code blocks are sucking up the processing time, I think it is the canned methods. I think that means I would have to move all my widgets into custom code blocks (or a single code block). That may just be more effort than it is worth.

For what itā€™s worth, here is the BAQ in question. This assumes you have three things in place:

  1. An ECO group ā€œMUā€ for mass updates.
  2. Part(s) with the original resource group id you want to change.
  3. A valid resource group to change them to.

In my case I setup two testing resource groups and switch my parts between them.

Just look at that BPM! Whew! ChangePartResourceGroupID.baq (260.3 KB)