Crm_ic created raised exception

Hello,
I tried to run tcode crm_ic but I got following error message from the internet explorer:
The following error text was processed in the system CRO : Exception
condition "COMMUNICATION_ERROR" raised.
The error occurred on the application server sap1770_CRO_01 and in the
work process 0 .
The termination type was: RABAX_STATE
The ABAP call stack was:
Method: CREATE_SESSION of program CL_SAM_BSP_SESSION_LAUNCHER===CP
Method: START_WORKER_SESSION of program CL_ICWC_SESSION_REGISTRY======CPMethod: ONCREATE of program CLO23UTXK1DHIM8WX0QZD2TBW2KZ9CP
Method: %_ONCREATE of program CL_O23UTXK1DHIM8WX0QZD2TBW2KZ9CP
Method: DO_INIT of program CL_BSP_PAGE===================CP
Method: GET_PAGE_CONTEXT_CURRENT of program
CL_BSP_CONTEXT================CP
Method: ON_REQUEST_ENTER of program CL_BSP_RUNTIME================CP
Method: ON_REQUEST of program CL_BSP_RUNTIME================CP
Method: IF_HTTP_EXTENSION~HANDLE_REQUEST of program
CL_HTTP_EXT_BSP===============CP
Method: EXECUTE_REQUEST of program CL_HTTP_SERVER================CP
Below is the abap dump message:
Runtime Errors RAISE_EXCEPTION
Date and Time 14.05.2007 04:05:51
Short text
Exception condition "COMMUNICATION_ERROR" raised.
What happened?
The current ABAP/4 program encountered an unexpected
situation.
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
administrator.
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
Error analysis
A RAISE statement in the program "CL_SAM_BSP_SESSION_LAUNCHER===CP" raised the
exception
condition "COMMUNICATION_ERROR".
Since the exception was not intercepted by a superior
program, 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 occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"RAISE_EXCEPTION" " "
"CL_SAM_BSP_SESSION_LAUNCHER===CP" or "CL_SAM_BSP_SESSION_LAUNCHER===CM002"
"CREATE_SESSION"
or
"CL_SAM_BSP_SESSION_LAUNCHER===CP" "COMMUNICATION_ERROR"
or
"SAPMHTTP " "COMMUNICATION_ERROR"
If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:
1. The description of the current problem (short dump)
To save the description, choose "System->List->Save->Local File
(Unconverted)".
2. Corresponding system log
Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".
3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".
4. Details about the conditions under which the error occurred or which
actions and input led to the error.
System environment
SAP-Release 700
Application server... "sap1770"
Network address...... "217.67.56.37"
Operating system..... "Windows NT"
Release.............. "5.2"
Hardware type........ "4x Intel 801586"
Character length.... 16 Bits
Pointer length....... 32 Bits
Work process number.. 0
Shortdump setting.... "full"
Database server... "SAP1770"
Database type..... "MSSQL"
Database name..... "CRO"
Database user ID.. "cro"
Char.set.... "C"
SAP kernel....... 700
created (date)... "Jan 15 2006 23:05:36"
create on........ "NT 5.0 2195 Service Pack 4 x86 MS VC++ 13.10"
Database version. "SQL_Server_8.00 "
Patch level. 41
Patch text.. " "
Database............. "MSSQL 7.00.699 or higher, MSSQL 8.00.194"
SAP database version. 700
Operating system..... "Windows NT 5.0, Windows NT 5.1, Windows NT 5.2"
Memory consumption
Roll.... 8176
EM...... 4180896
Heap.... 0
Page.... 24576
MM Used. 3736976
MM Free. 442176
User and Transaction
Client.............. 100
User................ "DIAGBASIS"
Language Key........ "E"
Transaction......... " "
Program............. "CL_SAM_BSP_SESSION_LAUNCHER===CP"
Screen.............. "SAPMHTTP 0010"
Screen Line......... 2
Information on Caller ofr "HTTP" Connection:
Plug-in Type.......... "HTTP"
Caller IP............. "172.27.104.12"
Caller Port........... 8001
Universal Resource Id. "/sap/bc/bsp/sap/ic_base/main.htm"
Information on where terminated
Termination occurred in the ABAP program "CL_SAM_BSP_SESSION_LAUNCHER===CP" -
in "CREATE_SESSION".
The main program was "SAPMHTTP ".
In the source code you have the termination point in line 23
of the (Include) program "CL_SAM_BSP_SESSION_LAUNCHER===CM002".
Source Code Extract
Line
SourceCde
1
method CREATE_SESSION .
2
3
data: rfcdest type rfcdest.
4
data: status type i.
5
data: http_client type ref to if_http_client.
6
7
rfcdest = destination.
8
cl_http_client=>create_by_destination( EXPORTING destination = rfcdest IMPORTING client =
9
10
http_client->request->set_header_field( name = '~request_uri' value = uri
11
http_client->request->set_header_field( name = '~request_method' value = 'GET'
12
http_client->request->set_header_field( name = if_http_header_fields=>user_agent value = s
13
http_client->send( exporting timeout = 10 ).
14
http_client->receive( ).
15
data = http_client->response->get_data( ).
16
http_client->response->get_status( importing code = status ).
17
http_client->close( ).
18
19
data: s type string. "#EC NEEDED
20
s = cl_sam_toolkit=>x2s( data ).
21
22
if ( status <> 200 ).
>>>>>
raise communication_error.
24
endif.
25
26
27
endmethod.
Not sure how to solve this since couldn't find any relevant notes.
Thanks

Hi KZ,
i've run the CRMS_IC_CHECK and i got following message:
Check System Settings and Status
TIME:      09:33:53
   Configuration summary
   Domain:                                       sapdemo.local
   Context Area Style Sheet:
   Scratch Pad Style Sheet:
   Broadcast Style Sheet:
   General
      Server domains are compatible.
      Logical system: CROCLNT100
The J2EE and HTTP service is running. the CRM_IC is activated. I even got same error when i test the CRM_IC from sicf. Not sure how i can progress further.
Thanks

Similar Messages

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/>

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 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

Raising exceptions at Application Module

Hi there;
 For this simple example;
 public void autenticateUser(String pUser, String pPassw) {
 StringBuffer wStatement = new StringBuffer("Begin");
 wStatement.append(" PackUser.autenticate(:1, :2);");
 wStatement.append("End;");
 try
 CallableStatement cllS = getDBTransaction().createCallableStatement(wStatement.toString(),DBTransaction.DEFAULT);
 cllS.setString(1,pUser);
 cllS.setString(2,pPassw);
 cllS.execute();
 catch (Exception e)
 throw new JboException(e);
 PackUser.autenticate will run into an No_data_found exception when user is not found , and the " catch " will throw an jboException;
 In authenticate bounded adf task flow, i posted the login page fragment (whose will run into an region) , the doAutenticate flow control , the am' binding authenticate user setting the parameters for enviromentBean (userName, passWord and so one ... ) and finally the errorPage configured as exception handler.
 Finally
 My jboException was raised, but my errorPage never was called ? as a meter of fact i received the " no_data_found error " inside one popup window.
 Does adf-task-flow not recognize Am's jboExceptions's interface (class errors) to re-route errors page ?
 _Or Maybe it's not an best practice to raise exceptions into an Application's data modules to "annunciate" BI constraints !_
 Many thanks ...
Marcos Ortega
 Brazil

Hi,
I'ts almost always best practice to return a result to the UI when calling an AM or VO method.
If you want to get a bit more fancy, you can return a String array containg a result and a message. Eg.
 // AM Method
 public String[] addLocation(Number locationId, String locationCode) {
 try {
 // Do some stuff
 } catch (Exception ex) {
 ex.printStackTrace();
 return new String[] {"Error", ex.getMessage()};
 return new String[] {"Success", "This location has been added."};
 }Drag the method onto the page to create a parameter form and page bindings.
You can then access the method results on the page declaratively like this:
 <af:panelHorizontal rendered="#{bindings.addLocation.result[0] == \'Error\'}" partialTriggers="add">
 <af:objectIcon name="error" rendered="#{bindings.addLocation.result[0] == \'Error\'}"/>
 <af:objectSpacer width="5" height="10"/>
 <af:outputText value="#{bindings.addLocation.result[0]} : #{bindings.addLocation.result[1]}"
 styleClass="x3s"
 inlineStyle="font-size:smaller;"/>
 </af:panelHorizontal>Brenden

Create a Exception Class

hi all ,,
can any one tell me how to create a exception class in ABAP OOPS concept ??
if possible can give link also for document

HI Jayakumar,
Please go thru this document
Exceptions are represented by objects that are instances of exception classes. Defining an exception is, therefore, the same as creating an exception class.
All exception classes must inherit from the common superclass CX_ROOT and one of its subordinate classes:
CX_STATIC_CHECK
CX_DYNAMIC_CHECK
CX_NO_CHECK
. The assignment of exception classes to one of these three paths of the inheritance hierarchy determines the way in which the associated exceptions are propagated. There is a record of predefined exception classes CX_SY_... whose exceptions are raised in error situations in the runtime environment. These classes all inherit from CX_DYNAMIC_CHECK or CX_NO_CHECK but not from CX_STATIC_CHECK (see hierarchy in the ABAP keyword documentation).
All exception classes must begin with the prefix CX_. They are usually defined globally with the Class Builder of the ABAP Workbench. Local exception classes can, however, also be defined.
Individual (abstract) exception classes that are used as the superclass of further exception classes can be defined. The exceptions of the subordinate classes can be handled together using a superclass.
Exception classes have the following features:
Constructor
The constructor must have a predefined structure and a specific interface. With global classes, the Class Builder generates the correct constructor and sets it to an unchangeable status. The constructor has two IMPORTING parameters:
TEXTID of the SOTR_CONC type
This parameter can be used to determine which of your exception texts the exception will use.
PREVIOUS of the CX_ROOT type
This parameter can be used to assign the PREVIOUS attribute a previous exception.
Methods
In exception classes, you can define your own methods. The following two predefined methods are inherited from the root class CX_ROOT:
GET_TEXT
Sends back the exception texts of a class (controlled by the TEXTID attribute) as a string.
GET_SOURCE_POSITION
Returns the program name, the name of a possible include program, and the line number of the statement that raised the exception.
Attributes
The attributes of exception classes are used to transport additional information on an error situation to the handler. The main piece of information is, however, always the fact that an exception of a particular class has occurred. The following attributes are inherited from CX_ROOT:
TEXTID
Used to specify the exception of a class more precisely by using several exception texts. Is evaluated in the GET_TEXT method.
PREVIOUS
If an exception is mapped to another exception, a reference to the original exception can be defined in this attribute via the EXPORTING addition of the RAISE EXCEPTION statement and by means of the constructor IMPORTING PARAMETER with the same name. This can result in a chain of exception objects. In the event of a runtime error, the exception texts of all the exceptions in the chain are output. Mapping an exception to another exception is only beneficial if the context in which the original exception occurred is important for characterizing the error situation.
KERNEL_ERRID
The name of the associated runtime error is stored in this attribute if the exception was raised by the runtime environment, for example, COMPUTE_INT_ZERODIVIDE with a division by zero. If the exception is not handled, precisely this runtime error occurs.
Parameters cannot be transferred to the constructor for this attribute. If the exception is raised with RAISE EXCEPTION, the attribute is set to initial.
Global Exception Classes
Global exception classes are defined and managed in the Class Builder. If the correct naming convention (prefix CX_) and the class type Exception Class is chosen when a new class is created, the Class Builder automatically becomes the Exception Builder.
The Exception Builder offers precisely the functionality required to define exception classes and generates independently-defined components that must not be changed. When classes are created, the category of the exception must be specified, in other words, whether it is to inherit from CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NOCHECK.
Tab Pages of the Exception Builder
The Exception Builder has the tab pages Properties, Attributes, Methods, and Texts.
The properties do not normally need to be changed.
Except for the four inherited attributes mentioned above, further public attributes can be generated by the Exception Builder. The contents of these attributes specify the exception more clearly and manage the exception texts.
All of the methods are inherited from CX_ROOT. New methods cannot be added. The instance constructor is generated automatically. It ensures that, when an exception is raised, the attributes have the right values. It also transfers the text of the superclass for an exception class whose exception text is not specified explicitly.
The instance constructor is generated on the basis of the attributes, which are set up on the basis of the exception texts. Changing the attributes in superclasses can, therefore, invalidate the constructors of subordinate classes. The constructors of subordinate classes can be regenerated under Utilities ® CleanUp ® Constructor.
Texts are a special feature of exception classes and the Exception Builder. For further information, refer to Exception Texts.
Local Exception Classes
Local exception classes can be defined for specific exceptions that only occur within one single ABAP program. The condition for a local exception class is that it inherits from one of the three classes CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NO_CHECK, or from their subordinate classes. An individual constructor and individual attributes can be created. Individual methods should not be created, however, and the methods of superclasses should not be redefined.
Examples of Local Exception Classes
report DEMO_LOCAL_EXCEPTION_1.
class CX_LOCAL_EXCEPTION definition
                        inheriting from CX_STATIC_CHECK.
endclass.
start-of-selection.
    try.
      raise exception type CX_LOCAL_EXCEPTION.
    catch CX_LOCAL_EXCEPTION.
      message 'Local Exception!' type 'I'.
endtry.
This example shows a minimal local exception class, which is simply the local representation of one of the three direct subordinate classes of CX_ROOT. It can be used in the program.
report DEMO_LOCAL_EXCEPTION_2.
class CX_LOCAL_EXCEPTION definition
                        inheriting from CX_STATIC_CHECK.
public section.
    data LOCAL_TEXT type STRING.
    methods CONSTRUCTOR importing TEXT type STRING.
endclass.
class CX_LOCAL_EXCEPTION implementation.
method CONSTRUCTOR.
    SUPER->CONSTRUCTOR( ).
    LOCAL_TEXT = TEXT.
endmethod.
endclass.
data OREF type ref to CX_LOCAL_EXCEPTION.
start-of-selection.
    try.
      raise exception type CX_LOCAL_EXCEPTION
                      exporting TEXT = `Local Exception`.
    catch CX_LOCAL_EXCEPTION into OREF.
      message OREF->LOCAL_TEXT type 'I'.
endtry.
In this example, the exception class from the previous example is extended to include an individual attribute and constructor. The IMPORTING parameter of the constructor must be supplied when the exception is raised (it is required here). The attribute can be evaluated in the handler of the exception.
report DEMO_LOCAL_EXCEPTION_3.
class CX_LOCAL_EXCEPTION definition
      inheriting from CX_SY_ARITHMETIC_ERROR.
public section.
    methods CONSTRUCTOR importing SITUATION type STRING.
endclass.
class CX_LOCAL_EXCEPTION implementation.
method CONSTRUCTOR.
    SUPER->CONSTRUCTOR( OPERATION = SITUATION ).
endmethod.
endclass.
data OREF type ref to CX_LOCAL_EXCEPTION.
data TEXT type STRING.
start-of-selection.
    try.
      raise exception type CX_LOCAL_EXCEPTION
            exporting SITUATION = `START-OF-SELECTION`.
    catch CX_LOCAL_EXCEPTION into OREF.
      TEXT = OREF->GET_TEXT( ).
      message TEXT type 'I'.
endtry.
In this example, an exception class is derived from one of the predefined exception classes for error situations in the runtime environment. An individual constructor is defined with an individual IMPORTING parameter that supplies the superclass constructor with this parameter. When the exception is handled, the exception text, as defined in the superclass, is read with GET_TEXT.

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

Raise exception while running ad hoc query

Hi,
I receive a "raise exception" when I try to run an existing ad hoc query in the work area: "standard area (client specific)". This does not happen when I when I create a new query or run a existing query in the work area:"Global(cross client)".
How can this be? Very thankful for answers:-)
-hilde

rohit,
just now my client informed that, he is getting same user group, not which he changed from AQB.
Please let me know if there is any other setting....
early reply appreciated..
thanks,
kumar

Workbench manager raising exception

I am converting Sybase 11.9 to Oracle 8.1.7.
While creating Oracle Model, the tool is raising exception for mapping user privileges. The exception is :
Sybase Source ModelMAP._MAPuserprivileges():1,invalid column index().
Any pointers as to how to fix this ?
Thx
Seema

Please e-mail
[email protected] Please include the %ORACLE_HOME%\omwb\log\error.log file
It may be a bug or you may just need to re-create your repository.

How to create an exception in query designer?

Hi,
I am new to BW. I created an exception and set the from and to limits with an alert level of green for an amount column. When I run this query in the web, it does not change the color to green for the condition in the amount column. What is the validity area of exception? Do I need to enter anything there? I am in BW 3.5

Hi,
You need to change the default option Result only to all the cells in the second tab(cell defining) of Exceptions in query designer.
http://help.sap.com/saphelp_nw04s/helpdata/en/68/253239bd1fa74ee10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/1a/615f64816311d38b170000e8284689/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/68/253239bd1fa74ee10000000a114084/frameset.htm
Hope this helps............
Rgs,
Ravikanth.

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

Error in Raising exceptions in a method and handling the same in the WF

Hi All
I tried to implement Raising exceptions in a method and handling the same in the workflow
in the same way given in SAPtechnical site .
1.by adding a error msg in exception parameter .
2. if the select query fails, to fetch the agent then :exit_return 9001 'ztable name' space space space.
3.in the Background activity in which this method is called there automatically one outcome appears ,and I hav acitvated that outcome and in that done what need to be done for that error handling - just send a mail to concern person .
4. in the normal outcome of the activity , the step to be executed are there .
but its not working , if exception come then the WF stuck there only . it do not follow the exception outcome .
Kindly help me , How can I do the exception handly in WF.
thanks & Regards
Kakoli

> That is usually the case - you catch an error in the underlying program and pass that back so the workflow can go into error.
> You're doing it correctly.
I don't think that's quite right.
If you define an error/exception in a method, it is automatically mapped to an outcome of the step/task.
If you activate that outcome, then you can handle the exception in a branch of the workflow.
For example: 'Remote connection is down, please contact Basis'
The step should only go into error if an outcome occurs that you have NOT activated.
So the original question is valid. Please give some more information on what the error message is..
chrs
Paul

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 WDA?

Hi,
   I want to know about raising exception in wda. Please explain in details.
Scenario: I have one input field as mandatory. if i click the button without filling that input field, self defined exception should raise. How to do this?
Thanks,
Gopi.

hi ,
place a UI message area in the RootElement Containeru cn make use of control wizard ( CONTROL + F7) to generate error or exception messages
select the radio button , generate messages and choose the method report_error_message
this code wud be automatically generated thru code wizard
* get message manager
DATA lo_api_controller     TYPE REF TO if_wd_controller.
DATA lo_message_manager    TYPE REF TO if_wd_message_manager.
lo_api_controller ?= wd_this->wd_get_api( ).
CALL METHOD lo_api_controller->get_message_manager
RECEIVING
    message_manager = lo_message_manager
* report message
CALL METHOD lo_message_manager->report_error_message
EXPORTING
    message_text              =   'Error_Text' " Give your error text here.
regards,
amit

BPM-Raise Exception does not work

I have designed the BPM in following way.
1. Receive step - Receive Asynchronous message
2. Defined the Block - DB
3. Send step 'A' to JDBC - inside the Block-'DB' - Acknowledgement-Transport, Exceptions System Error-DB, Receiver from-Send context.
4. Created an exception handler and Selected 'DB' as exception handler for the property of the exception handler branch.
5. Inserted the Send step-'B' to send mail inside the exception handler branch by using the MAIL receiver adapter.
We want send the message to update database by using JDBC adapter but if it fails to update database then we want send an e-mail to outlook.
But it looks like it is not working when it fails to update database.
Can someone please help me?
Thanks in advance!

Hi,
According to the SAP online help documentation for the receiver JDBC adapter:
The receiver JDBC adapter supports system acknowledgments but not application acknowledgments.
What you will need to do is either get a system error triggerred by the adapter (which basically throws up the red flag and tells XI that the message could ot be delivered successfully) , or get the application to trigger a fault message back to the adapter. I have not worked with the JDBC adapter, so I cant tell you in more detail.
Here are some links that I have been able to find that might help you...
Statuses in the monitor :
http://help.sap.com/saphelp_nw04/helpdata/en/ea/2f053d39177608e10000000a114084/frameset.htm
Dealing with Exceptions in BPM
http://help.sap.com/saphelp_nw04/helpdata/en/33/4a773f12f14a18e10000000a114084/frameset.htm
Cheers
Manish

Crm_ic created raised exception

Similar Messages

Maybe you are looking for