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.
Is composed from three areas
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
Architecture and Topology
shows over all architecture of scenario, a sample below:
Where the solution can work, a sample:
This Scenario will only work on BizTalk Name and version, Commerce Server Name and Version.
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:
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.