a6e5b969-be6e-4756-ae53-47d3cb899ca4.png

360e968e-8a87-4b54-9882-cab6be089b4f.jpg

Technical Account Manager

37ebd7e3-c300-4427-8100-344d8c14008e.nupkg

**Introduction**

  

Summary reporting for multiple performers is a challenge that has been addressed in multiple ways. This documentation and custom activity present a methodology for doing reporting that is less apparent to most solution architects. It is simple and reliable. It eliminates many of the pitfalls of other methods like file contention on Excel files and race conditions between performers.

  

**Overview**

  

At a high level, this methodology uses a single “Reporting” transaction that is added to the queue by the dispatcher. This ensures that only 1 performer will attempt to do the reporting. The transaction is set to “Low” priority so that it is always the last transaction pulled from the queue. The custom activity is then invoked to extract the transactions from the queue. It will extract exception information for failed transactions as well as 'Output Data' for successful ones.

  

**Coding**

  

The coding is simple, and I have provided screenshots below.

  

**Dispatcher**

  

After the normal transactions are added, use a separate Add Queue Item with the properties set as shown in the image below.

  

**Performer**

  

The IF activity shown below will direct normal transactions to the Process.xaml and the Reporting transaction to a Reporting workflow.

  

**Summary Reporting**

  

For creating a summary transaction report, a great source of information is the queue transactions themselves. They have the business data used for the transaction as well as the status of each transaction, exception information, etc.

  

The Transaction Summary Report library handles all of these requirements.

· Waits for given other performer jobs to end

· Extracts all transactions from a queue since the given start date.

· Extracts exception details for failed transactions – Exception Type and Exception Reason

· Extracts the given columns of Specific Content data

· Extracts the given columns of Output Data

  

I have tested it in a test queue, and you can see the sample results below. I manually did a little formatting. You can also use the datatable output property to customize the report however you wish.

  

**Capturing Output Data**

  

Transactions have the ability to take additional data that may be relevant for analysis or reporting. This is accomplished by using the Set Transaction Status activity. As shown below in the RE Framework a collection of value pairs can be assigned to the “Output” property.

  

Warning: The Output collection can only be used for Successful transactions. For Exception transactions, the exception reporting information is already in place. If your code uses a Throw, include any needed reporting text there in the message.

  

The Output values are shown in the “Output Data” part of the transaction page in Orchestrator. See attached screenshots.

In the example below the column name is “TransactionOutput”. This is the string you’ll use in the string array argument called “OutputDataHeaders”. See the example below.

This activity is used for creating a transaction report for transactions in a queue. It is especially needed when there are multiple performers on the queue.

7061f71d-40c0-4ca0-9c9a-7dd4a1908de4.png

01a3583b-d8f2-411e-a6bc-6a8977dbb1cc.png

c158d94e-3787-44c8-b7c9-b48aa9dfd6bd.png

5d5c09cc-f90f-4de0-8d05-8d617c7b658b.png

Visual Basic

98c8b6b5-7dbe-4fa7-821d-bbb212380a5a.docx

7dfed461-c975-4af5-9ac3-4bb30c08353e.zip

8597d300-6c95-47ae-903a-6652ce4837f2.nupkg

ac5946f6-0010-41fa-a9d4-a11ec6651cbd.docx

719d1fde-6795-468c-9cd8-164896cc3406.nupkg

**Introduction**

  

Summary reporting for multiple performers is a challenge that has been addressed in multiple ways. This documentation and custom activity present a methodology for doing reporting that is less apparent to most solution architects. It is simple and reliable. It eliminates many of the pitfalls of other methods like file contention on Excel files and race conditions between performers.

  

**Overview**

  

At a high level, this methodology uses a single “Reporting” transaction that is added to the queue by the dispatcher. This ensures that only 1 performer will attempt to do the reporting. The transaction is set to “Low” priority so that it is always the last transaction pulled from the queue. The custom activity is then invoked to extract the transactions from the queue. It will extract exception information for failed transactions as well as 'Output Data' for successful ones.

  

**Coding**

  

The coding is simple, and I have provided screenshots below.

  

**Dispatcher**

  

