Share via

Anti-Pattern: Everything but the Kitchen Sink Map

  • Article

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

  • Anonymous
    December 13, 2006
    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