bc-code-intelligence-mcp 1.3.3 → 1.3.4

package/embedded-knowledge/domains/alex-architect/api-page-development-patterns.md

@@ -1,87 +0,0 @@
----
-title: "AL API Page Development Patterns"
-domain: "alex-architect"
-difficulty: "intermediate"
-bc_versions: "14+"
-tags: ["api", "pages", "odata", "integration", "architecture"]
-samples: "samples/api-page-implementation.md"
-type: "implementation-pattern"
-category: "api-development"
-pattern_type: "good"
-severity: "medium"
-impact_level: "high"
-improvement_suggestion: "Use API pages for structured external system integration"
-implementation_steps: ["design-api-structure", "implement-field-exposure", "optimize-performance"]
-validation_criteria: ["odata-compliance", "security-integration", "performance-optimization"]
-technical_areas: ["al-code", "integration"]
----
-
-# AL API Page Development Patterns
-
-## Overview
-
-API pages in Business Central provide structured OData endpoints for external system integration. Unlike standard pages, API pages focus exclusively on data exchange with minimal UI considerations, requiring careful design for optimal performance and maintainability.
-
-**Key Decision**: API pages should expose logical business entities rather than raw table structures, providing stable integration contracts that abstract internal data organization.
-
-## Strategic Framework
-
-### API Page Design Philosophy
-- **Business Entity Focus**: Expose meaningful business concepts (Customer, Item, SalesOrder) rather than normalized table structures
-- **Contract Stability**: Maintain consistent field names and structures across BC versions to protect integration investments
-- **Performance Optimization**: Design for efficient data retrieval and modification patterns expected by consuming applications
-- **Security Integration**: Leverage BC's built-in authentication and authorization without exposing sensitive internal structures
-
-### Integration Architecture Patterns
-API pages serve as the primary integration layer between Business Central and external systems. They should provide complete business entity representations while maintaining clear separation between internal data models and external contracts.
-
-## Architecture Focus
-
-### Page Structure Design
-API pages require specific architectural considerations distinct from interactive pages. The PageType API designation enables OData endpoint generation with automatic JSON serialization and standardized query capabilities.
-
-### Field Exposure Strategy
-Expose fields that represent complete business entity state while avoiding internal implementation details. Include essential business identifiers, descriptive fields, and workflow status information that external systems need for business logic.
-
-### Relationship Management
-Design API pages to include related entity references through careful use of lookup fields and calculated fields. This enables consuming applications to navigate business relationships without requiring multiple API calls.
-
-### Version Compatibility
-Structure API pages to maintain backward compatibility as business requirements evolve. Use consistent naming conventions and avoid breaking changes to established field contracts.
-
-## Best Practices
-
-### Entity Modeling
-- **Complete Business Context**: Include all fields necessary for external systems to make business decisions
-- **Logical Grouping**: Group related information to minimize round-trips for common business scenarios
-- **Status Visibility**: Expose workflow states and business status fields that affect integration logic
-- **Audit Information**: Include creation dates, modification timestamps, and responsible user information
-
-### Performance Considerations
-- **Selective Field Loading**: Design pages to load only necessary fields for common query patterns
-- **Efficient Filtering**: Support standard OData filtering on key business fields like dates, status, and identifiers
-- **Batch Operation Support**: Enable bulk data operations where business processes require them
-- **Caching Awareness**: Structure responses to support effective caching strategies in consuming applications
-
-### Security Implementation
-- **Principle of Least Privilege**: Expose only fields that external systems legitimately need for business operations
-- **Sensitive Data Protection**: Exclude internal identifiers, system fields, and confidential business information
-- **Access Control Integration**: Leverage BC's permission system to control API access at field and record levels
-- **Audit Trail Maintenance**: Ensure API operations create appropriate audit records for compliance requirements
-
-## Anti-Patterns
-
-### Avoid These Approaches
-- **Direct Table Exposure**: Exposing raw table structures without business context abstraction
-- **Internal Field Leakage**: Including system fields, internal identifiers, or implementation details in API contracts
-- **Incomplete Entity Representation**: Requiring multiple API calls to reconstruct basic business entity state
-- **Breaking Contract Changes**: Modifying existing field names or removing fields without proper versioning strategy
-
-### Common Design Mistakes
-- **Over-Normalization**: Creating APIs that mirror database structure rather than business entity logic
-- **Under-Documentation**: Failing to provide clear guidance on field usage and business meaning
-- **Security Oversights**: Exposing sensitive information or bypassing standard BC security mechanisms
-- **Performance Blindness**: Designing APIs without considering query patterns and data volume implications
-
-*Implementation examples: see samples/api-page-implementation.md*
-*Related patterns: facade-pattern-external-api.md, api-authentication-patterns.md*

