Whilst we considered adding variables like the incoming mapper id in the config map, we came to the conclusion that is was more logical to add it as a separate variable inside the resource.
In terms of testing of the code, we tested the creating, updating and destruction of integration instance resources with and without the incoming mapper id.
Good thing to be aware of, is that XSOAR lacks input validation in the API. This means that you can provide invalid incoming mapper id's, but you can also provide fields that XSOAR says it requires - whilst it does not return errors if you don't provide it. We've already started a conversation about this with our Palo Alto contacts, as we think this should be fixed in XSOAR - and we should not be required to add such validation into the Terraform provider.
Whilst we considered adding variables like the incoming mapper id in the config map, we came to the conclusion that is was more logical to add it as a separate variable inside the resource.
In terms of testing of the code, we tested the creating, updating and destruction of integration instance resources with and without the incoming mapper id.
Good thing to be aware of, is that XSOAR lacks input validation in the API. This means that you can provide invalid incoming mapper id's, but you can also provide fields that XSOAR says it requires - whilst it does not return errors if you don't provide it. We've already started a conversation about this with our Palo Alto contacts, as we think this should be fixed in XSOAR - and we should not be required to add such validation into the Terraform provider.