Anti-Pattern: Everything but the Kitchen Sink Map























Name:


Everything but the Kitchen-Sink Map


Description:


Given a complex process with many complex rules, everything (business logic, related and unrelated procedures, etc) is shoved into the map.


Symptoms:


Symptoms include the following:


·         Map contains an overwhelming number of “scriptoids” (scripting functoid) performing custom business logic.


·         Map relies on custom functoids or .NET components to perform custom business logic.


·         Map is difficult to debug because of excessive complexity.


·         Map is difficult to maintain; when a rule changes, one or more custom scripts or code must be modified, tested and redeployed.


·         Business rules are difficult or impossible to deduce by looking at the map.


·         Business logic is sprayed across the BizTalk Server solution, from maps to orchestrations to the Business Rules Engine to external components and systems.


·         Encryption, data modification, and other value-added transforms appear in the map.


Pain:


This anti-pattern produces pain in the following areas:


·         Maintenance


·         Performance


·         Enhancement


·         Debugging


·         Monitoring


Cure:


There are many potential cures you can explore:


·         Business Logic


o   Use the BizTalk Business Rules Engine (BRE). This will increase the flexibility of your solution, ease some aspects of maintenance (maps, etc) at the expense of adding a dependency to the BRE, and force the business team to succinctly define a vocabulary and ruleset.


o   Call custom components containing business logic from an orchestration. For example, if you have a component that uses a complex algorithm to assign a ranking to a customer, call it from an orchestration (or custom pipeline component) and not from within a map.


o   Concentrate business logic in Orchestrations, the BRE and external LOB systems. For example, if your solution is processing 837 Professional claims, a combination of BRE and Orchestration logic may filter based on primary diagnosis and geographic region but a back-end adjudication system will handle most health claim rules.


o   Don’t forget about BAM. By carefully placing logic in appropriate places, you may enhance your ability to track key data using BAM.


·         Value-Added Transformations


o   Can you migrate some of the transformations into a custom pipeline? For example, encrypting certain fields in a message is better done in a custom pipeline component; doing so may improve performance and make maintenance and debugging tasks easier.


o   If you commonly apply the same pattern of 4 or more functoids against many elements, consider combing them into a custom functoid. This simplifies reuse, makes it easier to modify (change the custom functoid instead of ever instance of the transform), and may provide a performance benefit.


·         Other


o   Locate business logic and other procedures as far downstream in the business process as possible. By deferring potentially complex procedures, you may be able to avoid them.


o   Break large maps into smaller maps and run them serially in an orchestration. It may be better to trade a little performance for easier editing and debugging.


o   Develop a coherent plan for business logic based on business requirements, solution architecture, and performance goals. Make sure the plan is followed through sound process.


Comments:


BizTalk maps are great because they are so flexible. This also makes them dangerous because all manner of logic can be tossed in on a whim. Before adding more logic to a map, reconsider – is it better placed somewhere else?

Comments (1)

  1. keithknight says:

    Ah yes, have seen this one before! When confronted with an ‘everything but the kitchen sink’ map I usually reach for Steve Hart’s map documenter tool to try and help me come to grips with how the map works.

    http://www.hartsteve.com/2006/02/20/biztalk-map-documenter

Skip to main content