BizTalk Test Object Model Requirements

By Wesley Thomas,2014-08-27 16:42
31 views 0
BizTalk Test Object Model Requirements

    BizTalk Test Object Model Requirements

    Doc Status DRAFT

    Doc Milestone PathFinder

    Author Catalin Sipos


    This document describes the BizTalk Test Objects requirements, from tracking team’s perspective. The goal is to allow


    Below is a first draft of the tracking test team’s requirements. Note that there is currently good support for the first 2 main categories (R1 and R2) and we are working with tools team for the new UI. If you have requirements similar to R1 and R2, please also have a look at \\cozia\demos or contact me about the components we can offer for reuse.

    R1. Create BizTalk applications:

    R1.1. Installation and cleanup should be end to end

    ; Install starts from BizTalk solution creation and completes when the

    application is live

    ; Provide cleanup should start from a live application and proceed until

    its assemblies are uninstalled

    ; Scenarios will work correctly side by side; installing a new scenario

    is possible when other scenarios are installed and uninstalling a

    scenario will not affect the other scenarios installed

    R1.2. Rapidly develop and clone new scenarios (scenario reusing)

    ; Example: another Equity Loan scenario that has a distribution list on

    the send port

    ; Assembly Generator and Biz Explorer Dump should be usable via

    xml; the test case should not have to code every port creation and


    ; Support for a default admin configuration => by default enlist all

    services in deployed assemblies with the default host and start them

    ; Flexibility: either driven by xml or programmatically build;

    recommend using serializable classes -> free xml representation

    ; Xml should be minimal

    R1.3. Low migration cost from current approach

    R1.4. Simple, robust, efficient

    ; Roll back on errors

    ; No constraints on uninstall

    ; Integrated logging

    R1.5. Install, uninstall strategy should be expressed in the code rather than in

    an xml

    R1.6. Available as a component with no dependency on the test harness R1.7. Support for multi-machine installation

    R2. Message submit and processing

    R2.1. Multiple transport support

    R2.2. Single message, sequence or batch

    R2.3. Asynchronous operation

    R2.4. Support for synchronization

    ; Provide ways to wait for the message to be processed => waiting


    o Wait for service instance completion: pipeline or orchestration

    o Wait for file creation

    o Wait for tracking data to be processed

    o Wait for an answer

    o Wait for an orchestration instance to reach the desired state (e.g.


    ; Supports request response

    R2.5. Atomic

    ; Integrate with context setting, e.g. setting tracking options or


    R2.6. Easy to reuse and clone (e.g. same message, but once as Unicode and

    once as ASCII)

    R2.7. Support for multi-machine (P2)

    R3. Setting tracking options and breakpoints; this is moving to Ken’s team, but we currently have code that handles it

    R4. UI test framework

    R4.1. Independence on the specific technology used underneath (VS

    Environment Framework, Maui, etc)

    R4.2. Robust: support good mechanisms to avoid UI timing issues (event

    driven, wait for idle)

    R4.3. Setup is provided

    R4.4. Language agnostic

    R4.5. Clear, isolated basic functionality

Report this document

For any questions or suggestions please email