Playbook task naming in subplaybooks

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Playbook task naming in subplaybooks

L2 Linker

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

Curious Fellow
7 REPLIES 7

L2 Linker

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?

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

Curious Fellow

L4 Transporter

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.

Screen Shot 2022-08-23 at 10.51.58 am.png

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

Curious Fellow

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

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
Curious Fellow

L4 Transporter

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))

Screen Shot 2022-08-31 at 10.38.23 am.png

  • 2088 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!