cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Error Handling in Self-Service

What I would most like to have happen is for an error to 1) been shown to the user and 2) for the CloudApp to end up in a "failed" or "terminated" state as quickly as possible.
 
For #1 - the only way I know of to do this properly is via 'raise' because my end users don't have access to the Audit Entry logs. Related to this, I've found that only users with higher levels of permissions are able to see the full text of an error message whereas normal users only get the first line of an error message in the Self-Service UI and don't get anything in the email generated upon failure. Is there perhaps a different way of alerting the user to an error that I'm not aware of?
 
For #2 - I've found that cancel and abort end up hiding the error message from raise ...breaking my #1 desire. If I just let the raise happen, it can take many many seconds for the CloudApp to eventually reach failure. I've also implemented a scheduled_action to terminate in now()+10s which also causes an unnecessary delay.
 
So...what's the best way to a) show an error to the end user and b) fail/terminate the CloudApp as quickly as possible?
(5) Replies

For #1 The Activity Stream is limited as far as providing a full auditing stream of events and you are correct having a raise statement allows you to quickly notify the user that something unexpected has happened.
I'm interested to learn more about the visibility of the error message, I'm unaware of a filter we set in the Activity Stream based on a role.

For #2  Is this mostly a requirement while in development of a CAT ?
How quickly a Cloud App fails, is going to depend, does it fail to launch a resource, does it happen after provisioning ? etc
The Cancel and Abort are signals to the instantiation of the CloudApp, so you never hit the raise statement in that case. You're halting the process before it enters that block.

I'd like to understand the use-case for decreasing failure times, I understand it takes many seconds in it's current state.

Thank You

Thanks for your response Edwin!

 

1 - When you raise something via CAT, the Activity Stream only shows the first few lines to a non-admin user.  If I want to show them more depth, I can't.  Additionally, the email that my users get when a CloudApp fails only says it failed and contains NO further error info.  However, the same email being sent to me (as an admin) includes error content

 

2 - No, this requirement isn't just during development, it's about giving my users a timely experience when a failure happens.  I understand that the time to _detect_ a failure may vary depending on what the failure is, but I am expecting that once the failure is detected I can alert the user as quickly as possible.  This does not seem to be the case as it takes minutes after a 'raise' is issued for the message to show up in the UI, and then minutes more before the CloudApp is actually marked as "failed".  

 

Thanks for your help!

 

Perry

Any updates on this Edwin?
Hi Perry

Sorry for the delay. Reviewing your feedback today.

Hi Perry

 

#1 I believe you can include the error message into the raise statement, You are correct that based on your role you don't get the full error msg.

 

#2 The "delay" you are experiencing is likely due to our polling for the state of the execution.

 

If you'd like we cant take this offline and I can review a CAT for #1. I'll check with product if there are any levers we can tweak for #2.

egonzalez @ flexera.com. 

 

Thanks.