General guidelines for the creation and deployment of custom code in the Hyland Cloud include:
- Existing functionality in the software, whether through the base product, additional modules, or licenses, should be used when available instead of custom code.
- A document describing the solution and installation guidelines must be provided in English. Submitting your documentation in any other language will delay the review of your code until translated documentation is provided.
- The full source code must be provided for the review. If you are using a tool like Microsoft Visual Studio, you will need to provide the complete contents of the solution and any solution/project dependencies. CPE will perform the necessary compilation of any files that will be deployed within the Hyland Cloud environment. No precompiled solutions from Hyland-authorized resellers or customers will be deployed under any circumstance.
- Submissions are to be fully tested, production-ready solutions. The Hyland Cloud is not a development test environment. If inadequately tested code is submitted, remedial revisions will not be expedited.
- The OnBase APIs need to be used whenever possible.
- All code should be .NET 4.8 or higher. A fair guideline for framework selection would be to code against the same .NET Framework version that is supported by your OnBase solution.
- The code should not perform any scan or discovery of the environment or the resources of the server hosting the software component.
- The database, Disk Groups, and Hyland Cloud Solution servers are inaccessible from the internet. This means that you will need to have a forwarding or pass-through proxy service for web solutions that are accessible from the internet. For example, an E-Form should call a web service hosted on a DMZ web server that will call back to a web service hosted on your OnBase application server within the Hyland Cloud private network to access the database.
- Solutions should not use generic user accounts to perform work in OnBase. An audit trail will not exist.
- Solutions should not be accessible without providing user credentials or other security measures.
- Credentials must not be hard-coded into the logic, and clear text passwords cannot be stored within application or web configuration files. A utility needs to be included for changing encrypted configuration values.
- The code must have a logging mechanism. This may be accomplished through a
custom event log, standard Windows event log, or log file.Note:
If a log file is used, the file’s location should be configurable and provide for managing the creation and size of the log files.
- If the code has been previously reviewed, the changelog of the code updates should be provided. However, the entire solution source code needs to be submitted, not just the changed portions.
- Solutions cannot run as the local administrator account or as a member of the local "Administrators" group on the hosting server. If privileges on a machine need to be elevated for the account that executes your code beyond what is provided by being a member of the "User" group, you must explain the specific permissions needed and why.
- Any third-party libraries that are used remain the responsibility of the custom code developer. All licensing information must be provided so that we can ensure our own compliance with the licensing terms of the product. Third-party libraries will be checked for known vulnerabilities. If any are found, upgrades will be required to revisions in which they are eliminated.
- Inclusion of general purpose open source packages is limited to those parts necessary to support the functionality being utilized. Developers are responsible for integrating the necessary components and omitting extraneous code.