Inside Activate
...
Scripting
Scripting Guidelines
5 min
scripting guidelines activate scripts can be written in c#, vb net or powershell this article outlines general guidelines for the implementation of scripts to run in an activate environment execution times the activate job engine executes activate workflows and executes the activate scripts as part of this workflow the job engine executes a limited number of processes at any one time this is generally number of cpu 8 processes this means on a single cpu machine 8 jobs can be executed at any once time however, as a means of limited a specific task from taking over the server, only 50% of the available threads can be running a task at any one time activate scripts are generally intended to run in a 'short' period of time scripts that take a long period of time can prevent over processes from running in general, avoid thread sleep() functions and blocking in the script as much as possible instead activate scripts should use the activate job retry functionality best practices scripts should generaly take less than 1 minute longer running scripts may cause performance issues use jobworkflow\ result retry for things that need to retry logging most activate scripts execute in the context of a job all job logxxx functions log output to the activate database each log entry as a message and detail associated with it the following functions are available job logtrace(message, details) this will log trace entries to the database these will be deleted automatically after 90 days job logaudit(message, details) this will log an audit entry that is permanent these are never deleted job logerror(message, details) this will log an error log entry this can be used to log an error but still continue the script best practices limit log entries in production databases large amount of logging is expensive on performance and disk space in the sql database use logtrace for temporary logging remove debug logging in production scripts exception handling activate uses net exceptions to detect errors in scripts catching and logging the error in the script will prevent the job from failing this is sometimes desired but must be used carefully