IBM Security QRadar SOAR

 View Only
  • 1.  Field conflict - Functions (Integration Server and App host)

    Posted Mon July 12, 2021 07:45 AM
    Within our test environment, we have both an integration and Apphost server and have a number of custom (in house) and standard (downloaded via IBM) integrations already running on the integration server and are when trying to install new integrations via the Apphost, we are getting the following error 

    Unable to import configuration settings because of a conflict with the following Function Inputs: Exported object '__function/incident_id' type - 'NUMBER' do not match with the object in this organization. The valid types are 'TEXTAREA, TEXT'. Remove the conflicting field or change the API Name and try the import again.

    So the incident_id field, under functions has been set to text (via the install of a prior integration) and the package is expecting it to be a number.  So searching I found this article  

    Error installing fn-utilities 1.0.11 which described the issue, the fix is to delete this field, install the integration which replaces the field then test to make sure that the field changes hasn't impacted any other integration.  The problem with this is that this field is utilised by a number of functions, in our case 19 in total, so can't be removed unless I uninstall these 19 integrations.  But even if I was to do this, then recreate the field via a install on via the Apphost server, setting the field to a number.  When I reinstall the 'old' integrations, I'm going to get same error but on the integration server as the packages will be expecting a text field.  

    Has anybody found away around this?  To me there seem to be two possible solutions:  

    1) either modify each of the 'new' install packages, with the appropriate field definition. 
    2) change the field type programmatically, as you can't change it via GUI.  

    Has anybody else experienced this issue?  And how have they fixed it?  

    Any help / advice appreciated. 

    Thanks 

    Colin 




    ------------------------------
    Colin Mattholie
    ------------------------------


  • 2.  RE: Field conflict - Functions (Integration Server and App host)

    IBM Champion
    Posted Tue July 13, 2021 05:15 PM
    Colin,

    I believe we experienced a similar situation where we had multiple integrations using the same function input, although I don't quite remember how we got ourselves into the problem and how we fixed it.

    I do remember that as a result of that experience I have started to make function inputs specific to integrations / packages / apps. This eliminates most of the potential for the issue, but it does result in many similar and possibly duplicate function inputs. I don't think it puts too much strain on the system, but I could be wrong there.

    I agree with your thoughts that if you change the function input `incident_id` to a number (or whatever type aligns with the 'new' integration) then you're going to face the same issue with your other 19 integrations that leverage that same function input. So I would say possible solution 2 is out of the picture.

    Is the new app you're trying to install from the community?

    ------------------------------
    Liam Mahoney
    ------------------------------



  • 3.  RE: Field conflict - Functions (Integration Server and App host)

    Posted Tue July 13, 2021 08:19 PM
    Edited by System Thu November 11, 2021 11:15 AM
    All IBM developed apps now use the following definitions for common input fields: incident_id, artifact_id, task_id, attachment_id: https://github.com/ibmresilient/resilient-community-apps/tree/master/base_input_types. If you develop with these input fields as well, you should not have any conflicts going forward. Per Liam's post, using a unique prefix for your input fields is the best way to avoid conflicts.

    Regards,
    Mark

    ------------------------------
    Mark Scherfling
    ------------------------------



  • 4.  RE: Field conflict - Functions (Integration Server and App host)

    Posted Fri July 16, 2021 11:14 AM
    Liam and Mark, 

    Thanks for you thoughts, the majority of integrations that are using the field (with the exception of 1) are all from the App Exchange and are older versions on the Integration server, so would I be safe in assuming that if I was

    1) To remove them from the integration server,
    2) Delete the field
    3) Re-install the packages via the APPHOST, which should all have the 'correct' definition in. 

    That should fix the issue (other than recoding the one custom package we have) 

    Colin

    ------------------------------
    Colin Mattholie
    ------------------------------



  • 5.  RE: Field conflict - Functions (Integration Server and App host)

    Posted Wed July 21, 2021 09:26 AM
    For anybody else that experiences this issue (or similar) there is a far simpler 'fix', go into the Customization Settings, Functions.  Open any function and find the field you have the issue with in the input fields list (on the right hand side), edit the field, in our case incident_id and rename it by amending the API Access Name, i.e. incident_id becomes incident_id_old, you will get a warning message when you save. 

    One complete, simply recreate the field by clicked add field, and create the field as the integrations / standard definition.  So, in this case incident_id as a number.   You will then need to test all your integrations / functions that utilise this field to make sure that they still work correctly.  

    Colin

    ------------------------------
    Colin Mattholie
    ------------------------------