Updates back from Jira Cloud into Service Manager

[Berto2002]

Has anyone please worked out the Jira to Service Manager data push?

For example, having updates or status changes on the Jira Issue pushed back via API into the (originating) Service Manager RequestID?

@Sam P or @Martyn Houghton or @Keith Stevenson or @Adith or @HHH? I see you have all been part of the Jira Cloud forum posts.

[Sam P]

@Berto2002 no sorry, we grab the Jira issue ID from the Create node and thats it

[SamS]

@Berto2002, I'd look at the JIRA side on what is possible there:

https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Send-web-request

[Berto2002]

@SamS we can't trigger based on Service Manager can we? So if an update is made by a Customer, we can't listen for that and send the data to Jira?

[Gareth Cantrell]

@Berto2002 In Jira Cloud, you can create an automation rule that is basically an HTTP end point which can accept JSON requests.

In Hornbill, you can then setup a webhook which fires when a request is updated and push that to the end point of your Jira automation rule.

To get the content of the customer update would require two more web request actions from Jira to Hornbill- one to retrieve the activity stream access token and then a 2nd request to retrieve the activity stream identified in the initial webhook request, and these would be subsequent actions on the same Jira automation rule.

[Gareth Cantrell]

@Berto2002 I mocked up a quick Jira automation rule which could achieve what you're looking for and an example of how you'd setup the corresponding webhook in Hornbill:

[Martyn Houghton]

@Berto2002

We were looking at using the email updates from JIRA to trigger the update being applied to the request and at the same time BPM checking the status of the linked JIRA using the existing iBridge methods.

However, we cannot progress this approach as it is not currently possible to control the visibility of the email updates using the Auto Responder and we do not want internal development updates/comments appearing on the customer-viewable timeline.

Cheers

Martyn

 

 

[Berto2002]

Thanks both I will review with my infra guy and see what we can get going

[SamS]

@Berto2002, Webhooks would probably be the way to go - the way @Gareth Cantrell outlines.

A mention has to go out about the "Trigger Expression" - I would urge you to use that, so that not ALL updates to ALL requests trigger the webhook into Jira.

[Berto2002]

@Gareth Cantrell that was a very helpful mock-up and I think there might be enough there for us to test it.

Am I asking too much to ask you for the equivalent for updates the other way? I.e. pushing/pulling a customer update on a Hornbill Request into the JIRA Cloud Issue.

@SamS I found this link for Webhooks (Webhooks (hornbill.com)) but I could not find a reference in there for how triggers work and as a result I can't write the trigger to test using the third part webhook system. Can you give any pointers to either docs or more info on what is required in there please or an example expression for a use case so we get the idea?

The two use cases are:

1. A Customer updates a Hornbill Request and we want that 'sent' to Jira Cloud (this would only happen for Requests where Custom 33 had a JIRA Cloud issue reference)
2. A technician updates a JIRA Cloud Issue with a 'customer' type update and we want that added to the Hornbill Request timeline with a Customer visibility

Many thanks in advance.

[SamS]

@Berto2002you literally have to trigger the Hornbill webhook by doing the action.

If I'm not mistaken, there is a little explanation on how the expressions work on the page itself, just hit the question mark icon. The expression is SQL-ish and it should give you predictive text style assistance.

Just type in the word "record" and you should see a few suggestions. record.h_field_name will give you the contents of that field to check (for assets you would have different fields that for requests etc).

[Gareth Cantrell]

@Berto2002 the mockup I shared above will update the Jira Cloud issue when a comment is added to a Hornbill request.

Commenting on a Hornbill request from Jira is quite straightforward and can be achieved with a simple Jira automation.

I have reworked the mockup and tested both in my Jira and Hornbill instances and the basic steps for each are as follows (with images attached for clarification):

Comment Jira Issue on Hornbill update:

• Create a Jira automation to receive and process a webhook event from Hornbill (1a, 1b)
• Get an activity stream access token from Hornbill (1c)
• Use the access token to retrieve the activity record from Hornbill (1d)
• If the activity is an "Update", add the content to Jira issue as a comment.
• Create a Hornbill webhook that calls the URL of your Jira automation when a Requests:Updated event occurs (1e)

Comment Hornbill on Jira update:

• Create a Jira automation that triggers when a comment is added (2a)
• Call Hornbill to update the request timeline with the comment (2b)

 

These screenshots assume you have a Jira custom field, Hornbill Request ID that stores the Hornbill request ID and a Hornbill custom field, h_custom_33 that stores the Jira issue key

1a 

1b

1c

1d

1e

2a

2b

[Berto2002]

Wow. Many thanks. This is also a great contribution for others to read in future.

