Skip to main content (Press Enter).
Skip auxiliary navigation (Press Enter).
Code of Conduct
Skip main navigation (Press Enter).
Back to discussions
TM Forum Member
Posted 14 days ago
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.
New Best Answer
This thread already has a best answer. Would you like to mark this message as the new best answer?
Copyright 2019 TM Forum. All rights reserved. View our
Powered by Higher Logic