P.S.
The MyHistorian is just a sample, but should cover most common use-cases. But there are so many ways to use HistoryRead so it doesn’t cover all of them, thus why I linked the spec parts in case you wish to support more, as there are so many combinations of flags etc. (plus more if you use aggregates), that it is outside of the scope to try to explain everything here. However, SDK does have some help for Aggregates via AggregateCalculator, that is in the sample).

Good question.

Short version:
Pass a non-null ‘userEventId’ ByteString for the triggerEvent(userEventId), if you need them to be unique even after restart, use something that is. Maybe UUID and e.g. something like https://www.baeldung.com/java-byte-array-to-uuid (maybe we should make some helpers in the SDK in the future to make this easier). NOTE the result of using the link might differ from the “OPC UA Guid encoding rules”, this is OK here, because it is just raw bytes. Technically it is possible to use BinaryEncoder of the SDK to encode any UA values, but also note that doing that might be more complex than the link. Also, if you pass in something “real data”, sanitize the inputs (or check BinaryDecoder outputs carefully) when the client calling Acknowledge.

Long version:
The return value (the ByteString) of triggerEvent is the same as EventData.getEventId(). Note that you will also input a ByteString userEventId to the method. SDK will concatenate that value to the one it internally generates for a “full event id”, except if you give null, then it will just use the one it generated internally. The generated one is just a long that is incremented for each event. You can extract your userEventId via static EventManager.extractUserEventId(full_EventId_here) (basically it just returns one without the first 8 bytes).

The idea is that you will most likely have some external system outside of the SDK that is generating the event or alarm. It might generate it’s own identifier. You would then use that somehow as the userEventId and SDK basically just ensures they are unique by prefixing it with the counter. Since the EventId comes back when the client acknowledges the alarms, you can feed this info back to the external system to do the real acknowledge.

As to the uniqueness. I’m not 100% sure. The specification does say in https://reference.opcfoundation.org/v104/Core/docs/Part5/6.4.2 “EventId is generated by the Server to uniquely identify a particular Event Notification. The Server is responsible to ensure that each Event has its unique EventId.” (Then it says that one way for this is to use a Guid). I could see 2 different interpretations (i.e. unique just for _that server_ to identify the event for the purposes of e.g. Acknowledge OR in general; a restarted server could be thought to be a different server).

I guess it matters more where is the real state of the alarm. If this would be just a simulation or a test server, maybe there is no true state for the alarm after the server is shut down, i.e. that would make all previous alarms meaningless. After it starts again, it would re-use the EventId. So I guess the only danger is then if a client reconnected, and there was an alarm acknowledge action queued in some way that the client is acknowledging an old alarm that has the same EventId as a new alarm, which could then potentially be missed by the user of the client. If this is a use-case where this can cause problems, I would recommend NOT using null as the userEventId and just using something else. If you have no external system etc. test the UUID mentioned in the short version.

P.S.
The SDK logic is very old, back then alarms were basically not used. Though, as far as I see, they are still very much underused part of OPC UA. Maybe the SDK logic of using the long increment should also change in some future version. For example, maybe SDK prefix logic should just already use a UUID (it is only 8 more bytes anyway to a total of 16 bytes).

Most likely it is ok, maybe even a good idea, but this sort of starts to go beyond what I would say is within SDK-level support. That is to say, to give better suggestions we would need to know a lot more, and then it would be within the scopes of https://www.prosysopc.com/services/.