Export Sets | Post-Export Script will only work in Global scope in Upper Envs

[George Cutrell]

We are using post-export scripts to move the export file from the default ./export directory on the MID server to another directory location.  We have created all the export configuration (definition, set, target, schedule) in an application scope.  And it all works fine in our lower environments.  After the scheduled export runs, we see the commands show up in the ecc_queue in both output and input queues.  And the files are moved as expected.  All is good.  

In our upper environments, both pre-prod and prod, the same configuration works in application scope except for the post-export script.  In the upper environments, we can only get the post-export scripts to run when in Global scope.  The differences between our upper environments and lower environments is we have 2 MID Servers that are clustered (load balanced) which necessitates our post-script to have 2 move commands - one for each MID Server.  Note:  We have 2 commands in the post script because when the post script runs, it doesn't know which MID Server received the export file because of the clustered configuration; only 1 of the move commands will work which is expected.

Again, all that works just fine in Global.  But with the same configuration in application scope in our upper environments, exact same post-export script, the post-export script seems to never run as I don't see any evidence in the ecc_queue output queue.  Yet, in our lower environments where we have only 1 MID Server and no need for clustered configuration, the post-export script also works just fine in application scope.  

For now, in our upper environments, we're just going to keep everything in Global scope but would really like to know why that makes a difference.

[Siris]

Hi, I am also trying to achieve the same using post-export scripts to move the export file from the default ./export directory on the MID server to another directory location.  How is it done, can you share??.   Thanks

[Ankur Bawiskar]

@Siris 

can you post a new question as this thread is very old? tag me in that new question

[George Cutrell]

In the year's time since my original post, we have not figured out why the post script only works in Global verses our application scope.  Not really an issue and a minor anomaly we're willing to live with.

Regarding the script itself, here's an example.  In our environment, we have 2 MID servers and because we don't know which MID server will receive the export, we issue the Linux shell command twice - once to each MID Server.  On the MID Server where the file is exported to, the command will actually do something and on the other MID server, it won't.  And because we have use the name of the file in the shell commands, we're making sure that particular command will affect only the file that was exported.  I don't know if there's a way for the post script to know the name of the exported file without having to affectively hard code it.  That would be nice as then our post scripts wouldn't have to be customized per export file.

var ecc = new GlideRecord("ecc_queue"); 
ecc.initialize(); 
ecc.agent = "mid.server.ProdMid1";
ecc.topic = "Command"; 
ecc.name = "cp export/myexport_*.csv archive; mv export/myexport_*.csv moveit";
ecc.queue = "output"; 
ecc.state = "ready";
ecc.insert();

var ecc = new GlideRecord("ecc_queue"); 
ecc.initialize(); 
ecc.agent = "mid.server.ProdMid2";
ecc.topic = "Command"; 
ecc.name = "cp export/myexport_*.csv archive; mv export/myexport_*.csv moveit";
ecc.queue = "output"; 
ecc.state = "ready";
ecc.insert();

Note:  If you don't have direct Linux access to the MID server, you can use the above approach to send "ls" commands to see the file system.  Works in a pinch when you don't have access. 

[George Cutrell · Accepted solution]

Resolved.  Seems obvious now.  Just needed cross scope privileges given to ecc_queue from source scope app to Global.