Introduction to the Python Task API

the swimlane rest api and python driver allow you to connect to and interact with the swimlane platform from external entities (other programs acting as swimlane clients) the swimlane python script task type and the python task api allow you to customize and extend functionality within the platform swimlane offers these task types built in tasks such as the email import task that uses swimlane platform code to retrieve email message data from an imap inbox plugin tasks that vary depending on which plugins you have installed powershell script tasks python script tasks see docid\ ryxk0zn8kfyu4nr zkwjm for more information on creating python script tasks authoring and testing the script to author a python script that will be executed within swimlane from the left navigation menu, select integrations on the tasks tab, click new task and then click create a task on new task, filter for script and then select python (either version, 2 7 or 3 6) select that task type, and then click create in the new task \ python form enter a task name and optionally specify the application to which this task will be affiliated then click the save button in the upper right in the resulting page displaying the newly formed task, click the configuration tab type or paste in the desired python script code click the triggers tab and explore options for defining the times and conditions in which the new task's script will be executed inputs and outputs the swimlane task api provides the primary means of conveying input data into the task's script and retrieving output values from the script in addition, the script can interact with the swimlane rest api and its python driver, which gives this task type even greater power and flexibility many scripts use both the task api and the rest api/driver task api inputs the python task api provides the script with input values via several objects, all of which are python dictionaries sw context config sw context inputs sw context user sw context state these inputs are marshalled together and injected into the script by the platform whenever a python script task is executed as a background job they are not present within the script when it is executed from the task’s debugger console the sw context config object has the following keys/values sw context config\['swimlaneurl'] is the base url of the swimlane server (e g https //swimlane yourdomain com ) that launched the task sw context config\['internalswimlaneurl'] is the internal url used in opening a connection through the swimlane python driver sw context config\['applicationid'] is, if applicable, the id of the swimlane application with which the task is affiliated (this value is not available in debug mode ) sw context config\['recordid'] is, if applicable, the id of the swimlane record upon which the task was launched to operate (this value is not available in debug mode ) the sw context inputs object contains keys and values defined within the task's inputs tab (in the lower pane of the configuration tab) the developer can create an arbitrary number of input values specified by user chosen name and input type/value pairs the available input types are shown in task script intputs jpg for example, assuming the task's application has a field named "file hash", you can define a script input named "file hash" whose type is record, sub type field file hash then, to access the value of the record's "file hash" field at run time the script would simply hash value = sw context inputs\['file hash'] the sw context user object contains values pertaining to the user account under which the task is executed for example, if the task is triggered by changing a record and saving the change, then sw context user will contain information about the swimlane user whose record modification triggered the script's execution modified by user name = sw context user\['display name'] you can inspect the properties within the sw context user by following the instructions in debugging python script tasks, and forked plugin tasks, with print statements or debugging python script tasks, and forked plugin tasks, with custom log files using the guidance within the python section in helpful commands and queries add the following diagnostic code print(json dumps(sw context user, sort keys=true, indent=4, separators=(",", " "))) this code also works well for print statement debugging for log file debugging use json dump(sw context user, log file object, sort keys=true, indent=4, separators=(",", " ")) the sw context state object exists to provide the developer with a place to store values between script executions, in other words, the script code itself for example from datetime import datetime if 'last access datetime' in sw context state # do something with last access datetime, the value assigned on the previous script execution sw context state\['last access datetime'] = datetime now() strftime('%y %m %d %h %m %s') the key value pairs added to sw context state are available within the platform for future use after the script executes they can be found within the swimlane integrationstates collection which you can access by querying mongodb this allows each python script task its own data store which is a very useful feature consider the following example updated since = '' if 'last updated since' in sw context state updated since = sw context state\['last updated since'] else updated since = '2020 06 04t00 00 00z' logfile write('querying third party api for updated alarms starting ' + updated since + '\n') # query for and process the updated alarms new updated since = pendulum now() to rfc3339 string() replace('+00 00', 'z') sw context state\['last updated since'] = new updated since logfile write('retrospective date and time for the next run ' + new updated since + '\n') the above script, when run with a scheduled trigger launching it every 20 minutes, for example, can know to fetch and act upon only those alarms updated within the prior 20 minutes the added benefit, however, is that if the swimlane deployment hosting the script goes down for 2 hours for maintenance, the script will do the right thing the next time that it executes specifically, the first time that it runs, it will know to query for all of alarms updated within the prior two hours the second time that it runs after the maintenance window it will resume its typical behavior of launching every 20 minutes and fetching/processing only those alarms updated within the prior 20 minute span you can also test swimlane workflow this code is not well suited for production use, but it does make testing nuanced worfklow behavior easier count = 0 per record key = sw context config\['recordid'] + ' execution count' if per record key in sw context state count = sw context state\[per record key] sw context state\[per record key] = count + 1 if count == 0 sw outputs = \[{'data' 'first output'}] print 'count is {0} and record id is {1}' format(str(count), sw context config\['recordid']) else sw outputs = \[{'data' ', second output'}] print 'count is {0} and record id is {1}' format(str(count), sw context config\['recordid']) this creates a new entry in the script’s state store for every record upon which it operates this wouldn’t scale for an application with thousands or tens of thousands of records, but it is useful in pre production scenarios for determining how many times a script is invoked by the workflow feature upon a given record, and under what circumstances task api outputs to make assignments to a record's fields using the task api add the desired values to sw outputs for example import json import urllib iptolookup = sw context inputs\["ip"] yourapikey = sw context inputs\["api key"] url = 'https //www virustotal com/vtapi/v2/ip address/report' parameters = {'ip' iptolookup, 'apikey' yourapikey} response = urllib urlopen('%s?%s' % (url, urllib urlencode(parameters))) read() sw outputs append({'vt result' response}) then, make corresponding changes to the task's output mappings for the example above, that would involve setting up an output mapping from "vt result" to a chosen destination field retrieving files from an attachment field to retrieve files from an attachment field, configure a task input named "attachment field 1", and then add the following lines to your task's script files = context inputs\['attachment field 1'] for file in files name = file\['filename'] data = file\['base64'] # do something with the file # e g decode the file data and submit name and decoded data to a threat intel service