Keeping a mapping maintainable

Documenting intent INSIDE the map, avoiding expressions nobody can unpick, and the point at which a transformation belongs in the source system instead. THE MAP IS WHERE THE BUSINESS RULE ENDS UP LIVING, whether or not anybody meant it to. A condition on a status, a default for a missing value, a translation nobody wrote down — those are policy, expressed as expressions, in a place no policy document points at. So document intent where the tool allows it: a comment, a description, a name that says what a piece of logic is FOR. The expression says WHAT and only a comment can say WHY — and in six months only the second is recoverable. AVOID EXPRESSIONS NOBODY CAN UNPICK, and there is a practical test: can you say what it does in one sentence? If not, split it, move it to a lookup, or move it out of the…

In this module: Module 5 · Mappings and transformations

1. 1What a mapping really isFree preview
2. 2The mapper, practically
3. 3Required, optional and the empty element
4. 4Repeating elements and loops
5. 5Conditional mapping
6. 6Functions: strings, numbers and dates
7. 7Dates and time zones, carefully
8. 8Numbers, precision and currency
9. 9Lookups inside a mapping
10. 10Testing a mapping with real data
11. 11Namespaces, and the errors they cause
12. 12Keeping a mapping maintainable
13. 13What breaks: five mapping failures
14. 14Lab briefing · Map two schemas that disagree