Recommended Deployment Architecture
The aPriori Installation Guide provides an example of a very basic recommended deployment, with separate environments for production and testing.
Production Environment– The environment where users’ day-to-day work is completed and saved.
Test Environment – The environment where VPEs, UDAs, etc. are edited and tested. The recommended workflow is to export VPEs from the Production Deployment, import into the Test Deployment, edit and test in the Test Deployment and then Import into Production Deployment.
This chapter provides discussion and examples of more complex deployments. For example, the following deployment shows how to segregate data between different divisions of the same company:
There are several use cases for an architecture such as this:
• A company that has several competitive divisions, or areas of business that must be separate for adherence to regulation, can configure a production deployment with multiple component databases. In this type of deployment, users are granted permission to a specific component database. If you have super users or managers who should be able to access all component databases, you can assign permission to access multiple component databases.
• A company that has geographically remote users may find that some users cannot achieve appropriate network performance when connecting to a single server. In this case, the company can use deployments to distribute VPE and component schemas to servers that are closer to those end users. This could be used in conjunction with aPriori's separately-licensed Scenario Synchronization module for keeping component schemas synchronized if that is a requirement.
• A company that develops VPEs internally should develop their VPEs in a separate “development” deployment. Once these have been verified, the VPEs can be published to their end-user deployment. This can be linked the same license file as the end-user production deployment.
If this “development” deployment is linked to the same license file as the end-user production deployment, then it should not be used to make changes to Access Control Objects, UDAs, etc. These objects are shared across all deployments which share a license schema, and changes could disrupt a deployment being used for costing in production. These objects should only be developed in a separate deployment with a distinct license file.
Please contact aPriori support if you have questions about deployments, or any other aspect of aPriori IT architecture.