<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1801" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#b8b8b8>
<DIV><FONT face=3D"Courier New" size=3D2>Hi there,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>I have a situation where I am =
coding=20
exception conditions in a background object method that I =
have</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>created in our EBP =
system.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Within the object method there =
is an RFC to=20
a FM in our standard (backend) R/3 system.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>The FM in the backend system =
raises certain=20
exceptions which are coded for in the call FM</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>i/face in the object=20
method. </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>When I test the object =
method thru the=20
test function of the business object TAC (SWO1), the</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>code tests fine - SY-SUBRC is =
set to the=20
appropriate value as defined in the exception i/face. </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SY-SUBRC is then evaluated and =
the=20
'exit-return' macro is called to raise the appropriate error as=20
defined</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>in the object method exceptions =
(all the=20
object method exceptions are coded as application errors).</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>When the workflow is run =
however, as soon=20
as the exception is raised in the backend FM, a dump is produced in =
</FONT><FONT=20
face=3D"Courier New" size=3D2>both systems which is basically a dump =
detailing the=20
exception that was raised. The background step that runs the =
object method=20
however stays in a 'started' status and is not set to an error status =
therefore=20
not allowing the step to be rerun by the 'restart after errors' =
administration=20
TAC.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>A similar thing is occurring =
with a role=20
resolution FM which as well is calling a remote FM in the backend =
system. =20
As sson as the exception is raised, dumps are produced and the w/flow =
does not=20
even show the dialog </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>step that has the role =
resolution attached=20
as having started. Again the role resolution FM has the =
appropriate=20
exceptions coded in the call FM i/face. If I test the role =
resolution=20
via the test function of the role display TAC (PFAC_DIS) it works =
fine ie.=20
actor_tab is empty and the role terminates in error as =
the 'terminate=20
if no agents found' flag is set. </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<DIV><FONT face=3D"Courier New" size=3D2>Is this standard =
functionality? =20
Rather than raising exceptions should I be passing error messages to a =
'return'=20
table and evaluate it as per BAPI functionality? As I have =
quite a=20
lot of exception conditions coded I would like to verify this before =
recoding it=20
as a 'return' table. </FONT></DIV>
<DIV> </DIV>
<DIV>Any ideas would be greatly appreciated.</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV>NB: If I port the above code into an ABAP and test it it =
works fine -=20
ie. sy-subrc is set to the value as defined in the call FM exception=20
i/face.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Regards</FONT></DIV>
<DIV>Michael Arter</DIV>
<DIV> </DIV>
<DIV>SAP W/flow programmer</DIV>
<DIV>IBM GSA</DIV></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>61 3 9322 =
6946</FONT></DIV></BODY></HTML>