BizTalk Solution Documents AID–The Design Specifications–part 2

This is the second 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.
You can find the first part here

In this 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.

Detail Design

Detailed design can be divided into three parts based on architecture.

  1. Presentation Layer: In presentation layer, we will describe the messages flow layer from all actors, for example:
    the messages will be received from site1, http post . In order to receive messages from site1 we need to build site1 using technology X.

Describe the work Items for Site1:

    1. Create new user profiles.
    2. Modify this feature site
    3. Upload file
  1. Business Workflow Layer: In this layer we will describe graphically the messaging flow layer

GRAPHIC DIAGRAM

Describe all steps in the flow, for example:

A. Create New Order: Partner1 will send request either using http URL provided by Hub.

B. When New order is posted to site, ASPX page of site will drop message to MSMQT location on BizTalk Server.

If exist describe particular security aspects, for example,
This request will be encrypted using X.509 certificates.

Describe messaging typology and structure, for example,

Sample EDI Header:

image

After the Design Detail we will start to describe the others important aspect.

Exception Handling

Describe the methodology used in the solution covering all of the parts, coding, orchestration exception strategy, if necessary graphically too, for example:
In all use cases have Orchestration and there is no custom code involved in it.
Orchestration will have exception handler as shown in figure.

image



Integration

Describe the most relevant aspect about integration strategy, for example:

BAS Integration: B2B scenario will use BAS for Trading Partner Management.
Trading partner management is done using website provided BAS feature.

BAM Integration: BAM will be used to send alerts and notifications to vendors and broker.
Information required for BAM will be tracked using Tracking Profile Editor as shown in figure.

image

Other important aspects to cover are:

Boundary Conditions

In this section we will Identify all boundary conditions implied by this design, or to be covered by this design

Security

In this section we will Identify all boundary conditions implied by this design, or to be covered by this design

Authentication

In this section we will Identify all authentication strategy

Authorization

In this section we will Identify all authorization strategy

Impersonation

In this section we will Identify all impersonation strategy

Performance

In this section we will Identify all performance requirements, for example
According to functional specification 1.000.000 orders will be processed End-End per day.

The most important aspect is identify the possible messages peeks, for example

According to functional specification 1.000.000 orders will be processed End-End per day with a peek of 500.000 between 2:00 AM and 3:AM.

 

Globalization/Localization

In this section we will describe possible Globalization/Localization strict

Test Support

If functional specification contains specific items required to enable testability.
This section identifies specific work and impacts on the algorithms necessitated by test support

Manageability

List policies and settings the admin and IT professionals can set to affect this features behavior.

Supportability

List considerations for supporting the feature: things like tracing, diagnostics.

Serviceability

List any issues and considerations for updating this feature set after it’s been deployed. Do we need to stop the service to replace the component? Do we need to reboot?

Migration

In this section we will describe possible strict and requirements about migration

Multi-Machine Installation

Create and refer to an architecture diagram.

image

MulTi-Domain Installation

Describe the domain installation, for example:
The scenario will have two domains. One domain for front servers facing outside world.
Another domain will be used for rest for servers which are behind corpnet firewall.

Runtime Considerations

Tuning and Throttling

List considerations on tuning and throttling.

Large Messages

In this section we will list all possible large messages peeks

Multi-Message Box

If exist describe the multi-message box strategy, configuration, scopes
image

Tracking

Describe the tracking strategy of the solution, for example:
Tracking will be enabled for BAM. Body tracking will be enabled for this scenario.

Threading and Concurrency

Describe possible threading and concurrency issue

Fault Tolerance

Describe the fault tolerance strategy, for example:

image

SQL Server will be clustered in active-passive node.
Minimum scenario will have 2 BizTalk for fault tolerance.

About these ads

One comment

  1. Pingback: Scott Banwart's Blog › Distributed Weekly 203

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