Skip to main content
Solved

Automated Schedule of custom processing screen processes 0 rows

  • 22 July 2024
  • 5 replies
  • 73 views

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.

 

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

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.

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

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!

 

 

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

Reply


Terms & ConditionsCookie settings