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.
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.
The coding is simple, and I have provided screenshots below.
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.
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.
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
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.