Looking forward to meeting you at HUG24 in March; I gather you're on the bill @Gareth Cantrell

[Berto2002]

We've tried the set-up as @Gareth Cantrell described and it's not working, sadly. We're going to run through thing again in another session next week. A few observations include. The only issue that through an error was

Custom 33 is not recognised in the webhook spec so we altered to custom d; but it still didn't work. @SamS is there a reason why custom 31 + are not included in webhooks?

Our webhook:

[Gareth Cantrell]

@Berto2002 I may have introduced a typo when I modified my test setup for the screenshot. The trigger expression should probably read:

record.h_custom_x LIKE 'ABC-%'

... with out the brackets.

[Berto2002]

Ah, that would be interesting to try....

[Berto2002]

Thank you, @Gareth Cantrell, that definitely enabled the hook to trigger and we get an error message in JIRA.

That query is:

"Hornbill_RequestID"="{{webhookData.onEntityEvent.record.h_pk_reference}}"

And that's what we have called the field that contains the RequestID:

[Gareth Cantrell]

@Berto2002 Another typo on my part - you should use the JQL CONTAINS operator for text fields (~) (cf. JQL operators | Jira Software Cloud | Atlassian Support) so your JQL should look like: 

Hornbill_RequestID ~ "SR12345678"

 

[Berto2002]

@Gareth Cantrell.

We have managed to alter a parameter in the final branch statement and can get the h_last_update_activity_id to post on the JIRA timeline so we are connected. What we cannot do is get the content of the last update there.

We were looking through the Send web requests automation steps in JIRA and we can see this one gets the h_pk_reference from HB and assigns to "requestId" in JIRA

{
  "@service": "apps/com.hornbill.servicemanager/Requests",
  "@method": "getRequestRecord",
  "params": {
    "requestId": "{{webhookData.onEntityEvent.record.h_pk_reference}}",
    "returnRelatedData":false,
    "returnActivityStreamAccessToken": true
  }
}

We can then see this gets the h_last_update_activity_id and assigns to "activityID" in JIRA

{

 "@service": "activity",
  "@method": "activityStreamQueryItem",
  "params": {
    "activityID": "{{webhookData.onEntityEvent.record.h_last_update_activity_id}}",
    "accessToken":"{{webResponse.body.params.accessToken}}"
  }
}

What we cannot see is how JIRA can get told of the cell contents for "h_content" from "h_buz_activities" table which is where the updates are stored (The last updates text is not stored on the h_itsm_requests table).

We feel there should be perhaps be another web request or part of an existing one that uses the activityId to then pull back data from h_buz_activities/h_content for the given activityId?

[Gareth Cantrell]

@Berto2002

The query in 1d to activity:activityStreamQueryItem uses the activityID from the webhook and the accessToken from the previous request to getRequestRecord to return the activity record.

The response from this request should be in the format below, and you should be able to get the "content" variable in Jira using: {{webResponse.body.params.activity.content}} 

params.activity.content responds to the h_content column in the h_buz_activities table.

{
  "@status": true,
  "params": {
    "visibility": "...",
    "activity": {
      "id": "...",
      "actorInfo": {
        "userId": "...",
        "urn": "...",
        "firstName": "...",
        "lastName": "...",
        "name": "...",
        "onLineNow": true,
        "icon": "...",
        "onlineStatus": "...",
        "accountStatus": "...",
        "availabilityStatusInfo": {
          "id": 1,
          "status": "...",
          "flags": {
            "presentAtWork": true,
            "inWorkingTime": true,
            "doNotDisturb": false,
            "onCall": false,
            "requiresReturnDate": false
          }
        }
      },
      "stream_id": "...",
      "stream_type": "...",
      "stream_owner_ref": "...",
      "icon": "...",
      "verb": "...",
      "title": "...",
      "titleNew": "...",
      "content": "The content of the timeline update will be here",
      "language": "...",
      "published": "...",
      "updated": "...",
      "likes": 0,
      "youLike": false,
      "read": true,
      "fileAttachment": [],
      "comment": [],
      "additionalCommentsCount": 0,
      "type": "...",
      "visibility": "...",
      "activityType": "...",
      "status": "..."
    }
  }
}

 

[Berto2002]

[Berto2002]

And we got the Jira to Hornbill working too using the above!

Now we have a basic configuration, we can try some new things.

Thanks so much @Gareth Cantrell. I hope others find this resources useful in future.

[SamS]

Hi @Berto2002,

Answering your question as to why h_custom_33 isn't part of "record": that data is not in the request record directly, it is in a related table. That data oes not appear to be loaded alongside the regular request data.

[Berto2002]

We have worked-around the custom_33 issue by using another custom field, thank you. though.