Store service task response in task data

[jbirddog]

Supports storing the response of a service task in task data. An optional resultVariable attribute is supported for naming the task data key. If one is not specified a variable name will be constructed based off the spec name. Tested via the front end, which after running a sample diagram to hit bamboohr:

Event_0fy5yvl: COMPLETED

{
  "current_user": {
    "id": "1",
    "username": "56457e8f-47c6-4f9f-a72b-473dea5edfeb"
  },
  "spiff__service_task_one_result": {
    "amount": "65000.00",
    "currency": "USD",
    "id": "4",
    "payRate": "65000.00 USD"
  }
}

[burnettk]

do we need to normalize this in any way? can task_spec.name include spaces or hyphens?

[jbirddog]

Good catch, looks like dashes can be in the name - I'll convert them to underscores.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[danfunk]

Looks good to me.

[danfunk]

I didn't understand why this was here, checked out the code, ran it, and it doesn't need to be here. What is it for?!?!

[danfunk]

asking about the "AssertEqual = None" - but commented on the wrong line.

[jbirddog]

In the test case setUp, the global is set to self.assertEqual so that the mock connector can assert its name and params. Didn't realize you could omit this line and the global assertEqual on line 52 would create the variable.