Queue Report VBO - Adding Tags field to queue report

[NehaOza]

I would like to add tags ( tags separated by some separator) column in queue report generated by Queue Report VBO. Currently, Queue Report VBO does not have Tags column in standard template. 
Queue Report VBO fetches data from database, and Tags are in separate table. 

how can I achieve? where do I

------------------------------
NEHA OZA
------------------------------

[PabloSarabia]

Hi @NehaOza

If you have access directly to the database, here you have a query to extract all the tags per item in only one line.

SELECT ITEMS.ident
, (SELECT STUFF((
SELECT ',' + tag
FROM BPAWorkQueueItemTag ITEMSTAGS
INNER JOIN BPATag TAGS ON ITEMSTAGS.tagid = TAGS.id
WHERE ITEMSTAGS.queueitemident = ITEMS.ident
FOR XML PATH ('')
),1,1, '') )
FROM BPVWorkQueueItem ITEMS

​I use the function "FOR XML PATH" to concatenate all in the same line.


Hope this helps you! 😄

See you in the community, bye 🙂

------------------------------
Pablo Sarabia
Architect
Altamira Assets Management
Madrid
------------------------------

[Devendra_KumarP]

Hi Neha, 

Queue report will give you tag details for queue reporting. First use "Get Report Data" action which will give you all Item ids. Loop thru Item ids and use action "Get Item Data". 
Get Item Data will give you Tags along with Key, Priority, Status, Worktime etc.

------------------------------
Devendra Kumar Prajapati
Tech Lead
Infosys
Europe/London
------------------------------

[John__Carter]

Hi Neha - the idea with the queue report is that you (manually) prepare the template file so that it contains column headers for the fields and tags you are interested in. Eg:

Customer_ID   First_Name   Last_Name   Tag_C   Tab_A   Tag_F   Tag_K

The VBO will then use the template headers to decide which values and tags to include in the report.  For tags, the VBO will use the values Yes or No to indicate whether an item has the tag or not. Eg:

Customer_ID   First_Name   Last_Name   Tag_C   Tab_A   Tag_F   Tag_K
123456        Neha         Oza         Yes     No      No      Yes

There is a guide to explain this

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------

[NehaOza]

thank you Devendra Kumar, I am using Queue Report VBO provided by Blue Prism, where its is only allowed few fixed columns, in that list Tags , Priority and Worktime fields not present and also fixed fields data is being fetched from database directly. And Tags there is separate table where each tag will be in separate row for one item ID.

I will check, if I can add additional column fetching from Get Item Data.

------------------------------
NEHA OZA
------------------------------

[NehaOza]

thanks Pablo Sarabia, i will try thanks for query.

------------------------------
NEHA OZA
------------------------------

[NehaOza]

Hi John Carter, thank you for your reply.  I agree, Queue report VBO documentation says, it only add fields from listed in documentation where Tags are not listed. And also, it is getting data directly from database where Tags are in separate table, hence i was checking is three any way to add column in query so i can add in template to match with database

Also, we use tags to store other information as well, hence I would like Tags as separate column just like we see in queue report, which is not possible with BP queue report VBO. 

Hence I am trying to modify query within VBO and will modify template as well to incorporate Tags field in final output. 

------------------------------
NEHA OZA
------------------------------

[NehaOza]

Hi John Carter,

What is benefit of fetching data directly from database rather than fetching using Work Queue BP VBO

if you aware and throw some light, would help in deciding whether I should spend time in adding Tag and Worktime columns to Queue Report Template and Existing VBO or just directly fetch from Work Queue VBO.

Thanks,
Neha

------------------------------
NEHA OZA
------------------------------

[John__Carter]

Hi Neha

Ideally the database should be not be directly accessible to anyone but the App Server and the system admin. Digital workers (Runtime Resources/Resource PCS/Robots) should have no direct access and get all their data via the app server. This is for security reasons but also for performance - there is a risk of over-burdening the database with MI queries, to the detriment of the digital workers.

This being said, if access security is controlled and the risk/potential for a performance hit is understood, accepted and mitigated for, then extracting data can be done safely. Coordinating the access with a time when the DWs are not running (eg in the night) is one possible mitigation, or another is to query a backup/mirror database so as not to affect the production database.

The fundamental point is the BP database is primarily an operational database. It does contain data that can be used for MI, but the database should not be treated as an MI repository that can be queried at will - it has to be treated with thought and care.

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------