package/embedded-knowledge/domains/alex-architect/complex-facade-patterns.md

@@ -1,155 +0,0 @@
----
-title: "Complex Facade Patterns"
-domain: "alex-architect"
-difficulty: "advanced"
-bc_versions: "14+"
-tags: ["complex-facade", "enterprise-patterns", "multi-layer-facade", "facade-composition"]
-prerequisites: ["facade-pattern-al-implementation", "enterprise-architecture", "advanced-al"]
-samples: "samples/complex-facade-patterns.md"
-related_topics: ["facade-pattern-al-implementation", "enterprise-integration-patterns"]
----
-
-# Complex Facade Patterns
-
-## Overview
-
-Complex Facade Patterns extend basic facade concepts to handle enterprise-scale scenarios involving multiple subsystems, cross-cutting concerns, and sophisticated business logic coordination. These patterns enable management of intricate system architectures while maintaining clean, manageable interfaces.
-
-**Key Benefit**: Enables management of complex enterprise systems through sophisticated facade architectures that maintain simplicity for consumers while handling intricate backend coordination.
-
-## Advanced Facade Architectures
-
-### Multi-Layer Facade Systems
-Design facade hierarchies where higher-level facades coordinate lower-level facades, enabling different abstraction levels for different consumer types.
-
-### Composite Facade Coordination
-Implement facade composition patterns where multiple specialized facades work together to provide comprehensive business capability interfaces.
-
-### Domain-Specific Facade Clusters
-Create facade clusters that serve specific business domains while maintaining coordination capabilities for cross-domain operations.
-
-## Enterprise Integration Patterns
-
-### Cross-System Facade Orchestration
-Design facades that coordinate operations across multiple Business Central environments, external systems, and cloud services.
-
-### Transaction-Spanning Facades
-Implement facades that manage distributed transactions and coordination across multiple systems while providing simple operation interfaces.
-
-### Event-Driven Facade Coordination
-Integrate complex facades with event-driven architectures to enable reactive coordination and loose coupling between facade layers.
-
-## Sophisticated Business Logic Patterns
-
-### Workflow Facade Integration
-Design facades that encapsulate complex workflow orchestration, managing state transitions, approvals, and business rule enforcement.
-
-### Policy-Driven Facade Behavior
-Implement facades that adapt their behavior based on business policies, user roles, and dynamic configuration without interface changes.
-
-### Context-Sensitive Facade Operations
-Create facades that provide different capabilities and behaviors based on execution context, user permissions, and system state.
-
-## Performance and Scalability Patterns
-
-### Caching-Enabled Facade Architecture
-- Implement multi-level caching within facade hierarchies
-- Design cache invalidation strategies for complex data dependencies
-- Support distributed caching for multi-instance scenarios
-- Optimize cache performance for high-frequency facade operations
-
-### Asynchronous Facade Operations
-- Design asynchronous facade patterns for long-running operations
-- Implement callback and notification mechanisms for async completion
-- Support progress tracking and cancellation for complex operations
-- Enable parallel execution of independent facade operations
-
-## Advanced Error Handling
-
-### Cascade Error Management
-Implement sophisticated error handling that can manage failures across multiple facade layers and subsystem components.
-
-### Recovery and Compensation
-Design compensation patterns that can recover from partial failures in complex operations spanning multiple systems.
-
-### Circuit Breaker Integration
-Integrate circuit breaker patterns within facades to prevent cascade failures and enable graceful degradation.
-
-## Security and Compliance Patterns
-
-### Multi-Tenant Facade Security
-Design facades that handle multi-tenant security concerns while providing unified interfaces across tenant boundaries.
-
-### Compliance-Aware Operations
-Implement facades that automatically handle compliance requirements such as audit logging, data retention, and privacy regulations.
-
-### Permission-Based Facade Adaptation
-Create facades that dynamically adapt their available operations based on user permissions and security policies.
-
-## Monitoring and Diagnostics
-
-### Facade Performance Analytics
-Implement comprehensive performance monitoring across facade hierarchies to identify bottlenecks and optimization opportunities.
-
-### Operation Tracing
-Design distributed tracing capabilities that can track operations across multiple facade layers and subsystem components.
-
-### Health Monitoring
-Create health monitoring systems that can assess the status of complex facade architectures and provide early warning of issues.
-
-## Integration Strategies
-
-### API Gateway Facade Patterns
-Design facades that serve as API gateways, providing external access to complex internal capabilities with appropriate security and rate limiting.
-
-### Microservice Facade Coordination
-Implement facades that coordinate microservice interactions while hiding service discovery, load balancing, and failure handling.
-
-### Legacy System Integration
-Create facades that modernize access to legacy systems while maintaining compatibility and enabling gradual migration strategies.
-
-## Testing Complex Facades
-
-### Multi-Layer Testing Strategies
-- Implement testing strategies that validate facade behavior at multiple abstraction levels
-- Design integration testing that covers complete facade interaction scenarios
-- Support performance testing under realistic load conditions
-- Enable chaos engineering testing for resilience validation
-
-### Mock and Simulation Patterns
-- Create sophisticated mocking strategies for complex facade dependencies
-- Design simulation capabilities for testing facade behavior under various conditions
-- Support A/B testing for facade behavior changes
-- Enable testing of failure scenarios and recovery patterns
-
-## Best Practices
-
-### Architectural Principles
-- Maintain clear separation of concerns across facade layers
-- Design for both horizontal and vertical scaling requirements
-- Implement comprehensive monitoring and observability
-- Plan for facade evolution and migration strategies
-
-### Operational Excellence
-- Provide detailed documentation for complex facade architectures
-- Implement automated testing and deployment pipelines
-- Support configuration management for complex facade behaviors
-- Maintain clear operational procedures for complex facade management
-
-## Common Pitfalls
-
-### Over-Engineering
-Avoid creating unnecessarily complex facade architectures that become harder to maintain than the systems they're meant to simplify.
-
-### Performance Overhead
-Prevent facade layers from introducing significant performance overhead that negates the benefits of system simplification.
-
-### Tight Coupling
-Avoid creating tight coupling between facade layers that reduces system flexibility and makes changes difficult.
-
-### Monitoring Gaps
-Ensure comprehensive monitoring coverage across all facade layers to prevent issues from going undetected in complex architectures.
-
-*Complete complex facade examples: samples/complex-facade-patterns.md*
-*Basic facade patterns: facade-pattern-al-implementation.md*
-*Enterprise integration: enterprise-integration-patterns.md*

