When developing interfaces into most applications (Epicor ERP software included), one of the most important questions to ask is how you should go about implementing error handling.
To help you with that question, I have laid out my general advice on how you should best approach this in terms of interfacing to and from Epicor ERP 10 using Service Connect. You should be able to apply similar thinking when interfacing to and from other applications.
My usual solution for error handling is to break it down into three general approaches, and then determine which would fit best with the interface being developed (as well as considering which one the customer prefers).
NOTE: The information below assumes knowledge of Service Connect and Epicor ERP.
The simple approach
To implement a simple but effective approach to error handling, as a minimum, you will need to make someone aware that an error with an interface has occurred. This then gives someone the opportunity to take action and investigate the issue. One of the simplest ways to achieve this is to send an email to a specific mailbox when an error occurs.
To do this within a Service Connect Workflow you should carry out an error check using a ‘Choice’ element directly after every ‘.Net Reference’ element. If an error has occurred then stop processing and send an email to a specific email address using a ‘Poster’ element. Typically you would provide details of the error in the email body.
The intermediate approach
Again, you should carry out an error check using a ‘Choice’ element immediately after every Epicor ‘.Net Reference’ call. If an error occurs then you should write the details of the error to a UD table (using the ‘UpdateExt’ method for that particular UD table business object). A BAQ and dashboard could then be created within Epicor in order to display these records so that the user can view the errors that have occurred.
NOTE: Think carefully about how you structure the key fields and data that goes into the UD records as the user will most likely want to filter on this information. Also, I would recommend creating a small scheduled Service Connect workflow that picks up and deletes old records stored in the UD table (keep the last few weeks’ worth of data).
The advanced approach
Log all the details from the incoming data into UD records so that every field is stored. Once again you should carry out an error check using a ‘Choice’ element immediately after every Epicor ‘.Net Reference’ call. If an error is found then you should record the details of the error against the relevant record that you have already stored in the UD table and flag that particular UD record as being ‘in error’. If the incoming data is processed without error then a “Success” status could be recorded against the relevant record in the UD table.
A new BAQ and updateable dashboard would then be required so that the user can view the records that have been processed by the interface and filter their view (so for example they could just view the records that are in error).
The user would then have the option to adjust the data on the error records within the updateable dashboard. A checkbox on the dashboard could be made available in order to mark the UD record as ready for reprocessing. This checkbox would then trigger a BPM which would pass the data for that UD record to a Service Connect workflow. This Service Connect workflow would put the data from the UD record back into the original incoming format, and hand that data on to the original workflow for re-processing.
NOTE: Again I would recommend creating a small scheduled Service Connect workflow that picks up and deletes old records stored in the UD table (keep the last few weeks’ worth of data).
Error handling and interface
I’ve not gone into great detail on how you should build these suggestions for error handling into your Service Connect workflows. However, the general idea should help you to make the best choice for error handling, so that it is appropriate for the interface being developed and meets the needs of the customer.