Temporary errors in standard background methods?

[Kouw, FA - SPLTX]

Mike,
 
Don't know if this is relevant for your situation, but nevertheless: we are using standard background method
'BUS2081.PreliminaryPost' for automatically posting an invoice. SAP changed the standard method on my request:
they added a new exception in the code (1002, next to the already existing 1001). The new exception is raised
when the related PO is locked. The new exception results in a temporary error and is added to the standard
method (change key was needed to implement the change to standard SAP).
 
Regards,
 
Fred kouw
 
Alon Raskin wrote:
 
> Hi Michael,
>
>
>
> I am really pleased that you brought this up as this has been one of my pet
> gripes (one of many) about the BOR. What's worse is that it almost works.
>
>
>
> You can make the following call in your redefined method
>
>
>
> swc_call_method super 'MethodName' method_container.
>
>
>
> Super is a predefined reference to the supertype of the BOR Object that you
> are in.
>
>
>
> And it ALMOST works. What it does is call the supertype method but if you
> have delegation then it transfers the call back to the subtype. This means
> that you end up in and endless loop! I tried logging this bug with OSS but I
> honestly don't think they understood..
>
>
>
> If you have a subtype which is NOT delegated then this works perfectly. You
> can redefine a method and then call the supertype just as real OO.
>
>
>
> Close but no Cigar.
>
>
>
> Good luck with OSS..
>
>
>
> Alon
>
>
>
>
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
> Michael Pokraka
> Sent: Wednesday, November 19, 2003 4:55 PM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Temporary errors in standard background methods?
>
>
>
> Hi Alon,
>
> The reason I'd prefer not to redefine is the lack of 'proper' OO in
>
> Business Objects, and remaining upwardly compatible. As far as I'm aware,
>
> one cannot call the supertype method from a redefined method - which would
>
> make redefining a perfect alternative.
>
> I think I'll go with your suggestion about contacting SAP, some of these
>
> just seem such an obvious candidate for temp errors that I find it a
>
> little curious that it hasn't been changed yet (on 4.7 here).
>
>
>
> Thanks for your input.
>
> Cheers
>
> Mike
>
>
>
> Somewhere in the mists of time Alon Raskinwrote:
>
> > Hi Michael,
>
> >
>
> > You almost got it.
>
> >
>
> > What I would do is redefine the method on the new sub-type. That way it
>
> ensures that your method gets called by all developments.
>
> >
>
> > To be honest, before I go down that route, I would first log an OSS and
>
> try to get SAP to change their exception to a temporary one.
>
> >
>
> > Regards,
>
> >
>
> > Alon
>
> >
>
> > ________________________________
>
> >
>
> > From: SAP Workflow on behalf of Michael Pokraka
>
> > Sent: Wed 19/11/2003 15:58
>
> > To: SAP-WUG at MITVMA.MIT.EDU
>
> > Subject: Temporary errors in standard background methods?
>
> >
>
> >
>
> >
>
> > Hi Folks,
>
> > I'm surprised not to find anything in the archives about this one:
>
> >
>
> > Is there a simple way to mark a SAP-standard background method's
>
> exception as a temporary error? SAP have a habit of using the temp
>
> setting as little as possible, which is a bit annoying when trying to
>
> use standard methods as far as possible - BUS2012.RELEASE is an obvious
>
> example: if someone is editing the PO it immediately errors, no retry
>
> via SWWERRE, resulting in an unhappy WF administrator.
>
> >
>
> > The only thing I can think of (and have used in the past) is to have a
>
> custom delegated subtype of the object, with a custom method which calls
>
> the original method and duplicates the exceptions with the desired
>
> settings. This seems a bit of overkill just for setting a temporary
>
> error.
>
> >  In fact it seems so 'normal' that I'm wondering if I'm not missing
>
> > something glaringly obvious...
>
> >
>
> > Any thoughts/suggestions would be appreciated,
>
> > Cheers
>
> > Mike
>
> >
>
> _________________________________________________________________________________________
> This inbound message from KPN has been checked for all known viruses by KPN IV-Scan, powered by MessageLabs.
> For further information visit: http://www.veiliginternet.nl
> _____________________________________________________________________________________________
 
 
**********************************************************************
This e-mail and any attachment may contain confidential and privileged
material intended for the addressee only. If you are not the addressee, you
are notified that no part of the e-mail or any attachment may be disclosed,
copied or distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have received
this e-mail by error, please notify the sender immediately by return e-mail,
and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor responsible
for any delay in receipt.
**********************************************************************
 
_____________________________________________________________________________________________
This outbound message from KPN has been checked for all known viruses by KPN IV-Scan, powered by MessageLabs.
For further information visit: http://www.veiliginternet.nl
_____________________________________________________________________________________________