Can I not use interfaces as input objects in single tasks? (R/3 4.6C)

Wed Aug 31 04:26:52 EDT 2005

Thank you for your input. Yes, the "object-oriented" world of SAP BOR
reminds me a little of the "object-oriented" world of PowerBuilder (when
I used it in 10 years ago). It claims to be a duck, but it doesn't quite
walk like a duck, doesn't quite quack like a duck. In PowerBuilder it
was menus that couldn't be inherited. I wish IBM would have created
VisualAge ABAP. I've never tried a tool like VisualAge yet. Well, enough
day-dreaming.

Our approval takes place based on cost assignment (whoever is
responsible for the cost object used in the assignment gets the document
for approval), and each purchase order item and requisition item is
evaluated separately. Even accounting document items are sent for
separate approval. The idea is that the "budget owners" get a continous
flow of information about costs pertaining to their budget.

We currently have a report-centric solution for this. The idiots in
Enron and WorldCom have created a lot of additional work for the rest of
the world. As a result of their dishonesty I am going to rewrite the
solution to a workflow-centric one. The idea is to have better (and SAP
standard) tracking possibilities. However, the change should be as
transparent as possible to the users. The new solutions will therefore
integrate with the current approval report. This among other things
requires logging in tables of documents waiting for approval, as today.

There are therefore some common parts which I thought I'd implement with
the aid of an interface. I have given it some more thought, and I was
thinking about creating an object type "Statoil approval system
document". By defining a method in the interface which returns a
reference to this object type I can use a common task to perform common
tasks. I will need a task per object type to return the reference, but
that can be re-used in all the common scenarios.

The other alternative is to accept that different documents (purchase
order, accounting document, service entry sheet, etc) should have
different tasks even if the tasks have something in common, and minimize
the duplication of code in other ways.

Both solutions have their advantages and disadvantages as far as I can
see, so I still have not quite made up my mind.
-- 
Kjetil Kilhavn, Statoil KTJ IT BKS

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Pokraka
Sent: 29. august 2005 23:58
To: SAP Workflow Users' Group
Subject: Re: Can I not use interfaces as input objects in single tasks?
(R/3 4.6C)

Hi Kjetil,
Interesting one... Interfaces are great :) I remember attempting
something similar: I tried creating a task based on a common supertype
and binding in subtypes with redefined methods in the different WF's,
hoping it would execute the subtype's method. Unfortunately polymorphism
was just a little beyond WF and it whined about object type mismatches
and stuff.
I think it was 4.6c, but maybe it gives you an idea or maybe it even
works thanks to some fabulous patches.... (hey, one can always be
hopeful!).

Plan B: Have an interface method look for an object in the container and
call its same-named method. (Or redefine a common supertype's
instance-independent method to do this).
At binding, shove your 'real' object into adhoc objects so you don't
have to bother with any hardcoding. You'll need to do some coding to
either look for it in the container based on compatible object types or
use a naming convention of sorts. Or perhaps to bind the element name as
a parameter?

Thus bind:
PurchReq -> Adhoc Objects
'PurchReq' -> ElementName

to another object's method/task (supertype, interface or whatever):
METHOD FOO CHANGING CONTAINER
   SWC_GET_ELEMENT container 'ElementName' l_elementname.
   SWC_GET_ELEMENT container l_elementname l_obj.
   SWC_CALL_METHOD l_obj 'FOO' container.

Cheers
Mike

Kjetil Kilhavn wrote:
> I am currently rewriting an existing application where the code is 
> quite dynamic and re-useable. In order to maintain the dynamic nature 
> of the solution I thought I'd create an interface and reference the 
> interface instead of creating all methods in all object types. A nice 
> surprise compared to ABAP Objects was the ability to actually 
> implement a method in the interface, so I didn't have to copy the 
> implementation between all the object types.
>  
> Now I am facing the problem that apparently I can not bind my purchase

> requisition object to the task I have created for executing my 
> interface method. It seems I will have to create one task for each 
> object type that implements the interface. Needless to say, this is a 
> major bummer after being happy about the ability to implement the 
> method in the interface.
>  
> Has anyone successfully used an interface as the object in a task?
> I've been trying all sorts of things now and am about to give up and 
> create one task per object type, but first I'll give you the weekend 
> to assist me ;-)
> --
> Kjetil Kilhavn, Statoil KTJ IT BKS
>  
> 
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is 
> intended for the addressee only. Any unauthorised use, dissemination 
> of the information or copying of this message is prohibited. If you 
> are not the addressee, please notify the sender immediately by return 
> e-mail and delete this message.
> Thank you.
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.