Skip to main content
Solved

Automated Schedule of custom processing screen processes 0 rows


Forum|alt.badge.img
  • Jr Varsity III
  • 15 replies

Build 23.212.0024

We have a custom processing screen which makes use of a delegate to perform a union of various records into a single processing list; as described here https://asiablog.acumatica.com/2015/11/union-selects-in-bql.html . This processing screen is used to poll remote API for status updates.

I mention the delegate method of performing a union as we originally thought that might be the reason for our issues, however we now don’t believe that’s the case.

This processing screen works fine when used manually; any success, warning or errors are correctly reported to the UI.

We can using a schedule to automate this processing screen on local development machines and the number of processed rows is correctly reported in the history (greater than 0). Since the automation works locally I presume the configuration of our processing screen is correct. We have read a number of discussions on this matter but none seem to show similar behaviours. We are using the “Process All” action. We also have a NoteID field configured on the DAC which maps to the NoteID of each of the source rows.

In the production environment 0 rows are processed when we can run the same screen manually and process more than 0 rows.

It’s almost like on production, when the screen is being executed by the schedule it is happening under a different tenant that has zero rows to process.

Since the automation works locally, can anyone suggest any way to debug the potential issues in production environment?

Many thanks.

 

Best answer by neil40

Yes a solution was found after going on a bit if a wild goose chase. Doing some SQL profiling helped to highlight the fact that the queries being produced by the system were different when run by our test user and the scheduler in terms of the where clause criteria surrounding branchID's.

The key piece of information that we were missing was that the scheduler runs as the user 'admin'.

Simply ensuring that the user 'admin' had access to the relevant branches solved the issue for us.

A simple solution in this case but an annoyingly large amount of time spent diagnosing!

 

 

View original
Did this topic help you find an answer to your question?

6 replies

Forum|alt.badge.img
  • 69 replies
  • July 24, 2024

@neil40 , have you checked the Conditions and Filter Values for the Automation Schedule? 


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 15 replies
  • July 25, 2024

Thanks for the reply.

I checked the the Automation Schedule and there are no Conditions against it. 

The strange thing is the Automation works for another tenant on the same system (just not the tenant we want!). As if something is misaligned behind the scenes. No differences in the schedule.


Chris Hackett
Community Manager
Forum|alt.badge.img
  • Acumatica Community Manager
  • 2658 replies
  • August 22, 2024

Hi @neil40 were you able to find a solution? Thank you!


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 15 replies
  • Answer
  • August 22, 2024

Yes a solution was found after going on a bit if a wild goose chase. Doing some SQL profiling helped to highlight the fact that the queries being produced by the system were different when run by our test user and the scheduler in terms of the where clause criteria surrounding branchID's.

The key piece of information that we were missing was that the scheduler runs as the user 'admin'.

Simply ensuring that the user 'admin' had access to the relevant branches solved the issue for us.

A simple solution in this case but an annoyingly large amount of time spent diagnosing!

 

 


Chris Hackett
Community Manager
Forum|alt.badge.img
  • Acumatica Community Manager
  • 2658 replies
  • August 22, 2024

Thank you for sharing your solution with the community @neil40!


Forum|alt.badge.img
  • Jr Varsity II
  • 31 replies
  • December 26, 2024
neil40 wrote:

Yes a solution was found after going on a bit if a wild goose chase. Doing some SQL profiling helped to highlight the fact that the queries being produced by the system were different when run by our test user and the scheduler in terms of the where clause criteria surrounding branchID's.

The key piece of information that we were missing was that the scheduler runs as the user 'admin'.

Simply ensuring that the user 'admin' had access to the relevant branches solved the issue for us.

A simple solution in this case but an annoyingly large amount of time spent diagnosing!

 

 

Oddly enough - I’m experiencing the exact same issue on the exact same build you mentioned.

 

We have a basic automated schedule that just references a GI screen. The GI simply pulls data over x time period and presents it. I was able to get this to run for one day fine but once I changed it to scheduler, it will no longer recognize any records, therefore won’t initiate the business event it’s tied to.

The conditions and filters are empty. If I press VIEW SCREEN from the automated scheduler, I can see results.

I did confirm the admin user roles are included in the GI and that admin user can access all branches.

The only way I can get this to run is creating a new business event + new scheduler. It seems to work for whatever time period but then won’t process records next time I change it to a schedule.

I haven’t tried replicating all this to a test tenant.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings