My BizTalk Code Review Checklist

I recently put together a BizTalk Code Review checklist for our development teams, and thought I’d share the results.

We didn’t want some gargantuan list of questions that made code review prohibitive and grueling. Instead, we wanted a collection of common sense, but concrete, guidelines for what a BizTalk solution should look like. I submit that any decent BizTalk code reviewer would already know to look out for the items below, but, having the checklist in written form ensures that developers starting new projects know EXACTLY what’s expected of them.

I’m sure that I’ve missed a few things, and would welcome any substantive points that I’ve missed.

BizTalk Code Review Checklist

Naming Standards Review
Standard Result Correction Details
Pass Fail
Visual Studio.NET solution name follows convention of:
[Company].[Dept].[Project]
Visual Studio.NET project name follows convention of:
[Company].[Dept].[Project].[Function]

Schema name follows convention of:
[RootNodeName]_[Format].xsd

Property schema name follows convention of:
[DescriptiveName]_PropSchema.xsd

XSLT map name follows convention of:
[Source Schema]_To_[Dest Schema].btm

Orchestration name follows convention of:
[Meaningful name with verb-noun pattern].odx

Pipeline name follows convention of:
Rcv_[Description].btp /
Snd_[Description].btp

Orchestration shape names match BizTalk Naming Standards document
Receive port name follow convention of:
[ApplicationName].Receive[Description]

Receive location name follows convention of:
[Receive port name].[Transport]

Send port name follows convention of:
[ApplicationName].Send[Description].[Transport]

Schema Review
Standard Result Correction Details
Pass Fail
Namespace choice consistent across schemas in project/name
Nodes have appropriate data types selected
Nodes have restrictions in place (e.g. field length, pattern matching)
Nodes have proper maxOccurs and minOccurs values
Node names are specific to function and clearly identify their contents
Auto-generated schemas (via adapters) have descriptive file names and “types”
Schemas are imported from other locations where appropriate to prevent duplication
Schemas that import other schemas have a “root reference” explicitly set
Clear reasons exist for the values promoted in the schema
Schema elements are distinguished appropriately
Schema successfully “validates” in Visual Studio.NET
Multiple different instance files successfully validate against the schema

Mapping Review
Standard Result Correction Details
Pass Fail
Destination schema has ALL elements defined with either an inbound link, functoid, or value.
Functoids are used correctly
Scripting functoid has limited inline code or XSLT.
Scripting functoid with inline code or XSLT is well commented
Database functoids are not used
Multiple “pages” are set up for complex maps
Conversion between data types is done in functoids (where necessary)
Map can be validated with no errors
Multiple different input instance files successfully validate against the map

Orchestration Review
Standard Result Correction Details
Pass Fail
Each message and variable defined in the orchestration are used by the process
Transactions are used appropriately
All calls to external components are wrapped in an exception-handling Scope
No Expression shape contains an excessive amount of code that could alternately be included in an external component
The Parallel shape is used correctly
The Listen shape is not used in place of transaction timeouts
All Loops have clearly defined exit conditions
Where possible, message transformations are done at the “edges” (i.e. port configurations)
Calling one orchestration from another orchestration is done in a manner that supports upgrades
Correlation is configured appropriately
All messages are created in an efficient manner
The message is not “opened” in unnecessary locations
All variables are explicitly instantiated
No port operations are named the default “Operation_1”
Port Types are reused where possible
All Request/Response ports exposed as a web service are equipped with a SOAP fault message.
Orchestration has trace points inserted to enable debugging in later environments
Orchestration design patterns are used wherever possible

Business Rule Review
Standard Result Correction Details
Pass Fail
Business rule output tested for all variations of input
Conflict resolution scenarios are non-existent or limited
Long-term fact retrievers used for static facts
Business Rule vocabulary defined for complex rule sets

Configuration Review
Standard Result Correction Details
Pass Fail
Receive Port / Send Port tracking configurations appropriately set
Maps are applied on the Receive Port where appropriate
Send port retry interval set according to use case
Maps are applied on Send Port where appropriate
Send port does NOT have filter attached if connected to an orchestration
Subscriptions exist for every message processed by the application

Deployment Package Review
Standard Result Correction Details
Pass Fail
“Destination Location” for each artifact uses “%BTAD_InstallDir%” token vs. hard coded file path
All supporting artifacts (e.g. helper components, web services, configuration files) are added as Resources
Binding file is NOT a resource if ports use transports with passwords

Overall Solution Architecture Review
Standard Result Correction Details
Pass Fail
Solution is organized in Visual Studio.NET and on disk in a standard fashion
Passwords are never stored in clear text
All references to explicit file paths are removed / minimized
All two-way services INTO BizTalk produce a response (either expected acknowledgement or controlled exception message)
Calls to request/response web services that take an exceptional amount of time to process are reengineered to use an “asynchronous callback” pattern
Exceptions are logged to an agreed upon location
Long-running processes have a way to inspect progress to date
Solution has been successfully tested with REAL data from source systems
Solution has been successfully tested while running under user accounts with permissions identical to the production environment
Messages are validated against their schema per use case requirements
Processes are designed to be loosely coupled and promote reuse where possible

Technorati Tags:



Categories: BizTalk, General Architecture

13 replies

  1. Terrific! It’s always good to have a standard.🙂

  2. Great work Richard! I’ll use it by 150%.

    My additions (mostly to create a test-driven solution):

    Naming Standard:
    The name convention document is a part of solution.
    Project properties: Application name, Assembly name, Default namespace, using right Key file! Deployment server (local name changed to “local’)

    Schema:
    Target namespaces (use the name convention for it)
    Set of the test schema instances (as a part of project) to cover main parts of the schema validation

    Maps:
    Set of the test source schema instances (as a part of project) to cover main parts of the map

    Orchestrations:
    Orchestration artifact names follow the name convention.
    Preference for using multi-part messages.
    Set of the test messages (as a part of project) to cover main parts of the orchestration

    Ports: (I’d rather include all port properties review as a separate part)
    Test direct ports for testing the message transmitting whenever it possible.

    Deployment package:
    All supporting artifacts ( … add the custom SQL code)
    Test harness projects

    Overall solution architecture:
    Implementation of the Error sub-system (not for small solutions)

    Regards,

    Leonid Ganeline [BizTalk MVP]
    http://geekswithblogs.net/leonidganeline/

  3. Handsome!

    I’m new in BizTalk development. And this kind of checklist is very useful.

    IT could be even more useful if there was some web links to related BizTalk articles for each item whenever possible.
    This list could then become an auto training track.

    Thanks again for this great article.

    Pascal

  4. Great Work Richard!

  5. Thanks Richard for fabulous post

  6. Still very useful, even after all these years …

  7. This is amazing and exactly what I was looking for. Thank you Richard, I stay humbled by the help and mentor ship you offer to us.

Trackbacks

  1. New and Notable 187 - Sam Gentile
  2. BizTalk Code Reviews - Jason Hyland
  3. You’ve Just Bought BizTalk Server. Congrats. Now What? « Richard Seroter’s Architecture Musings
  4. BizTalk Environment Migration Checklist « Richard Seroter’s Architecture Musings
  5. New and Notable 187 : Sam Gentile's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: