Q: You’ve recently published a webcast on the updated WCF SAP Adapter and are quite familiar with ERP integration scenarios. From your experience, what are some of the challenges of ERP integration scenarios and how do they differ from integration with smaller LOB applications?
A: There are definitely a few challenges that a BizTalk developer has to overcome when integrating with SAP. The biggest being they likely have no, or very little, experience with SAP. On the flip side, SAP resources probably have had little exposure to a middleware tool like BizTalk. This can lead to many meetings with a lot of questions, but few answers. The terminology and technologies used by each of these technology stacks are vastly different. SAP resources may throw out terms like transports, ALE, IDoc, BAPI, RFC where as BizTalk resources may use terms such as Orchestrations, Send Ports, Adapters, Zombies and Dehydration. When a BizTalk developer needs to connect to an Oracle or SQL Database, they presumably have had some exposure in the past. They can also reach out to a DBA to get the information that they require without it being a painful conversation. Having access to an Oracle or SQL Server is much easier than getting your hands on a full blown SAP environment. I don’t know too many people who have a personal SAP deployment running in their basement.
Another challenge has nothing to do with technology, but rather politics. While the relationship between Microsoft and SAP has improved considerably over the past few years, they still compete and so do their consultants. Microsoft tools may be perceived poorly by others and therefore the project environment may become rather hostile. This is why it is really important to have strong support from the project sponsor as you may need to rely on their influence to keep the project on track. Once you can demonstrate how flexible and quickly you can turn around solutions, you will find that others will start to recognize the value that BizTalk brings to the table. Even if you are an expert in integrating with SAP, there is just some information that will require the help of an SAP resource. Whether this is creating the partner profile for BizTalk or understanding the structure of an IDoc, you will not be able to do this on your own. I recommend finding a “buddy” on the SAP team whether they be a BASIS admin or an ABAP developer. Having a good working relationship with this person will help you get the information you need quicker and without the battle scars. Luckily for me, I do have a buddy on our BASIS team who is more interested in Fantasy Football than technology turf wars.
Overall, Microsoft has done a good job with the Consume Adapter Service Wizard. If you can generate a schema for SQL Server, then you can generate a schema for an SAP IDoc. You will just need some help from a SAP resource to fill in any remaining gaps.
Q: “High availability” is usually a requirement for a solution but sometimes taken for granted when you buy a packaged application (like BizTalk). For a newer BizTalk architect, what tips do you have for ensuring that ALL aspects of a BizTalk environment are available at runtime and in case of disaster?
A: Certainly understanding the BizTalk architecture helps, but at a minimum you need to ensure that each functional component is redundant. I also feel that understanding future requirements may save you many headaches down the road. For instance most people will start with 2 BizTalk Application servers and cluster a SQL back end and figure that they are done with high availability. They then realize that when they are trying to pull a message from a FTP or POP3 server that they start to process duplicate messages since they have multiple host instances. So the next step is to introduce clustered host instances so that you have high availability but only one instance runs at a time. The next hurdle is that the original Operating System is only “Standard” edition and can’t be clustered. You then re-pave the BizTalk servers and create clustered host instances to support POP3/FTP only to run into a pitfall with hosted Web/WCF Services since you need to load balance those requests across multiple servers. Since you can’t mix Windows Network Load Balancing with Windows Clustering, this becomes an issue. There are a few options when it comes to providing NLB and clustering capabilities, but you may suffer from sticker shock.
Another pitfall that I have seen is someone creating a highly available environment, but neglecting to cluster the Master Secret Server for Enterprise Single Sign On. The Enterprise Single Sign On service does not get a lot of visibility but it is a critical function in a BizTalk environment. If you lose your Master Secret Server, your BizTalk environment will continue to use a cached secret until this service comes back online. This works as long as you do not have to bounce a host instance due to a deployment or unplanned outage. Should this situation occur, you will be offline until you get your Master Secret Server back up and running. Having this service clustered allows you some additional agility as you are no longer tightly coupled to a particular physical node.
Q: I’ve asked other interview subjects which technologies are highest on their “to do” list. However, I’m interested in knowing which technologies you’re purposely pushing to the back burner because you don’t have the cycles to go deep in them. For instance, as much as I’d like to dig deep into Silverlight, ASP.NET MVC and WF, I just can’t prioritize those things over other technologies relevant to me at the moment. What are your “nice to learn, but don’t have the time” technologies?
A: Oslo and SharePoint.
Oslo is a technology that will be extremely relevant in the future. I would be surprised if I am not using Oslo to model applications in the next couple years. In the mean time I am happy to sit on the sidelines and watch guys like Yossi Dahan, Mikael Håkanssson and Brian Loesgen challenge the limits of Oslo with Connected Systems technology. Once the feature set is complete and is ready for primetime I plan on jumping on that bandwagon.
A lot of people feel that SharePoint is simply a website that you just throw your documents on and forget about. What I have learned over the last year or so while working with some talented colleagues is that it is much more powerful than that. I have seen some creative, integrated solutions provided to our field employees that are just amazing. Having such talented colleagues take care of these solutions reduces my desire to get involved since they can take care of the problem so much quicker, and better, than I could.
By no means am I knocking either of these technologies. BizTalk continues to keep me busy on a daily basis and when I do have some time to investigate new technologies I tend to spend this time up in the cloud with the .Net Service bus. These requirements are more pressing for me than Oslo or SharePoint.
Q [stupid question]: The tech world was abuzz in July over the theft and subsequent posting of confidential Twitter documents. The hacker got those documents, in part, because of lax password security and easy-to-guess password reset questions. One solution: amazingly specific, impossible-to-guess password reset questions. For instance:
- How many times did you eat beef between 2002 and 2007?
- What’s the name of the best-looking cashier at the local grocery store?
- What is the first sentence on the 64th page of the book closest to you?
Give us a password reset question that only you could know the answer to.
A: As a kid which professional athlete did you snub when they offered you an autograph?
True story, as a kid my minor hockey team was invited to a Winnipeg Jets practice. While waiting inside the rink, the entire Edmonton Oilers team walked by. Wayne Gretzky stopped expecting my brother and I to go running up to him asking for an autograph. At the time, we both were New York Islander and Mike Bossy fans so we weren’t interested in the autograph. He seemed a little surprised and just walked away. In retrospect this was probably a stupid move as this was probably the greatest ice hockey team of all time that included the likes of Mark Messier, Paul Coffee, Jari Kurri and Grant Fuhr.
Thanks Kent. Some good stuff in there.