BizTalk Solution Documents AID–The Design Specifications–part 1

This is the first of a collection of articles that explain, for my experience, the best way to organize a structure of a document for all the most usual cases.
In this article the design specification of a BizTalk Solution, the same structure can be used for all types of solutions, BizTalk and not.

  • Introduction

Is composed from three areas

    • Associated Documents
      • List of the documents associates to design specifications, normally
        • Pattern (B2B, BPM ) Functional Specification
        • Customer Scenario Specification
        • Some particular documents as
        • TPM Specification
        • BAM Alert and Notification Specification
    • Supported Features

      features/functionalities supported in Scenario for example:

        • Support EDI orders over SFTP
        • Support for CS catalog, order and inventory adapters
        • Create or Update orders either using http post for given URL.
        • Check and update inventory of items.
        • Update User Profile for Brokers and Vendors.
    • Definitions
    • List all particular definitions used in the document, for example:
      • B2B: Business –To- Business
      • TPM: Trading Partner Management
      • CBO: Common Business Object.
      • BAM: Business Activity Monitoring.
      • BAS: Business Activity Services.

Design Overview
List and design, if need, the most important aspects of the solution design, sample:

The general design consists of an orchestration that:

Macro Requests steps

  • New Order coming from Broker.
  • Update Order coming from Broker.
  • Update user profile from Broker.
  • Update Inventory from Vendor.
  • Check Inventory from Vendor.

Describe the formats type:
These requests will be received by hub in different formats such as EDI, Flat Files and XML using different transports like HTTPS, SFTP etc.

Describe the macro steps:

A. Create New Order: Broker will send request either using commerce server website or will post to http URL provided by Hub.

1. New Order using commerce site: Broker will create order using commerce website. This order will be received ………

2. New Order using HTTP Post: Some broker can send their order using HTTP URL specified by Hub…………..

3. EDI Type Orders: EDI type orders will be uploaded to SFTP site. EDI Type orders will be picked by File Receive location. ……..

B. Update Order: Broker will send request either using commerce server website or …….

1. Update Order using HTTP Post: Some broker can send their update order using HTTPURL specified by Hub. …….

2. EDI Type Order: For EDI Type change orders will be uploaded to SFTP site. . EDI Type ………….

Present the design graphically

image

Architecture and Topology
shows over all architecture of scenario, a sample below:

image

Platforms/Portability Issues

Where the solution can work, a sample:

This Scenario will only work on BizTalk Name and version, Commerce Server Name and Version.
or
In case of (A), nothing special is needed on the operating system other than bla bla bla.
In case of (B), it will require certain level of setting for MSDTC for windows [version x] (not Windows version x)

Assumptions and Dependencies

Following assumptions are made for your scenarios release:
a.    Where development of scenario will be done.
b.    Adapter for will be used for development
c.    BAM alert and notification Service will be used
d.    BAS Trading Partner will be used

Partners and Dependencies

List all partners and dependencies types, logical, application and technological, a sample:
Adapters dependencies?
There is a dependency on the SAP Adapter and the MQ Series adapter –
The SAP and the MQ Series adapters covers all requirements? .
Need mainframe connectivity for development and test?
Need Partner support for development or test?

Issues and Risks
List all Issues and Risks of the solution, sample below:

Need to get some particulars libraries or Adapter bits as early as possible. Delay in getting these bits may cause slippage in schedule.
Some issues may arise with the Inter-BTS adaptor design

The next part of this article will start with the most important aspect the Detail Design.

The Detail Design describe in detail the high level architecture of the solution, graphically and with descriptions in detail.
It’s the more complex session of the document, It must cover all the most important aspect as:

Design Challenges, Exception Handling, Integration, Boundary Conditions, Security, Authentication, Authorization,
Impersonation, Performance, Globalization/Localization, Test Support, Manageability, Supportability, Serviceability,
Migration, Multi-Machine Installation, Multi-Domain Installation, Runtime Considerations, Tuning and Throttling,
Large Messages, Multi-Message Box,Tracking, Threading and Concurrency, Fault Tolerance

next topics to the next article.

About these ads

2 comments

  1. Pingback: Scott Banwart's Blog › Distributed Weekly 201
  2. Pingback: BizTalk Solution Documents AID–The Design Specifications–part 2 | Nino Crudele'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