Business Object Design for a Web Application with Dynamic Elements
A Blue Prism business object is being developed to interact with a web-based CRM application. The application uses dynamic IDs for elements (e.g., 'input_12345') that change on each page load. The object currently uses hardcoded IDs captured during development, causing frequent failures when the application is updated or when IDs change. The object has actions like 'Login', 'CreateCustomer', and 'SearchCustomer'. The 'CreateCustomer' action fails intermittently with 'Element not found' errors. The web application also has a modal dialog that sometimes appears asking for feedback, which blocks interaction. The business requires the object to be reusable across multiple processes and resilient to minor UI changes.
1. How would you redesign the business object to handle dynamic element IDs and the occasional modal dialog?
Read the worked answer
To handle dynamic IDs, avoid using hardcoded IDs. Instead, use more stable attributes such as the element's name, class, or XPath based on relative position or text. For example, use XPath like //input[contains(@name, 'customerName')] or identify by label text. In Blue Prism, use the Application Modeller to match on multiple attributes and enable 'wildcard' matching where appropriate. For the modal dialog, add a check at the start of each action to detect if the dialog is present (by spying on its unique title or text) and close it by clicking the 'No thanks' button. Implement this as a separate action 'DismissFeedbackDialog' and call it at the beginning of 'CreateCustomer' and other actions. Also, use Blue Prism's 'Wait for' stages with conditions to handle timing. This makes the object resilient to ID changes and modal interruptions.
2. What exception handling strategy would you implement within the object to ensure reusability and clear error reporting?
Read the worked answer
Within the object, implement a consistent exception handling pattern: each action should have a block that catches exceptions, logs detailed error information (including the action name, input parameters, and a screenshot if possible), and then rethrows a custom exception with a clear message. Use Blue Prism's 'Exception' stage to catch and handle. For recoverable errors (like modal dialog), handle internally and continue. For non-recoverable errors (like element not found after retries), throw a Business Exception with a specific code. This allows calling processes to decide whether to retry or mark as exception. Also, ensure that the object cleans up (e.g., closes dialogs) in the 'Clean Up' section. Document the exceptions in the object description. This promotes reusability and easier debugging.