Custom functions are invoked from maps, resolved into port and adapter properties and pipeline-component property values, and evaluated in routing expressions. Those are hot, repeated, sometimes parallel call sites. The discipline is not purity, it is that every invocation is one deliberate, bounded operation whose cost you can name. A function that formats a date costs nothing; a function that calls a stored procedure costs one round-trip; a function that chains three external calls and a retry loop has stopped being a function and become a hidden integration.

Deterministic helpers, date formats, check digits, string normalization, static code tables, remain the default, because they are trivially testable and safe to call anywhere at any frequency. When a function genuinely needs external data, keep the call single-purpose and be precise about how often it runs. A lookup against a reference table is fine. A transactional sequence draw, an EDI interchange control number from a counter table, say, is fine too, provided it executes exactly once per message: in a map, assign the result to an xsl:variable once and reference the variable, never call the function inline per segment. Every call draws a number. The EDI 850 tutorial shows the pattern end to end.

What still does not belong in a function is bulk enrichment of message content, fetching live data per record across a large batch. That is a content enricher, and it belongs on a port via a caller adapter, where the call is visible, retryable and resilient, instead of buried as a per-line network call that freezes a map mid-transform when the reference system slows down.