IBM QRadar SOAR

Hi Pierre,

Yes. This capability should be possible, with one consideration. 
First, I created a xlsx spreadsheet and added it as an attachment to an existing incident. I then create workflow and rule to read the attachment specifying the worksheet and column ranges similar this: "Sheet1"!A1:C2. The results returned was an array with each row returned and columns in column order):

{
'titles': ['Sheet1'],
'sheets': {
   'Sheet1': {
      'A1:C2': [
         [
           'inc1',
           2034,
           'name1'
         ],
         [
           'inc2',
           2035,
           'name2'
         ]
      ],
      '_keys': ['A1:C2']
    },
    '_keys': ['Sheet1']
  }
}

Now the only consideration is creating the new incidents. There's no off the shelf function for doing that (fn_incident_utils would be the right package for us to enhance). So that would need to be a custom function you write to perform the mapping of your excel data columns to incident fields.

Hope this helps.
Mark

Hi Pierre,

Yes. This capability should be possible, with one consideration. 
First, I created a xlsx spreadsheet and added it as an attachment to an existing incident. I then create workflow and rule to read the attachment specifying the worksheet and column ranges similar this: "Sheet1"!A1:C2. The results returned was an array with each row returned and columns in column order):

{
'titles': ['Sheet1'],
'sheets': {
   'Sheet1': {
      'A1:C2': [
         [
           'inc1',
           2034,
           'name1'
         ],
         [
           'inc2',
           2035,
           'name2'
         ]
      ],
      '_keys': ['A1:C2']
    },
    '_keys': ['Sheet1']
  }
}

Now the only consideration is creating the new incidents. There's no off the shelf function for doing that (fn_incident_utils would be the right package for us to enhance). So that would need to be a custom function you write to perform the mapping of your excel data columns to incident fields.

Hope this helps.
Mark

Hi Pierre,

Yes. This capability should be possible, with one consideration. 
First, I created a xlsx spreadsheet and added it as an attachment to an existing incident. I then create workflow and rule to read the attachment specifying the worksheet and column ranges similar this: "Sheet1"!A1:C2. The results returned was an array with each row returned and columns in column order):

{
'titles': ['Sheet1'],
'sheets': {
   'Sheet1': {
      'A1:C2': [
         [
           'inc1',
           2034,
           'name1'
         ],
         [
           'inc2',
           2035,
           'name2'
         ]
      ],
      '_keys': ['A1:C2']
    },
    '_keys': ['Sheet1']
  }
}

Now the only consideration is creating the new incidents. There's no off the shelf function for doing that (fn_incident_utils would be the right package for us to enhance). So that would need to be a custom function you write to perform the mapping of your excel data columns to incident fields.

Hope this helps.
Mark

@Mark Scherfling which function did you use to read the file in your workflow please? 

Hi Pierre,

Yes. This capability should be possible, with one consideration. 
First, I created a xlsx spreadsheet and added it as an attachment to an existing incident. I then create workflow and rule to read the attachment specifying the worksheet and column ranges similar this: "Sheet1"!A1:C2. The results returned was an array with each row returned and columns in column order):

{
'titles': ['Sheet1'],
'sheets': {
   'Sheet1': {
      'A1:C2': [
         [
           'inc1',
           2034,
           'name1'
         ],
         [
           'inc2',
           2035,
           'name2'
         ]
      ],
      '_keys': ['A1:C2']
    },
    '_keys': ['Sheet1']
  }
}

Now the only consideration is creating the new incidents. There's no off the shelf function for doing that (fn_incident_utils would be the right package for us to enhance). So that would need to be a custom function you write to perform the mapping of your excel data columns to incident fields.

Hope this helps.
Mark