Jump to content

Steve G

Hornbill Developer
  • Posts

    733
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by Steve G

  1. What's Changed Microsoft Teams iBridge integration - updated data source for Team searching to only return non-Security type groups, and allow typing to search for Teams.
  2. @Steven Cotterell Those utility operations should actually not be premium on your instance, they are free to use - I just had this switched on in my development instance from some previous testing... I've just updated the datasource which is used to return the Teams as part of the Post To Channel operation, so that it's now a search box rather than a drop-down select box, and it'll also now not return security groups (which it was doing previously). Give it 5 mins for the content pack to get to your instance, then try searching with the first few letters of the Team group display name... Note - this will only do a "starts with..." search on the display name, as the MS API we're using to return groups doesn't support "contains" as an operator. Let me know how you get on. Cheers, Steve
  3. @Steven Cotterell That's a good point actually, they probably shouldn't be premium. Let me find out why they have the flag and I'll get back to you shortly. The IFTTT one isn't marked as premium... Cheers, Steve
  4. What's Changed HTTP Request iBridge utilities - updated the Body input parameter to be a multiline text entry field, rather than a single-line input.
  5. @Steven Cotterell I've just tested this and it does indeed work. I created a webhook against one of my teams, then posted to it using the HTTP Request operation via a workflow and Service Manager request, and this was the result: The node was configured as so: And the content of the body was: { "@type": "MessageCard", "@context": "http://schema.org/extensions", "themeColor": "0076D7", "summary": "Hornbill Request Logged: &[global["inputParams"]["requestId"]]", "sections": [{ "activityTitle": "![TestImage](https://47a92947.ngrok.io/Content/Images/default.png)New &[global["flowcode"]["requestType"]] for &[global["flowcode"]["customer"]]", "activitySubtitle": "&[global["flowcode"]["summary"]]", "activityImage": "https://teamsnodesample.azurewebsites.net/static/img/image5.png", "facts": [ { "name": "Request Reference", "value": "&[global["inputParams"]["requestId"]]" }, { "name": "Assigned to", "value": "&[global["flowcode"]["owner"]]" }, { "name": "Status", "value": "&[global["flowcode"]["status"]]" }], "markdown": true }] } Which was based on Microsofts example here: https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/connectors/connectors-using It uses no authentication, so you just need to make sure you keep the webhook URL private, or anyone could post to it Cheers, Steve
  6. @Steven Cotterell As long as the webhook doesn't need authentication, or supports basic auth, then you could use one of the HTTP Request operations listed under Utilities > Experimental in the Cloud Automation node to send "stuff" to the webhook... I've not tried it, but there's no reason why it wouldn't work Either that, or you could script it with PowerShell when we release Hornbill ITOM Cheers, Steve
  7. @Steven Cotterell Yeah I think that, because the API is in beta, Microsoft have just set the rights to be "something that an admin would have" - as the permission really doesn't make sense here. I expect that when this moves out of beta and in to production it will have a Graph permission all of it's own, so you'll be able to create a limited account just for this...
  8. @Steven Cotterell No worries, let me know how you get on. Just to note about the Teams integration too - the API we're using to post to a channel is actually still in Beta with Microsoft (we wouldnt usually implement integrations with APIs that are in beta, but we had another customer who really needed to use it...) - so it is liable to change when it moves in to production. So if this actually does stop working at some point, then that will be why and we'll need to update the integration to cater for its status change. As per the notes against the operation: I am checking the API status regularly, so you may not even see an outage when it moves in to production, but just one to be aware of... Cheers, Steve
  9. @Steven Cotterell From what I remember, refresh tokens in Office 365 expire after 14 days of inactivity - but that can be set to between 10 minutes and 90 days (depending on your O365 config). So I expect this issue is because the key was created a couple of months ago and the token has not been used... The fix should be straightforward - if you go back in to the key in keysafe, hit the Revoke Access button, then click Connect and re-log in to the Microsoft account that needs to perform the operation, you should get a working token and refresh token back. Then as long as you use the Teams integration once every 14 days (or more frequently than whatever the O365 refresh token expiry is set to for your organisation), then you should never have to revoke/reconnect your key again as it's all handled in the background. Cheers, Steve
  10. @Steven Cotterell It appears we posted at the same time It looks like your access token is invalid, and we've not been able to get a new one using the refresh token. This should all happen automatically in the background - unless the refresh token had expired between uses... When was this keysafe entry created, and how often is it used? Thanks, Steve
  11. Hi @Steven Cotterell, The "check console" message is referring to the console within your browser - any error messages for this will be listed in there. If you're a Chrome user, the shortcut to get there is Ctrl+Shift+J (or Cmd+Shift+J on Mac). What you should actually see, if the Keysafe entry has a valid token that has access to retrieve a list of Teams, is: Let me know what is being written to your browser console, and I'll hopefully be able to point you in the right direction. Cheers, Steve
  12. Hi @nasimg, A couple of AD packages are going to be released alongside ITOM, here's a sneak-peek at the operations within the AD User package Regarding the API call to raise a Service Request, you need to follow the instructions in that ServiceNow document, but for the details: Enter URL: The API endpoint for your instance (replacing yourinstanceid with the case-sensitive ID of your Hornbill instance): https://eurapi.hornbill.com/yourinstanceid/xmlmc/apps/com.hornbill.servicemanager/ServiceRequests?method=logServiceRequest Method: POST Headers (replacing yourapikeygoeshere with an API Key generated against a user within Hornbill, to authenticate the API call): Content-Type : text/xmlmc Authorization : ESP-APIKEY yourapikeygoeshere Body - this is the payload of the API call, in XML: <methodCall service="apps/com.hornbill.servicemanager/ServiceRequests" method="logServiceRequest"> <params> <summary>New onboarding request for {{new_hire}}</summary> <description>New onboarding request for {{new_hire}}</description> <teamId>TEAMID/GOES/HERE</teamId> <externalRefNumber>{{externalid}}</externalRefNumber> </params> </methodCall> And that's pretty much all there is to it... So that will log a new Service Request on your Hornbill instance on the back of a webhook event in Enboarder, populating the summary, description and external reference number fields, as well as assigning the SR to the team specified in the teamId element. To add additional details to the request being logged (service, catalog item, priority, workflow etc) this can be done by adding to the XML payload, as per the API documentation here: https://api.hornbill.com/apps/com.hornbill.servicemanager/ServiceRequests?op=logServiceRequest Let me know if you need any more information. Cheers, Steve
  13. Hi @nasimg, I've had a look at that document, and it looks like a pretty basic integration - Enboarder just logs new tickets on ServiceNow as part of their Webhooks functionality. Is this the same integration you're after - so an action in Enboarder would log a Service Request in Hornbill Service Manager? If so, then I could help with populating the webhook API call... Cheers, Steve
  14. @Jeremy Yeah that makes sense, I've added a new output parameter to both the Sheets operations that will contain the row number that has been updated/appended. I've just released them to live, so your instance should have the updates in the next 5 minutes. Let me know how you get on with this. Cheers, Steve
  15. What's Changed Google Sheets iBridge integrations - new output parameter to pass back the number of the row that has been updated/appended.
  16. Hi @Jeremy, As long as you know the row number, and the column you want to start stiring from, then this is possible with the Google > Sheets > Update operation. See ther Row and Starting Column input parameters here: Cheers, Steve
  17. Hi @Dan Munns, Yeah you should be able to pick that out of the request description and tag on to the end of the request summary in the BPM workflow without too much of a headache. If you have 2 nodes in your workflow, one to grab the request details, and one to update the summary: And the Summary field is populated with: &[global["flowcode"]["summary"]] : &[global["flowcode"]["description"].match(/(WKS[0-9]{4})/) ? global["flowcode"]["description"].match(/(WKS[0-9]{4})/)[1] : "Not Found"] This will overwrite the summary with itself, followed by a colon, and then whatever has been matched by your regular expression from the description field. In my example, I'm looking for WKS followed by 4 numeric digits: You'll notice that the regex is being done twice - this is just a bit of ternary logic, to make sure that the workflow doesn't fail if the regex doesn't match anything. Cheers, Steve
  18. Hi @Andytaylor93, The Hornbill API requires datetimes to be provided in UTC, and that is how they are stored in the database. When viewing request data (vi the main app), these UTC datetimes are displayed in the session users local timezone (BST in your case). Is the issue actually with Jira providing the scheduled datetime in your local timezone (BST) rather than UTC? Cheers, Steve
  19. Hi @dwalby, I've had a cursory look at their API documentation and we should be able to implement some iBridge integrations to PivotalTracker easily enough, as they have RESTful APIs with pretty basic token authentication. What specific integrations were you thinking about? Giving their endpoint list a once-over may help for you to work out what we can do compared to what you need https://www.pivotaltracker.com/help/api/rest/v5#Endpoints Cheers, Steve
  20. Whats New New Hornbill Service Manager integrations - Log New Change Request; Log New Known Error; Log New Problem; Log New Release. Whats Changed Hornbill Service Manager integrations, added new exception handling - Log New Incident; Log New Service Request. Whats Fixed iBridge integration - HTTP Request - Basic Auth. Fixed typo in output parameters display name.
  21. Just to close this topic off, v1.8.0 of the asset import tool has fixed this issue. The latest version of the tool can be downloaded from here: https://github.com/hornbill/goDBAssetImport/releases/latest Steve
  22. What's Changed Password Generator utility - added support to exclude specific characters from the generated password
  23. Hi @Jeremy I've added support for the above in to the password generator utility, it's been released so should be on your instance in the next few minutes. Config as below. Cheers, Steve
  24. Hi @MikeW, I've just given your config a whirl through v1.2.0 of the import tool (with a number of non-visible characters stripped out - I presume these were added by this forum though), and have been unable to replicate your issue Could you re-run the tool with the -dryrun=true command line parameter, and post the log file output so I can take a look, please? Thanks, Steve
  25. Hi @Paul Alexander, The first message I'm not sure about to be honest, your Azure admin may be able to help with that. The second message suggests that the keysafe key that the integration node is configured against has been deleted? Could you check the integration node in your workflow and make sure it's got an active key defined against it? Cheers, Steve
×
×
  • Create New...