The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Allow user to run scheduled import on demand

bradleyperkins
Giga Contributor

We run a number of scheduled imports during off hours that bring in data for custom application. These imports use a mid server and JDBC to connect to our databases. The queries are designed to return only updated or new rows and the imports run quickly.

We have a need to allow a few non-admin users that manage the process the custom application supports to run those imports on demand during the day. I'd like to provide them with the capability to run an import at any time without giving them direct access to the Scheduled imports table.

This would be accomplished via a button that would appear on a table list or a navigator menu item. This would effectively perform the same action that the Schedule Import form "Execute Now" button does.

Can anyone suggest how we might provide this feature?

9 REPLIES 9

This is in a scoped application so neither of these are allowed. I'll look at your other suggestion. I would like to run the tested/working scheduled import if possible.



if (typeof SncTriggerSynchronizer != 'undefined')


    SncTriggerSynchronizer.executeNow(rec);


else


    Packages.com.snc.automation.TriggerSynchronizer.executeNow(rec);


gcubed_
Tera Contributor

We normally use a catalog item or record producer to allow non admins to execute processes that are normally done by an admin.



For catalog items, it is pretty easy to have the workflow engine tap the mid server to accomplish an number of things.   Just make sure that the mid server can update the requested item if you have any wait for activities in the workflow.



If the mid server activity is a fire and forget process, I normally use a record producer to trigger the mid server.



Using these methods, we have records on who and when a given user executed the process and the ability to lock down who has access to a given function base on group membership.



V/r,


Gene


Gene,



I've never thought of using a record producer this way. This would be a 'fire and forget' process as it is asking to load new data, with the expectation that the data might be available later (in a few minutes).



I would create a table, for example   'x_user_scheduled_import_log'.
That table's record producer form would simply consist of some instructions and a button that would create a record in that table logging who ran the action.


The record producer script would run code to fire the scheduled import.


We often use the record producer method for non-admins to load data.   They attach a xlsx spreadsheet, populate some default values for a given set of fields on the destination records and press go.   The record producer places the attachment onto the sys_data_source table, in this case, and the record producer script loads the data from the xlsx, populates an on startup script with the default values and runs the associated transform map.   In the transform maps on complete event, we send a notification that the load is completed along with any errors that we find in the import set table for this run.



The catalog item works best when a non-admin needs to run on demand process that requires semaphoring between the SN instance and an external process (Mid Server,   external long running interface, multiple external process steps…).   Here we use the workflow to fire the external processes via a run script activity passing whatever the external process needs along with the current requested item's sys_id. The workflow then drops into a wait for condition activity. Once the external process is complete or errors out, it reaches back into SN (usually via scripted REST service) to update the requested item and triggers the wait for condition in the workflow.



V/r,


Gene


bradleyperkins
Giga Contributor

Both Sachin's and Gene's suggestions led me to a solution after resolving the noted scoping problems.


I created a new table to log non-admin authorized imports and a record producer for that table. The record producer's script uses a variation of Sachin's suggestion to execute a scheduled import.



var rec = new GlideRecord('scheduled_import_set'); // We want to execute a scheduled import


rec.get('name', 'MY_JOB_NAME_HERE');


if (typeof SncTriggerSynchronizer != 'undefined') {


    SncTriggerSynchronizer.executeNow(rec);


} else {


    Packages.com.snc.automation.TriggerSynchronizer.executeNow(rec);


}



My problem was that both the table and the record producer had been created in the scoped application from which they will run. That did not allow the scheduled execution to be run. SncTriggerSynchronizer is not available.



Recreating both and the menu item module that calls the Record Producer in the global scope solved the problem.