Mappings or transformations are one of the most important parts of integration flows. A lot of energy is spent on developing, maintaining and managing such transformation logic. In an XML world, transformations are often developed using XSLT (and some XQuery). But besides these nice standards, a lot of other more proprietary transformation solutions are used.
Just like with normal application logic, integration developers will always strive to re-use already existing interfaces and message formats. E.g. a new application or business partner will be pushed to re-use an already integration flow and corresponding message layout. Existing transformations maybe extended to support specific requirements, thereby going through quite some testing.
But "re-use" of smaller pieces of transformation logic is not done. The concept of invoking lower level pieces of transformation logic does not apply. There are no libraries from which smaller pieces of transformation logic are re-used in multiple mappings.
And this is not even the case within a single mapping. E.g. for transforming a structure occurring multiple times in a source and target message (take for instance a shipping and invoice address), no subroutine (such as TransformAddress() ) will be used.
There are a couple of reasons for this way-of-working:
- messages are often not constructed from standardized building blocks
- source and target message must contain the same data structures multiple times
- re-usable pieces of transformation logic are often small
- managing the re-use of transformation logic across mappings requires discipline
- tools and standards are not helping much
Still, I find it strange that "modularization" is not applicable in the world of integration.
1 comment:
Hello nicee blog
Post a Comment