Raise exception with parameters

Hi,
Does anyone know how to hook into raising (predefined) exceptions with parameters?
In a distributed environment I have to write my integrity constraints in triggers. For example, upon deleting, I throw an ORA-02292 myself if a child record exists inside a remote table (PRAGMA EXCEPTION_INIT(CHILD_RECORD_FOUND, -2292)). This results in the message ORA-02292: integrity constraint (.) violated - child record found.
How do I pass someting to the %s parameter of the message? I'd like it to say ORA-02292: integrity constraint (MY_TRIGGER.REMOTE_TABLE) violated - child record found.
If I throw the "stripped" ORA-02292, users won't have a clue as to what's failing.
If I throw a user defined exception, I lose the ORA number, resulting code written specifically to handle these to start failing.
Sure, updating all our exception handlers would be an option... NOT!
Thanks,
K.

How do I pass someting to the %s parameter of the message?You can't. But you can try something like this:
declare
child_record_found exception;
pragma exception_init(child_record_found, -2292);
begin
begin
    raise_application_error(-20000, 'Integrity trigger (MY_TRIGGER.REMOTE_TABLE)');
exception
    when others then
      raise child_record_found;
end;
end;
ERROR at line 1:
ORA-02292: integrity constraint (.) violated - child record found
ORA-06512: at line 9
ORA-20000: Integrity trigger (MY_TRIGGER.REMOTE_TABLE)

Similar Messages

Error text missing in raising exception (In ABAP mapping)

Hi,
iam using ABAP Mapping for 1 interface.
Based on some condition i am raising exception with error text. When i executed this in SXI_Mapping_test it's showing the Error text. But when i execute the interface directly error text is missing in the Error details.
can any one figure out y its not coming..
regards
Kishore

Hi,
I think you need to write the error to mapping trace.
http://help.sap.com/saphelp_nw04/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
Regards
Vijaya

How to raise a self-defined event with parameters in program

Hi,all,
I want to raise a self-defined event with parameters in one of my method ,how to do that?Thanks

Hi Ray,
If your event name is MYEVENT and the parameter name is MYPARA and the value you want to pass to this parameter is L_PARAVALUE, use the following -
wd_this->fire_myevent_evt( mypara = l_paravalue ).
If the event is to be raised in an a view, then you need to get the component controller instance first and use it instead of wd_this.
Also, this can be obtained directly by clicking on the WD Code Wizard ->Radio button for raise event->selecting your event.
Regards,
Neha
PS:Reward if helpful

Raise exception when the user entered value is not present

Hello Abap experts,
To raise an exception in the function module when the imported variable value is not presnt in the table.
import variable: cust_name.
how to define a exception for this raise it in the code. any examples and suggestions.
Thanks,
BWer

Here is the F1 help on RAISE.

RAISE
Basic form 1
RAISE except.
Effect
This statement is only effective in function modules and methods.
It triggers the exception except.
If the exception is to be handled by the caller of the function module or method ( CALL FUNCTION or CALL METHOD ), the system passes control straight back to the caller. EXPORT parameters of a function module or method are not filled. The EXPORTING, CHANGING, and RETURNING parameters of a function module or method are only filled with the current values if they were defined to be passed by reference. reference).If they are defined to be passed by value, they are not filled.
If the exception is not handled by the caller, the program terminates with an appropriate error message.
Example
Let there be a function module STRING_SPLIT containing the following code (see also the example in the documentation of the CALL FUNCTION statement):
FUNCTION-POOL CSTR.
FUNCTION STRING_SPLIT.
IF STRING NA DELIMITER.
 RAISE NOT_FOUND.
ENDIF.
ENDFUNCTION.
The calling program might then contain the following:
PROGRAM EXAMPLE.
CALL FUNCTION 'STRING_SPLIT'
 EXCEPTIONS
 NOT_FOUND = 7.
IF SY-SUBRC = 7.
WRITE / 'There is a problem.'.
ELSE.
ENDIF.

If the NOT_FOUND exception is raised in a RAISE statement in the function module STRING_SPLIT, the system exits the function module and returns control to the calling program. The return code, which you should evaluate directly after the CALL FUNCTION statement, now contains the value 7.
Note
Runtime errors:
RAISE_EXCEPTION: The caller did not handle the exception that was triggered.
Related
MESSAGE ... RAISING
Additional help
Creating Function Modules

