What is important, what will be the correct for you and your BizTalk environment?
In order to make a framework you should have a good knowledge of BizTalk. Not just as a developer but also as an Administrator. The difference is huge, and having a good knowledge about both could become very helpful!
Keep the names of your colleagues out of the framework, they might not work there tomorrow!
Sometimes hiring a senior BizTalk Administrator to do this job could be the right for you. You are free to contact me for more information and BizTalk administrator i can recommend for this job.
Having a good framework documented will make it easier when you hire new people and getting them up to date on how you work because, BizTalk is not used the same everywhere. It will be easier to hand over a framework to consultants whom just are in for a little while.
First you need to determine what kind of integrations you have, do you need "100%" uptime, or is it okay if you turn them off for a couple hours, maybe during night, or weekends? You need to take this to consideration when you want to complete a framework for BizTalk.
Do you have a local development office, or do you order them "out of office" ? What demands can you set, and what are your current requirements?
How are you working, are you currently using PowerShell to implement new integrations, or are you doing it manually, is it working good enough?
What kind of environments do you have currently, do you have a test, pre installation and production environment?
Recomended environment:
Development Environment - Not reachable for BizTalk Administrators
This is the environment where the development takes part; this is where only the developers have access.
Pre-installation environment - Not reachable for developers
Will the integration install successfully, or will it fail during installations, this is a clean environment, running this on VMWare or Hyper-V
Test environment - Not reachable for developers
This is where you do a full scale test of the integrations, test messages and "stress testing" should be done here.
Production environment - Not reachable for developers
Little or less needs to be said about this environment. Its production.
My test and production environments are identical, they all have the same assembly files (unless some newer are under testing) the servers are set up the same way, same hardware and same BizTalk installation (can be run under another domain as the production to cut off some costs for licensing, same goes for the Pre-Installation environment.
My BizTalk servers in test and production is a total of 4, 2 single and 2 clustered. The clustered server have the responsibility for the WCF and other adapters requiring for HTTP or IP on receive.
I can control the production environment from my local computer using MMC (I will post more information regarding this).
There are a few topics that will be covered in the framework:
Change LogKeep the document well sorted, and well documented, keeping a change log is vital to make sure the documentation is up to date, and recent changes can be looked up easy.
PurposeWhat is the purpose of this framework, why do you need it, and why should you follow it?
PrerequisitesWhat do you need in order to make sure this document can and will be followed, except from a BizTalk environment, do you need and other departments to follow this framework?
ResponsibilitiesMany have the BizTalk administrators divided into doing different tasks; one may have the responsibility of taking care of new integrations, error handling, health checking and so on. Describe all the different tasks that needs to be done (keep names out of the document since people tend to change jobs every now and then)
Describe the tasks in full detail, example of tasks;
- BizTalk Integrations
- Error handling
- Installing new integrations
- health checkNew integrationsWhat should be done when new integrations comes from development, in my example the integration must first be installed in the pre installation environment. If this goes bad the integration is returned back to development for fixing. If it goes well, with no errors it should be installed in test, when installing it in test we should have test messages and correct documentation in hand. Maybe you prefer to have two weeks of testing to make sure you have tried all combination of the new integrations, what happens if the message is empty? What happens if you remove something from the file? What happens if a part of the messages is not received? When should it land under suspended in BizTalk, should you maybe have an error catalog for some type of errors?
Changes to existing integrationsWhat do you need to take into consideration, as I mentioned earlier the questions is, what if the integration needs to be up every day, except for one day a year, maybe more or maybe even less? (PowerShell can do this for you very easy). What do you require, can the new installation be installed over the old one, do you have versioning on all assembly and file paths?
Handover ProceduresWhat are your requirements when you get a new integration, do you have a meeting with the developers, going thru the whole integrations or is documentation good enough?
In general, the new integration or changes to existing integrationsDescribe in general your requirements for handing over new or changes to exsisting integrations.
Delivery of the integrations from development to managementDescribe in depth what you requirements are for all integrations handed over from development to management.
Documentation requirementsDo you have documentation requirements, where can they be located?
ChecklistsWhen a new integrations comes in, do you have a checklist the integrations must pass before you can install it in production? If not make one, and follow it!
Quality assurance of new integrationsHow can you as a BizTalk administrator give assurance to the users of the integration that is fulfills the requirements you have, and they expect?
Approval of new integrationsHow do you approve new integrations? Describe in depth.
Implementation of new integrationsHow do you implement new integrations, are you using PowerShell, or are you installing the integrations on its own, is it some integrations that needs to be done one way or the other? If you have any of these, describe the type and why it needs to be done this way.
Internal testing of new integrationsHow do you test the integrations, what tools are you using, are you manipulating messages to see the affect it has, do you let the developers test?
Integration EnvironmentHere you need to write about the environments, write some general information, what kind of environments do you have, where are they located, what are the hardware, how do they work? Clustered or not? What are their names and DNS names. What are the environments called? A good Visio drawing could help a lot.
BizTalk HostsI assume you have some hosts, write them all down, you should also mention that you are running receive locations with one user, orchestration with one user and send with another, security is important people!
Example:ReceiveHost64
This is a receive host running 64-bit. This host has the responsibility of all files and is running on all the servers at the same time.
IsolatedHost
This is an isolated hos, this host is only running on server1 and server2, these two servers are clustered. This host only runs WCF receive locations.
OrchestrationsHost
This is by default a 64-bit host at hour environments. These hosts run on all the servers and have the responsibility to do the orchestrations of all integrations.And so on…Installation Guide for BizTalk ServerHow do you install BizTalk servers at your company, do you have special requirements for hardware, do you have special requirements for where the SSO should be and how the MSSQL should be setup, this is the place to put this into writing.
Roadmap for Integration EnvironmentThis category has 2 sub categories
- Current target imageWhat are your current target
- Future target imageWhat are you future goals?
Web servicesWeb services are getting used more and more, you should have some information on how they are set up at you company.
Setup Web farmHow is it setup, is it running on one server, several, clustered and how!
Name StandardRemember to always have a good standard for naming integrations, both WS and BizTalk integration should have its own preset way. This makes it easier to work with, and easier to troubleshoot.
You have to sub categories:
- BizTalk
- WebServicesTroubleshootingHow do you troubleshoot, there are a few sub categories here, you can add more if you need them.
- Deviation HandlingHow do you do the deviation, send emails, register them in some ITIL or similar procedures?
- What defines a deviation
I usually like to say that anything that is not normal operation is a deviation.
- Errors
What are your procedures during errors, if a message is suspended (maybe its described in the documentation) if the BizTalk environment is giving out errors, what do you do?
- Residual error
I often call integrations that gives me residual errors for “problem integrations” integrations providing a known error, that occurs over and over again is a risk to the environment and should be taken care of as soon as possible.
- Many suspended messages
What do you do if you have to many suspended messages, have you stress tested your environment and know how many you can handle?
- Too many active messages
What do you do if a message is running active for too long, and what if they pile up?
- Orphaned messages
What are your routines on orphaned messages, this is a known issue in BizTalk 2006 – 2009. How do you check for them and how often. When do you remove them?
- Patching (Microsoft security patch and BizTalk patching)
How is patching being done by you, do you take test first? Do you need to test all integrations before implementing the patches to the production, or is the patching going automatically?
- Health CheckHow and when do you perform a health check do you have one with Microsoft?
MonitoringHow do you monitor BizTalk, do you have programs, who have access and what are they doing?
Manual MonitoringWhat is your manual routines for monitoring?
Automatic monitoringWhat is your automatic routine for monitoring (could I recommend my BizTalk Monitord? Can be located on sourceforge.com)
Change and upgrade proceduresHow do you change and upgrade your environments, do you do a migration to a new set of servers, do you have any certain vulnerabilities?
Versioning of applicationsWhat are your stands on versioning the applications? Assembly files, and other required files for integrations?
More topics will be given later, for now. Good night.
