Can I test Playbooks with CLI?

[SergioPalacios]

Hi everyone,

I'd like to know if it's possible to test Playbooks via the command line interface or something similar. Currently, I always use the GUI for testing purposes, loading an incident from the debugger panel and just clicking to run. However, sometimes, the GUI is too slow, especially when the playbook has a lot of "boxes" to render. Generally, it doesn't depend on how difficult the boxes are to run; it seems that having many boxes to render in the same playbook or sub-playbook severely affects performance, increasing the browser's RAM usage too (it doesn't matter which browser, as all yield the same results: Mozilla, Chrome, Edge, Opera...).

So, I think testing playbooks with the debugger panel using something like CLI or API would be nice. Is it possible?

Thank you all.

[asawyer]

Hi @SergioPalacios – I don't think it is possible to do exactly what you're looking for, but I have a few suggestions that may help.

• It is possible to trigger a playbook automatically, which may help with your testing, because then you can kick off the playbook automatically and return to it later to review, once the tasks are done running. The command to do this is !setPlaybook
• You can also run the playbook in the Playground Work Plan to test, rather than using the debugger. Sometimes I find this is faster than the debugger.
• For the construction of the playbook itself, using subplaybooks so that there are less tasks in the top-level playbook to render can help speed up the page loading time.

Let me know what you think!

[SergioPalacios]

Hi @asawyer !

Thanks a lot for reply! I'll test all of your suggestions and I'll let you know if it works! 😀

Is it possible that the "delay" meanwhile executing all the task in a playbook is due to a big work plan? My playbook has a lot of "boxes"/task and subplaybooks in a same main playbook. So, do u think that split all the playbooks in a different individuals playbooks called each one with !setPlaybook would be work better than only one? 
I mean, Palo Alto says that work plans bigger than 3MB can overload XSOAR and makes the playbook run slower than normaly. But i dont really know if the work plan size is related to an incident or its just indepent in each playbook.

Thanks in advance!

[asawyer · Accepted solution]

Hi @SergioPalacios – The number of tasks in a playbook does contribute to the amount of time it takes for the playbook to load in the UI. So breaking your playbook into smaller subplaybooks is a good practice, especially if the playbook is large (30+ tasks). 

The work plan size does vary by incident, because it is not just the size of the playbook itself, but also the inputs, outputs, war room entries, etc. that are specific to each incident. If you are on XSOAR 6, you can view incidents with large work plans from the System Diagnostics page. You can also run the getInvPlaybookMetaData command on these incidents to see which specific tasks are making the work plan so large.