Regards,
Rich Heilman

Raising Exception

Hi all,
I am raising exception in Function Module but catch in my Report. So can any body tell me how to do it?
Any Help will be rewarded.
Sachin

Sample code to display whether year is a leap year or not....
PARAMETERS:
P_YEAR TYPE I. " year
DATA:
W_RESULT TYPE C.
CALL FUNCTION 'ZFUNC'
EXPORTING
 YEAR = P_YEAR
IMPORTING
 RESULT = W_RESULT
EXCEPTIONS
 NEGATIVE_NUMBER = 1
 OTHERS = 2.
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
WRITE ' error '(001).
ENDIF.
IF W_RESULT EQ 0.
WRITE: ' leap year'(002).
ELSE.
WRITE: ' Not a leap year'(003).
ENDIF.
Here while you are developing a Function Module, in the exceptions tab, remember to display the exception numbers.
Regards,
Pavan

Re: Raising Exceptions Vs returning erro[Ref:C809787]

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Exception with the type CX_SY_OPEN_SQL_DB occured and was not handled

Hi Champs,
I am working on an interface which picks up file uploaded in a XI server and process it. The Function module used is a Z function module, developed locally.
I am uploading an tab limited file in XI server and a background job processes the file. The tab limited file contains Payelement Transaction ID as primary key. And after validation of elements like WBS element, cost center etc the file is posted using BAPI BAPI_ACC_DOCUMENT_POST. And all the Payelement Trans Ids are also replicated in a Z table, with there status viz. Success or Error or Warning.
After background job was completed, we found in Tcode SXMB_MONI that the file was in error.
The error message was :
Error during proxy processing An exception with the type CX_SY_OPEN_SQL_DB occurred, but was neither handled locally, nor declared in a RAISING clause The system tried to insert a data record, even though a data record with the same primary key already exists.
But to my dismay, I found that some of the Payelement Trans Ids were posted for a document and are also replicated in my Z table.
From the error it seems that we are inserting a record that is already there in the document. I have checked in for BAPI's input parameter, there is nothing duplicate.
Note: Insertion in Z table is made after the BAPI BAPI_ACC_DOCUMENT_POST.
Can you help me out in this issue as it is now getting into veins
Reagrds,
Nishant

Hi,
Even we have faced this kind of issue. In order to solve this just write the following code:
1) Before inserting records in to Z table, write one select query on that table with primary key fields in where clause. Pass the value that are returned by BAPI BAPI_ACC_DOCUMENT_POST to the key field.
2) If sy-subrc = 4, insert records in Z table else Continue and dont insert records in this table.
This will solve your problem.
Regards,
Prashant

ECL Viewer 5 raise exceptions viewing tif drawings

Hello all,
Bit of a strange one here that hopefully someone may be able to help me with...
We are (still) running 4.6C, on Ora 9.2.0.7 over Windows.
We are running 640 Gui patched to 24
We have deployed (in a failed attempt to stop the error I will describe below) ECL viewer 5.1.3.
Client machines are running XP with SP2
Error:
after entering MM03 and choosing Additional Data > Document Data we click on an attchment (doc type DRG) and choose to view via the display (glasses) icon. The tif file (which is copied into C:\temp) opens. many of the tif files (scanned drawings) have multiple pages so we move to the next page by clicking 'Navigation' > 'next'.
The problem is that after a seemingly random amount of clicks on to next pages a raise exception occurs. After the short dump it is no longer possible to view the document again as we get the error 'file c:\temp\xxxxx.tif cannot be created' and so the only way to view the drawing is either to access the file from the temp directory or completly log out of SAP and relog back in.
i have searched for notes and we were advised to deploy the 5.1.3 viewer which only seems to have made it worse because before the 5.1.3 deployment we were getting many short dumps but the user oddly didn't see the short dump on their screens - now 5.1.3 is in place the user now sees the short dump and calls the support desk very often.
Has anyone been unfortunate enough to have experienced this before or anyone got any brain waves????
yours thankful in advance and loosing the will to live,
Andy
ps here is the short dump extract:
                                                                                Error analysis
