cancel
Showing results for 
Search instead for 
Did you mean: 

Extending key attributes with IF_WORKFLOW

Former Member
0 Kudos

Hi Wuggies,

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.

http://scn.sap.com/community/bpm/business-workflow/blog/2006/06/28/getting-started-with-abap-oo-for-...

http://scn.sap.com/community/bpm/business-workflow/blog/2006/08/21/using-abap-oo-attributes-in-workf...

Is there anybody, who's got any design solution or Workaround here available?

The text-bases class builder didn't bring any further Options.

Florin

Accepted Solutions (1)

Accepted Solutions (1)

pokrakam
Active Contributor
0 Kudos

Hi Florin,

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.

Regards,

Mike

Former Member
0 Kudos

Hello Mike,

thanks for your thoughts on that

It's somewhat true, that it's a contradictions, when one intends to use the inheritance to keep the key-fields as they were, to remain compatible with its superior classes. Probably that's one of the reason they were made unchangeable. But if the developer know, what they're doing, it could be opened up, right?

What I'm essentially missing with the ABAP OO interfaces -- and which is the main reason why I dare to bring in generic coding into the class hierarchy -- is the lack of template coding within Interface methods.

I was quite astonished when I found out that this is possible with BOR interfaces, and it can bring up a generic - widely re-usable - coding that works within different contexts of BOR object implementation.

That's an advantage of BOR over ABAP-OO (within Workflow), where there's still no easy approach to bridge that gap within an OO-Workflow-scenario.

I've checked to see what happends, when you modified the key-attributes the hard way, just to see, how the runtime behaves ... but it seems that it looks up the class hierarchy for the first inclusion of IF_WORKFLOW and uses the maintained key-attributes from there, regardsless of how the subclasses look like ... so that seems to be a dead-end ... unless you "include" some extension in the Workflow runtime.

Florin

pokrakam
Active Contributor
0 Kudos

Hmmm, I can see what you mean. And yes, I've been through the same way of forcing different key attributes via the backdoor.

But in the OO sense, BOR "interfaces" are wrong and should really be called templates. If anything, they resemble multiple inheritance, which ABAP (unfortunately?) doesn't do. An interface is abstract and cannot contain code; it's a specification.

If WF could handle interfaces, it would help. A ZIF_USER implementation can inherit from different 'template' superclasses, whereas a ZCL_USER can only inherit along a single path. This is why good OO design tends to favour interfaces over inheritance.

Regards,

Mike

Answers (0)