As part of our offboarding workflow, there is a process that exports the RITM#/username/userID to a file via mid server export. I have been trying to figure out where it is having trouble, which is typically when terminations get 'batched' and trigger at same second or within a few seconds- Friday afternoons typically. I have been refining the workflow and adding in some randomizing timers, and that may still be the option here, but now that I have a better idea one where this is failing, I am seeking advice.
From the OFFBOARD WORKFLOW there is an EXPORT TO MIDSERVER activity-
var gr = new GlideRecord("scheduled_data_export");
gr.addQuery("sys_id", 'cd0af7921bb9a5505d8b41d5ec4bcbe1'); // sys_id of your scheduled export
gr.query();
if (gr.next()) {
gs.executeNow(gr); // if using in scoped app
//SncTriggerSynchronizer.executeNow(gr); // if using in non-scope app i.e global
}There is a 40 minute wait timer after this, at the end of which it does a data import on the table that tracks success/failure looking for the RITM#. I had previously thought the problem was after the export, but after refining and changing things, that is not the case.
Above is the screenshot of the scheduled job that gets triggered to send the file to mid server. What is happening is related to the DELTA REPORTS option above... the call from the offboard workflow DOES NOT include a RITM#, just the gs.execute to do this. And because there is several offboards being started within seconds, by the time one RITM gets to here, another has already been created, and this is exporting the following (wrong/incorrect/subsequent) RITM details.
The retry-loop I added is not helping because this job is not looking for the RITM# specifically that is triggered, just the most recent since the RITM was created... which is not always the RITM in question when several get created at the same time.
I would think the ideal solution would be to somehow pass the current.number over for the scheduled job (which results in export target/definition) to pull the correct RITM details... but not sure how to do that given this sequence of events before it gets to the EXPORT.
How do I get the scheduled export/definition to lock onto the correct RITM# with the above as a starting point and being called from the offboard workflow?
Jeff
The export definition and target are working, but they sometimes export the wrong RITM info because of this-
When this runs and grabs the most recent updated RITM... that RITM is not the one that triggered this data source; another RITM was created in the ticks between, and that RITMs details are the ones exported.
I am trying other kludgy methods on slowing down RITM creation for offboards to give a few seconds for this to work correctly, but ideally... the data source should be passed the exact RITM somehow and there would be no chance for this delta reports thing to lock onto the wrong RITM when say 5 are created within 10 seconds. Does that make sense?
