Date: Fri, 29 Mar 2024 13:23:34 +0100 (CET) Message-ID: <1292512967.3669.1711715014484@263d865a522e> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3668_917236878.1711715014484" ------=_Part_3668_917236878.1711715014484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The AJAX Errors are caught within the State Machine Diagram. The <<UIStates>> are wrapped b=
y a surrounding Composite State which will catch all exceptions and errors =
which might occur and then delegate these via <<UIErrorTransitions>> to the error handling
The definition of which type of AJAX error, a fault or a connection erro= r, should be caught, depends on how the <<UIErrorTransitions>> are specified. Any fault or err= or happening within the <<UIStat= es>> and are held by the Composite State will be caught.
Due to almost all UI requests going to an xUML service, the service exce= ptions need to be caught and delegated to the user interface. The exception= signal/event holds more information on the error that occurred and all thi= s information can be displayed to the user.
As seen in the above figure, a service handling an AJAX request, sends a= n <<Exception>> . T= his exception will be caught by the xUML UI and can be e.g. display that er= ror to a user as below figure shows.
The Exception signal is caught within the <<UIErrorTransition>> where it is sent to a JavaS= cript operation having this fault event as an input object. The JavaScript = operation is defined on the <<UI= >> controller and is registered in the call properties of the = <<UIErrorTransition>> as seen in below figure.
The <<UIErrorTransition>&g= t; further defines which type of error should be caught by defining = the ajaxFaultCode as well as the ajaxFaultType. In case of the above figure all exceptions are caught by using the *= ** in both cases. This allows having different user interfaces for differen= t types of errors.
Figure: Configuration to Catch AJAX Faults
The JavaScript operations input object has to be of type UISOAPE= rrorMessage. The object holds the following information.
Attribute | Description |
---|---|
code | An error code, defined and set in the service wh= ere the <<Exeption>> signal is sent. |
type | The type of error, defined and set in the servic= e where the <<Exeption>>= span> signal is sent. |
description | A description of the error, defined and set in t= he service where the <<Exeption&= gt;> signal is sent. |
category | The category of the error e.g. User or System |
Connection errors occur when a request to a service times out or is not = possible at all due to the service is e.g. not running. The error which is = caught returns back the URL it tried to connect to. The implementation with= in the model follows the same principle as with AJAX faults. The error is c= aught by the Composite State and is redirected to the <<UIErrorTransition>> which handles the = connection error. The difference is in the settings of the transition.
To catch connection errors, the parameter onAjaxConnectionError<= /strong> needs to be set to true. The JavaScript operation called has an in= put parameter called url and is of Base Type String.