A RAISE statement in the program "CL_GUI_CFW====================CP " raised the
exception
condition "CNTL_ERROR".
Since the exception was not intercepted by a superior program
in the hierarchy, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
How to correct the error
If the error occurred in a non-modified SAP program, you may be
able to find a solution in the SAP note system.
If you have access to the note system yourself, use the following
search criteria:
"RAISE_EXCEPTION"
"CL_GUI_CFW====================CP " or "CL_GUI_CFW====================CM00P "
"UPDATE_VIEW"
or
"CL_GUI_CFW====================CP " "CNTL_ERROR"
or
"SAPMMG01 " "CNTL_ERROR"
If you cannot solve the problem yourself, please send the
following documents to SAP:
1. A hard copy print describing the problem.
   To obtain this, select the "Print" function on the current screen.
2. A suitable hardcopy prinout of the system log.
   To obtain this, call the system log with Transaction SM21
   and select the "Print" function to print out the relevant
   part.
3. If the programs are your own programs or modified SAP programs,
   supply the source code.
   To do this, you can either use the "PRINT" command in the editor or
   print the programs using the report RSINCL00.

Hi Andy,
I would recommend you to upgrade to the latest available ECL Viewer version 6.
Please see SAP note 1083901.
Further please upgrade also your SAPGUI to the latest patch level as explained in note 164203. After this upgrade please un-install your ECL Viewer 5.1.3 by using one of the following mehtods:
Search for WebViewer2d.dll file. If it is present at more than one place then it means ECL Viewer is installed more than once without uninstalling the previous version (You can check the folders and should be able to see all the dll's for ECL Viewer such WebViewer3d.dll/Printing.dll etc to make sure that there is not only single file but the whole installation).
In this case:
A) Uninstall the version integrated with SAP GUI by using SAP Installation scripts. You need to uncheck the 'EAI Viewer' component in 'General Add-on' option.
B) Check add/remove program and if there is an entry like SAP Viewer, uninstall it.
After this search again, and you should not get WebViewer2d.dll file on machine. Now reinstall the latest Viewer. This should solve most of the issue related to inconsistencies.
Then install the latest ECL Viewer 6 and the issue should be solved.
Best regards,
Christoph

Raising exceptions in PL/SQL

Hi Friends
I have the following code:
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
end;
I will be having about 6-7 million rows every month to process. To raise exceptions, I am thinking of either of the following options:
Option 1_
declare
var1....
var2....
var3 exception;
var4 exception;
var5 exception;
cursor c1
begin
insert stmt;
update stmt;
IF SQL%NOTFOUND then
var3;
end if;
update stmt;
IF SQL%NOTFOUND then
var4;
end if;
for r1 in c1 loop
end loop;
IF SQL%NOTFOUND then
var5;
end if;
Exception
when var3 then blah blah
when var4 then blah blah
when var5 then blah blah
end;
Option 2_
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
Exception
when others then blah blah
end;
In terms of performance, which option is better? And is there any better option?
Thanks....

In terms of performance, which option is better? And is there any better option?If you consider in terms of performance i think you cant find any difference in both ways.
But your both code does not do the same thing. They are entirely different. They are not the same.
For example, If your UPDATE statement fails with a Too many rows error what will happen.
In the first procedure the procedure will raise the error to the client. But in the second case the error is caught by the WHEN OTHERS block.
So now here the real thing is what you do in the WHEN OTHERS block. Do you suppress the error? Do you return NULL? What do you do, That is what matters.
Your Bla..Bla..Bla.. part in the EXCEPTION is very important. Most of them do mistake there.
WHEN OTHERS is a great feature. But it must be used properly. Its like a very sharp knife. If you dont use it properly there will be blood.

Raising exceptions in event handlers?

Hi
Is it possible to raise exceptions in event handler? As an example, I added a listener to a UnitOfWork, and implemented the preCommitUnitOfWork() method. In the method, I'm performing some operations, and if something goes wrong, I need to roll back the entire UnitOfWork. Is this possible to raison an exception, or is there some other way to acheive this?
Thanks
Regards
Eric

