Open APIs

 View Only
  • 1.  TMF642

    TM Forum Member
    Posted Oct 07, 2021 08:51
    Hi All,

    Why does the TMF642 spec mandate that an ID must be generated by the EMS on Event Creation, for the source system to somehow store against the originating alarm for subsequent updates and an eventual clear?

    I'm not aware of any COTS source event systems that have the capability to update the originating Event metadata with this alarm to store the ID in a stateful manner, for later reuse.

    I find, more often than not, that the only way to consume TMF642 is to CREATE an event - for Creates, Updates and Clears and rely on the EMS to correlate/deduplicate these events.

    Shouldn't the ID stem from the source system (externalAlarmId) and not be generated from the EMS? Perhaps coupled with the sourceSystem field to ensure uniqueness?

    I'm having a tough time explaining the TMF642 mechanics to consumers that wish to use it across many of their Event Sources, but simply cannot adhere to the spec.

    Kind regards

    Sam
    Sam

    ------------------------------
    Sam Fowler
    ServiceNow, Inc.
    ------------------------------