Relationship between ET_FAILED_KEY and EO_MESSAGE in action calls

[ThomasQ]

Hi,

When calling an action with a set of keys I would like to determine whether a failed key is a failed key because of a lock (so that it makes sense to call the action with that key once more after a couple of minutes). In order to achieve this I analyze EO_MESSAGE.

Unfortunately, the lock message always refers to the node that is actually locked (of course...), but there is no link to one of the keys for which the action is called.

If I don't know the internals of the action, there's no chance to find out which of the failed keys is a failed key because of a lock. And even if I do, it's sometimes very complicated to trace it.

Is there any option that might help here?

Regards, Thomas

[ivo_vollrath]

Hi Thomas,

I am not aware of any such option. But it might be an option to re-try the action for the failed keys one-by-one (provided that a failing action does not have any side-effects and performance is not of utmost importance). Of course, this approach cannot be a general recommendation. However, assuming that failed keys should not be the standard situation, it may still be an option for failure recovery or analysis.

Regards,

Ivo

[ThomasQ]

Hi Ivo,

Thanks for the idea. This would finally handle all failed-because-of-lock keys. But I would never know whether a still-failed key is a failed-because-of-lock key or whether it needs a different handling.

Regards, Thomas

[Former Member]

Hi Thomas

as far as I know, the single message objects (/bobf/cm_frw) within the EO_MESSAGE have a public attribute named origin location (...->ms_origin_location) consisting of the fields

BO_KEY

NODE_KEY

KEY

ATTRIBUTES

Did you check the KEY field of this attribute of the message(s) signalling the lock (symptom is "FOL.FOL")? Is it filled? Maybe this can be used to match the message with the contents of ET_FAILED_KEY.

Ok, not beautiful but it could work...

Regards,
Andreas

[ThomasQ]

Hi Andreas,

I had already checked that. In my case (propagate a change in a node to a node of another BO instance) MS_ORIGIN_LOCATION-KEY is filled with the 'target' node, i.e. with the key to which the message refers.

I think I'll complement the 'push' action by a 'pull' action for the target node. The push will call the pull on the target node and will always finish successfully, writing a reminder to a separate DB table in case of a lock (our application already provides this delayed update  feature for other prcoesses). Processing the reminder then calls the pull action with a proper handling of lock messages.

Some more work than I expected, but I think that's the only way.

Regards, Thomas