[releases/29.x] [ALAppExtensions #30429][Event Request][Extensibility Request] Additional Events to resolve Ambiguous Integration Table Mappings with shared BC Table IDs (Codeunit "CRM Order Status Update Job", Codeunit "CRM Integration Management", Ta... - #10996
Conversation
…ntegration table mappings (#10578) ## Summary Adds four integration events so extensions can select the correct `Integration Table Mapping` when several mappings share the same Business Central `Table ID` — for example, a `Sales Header` mapping that syncs quotes alongside the standard sales order mapping. Today the base code disambiguates only by `Table ID`, so extensions with additional same-table mappings can resolve the wrong mapping during order-status updates, coupling, uncoupling, and match-based coupling. Requested via [ALAppExtensions #30429](microsoft/ALAppExtensions#30429). ## Changes | Object | Procedure | New event | | --- | --- | --- | | Codeunit "CRM Order Status Update Job" | `UpdateSalesOrders` | `OnUpdateSalesOrdersOnBeforeFindIntegrationTableMapping` | | Table "Coupling Record Buffer" | `Initialize` | `OnAfterInitialize` | | Codeunit "CRM Integration Management" | `RemoveCoupling` | `OnRemoveCouplingOnBeforeGetIntegrationTableMappingForUncoupling` | | Codeunit "CRM Integration Management" | `MatchBasedCoupling` | `OnMatchBasedCouplingOnBeforeGetIntegrationTableMappingForMatchBasedCoupling` | All events are thin `[IntegrationEvent(false, false)]` publishers. `RecordRef` context parameters are passed by value (read-only) so subscribers can inspect the source record to choose the mapping without mutating the caller's state, matching the existing input-only `RecordRef` events in the integration sync engine. Fixes [AB#647520](https://dynamicssmb2.visualstudio.com/1fcb79e7-ab07-432a-a3c6-6cf5a88ba4a5/_workitems/edit/647520) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4f698109-800e-4840-b9b5-603e3e682257
GitHub Actions
Inactive
github-actions
Bot
added
the
Team: Integrations
Good Sense Reviewer - Round 1Recommendation: AcceptWhat this PR doesThis adds four integration events so extensions can choose the correct Integration Table Mapping when more than one mapping uses the same Business Central table ID. The event placement is suitable. Three events run before the existing mapping lookup continues, so subscribers can add extra filters to the same Integration Table Mapping record. The buffer event runs after standard initialization has filled the record, so subscribers have the final context before the UI uses it. With no subscribers, the existing filters, FindFirst calls, coupling flow, and sync job flow stay unchanged. Problem-solution fitFit: Strong The requested behavior is to let extensions disambiguate mapping selection in sync, coupling, uncoupling, and match-based coupling flows. The diff adds narrow extension points at those lookup or initialization points without changing default behavior. SuggestionsNone. Risk assessment and necessityRisk: Low. The change is additive and only publishes new local integration events in BaseApp integration code. The publisher declarations and call sites are present at the intended points, and the existing mapping filters still run when there are no subscribers. Necessity: The change is justified. Without these events, extensions that add another mapping for the same Business Central table can hit the standard mapping and get noisy or wrong sync, coupling, or uncoupling behavior. The scope is narrow and matches that problem.
|
3de8734
into
releases/29.x
4 participants
Summary
Backport of bug #647520 to releases/29.x.
Fixes AB#648901
Original PR: #10578