Enhanced Error-Handling in powerGate

A reliable, immediate, and user-friendly error handling and messaging is business-critical when making ERP integrations to ensure process reliability and data quality.

Departments rely on the accuracy of information they receive from other units to keep processes running smoothly and maintain product quality. In this regard, we at coolOrange decided to upgrade the way errors are handled in powerGate to grant immediate and understandable error-handling reliably. Before exploring the new features, let us take a moment to examine how errors were handled previously, the difficulties that existed and the confusions it may have caused, so that you understand the importance of this upgrade.

Let us consider a simple process where powerGate attempts to create an item into the ERP system. For whatever reason, the ERP system refused to create the item (missing information, date mismatch, permissions, connection lost, server down, maintenance, etc,) Now, the powerGate cmdlet internally reports the problem and so far it was the responsibility of the script developer to intercept and act upon it by creating a pop-up message or retrying the process.

Depending on the given workflow, the error handling and error message may be different. For example, if powerJobs processes a job to create an item in the ERP system and an error occurs, displaying a popup dialog would not make sense because no one would notice since the job processor runs on a dedicated server machine. The job is hanging and waiting for somebody to come and notice what has happened and take action. All the while, the job processor is frozen eventually pausing all consequent jobs without anyway of notifying the user.

Another example is the creation of ERP items when a part or assembly is released in Vault. In this case, it is best to use the Vault restriction dialog, display a meaningful message there, and stop the release process. This way the user knows immediately what is going on and the release process is stopped to prevent data from being released that may not match the data in the ERP.

Another example is the ERP item creation during BOM transfer. In this case, the user works with the powerGate BOM transfer dialog and wants to create many ERP items at once. Displaying an additional error dialog would be possible here but displaying a dialog for each item would overwhelm the user. A better solution is to use the status icons integrated in the BOM dialog and display the errors for the respective item. In this way, the user immediately recognizes which items have problems without having to click through dozens of dialogs.

As you can see, different use-cases require different solutions.

Up until now, the responsibility of interpreting the errors and taking actions was on the shoulder of the script guy. He/she had to consider whether they are at the job processor or at the Vault Client or running the BOM dialog.

Thanks to the experience we have gained in over a hundred projects over the last years, we have identified the error situations that need to be handled and embedded them in the product. powerGate now knows when and how an error should be presented and in what way, so that the person responsible for the scripting can focus on implementing the customer's requirements without thinking about the worst-case scenario.

There are three types of problems:

1. Connection or communication problem, where the ERP cannot be reached, the user does not have permission, the data is locked by another user, and the like
2. Semantic or syntax problem, where mandatory values are missing, or the length does not match, or a text is sent where a number is expected, or …
3. Business logic, where the implemented logic encounters an unexpected error and is confronted with a situation that was not foreseen at the beginning (like with legacy data)

In all three cases, it is good to know where the problem occurred, either on the Vault client side, on the server, or in the ERP system. The new powerGate dialog makes this easily visible, reducing troubleshooting time.                                         

Depending on the given use case, powerGate brings the error message in the best available way, like as a restriction dialog during a life-cycle transition, as a job-error during job processing, as a status icon within the BOM transfer dialog, and as a dialog box where no other options is available.

This important improvement relieves the script guy of the burden of error handling and drastically reduces customization code, making it more readable, reliable and process safe.

While this feature will immediately improve new projects, as usual powerGate is cross-version compatible and this new version can also be implemented in existing projects. However, for existing projects, it is recommended to revise the customization and remove the custom error handling to prevent error messages from being displayed twice.

If you like to read more details about this enhancements, check out the change log.