nop cut succeed fail errorcode applyAllRules if while for foreach break assign writeString writeLine delay remote

nop Description: No action. Note: This microservice is a placeholder, with no operation being performed (no-op). Example Usage: See clients/icommands/test/rules3.0/ cut Description: Tells the rule engine not to retry any other applicable rules for this action. Example Usage: See clients/icommands/test/rules3.0/ succeed Description: Succeed immediately. Example Usage: See clients/icommands/test/rules3.0/ fail Description: Fail immediately. Recovery and retries are possible. Example Usage: See clients/icommands/test/rules3.0/ errorcode(action) Description: This microservice traps the error code of an action. Note: The rule engine views the return value of most microservices as an integer “errorcode”. If the return value of a microservice is less than zero, the rule engine interprets it as a failure, rather than an integer value; and if the return value is greater than zero, the rule engine interprets it as an integer. Therefore, an expression that compares whether the return value of a microservice is greater than or equal to 0 either evaluates to true or fail, since when the microservice returns a negative integer, the rule engine interprets the value as a failure. In some applications, there is need for capturing all possible return values as regular integers. The “errorcode” microservice can be used to achieve this by putting the action whose return value needs to be captured in action. Example Usage: See clients/icommands/test/rules3.0/ applyAllRules(action, expr, expr) Description: This microservice executes all applicable rules for a given action. Note: Normal operations of the rule engine is to stop after a rule (one of the alternates) completes successfully. But in some cases, one may want the rule engine to try all alternatives and succeed in as many as possible. Then by firing that rule under this microservice all alternatives are tried. The first expr is a parameter of type string or integer which is 0 or 1, the value used to check if the rei structure needs to be saved at every rule invocation inside the execution. This helps to save time if the rei structure is known not to be changed when executing the underlying rules. The second expr is a parameter of type string or integer which is 0 or 1, whether the “apply all rule” condition applies only to the action or is recursively done at all levels of invocation of every rule inside the execution. Example Usage: See clients/icommands/test/rules3.0/ if( expr ) { actions } else { actions } Description: The if-then-else construct in the rule language. Note: The expr is a conditional check. If the check is successful (true), the first actions will be executed. If the check fails, then the second actions will be executed. Example Usage: See clients/icommands/test/rules3.0/ while( expr ) { actions } Description: The while loop in the rule language. Note: The expr is a condition that will be checked on each loop iteration. The actions are the body of the while loop and will be executed as long as the condition evaluates to true. Example Usage: See clients/icommands/test/rules3.0/ for( expr; expr; expr ) { actions } Description: The for loop in the rule language. Note: It is similar to the for construct in C. Example Usage: See clients/icommands/test/rules3.0/ foreach( var ) { actions } Description: Performs a loop over a list of items given in different forms. Note: The foreach loop, similar to C-type languages, loops through the items in a list. It takes a list (or a general query result), and for each item stored in the variables, executes the actions within the body of the loop. The var specifies the variable that has the list (the same variable name is used in the body of the loop to denote an item of the list!). Example Usage: See clients/icommands/test/rules3.0/ break Description: Breaks out of while, for and foreach loops. Example Usage: See clients/icommands/test/rules3.0/ var = expr Description: The "=" operator assigns a value to a variable. Note: It can be used to assign values to * and $ variables. Example Usage: See clients/icommands/test/rules3.0/ writeString(expr, expr) Description: Appends a given string to the given buffer. Note: This microservice takes a given buffer string and appends it to the end of a buffer (either stdout or stderr in ruleExecOut parameter) or a local log file. This may be extended later for writing into an iRODS file, too. The ruleExecOut is a system MS-parameter (*variable) that is automatically available. The first expr is a parameter of type string which is the buffer name in ruleExecOut. Currently, “stdout”, “stderr”, and “serverLog” are supported. The second expr is a parameter of type string which is the string to be written into the named buffer. Example Usage: See clients/icommands/test/rules3.0/ writeLine(expr, expr) Description: Writes a given string and newline character into the given buffer. Note: This microservice takes a given buffer string and appends it and a newline character to the end of a buffer (either stdout or stderr in ruleExecOut parameter) or a local log file. This may be extended later for writing into an iRODS file, too. The ruleExecOut is a system MS-parameter (*variable) that is automatically available. The first expr is a parameter of type string which is the buffer name in ruleExecOut. Currently, “stdout”, “stderr”, and “serverLog” are supported. The second expr is a parameter of type string which is the string to be written into the named buffer. Example Usage: See clients/icommands/test/rules3.0/ delay( expr ) { actions } Description: Executes a set of operations later when certain conditions are met. Note: This microservice can be used to perform periodic operations. The expr is a delay condition. The actions are a set of statements that will be delayed in execution until the delay condition is true. The condition also supports repeating of the body until success or until some other condition is satisfied. The delay condition is a parameter of type string. It is tagged with the following tags: EA - execAddress - host where the delayed execution needs to be performed ET - execTime - absolute time when it needs to be performed. PLUSET - relExeTime - relative to current time when it needs to execute EF - execFreq - frequency (in time widths) it needs to be performed. The EF value is of the format: nnnnU <directive> where nnnn is a number, and U is the unit of the number (s-sec,m-min,h-hour,d-day,y-year), The <directive> can be of the form: <empty-directive> - equal to REPEAT FOREVER REPEAT FOREVER REPEAT UNTIL SUCCESS REPEAT nnnn TIMES - where nnnn is an integer REPEAT UNTIL <time> - where <time> is of the time format supported by checkDateFormat function below. REPEAT UNTIL SUCCESS OR UNTIL <time> REPEAT UNTIL SUCCESS OR nnnn TIMES DOUBLE FOREVER DOUBLE UNTIL SUCCESS - delay is doubled every time. DOUBLE nnnn TIMES DOUBLE UNTIL <time> DOUBLE UNTIL SUCCESS OR UNTIL <time> DOUBLE UNTIL SUCCESS OR nnnn TIMES DOUBLE UNTIL SUCCESS UPTO <time> Example Usage: See clients/icommands/test/rules3.0/ remote( expr, expr ) { actions } Description: Executes a set of operations later when certain conditions are met. Note: This microservice takes a set of actions that need to be executed at a remote iRODS server. The first expr is a parameters of type string which is a host name of the server where the body need to be executed. The second expr is a parameter of type string which is a delay condition about when to execute the body. If there is no delay condition, the execution is done immediately and synchronously with the result returning back from the call. Example Usage: See clients/icommands/test/rules3.0/