Playbook task naming in subplaybooks

[Antanas]

Hi!

I can't find much data on Subplaybook naming numbers - how are they being assign and when do they change?

I've run into the following issue: i had a standalone playbook with some subplaybooks inside. In the main playbook I've been referring to the results of the subplaybooks by e.g. subplaybook-167.something. It worked fine until I started to use the main playbook as a subplaybook of other playbook. I noticed then that the subplaybook name numbers in the new playbook are different and that kills my logic, e.g. subplaybook-167 became subplaybook-54. What is the best approach to overcome this? Is there a way to hard code subplaybook name and refer to it regardless of whether it is run as standalone or part of other playbook?

Thanks,

Antanas

[nkazinets]

Hey @Antanas,

The sub-playbook number usually represents the sub-playbook task ID in its' parent playbook. So theoretically it should stay the same as long as no other changes are made to it that change the task's number (like in your example, adding the parent playbook to be a sub-playbook in another playbook).

However, the above logic isn't 100% guaranteed, and can be different in some cases - so I would highly advise avoiding relying on this numbering. Instead, you can use the playbook outputs parameters so you won't have to use the subplaybook-xx context path when needing to refer to any data saved in that sub-playbook.

I don't know what's your use case here, but was there any specific issue or reason you chose using subplaybook-167 instead of the playbook outputs?

[Antanas]

Thank you for your answer @nkazinets 

The reason I'm using subplaybook numbers is that I saw this commonly used by Palo Alto PS guys who inititially developed the playbooks in our environment. I understand the workaround now and will rebuild the ones in question. 

Thanks again,

Antanas

[jfernandes1]

Hi @Antanas,

You can use the key ${currentPlaybookID} in the sub-playbook to grab the id of the playbook task. You can send this back to the parent playbooks as an output if you need to re-use it later. Refer to the screenshot below.

[Antanas]

Hi @jfernandes1 ,

This is very promising. I encountered one issue though. I managed to dynamically set a full subplaybook name which is stored on a key. However when I try to pass the value of that key into a function that requires an array - it fails.

E.g. I have set a key SubplaybookKey which after execution is dynamically set to "subplaybook-28.LogRhythm.Search.Results"

When I pass the SubplaybookKey into ExportToCsv automation that requires an array - it fails as it literarily receives string "subplaybook-28.LogRhythm.Search.Results". Is there an easy way to force this value to be treated as the data behind the key?

Thanks,

Antanas

[nkazinets]

Hi @Antanas,

How are you passing the SubplaybookKey to the export command?

When using a context key with the intent of getting the data behind the key, we need to wrap it with ${} - this will get the data, instead of the key name (which is useful in other scenarios)

So in your case, the command would look like so:

!ExportToCSV csvArray=${subplaybook-28.LogRhythm.Search.Results} fileName=test.csv

[Antanas]

Hi @nkazinets ,

The issue is that i do not know the subplaybook name beforehand. The name is dynamically built during execution and is stored under the key SubplaybookKey. If I try something like that - it wouldnt work:

!ExportToCSV csvArray=${${SubplaybookKey}} fileName=test.csv

[jfernandes1]

Hi @Antanas, that's an excellent question. In my particular use case, I passed the collected playbook IDs to the deleteContext command. This command only required the keys to be specified. Your use case requires "double replacement".

1. Replace with the dynamic sub-playbook IDs 

2. Replace with the key value

I don't think this is possible without a custom automation. It would be fairly simple though. I've written some code below to help with this. You can perform the first replacement while passing the value to the command. The automation will perform the second replacement. 

data = demisto.args()['key']
incident  = demisto.incidents()[0]
incident.update(demisto.context())
if not incident.get(data):
    return_error("Key not found")
else:
    demisto.results(incident.get(data))