package/embedded-knowledge/domains/alex-architect/facade-pattern-al-implementation.md

@@ -1,138 +0,0 @@
----
-title: "Facade Pattern AL Implementation"
-domain: "alex-architect"
-difficulty: "intermediate"
-bc_versions: "14+"
-tags: ["facade-pattern", "structural-patterns", "api-simplification", "complexity-hiding"]
-prerequisites: ["object-orientation-al", "interface-basics", "module-design"]
-samples: "samples/facade-pattern-al.md"
-related_topics: ["complex-facade-patterns", "adapter-pattern-al"]
----
-
-# Facade Pattern AL Implementation
-
-## Overview
-
-The Facade Pattern provides a simplified interface to a complex subsystem, hiding the complexity of multiple interacting objects behind a single, easy-to-use interface. In AL development, facades are essential for creating clean APIs and managing complex business logic interactions.
-
-**Key Benefit**: Simplifies client code by providing a unified interface to complex subsystems while maintaining loose coupling and flexibility.
-
-## Core Facade Architecture
-
-### Unified Interface Design
-Create single interfaces that encapsulate complex operations across multiple AL objects, procedures, and business logic components.
-
-### Complexity Encapsulation
-Hide implementation details of complex subsystems behind simple, focused facade methods that handle coordination and orchestration.
-
-### Dependency Management
-Manage dependencies between multiple subsystem components within the facade, preventing clients from needing to understand complex relationships.
-
-## Implementation Strategies
-
-### Business Process Facades
-Design facades that encapsulate complete business processes, coordinating multiple tables, pages, and codeunits to provide single-operation interfaces.
-
-### Data Access Facades
-Implement facades that simplify complex data access patterns, hiding join operations, filtering logic, and data transformation from client code.
-
-### Integration Facades
-Create facades for external system integration that hide protocol details, authentication, and error handling behind simple method calls.
-
-## AL-Specific Patterns
-
-### Codeunit Facade Implementation
-Use codeunits as facade implementations that coordinate multiple AL objects while providing clean, procedure-based interfaces.
-
-### Table Facade Extensions
-Extend table objects with facade methods that encapsulate complex business logic while maintaining data integrity and validation rules.
-
-### Page Integration Facades
-Design page-level facades that coordinate multiple page elements and actions to provide simplified user interaction patterns.
-
-## Advanced Facade Techniques
-
-### Layered Facade Architecture
-Implement multiple facade layers that provide different levels of abstraction for different types of clients and usage scenarios.
-
-### Context-Aware Facades
-Design facades that adapt their behavior based on user context, permissions, or system configuration while maintaining consistent interfaces.
-
-### Event-Integrated Facades
-Integrate facade operations with AL event systems to provide notifications and enable extensibility without facade modification.
-
-## Performance Considerations
-
-### Operation Optimization
-Optimize facade operations to minimize unnecessary object instantiation and method calls while maintaining interface simplicity.
-
-### Caching Integration
-Implement intelligent caching within facades to improve performance for frequently accessed complex operations.
-
-### Resource Management
-Design facades to efficiently manage resources and connections, especially for integration and external system access scenarios.
-
-## Error Handling and Validation
-
-### Unified Error Management
-- Implement consistent error handling across all facade operations
-- Provide meaningful error messages that abstract subsystem complexity
-- Support error recovery and retry mechanisms within facade logic
-- Maintain error logging and diagnostics for troubleshooting
-
-### Input Validation
-- Centralize validation logic within facade methods
-- Provide comprehensive parameter validation before subsystem operations
-- Support business rule validation across multiple subsystem components
-- Enable early error detection to prevent inconsistent states
-
-## Best Practices
-
-### Design Principles
-- Keep facade interfaces focused and cohesive
-- Implement facades at appropriate abstraction levels for target clients
-- Maintain clear separation between facade logic and subsystem implementation
-- Design for both simplicity and extensibility
-
-### Documentation Standards
-- Provide clear documentation for facade capabilities and limitations
-- Include examples of common usage patterns and scenarios
-- Document any performance characteristics or constraints
-- Maintain clear guidance for when to use facade versus direct subsystem access
-
-## Integration Patterns
-
-### Service Layer Integration
-Integrate facades with service layer patterns to provide business service interfaces that coordinate multiple business capabilities.
-
-### API Gateway Patterns
-Use facades as API gateways that provide external access to internal Business Central capabilities with appropriate security and validation.
-
-### Microservice Coordination
-Design facades that coordinate microservice interactions while providing unified interfaces for complex business operations.
-
-## Testing Strategies
-
-### Facade Testing
-- Implement comprehensive testing for facade operations and edge cases
-- Mock subsystem dependencies to enable isolated facade testing
-- Test error handling and recovery scenarios thoroughly
-- Validate facade performance under different load conditions
-
-### Integration Testing
-- Test complete end-to-end scenarios through facade interfaces
-- Validate subsystem coordination and data consistency
-- Test facade behavior under various system conditions and configurations
-- Ensure facade operations maintain transactional integrity
-
-## Common Pitfalls
-
-### Over-Simplification
-Avoid over-simplifying facades to the point where necessary functionality becomes inaccessible to clients requiring more control.
-
-### Facade Bloat
-Prevent facades from becoming bloated with too many responsibilities that reduce their effectiveness and maintainability.
-
-*Complete facade implementation examples: samples/facade-pattern-al.md*
-*Complex facade patterns: complex-facade-patterns.md*
-*Related structural patterns: adapter-pattern-al.md*

