Troubleshooting

Click the link to refer the below troubleshooting topics:

• Log File Location
• Enable Debug Level Logs
• Database Migration Troubleshoot
• TxnStore and Reporting Migration Troubleshoot 
• File Access Denied Error
• RobotFarm Migration Troubleshoot
• Dependent Process in Export and Import Migration

Log File Location

The log files get created at the below location.

• Migration Workbench Utility Logs: <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench\Logs\AssistEdge_MW.log
• Database Migration Logs: <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench\Logs\MW_DatabaseMigration.log
• Txnstore Migration Logs:
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench\Logs\MW_TxnStoreMigration.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\Command\ae.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\Command\txnstore.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\TxnStore\log\elasticsearch.log
• RobotFarm Migration Logs: <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench\Logs\AssistEdge_MW.log
• Reporting Migration Logs: 
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench\Logs\MW_Reportingmigration.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\Command\ae.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\Command\txnstore.log
  • <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\data\TxnStore\log\elasticsearch.log
• Updater logs: <<Robot Agent Machine Folder>>\Robot\RobotAgent\Logs\UpdaterLogs\AE_Updater.log

 

Enable Debug Level Logs

To enable debug level logs for migration workbench utility:

1. Open MigrationWorkbench.exe.config file available at <<AssistEdge Build Folder>>\AssistEdgeAutomation\migration\Workbench.
2. Search for keyword <categorySources>.
3. Replace the keyword Information with All.

    

   

Database Migration Troubleshoot

To troubleshoot Database migration, if:

1. Test Connection failed:
   1. Ensure that the database instance name and user credentials are correct. (For oracle database, verify port and service name).
   2. Database Server is accessible from machines on which migration utility is running.
2. Database list is not getting populated while migrating SQL database instance:
   1. Verify that the user has db_owner role for the database that is to be migrated.
   2. Ensure that database is mapped to the user.

 

NOTE:

To migrate the database again, you need to restore the 18.x database from the backup file and run the Migration Workbench again.For more information, see Database Migration.

 

3. Unable to Migrate Oracle Database using migration workbench:
   
   While migrating the Oracle database, the error message appears as Table or view doesn't exist.
   
   Ensure that the user has access to dba_triggers table of the Oracle database. The Oracle database migration is done once the full access is granted.
4. Database Connectivity Issues:
   
   In case of Oracle DB, check if the entries for config section handler oracle.manageddataaccess.client are already present in machine.config file on the web server. If the section exists in machine.config, check the Version attribute values. If the Version attribute values in machine.config and web.config of AssistEdge Workflow service do not match, an error message stating There is a duplicate oracle.manageddataaccess.client section defined may be observed at runtime.
   
   To resolve this error, follow the below steps:

• Update the config section handler entry for oracle.manageddataaccess.client in web.config of Workflow and Vanguard. Use the version mentioned in machine.config in both the web.config files and then restart the corresponding services. After performing this action, the workflow is up and running; however, if it fails to login to Admin Module, then reverse the action. Use the version mentioned in web.config file in machine.config and restart the corresponding services.
• In case the above solution does not work, remove the config section handler entry for oracle.manageddataaccess.client from the machine.config.
• However, note that there could be other applications (beyond AssistEdge) on the machine that are dependent on this entry in the server’s machine.config. In such cases, this config section handler entry needs to be added for all such application's .NET config file present on that server that depends on it.

Verify if the database services are running. If the issue persists, restart the database service and the database server.

 

TxnStore and Reporting Migration Troubleshoot

To troubleshoot the Txnstore and Reporting migration, if:

1. TxnStore validation failed:
   Ensure that TxnStore component is started.
2. TxnStore status is red:
   Restart TxnStore .

 

NOTE:

To migrate the TxnStore again, you need to delete the existing data folder present at  <<AssistEdge Build Folder>>\AssistEdgeAutomation\data\TxnStore and perform TxnStore migration again using Migration Workbench. For more information, see TxnStore Migration.

 

1. During TxnStore and reporting migration, if error appears <span id="lblErrMessage">The server encountered an error processing the request.<br /> See server logs for more details.</span>
   
   Solution:
   1. Stop all the running components from the server using ae stopall command. This command is executed from RPA scripts folder location.
   2. Start the required components and retry the failed migration.
       

File Access Denied Error

While migration if error appears, Access denied to the <logfilename.log>.
Solution:

1. Validate that the file ( for example, MW_reportingmigration.log) is not open anywhere. If yes, then close it.
2. Click home page and try reporting migration again.
3. If issue persists, restart the migration workbench.
    

RobotFarm Migration Troubleshoot

Follow the below steps if:

 

1. RobotAgents are not visible at the time of RobotFarm migration:
   If RobotAgents are not visible at the time of RobotFarm migration, ensure that TxnStore component is running and TxnStore migration with previous version data folder is successful.

2. Robot Migration fails due to access denied error:

1. Ensure that user has read and write access on RobotAgent folder of 18.x and 19.0 version.
2. If user is having read and write access and the error is encountered, you must run 19.0 RobotAgent.exe as Administrator.

3. The migration for RobotAgent is successful, but it fails to migrate some of the bots. 
   There is a possibility that the bots might have failed due to the memory shortage. In that case, check for the error in the updater logs of the failed 19.0 robot agent logs. Resolve the error and migrate the bots again by selecting the check box next to the bot name. Click Migrate.
   
   

 

4. Agents are not displayed on migration workbench for migration. Querying for agent result is unavailable. 
4. Check if:

• The Robot Agent is started.
• The Robot Agent is not already migrated.
• The old agent path is given in the config file of the new robot agent.
• The given old agent path is correct, and it exists.
  
  

 

5. If access is denied exception occurs at the time of migration, run the 19.0 RobotAgent.exe as administrator.
6. Before migrating RobotFarm again, you need to delete the rfdata.xml file present in the <<AssistEdge 20.0 Build Folder>>\AssistEdgeAutomation\migration\Workbench folder. This is applicable for scenario if successfully migrated robots need to be migrated again.

Dependent Process in Export and Import Migration

During the Migration process dependent processes are bundled with the parent process and are exported / imported automatically. To ensure that the exported / imported process feature work as expected for the dependent processes of the DW activity and the Trigger activity, users must edit, save, publish, and deploy the dependent process before the parent process.