If you’re looking to dig a bit deeper into WCF security, and specifically how to perform particular tasks, go check out J.D. Meier’s blog for a link list of new “how tos” and videos recently posted to CodePlex.
Specifically, you’ll find some useful demonstrations for creating temporary certificates for message-based security, some interesting looks at impersonation, using SQL Role Providers for authentication, and more.
Technorati Tags: WCF
My company’s “standard operating procedure” for BizTalk Server doesn’t call out the specific requirements to deploy among environments (development to test, test to production, etc), so I’m trying to help the team get those articulated. Here’s my first stab at a checklist that should be followed for BizTalk application migration between environments. I don’t want the list to be abusive, but want it to be as comprehensible as possible. Any feedback is appreciated.
| Migrate from Local Development to Shared Development | ||
| Task | Comments | |
| 1. | Code review executed by BizTalk team | Refer to BizTalk Code Review guidelines |
| 2. | Consistent system artifact naming in place | System DSNs, application configuration settings |
| 3. | Server access request approved | BizTalk Administrator rights ok |
| 4. | User has taken BizTalk developer training, and optionally, BizTalk administrator training | |
| 5, | BizTalk application and host usage defined | Are standard hosts used, or are additional ones defined? Does this project belong in an existing BizTalk Application, or a new one? |
| 6, | Reusable assets are factored into common applications and assemblies | Schemas, web services, business rules |
| 7. | Application security requirements are clearly identified | Authentication and authorization |
| Migrate from Shared Development to Test | ||
| Task | Comments | |
| 1. | Code successfully builds and runs all core use cases | |
| 2. | Code review is re-executed if significant deviations discovered during initial code review | |
| 3. | Performance test plan is in place | Test expected load + 25%; test LOB adapters to confirm downstream system load acceptance |
| 4. | Repeatable release management from development environment is set up | Binding files created, MSI built, scripts constructed; helper components and web services added to MSI |
| 5. | Exception handling strategy is confirmed | System retries, exception logging, resuming suspended messages |
| 6. | Application is ready for multi-box deployment | All hard-coded file system references considered |
| 7. | List prepared of all encountered application and system exceptions, and resolution strategy for each | Used for testing and eventual administration purposes |
| 8. | Need for new host instances or changes to throttling settings considered | |
| 9. | All web services are managed by governance platform [SOA Software] | |
| Migrate from Test to Production | ||
| Task | Comments | |
| 1. | Application monitoring requested and configured [Microsoft Operations Manager] | Identify events to monitor and notification recipients |
| 2. | Appointed application administrator has BizTalk Operator rights approved | |
| 3. | All web services are managed by governance platform [SOA Software] | |
| 4. | Debug statements removed and Event Log trace statements removed | |
Technorati Tags: BizTalk
Scenario: I want to allow BizTalk Server 2006 (R1) to send XML (InfoPath forms) to a MOSS 2007 document library without resorting to hacks.
Resolution: I can’t use the out-of-the-box BizTalk SharePoint adapter (only BizTalk Server 2006 R2 works natively with MOSS 2007) so I decided to utilize the available SharePoint web services to upload my file. I wrote a wrapper web service to (a) encapsulate some additional logic (b) shield the BizTalk developer from understanding SharePoint services and (c) require no usage of the SharePoint 2007 object model.
What did this solution look like? I decided to use the CopyIntoItems method available on the SharePoint Copy web service. This allows you to send a byte array of data to a document library and have it appear as a new document. To hit the WSDL for this service, you’d go to:
http://<your sharepoint base url>/sites/<site name>/_vti_bin/Copy.asmx
Here you’ll see the CopyIntoItems operation. My wrapper service starts with a couple “using” statements …
using System.Net; //for NetworkCredentials object using System.Text; //for encoding bytes using System.IO; //for stringwriter using System.Xml;
Next I have my wrapper operation …
[WebMethod] public string UploadXmlToSharePoint(string docToUpload, string siteRoot, string docLibrary, string fileName, string userName, string password, string domain)
I’m taking the XML document input as a string in order to make the schema easier in BizTalk, and, ensure I don’t lose my InfoPath processing instructions when transporting over the wire (which seemed to be happening when I used an XmlDocument type input parameter). Also note that I’m taking in a user/password/domain combo. This is to allow for reuse later down the line. The account used to call the SharePoint service MUST be a site administrator, so I’m making it an explicit parameter. The first thing I do inside my operation is build up the destination Uri based on the input parameters.
//build full destination Url string destinationPath = siteRoot + "/" + docLibrary + "/" + fileName;
Next I have to take the input string and convert it to the byte array required by the MOSS web service …
//convert string to byte array
byte[] fileIn = ConvertDocToBytes(docToUpload);
...
private byte[] ConvertDocToBytes(string xmlString)
{
ASCIIEncoding encoding = new ASCIIEncoding();
return encoding.GetBytes(xmlString);
}
Now I need to instantiate some values needed by the MOSS service. First we have the “result” object which conveys the state of the copy transaction. Then I have a “FieldInformation” array which can be used to pass in specific field values. Note that you CANNOT pass in a null value here, or else you get a cryptic error when calling the service. You can make it blank, but don’t use a null parameter in its place. Finally, I create a destination Uri array.
//holds MOSS service response values
SharePointSvc.CopyResult[] results;
//required fieldinformation array
SharePointSvc.FieldInformation fieldInfo =
new SharePointSvc.FieldInformation();
SharePointSvc.FieldInformation[] fieldInfoArray = { fieldInfo };
//destination url (notice that it's an array, meaning
//multiple sites COULD be targeted
string[] destUri = { destinationPath };
Now I can actually call this puppy. After instantiating the web service proxy class (generated by the Add Web Reference command), I need to provide explicit credentials.
//create instance of web service proxy
SharePointSvc.Copy copy = new SharePointSvc.Copy();
//pass valid credentials
copy.Credentials = new NetworkCredential(userName, password, domain);
//call primary operation; sourceUri, doesn't matter here
copy.CopyIntoItems(
"http://none",
destUri,
fieldInfoArray,
fileIn,
out results);
The last step is to actually check the “result” object for errors and return any errors back to the caller.
//check for error and return final result
if (results[0].ErrorMessage != null)
{
return "Error: " + results[0].ErrorMessage;
}
else
{
return "Success";
}
Sweet. After building and deploying this service, I can call it from any client, BizTalk (2004/06) included. I’ll obviously want to securely store my credentials (using Enterprise Single Sign On) and not embed those in my client directly.
So if I call my service, and pass in a plain old XML file, it shows up in my document library as expected.
Now, if I send an InfoPath document to a Forms Library set up with an InfoPath template, the result is this …
Nice! The document is recognized as an InfoPath document (see the icon), and, the promoted columns are properly loaded.
So, if you’re interested in a fairly easy way to programmatically upload documents to a MOSS 2007 library, without having to use the SharePoint object model or BizTalk adapter, this web service might just work for you.
Technorati Tags: SharePoint, BizTalk
I’d like to think that my company is fairly far along the SOA path, but we’ll be spending time this year looking to refine our SOA reference architecture and map our progress on a SOA maturity model. Most of the maturity models out there have some sort of scale which ranges from “starting with basic services in pilot projects” and graduates to “enterprise services and process orchestration” all the way to “agile, event-driven environments.” If you’re unfamiliar with concept, check out what Sonic has to say.
All that said, I was thinking about some of the lower-level, tangible ways that I could observe whether we were indeed becoming more advanced in our SOA journey. So, I put together a short list of 10 criteria that would indicate to me that we were doing more than paying lip service to the architectural principles of SOA. Let it be noted that I don’t think my company does many of these, but you can’t know what you’re shooting for if you don’t throw up a target.
Thoughts? Do you find that you or your company already do many of these? Or do you think any of these criteria are unnecessary or incomplete?
Technorati Tags: SOA
The BizTalk product team keeps pumping out posters, so I guess that I’ll keep highlighting them. This particular one focuses on the core BizTalk databases, their functions, and how they relate to each other. Specifically, you’ll find each BizTalk database alongside it’s role, functional events, data movement events and more. Given that SQL Server databases form the heart and soul of BizTalk Server, it’s fairly important that any self-respecting BizTalk person knows this information.
I can’t imagine that there are many more poster ideas left for the BizTalk team to produce. I mean, what’s left? Security roles? Functoids? Maybe they’ll mail it in and produce a poster of the product team itself playing a spirited game of freeze tag.
Technorati Tags: BizTalk
After reading today’s Dilbert comic, I’m not sure Wally is the standard-bearer for architects that I want to get behind …
I’ve finally gotten around to publishing my source code for my SSO Configuration Data Store Tool. You can download both the runtime application and underlying source code from here. If you want to mess around with it, great, but please keep my name on there.
Although I’m not finished with my “BizTalk + WCF” series for TopXML.com yet, I have finished the first part of the series on consuming WCF services. So, I’ve put the source code I used for all those demonstrations right here. The binding file is in there as well. Once I finish the last part of the series, I’ll post that source code too.
Enjoy.
It’s just over a year ago that my company switched from their previous EAI platform to BizTalk Server 2006. Over that time, we’ve learned some best practices for setting up a brand new BizTalk program, and I thought I’d share my “Top 10” recommendations for organizations getting started with BizTalk. The below recommendations aren’t in any particular priority-based ordering …
So there you go. My company learned some of those lessons above the hard way, so hopefully I can save someone else a little heartache.
For those of you who have helped establish BizTalk for your own company (or as a consultant), are there other recommendations you’d like to share?
Technorati Tags: BizTalk
A few interesting Microsoft Knowledge Base hotfixes for BizTalk Server 2006 were recently added and worthy of sharing.
Technorati Tags: BizTalk
UPDATE: I have since moved these articles to my own blog and they can be found here.
I just posted another article for TopXML.com as part of my series on BizTalk + WCF. This post covers the various ways to expose WCF services and endpoints out of BizTalk itself.
Topics include: exposing one-way services, working with services exposed via schemas or orchestrations, handling exceptions, generating MEX endpoints, hosting the WS-Http adapter in-process, using simple type service parameters, and using multi-part messages.
Richard Seroter's Architecture Musings 