I finally launched a web site for my consulting company:
http://www.entechsolutions.com
At the same time I packaged BETA versions of XLib and XWebSiteTemplate. You can find these products as well as AutoSuggestBox control in the ‘Developer Corner’ section of the web site.
Please see complete post here:
Recently, one of the clients of my consulting business asked for an integrated email solution. I did some research and found that EmailLabs would fit client needs. They are one of the few companies that provide an API to their email marketing solution. The only issue is that their API is very basic — it works by sending and receiving XML messages through HTTP.
To simplify things I wrote .NET web service that wraps around HTTP messages. It allows .NET developers to quickly tap in into list management, message building and sending functionality provided by EmailLabs. The web service is available at the following location:
http://samples.entechsolutions.com/EmailLabsWebService/Service.asmx
This web service encapsulates about 80% of functionality of EmailLabs API. For this release I concentrated on most useful functions. I didn’t implement functions used for managing Filters and adding/editing Demographics.
To demo the API you can contact EmailLabs to setup a demo account. For testing they let you send e-mails with up to 50 recipients. Or you can send me an e-mail I will give you access to my demo account.
Security Considerations
For API integration EmailLabs provides IP security. For every mail list you can specify a list of IP Addresses that can contact EmailLabs API. To test .NET web service you can provide security the following 2 ways:
A. Disable IP Security for the list
For this approach you may want to create a new test list, so security for other lists stays the same.
B. Add IP Address ‘66.129.79.80′ to secure IP addresses list
This IP address is dynamic, so it is possible that it may change. Let me know if you get authentication error using this approach.
FYI: If you create a new mailing list using Web Service API – it will automatically add appropriate IP address to the list of allowed IP addresses.
Please see the full post here:
If you specify 'DataObjectTypeName' parameter in ObjectDataSource — UpdateParameters get ignored. So if you have:
<asp:ObjectDataSource ID="objectDataSource" runat="server"
DataObjectTypeName="Customer" InsertMethod="Save"
UpdateMethod="Save"
DeleteMethod="Delete"
SelectMethod="LoadList"
TypeName="CustomerLogic"><UpdateParameters>
<asp:Parameter Name="CategoryID" DefaultValue="5"/>
</UpdateParameters>
</asp:ObjectDataSource>
When you do update — parameter 'CategoryID' is not bind to Customer.CategoryID.
The solution to this problem is to add parameters dynamically in Updating event handler:
protected void objectDataSource_Updating(object sender, ObjectDataSourceMethodEventArgs e)
{
Customer customer=(Customer)e.InputParameters[0];
customer.CategoryID=5;
}
When reading MSDN documentation for ObjectDataSource.SelectMethod I found the following paragraph.
If the DataObjectTypeName property is set, the method is resolved in a different way. The ObjectDataSource looks for a method with the name that is specified in the SelectMethod property that takes one parameter of the type that is specified in the DataObjectTypeName property. In this case, the name of the parameter does not matter.
I tried it, but it doesn't look like it works. ObjectDataSource still looks for a method that has multiple SelectParameters arguements and not one 'DataObjectTypeName' arguement.
This is inconsistent with documentation for 'ObjectDataSource.DataObjectTypeName' where it says that:
Instead of specifying several parameters that are passed to the Update, Insert, and Delete methods, you can create one object that aggregates several data field values. This one object is passed to the methods, instead of several parameters.
Since my 'Select' method can have dozens of parameters I would rather use a class then dozens of arguements. I think the reason it works diferently from (Update/Insert/Delete) is that in some cases Search Arguements may be different from the ones required for Insert/Update/Delete. For example class Customer may have 'DateCreated', but CustomSearch will have 'DateCreatedFrom' and 'DateCreatedTo'.
The solution would be to provide another ObjectDataSource property 'SelectDataObjectTypeName' and hopefully MS can implement it for next update. For now they just need to fix up the documentation.
