A key part, and sometimes overlooked part of any integration project are the operational requirements. Everyone is very busy trying to figure out how the whole solution is going to work, but someone needs to determine how this thing is going to continue to operate. Keep in mind that there are all kinds of thing that can make your solution stop working such as passwords getting changed (a typical enterprise security requirement), software patches getting installed, etc. Additionally, things need to be thought about early in the process, like how are we going to make updates to assemblies with minimal (or NO) downtime.
I have put together a list (perhaps just the beginnings) of some key operational requirements to think of.
- Plan an effective backup strategy - Prepare a strategy that minimizes the time taken to recover the system to an operable state in the event of a catastrophic failure.
- Disaster Recovery - Create a plan for how databases will be restored. Determine recovery model assumptions for connected applications.
- Patching procedure - A clear plan needs to be developed for patches made to the BizTalk production environment. This should include items such as versioning of files, deploying the patch while avoiding (or limiting) downtime, best time to avoid service interruption, etc.
- System and application health - Track the health status of the system and application to ensure operations are performed within expected parameters or agreed service levels.
- System and application performance monitoring - Track the system and application response times and resource usage.
- Boundary for information security - Define what type of information must be protected within the solution.
- SSO Master Secret needs to be restorable - Configuration of adapters will be lost if key becomes corrupt or lost in the event of a crash. Backup the master secret from the master secret server.
- Purge/Archive historical data from Tracking database - Run the Purge_DTADB.sql script to create the stored procedures to maintain the tracking database. These stored proc's may need to be edited to get the desired affect (purging to a remote database for example).
- All BizTalk databases must be backed up transactionally - Backing up individual databases and restoring individually will not work as it breaks transactional integrity. Read on-line documentation to become familiar with how to enable sql agent job "Backup BizTalk Server".
- Avoid resource contention - BizTalk receiving, sending and orchestration processing should be segregated in separate hosts.
- Host instances running File Adapter needs access to receive locations - A DACL should be employed that grants read, write, delete files and delete subfolders and files permission on the directory from which the file receive location picks up messages to the service account hosting the receive locations.
- Files can not be read only - Any file that will be received by BizTalk from any location (MQ queue, file directory, etc) will not be marked read only.
This list is by no means complete, and there will be other operation requirements that will be specific to your situation, but it should generate some thought. We all want to get in there and play with the code, but due diligence to the operational requirements at an early stage will prevent a lot of headaches (and late night phone calls).
I will try to make following posts be a little more BizTalk centric. I’m working on some RoleLink examples that should be wrapped up soon!!!