Top 14 Integration Challenges I’ve seen in the Past 14 Years
•Download as PPTX, PDF•
1 like•1,090 views
Stephen W. Thomas been working with BizTalk Server and Integration using Microsoft products since Tuesday February 27th, 2001. Since then he has worked on over 21 different client projects all over the world. Clients range in size from small companies to large Fortune 500 powerhouses. This session will take a look at the top 14 client challenges that Stephen has run into in the past 14 years of working in the field and how to address them.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (6)
Similar to Top 14 Integration Challenges I’ve seen in the Past 14 Years
Similar to Top 14 Integration Challenges I’ve seen in the Past 14 Years (20)
More from BizTalk360
More from BizTalk360 (20)
Recently uploaded
Recently uploaded (20)
Top 14 Integration Challenges I’ve seen in the Past 14 Years
- 1. tSponsors Stephen W. Thomas Integration MVP Top 14 Integration Challenges I’ve seen in the Past 14 Years BizTalk Summit 2015 – London ExCeL London | April 13th & 14th
- 2. About Me • 11 Year Integration MVP • Pluralsight Author • Run BizTalkGurus.com and BizTalkGuru.com • 21+ Clients in over 14 years • Twitter: StephenWThomas • Email: me@BizTalkGurus.com or me@BizTalkGuru.com
- 3. Recap from Last Year • I left my wife, 3 year old, and 2 week old at home • Talked on Azure IaaS • PowerShell to create BizTalk Domains
- 4. Overview • Review the top challenges and difficulties I have ran into over the past 14 years. • Goal is to think about and avoid these challenges to deliver better solutions.
- 13. Thinking BizTalk Is Like .Net 6 BizTalk is just C# code. FX Cop should work.
- 19. Questions? Email: me@BizTalkGurus.com or me@BizTalkGuru.com
Editor's Notes
- A lot of times projects want to train .Net resources in BizTalk Mastering BizTalk (and other technologies) sometimes requires you to be able to let things go and not try to apply “logic” to all situations. Why doesn’t the Admin Console auto refresh? Why sometimes even after a host restart, bouncing the server just makes everything work.
- Pain to deal with Operations teams but in the long run that is a better way to go. Saw a Dev add a TOP 1 to a SQL Receive Stored Procedure and ended up spending about 24 straight hours on the phone with Microsoft Support.
- BizTalk name boxes can be small and hard to read. Always remember to change the default Operation on Send Port from Operations_1.
- Spent 40 hours to build a custom MS Build based few click deployment for a client. Saved 100’s of man hours over the course of a year doing daily redeployments into testing environment. Using BTDF helps a lot, but requires a little bit of a learning curve.
- As an integrator we have access to and see critical data in the enterprise. Custom Orders, SAP, Salesforce, out to the cloud. We usually transform this data from one format to another. Quickly become the GOTO resource for data question. I was the Commerce Server Catalog lead for a month on a project.
- Out of the box the ESB Toolkit is a little buggy and limited. This causes projects to drastically miss use it. This combined with #14 Resources gets some projects into trouble. Then they think “BizTalk is broken or doesn’t work” It is ok to mix ESB and non-ESB processes. The exception management framework is awesome.
- Not just for production. More than one project ran out of SQL disk space during testing. Cost was about 1 day each occurrence. My experience is on both extremes, either they have 3 servers to handle a few messages an hour or they have 2 servers to handle 150 messages a second.
- Most of the time the issue is how to define a “unit test” in BizTalk. Using BizUnit to smoke test / unit test a new deployed costs time in the beginning but well worth it in the long run.
- All about trying to educate. BizTalk is a platform. Clients want to run FxCop. Client want to change DLL version numbers. Clients don’t understand why it needs a separate build process.
- Rarely does a client have a 2nd environment that mirrors production. It is important to have at least one multi server environment outside of production Easy to do in Azure
- Depends on the maturity of BizTalk at that client. Clients that are already running BizTalk do this better. Transition to support make more than documentation. Will see errors in other systems first in BIzTalk.
- Seen this on 2 separate clients with very strong operations teams. Most of the time its based on past experience with poorly written BizTalk code. At the time of deployment, operations telling developers to change code. Operations based decisions vs Business based. Involve early and education.
- Often complex frameworks and processes are put in place How often to they really get reused? This is why I love Microservices!
- Always told BizTalk is broken so we research deep into other systems Learn a lot about the other systems Other people start to not like us because we know almost as much as they do