package/embedded-knowledge/domains/alex-architect/facade-pattern-external-api.md

@@ -1,79 +0,0 @@
----
-title: "AL Facade Pattern for External API Integration"
-domain: "alex-architect"
-difficulty: "intermediate"
-bc_versions: "14+"
-tags: ["facade-pattern", "api-integration", "abstraction", "maintainability"]
-samples: "samples/facade-pattern.md"
-type: improvement-pattern
-category: "architectural-patterns"
-pattern_type: good
-severity: medium
-impact_level: medium
-improvement_suggestion: "Use facade pattern to simplify external API integration"
-implementation_steps: ["create-facade-codeunit", "abstract-api-calls", "centralize-error-handling"]
-validation_criteria: ["single-entry-point", "hidden-complexity", "clean-interfaces"]
-technical_areas: ["al-code", "integration"]
----
-
-# AL Facade Pattern for External API Integration
-
-## Overview
-
-The facade pattern creates a unified, simplified interface to complex external API systems. Instead of exposing raw API complexity throughout your AL codebase, the facade provides a clean business-focused entry point that handles all technical implementation details internally.
-
-**Core Principle**: One dedicated codeunit acts as the single gateway to external systems, abstracting authentication, error handling, retry logic, and data transformation.
-
-## Strategic Framework
-
-### When to Apply Facade Pattern
-- **Multiple API endpoints** required for single business operation
-- **Complex authentication flows** (OAuth, JWT, multi-step auth)
-- **Inconsistent external API responses** requiring normalization
-- **Rate limiting and retry logic** needed across multiple calls
-- **Future API changes** anticipated requiring isolation from business logic
-
-### Architecture Benefits
-- **Dependency Isolation**: External system changes don't cascade through codebase
-- **Simplified Testing**: Clear boundaries for mocking external dependencies
-- **Centralized Logic**: Authentication, error handling, and retry patterns in one place
-- **Business Focus**: Consuming objects work with business concepts, not technical APIs
-
-## Architecture Focus
-
-### Facade Structure
-Create a dedicated codeunit containing:
-- **Public Methods**: Business-focused operations (GetCustomerData, SyncOrderStatus)
-- **Private Methods**: Technical API calls, authentication, error handling
-- **Internal State**: Connection management, token caching, configuration
-
-### Interface Design Principles
-- **Business Language**: Method names reflect business operations, not API endpoints
-- **Simplified Parameters**: Hide complex API parameter mapping from consumers
-- **Consistent Returns**: Standardized response patterns regardless of underlying API variations
-- **Error Abstraction**: Convert technical errors to business-meaningful messages
-
-## Best Practices
-
-### Implementation Guidelines
-- **Single Responsibility**: Each facade handles one external system or related service group
-- **Stateless Design**: Avoid maintaining connection state between method calls
-- **Configuration Driven**: Use setup tables for URLs, credentials, and API versions
-- **Comprehensive Logging**: Log all external interactions for troubleshooting
-
-### Error Handling Strategy
-- **Graceful Degradation**: Provide fallback behaviors when external systems unavailable
-- **Retry Logic**: Implement exponential backoff for transient failures
-- **Circuit Breaker**: Prevent cascading failures when external system is down
-- **User-Friendly Messages**: Translate technical errors to actionable business guidance
-
-## Anti-Patterns
-
-### Avoid These Approaches
-- **Direct API Calls** scattered throughout business logic objects
-- **Shared HTTP Client** instances without proper abstraction layer
-- **Exposed Technical Details** like HTTP status codes in business methods
-- **Mixed Responsibilities** combining business logic with API communication
-
-**Implementation Reference**: see samples/facade-pattern.md
-**Related Patterns**: error-handling-patterns.md, api-authentication-patterns.md