enhancement Webhook request sub-entity payloads inconsistent

[Gareth Cantrell]

I have noticed that the update payload for Incidents (urn:webhook:entity:Incidents:updated) are not consistent with the other Request entities (ChangeRequests, Problems, Releases).

For example, I have a webhook listening for updates to Change Requests and the webhook sends the h_fk_reference field in the record structure:
 

{
  "onEntityEvent": {
    "eventSource": "urn:webhook:entity:ChangeRequests:updated",
    "callingSessionId": "U2023051500000957.5086",
    "eventTime": "2023-05-16 11:05:35Z",
    "actionBy": "xxx",
    "actionByName": "xxx",
    "entity": "ChangeRequests",
    "record": {
      "h_fk_reference": "CH00000234",
      "h_custom_a": "Medium",
      "h_last_updated": "2023-05-16 11:05:34"
    }
  }
}

However, when using Incidents, the webhook sends the h_pk_id only, so it is not possible to determine the request Id as the API doesn't appear to have any methods for retrieving the underlying request:

{
  "onEntityEvent": {
    "eventSource": "urn:webhook:entity:Incidents:updated",
    "callingSessionId": "U2023051500000956.4189",
    "eventTime": "2023-05-16 10:28:40Z",
    "actionBy": "xxx",
    "actionByName": "xxx",
    "entity": "Incidents",
    "record": {
      "h_pk_id": "121",
      "h_custom_a": "Medium",
      "h_last_updated": "2023-05-16 10:28:40"
    }
  }
}

I can get around this by configuring the webhook to send a Requests:updated event, however this is inefficient and results in more outgoing calls than is necessary when I'm only interested in Incident updates.

Is it therefore possible to update the Incidents payloads to include the h_fk_reference field, rather than the h_pk_id field?

[AlexTumber]

@Gareth Cantrell thanks for your post.

Unfortunately it's not possible for us to configure the payload on an entity by entity basis. At this current time, the web hook functionality sends the primary key plus any columns that have ben modified for all application entities.

Personally, I would love to see us update the incident table and have a consistent set of columns across the board but a change like that to a major table that's used by every one of our customers involves a lot of work (to the detriment of other features/functionality), as I'm sure you can appreciate. The fact there is also a viable workaround available (admittedly not ideal) is also likely to mean this won't be addressed anytime soon unfortunately. 

I will post back to this thread if there are any updates or any movements on this particular known issue.

Alex

[Gareth Cantrell]

@AlexTumber thanks for the update.

I can appreciate that it'd be a major change and we can live with the workaround.

On that note, it would be really nice to be able to attach conditions to a webhook, insofar as it would then only fire if those conditions are met.

Currently, a single update can cause a webhook to initiate multiple calls, with varying information carried in each call.

[AlexTumber]

@Gareth Cantrell no problem. I totally agree and adding conditions to web hook events makes a lot of sense to me. 

I'll forward this requirement onto the relevant team at Hornbill.

Alex

[Gerry]

@Gareth Cantrell

In the roadmap and under active development is something we are calling business rules.  Different to web hooks, but will have conditions that trigger actions, so some of what you are doing with webhooks you will probably be able to do with business rules, but should be easier to maintain. 

To be fair though, conditions on web hooks is actually not a bad idea for consideration. I am always conscious of over-complicating Hornbill when we consider features, but WebHooks are really an advanced feature of our enterprise offering so I don't see why we could not add conditions to web hooks.  From memory, everything we would need to be able to apply a condition check over the record relating to the web hook is in our hands and we have an ultra fast expression evaluator that could be applied to that exact data.  I will add a review of the code to see how viable that is. 

In relation to the question about the events, in your example, I believe the event for ChangeRequests is actually being fired as a result of a Requests entity update, meaning the API that was called that caused the ChanegRequests to fire a webhook was in fact an API call to update the Requests entity, which has the ability to update a related entity indirectly.  So the record being updated is a related record, hence the FK value, as opposed to the requests primary key.  It *may* be possible to provide the primary key value of the main entity that was updated under these conditions, I am not exactly sure, again I would need to look and see whats possible without breaking things or sacrificing efficiency.  Its not likely the code change that will be the issue, its setting up the replication and test environment, and the subsequent add of automated testing, so time is needed here.  

I will post an update once we have had a look at whats possible here.

Gerry