KMC Resource Eventing: Rename and display name/description

[Former Member]

Hallo,

I'm wondering about the behavior of ResourceEvent.RENAME.

When a KMC resource is renamed, its 'old' properties can be accessed by ResourceEvent.PRE_RENAME. On ResourceEvent.RENAME, the new RID is propagated but not the new displayname and description. These are set afterwards on ResourceEvent.PROPERTY_SET. Why isn't this propagated before the RENAME event is thrown? I register with the broker in synchronous mode.

Kind regards,

Christian

[former_member441228 · Accepted solution]

That's because the 'display name' is just a property of a resource while the RID is the identifier "managed" by the namespace submanager of a repository manager. The new display name is most likely set by an event receiver, and in your case that receiver has apparently not processed the event yet.

helmut

[Former Member · Accepted solution]

Hallo Helmut,

your answer clarifies my problem though it is not the answer I wanted to get.

With the current behaviour I must also subscribe to ResourceEvent.SET events in order to get the new displayname and description after a renaming. Within ResourceEvent.SET handling I would have to distinguish wether the resource has been renamed before or whether the SET-operation is thrown on another resource. This produces unnecessary overhead within the event loop and complicates the event handling as it can't be stateless anymore.

Looking at KMC as a black box I would expect a different behavior: when EventResource.RENAME is thrown, everything (Properties, data, ...) of the renamed resource is already updated. Am I on the wrong track or wouldn't this be the behaviour one expects on using SAP EP eventing?

Kind regards,

Christian

[former_member441228 · Accepted solution]

Well, sorry that the answer doesn't match your expectations. The point is that as an event receiver your code is running inside of that black box.

And that's true for all the other event-based stuff as well. The manager or submanager itself doesn't know the semantics of most properties so it can't adjust to the value you'd like to see before the very first event is sent out.

If KMC were designed as a closed black box then of course it would have to reject any plugins like filters or event handlers that allow to tweak the behavior of KMC.

[Former Member · Accepted solution]

Ok,

so the only possibility to get this working in the correct order for me is to implement a workaround.

Thanks for your answers,

regards

Christian

[former_member441228 · Accepted solution]

I guess yes as the namespace operation and the display name property tracking are two different; and depending on the UI you will even see cases where a rename in the namespace doesn't result in changes to the display name.

You're probably triggering your scenario through a UI rename command which is implemented in a way that bundles the namespace and the property methods. I would suggest to rely on this observation.

[detlev_beutner · Accepted solution]

Hi Christian, hi Helmut,

quite interesting thread, for I'm doing this just three weeks later.

Anyhow, one answer and one question:

Christian, you talked about the SET-Template. This should be relevant for updating content, not properties. Maybe as Helmut wrote, your use case (using some UI functionality) also updates the content together with the properties. But in general, PROPERTY_SET should be the right thing.

Helmut: I need, as Christian did, the old name of the display name as well as the new one. But there is no PRE_PROPERTY_SET!?!? How to access the old name? In my use case, probably there will no other event be thrown (when renaming a collaboration room; no content, no RID change).

Hope it helps & thanks in advance

Detlev