After the normal transactions are added, use a separate Add Queue Item with the properties set as shown in the image below.  Optionally include a date time in this Reporting Transaction that will serve as the filter for the transactions pulled from the queue.

  

**Performer**

  

The IF shown below will direct normal transactions to the Process.xaml and the Reporting transaction to a Reporting workflow.

  

If you are using a unique Reference queue, you will want to add a date or DateTime to the Reference of your reporting Transaction. In that can you would use a .contains(“Reporting”) in the IF below instead.

  

The activity excludes all transactions from the report results that have “Reporting” in the Reference field.

  

**Summary Reporting**

  

For creating a summary transaction report, a great source of information is the queue transactions themselves. They have the business data used for the transaction as well as the status of each transaction, exception information, etc.

  

The Transaction Summary Report library handles all of these requirements.

· Waits for given other performer jobs to end

· Extracts all transactions from a queue since the given start date.

· Extracts exception details for failed transactions – Exception Type and Exception Reason

· Extracts the given columns of Specific Content data

· Extracts the given columns of Output Data

  

  

  

**Capturing Output Data**

  

Transactions have the ability to take additional data that may be relevant for analysis or reporting. This is accomplished by using the Set Transaction Status activity. As shown below in the RE Framework a collection of value pairs can be assigned to the “Output” property.

  

Warning: The Output collection can only be used for Successful transactions. For Exception transactions, the exception reporting information is already in place. If your code uses a Throw, include any needed reporting text there in the message.

  

The Output values are shown in the “Output Data” part of the transaction page in Orchestrator. See attached screenshots.

In the example below the column name is “TransactionOutput”. This is the string you’ll use in the string array argument called “OutputDataHeaders”. See the example below.

7803ed28-7fad-4e5c-ae10-d485780161e3.docx

eef2ca02-7cea-42aa-b2a8-30d9c16d81b9.zip

b26d9415-8f29-4b36-a9cc-c7ce8a34ffdb.nupkg

da2dc047-69d6-4f26-ae1e-094a52d653ec.zip

0d4937c5-798d-4bad-8539-c0c20345ad45.nupkg

1ac2e84a-b4b4-478e-b712-546523d96565.docx

f1f6e738-6a85-488a-90e1-1e05d8c8f1ce.zip

ba04037c-7fa8-4f82-8c17-a37a99975e86.nupkg

**Introduction**

  

Summary reporting for multiple performers is a challenge that has been addressed in multiple ways. This documentation and custom activity present a methodology for doing reporting that is less apparent to most solution architects. It is simple and reliable. It eliminates many of the pitfalls of other methods like file contention on Excel files and race conditions between performers.

  

**Overview**

  

At a high level, this methodology uses a single “Reporting” transaction that is added to the queue by the dispatcher. This ensures that only 1 performer will attempt to do the reporting. The transaction is set to “Low” priority so that it is always the last transaction pulled from the queue. The custom activity is then invoked to extract the transactions from the queue. It will extract exception information for failed transactions as well as 'Output Data' for successful ones.

  

**Coding**

  

The coding is simple, and I have provided screenshots below.

  

**Dispatcher**

  

After the normal transactions are added, use a separate Add Queue Item with the properties set as shown in the image below.  Optionally include a date time in this Reporting Transaction that will serve as the filter for the transactions pulled from the queue.

  

**Performer**

  

The IF shown below will direct normal transactions to the Process.xaml and the Reporting transaction to a Reporting workflow.

  

If you are using a unique Reference queue, you will want to add a date or DateTime to the Reference of your reporting Transaction. In that can you would use a .contains(“Reporting”) in the IF below instead.

  

The activity excludes all transactions from the report results that have “Reporting” in the Reference field.

  

**Summary Reporting**

  

For creating a summary transaction report, a great source of information is the queue transactions themselves. They have the business data used for the transaction as well as the status of each transaction, exception information, etc.

  

The Transaction Summary Report library handles all of these requirements.

· Waits for given other performer jobs to end

· Extracts all transactions from a queue since the given start date.

· Extracts exception details for failed transactions – Exception Type and Exception Reason

· Extracts the given columns of Specific Content data

· Extracts the given columns of Output Data

\* See attached Word document for full features list and details.

\*\* If you need a Windows Legacy version please submit a question to this listing or contact me directly.

  

  

  

