Interview question - Scenario based

Help Activities
, , ,
1

Hi All,

First thing is “Invalid passowrd” for login application will come under business exception or application exception.
if it is business exception then we no need to retry right?
and if this login part is created in the InitAllApplication.xaml file then how will handle business exception?(May be we need to alter REFramework and add one more transaction for Buisness Exception and come to end process)

Thank you

2

“Invalid Password” is a Business Exception, so no retry is needed.
Modify InitAllApplications.xaml to Detect Business Exceptions

  1. In InitAllApplications.xaml**, surround the login logic with a Try-Catch.
  2. Inside the Catch Block:
    If the error is “Invalid Password”, throw a BusinessRuleException.
    Otherwise, rethrow the Application Exception.
  3. Modify Main.xaml:
    After catching a Business Exception, stop the process immediately and go to the End Process state.
1 Like
3

@Sharan99
“Invalid Password” is a Business Exception as it occurs due to incorrect input, not a system failure. Business Exceptions should not be retried in REFramework since retrying won’t resolve incorrect credentials. If login is in InitAllApplications.xaml, handle it by wrapping the login logic in a Try-Catch, catching BusinessRuleException, and transitioning directly to End Process in Main.xaml. Alternatively, treat login as a separate transaction before the main process. This ensures proper handling without unnecessary retries. Modifying REFramework this way allows structured handling of login failures while maintaining automation efficiency. Hope this helps! :rocket:

1 Like
4

In this case, the type of exception is completely irrelevant, as long as it is caught, and the type of error is fed back properly. The conclusion is that an application login failed, and your process should be able to handle that. The rest is just flavour or for reporting purposes.

To me personally this would be a system exception though. For me a businessrule exception is any form of pre thought of process rule that can happen on a transaction. Expired or incorrect passwords would require direct action from an operator, while a failed transaction with a BE might only be the responsibility of some key user when it suits him/her. Using a SE here would indicate its urgency, as well as making sure the entire job gets a status failed.

Taking a soft BE approuch here and transitioning the end process normally might report the job complete, showing ‘green’ in Orchestrator, and nobody takes any action.

You do want to prevent any form of retry in it, since we all know what can happen to an account if you enter the wrong credentials a few times in a row. Since REF is the assumed main flow, and opening applications usually performed in the init part, it will transition to end process with any exception, so no special coding would be needed.

But hey, this is just ‘my’ preference :wink:

2 Likes
5

Hi @Sharan99

If the credentials are incorrect or invalid password, this will treat this as a business exception. Repeated attempts with the wrong credentials will result in the same error message. Since the application will not allow login with incorrect credentials, retrying does not serve any purpose. Therefore, there is no need to retry when encountering business exceptions.

Hope it helps!!

6

if it works please mark as resolved .
Thank you

7

@Sharan99

Welcome to the community

Business exceptions are those which are to be corrected by process users or process owners…

For this case as the support team would be taking care we can consider as system exception

And generally in initapp there are no retry anyways so it would not retry

But again if the application creds are managed by business then its ideal you consider as bus exception and report it

Cheers