Many thanks to all the guys and gals of the Little Rock .NET User Group for having me in to do the "WCF Deep Dive" for 6 hours today. Despite some challenges from the lab, we made allot of good headway. I promised the code and slides, so here they are : SlidesConsole Application in Visual BasicConsole Application in C# (with ConcreteCalculator corrected)"Wildly Chatting Friends" Web Application Thank you all for putting up with me as I did my first long class, it taught me a great deal that will shape my future longer training sessions and I got the impression most of you learned something. My thanks again to Larry Taylor and the all those who helped us over our issues with the Lab and Network security.
Sometimes the weirdest things come up when testing. I was helping with some Integration Testing recently, and we needed to submit a new valid postal address with every request to this system. That's a hefty load to bear, and certainly if I were doing Unit Testing I'd be mocking away that system just to not have to deal with that problem, but for Integration Tests there was no way around it. My answer? Public data my good friends. The quest started with Google, as most do, and a search criteria like this : City State Zip filetype:csv Which after browsing for several pages I modified to: City State Zip filetype:csv site:usps.com That resulted in the CSV which is the source of the data we're using, a list of Post Offices across the nation. The list is very long, a total of 19,931 addresses. Now, it wouldn't be fair to just list the Google queries here, after all this is a technical blog. I took the CSV apart, removed the irrelevant fields and parsed it into an object to hold address data, specifically this object. [Serializable]public class AddressData{private string _Name;public string Name{get { return _Name; }set{_Name = value;}}private string _StreetLine1;public string StreetLine1{get { return _StreetLine1; }set{_StreetLine1 = value;}}private string _StreetLine2;public string StreetLine2{get { return _StreetLine2; }set{_StreetLine2 = value;}}private string _City;public string City{get { return _City; }set{_City = value;}}private string _State;public string State{get { return _State; }set{_State = value;}}private string _Zip;public string Zip{get { return _Zip; }set{_Zip = value;}}}Now if you compile your own version of that code, and create a List<AddressData> you should be able to Deserialize this file of all the addresses for your own use.
With my current client I've had a chance to work with the SAP adapter for the first time, which is a treat since most of my work with BizTalk has revolved around HIPAA and EDI. So I've been working with it for several weeks, and I very much like the delivery of the adapter with one, glaring gotcha which I'll discuss. The way the adapter works is that you can access any iDoc or RFC from SAP by creating a port configured with identity you will connect with, and then selecting to add items to your solution and select Add Generated Items... and finally select "Add Adapter Metadata". You can then walk through the process of selecting your port and searching for your RFC or iDoc. When you've completed the wizard you will have a newly generated XSD schema added to your project. Happy days, and off you go, until deployment time. You see, when the wizard walked through that process, for an RFC, it generated an assembly, quietly, in a directory which on most boxes will be : C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\Bin. That assembly is required for the Adapter to work at runtime, and as such must be included in your deployments. Add to this pickle that the assembly is not strongly named, so you can't put it in the GAC like everything else and life get's really interesting. This one caught me completely off guard, and personally I consider this a major flaw in the design of the adapter. I've now added two new items to my "To Do" list. First, implement Scott Colestock's deployment framework on my project so I don't have to deal with external resources and the BizTalk "Export MSI" functionality. Second, learn more about the Line of Business Adapter SDK and the new WCF adapters to systems like SAP that I attended a talk about at TechEd this year.
