If a script is not working when run from SAFR Actions, its always a good idea to test the script outside of SAFR Actions.  This enables an easier means of debugging script issues.  If you have done this and the script works fine when when run at the command prompt, then there are a few possible reasons:

  • Arguments passed by SAFR Actions are different than expected
  • Differences in user permissions
  • Command PATH results in different executable than expected 

Below provides some recommendations for troubleshooting each possibility.


Arguments

Make sure the arguments that SAFR Actions is passing are the same as you expect.  A good way to find this out is to look at the SAFR Actions log file.  There you will find the command that SAFR Actions has executed.  Try to copy and paste that command and run it directly on the command line.

SAFR Actions Log File Location:

Windows: C:\ProgramData\RealNetworks\SAFR\ares\logs\ares.log
Linux: /opt/RealNetworks/SAFR/ares/logs/ares.log
macOS: /Library/RealNetworks/SAFR/ares/ares.log


In the log file you will see a line like this:

--> 2020-08-01 13:51:34 0.41sec id: 2D07BA32-7EEB-4442-A51C-17B3D3E8FBB5 Building1 FaceTime HD Camera (Built-in) staff Steve m 50 -> ./scripts/check_activity.py 2D07BA32-7EEB-4442-A51C-17B3D3E8FBB5 "Steve"

You should ensure that the command is properly quoted and can run correctly at the command prompt by copying and pasting it to your terminal or command window.


User Specific Errors

SAFR Actions will run scripts as System user. But when testing your script you may be running your scripts under a specific user account. That difference may result in different errors such as:

  • Environmental differences such as system PATH or python modules not installed for System user
  • Files not being accessible due to permissions for other reasons


File permissions

FIe may not be writeable.  This may even be true if the file was created in SAFR Actions program directory by a previous run of the script by a different user.  


Environmental differences

depending on the user, there may be differences such as the system path variable.  If you are using Python-based script, the installed modules can be different for different user depending on how they are installed.


To identify file permission or environmental differences, try to run your script as the system user.  You can do this on Windows using the following


https://docs.microsoft.com/en-us/sysinternals/downloads/pstools


Then open  DOS prompt as System user as follows:

https://stackoverflow.com/questions/77528/how-do-you-run-cmd-exe-under-the-local-system-account


In short, just download and install pstools from Microsoft using the link above and run the following command to open a DOS prompt as System user:

psexec -i -s cmd.exe

Then change directory to SAFR Actions and run the command you got from SAFR Actions log file.


Command PATH Issues

SAFR Actions runs scripts using the SAFR Actions application directory as the working directory.  This is the directory one level above the 'scripts' directory.  See above for list of SAFR Actions directories.  


Any relative paths referenced should be relative to this directory.


The case of the disappearing arguments

A subtle and hard to find issue with running commands from SAFR Actions is that arguments that resolve to an empty string will 


First, its important to know that any arguments passed to a script from SAFR Actions should be quoted as follows:

python .\scripts\myscript.py "#F" "#U" “#E” “#T”

If the quotes are omitted, then any empty values will appear as plain whitespace.  For example, if #E (external id) is empty in the person record, then the receiving command will only get 3 arguments where #T (person type) will be in the 3rd position instead of the 4th as expected.


This solution works well for Linux. 


But even when quoting, something even more subtle happens under Windows (DOS).  In the SAFR Actions log file, the command appears as follows:

python .\scripts\myscript.py "Steve" "McMillen" “” “noconcern”

But in the python or DOS Batch script that is invoked, something even more insidious occurs, the 3rd argument is simply dropped and if you echo the arguments with the following:

"echo %* >> log.txt"

you get only the following in the log.txt file:

"Steve" "McMillen" "noconcern"

As a workaround, when running SAFR Action in Windows, its advised to add an extra space to every token and trim the whitespace from the ends on the receiving side.  So the SAFR Actions "action" line should look like:


python .\scripts\myscript.py "#F " "#U " “#E ” “#T ”

observe there is an extra space character after each token.


Debugging - Getting Log Output from SAFR Actions Script

SAFR Actions does not write log output from the running script to any locations.  Nor does it capture error output from the command.  This is because SAFR Actions is designed for performance and does not hold a process handle to the running script.


But this design makes it very hard to troubleshoot problems that are specific to SAFR Actions.  For example, the previous section "The case of the disappearing arguments" will not happen if you run the command on the command line but will if you run the same inside SAFR Actions.


A good way to view logs from your scripts run from within SAFR Actions is as follows:


Create following DOS batch or shell script file in your SAFR Actions "scripts" directory:

@echo off
.\scripts\myscript.py %* >> app.log

The 2nd line should have script you are trying to debug.


Then modify the "action" in SAFR Actions config from this:

python .\scripts\myscript.py "#F" "#U" “#E” “#T”

To this:

.\scripts\log.bat "#F" "#U" “#E” “#T”

Now trigger an event (watch SAFR Actions log to make sure it got triggered) and then view output in app.log (which will be located in SAFR Actions directory (one above scripts).


Once you are done troubleshooting, don't forget to change the 'action' in SAFR Actions config back to your command directly.  And remember to add 'python' in front of the script if its a python script.