The "Long Description/Solution" field (OoB) is a journaled field with a 4K character limit for EACH entry. In xmatters, there is a hard stop after 2K characters.
When we send over an incident that exceeds 2K characters in the Long Description/Solution field, the following error appears in the Service-Now log:
An ERROR occured processing the REST org.apache.commons.httpclient.methods.PostMethod@f9397c ErrorCode 1 ErrorMessage Method failed: (/reapi/2014-06-01/engines/ServiceNow/group/events) with code: 400 Body {"type":"DATA_VALIDATION_ERROR","message":"There are data validation errors in the form.","errorDetails":[{"jsonPath":"properties/Long_Description","details":"Exceeded the specified maximum number of characters"}]}
The scary part is that people assume that alerting is happening, but in reality, nothing is happening and critical time is being wasted until someone goes back into the incident and see that nothing is going out.
Since this is a journaled field, there is no ability to shorten what goes over as I can't delete the earlier entries. I can't figure out a way for xMatters to accomodate more than 2K characters and can't figure out a way for Service-Now to just stop sending more than 2K characters over to xMatters in this field.
Anyone else have this problem that is using Service-Now and xMatters? If not, what did you do?
Thanks, in advance, for any assistance.
Comments
Please sign in to leave a comment.
Hey Gil!
Yea, I've seen this come up from time to time. What we can do is chop it up on the SN side, then re-assemble in the email side. (I'm assuming you don't want these sent via SMS or read over the phone! but even still, this would work).
First, we have to make an absolute max limit of how many characters you want to allow. We can't just allow anyone to paste in the entire contents of the Library of Congress and the Tax code here! Let's say 6000 characters is enough. Then since, xM can only hold 2,000 per property, we'll need 3 buckets (6000/2000 = 3) to put all the stuff in. If you want more, just take the number of characters and divide by 2000 to get the number of buckets we'll need.
So, add a new property to represent each bucket. I'd call them something sensible, like "Long_Description_1", "Long_Description_2", etc. Make sure to add them to the layout of each form you want them on.
Then, just put them next to each other in the message design page. No spaces, no new lines, nothing. That way, if we chop something in the middle of the line, it will get re-assembled without anyone noticing.
The next part is to update the code in SN to chop up the field and put it in the right buckets. So crack open that xMattersRESTHelper script include and find the part with a bunch of these "setParameters", and find the one that has your "Long_Description" field. Now, replace that one line with these 3 (or more) lines:
javascript
// substr( idx, lng ) takes the string starting at idx, and goes for lng chars
this.setParameter("Long_Description", record.Long_Description.substr( 0, 2000 ));
this.setParameter("Long_Description_1", record.Long_Description.substr( 2000, 2000 ));
this.setParameter("Long_Description_2", record.Long_Description.substr( 4000, 2000 ));
Note that the substr function will start at the first parameter and go for the number of parameters following. So, 4000, 2000 is start at the 4000th character and go for 2000 characters.
The final piece is to add a "slot" for these new fields in the REST Message. In the Integration - xMatters menu in ServiceNow, you'll see an entry near the bottom called "xMatters REST Message". Click that guy to display the REST message, and scroll down a bit to click on the "post" method. Scroll down a little there and you'll see the template for the REST Message in the "Content" field. We'll have to add in our new fields here. So look for the
"xmatters_url": "${xmatters_url}",in the properties section, near the bottom and add these three lines:"xmatters_url": "${xmatters_url}",
"Long_Description": "${Long_Description}",
"Long_Description_1": "${Long_Description_2}",
"Long_Description_2": "${Long_Description_2}"
},
"recipients": [${recipients}],
"callbacks": [${callbacks}],
"priority": "${event_priority}",
"responses": [${responses}]
}
Note that I've left in the closing } for reference. Whew. For troubleshooting, you can enable DEBUG in the Incident Notifications configuration and that will print the entire PAYLOAD to the system log in SN. If you see the Long_Description there, you are half way!