Hi
Is it possible to raise exceptions in event handler? As an example, I added a listener to a UnitOfWork, and implemented the preCommitUnitOfWork() method. In the method, I'm performing some operations, and if something goes wrong, I need to roll back the entire UnitOfWork. Is this possible to raison an exception, or is there some other way to acheive this?Eric,
I tried this and had some success with a simple test case. I created an exception that extends the oracle.toplink.exceptions.TopLinkException class. Then I added the throws clause to the preCommitUnitOfWork event handler. Throwing my custom exception (that extends TopLinkException) from the event handler works fine and should allow you to retry your update, etc. Note that as long as the exception is thrown at "preCommit" time you should not need to roll anything back as the updates were not applied to the cache or DB. Also, if you applied updates to your registered clones instead of the original objects, the original objects state should be unchanged.
Hope this helps,
Pete Farkas

PI - Proxy processing An exception with the type CX_SY_CONVERSION_NO_NUMBER

Hi All,
We have PI sync scenario,SOAP to Proxy.
We are geeting the below error in Proxy .
Error during proxy processing An exception with the type CX_SY_CONVERSION_NO_NUMBER occurred, but was neither handled locally, nor declared in a RAISING clause The argument ' 1,000.000' cannot be interpreted as a number.
But when the same data got updated in Proxy.Not sure about the root cause of the error.
Regards,
Arun

Hi ,
It looks like proxy is not able to convert string to number or the format of number is incorrect. This is only possible reason of this exception.
The argument ' 1,000.000' cannot be interpreted as a number.
Check out if the format is correct.. .
Regards
Aashish Sinha

DYNAMIC_CALL_FAILURE Error during proxy processing An exception with the ty

Hi,
SRM 7.0 contains 2 clients:
Sender: 100 for EBP, logical system is CLNT100
Receiver: 200 for SUS, logical system is CLNT200
both the clients are connected through PI 7.0, logical system of PI is CLNT001.
From SPROXY of 100EBP, i'm executing the outbound proxy, in moni sent msg success.
In PI also msg is processed.
But in SUS200, it is showing below error msg:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
<SAP:Category>XIProxy</SAP:Category>
<SAP:Code area="ABAP">DYNAMIC_CALL_FAILURE</SAP:Code>
<SAP:P1>UNCAUGHT_EXCEPTION</SAP:P1>
<SAP:P2>CL_BBPX_TRADING_PARTNER_SUS_IN</SAP:P2>
<SAP:P3>EXECUTE_ASYNCHRONOUS</SAP:P3>
<SAP:P4 />
<SAP:AdditionalText />
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Error during proxy processing An exception with the type CX_BBPX1_STD_MESSAGE_FAULT occurred, but was neither handled locally, nor declared in a RAISING clause Application Error</SAP:Stack>
<SAP:Retry>M</SAP:Retry>
</SAP:Error>
Pls help in resolving the same....
tnx n rgds,
balu

Hi,
How did you solve the issue? Can you please provide the solution.
Thanks,
-Devi Swain

An exception with the type CX_SY_CONVERSION_CODEPAGE occurred

Hi Friends,
i gonna mad by applying all notes related to this error but still i am not getting the abap report as bsp application, the notes i applied manualy are listed below
834521
849287
851753
853589
Runtime Error:
+Business Server Page (BSP) error
What happened?
Calling the BSP page was terminated due to an error.
SAP Note
The following error text was processed in the system:
An exception with the type CX_SY_CONVERSION_CODEPAGE occurred, but was neither handled locally, nor declared in a RAISING clause
Exception Class CX_SY_CONVERSION_CODEPAGE
Error Name CONVT_CODEPAGE
Program SAPLSURL
Include LSURLF01
Line 309
Long text Bei der Zeichensatzkonvertierung wurde entweder ein Zeichen entdeckt, welches in einer der Codepages nicht dargestellt werden kann, oder festgestellt, daß diese Konvertierung nicht unterstützt wird.
Error type: Exception
Your SAP Business Server Pages Team+
i am using
Component version SRM 4.0 ( SRM Server 5.0 )
SAP_BASIS 640 ( highest support - SAPKB64011 )
SAP_ABA 640 ( highest support - SAPKA64011 )
Unicode system - Yes
Bsp code used
On Create
this handler is called once the page is first created (stateful mode)
it performs a once-off data initialization or object creation
data: listobject type table of abaplist. " occurs 10.
data: report_name type syrepid.
data: output_str type string.
submit ZTEST_YOGESH
using selection-set 'TEST' and return
exporting list to memory .
call function 'LIST_FROM_MEMORY'
tables
listobject = listobject
exceptions
not_found = 1
others = 2.
try.
call function 'WWW_HTML_FROM_LISTOBJECT'
exporting
template_name = 'WEBREPORTING_REPORT'
tables
html = html
listobject = listobject.
CATCH cx_sy_conversion_codepage.
ENDTRY.
+
Layout+
<%@page language="abap"%>
<% data: html_wa type w3html.
clear: html_wa . %>
<% loop at html into html_wa. %>
<%= html_wa %>
<% endloop. %>
could any one give me any light on this, your help would be greatly apreciated.
Thanks
Message was edited by: Murugadass Krishnan