**Capturing Output Data**

  

Transactions have the ability to take additional data that may be relevant for analysis or reporting. This is accomplished by using the Set Transaction Status activity. As shown below in the RE Framework a collection of value pairs can be assigned to the “Output” property.

  

Warning: The Output collection can only be used for Successful transactions. For Exception transactions, the exception reporting information is already in place. If your code uses a Throw, include any needed reporting text there in the message.

  

The Output values are shown in the “Output Data” part of the transaction page in Orchestrator. See attached screenshots.

In the example below the column name is “TransactionOutput”. This is the string you’ll use in the string array argument called “OutputDataHeaders”. See the example below.

e092b456-52f5-4e3a-972c-7680ca8f6df5.docx

c9afe8d6-527f-4156-a540-d4144ceb5f6b.zip

34914768-943d-4ee5-8672-ac249ae7485b.nupkg

**Introduction**

Summary reporting for multiple performers is a challenge that has been addressed in multiple ways. This documentation and custom activities present a methodology for doing reporting that is less apparent to most solution architects. It is simple and reliable. It eliminates many of the pitfalls of other methods like file contention on Excel files and race conditions between multiple performers.

  

**Overview**

At a high level, this methodology uses a single “Reporting” transaction that is added to the queue by the dispatcher. This ensures that only 1 performer will attempt to do the reporting. The transaction is set to “Low” priority so that it is always the last transaction pulled from the queue. The custom activity is then invoked from the Process Transaction state to extract the transactions from the queue. It will extract Exception information for failed transactions as well as 'Output Data' for successful ones. 

  

This activity optionally waits for the number of running processes with a given name to be one. This gives other performers time to complete the last few transactions before the reporting begins. Please see additional details below for the full list of features. Demo projects have also been provided.

  

**Coding The Dispatcher**

  

**Transactions Remaining Activity**

There are scenarios where the dispatcher is scheduled to run frequently. If you want to report on each batch of transactions separately you may want to make sure that the reporting transaction is processed before the next batch of transactions is added to the queue.

  

An activity called Transactions Remaining is provided to be used in scenarios where a dispatcher may be scheduled so that it could add a second batch of transactions into the queue before the previous batch is complete. Using the activity below, your Dispatcher can easily determine if there are still New or In Progress transactions still in the Queue and skip creating more transactions if needed.

  

Please note the “Ignore In Progress Transactions Older Than Minutes” property. If a performer faults it is possible to leave the transaction with the state, “In Progress” even though it is really abandoned. For this reason, you are able to ignore any transactions that started more than X minutes ago.

  

**Create Reporting Transaction Activity**

After the normal transactions are added, use this activity to easily add a Low priority Reporting Transaction to your queue. The Reference property must contain the word “Reporting”, but it can also have other text as needed. The BatchStartDateTime property will be used by the Performer to filter the transactions. So the time needs to be before the Create time of the transactions added to the queue.

  

**Coding the Performer**

  

**CreateSummaryReport activity**

This activity is used to extract the data from the queue and has many options. It is best to implement this activity in the Process Transaction state of your Performer process. The IF shown below will direct normal transactions to the normal transaction logic and the Reporting transaction to a Reporting workflow.

  

If you are using a unique Reference queue, you will want to add a date or datetime to the Reference of your reporting Transaction. This is the reason for using .contains(“Reporting”) in the IF below.

  

The activity excludes all transactions from the report results that contain “Reporting” in the Reference value.

This activity is used for creating a transaction report for transactions in a queue. It is very useful when using multiple performers.

79b1f772-7ca9-4114-8723-a4e0e81bc6e2.png

fdb99abc-bbec-4b67-a7f8-acdd43770033.png

71df3cab-6741-4cd3-8b8e-e29aaccce445.png

e3c9c8af-b5b9-47de-8b2f-9353f7c0499a.docx

5a3a1f72-10d8-4b46-9a49-0aa8d821db85.zip

9e04bad0-4c02-48a6-a6a3-4fe892561e65.nupkg

c832102f-0895-4dfd-bce6-60fbab6cc76d.nupkg

5e162144-6963-49ef-b576-f4f77ee0926c.nupkg

932814da-a7e2-44d1-bcaf-14d5d0e942af.nupkg

