X++ Development / Field notes
X++ Chain of Command: Keep the Original Business Method in the Flow
Chain of Command lets an extension wrap supported public or protected methods while preserving the original implementation in the call chain. A wrapper is safest when its scope is narrow, its signature matches the target and its continuation behavior is reviewed against the platform's documented rules.
Confirm the exact method is a supported extension point
Before writing a wrapper, verify that the target method and type support method wrapping in the application's platform version. A method name found in source or metadata is not, by itself, proof that a wrapper will run in the target environment.
Record the target type, method signature, package reference and platform version. Check for explicit attributes or documented restrictions that prevent the extension point from being used.
Keep next unconditional unless the method is replaceable
Microsoft's Chain of Command guidance requires wrapper methods to call next so that the chain and original implementation run. The call belongs in the first-level method statements and cannot be hidden inside a conditional branch or loop. Replaceable methods have a documented exception, but breaking the chain should be a deliberate and narrowly scoped decision.
Treat the wrapper as a link in an extension chain, not as an overwrite. Other installed extensions may also participate, so avoid assumptions about which wrapper runs first or last.
- Keep the wrapper signature aligned with the target
- Call next in the documented position
- Place only the required before/after logic around the call
- Review cross-model dependencies and target version
Keep side effects and transaction ownership clear
A wrapper that introduces a new database write, external call or posting action changes the operational meaning of the method. Keep the extension close to the requirement and identify which layer owns transaction control, validation and error reporting. Avoid turning a method wrapper into a second process that duplicates standard business behavior.
If the platform does not expose a suitable extension point, document the gap and use Microsoft's extensibility request process or another supported design. Do not imply that every framework method can be wrapped.
Accept behavior at runtime as well as at compile time
A successful compile confirms that the extension code builds in its package context. It does not establish that the intended runtime path invokes the wrapper or that the full process remains correct with other extensions installed.
Test the normal path, relevant exceptions, permissions and the resulting business record in the target environment. The acceptance record should name the platform version and the process owner who confirms the outcome.
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.
