BTech
	BTech Alerts & Notifications - Check this page for the latest information on emergencies and system outages. All times are Pacific.
	Category: Integrations Category: Integrations - Non BTech Product Managers Integrations Overview, 1000060230.
Integration Information

Error Handling and Reporting

Error handling needs to be applied for:

• All connector calls for when the connection failed due to authentication issue, bad request, internal server error, or network issue.
• Or when the connector call response is returning error that is captured by the application behind the connector.
• Business Rules or decision steps if the rejected documents need to be logged/alerted.
• Data quality issues that cause data mapping, business rules, connector calls to fail.

A common error handling process needs to be built to do the following:

• Log the errors with relevant details including but not limited to:
  1. Process Name, Atom Name, Execution ID, Source and Target system, data object
  2. Record tracking number
  3. Error message, error code, error type
  4. System to which the errors should be logged to
  5. People/teams who should be alerted for specific type of errors:
     • Technical errors should go to technical support team.
     • Functional errors, such as data quality issue caused errors, should be sent to business and functional users to review and address.

Operational Maintenance

• When process fails, often there is need to rerun the process to catch any data that would have been missed due to the failure.
• Is there lastSuccessfulRun timestamp to be reset?
• Is there any extended process property that would allow certain record to be included in next process run?
• Is there any flags, time stamp, to reset in source or target applications to allow for certain records to be reprocessed?
• Who should be notified to review and identify the root cause of the failure, to address any data issue,  process issue, or integration design issues?
• In this solution, error handling is performed using Swinerton’s standard error handling framework.
• For both system errors and data errors, notification email alerts can be sent, the errors are logged in audit database and can be viewed on a Boomi flow exception dashboard.
• The following screenshot shows all the potential errors that can be captured and logged:
  

  
  

  

Rerun

• This process can be rerun in case any of the errors caused the files not retrieved or sent to Azure blob container after the regular daily execution.
  
  
• After rerun, the ProcessDataConnectorAutodeskReqABCS process is executed again, as can be verified and evidenced from the process reporting screen:
  
  
• In the case of refresh token error, a new refresh token needs to be generated.
  • Contact Gobinath for the new token, and set in the Dynamic process property “DPP_RefreshToken_AutoDeskDataConnect” on the process property screen for the deployed process of ProcessDataConnectorAutoDeskReqABCS
    

Error Message:

• Error Code=AutoDesk Job Not Complete, ErrorMsg=AutoDesk Automated Job has not completed successfully at 100% today.

• When this failure occurs, it tends to persist throughout that day.
• The recommended solution for resolving this issue is to re-run the execution.
• If the re-run proves ineffective, an alternate measure involves manually transferring the file from Autodesk to the Azure blob container.
• To take this action, follow these steps:

1. Create a ticket with Autodesk (Katy / Ben Sohn), Autodesk must be down that time.
   • Swinerton Autodesk team should work with vendor to resolve this issue.
2. As a workaround for that specific day:
   • Access the system using the forge/integration account and manually initiate the data transfer(New Load).
   • If the manual transfer proves successful, you can then proceed to re-run the previously failed execution.
3. Avoid attempting a re-run if the same error persists.
   • The process will automatically resume the following day.