William Weiszbrod

I was working on doing some API testing on the Demo site but it seems the login no longer works, has the demo site been depreciated or someone break something? Be great to access it again as it helps me understand if I am doing something wrong with my API tests within my Hornbill instance or if we just messed something up in our Hornbill instance so the API doesn't behave as expected.

@SamS Are you referencing this article?: https://wiki.hornbill.com/index.php?title=XMLMC_API_File_Upload_Sample if so then I have a PowerShell script using the concepts based on the article, I was hoping to add the file when calling "Entity API / logIncident", it's implied it's possible based on the parameters listed here: https://docs.hornbill.com/servicemanager-api-api/entities/incidents/espflowcodeentityoperation/content/logincident Now if it turns out this isn't possible I do at least have my current working method, I just wanted to limit my API calls from 3 to 2. Currently I POST for the ticket creation, I PUT for the file upload, and end with another POST to attach the uploaded file to the created ticket. By end of year we will be creating 50+ tickets for contract extensions and need to track each person by a ticket, instead of manually creating each one be great to just automate the creation of them all. I just want to be kind to the API and limit the number of actions.

fun fact you can also escape the character in power automate by just doubling so you could @@ instead.

I'm hoping this is something easy I'm overlooking when it comes to attaching a file to logging a ticket via the API, per the "Entity API / LogIncident" it states as an input "fileName" as string (should mention array(string) in my opinion) with a description of "The full path for the file(s) to be attached." Based on this I would assume the path to the WebDav session location, or is this a different location? I've tried a couple of different methods for the file reference, in all cases the ticket is created without issue and no returned errors or warnings but no attachment. I did manage to attach a file but required another API call via "attachFileFromSession" which did work, and I can go this route if it's not possible to attach the file at time of ticket creation. Here is the code I used as of my last test, much appreciated for any assistance. # CREATE A TICKET $FileAttachment = @{ filename = "/session/Ab.pdf" description = "This is a file" visibility = "TrustedGuest" } $FJson = ($FileAttachment | ConvertTo-Json) $Endpoint = "https://mdh-p01-api.hornbill.com/demo/xmlmc/apps/com.hornbill.servicemanager/Requests" $Body = @{ "@service" = "apps/com.hornbill.servicemanager/Incidents" "@method" = "logIncident" params = @{ summary = "Iphone 17 is bat shit crazy" #description = "" requestType = "Incident" # customerId = "xs:string" # customerType = "xs:string" # ownerId = "xs:string" # teamId = "xs:string" # status = "xs:string" # priorityId = "xs:string" # categoryId = ""xs:string"" # categoryName = "xs:string" # image = "xs:string" # sourceType = "xs:string" # sourceId = "xs:string" # assetId = "xs:string" # impact = "xs:string" # urgencyId = "xs:string" serviceId = "15" # questions = $Qjson # resolutionDetails = "xs:string" fileName = @($Fjson) # siteId = "xs:string" # siteName = "xs:string" # catalogId = "xs:string" # catalogName = "xs:string" # externalRefNumber = "xs:string" bpmName = "mobile-issue" # questionFieldMap = # senderDetails = "xs:string" # ccDetails = "xs:string" # connectionMap = "xs:string" # connectionUpdateTimeline = "xs:boolean" # connectionTimelineVisibility = "xs:string" # employeeAssignmentUserId = "xs:string" # employeeAssignmentNumber = "xs:string" } } $Header = @{ "Authorization" = "ESP-APIKEY XXXXXXXXXXXXXXXXXXXXX" } $Parameters = @{ Method = "POST" Uri = $Endpoint Headers = $Header Body = ($Body | ConvertTo-Json) ContentType = "application/json" } $CaptureTicket = Invoke-RestMethod @Parameters $CaptureTicket.params.requestId

Last update as apparently uploading with the above code "works" as in an object with the name exists the PDF was in fact corrupted after upload. I got some wild file sizes when uploading, tried a couple of different methods to get it to play nice but in the end I had to convert the whole file into a bitstream and then upload that stream to prevent the corruption. For the sake of completeness here is what I did for anyone who needs a method to upload files via he API without corruption using PowerShell, note this works for PDF but most likely works for any file type as the file is a bit stream. # UPLOAD ATTACHMENTS $Endpoint = "[your instance]/dav/session/Ad.pdf" $fileBytes = [System.IO.File]::ReadAllBytes("[full path to local file]") $file = New-Object System.IO.MemoryStream $file.Write($fileBytes, 0, $fileBytes.Length) $file.Seek(0, [System.IO.SeekOrigin]::Begin) | Out-Null $Header = @{ "Authorization" = "ESP-APIKEY [your api key]" } $Parameters = @{ Method = "PUT" Uri = $Endpoint Headers = $Header Body = $File ContentType = "application/pdf" StatusCodeVariable = "StatusCode" } $CaptureUpload = Invoke-RestMethod @Parameters $StatusCode # Will return 200 when succesful

