Click a Process button and Turn off your PC

Hello all! I made a post last November that @hmwillett was able to answer:

I return to beat a dead horse :racehorse: :toothbrush: … or a running horse with a toothbrush.

I am working with a solution that creates hundreds of jobs in one go. The user loads a grid, manually inputs data, then they click a process button. The solution then creates jobs using the data the user manually entered. Problem is, this solution is client side (classic). It takes forever to process, and the user cannot close their PC until it has finished. Very headache inducing.

The solution by Hannah in my previous post to have it run server side was provided under the fact that we didn’t have Functions Maint. Now that we do, I wanted to come back to this.

Users want to click the button and close their computer. They don’t want to keep it on. So I have to get this solution on the server side. If I recreated everything in Kinetic and called a function, I assume the user would still have to sit there and wait for the function to process, correct? That assumption lead me to believe a possible solution would be to save the user inputs to a UDTable (I need those user input values) when they click the process button. Then, schedule a function that does everything the client solution does using the saved values from the UDTable. I like this route because I can schedule it to run when nothing else is going on.

Does anyone know of a better way? I want to be sure there isn’t a solution out there with less overhead. Perhaps I don’t even need the UDTable? Maybe there’s a way they can click the process button and the function just takes over, allowing them to shut off their PC? I don’t think so though, because the user inputs would be lost as they’re not saved anywhere before the jobs are created

Thank you for reading, and thank you for any of your thoughts.

Perhaps you want to submit the scheduled function to the task agent with the click of a button… Sort of like how you can run a report using the now schedule.

  • Button click instantiates the scheduled function
  • Then submits it to the task agent using submit to agent.

Not sure how you would go about that from a kinetic form, but there is no reason you couldn’t have a function that did all that for you… You call that function rather that the one you are scheduling now.

3 Likes

How are they being input? Via a file? I won’t know what tools you have at your disposal, but I would do something like this:
Use the file picker widget to allow the user to upload the file to the server. Have a Workato automation that runs when a file is dropped to a certain location (where the file gets uploaded). Then have Workato call a function to process the jobs from the file. Easy peasy, no users displeasied.:sweat_smile:

3 Likes

A similar idea that would also let them walk away - have them DMT the file to a UD table, then schedule the function to run and process everything in that UD table at a specific time.

2 Likes

At first glance, Simon’s idea is most appealing.

That however depends on some details on what and how you have them entering this information.

If it’s all on a grid screen, you just have them enter it all, and call a function with that data, that schedules another function and returns immediately.

Processing will occur in the background and the input data will be stored in systaskparams for a while. No need for a table, unless you want longer term storage.

The other two ideas here also have merit. It really depends on preference.

1 Like

All good ideas - but I’m thinking a combination of @aosemwengie1 and @hmwillett ideas would be the best. Sticking within the framework, a copy/paste or a DMT (could be processed by a file watcher service on the server) to get the data into a UD table and Workato could be watching and processing that UD table into Jobs. Low code solution that totally offloads the work to either your server or shares the load with Workato.

3 Likes

Just rereading your initial problem. Keeping stuff in the framework , I agree with 100%.

  • Using DMT… brings in a whole load of other problems, that’s my personal opinion.

  • Workato That’s great if you already have it.

I’d be more inclined to use a UD table to capture any errors. But of course your data entry screen will have lots of data validation to prevent that when the jobs are created… You already have the function it seems so the submit to agent is the last piece of the puzzle, no reinventing the wheel.

2 Likes

Thank you everyone for your input. This community is so great! Good stuff to chew on with like-minded brains :smile: I like all of these ideas, but @Hally’s is intriguing as I wouldn’t have to save the input values anywhere. Truly, after the process runs, those UDTable values will be meaningless. I don’t want to store them if I don’t have to.

To answer @hmwillett’s question, the interface is a grid fed by a BAQ. The user-entered fields are just added/dummy columns. When the button is clicked, the screen cycles through the grid’s rows getting the input values from those columns. Of course, I could take those values and toss them into a file for processing.

So far, it looks like if I do store the input values in a UDTable or in an output file, the advantage would be I could schedule the process to run whenever things are slow. If I don’t, it’ll process when they click the button, but at least they can shut down their PC. Any other thoughts are welcome.

Hello, errors are already being caught in a separate UDTable; covered there. I agree on DMT; I’ll have to look into Workato. I do not have the function. Everything is currently client side. I like your idea best because from the way it sounds, I wouldn’t have to store the user’s input values in a UDTable or a file.

You don’t need a UD Table for that, if you know the slow times, just schedule it to run then in your initial call.

I say just attach a nuclear power source and let the client run 24/7/365. Keep control rods stocked in the broom closet.

3 Likes

From the time the user clicks the button, to the time the function processes, wont the input values be lost? I think I’m doing a bad job of explaining this, sorry :slight_smile:

Grid loads data via a BAQ but it also has a checkbox column called HockeyRules! HockeyRules is not populated by the BAQ. Instead, the user checks and unchecks certain rows.

I’m concerned with losing my HockeyRules values. Currently, the customization cycles through the rows in the grid, so it has no problem getting the HockeyRules value.

If I pass in the input values to the function as a parameter, and schedule the function to run later, will it hold the parameter values until processing time?

:ice_hockey:

Sounds a smidge illegal, but I dig the concept.

Sorry I mis read your initial post.

Down side of not storing it is the user cannot save the information, park it an walk away… Not sure how I would feel if for some reason Kinetic just shut down on me in the middle of keying in a hundred jobs…

Which does make me want to ask, why are you creating so many jobs manually?

Wouldn’t that be a PenaltyBox? You’d hate to have a checkbox in a no-check league…

2 Likes

yes it will be stored in systaskparams I think… Just like a report… (need to test)

EDIT
I misspoke it’s ice.SysAgentTaskParam

2 Likes

They’ll have to rework the object naming conventions…should read as Icing.SysActivityLog

3 Likes

No, they will be stored in the systaskparams (that’s the right table guys?) table for the scheduled function.

That’s how they work.

I’ve got an example on here somewhere for scheduling a function from a function. I don’t think I posted an example with scheduling an actual time, instead of “now”, but it’s not that difficult to set the time as well.

@Hally with the rescue, they’ll be there.

2 Likes

Good stuff! I’ll dig for that post and see what it’s all about. If it prevents me from using a UDTable, I think I’ll be ok with scheduling it “now”.

image

1 Like