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

Technical Account Manager

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

The Split Workbook activity splits the data of a sheet by the values in a given column and creates a separate workbook for each value. The DataTable returned can conveniently be used by the Queue All Workbooks activity to make a queue item for each workbook to be processed by a Processor. The Processor would consume the queued items which contain the path to the generated workbook files.

These activities allow the user to easily convert a process written to handle a sheet of data from a workbook to a Dispatcher-Processor model that can be run on many concurrent robots.

The Split Workbook activity splits the data of a sheet by the values in a given column and creates a separate workbook for each value. The DataTable returned can conveniently be used by the Queue All Workbooks activity to make a queue item for each workbook to be processed by a Performer. The Performer would consume the queued items which contain the path to the generated workbook files.

This process makes it simple to make queue items for subsets of data in an Excel sheet.

The Split Workbook activity splits the data of an Excel sheet by the values in a given column and creates a separate workbook for each value. The DataTable returned can conveniently be used by the Queue All Workbooks activity to make a queue item for each workbook to be processed by a Performer. The Performer would consume the queued items which contain the path to the generated workbook files.

The config file allows you to specify a full path to a folder or a "Special Folder" using the .net Environment.SpecialFolder Enum like "UserProfile".  You can also specify a subfolder to be added to the derived special folder.  This enables you to act on folders like C:\\Users\\richard.king\\AppData\\Local\\CrashDumps\\. 

You can specify the number of days old a file must be in order to be archived.  You can specify the number of days old the archive folder must be in order to be deleted.  You can specify that only archive folders are deleted or you can have it delete any subfolders that are old enough to be deleted.

Please go through the user guide attached in the Documentation section to help you properly run this automation.

This solution is used to archive and delete files in multiple folders based on age. A list of folders is provided in the config file.

One of our recommended best practices is to start each automation using a template.  In essence, it doesn't make sense to start with a blank project in most cases.  Using a template creates reuse and adds functionality to your automation with minimal effort.  

  

There are different profiles for automations that determine what template is best to start with.  For instance, if you are processing many transactions or you want to split the work across many robots you would use RE Framework as the template.  Many customers customize the RE Framework and make their own versions as well.  

  

Many customers create automations that don't have transactions.  Maybe they run a couple of reports in the ERP and combine them in Excel.  Maybe it's a single transaction per day.  Particularly when the COE program is just getting started, the big templates can be intimidating and quite unnecessary for that automation described above.  At the same time there are basic functionalities that are also best practices that you don't have to recreate in every new automation.

  

This template can be used when there is only one transaction and a queue is not required.  It provides best practice features:  

1\. storing values and asset names in a config file  - loading them into the config dictionary.

2\. configurable retry. 

3\. basic exception handling.

4\. exception screenshot.

This template can be used when there is only one transaction and a queue is not required. It provides: config file, retry, exception handling, and exception screenshots.

One of our recommended best practices is to start each automation using a template.  In essence, it doesn't make sense to start with a blank project in most cases.  Using a template creates reuse and adds functionality to your automation with minimal effort.  

  

There are different profiles for automations that determine what template is best to start with.  For instance, if you are processing many transactions or you want to split the work across many robots you would use RE Framework as the template.  Many customers customize the RE Framework and make their own versions as well.  

  

Many customers create automations that don't have transactions.  Maybe they run a couple of reports in the ERP and combine them in Excel.  Maybe it's a single transaction per day.  Particularly when the COE program is just getting started, the big templates can be intimidating and quite unnecessary for that automation described above.  At the same time there are basic functionalities that are also best practices that you don't have to recreate in every new automation.

This activity uses the process's current Orchestrator connection to download logs to a DataTable using Orchestrator APIs. It provides filters that can be applied to the API. The developer can use this activity to fit many use cases. In the benefits section there are listed a few use cases known at this time.

This activity uses the process's current Orchestrator connection to download logs to a DataTable.

This activity uses the process's current Orchestrator connection to download logs to a DataTable using Orchestrator APIs. It provides filters that can be applied to the API. The developer can use this activity to fit many use cases.

**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.

**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.

**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.

**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.

**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.

The goal is to provide unattended automation that allows the customer to verify that the robot VMs are properly configured, have the right software installed, etc. 

  

COE teams can schedule this to run early in the morning and get a report emailed to them from each tenant. First thing every morning they know the robots are ready for the day. The automation has special logic that allows a list of tests to be run on each available robot VM and reported out so that corrective action can be taken.

  

Additional benefits:

· Validate a new system installation or system upgrade by performing some basic actions on every robot.

· Troubleshoot issues that are random, recurring or only happen on some bots. The automation can collect screenshots and recordings of the failed tests.

· Collect information that is useful for administration purposes (Windows version, Chrome version, results of any command of PS script).

· Easily make a change on every robot - create a directory, install an app, etc.

The goal is to provide unattended automation that allows the customer to verify that the robot VMs are properly configured.

Get Queue Items Export
======================

Get Queue Items Export Activity
-------------------------------

This activity 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 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 Data values into separate DataTable columns for ease of use.

This activity is a replacement for the UiPath Get Queue Items activity. It uses the recommended Export APIs to get the data.

Get Queue Items Export
======================

**Get Queue Items Export Activity**

This activity 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 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 Data values into separate DataTable columns for ease of use.

**Get Queue Items Export Activity**

This activity 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 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 Data values into separate DataTable columns for ease of use.

This activity is a replacement for the UiPath Get Queue Items activity. It uses the recommended Export APIs to get the data and returns a datatable.

About me