Common Configuration Patterns
The goal of this document is to develop patterns of application configuration to meet client-specific business requirements. The high-level goals of any configuration is that it is:
- Run-time configurable, if possible
- Safe
- Secure
- How it is done is clear, well-documented, and works across releases
- Upgradable and maintainable
- If deploy-time, deployments should be as independent as possible and not require downtime - shouldn't touch CRM
For each item, we should provide:
- some documentation on what it is and how it works
- some support for estimating the effort required for this type of configuration with small/medium/large definitions if required
- measure of maintainability
- ...
Potential Strategies:
- finance should be mixed in and not customized - not used as "base"
- Does the portal server need to be mixed in to finance or can finance be all remote too
- Implement FDC3 for certain types of loosely coupled integrations
Functional
CRM
Badges
Themes
Custom Fields
Configuring custom Fields and custom field groups
Activity Management
Integration
Exchange
Security
Keycloak
Publishing APIs.
Model Services
Model Services with API objects
NexJS Server APIs (NodeJS prototype)
Consuming APIs
UX Integration
Standard Portlet extensions (UX Augments)
Custom NexJ Portlets (with supporting Business Model objects)
Remote Portlets
Technologies
Reporting Dashboard Portlets
Event Integration
- Web Hooks?
Data Integration
Streaming outbound
- Streaming inbound
- Data Loading (import toolkit)
Business Model Integrations
Adding new primitive fields
Adding new objects