Hi,
Pls don't forget to reward points and close the question if you find the answers useful.
Eddy

Catching errors in Web Dynpro for Java when thrown from RFC Raise Exception

Hello Developers,
I'm looking for information that explains how a Web Dynpro for Java application responds and processes errors that are thrown from a Raise Exception event within an RFC.
The Exceptions do not appear to be part of the Model and I can't identify how they get processed.
When rfc HRXSS_CAT_WD_RECORD raises exception PERNR_NOT_LOCKED this exception is passed back to the calling webdynpro CAT DC that displays the exception on the web page along with the log.
I would like to display a friendlier message and without the log. Any information on how to customize the handling of this error would be greatly appreciated.
Thank you,
Terry

[see here|https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.highlightedcontent?documenturi=%2flibrary%2fuser-interface-technology%2fwdJava%2FHowtoHandleExceptionsEffectivelyWhileWorkingwithWebDynproJava%28WDJ%29.pdf]

Error during proxy processing An exception with the type CX_BBPX1_STD_MESSA

Hello,everyone!
My PI version is 7.11,SRM SUS version is 7.0,ECC version is 6.0 ,When I import XI SRM CONTEN,sending IDOC in ECC,there is a error some of the mesages:
<SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
<SAP:Category>XIProxy</SAP:Category>
<SAP:Code area="ABAP">DYNAMIC_CALL_FAILURE</SAP:Code>
<SAP:P1>UNCAUGHT_EXCEPTION</SAP:P1>
<SAP:P2>CL_BBPX1_SUSPO_IN</SAP:P2>
<SAP:P3>EXECUTE_ASYNCHRONOUS</SAP:P3>
<SAP:P4 />
<SAP:AdditionalText />
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Error during proxy processing An exception with the type CX_BBPX1_STD_MESSAGE_FAULT occurred, but was neither handled locally, nor declared in a RAISING clause Application Error</SAP:Stack>
<SAP:Retry>M</SAP:Retry>
</SAP:Error>
Detialed error from SXMB_MONI,
Error in XI interface: Exception occurredE:BBP_PD:147 -Enter a country for partner 0015111411 with type 'Vendor' I:R5:553 -'Different country' field contents deleted because identical to 'Country' E:BS:002 -"Create" is not allowed (SUS Purchase Order 7100076527 ) Program: CX_BBP_BD_ERROR===============CP; include: CX_BBP_BD_ERROR===============CM002; Line:
This issue only ocuured for partner 0015111411, but we tried with other partner ID and those messages are processed sucessfully and PO is created.
I have a doubt that, is there functionality in proxy to compare the country with partner in SRM system. Could please anyone help me one the same.
Regards,
Baskaran K

HI,
This is a standard proxy. I'm not sure how to debug the proxy with payload. Could you please tell me the steps.
We have one more error message
<FAULT_TEXT>Error in XI interface: Exception occurredE:BBP_PD:147 -Enter a country for partner XY91 with type 'Sold-to Party' E:BS:002 -"Create" is not allowed (SUS Purchase Order 7100076526 ) Program: CX_BBP_BD_ERROR===============CP; include: CX_BBP_BD_ERROR===============CM002; Line: 57</FAULT_TEXT>
Is there any table to check these details like Sold-to Part, Vendor etc in SRM system?
Regards,
Baskaran K

Raise exception with parameters

Similar Messages

Maybe you are looking for