Integrity provides a wealth of configuration options. However, due to the complexity of the development ecosystem and demands from the user base, there will inevitably be a desire for extending the core functionality with custom code. There can be a number of reasons for extending Integrity including, but not limited to:
- Integration to other Applications
- Custom business logic
- Automation
- Improved Interface Efficiency, e.g., role or solution specific Interfaces
Due to the ratio of end users to administrators, a large amount of administrative development time should often be exchanged for a relatively modest saving in time for end users. In other words, an investment many hours of administrative time to save a few minutes of end user time is often still a viable exchange. This is because there will be many more end users performing the operation more frequently, so 500 end users each saving a few minutes a day may quickly add up to exceed the amount of time spent by the administrator in developing the time saving functionality. However, you should also consider the amount of time to maintain and upgrade any custom code, as well as any performance impacts it may have on the Integrity server or other users.
This guide is meant to provide tips and best practices for the various coding interfaces provided by Integrity. It cannot cover each topic exhaustively, so references to other guides are noted as applicable. It will also focus specifically on Integrity functionality and will not repeat commonly understood best practices for the programming language you intend to use; you should familiarize yourself with those best practices and standards beforehand and consider this guide to be supplementary material. The functional areas discussed in this guide include:
- Trigger Scripts
- Custom Action Buttons
- Application Programming Interface (API)
- Automated Test Execution Framework (ATEF)
- Web Services
- Report Recipes
- Command Line Interface (CLI)
