Look at this flow diagram from the Main Page of a process in Process Studio:
Thinking about the standard Blue Prism Process Templates, what is wrong with how this Main Page is handling exceptions?
Look at this flow diagram from the Main Page of a process in Process Studio:
Thinking about the standard Blue Prism Process Templates, what is wrong with how this Main Page is handling exceptions?
In the standard Blue Prism Process Templates, correct exception handling includes the capability to differentiate between various types of exceptions that might occur. This prevents marking every item in the Work Queue with the same System Exception, allowing for proper categorization and handling of different errors. The flow presented does not account for this as it lacks concurrent exception logic, meaning it would mark every item with the exact same System Exception without distinguishing between different issues. Hence, the main issue with the process in the image is the lack of concurrent exception logic to ensure proper handling and categorization of exceptions, which is why the correct answer is D.
Answer is A according to Udemy binkis tests. It follows blue prism template
So there is a mistake, since correct answer is D. Presented template is shown in materials from BP training, but it's not the final version - some improvemts can be done, like in answer D
Isn't it Option D?
A is correct
I vote for A. Because this flow can be found in Best Practices document on page 17 and 18, D is also seemed correct but this flow can be stopped manually by "Stop ?" decision stage if concurrent exception occurred. And E is also seemed correct but in Best Practices document resetting application logic is added on subpages. (page 19)
Correct answer is A.
A is not correct answer, since logic for checking consequitive exceptions is also part of BP Process Template (ans D)
Answer should be D and E D Because - In the diagram the action is used to mark the item as exception where as the standard template has a page called which has concurrent exception handling and mark exception logic inside D Because - after the recover stage there should be a calculation variable to capture the type and details of the exceptions so that we can mark the item as exception accordingly.
E is not correct, since such logic (for resetting applications) should included after 'Mark item as exception' - otherwise, there is a chance to not execute 'Mark item as exceptio' if resetting aplication fails
D is the answer, it is not a template, no exception info is collected, you need a multi-cal Exception Data between Recover and Resume
D is correct
D is the correct answer.
Looks like Template, A
For Sure
Create Quotes page need to reset for ready the next case.
E is the correct answer. Create Order page need to reset for ready the next case.
E is not correct, since such logic (for resetting applications) should included after 'Mark item as exception' - otherwise, there is a chance to not execute 'Mark item as exceptio' if resetting aplication fail
I think it is D
I think it's D. In my opinion Option A is not true because the 'Mark Item as Exception' is a stage and not the page like shown in this image. The BP Process Template calls 'Mark Item as Exception'' page where it does categorize the errors.
B is definitely wrong. I vote for A.
I changed my mind. I vote for D.