How to know if a particular fragment of a ManagedObject has been updated in an EPL app?

Is there a way by which we can fetch a recently updated fragment of a ManagedObject in an EPL app? I know ManagedObjects params have a string attribute called “PARAM_NOTIFICATION” whose value can be either “CREATED” or “UPDATED”, using which we can know if a particular MO is a new MO (CREATED) or an existing one which has just been updated (UPDATED). But the limitation of this parameter is that it only tells about the whole MO in general and doesn’t tell which specific fragment of that MO was actually updated.

Use Case:
Suppose an MO has 3 Fragments: A, B and C.
I want to monitor for any change in the fragment C of the MOs and then perform a set of functions when C is updated, but can’t figure out a way to know if there are any changes made in that particular fragment C.
Currently, by checking the PARAM_NOTIFICATION value, I am filtering out the existing MOs, but this gives me all the updated MOs (where any fragment is updated), and not the ones where specifically fragment C is updated.
I want to filter out those MOs where fragment C is updated.

Any help would be appreciated.

1 Like

I am not aware of Apama specifics but could you elaborate about your use case a bit more?

It might be a better option for you to create Cumulocity Events rather than setting Managed Object Properties (or create an additional event for ‘X happened, state changed to: Y’). This way you would just subscribe to this event stream. Additionally, such events provides you a history of all changes automatically.

1 Like

Thanks for your response Korbibian_Butz. I have updated my post and included a more detailed explanation of my use case. Hope it makes things clearer.

As Korbinian has mentioned at the moment there is no built-in functionality to detect if a fragment has been added/updated/removed for a ManagedObject. The PARAM_NOTIFICATION property in Apama only applies to the whole ManagedObject. You would need to come up with your own implementation.

Thanks for your response Christian.
I’ll try to figure out a work around for this problem.