Thanks again! I was confused as apparently Invoke-RestMethod doesn't return the status code, it only returns messages placed in the body of the return message. Snagging the status code from Invoke-RestMethod you have to specify a variable in the parameters, then you can query that variable to know the status of the response. Just in case anyone else runs across this here is a fully functional PowerShell Script for uploading via the API with the response parameter set. # UPLOAD ATTACHMENTS $Endpoint = "(your instance here)/dav/session/(name of file with extension)" $File = "[(local file full path name)]" $Header = @{ "Authorization" = "ESP-APIKEY XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } $Parameters = @{ Method = "PUT" Uri = $Endpoint Headers = $Header Body = $File ContentType = "application/pdf" #change this to match the file type StatusCodeVariable = "StatusCode" #This is the variable for the status code } $Capture = Invoke-RestMethod @Parameters $StatusCode #if succesful this will return 200

Excellent, I didn't get a 404. Should I get a return of nothing if it works? I was hoping it would return some kind of confirmation. the PDF is just me smashing my keyboard against my head, so it's just a bunch of gibberish.

Hoping I could get an example of a properly formatted PowerShell script that would upload a file via the API, I have been doing API testing via the Hornbill demo site and so far it's being going great. The only hitch I have had is demoing a file upload via the API, I was attempting to upload a tiny PDF file (48KB) but ended up with a 404. I could be doing it right but maybe the demo site doesn't have /dav/session available? Any assistance in making sure I'm doing it right would be great, I keep pouring over the information in the wiki, documentation library and this forum but feel like I have missed something that would make it work. Note: I have not uploaded to a WebDav location before so the process is new in general to me. $Endpoint = "https://mdh-p01-api.hornbill.com/demo/dav/session/Ad.pdf" $File = "C:\Temp\Ad.pdf" $Header = @{ "Authorization" = "ESP-APIKEY XXXXXXXXXXXXXXXXXXXXXXXX" } $Parameters = @{ Method = "POST" Uri = $Endpoint Headers = $Header Body = $File ContentType = "application/pdf" }

Thanks for confirming. While I will end up doing as you have pointed out, the idea of having auto tasks interact with the function of a one time request just seems really helpful. Maybe it's a perspective thing, from my point of view I see it like this: why have a ticket exist to remind me of something? When I could have something just create a ticket at the time of the action, this is the kind of thought process that comes from scheduling on a calendar vs flagging an email.

I am hoping this is a thing that can be done and I have just been over looking it: Can one setup an auto task that is able to create a one time scheduled request? Reason for this: I am looking to better enable loaning equipment, having the ability to create a scheduled request for the equipment return would improve the probability of getting loaned equipment back from end users. How I see the workflow: 1. A request for borrowing equipment is opened 2. We capture the time frame they wish to borrow the equipment 3. The tech assigns and links the hardware in the ticket. 4. Upon the resolution of the ticket an auto task kicks off that pulls the end borrow date and the linked asset and creates the one time scheduled request to reclaim the equipment. If this is not a feature this seems like it would be a great expansion on the auto task feature.

So my company is working to a go live, at this time it appears that we decided that we only needed 10 licenses. However what will this do when we go actually live? does this mean only 10 can be logged in at anytime? Thanks for any assistance.

Hi James Ainsworth Good to know and was easy enough to test, however this does raise some concerns. As an example say I set my language to Chinese and created a progressive capture with a custom form, I was able to determine that my selected language dictates the custom forms language. This means only people with Chinese will see the labels I made unless I happen to think ahead and change the language to English(British), which seems a bit convoluted though as a work around I could just make sure everyone who can make progressive captures is set to English(British). In any event I appreciate all your help in clearing this up! Thanks!

Hi James Ainsworth Thanks for the information, so I updated my language to English(Americas) and sure enough everything started coming up, i'm unsure why this would make a difference. Based on what I'm seeing now I have to make a specific label for each language? Can I not set a default label and if needed change it to language specific? We have multiple languages that could be selected and it would be rather time consuming initially to setup each region with its specific label. I appreciate your assistance.

Hello, We just went live today with our demo site and we have an issue with custom form fields not updating the label name, we are able to confirm in the Hornbill test site that we can change the label name and it reflects it in the progressive capture. Below is a screen capture showing the label being test3 the immediate following image is a newly opened and logged in browser navigating through the progressive capture, as seen in the second screen shot it still shows the generic label information. As a side note we can update the Description of the field without any issue. Any ideas? am I missing something? Thanks!

Hello, I had a question as I haven't fully figured out if this is something even possible in the system. Based on what I have found in the Wiki it looks like it is but without a personal test site yet (which we are work to for our switch on) I can't verify. Anyway the question regards emails and how they interact with a ticket, so say I send an email from the ticket: When the user reply's to this email I just sent where does it go? Does it automatically link back to the ticket (preferred method) or does it just generically drop into one of the mailboxes configured? If the latter happens does this mean I have to manually associate my ticket to the email? This is assuming I am not using the rule configuration found on the wiki: So assuming I need to have a rule in place in order to have the emails auto attach to the tickets, what limitations will I run into? does this mean only incidents and service requests can be configured like this? What about change requests? Thanks and let me know if I need to clarify anything, I tried this in the Hornbill Demo site but it doesn't appear the email box has the ability to receive any emails based on the "inbound mail service".