I'm a bit stuck with the design of class hierarchy that involves the IF_WORKFLOW-Interface:
The ABAP Class, that first includes/implements the IF_WORKFLOW Interface has got the column "Key" in the attributes tab available. The checkboxes there are ready for input for all the attributes, which are created on the current class Level. So far, so understood: You can't make an existing attribute a "Workflow" key-field afterwards... However, I wonder, why there is such a restriction. It seems a bit unnessesary.
However, when there's no key field checked (as e.g. it's a quite generic implementation), any of the subclasses cannot make any of its attribute a key-member (and of course it still can't modify the key-checkbox ... if though the attribute was created having the IF_WORKFLOW interface).
Basically you can't create key field attributes, once you've inherited a class. For that I'm a bit disappointed, as ABAP Objects tends to use inheritance, isn't it??).
I've read through the Blogs here that explain the usage ... but none of them uses real inheritance.
Is there anybody, who's got any design solution or Workaround here available?
The text-bases class builder didn't bring any further Options.
While I also find it inconvenient at times, it does make sense and works the same as BOR. "Key" is an inherited property and it cause major problems if it could be overridden and goes against the idea of a persistent object reference.
Think about it: We could ask for an object Sales Order 1234 and get back Order 1234 item 20, which could be intended and even managed by a smart developer, but throw it open to the big wide world and it's just asking for trouble.
The 'OO-way' to solve this is with interfaces, which are unfortunately not supported by WF. So my approach is to use an inherited generic key alongside a typed key. Been meaning to blog it for a long time, I blame severe shortage of round tuits.