Automation Script
sysopswork reads an automation script and interprets its instructions. Each instruction must be within a single line, with few exceptions (explained throughout this page).
At this page, I will explain how to create Basic Scripts to implement native commands with minimum instructions. In the next section, I will introduce how to automate REST(ful) API, then progress to Elaborated Scripts. At the end of this page, you will find additional instructions that can enhance even further your automation.
Note: Examples provided on this page are for demonstration only. Test your automation before implementing to production.
Basic Scripts
At minimum, you can automate your implementations by simply applying the vendor native commands provided top-down, used for straight forward well-known and tested implementations.
The least required instructions are OBJECT: to inform sysopswork where the command(s) must be implemented at, and the block IMPLEMENTATION-COMMAND-START/END: with the actual commands within.
Example of a basic script:
OBJECT: ubuntu001
IMPLEMENTATION-COMMAND-START:
sudo apt -y update
sudo apt -y install apache2
sudo ufw allow "Apache Full"
IMPLEMENTATION-COMMAND-END:
You can have as many commands as you need, and implement the commands in multiple objects using the same script. Another example of a basic script, implementing different commands in different objects:
OBJECT: ubuntu002
IMPLEMENTATION-COMMAND-START:
sudo apt -y update
sudo apt -y install nodejs
sudo apt -y install npm
IMPLEMENTATION-COMMAND-END:
OBJECT: ubuntu003
IMPLEMENTATION-COMMAND-START:
sudo apt -y update
sudo apt -y install apt-transport-https ca-certificates curl gnupg lsb-release
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt -y update
sudo apt -y install docker-ce docker-ce-cli containerd.io
IMPLEMENTATION-COMMAND-END:
Blank lines can be used anywhere for better script visibility.
Instruction IMPLEMENTATION-COMMAND-START: can be reduced to IMPCS:. And instruction IMPLEMENTATION-COMMAND-END: can be reduced to IMPCE:, as per below.
OBJECT: ubuntu001
IMPCS:
sudo apt -y update
sudo apt -y install apache2
sudo ufw allow "Apache Full"
IMPCE:
You will notice that some instructions will have both expanded format for clarity, and respective reduced version for brevity.
IMPORTANT: sysopswork instructions within IMPLEMENTATION-COMMAND-START/END: (or IMPCS/E:) block are considered part of the block. Therefore, ensure that you close the block before entering another sysopswork instruction.
REST(ful) Automation
REST set of instructions is used to automate HTTP(S) requests. It is not limited to RESTful though. It can also be used for other HTTP RPC flavors (such as SOAP), or RPC-Hybrid communication.
The name REST was chosen as it is becoming the de facto method of web service API by vendors.
Note: whenever I mention HTTP, I also mean HTTPS.
As REST automation deals with APIs, and not necessarily with objects, the instruction OBJECT: is NOT used with RESTful automation. sysopswork provides a set of REST instructions necessary to deal with API authentication.
Below are the major instructions used for RESTful automation (complementary instructions are provided throughout this page):
X.REST-METHOD: (or X.RESTM:) is used to indicate HTTP method. Valid values are GET, POST, PUT, PATCH, DELETE. The default method is GET.
X.REST-URL: (or X.RESTU:) is the only required REST instruction. It is used to indicate the URL (also known as URI) used for the request. Enter a string not enclosed to any quotes (or other characters). Must contain the entire query in URI encoded format.
X.REST-HEADERS: (or X.RESTH:) is used to adjust HTTP request headers, if necessary, meaning its optional. It has to be provided in JSON format with all values being in string format. Example is provided below.
X.REST-DATA: (or X.RESTD:) instruction is where the enclosed-body data of the HTTP request is defined, if required. This instruction is for cases where the data can be provided within a single line.
Block X.REST-DATA-START: (or X.RESTDS:) and X.REST-DATA-END: (or X.RESTDE:) is also used for enclosed-body data, however for multi-line data value. Data goes between instructions X.REST-DATA-START: and X.REST-DATA-END:, not at the same line of the instructions.
IMPORTANT: sysopswork instructions within REST-DATA block are considered part of the block. Therefore, ensure that you close the block before entering another sysopswork instruction.
X. represents a sequence number, meaning that you replace X by a number. This is used for other parts of the script, that will be explained further down on this page, and it is recommended to be used for all REST request calls, although not mandatory.
A set of instructions is provided per REST API request call.
An example of REST API script:
1.REST-METHOD: POST
1.REST-URL: https://example.com/api?set=val
1.REST-HEADERS: {"Content-Type":"application/json"}
1.REST-DATA: {"object": {"keyOne": "valueOne", "keyTwo": "valueTwo"}}
2.RESTU: https://example.com/api?get=val
2.RESTH: {"Content-Type":"application/json"}
Notice this script does not have the instruction OBJECT:, as it is not used for REST API automation.
Also notice the sequence number used is the same for all instructions of respective REST API call. Even not being mandatory, this is a good practice to differentiate the HTTP requests. The sequence number used for reference of other instructions that will be explained further down on this page is the one provided with REST-URL: instruction.
At same script, you can automate both command line implementation as well as REST API calls. Example of such combination:
OBJECT: ubuntu001
IMPCS:
sudo apt -y update
sudo apt -y install apache2
sudo ufw allow "Apache Full"
IMPCE:
1.RESTM: POST
1.RESTU: https://example.com/api?set=val
1.RESTH: {"Content-Type":"application/json"}
1.RESTD: {"object": {"keyOne": "valueOne", "keyTwo": "valueTwo"}}
OBJECT: ubuntu002
IMPCS:
sudo apt -y update
sudo apt -y install nodejs
sudo apt -y install npm
IMPCE:
Important to notice that REST commands are provided consecutively, and that none of the REST instructions are within the block IMPLEMENTATION-COMMAND-START: and IMPLEMENTATION-COMMAND-END:, so sysopswork can distinct what are CLI commands and what are REST API calls.
Elaborated Scripts
So far, scripts presented show how to implement commands as well as submit REST API calls. This can get you started with some simple automation, but how can we confirm that commands were properly implemented, or that the object is now configured as intended. In the case of REST API, we also need to have a way to read responses and determine that automation worked as expected, or not.
sysopswork follows an implementation life cycle, and specific instructions are used in order to determine at which implementation step the instruction is, and within each step, we can determine if the results of the commands implemented (or REST API calls requested) were successful or not, and act upon it, by proceeding, stopping or even reverting back the implementation.
More details of the implementation life cycle can be found at Implementation Life Cycle , but I will provide a quick overview here.
sysopswork Implementation Life Cycle consists on the following steps:
Pre-Implementation Test
Implementation
Post-Implementation Test
Back-out
Post-Backout Test (or Final Test)
Within each step, sysopswork has 4 instructions:
Step Command
Step Results
Step Success Action
Step Failure Action
The reason of having steps and respective instructions is for sysopswork to know what to do next. For example, if a pre-implementation test failed, sysopswork is supposed to stop before proceeding with the actual implementation command. Another common sense example is for sysopswork to have the ability to revert back the implementation in case post-implementation tests return unexpected results.
Although initial instructions listed below are used for CLI native commands, REST instructions also follow the Implementation Life Cycle and details are provided in the last subsection.
Pre-Implementation Test Instructions
Pre-Implementation Test command instruction is:
X.PREIMPLEMENTATION-COMMAND: native command
Or its reduced version:
X.PREC: native command
X. is optional, and X is a reference number. More information about reference numbers is provided at Variables.
The native command is the actual command that sysopswork will run at the object, similar to what you type when you want to enter a command at the target device.
You can run any command as part of the pre-implementation test, but benefiting from the concept of the Implementation Life Cycle this command should be a verification before the acutal implementation.
And without analyzing the results of the command, PREIMPLEMENTATION-COMMAND: (or PREC:) becomes just another command applied to the object. To analyze the results, we use the instruction:
X.PREIMPLEMENTATION-RESULTS: word OR regex OR precision syntax
Or its reduced version:
X.PRER: word OR regex OR precision syntax
Some native commands return some value back and sysopswork collects that value for analysis. You have 3 methods to analyze the results: “word”, “regex” or “precision syntax”. More information about those options is provided at Implementation Life Cycle.
If the results analyzed were successful, by default, sysopswork continues with the automation. You might want to stop the automation in case the test was successful, by using the following instruction:
X.PREIMPLEMENTATION-SUCCESS: stop
Or its reduced version:
X.PRES: stop
If the PREIMPLEMENTATION-RESULTS: or PRER: test fails, sysopswork will stop the automation and consider that automation has failed. There might be cases where you want to run a pre-implementation test, ignore the results of that test, and continue with the automation. For those cases, you can use:
X.PREIMPLEMENTATION-FAILURE: continue
Or its reduced version:
X.PREF: continue
None of the pre-implementation test instructions are mandatory, however, there are some rules you need to follow if you want to use them:
You cannot have a
PREIMPLEMENTATION-RESULTS:without aPRETEST-COMMAND:.You cannot have
PREIMPLEMENTATION-SUCCESS:norPREIMPLEMENTATION-FAILURE:without the instructionPREIMPLEMENTATION-RESULTS:.The instructions as part of the same step
PREIMPLEMENTATION-must be provided consecutively.
In the vast majority of your automation scripts, for pre-implementation test you will have the instruction PREIMPLEMENTATION-COMMAND: (or PREC:) and PREIMPLEMENTATION-RESULTS: (or PRER:).
Implementation Instructions
Implementation Instructions follow the same model as mentioned on Pre-Implementation Test Instructions section above.
Other than the instruction itself, the main difference is that rather than failing the automation if the results of the command returns an unexpected value, sysopswork triggers the back-out of the implementation. If no back-out instructions are provided in the script, then sysopswork by default will interrupt the automation and consinder that the implementation failed. More information is provided at Implementation Life Cycle.
The Implementation Instructions are:
Implementation Command:
X.IMPLEMENTATION-COMMAND: native command
Or its reduced version:
X.IMPC: native command
As most implementations have multiple commands, you can substitute IMPLEMENTATION-COMMAND by the block IMPLEMENTATION-COMMAND-START/END: (or IMPCS/E:) as shown on Basic Scripts section.
IMPORTANT: sysopswork instructions within IMPLEMENTATION-COMMAND-START/END: (or IMPCS/E:) block are considered part of the block. Therefore, ensure that you close the block before entering another sysopswork instruction.
Implementation Results:
X.IMPLEMENTATION-RESULTS: word OR regex OR precision syntax
Or its reduced version:
X.IMPR: word OR regex OR precision syntax
Ideally you should use IMPLEMENTATION-RESULTS: right after an instance of IMPLEMENTATION-COMMAND:. In case you use the block IMPLEMENTATION-COMMAND-START/END: instead, IMPLEMENTATION-RESULTS: will apply to the results of the last command of the block.
Implementation Success Action:
X.IMPLEMENTATION-SUCCESS: stop
Or its reduced version:
X.IMPS: stop
Implementation Failure Action:
X.IMPLEMENTATION-FAILURE: continue
Or its reduced version:
X.IMPF: continue
Post-Implementation Test Instructions
Post-Implementation Test Instructions follow the same model as mentioned on Pre-Implementation Test Instructions section above, however sysopswork deals with the results of post-implementation test in the same way as it does for the Implementation step. In other words, if the results of the command returns an unexpected value, sysopswork triggers the back-out of the implementation. If no back-out instructions are provided in the script, then sysopswork by default will interrupt the automation and consinder that the implementation failed. More information is provided at Implementation Life Cycle.
The Post-Implementation Test Instructions are:
Post-Implementation Test Command:
X.POSTIMPLEMENTATION-COMMAND: native command
Or its reduced version:
X.POSTC: native command
Post-Implementation Test Results:
X.POSTIMPLEMENTATION-RESULTS: word OR regex OR precision syntax
Or its reduced version:
X.POSTR: word OR regex OR precision syntax
Post-Implementation Test Success Action:
X.POSTIMPLEMENTATION-SUCCESS: stop
Or its reduced version:
X.POSTS: stop
Post-Implementation Test Failure Action:
X.POSTIMPLEMENTATION-FAILURE: continue
Or its reduced version:
X.POSTF: continue
Back-Out Instructions
If everything goes well with the implementation, meaning that the results of the commands applied on previous steps return the expected value, then Back-Out Instructions are simply skipped by sysopswork.
Although not mandatory, you must have a way to return your configuration to a previous state in case something goes wrong, and sysopswork use the Back-Out Instruction to perform this restoration.
Details about how Back-Out works is provided at Implementation Life Cycle.
Instructions are similar to the other steps of the Implementation Life Cycle.
The Back-Out Instructions are:
Back-Out Command:
X.BACKOUT-COMMAND: native command
Or its reduced version:
X.BACKC: native command
Similar to the block of commands of Implementation step, you can substitute BACKOUT-COMMAND by the block BACKOUT-COMMAND-START: with BACKOUT-COMMAND-END: (or BACKCS: with BACKCE:).
IMPORTANT: sysopswork instructions within BACKOUT-COMMAND-START/END: (or BACKCS/E:) block are considered part of the block. Therefore, ensure that you close the block before entering another sysopswork instruction.
Back-Out Results:
X.BACKOUT-RESULTS: word OR regex OR precision syntax
Or its reduced version:
X.BACKR: word OR regex OR precision syntax
Similar to Implementation step, if you use the instruction BACKOUT-RESULTS: right after the block BACKOUT-COMMAND-START: with BACKOUT-COMMAND-END:, the results analyzed will be from the returned value of the last command of the block.
Back-Out Success Action:
X.BACKOUT-SUCCESS: stop
Or its reduced version:
X.BACKS: stop
Back-Out Failure Action:
X.BACKOUT-FAILURE: continue
Or its reduced version:
X.BACKF: continue
In case the analysis of BACKOUT-RESULTS: brings an unexpected value, sysopswork interrupts the automation and considers that implementation has failed.
Final-Test Instructions
Final-Test is actually part of the Back-Out procedure, and also skipped by sysopswork if the implementation is proceeding as expected.
Although some might find this step redundant with Back-Out, as it has similar instructions and the behavior is the same in case the results of the command brings an unexpected value, it is a good practice to distinct what is actually a change command and a verification command. And this step serves the latter case.
The Final-Test Instructions are:
Final-Test Command:
X.FINALTEST-COMMAND: native command
Or its reduced version:
X.FINC: native command
Final-Test Results:
X.FINALTEST-RESULTS: word OR regex OR precision syntax
Or its reduced version:
X.FINR: word OR regex OR precision syntax
Final-Test Success Action:
X.FINALTEST-SUCCESS: stop
Or its reduced version:
X.FINS: stop
Final-Test Failure Action:
X.FINALTEST-FAILURE: continue
Or its reduced version:
X.FINF: continue
REST Implementation Life Cycle Instructions
As mentioned before, REST also follows the Implementation Life Cycle, and other than the instructions provided at REST(ful) Automation section, there are few other instructions necessary to determine the step of the life cycle and to analyze results of the API responses.
First, sysopswork need to know which step of the Implementation Life Cycle the request is part of. For that we use the instruction:
X.REST-STEP:
Or its reduced version:
X.RESTS:
Valid values are: PRE for pre-implementation test, IMP for implementation, POST for post-implementation test, BACK for back-out, and FIN for final test. This instruction is optional. By default, the value is IMP.
The instruction to verify the enclosed-body data of a response for a REST request is:
X.REST-DATA-RESULTS: PARSE COMPARISON "VALUE"
Or:
X.REST-DATA-RESULTS: RESULTS_REGEX
X.REST-DATA-RESULTS: can be compressed to X.RESTDR:.
PARSE can be: JSON("VALUE_QUERY"), XML("FULL_XPATH_ELEMENT_QUERY", "OPTIONAL_ATTRIBUTE", "OPTIONAL_NS_REG") or RAW(). RAW() does not have any parameter. It indicates that the first line of HTTP response enclosed body will be compared. If there are multiple raw text lines, you should use RESULTS_REGEX instead.
For XML, only the paramenter XPATH_ELEMENT_QUERY is required. If OPTIONAL_ATTRIBUTE is provided, the value of the attribute is fetched instead of the value of the element. OPTIONAL_NS_REG can be used to register a list of known namespaces in the format: <prefix1>=<href1> <prefix2>=href2> .... Usually only XPATH_ELEMENT_QUERY is necessary with REST APIs.
If XML() is used and XPath returns a set of nodes, sysopswork will verify all nodes and consider the results as expected if matched on all nodes. If one the nodes fail with the test, the XML test will fail. Suggestion is to indicate XPath with minimum nodes as possible. Ideally the only one you are testing.
COMPARISON is the same used by control flows. More details at Control Flow .
"VALUE" is a string and must be enclosed between double quotes.
RESULTS_REGEX is the same used for any -RESULTS instructions. Details provided at Implementation Life Cycle .
Example of XML REST Response:
<xml>
<data>
<object>
<id>123456</id>
</object>
<object>
<id>098765</id>
</object>
</data>
</xml>
If you want to confirm that first object ID is “123456”, then use the following data results query:
X.REST-DATA-RESULTS: XML("/xml/data/object[1]/id", "", "") IS "123456"
And to verify the headers of a response for a REST request, the instruction is:
X.REST-HEADERS-RESULTS: RESULTS_REGEX
X.REST-HEADERS-RESULTS: can be compressed to X.RESTHR:.
Example of HTTP Header data when accessing https://www.google.com:
HTTP/2 200
date: Mon, 16 May 2022 01:23:38 GMT
expires: -1
cache-control: private, max-age=0
content-type: text/html; charset=ISO-8859-1
p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
server: gws
x-xss-protection: 0
x-frame-options: SAMEORIGIN
<hidden information for brevity purposes>
Notice that the first line contains the status code 200, this line also counts during RESULTS_REGEX verification, meaning that if you want to check the header “expires”, it is the 3rd line of the verification.
sysopswork only analyzes data content from responses with status code 2xx.
sysopswork will automatically follow redirects, if necessary.
If any error code is returned, sysopswork will consider the implementation failed, and will provide the returned code, headers and any body data in the error message on log file.
Additional Instructions
Below you find instruction that were previously described and some additional useful instructions you can leverage.
OBJECT:
Required.
One of the most important instructions of the script. This instruction is mandatory before any command instruction. It tells sysopswork where to implement the commands. It has the following format:
OBJECT: name(technology)
The (technology) part is optional if the technology is “compute”. For other technologies, this parameter has to be informed.
ADDOBJ:
Optional.
Used to add objects to sysopswork system. It is ideal when you are provisioning a new object then you want to configure that object using the same script.
It takes a JSON format value and syntax is the following:
ADDOBJ: {"name": "OBJECT_NAME", "ip_address": "IP_ADDRESS", "access_method": "ACCESS_METHOD", "login_mode": "LOGIN_MODE", "prompt": "PROMPT", "public_port": "PUBLIC_PORT", "service": "TECHNOLOGY"}
You can also enter credentials on ADDOBJ using the following valid keys: - “username” - “password” - “keyfilepath” - “passphrase” - “thumbprint”
More details on how to add an object can be found at Objects.
TEXT
Optional.
There are some local commands that read from text files (YAML, JSON, etc). And sometimes data at those text files is determined after some CLI command or REST API call.
For those cases, you can use TEXT instructions to indicate to sysopswork that there are variables that are evaluated during automation and those values need to be adjusted at the text file that will be used by another command.
If the data at the text file does not change, you don’t need to use TEXT instructions. If it does change during automation, ensure to have the variables within {{var}} (double curly brackets), so sysopswork can replace them by the variable values.
TEXT instructions are:
TEXT-FILE: "path_to_existing_file"
Notice that path fo existing file has to be enclosed within double quotes.
The short version of TEXT-FILE: instruction is:
TEXT: "path_to_existing_file"
You can also create new text files within the script for the same purpose, but including the text content at the script file. The syntax is:
TEXT-FILE-START: "filename"
text line
text line with {{variable}}
text line
TEXT-FILE-END:
Notice that for TEXT-FILE-START: you have to indicate only the filename, not the path to the file. This file will be saved at sysopswork subdirectory /temp during automation. After implementation, it will be deleted. If you want the file to persist, use the instruction TEXT-FILE: instead.
The short version for block TEXT-FILE-START/END: is:
TEXTS: "filename"
text line
text line with {{variable}}
text line
TEXTE:
Although TEXT instructions make more sense to be used when there is a variable that will be evaluated during automation, you can still include the block TEXT-FILE-START/END: (or its short version TEXTS/E:) in your script, with static content for reference of the data that will be consumed by the CLI command or REST API call.
IMPORTANT: Control flow instructions (including }, CONTINUE, and BREAK) within text blocks are considered part of the text file, not as sysopswork instructions. Other sysopswork instructions within a text block will be considered a syntax error. Therefore, ensure that you close the text block before entering another sysopswork instruction.
QUESTION: & ANSWER:
Optional.
Always provided with both instructions in two distinct lines.
QUESTION: and ANSWER: is used to replace parameters in a script before the automation starts. It is great for reusability, when you have commands where some parameters are different between implementations and you don’t have to create different scripts for each implementation.
QUESTION: instruction contains any string. It could be a question or any statement that indicates what the script is looking for.
ANSWER: is the part that replaces the answer variable on other lines of the script.
Better explained with an example. Let’s say you want to have a script to install packages on a specific Ubuntu host (ubuntu001), but you want to use the same script regardless of the packet. Your script would look like the following:
QUESTION: What is the APT package name?
ANSWER: package
OBJECT: ubuntu001
apt -y update
apt -y install {{package}}
Notice that QUESTION: and ANSWER: have each their respective lines and ANSWER: is consecutive of QUESTION:. This rule must be followed.
For the instruction QUESTION:, the part What is the APT package name? can be any statement. It is used to ask the user of the script what is the information the script is looking for.
For the instruction ANSWER:, the value package is critical. Before the automation begins, sysopswork will ask the question to the user, and whatever answer the user provides will replace any occurences on the script which contains {{}} with the answer value on it. In the previous example, the last line apt -y install {{package}} will have the placeholder {{package}} replaced by the user’s answer.
If the user answers nodejs, the script implemented will look like the following:
OBJECT: ubuntu001
apt -y update
apt -y install nodejs
You can use as many QUESTION:/ANSWER: instruction pairs as you want.
Any instruction can have the {{PARAMETER}} placeholder, with exception of the instructions QUESTION: and ANSWER: themselves.
This works great with commands and the instruction OBJECT:.
PROMPT:
Optional.
The instruction PROMPT: should not be confused with the object prompt. Both are indeed prompts (the reason of keeping both with same name), but are used for different purposes.
The instruction PROMPT: is used when the automation flow is interrupted by the terminal/Command Prompt request for user input. Let’s say that you enter a command, and the terminal requests your password (majority of the cases of using PROMPT:). You can use PROMPT: to provide the password and continue with the automation.
In its simplest form, PROMPT: has the following syntax:
PROMPT: query$answer
The $ sign separates the query from the answer.
The query is any word that sysopswork reads from the terminal for what the command requests. If the command you enter provides the following prompt:
Enter your password:
You can use password as your query. It can be any word or part of the word that is requested by the terminal.
The answer is the exact input you would type in the terminal/Command Prompt enclosed within valid delimiters. The valid delimeters are: /, %, or |. In other words your answer should be provided as: /answer/, %answer%, or |answer|.
Say you enter a command that asks you the following question:
Would you like to proceed? (y/n)
And you want to answer y. Your PROMPT: instruction would look like:
PROMPT: proceed$/y/
Noticed that I took any word from the terminal request as a query. It could have been like or Would, but proceed is more relevant to the understanding of the prompt. I also picked the delimeter /. I could have picked the other delimeters if the delimeter would conflict with the answer that has to be provided.
You can also use your credentials for a specific object just by referring to them. For example, let’s say that your password for an object is “admin” (I hope this is not your real password). Instead of using the PROMPT: instruction as:
PROMPT: password$/admin/
You can use:
PROMPT: password$password
This does not mean that sysopswork will enter the word “password”. It means that sysopswork will use your password for the respective object (in this case “admin”), and enter it for this prompt.
The valid credentials are: $user, $password.
# COMMENT
Optional.
Any string within the same line trailed by # is considered a comment. It is used simply for documentation purposes. sysopswork ignores comment lines during automation.
# This is a comment!
EXIT:
Optional.
Whenever sysopswork connects to an object to implement commands, it automatically leaves the object by an implicit “exit” command. You don’t have to enter this instruction if this is what it takes to leave the object.
However, there are some objects that require more than a single “exit” command, or use a different command to leave the communication session. For those cases, you have to provide what are those commands.
If you provide one or more EXIT: instructions in the script, sysopswork will no longer use the implicit “exit” command.
For example, if two “exit” commands are necessary to close the session with the object, your script must contain:
EXIT: exit
EXIT: exit
If “quit” command is the one used to close the session with the object, the instruction will be:
EXIT: quit
This is optional and used only in cases where the command to close the session is not a single “exit”.
WAIT:
Optional.
This instruction makes sysopswork waits for the provided number of seconds before proceeding with the next steps of the automation. This is usually necessary when you have to wait for some process in the background to complete before you proceed.
Notice that I highlighted background on previous paragraph. The reason is because you DO NOT need to use the instruction WAIT: if the process called by the last command or REST API request is actually running in foreground and provind you with results. For those cases, sysopswork will wait anyways for the command or HTTP request to complete with a response before proceeding.
The syntax is:
WAIT: seconds
Replace seconds by the number of seconds.
Note: The number of seconds provided in a WAIT: instruction increases the number of seconds of the current timeout interval, as they must not conflict.
PRINT:
Optional.
It prints a message in the log file. It is good for reference and troubleshooting purposes.
The syntax is:
PRINT: value
value being any string or variable. PRINT: instruction’s main objective is to print variables, which are described at page Variables. To print a string, just enter any string without starting with the character $, which is reserved for variables.