Attachment Management

[Rick-2CA]

I've put together some functions for attachment management via the ServiceNow Attachment API. We're looking at the following functions:

• Get-ServiceNowAttachment - Lists attachments associated with a ticket number in a specified table. Allows for filtering attachments by name making it more useful for piping into Remove or Save.
• Add-ServiceNowAttachment - Adds an attachment associated with a ticket number in a specified table.
• Remove-ServiceNowAttachment - Removes an attachment by its sys_id. Easiest to use the Get function to pipe into Remove.
• Save-ServiceNowAttachment - Saves an attachment by its sys_id to destination path.

Since the unique requirement is the sys_id ServiceNow allows for attaching more than one file with the same name. There isn't a great way to update an attachment without removing and then adding it back.

Anyone else have any input as to how they deal with attachments that I should consider when I go to integrate and test these?

[gdbarron]

Hey there, started looking at your project and thought I would try and contribute.

You could provide update functionality by combining add and remove. You still need the separate add/remove functions, just adds to ease of use. Perhaps provide a -allowclobber or similar parameter to deal with multiple files that already exist with the same name when someone tries to update (you'd need to allow removal by name as well as sys_id).

I'm just getting into the SN API and probably just my lack of knowledge, but not sure I understand the difference between add and save. In fact, looking at the rest api, I don't see a save option. Is it a 2 step process, add and then save?

[Rick-2CA]

We could do an Update command that simply removes and adds. I'm afraid to play with anything by name though. I ran across a ticket in my org this week that had 10+ files with the same name attached. No idea why. One would hope anyone doing an update would only have one of each name, but I'd hate to blow away someone's data by trying to work off of name when the back end relies upon sys_id and the accuracy that provides.

If you look here the top two GET calls get metadata. The third GET call gets the binary file - or the bits necessary to create the attachment. The Save function uses that third option to save the file locally (download).

I hope you like the project and can contribute. Thanks for the reply.

[gdbarron]

That was one of the use cases I was thinking of. Someone mistakenly attaches multiple files with the same name and wants to remove them all. We could ensure we use confirmations and alert them to how many they will be removing before we do so. I understand your hesitation to provide this. I definitely get that sys_id is unique, but people will recognize a file by name, not sys_id so thought this might be better.

Another option might be to provide an All parameter to the remove function and of course provide the same confirmation.

Thanks for the link, makes sense now. I thought we were adding the attachment to the ticket, kind of like queuing it up, and then saving. Maybe instead of Get-ServiceNowAttachment call it Get-ServiceNowAttachmentDetail and instead of Save-ServiceNowAttachment calll it Get-ServiceNowAttachment with an optional file path parameter? This would give someone the ability to either get the binary response and perform additional actions or save it to a file.

[Rick-2CA]

I chatted with someone in the PowerShell Slack today who suggested Read-ServiceNowAttachent to get the details and Get-ServiceNowAttachment to perform the download. That coincides with the logic written in Get vs Read, but I hesitate to take that route. The Read verb is not often used and doing Read | Get strikes me as less clear than the other two options.

Right this minute I'm leaning towards Get-ServiceNowAttachmentDetail and Get-ServiceNowAttachment. Going with the idea that Save is for a state, not for a download.

[gdbarron]

I like the link, great info, thanks.

[BristleBeard]

Do you have a timeframe that you may roll this feature out? I'm actually researching how to add an attachment now, so it'd be nice to not reinvent the wheel! :)

[Rick-2CA]

@BristleBeard - No time frame I'd want to quote. If you'd like to play with the functions I've set them up for download.

Any feedback you have would be appreciated if you use the files.

[Rick-2CA]

PR #78 has been submitted for attachment management. Would appreciate a review of the changes if anyone is so inclined. There are changes not included in the download I linked above for BristleBeard.

[Rick-2CA]

Published to prod in #79