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

Entity badges

Themes

Theme configuration

Custom Fields

Configuring custom Fields and custom field groups

Activity Management

Integration

Exchange

Security

• Keycloak

Publishing APIs.

• Model Services

Model Services - REST

• Model Services with API objects

Model Services Versioning

• 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