2e278a4a-5ed7-45f5-af81-4ae3c947e7aa.zip

14a9c0e1-df7c-483c-b006-98fe5262b0a3.nupkg

**Introduction**

Summary reporting for multiple performers is a challenge that has been addressed in multiple ways. This documentation and custom activities present a methodology for doing reporting that is less apparent to most solution architects. It is simple and reliable. It eliminates many of the pitfalls of other methods like file contention on Excel files and race conditions between multiple performers.

  

**Overview**

At a high level, this methodology uses a single “Reporting” transaction that is added to the queue by the dispatcher. This ensures that only 1 performer will attempt to do the reporting. The transaction is set to “Low” priority so that it is always the last transaction pulled from the queue. The custom activity is then invoked from the Process Transaction state to extract the transactions from the queue. It will extract Exception information for failed transactions as well as 'Output Data' for successful ones. 

  

This activity optionally waits for the number of running processes with a given name to be one. This gives other performers time to complete the last few transactions before the reporting begins. Please see additional details below for the full list of features. Demo projects have also been provided.

  

**Get Queue Items**

  

**Get Queue Items Export Activity**

This activity can be used independently of the Reporting activities.  It is generally a replacement for the UiPath Get Queue Items activity.  It uses the recommended Export APIs to get the data.  This method is not affected by the new API limits or the removal of the Specific Content and Output Data from other APIs.

  

**Get Queue Items Export And Parse Activity**

This activity can be used independently of the Reporting activities.  It is a more advanced replacement for the UiPath Get Queue Items activity.  It uses the recommended Export APIs to get the data.  Compared to the activity above, this one will parse the Specific Content and Output Date values into separate datatable columns for ease of use.

  

**Coding The Dispatcher**

  

**Transactions Remaining Activity**

There are scenarios where the dispatcher is scheduled to run frequently. If you want to report on each batch of transactions separately you may want to make sure that the reporting transaction is processed before the next batch of transactions is added to the queue.

  

An activity called Transactions Remaining is provided to be used in scenarios where a dispatcher may be scheduled so that it could add a second batch of transactions into the queue before the previous batch is complete. Using the activity below, your Dispatcher can easily determine if there are still New or In Progress transactions still in the Queue and skip creating more transactions if needed.

  

Please note the “Ignore In Progress Transactions Older Than Minutes” property. If a performer faults it is possible to leave the transaction with the state, “In Progress” even though it is really abandoned. For this reason, you are able to ignore any transactions that started more than X minutes ago.

  

**Create Reporting Transaction Activity**

After the normal transactions are added, use this activity to easily add a Low priority Reporting Transaction to your queue. The Reference property must contain the word “Reporting”, but it can also have other text as needed. The BatchStartDateTime property will be used by the Performer to filter the transactions. So the time needs to be before the Create time of the transactions added to the queue.

  

**Coding the Performer**

  

**CreateSummaryReport activity**

This activity is used to extract the data from the queue and has many options. It is best to implement this activity in the Process Transaction state of your Performer process. The IF shown below will direct normal transactions to the normal transaction logic and the Reporting transaction to a Reporting workflow.

  

If you are using a unique Reference queue, you will want to add a date or datetime to the Reference of your reporting Transaction. This is the reason for using .contains(“Reporting”) in the IF below.

  

The activity excludes all transactions from the report results that contain “Reporting” in the Reference value.

39b25b33-ca1a-4118-b5f4-de77f832485b.docx

56ce19e1-a733-41c7-ab08-65221d0cd228.nupkg

8cfa2b25-b512-4deb-ac32-031dc7ef4abe.zip

809be614-947e-4d99-a0ff-7f5ea08fd10b.nupkg

f7a03d0f-6122-4c57-9515-59f3823ed8e6.docx

46dc4a65-7528-4a5d-9c80-4f1a6b32fc95.zip

c69cb720-5459-4d0f-adc1-6cab636d8796.nupkg

4dca663c-ee1b-4902-95af-d11ae11babb8.zip

c93669ac-c534-44b7-af3b-95ab651d5897.nupkg

ecf2fcc2-4f0a-4079-899b-cb8635a9d201.zip

Transaction Summary Report Activity