Error occurred while processing incomingData. Error: Generated alias is blank.

[Michael Gaston]

We just had to reinstall the OpsGenie plugin into our ServiceNow instances. Currently we have it activated in dev with the API key. When I try to generate an alert in OpsGenie from ServiceNow, I'm getting the error in the logs - "Error occurred while processing incomingData. Error: Generated alias is blank". I can see in the business rules that the incident number should be mapping to this field but its not coming over. I also tried using the number as the source field in the transform map for both the Alias and the Alert ID, but that's not working either. 

[John M]

Hi @Michael Gaston

I would suggest checking the ServiceNow integration's advanced settings in Opsgenie. Check to see if the value being used for the alias field is processing correctly. It sounds like the dynamic value you have set may be parsing the alias to a blank value. 

[Michael Gaston]

This is what we have, I have tried replacing alias with the incident number as well but no luck. 

[John M]

@Michael Gaston what are the debug logs showing for the 'alias' value in the raw payload?

[Michael Gaston]

Pretty much everything is coming through as null even though those fields are also mapped, specifically category and priority, but incident number does come through. Alias is blank. I tried to put the incident number for alias on the OpsGenie side and the log still shows it coming through blank. 

[John M]

@Michael Gaston What version of SNow are you on? It looks like we have a FR to make Opsgenie compatible with the latest Utah version:

https://jira.atlassian.com/browse/OPSGENIE-1391

I'm wondering if that is causing the issue you're seeing. 

[Michael Gaston]

It looks like we are on Tokyo. I checked our Prod and Dev instance they both show this. 

[John M]

It looks like Opsgenie should be compatible with the Tokyo release. Typically when values are parsed to null there is a mismatch with the formatting Opsgenie is expecting and what it's actually receiving. So the issue may point to a configuration issue on ServiceNow. Can you have ServiceNow support verify your config on their end?

https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-servicenow/

You can also open an Opsgenie ticket or chat with us if you are on the Essentials plan or higher so we can access your instance to look into this more. 

[Michael Gaston]

I appreciate your assistance on this, I wanted to note that when i look at the logs, after "received integration request", it runs the "add work note" rule. Should this not be running the "Create Alert" rule first? Is that why I'm getting a no alias error, because its running a rule that needs an alert to have already been created? 

[John M]

If the add note action is coming in before an alert is created that would cause an error since there is no alert yet to add the note to.

The alias should be based on what's being sent from SNow, so it should still have a value from the SNow ticket even if an alert doesn't exist yet in Opsgenie.

It could be that the filters on the 'create' action aren't matching the payload. I would suggest searching "INC0023119" (with quotes) in the debug logs to see if the 'create alert' payload was discarded. 

[Michael Gaston]

I'm not sure how to tell if its been discarded, but here is also shows the alias as not having a value. 

[John M]

@Michael Gaston That is the raw payload before it is processed by Opsgenie. When the alias is blank Opsgenie will assign a default alias. But if that is happening, none of your other actions after the initial 'create alert' will work since the alias is being assigned by Opsgenie and not by Service Now. If the payload is being discarded there will be a separate warning log that states the reason.

[Michael Gaston]

I went ahead and updated the api key to be set in our test environment to see if it was an issue caused in our dev environment, and i'm no longer having an issue with the alias coming over. After running more tests it looks like the issue is caused by the "when to run" setting on the create alert business rule. By default this was not set to anything in test so the alerts were coming through correctly. However, when I try to adjust this to only create when an alert is P1 or 2, or if I say only run when a major incident is proposed, it no longer flows through correctly. It does create the alert but sets most of the values to null including the alias like before.

 

[John M]

It sounds like it could possibly be a bug on the ServiceNow side. I just don't know whether they are sending null values or if we are interpreting them as null because the business rule filter is doing something to change the formatting that Opsgenie is expecting. Is ServiceNow logging able to confirm what is being sent to Opsgenie?

[Michael Gaston]

Thanks for your help on this, here is where we are now: 

With no filter set on the when to run tab, in the opsgenie create alert tab, the alert comes through with all the information that's listed to be mapped. 

When I specify when to run, that's when data is showing in the opsgenie alert as null. In the Snow logs I can see that some of the fields do have the data needed, but others do not. I've highlighted these fields in the screenshots provided.  

The first image shows the alert in opsgenie with the business rule filter applied, its applying a value i cannot find in the ServiceNow for the alias. I can also see that the category is blank when it does show a value for this field in the log.

The SNOW log shows that there's a value for the category field, but this does not come over to the opsgenie alert. The value for the alias in the opsgenie alert is no where to be found in the log, so i'm not sure where that is coming from. 

It seems that if I apply a filter on when to run, that is what is causing the issue. This was not the case before we did a clone over and opsgenie got removed because it was not yet in our production instance. 



The corresponding OpsGenie log for this alert shows these values as null.  

[John M]

The alias is required so if it's blank Opsgenie will generate an alias, which will be the same as the alert ID. So that part is expected.

For this issue in general though, I think that having access to your account logs would assist in the troubleshooting process. You can open a support ticket here so we can assist you:

https://support.atlassian.com/contact/#/