Change the Exception Type field within an exception stage to be configurable only within System

[Asilarow]

Currently, the Exception Types are created by users manually typing into the combo box within the Exception Stage's properties.

This often leads to multiplication of the same exception type due to typos, misunderstandings, etc.

Example below:

This in turn becomes a nightmare when it comes to reporting, as often a hard set rule cannot be followed for extrapolating these from the overall pot.

I suggest removing the ability to add new exception types by typing into the combo box, and instead make it a privileged action within the System settings.

For example within the already existing Exception Type screen:

This could be done by implementing an "Add new exception type" action on the side panel, below the already existing "Scan processes"

[diane.sanzone]

Would new exception types automatically add if used in any code that is part of a release, or would they need to also be selected (similar to environment variables and work queues?) 

Also, what about including a "find references" option for the ones that exist in the list, similar to how environment variables work? This would allow you to easily identify the usage of these items and easily correct any issues. It would also allow you to convert to a new exception type if internal standards or verbiage change.

[Asilarow]

In terms of adding a release, that's what they do now indeed, Diane.

The biggest issue is controlling the exception types, when the development environment itself allows the users to add a new type without even realising it sometimes.

As for finding references, that can be easily done by using the already existing filters in advanced search.

Not sure what you are asking about there?

[diane.sanzone]

If adding new types is restricted to system admins, then it would seem that release managers might not be able to automatically import the new exception types due to security constraints.  In my environment they are two different groups and my admins shouldn't be anywhere near importing releases.  I also wouldn't want them as a required resource for new installs.

As for the find references, I haven't found a way to identify all instances of a given exception type.  If there is I'd love to see it so I can clean up the garbage in my system.  My thought here is like a find and find/replace function, similar to excel. Look at the list of exception types in the system tab. Right click the one with a typo, find/replace and update with the correct variable.  This would eliminate the security conflict I describe above and also allow you to easily correct any mistakes system-wide.

[Asilarow]

When a release is imported with exception types that aren't there yet, they are automatically created.

This is standard behaviour at present, and shouldn't change.

The change should be around how the exception types are created, so that only people with the relevant privileges can create them.

I do not encourage anyone to limit this just to system admins... as that would be a massive bottleneck for the release management process.

I do however, strongly recommend taking away the ability to do so from all users, and only allowing a select group to do that.

Which group it would be will be down to each organisation's individual setup.

This is what my suggested improvement idea would achieve. 

[Asilarow]

FYI - to find all instances of a given exception type in a process or object follow the below steps:

1. Copy the exact name of the Exception Type you wish to find
2. Open the relevant Object/Process
3. Press Ctrl+Shift+F or click the "Advanced Find" option within the "Edit" menu
4. Paste the exception type into the "Find What" edit box
5. Press "Find next"
6. The list will be populated with all stages that use or refer to the given exception type

[diane.sanzone]

Thanks, Andrezej, but your step #2 is my exact point.  You state to open the relevant code.  What if I don't know which piece of code has the offending exception type?  When you have a team of 7 developers plus contractors working on multiple initiatives, it's impossible to know who fat-fingered "exceptoin".  I was hoping for a "find references" similar to with environment variables where all code items are searched concurrently.  I do, however, appreciate you attempting to answer my question. Thanks. 

My comments regarding the permissions were only that sometimes making one change (restricting a particular thing to a select group) can inadvertently have other impacts (removing the ability for the release manager to create new types via the import process).  I agree that shouldn't change, but think it should be pointed out to make sure that it doesn't.

[Asilarow]

Unfortunately there is no easy way of doing so without coding.

If you have access to your Blue Prism database, you could use the below SQL to identify the exceptions:

-- Define a CTE to perform the CAST operation

WITH ProcessXML_CTE AS (

    SELECT

        ProcessID,

        CAST(ProcessXML AS XML) AS ProcessXML_Cast

    FROM BPAProcess

)

-- Use the CTE to apply the .nodes() method

SELECT

    P.ProcessID,

    P.ProcessXML_Cast.value('(/process/@name)[1]', 'NVARCHAR(MAX)') AS ProcessName,

    Stage.value('@stageid', 'NVARCHAR(255)') AS StageID,

    Stage.value('@name', 'NVARCHAR(255)') AS StageName,

    Stage.value('(exception/@detail)[1]', 'NVARCHAR(MAX)') AS ExceptionDetail

FROM

    ProcessXML_CTE AS P

CROSS APPLY

    P.ProcessXML_Cast.nodes('/process/stage[@type="Exception"]') AS T(Stage)