Now and then, I see a description of an XI scenario in which some functionality is accomplished by the side effects of a mapping program. This has always troubled me, so I’ll try to explain why side effects are a bad idea.
What are side effects?
According to Wikipedia, a function produces a side effect “if it modifies some state in addition to returning a value”. In the context of a mapping, the returned value is the target document. So if the mapping changes anything else (such as updating the status of a sales order) while performing the mapping, it is producing a side effect.
On the other hand, if the receiver system updates the status of a sales order when it receives the target document, this is not a side effect of the mapping but rather the result of routing the message to the receiver.
Note that performing a lookup in some system as part of a mapping is NOT a side effect, since it does not change the state of the system where the lookup is performed. Neither should the production of logging or trace information be considered side effects even though they do, strictly speaking, modify the system state.
Why side effects are bad
There are many opportunities for errors to occur during message processing in XI, both as a direct result of processing a particular message (mapping errors, connectivity issues, etc) and because of external events (system crash, power loss, etc). To avoid data loss as a result of such errors, XI provides “guaranteed delivery” of asynchronous messages. Basically, this is accomplished by persisting received messages in the database prior to mapping them and forwarding them to the receiving system. Now if an error occurs after mapping but before the message is delivered to the receiver, the message can simply be reprocessed later without the interaction of the sender system. This usually means that any mapping involved is repeated. If the mapping has side effects, these will be repeated as well. The results could range from harmless to disastrous!
Introducing side effects in mappings makes the XI scenario less transparent to other developers and operations staff alike. No-one (hopefully) expects mappings to produce side effects and such side effects are likely completely invisible in the Integration Directory. Only by looking at the actual mapping program (be it graphical, Java, XSLT, etc.) can someone discover what is going on. And I don’t think documentation provides a real solution to this problem – we all know how often documentation actually gets read.
3. Separation of design and configuration
XI was designed with a clear separation of design and configuration – Integration Repository and Integration Directory. In order to implement side effects in mappings, you almost always need to include some kind of configuration in the mapping itself, often in the form of connection information (URL, username, password, etc.). This violates one of the fundamental principles in XI.