John Warner
I am trying to find a way of assigning an output back onto my scenario.
So I have a scenario to create a new incident in Status page which works fine and returns a set of output.
output['Incident ID'] = respBody.id;
Now I want to save that to the scenario so have a dummy field (SP_INCIDENT_ID) which does not appear on the form so that later I can use it to make an update of the incident on status page.
So I imagine I need to code something like
event.properties[‘SP_INCIDENT_ID’] = output['Incident ID']
0
Comments
Please sign in to leave a comment.
I'd like to know this as well. It *seems* as if only the time that the properties can be set is by the initiating step in a workflow. Looking at the properties on an xMatters event seems to only list those initial properties and not any set by later steps in the workflow.
I've added a property to a workflow and added it to a form for the workflow (there was something I read that suggested only form properties would be stored as part of an event but I may have misunderstood).
In theory, you ought to be able to just set it like any other output in a step but it isn't getting saved.
Hey guys! And wow, apologies for the super late response, sorry about that John.
The event properties are where we store information used to deliver to people. They are immutable however, so once the event is in-flight, they cannot be changed. From a notification perspective this makes sense, because you wouldn't want Joe, Bob and Sam having different information for the same event!
However, this causes problems when we need to store data for later re-use. We're aware of this and have plans for an over-arching "Incident" that will have some kind of runtime storage component, but that is still a ways off.
A couple options come to mind:
I think our consultants have also done this in the field, so I'll see if I can track down some of them and see if they have any additional insights.
Happy Wednesday!
--- Travis
Hi Travis
Thank you very much for your suggestions.
"They are immutable however, so once the event is in-flight, they cannot be changed." - I understand this point but what isn't clear to me is the definition of an in-flight event.
For example, an trigger fires a workflow which contains a series of steps to execute and finishes with a step to create a xMatters event. At what point in that workflow do the properties become immutable? Is it after the first step finishes executing?
The reason I ask is because if it would be possible to allow properties to be changed within a workflow *before* the xMatters event is created, that would certainly help me (!) but would also seem to avoid the concern of different agents receiving different notifications since they only receive notifications off the back of the actual xMatters event? Or am I misunderstanding things here ... ?
I'd like to give you an example of what I'm trying to solve because I think it may help with the company-internal thinking regarding events and incidents.
Given a service, e.g. an e-commerce site, that has multiple components, e.g. database, web service, etc. One or more of those components could go into a failed state and a separate xMatters event created for each failed component. However, the customer-facing status dashboard should only provide a high level view - customers just need to know there is a problem with the site, not the underlying cause.
That is fairly simple to handle when the alarms go off. However, once support agents start clearing the problems, the dashboard must only be cleared once *all* events affecting that single service have been resolved. That means searching xMatters to find any active events for that service.
Looking at the API, there are two ways I can do this:
1. Have an event property that specifies the affected service and search for that property value.
2. Search all active events, retrieve them, determine the affected service from the trigger details.
Option 1 is the most effective, hence this conversation :). I think I can use your second suggestion to help me implement that option through indirected place-holder events but it isn't *entirely* ideal.
I hope the above is food for thought on how things could be tweaked/improved.
Many thanks.
Hi Travis
"We're aware of this and have plans for an over-arching "Incident" that will have some kind of runtime storage component, but that is still a ways off. "
Having done more work on integrating xMatters with status.io, I can see the benefit of an "incident" vs an "event". In my workflow, each CloudWatch alarm triggers an xMatters event but, if they all affect the same component on status.io, only one incident is created on status.io. I've worked out how to only mark the incident as dealt with once all of the corresponding xMatters events are terminated but there is the risk of a race condition if multiple xMatters events terminate within a very close timeframe of each other. Having a xMatters incident to correlate between multiple events and an external "thing" would help there ...
I've now figured out how to save a value to an event property ... the only absolute requirement is that the value must exist before you get to the "xMatters Create Event" step. As Travis has stated, once the event itself has been created, the property values are immutable.
To set this up:
1. Define a property on the Workflow Properties tab.
2. Add the property to the layout of a form. Note that it is not necessary to actually add the property to any of the messages.
3. (This is the bit I was missing out previously) In the "xMatters Create Event" step, find the new property on the Setup tab of the step and drag the desired value from the right hand side into the property.